루트 서버는 13개가 아니다. 1,900개가 넘는다. 사람이 사는 거의 모든 대륙에 흩어져 있고, 오늘 당신의 쿼리에 답하는 그 서버는 십중팔구 같은 도시 안에서 몇 밀리초 거리에 있다. 그런데도 모든 설명글, 모든 인터뷰 답변, 모든 자격증 교재가 13이라고 말한다. 틀린 숫자다. 20년째 틀려 있다. 그리고 그게 여태 살아남은 이유가 숫자 자체보다 더 흥미롭다.
13은 실재한다. 단지 엉뚱한 걸 세고 있을 뿐이다. 루트 서버 식별자가 13개다 — A부터 M까지, a.root-servers.net부터 m.root-servers.net까지 — 그리고 이걸 12개의 독립된 조직이 운영한다. (Verisign이 A와 J를 둘 다 운영하고, 나머지는 하나씩 맡는다.) 이 식별자들은 기계가 아니다. 각각은 하나의 IP 주소이고, 그 주소 뒤에는 한 무리가 앉아 있다.
왜 12도 50도 아닌 13인가
이 숫자는 1987년에 고정됐다. 고정시킨 건 패킷 하나였다.
DNS는 UDP 위에 지어졌고, 거기엔 단단한 천장이 있었다. 응답은 512바이트 안에 들어가야 한다, RFC 1035에 따라. 게으름이 아니었다 — 512는 어떤 IP 경로든 단편화 없이 한 데이터그램으로 실어 나른다고 모두가 믿었던 크기였다. 그 아래로 머물면 답이 한 방에, 통째로, 재조립 없이 도착한다.
이제 리졸버가 애초에 루트를 어떻게 찾는지 생각해 보자. 루트 서버를 DNS로 조회할 수는 없다 — 루트가 DNS의 출발점이니까. 그래서 리졸버는 작은 부트스트랩 파일(이른바 “루트 힌트”, 전통적으로 named.root)을 들고 다니다가, 시작할 때 프라이밍 쿼리를 던진다. 루트 서버 하나에게 묻는 것이다. “루트 서버들이 다 누구냐?” 답은 모든 루트 이름과 그 주소의 목록으로 돌아온다.
그 답이 512바이트 안에 들어가야 했다.
계산해 보면 빠듯하다. 서버 하나마다 답변(answer) 섹션의 이름 하나와 추가(additional) 섹션의 주소 레코드 하나가 든다. 질문, 헤더, 레코드마다 붙는 오버헤드까지 더하면, 이름-주소 쌍 13개쯤에서 자리가 딱 떨어진다. 14번째였다면 응답이 512바이트를 넘겨 잘림(truncation)을 일으켰을 것이다. 그래서 운영자들은 13에서 멈췄다. 위원회가 고른 행운의 숫자가 아니라 — UDP 패킷 하나에 들어가는 최대 개수였다.
이 “서버 13개”라는 틀이 지금은 적극적으로 사람을 오도하는 지점이 여기다. 그 제약은 사라졌다. EDNS0(RFC 6891)가 512바이트 천장을 진작에 들어 올렸고, 프라이밍 응답은 이제 IPv6 글루까지 싣고, 옛날식 데이터그램 하나를 넘어선 지 오래다. 13의 공학적 근거는 만료됐다. 숫자는 만료되지 않았다. 루트 식별자의 개수를 바꾼다는 건 지구상 모든 리졸버에 박혀 있는 루트 힌트를 다시 맞춰야 한다는 뜻이고, 아무도 그걸 재미로 건드리지 않으니까. 그래서 13은 이제 설계 결정의 의상을 걸친 역사적 잔재다.
IP 하나, 수백 대의 기계
식별자 개수가 13에 얼어붙어 있다면, 어떻게 용량을 키우고, 공격을 견디고, 모두의 코앞에 루트 서버를 가져다 놓는가? 라우팅에서 꼼수를 쓴다.
그 꼼수가 애니캐스트다. 13개 IP 주소 중 하나를 골라, 그걸 수십 군데, 수백 군데 물리적 위치에서 동시에 BGP — 인터넷의 라우팅 프로토콜 — 로 광고한다. 모든 사이트가 자기가 그 주소라고 주장한다. 당신의 쿼리가 나가면 라우팅 망은 늘 하던 일을 한다. 네트워크상 가장 가까운 사이트에 패킷을 넘긴다. 목적지 IP는 똑같지만, 당신이 어디 있느냐에 따라 닿는 기계는 천차만별이다. 서울에서 K-루트로 던진 쿼리와 상파울루에서 K-루트로 던진 쿼리는 완전히 다른 하드웨어에 도착하고, 두 클라이언트 다 그걸 모르고 신경도 안 쓴다.
그래서 “루트 서버가 몇 개냐”에는 깔끔한 답이 없다. 주소는 13개. 운영자는 12개. 그리고 2026년 기준, 그 주소들에 응답하는 물리적 인스턴스가 1,900개가 넘는다 — 운영자들이 사이트를 늘릴 때마다 그 수는 계속 올라간다. 13은 라우팅 프로토콜이 여러 장소에 주소 하나를 기꺼이 공유시켜 만든, 실제 쇳덩이 위에 씌운 논리적 허구다.
애니캐스트는 원래 계획이 아니었다. 한 대 맞고 나온 대응이었다. 2002년 10월 21일, 공격자가 13개 루트 전부에 약 한 시간 동안 트래픽을 퍼부었다. 시스템은 대체로 어깨를 으쓱하고 말았다 — 서버들이 그 쓰레기 트래픽을 걸러내고 있었으니까 — 하지만 13개의 뚱뚱한 표적이 인터넷의 토대로서는 나쁜 모양새라는 분명한 경고였다. 해법은 13개의 표적이기를 그만두는 것이었다. K-루트를 운영하는 RIPE NCC는 전 세계에 미러 인스턴스를 깔았고, F-루트도 똑같이 했다. 다음 대형 공격이 2007년 2월 6일에 — 24시간짜리 공습으로 — 왔을 때, 애니캐스트된 서버들은 여러 사이트에 부하를 분산시키며 버텨냈고, 그만큼 널리 분산하지 않았던 몇몇 루트는 실제 타격을 입었다. 똑같은 13개 이름 아래에서 아키텍처가 조용히 바뀌어 있었고, 그게 드러났다.
가장 작은 꼼수: 직접 운영하기
이 질문 전체를 거의 케케묵은 것으로 만들어 버리는 마지막 수가 있다. 당신의 리커시브 리졸버는 루트 서버에 아예 안 물어봐도 된다.
루트 존은 작다 — 사실상 모든 TLD와 각각을 책임지는 네임서버의 목록일 뿐이다 — 그리고 공개돼 있다. RFC 8806(실험적이던 RFC 7706을 대체했다)은 현재 루트 존 전체를 복사해 당신 리졸버의 루프백 주소에 올리는 방법을 설명한다. 이제 모든 루트 쿼리는 로컬에서, 마이크로초 단위로 답해지고, 기계 밖으로 절대 나가지 않는다 — 왕복 지연을 죽이고, 당신이 어떤 TLD를 조회하는지 누가 엿보는 것도 막는다. 일부러 루프백에 가둬 놨다. 실수로 네트워크 나머지에 루트를 서빙하기 시작해 아무도 부탁한 적 없는 1,901번째 인스턴스가 되는 걸 막으려고. RFC들은 이걸 베스트 프랙티스가 아니라 운영상 위험이 따르는 선택지로 신중하게 규정한다. 하지만 존재한다. 그리고 그건 루트를 그냥 한 부 가질 수 있다는 뜻이다.
그러니 “루트 서버가 몇 개냐”에 대한 정직한 답은 이렇다. 뭘 세느냐에 따라 다르고, 13은 그 집합에서 가장 쓸모없는 숫자다. 이름이 13개인 건 2000년대에 더는 중요하지 않게 된 패킷 크기 때문이다. 기계가 1,900개 넘는 건 라우팅 꼼수가 번호 재배정 없이 시스템을 키우게 해줬기 때문이다. 그리고 정확히 하나가 더 있을 수 있다, 당신의 루프백 위에, 누구에게도 묻지 않겠다고 마음먹는 그 순간.