도메인은 소유가 아니라 임대였다 — .name 3단계 종료가 드러낸 것
도메인은 소유가 아니라 임대였다 — .name 3단계 종료가 드러낸 것
도메인은 우리가 소유한 식별자인가, 아니면 레지스트리의 사업 판단에 종속된 임대물인가. 22,000개의 주소를 지우는 절차에는 그 주소를 쓰는 사람이 당사자로 등장하지 않는다.
도입
2026년 9월 3일, 엔지니어 닐 프레이저(Neil Fraser)는 자신의 사이트에 “.name Termination” 이라는 짧은 글을 올렸다. 25년 가까이 써 온 neil.fraser.name 이 사라진다는 통보를 며칠 전 등록대행사(레지스트라)로부터 이메일로 받았다는 내용이다. 그 주소는 그의 웹사이트이자 이메일 주소였고, API 를 제공하는 서버의 호스트명이었다. 그는 “이 도메인은 YouTube 와 Facebook, 스마트폰보다 먼저 있었다”고 적었고, 딸이 태어난 직후 beverly.fraser.name 도 등록했다고 덧붙였다. 글은 Hacker News 에서 2,146점과 500건이 넘는 댓글을 모으며 그 주의 최대 화제작이 됐다.
글 자체는 통보를 받은 개인의 기록에 가깝다. 그러나 그 뒤에 놓인 공개 문서들 — Verisign 이 ICANN 에 제출한 신청서 두 건, ICANN 이 Verisign 앞으로 보낸 2026년 7월 28일자 통지, 한 등록인이 제기한 재심 청구와 그에 대한 옴부즈맨 평가·이사회 위원회 권고 — 를 시간 순으로 읽으면 개인의 사연보다 훨씬 구조적인 것이 드러난다. 도메인 이름 하나가 세상에서 지워지는 절차에서, 그 이름을 실제로 쓰는 사람은 심사 대상도 아니고 통지 대상도 아니다. 이것은 실수가 아니라 설계다.
여기서 던져야 할 질문은 “Verisign 이 나쁜가”가 아니다. 그 질문은 답하기 쉽고 아무것도 바꾸지 못한다. 더 유용한 질문은 이것이다. 우리가 도메인을 등록할 때 실제로 취득하는 권리는 무엇이며, 그 권리는 누구를 상대로 주장할 수 있는가.
신청서 두 장에서 종료 통지까지, 넉 달 반
먼저 사실 관계를 문서에 적힌 대로 정리한다.
.name 은 2001년경 개설된 gTLD 로, 처음부터 3단계 등록을 전제로 설계됐다. 즉 firstname.lastname.name 형태로 등록하는 것이 원형이고, *.ny.us 나 *.co.uk 처럼 정식 whois 레코드를 갖는 등록 단위다. 프레이저는 자신이 .name 을 고른 이유 중 하나가 운영 주체가 Verisign 이 아닌 Global Name Registry 였기 때문이라고 썼다. 그 뒤 Verisign 이 Global Name Registry 를 인수했다.
2025년 10월 15일, 11월 4일, 12월 16일 — 세 차례에 걸쳐 Verisign 과 ICANN 은 제출 전 사전 협의를 진행했다. 이 사실은 재심 청구서와 이사회 책임메커니즘위원회(BAMC) 권고문에 각각 기재돼 있다.
2026년 4월 15일, Verisign 은 레지스트리 서비스 평가 정책(RSEP)에 따라 신청서 두 건을 제출했다. RSEP 2026013(케이스 번호 01581614)은 .NAME 의 3단계 도메인 등록 서비스 중단, RSEP 2026014(케이스 번호 01581607)는 .NAME 이메일 전달 서비스와 2단계 이메일 주소의 중단이다. 신청서가 제안한 결과는 명확하다. 중단 이후 신규 3단계 등록은 받지 않으며, 기존 3단계 등록은 종료(삭제)된다.
Verisign 이 밝힌 사유는 “제한적인 레지스트라 지원과 3단계 도메인 사용 감소”이며, 약 22,000건의 3단계 등록이 있지만 “그 대다수는 사용되지 않고 있다”는 설명이 붙었다. 서비스 중단이 “.name TLD 운영의 효율을 높일 것”이라고도 적었다. Verisign 은 또한 “사용자 기반의 다수를 차지하는 일부 레지스트라 그룹과 구두로 협의했으며” 그들 중 누구도 보안·안정성·경쟁 문제를 제기하지 않았다고 신청서에 기재했다.
2026년 5월 7일 ICANN 은 두 신청을 승인했고, 5월 8일 RSEP 절차 웹페이지에 승인 사실을 게시했다. 여기서 첫 번째 비대칭이 드러난다. 승인은 5월 초에 이미 공개돼 있었지만, 그것은 아무도 상시 관찰하지 않는 페이지 위에서였다. 프레이저가 사실을 안 것은 8월 말이다. 참고로 프레이저는 글에서 “7월 28일 ICANN 이 이를 승인했다”고 썼는데, 문서상 승인일은 5월 7일이고 7월 28일은 별도의 통지 문서 날짜다.
그 7월 28일자 문서는 ICANN 의 어맨다 페센던(Amanda Fessenden, GDD 계정·서비스 부문 부사장)이 Verisign 의 패트릭 케인(Patrick S. Kane, 네이밍 서비스 수석부사장)에게 보낸 서한이다. 서한은 .NAME 레지스트리 계약의 갱신 협의가 진행 중이라는 이유로, 만료 예정인 계약의 개정 대신 이 서한을 발행한다고 명시한다. 즉 계약서를 고치는 대신 편지 한 통으로 공개 고지를 갈음한 것이다. 서한은 Verisign 이 제안한 대로 서비스를 중단해도 좋다고 확인하면서, 통지 의무를 세 줄로 규정한다. 3단계 .NAME 등록을 지원하는 레지스트라에게 최소 90일 전 사전 통지, 최소 30일 전 재통지, 그리고 절차 전반에 걸친 고객 지원.
이 대목의 각주가 이 사건 전체를 요약한다. 서한 각주 1은 이렇게 적혀 있다. “등록인과의 커뮤니케이션에 관해서는, 레지스트라가 레지스트라-등록인 관계를 관리한다.”
즉 ICANN 은 Verisign 에게 레지스트라를 향한 통지 의무만 부과하고, 그 통지가 실제 사용자에게 도달하는지는 레지스트라-등록인 계약의 문제로 넘긴다. 프레이저가 8월 말에야 소식을 들은 것은 이 사슬의 정상적인 작동 결과다.
프레이저가 특히 문제 삼은 것은 자신의 도메인이 “2040년까지 등록·결제가 완료돼 있음에도” 2월에 사라진다는 점이다. HN 에서는 이 진술 자체에 의문이 제기됐다. 도메인 등록에는 10년 상한이 있는 것으로 아는데 어떻게 2040년까지 결제가 가능하냐는 것이다 (@xyzzy_plugh). 이에 대해 10년치 등록에 더해 레지스트라 단계의 선납 갱신이 얹힌 형태일 것이라는 추정이 나왔지만 (@swiftcoder), 확인된 답은 스레드에 없다. 다만 선납 자체는 쟁점으로 실재한다. 재심 청구서는 도메인이 표준 최대 등록 기간인 10년까지 선납 갱신될 수 있다는 점을 지적하며, 신청서가 만료 전 종료 시의 환불·크레디트·그랜드파더링·보상에 대해 아무것도 다루지 않는다고 적었다.
”생애주기에는 영향이 없다” — 심사가 묻지 않도록 설계된 것들
이 사건이 HN 에서 폭발한 직접적 계기는 신청서의 답변들이었다. 한 이용자는 신청서 3.6항 — “귀사의 제안 서비스로 제품이나 서비스가 영향을 받을 수 있는 주체들과 소통한 적이 있습니까” — 에 대한 답이 “아니오. 해당 없음”이었다고 지적하며, 신청서 전반의 답변이 몇 단어에 불과하다고 요약했다 (@mchesters). 다른 이용자는 2.1항 “제안 서비스가 도메인 이름의 생애주기에 어떤 영향을 미칩니까”에 대한 답이 “없음. 도메인 이름의 생애주기에 어떠한 영향도 없을 것”이었음을 인용하며, 3단계 도메인을 전부 삭제하는 변경이 정의상 생애주기에 영향을 주지 않을 수 없다고 반박했다 (@ipython). 경쟁 관련 항목에도 “경쟁에 미치는 영향은 없다”, “해당 없음. 도메인 이름 시장에 미치는 영향은 없다”는 답이 달렸다.
다만 정확을 기하자면, 3.6항의 “해당 없음”은 생략된 두 번째 문장(“있다면 그 소통 내용을 기술하시오”)에 대한 답으로 읽는 것이 자연스럽다는 반론도 나왔다 (@chrismorgan). 같은 이용자는 더 날카로운 지적을 덧붙였다. 이 신청서는 신규 서비스 도입을 전제로 만들어진 양식인데, 실제 제안은 기존 서비스의 폐지다. 그래서 질문 상당수가 무의미해진다는 것이다.
이 관찰이 핵심이다. 문제는 Verisign 이 양식을 성의 없이 채운 것이 아니라, 양식이 묻는 것과 이 변경이 초래하는 것이 애초에 겹치지 않는다는 점이다.
실제로 등록인 한 명이 이 논리를 정식 절차에 올렸다. 2026년 6월 2일, DODO.DODO.NAME, GEORGE.DIMITROV.NAME, ASEN.ILIEV.NAME 세 개의 3단계 도메인을 보유한 도이친 스피리도노프(Doytchin Spiridonov)가 재심 청구 26-2를 제기했다. 청구 취지에는 승인 정지, 승인 근거 공개, 공개 의견수렴 절차의 개시, 그리고 유료 만료일까지의 유지(그랜드파더링) 또는 그에 상응하는 환불·보상이 포함됐다.
결과는 기각 권고였다. 7월 31일 ICANN 옴부즈맨의 실질 평가, 8월 24일 BAMC 권고 모두 재심 사유가 없다고 결론지었다. 중요한 것은 기각의 이유다.
첫째, 심사 범위. ICANN 의 7월 28일 서한이 직접 밝히듯, RSEP 에 따른 ICANN 의 평가는 제안된 변경이 “(i) 중대한 보안 또는 안정성 문제를 야기할 수 있는지, (ii) 중대한 경쟁 문제를 야기할 수 있는지”에 한정되며, “RSEP 의 문언에 의해 제한되고 제안된 서비스 도입 또는 기존 서비스 폐지의 다른 잠재적 영향에는 미치지 않는다.” BAMC 는 같은 논리를 재확인했다. 이주 비용, 인터넷 정체성의 단절, 선납금 손실은 “등록인들에게 중요하다는 점은 이해되지만” RSEP 심사 범위 밖이라는 것이다.
둘째, 구제 수단의 소재. BAMC 권고문 각주 7은 청구인이 요구한 공개 의견수렴, 그랜드파더링, 환불이 재심 절차의 범위를 넘어서거나 “레지스트라와 등록인 사이의 계약으로 규율되는 사항이며 ICANN 은 그 계약의 당사자가 아니다”라고 못박는다. 등록인이 손해를 주장할 상대는 ICANN 도 Verisign 도 아니고, 자신의 등록대행사다. 그런데 등록대행사는 레지스트리가 서비스를 없애기로 한 결정을 되돌릴 힘이 없다.
셋째, 그리고 가장 논쟁적인 부분. BAMC 는 “생애주기에 영향이 없다”는 답변이 허위가 아니라고 판단하면서 이렇게 논증했다. “도메인 등록의 조기 종료는 도메인의 생애주기에 영향을 주지 않는다. 해당 도메인은 여전히 표준 생애주기의 각 단계를 거칠 수 있기 때문이다.” 즉 “생애주기”는 등록·갱신·만료·삭제로 이어지는 상태 기계의 정의를 가리키며, 그 기계에 실제로 들어가 있는 22,000건이 강제로 종료되는 것은 정의를 바꾸지 않는다는 해석이다. 옴부즈맨도 22,000이라는 숫자에 대해 “개인들에게는 중요하지만, 엄격히 정의된 커뮤니티 개발 정책에는 관련이 없다”고 적었다.
이 해석은 형식적으로 방어 가능하다. 그리고 바로 그 점이 문제다. 검사가 묻는 질문과 사람들이 걱정하는 위험이 서로 다른 대상을 가리키고 있다면, 검사를 아무리 정직하게 통과해도 위험은 걸러지지 않는다. HN 의 한 이용자가 “도시계획 결정처럼 영향받는 이용자를 상대로 공개 의견수렴 기간을 거쳐야 하는 것 아니냐”고 물은 것은 (@swiftcoder) 정확히 이 결손을 지적한 것이다. RSEP 은 20년 된 합의 정책이고, 레지스트리 운영자가 서비스를 추가·변경·제거할 수 있게 하는 창구로 설계됐다. 등록인은 그 창구의 반대편에 없다.
한 이용자는 “이미 돌아가고 있는 것을 두고 효율을 높이겠다는 것은 터무니없는 변명”이라며, 백엔드를 교체하거나 기성 소프트웨어를 도입하려는데 이 특이한 TLD 가 맞지 않으니 그냥 플러그를 뽑는 것으로 보인다고 썼다 (@xp84).
구조적 원인은 경제성이다. TLD 의 수명을 결정하는 것은 기술이 아니다. 22,000건의 3단계 등록은 데이터베이스로서는 사소한 규모다. HN 의 한 이용자는 “22,000건이면 계산기에도 들어갈 크기인데 관리 부담이 크다는 주장은 납득되지 않는다. 게다가 대다수가 미사용이라면 그 부담은 대체 어디서 나오는가”라고 반문했다 (@bityard). 하지만 레지스트리 입장에서 문제는 저장 비용이 아니라, 이 서비스가 EPP 처리 경로·레지스트라 지원·계약 문언·분쟁 처리에 만들어 놓은 영구적인 예외 처리다. 수익이 그 예외 처리의 유지비를 넘지 못하는 순간, 그 서비스는 정리 대상이 된다. 참고로 Domain Incite 는 5월 11일 보도에서 .name 전체 등록 수를 약 96,000건으로 전하며 2단계와 3단계의 내역은 공개되지 않았다고 적었고, HN 에서도 종료 대상 22,000건은 3단계이고 2단계 등록 약 10만 건은 그대로 유지된다는 지적이 나왔다 (@decimalenough).
식별자가 끊길 때 함께 끊기는 것들
프레이저가 글에서 진짜로 경고한 것은 사이트가 사라진다는 사실이 아니다. 그 다음이다.
3단계 도메인이 종료되면 그 위의 2단계 도메인이 비게 되고, 등록 가능한 상태가 될 것으로 보인다. 만약 제3자가 fraser.name 을 확보하면 그는 neil.fraser.name 을 그대로 재현할 수 있다. 그 주소로 발급된 계정의 비밀번호 재설정 메일을 받을 수 있고, 그의 인증으로 코드를 커밋할 수 있으며, 그 도메인의 서비스를 바라보는 IoT 기기를 장악할 수 있다. 프레이저의 표현대로, 25년간 그 이메일 주소로 개설된 계정을 온·오프라인을 통틀어 전부 열거할 방법은 없다.
이것이 도메인 종료가 단순한 링크 부패(link rot)와 다른 이유다. 링크 부패는 참조가 끊기는 문제다. 도메인 회수는 참조가 살아 있는 채로 소유자가 바뀌는 문제다. 도메인 이름은 지난 20년 동안 웹 주소를 훨씬 넘어선 역할을 떠맡았다. 이메일 주소이자 사실상의 계정 식별자이고, OAuth 및 SSO 의 도메인 검증 단위이며, 이메일 서명과 인증서 발급의 통제 증명 대상이고, 논문·코드 저장소·패키지 네임스페이스에 박히는 영구 링크의 접두사다. TLD 하나가 사라질 때 끊기는 것은 웹페이지가 아니라 이 전부다.
.name 의 경우 그 위험이 하나 더 겹친다. HN 의 여러 이용자가 지적했듯 공개 접미사 목록(Public Suffix List)에 *.name 이 와일드카드로 등재돼 있지 않다. .name 이 3단계와 2단계 등록을 동시에 허용해 왔기 때문에, doe.name 이 예약된 접미사인지 일반 등록 도메인인지 목록 차원에서 구별할 방법이 없다는 것이다 (@nneonneo, @CodesInChaos, @akersten). 결과적으로 브라우저는 joe.doe.name 이 .doe.name 전체에 쿠키를 설정하는 것을 막지 않는다. 즉 이 TLD 의 격리 보장은 종료 이전에도 이미 온전하지 않았다.
이 위험이 가설이 아니라는 증거는 같은 TLD 의 과거에 있다. 한 이용자는 .name 초기에는 신분증을 제출해 본인 이름임을 입증해야 firstname.lastname.name 을 등록할 수 있었고 그 등록에 firstname@lastname.name 이메일 전달이 딸려 왔는데, 어느 날 아무런 사전 통지 없이 그 이메일 주소가 작동을 멈췄다고 증언했다. 더 답답한 것은 그 뒤의 대응이다. 그는 자신이 쓰는 2단계 도메인 아래에 다른 3단계 등록자가 없다는 사실을 레지스트리 측도 인정했음에도, 그 2단계 도메인을 자신에게 넘겨 달라는 요청이 15년 넘게 거절당했다고 적었다 (@p4bl0). 이번 종료가 만들어 낼 공백에 대해서도 같은 종류의 해법이 존재한다. 기존 등록은 유지한 채 신규 3단계 등록만 중단하고, 3단계가 걸려 있는 2단계 도메인은 계속 예약 상태로 두는 것이다 (@nneonneo). 신청서에는 그런 언급이 없다.
그렇다면 대안은 무엇인가. 각각이 실제로 무엇을 보장하고 무엇은 보장하지 않는지 구분해야 한다.
자체 2단계 도메인 보유는 3단계 위험을 없앤다. 하지만 임대 구조 자체를 없애지는 못한다. .name 이 아니어도 레지스트리는 계약을 갱신하고 정책을 바꾸며, 국가 코드 TLD 는 지정학의 영향을 받는다. HN 의 한 이용자는 “다른 TLD 로 옮기면 되지 않느냐”는 물음에 “그가 잃는 것은 기존 주소에 묶인 계정들이므로, 어차피 옮길 것이라면 어떤 도메인이든 마찬가지”라고 답했다 (@echoangle). 이전은 미래의 위험을 줄이지만 과거에 뿌려 놓은 식별자를 회수해 주지는 않는다.
ORCID, DOI 같은 영속 식별자는 학술 인용의 안정성을 위해 설계됐고 그 목적에는 잘 작동한다. 그러나 이들은 참조를 안정시킬 뿐 인증 주체가 아니다. 계정 복구를 ORCID 로 하지는 않는다. 게다가 이들 역시 운영 기관이 유지하는 서비스이며, 최종적으로는 해석기(resolver) 도메인에 의존한다.
IPFS, DID 류의 탈중앙 식별자는 이름과 운영 주체의 결합을 끊는 데 목적이 있다. 키를 쥔 사람이 식별자를 통제한다는 점에서 회수 위험은 확실히 줄어든다. 대신 두 가지를 보장하지 못한다. 사람이 읽고 받아쓸 수 있는 이름과, 키를 잃었을 때의 복구다. 그리고 현실의 서비스는 여전히 이메일 주소를 계정 축으로 쓴다.
DNS 자체를 신뢰 기반으로 삼는 길도 튼튼하지 않다. HN 에서 한 이용자는 2년간 Tranco 상위 1,000 사이트의 DNSSEC 도입을 추적한 결과 그 기간 새로 활성화한 곳이 8곳에 불과했다고 밝혔다 (@tptacek). 도메인 계층을 신뢰의 뿌리로 승격시키려는 시도는 지난 20년간 반복적으로 좌초했다.
그래서 실무적 결론은 소극적일 수밖에 없다. 첫째, 계정 축을 도메인에서 분리하라. 조직이라면 SSO 의 사용자 식별자를 이메일 문자열이 아니라 불변 ID 로 잡아야 한다. HN 토론에서도 Google 계정 주소 변경 기능을 써 본 이용자가, 사용자 ID 가 아니라 이메일 문자열을 키로 삼는 서비스에서 OAuth 문제가 생길 수 있다고 전했다 — 그리고 “대부분의 사이트가 그렇다”고 덧붙였다 (@avarun). 둘째, 식별자 인벤토리를 만들어 두라. 프레이저가 계정을 열거할 수 없다고 쓴 것은 개인의 태만이 아니라 25년의 누적이다. 어떤 서비스가 어떤 주소를 복구 경로로 쓰는지 목록이 없다면, 도메인 위험은 발생 시점까지 측정 불가능하다. 셋째, 만료일보다 종료 리스크를 보라. 선납 10년은 레지스트라와의 계약이지 레지스트리의 서비스 존속 보증이 아니다. 이번 사건이 정확히 그 차이를 보여줬다.
결론
처음의 질문으로 돌아가자. 도메인은 소유한 식별자인가, 임대물인가.
문서가 주는 답은 명확하다. 임대물이며, 심지어 임대차의 당사자는 전대인(레지스트라)이지 건물주(레지스트리)가 아니다. ICANN 의 심사는 보안·안정성·경쟁만을 묻고, 그 밖의 영향은 명시적으로 범위 밖이다. 구제는 등록인과 레지스트라 사이의 계약에 맡겨져 있는데, 그 계약의 상대방은 서비스 폐지를 되돌릴 권한이 없다. 22,000건이라는 숫자는 “개인들에게는 중요하지만 정책에는 관련이 없다”고 기록됐다. 절차의 어느 단계에서도 거짓말이 필요하지 않았다.
이것이 이 사건의 불편한 지점이다. 규탄할 악당이 있으면 문제는 오히려 쉽다. 여기서는 각 주체가 자기 규칙 안에서 정확하게 움직였고, 그 결과 아무도 답하지 않는 질문 하나가 남았다. 25년 된 식별자를 지우는 결정에서 그 식별자의 사용자는 어디에 있어야 하는가.
프레이저는 글을 “변호사를 구할 때”라는 문장으로 끝냈다. 그 소송이 어떻게 되든, 개인이 사후에 소송으로 다투는 것이 유일한 구제 경로라는 사실 자체가 설계의 실패다. 선례도 같은 방향을 가리킨다. HN 토론에서 정리된 경위에 따르면, 2019년 ICANN 이 .org 의 가격 상한 폐지를 제안했을 때 접수된 의견은 반대 3,252건에 찬성 6건이었지만 상한은 그대로 폐지됐다 (@CodesInChaos). 그 뒤 운영 주체가 .org 레지스트리를 사모펀드 Ethos Capital 에 매각하려던 계획을 무산시킨 것도 정식 심사 절차가 아니라 광범위한 비판과 캘리포니아 주 법무장관의 서한이었다 (@qrobit, @NewJazz). 의견수렴은 통과됐고, 제도 밖의 소란이 작동했다.
그렇다면 남는 질문은 이렇다. 당신이 지금 쓰는 이메일 주소가 3년 뒤 다른 사람의 소유가 된다면, 그 사실을 몇 개의 서비스에서 알아차릴 수 있는가. 그 목록을 만들 수 있는가.
출처:
- https://neil.fraser.name/news/2026/09/03/
- https://news.ycombinator.com/item?id=49550772
- https://itp.cdn.icann.org/en/files/consensus-policies/fessenden-to-kane-2-28-07-2026-en.pdf
- https://www.icann.org/en/system/files/files/reconsideration-26-2-spiridonov-request-redacted-02jun26-en.pdf
- https://www.icann.org/en/system/files/files/reconsideration-26-2-spiridonov-bamc-recommendation-24aug26-en.pdf
- https://www.icann.org/resources/pages/reconsideration-26-2-spiridonov-request-2026-06-04-en
- https://domainincite.com/31699-verisign-to-delete-name-3lds-and-email-addresses