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