요약

  • ICANN은 2026년 5월 12일 등록 데이터 정책(Registration Data Policy)을 개정했다. 제10.7조가 효력을 갖는 시점부터 인증된 긴급 요청은 2시간 이내에 접수 확인을 받고, 부당한 지연 없이, 통상 24시간 이내에 답변을 받아야 한다.
  • 정책의 구현 참고 문구는 제10.7조가 ICANN이 요청자 인증을 확립하는 합의 정책(Consensus Policy)을 완전히 이행했을 때에만 효력이 발생한다고 말한다. 규칙의 공개와 의무의 활성화는 별개의 사건이다.
  • ICANN의 인증 인풋 그룹(Input Group)은 개념 실증(proof of concept)을 조언할 뿐 정책을 만들지 않는다. 계획된 2026년 12월 테스트와 2027년 3월 결과 보고서는 그 자체로 계약상 시계를 작동시키지 않는다.
  • 인증은 유한한 요청자 지위를 증명해야 한다. 요청이 긴급한지, 합법인지, 필요한지, 공개를 받을 권리가 있는지를 판단해서는 안 된다. 공개 활성화 접수증은 효력 발생 사건, 자격 증명 범위, 허용된 제출 채널, 타이머 규칙, 예외, 컴플라이언스 분모를 결합하되 그 판단들은 분리된 채로 유지해야 한다.

시계는 텍스트 안에 존재한다

등록 데이터 정책은 이제 긴급 요청에 비정상적으로 명확한 시간적 형태를 부여한다. 제3.8조는 이 범주를 인증된 요청자(Authenticated Requestor)가 제기하는, 생명에 대한 임박한 위협, 중대한 신체 상해, 중요 기반시설 또는 아동 착취에 관한 요청으로 한정하며, 그때에도 공개가 위협에 대응하거나 해결하기 위해 필요한 경우여야 한다. 제3.9조는 요청자를, ICANN 합의 정책에 따라 구현된 메커니즘으로 인증된 법 집행 기관 또는 신뢰되거나 유자격 기관으로 정의한다.

제10.7조는 여기서 절차를 만든다. 요청자는 상황이 긴급 정의에 부합한다고 확인 진술해야 한다. 등록기관과 레지스트리 운영자는 2시간 이내에 접수를 확인해야 한다. 부당한 지연 없이, 예외적 상황이 없는 한 24시간을 넘기지 않고 답변해야 한다. 예외가 적용되면 같은 24시간 창 안에 요청자에게 통지하고 이유를 설명하며, 접수 시점으로부터 72시간을 넘지 않는 예상 답변 시점을 제시해야 한다.

텍스트는 무엇이 연장 사유가 되지 못하는지까지 말한다. 불가항력이나 다수 도메인 이름을 다루는 요청은 예외적 복잡성을 만들 수 있다. 공휴일, 예정된 휴가, 예정된 출장은 그렇지 않다. 이것은 장식적 포부가 아니라, 시작점과 중간 접수 확인, 답변 한계, 제한된 탈출 경로를 갖춘 운영상 의무로 기초되어 있다.

ICANN의5월 12일 발표는 이 범주가 좁은 이유를 설명한다. 이것은 비공개 gTLD 등록 데이터에 대한 평범한 요청을 빠른 큐에 넣은 것이 아니다. 시간이 생명, 신체 안전, 중요 기반시설 또는 아동에 대해 중요할 수 있는 위협에 관한 것이다. 느리거나 모호한 전달은 실제 비용을 초래할 수 있다. 따라서 정밀한 시계는 정당한 정책 목표이다.

그러나 대문자MUST조항만 읽으면 현재 시점에 대한 잘못된 답을 얻게 된다.

시계는 활성화 관문 앞에서 대기 중이다

정책의 구현 참고 문구는 제10.7조의 의무가 ICANN이 요청자 인증 절차를 확립하는 합의 정책을 완전히 이행하는 날 효력이 발생한다고 명시한다. 5월 12일 발표는 법 집행 인증 메커니즘이 구현되기 전까지는 긴급 요청 문구가 효력을 갖지 않는다고 말한다. ICANN의GAC 조언 현황 페이지는 해당 문구가 공개되었기 때문에 타임라인에 관한 조언 항목을 종결하면서도, 24시간 답변 타임라인의 집행은 인증의 가용성이 확보될 때까지 보류 중임을 명시적으로 적어둔다.

이 세 가지는 서로 경쟁하는 설명이 아니다. 서로 다른 세 가지 상태를 보여준다. 정책 텍스트는 공개되었다. 타임라인 작성에 관한 GAC 조언은 종결될 수 있다. 그럼에도 계약상 의무는 여전히 유예될 수 있다.

이 구분은 살아 있는 정책 페이지에서 쉽게 사라진다. 변호사나 컴플라이언스 담당자는 현재 시제로 쓰인 제10.7조를 본다. 법 집행 요청자는 2시간 접수 확인과 24시간 답변을 본다. 등록기관은 페이지 아래쪽의 구현 참고 문구를 본다. 자동화된 정책 목록은 조건 없이 규칙만 색인할 수 있다. 공개 기록에는 필요한 사실이 모두 있지만, 하나의 활성화 상태로 제시되지는 않는다.

문제는 조건부 효력이 본질적으로 부당하다는 것이 아니다. 분산 시스템은 의존성이 가용해지기 전에 규칙을 준비하는 일이 흔하다. 문제는 의존성이 규칙과 함께 다녀야 한다는 점이다. 정책 버전, 활성화 조건, 효력 발생 사건, 대상 집단이 문서가 복제·요약·이행되는 과정에서 분리되면, 같은 문장이 서로 양립할 수 없는 기대를 만들 수 있다.

따라서 첫 번째 규율은 언어적이다. ICANN의 등록 데이터 정책 전체가 효력이 없다고 말하지 말라. 그 정책은 2025년 8월 21일부터 일반적으로 효력을 갖는다. 유예된 조건은 정확히 2026년에 추가된 제10.7조 긴급 요청 의무에 속한다. 마찬가지로, 조항이 살아 있는 합의 정책에 나타난다는 이유만으로 24시간 의무가 집행 가능하다고 말하지 말라.

개념 실증은 활성화 사건이 아니다

ICANN은법 집행 기관 인증 메커니즘 인풋 그룹을 만들었다. 그 임무는 실무적이다. 등록 데이터 요청 서비스(RDRS) 또는 그 후속 시스템을 사용한 법 집행 요원 인증의 개념 실증을 조언한다. 그룹은 워크플로 설계, 기술 요건, 인증 절차를 검토하고 있다.

공개 일정은 유용한 체크포인트를 제공한다. 2026년 6월 구성, 7월부터 회의 시작, 10월 RDRS 와이어프레임, 12월 개념 실증 테스트, 2027년 3월 결과 보고. 그룹은 이미 회의를 시작했다. 프로젝트는 실재한다.

권한도 명시적으로 한정되어 있다. 프로젝트 페이지는 인풋 그룹이 정책 개발 기구가 아니며 정책 권고를 개발하지 않을 것이라고 말한다. ICANN의참여 요청 공고는 이를 조언적이고 이행 중심의 그룹으로 묘사한다. 이 그룹은 요청자 인가에 관한 정책 권고 변경을 검토하는 GNSO 보충 권고팀과 병행하여 작업한다.

병행 작업이 곧 권한 통합은 아니다. 기술 그룹은 기존 법 집행 인증 시스템이 어떻게 상호 운용되는지, 어떤 속성이 필요한지, 철회가 어떻게 작동해야 하는지, 어떤 RDRS 변경이 실용적인지, 로깅을 어떻게 프라이버시 친화적으로 만들 수 있는지 발견할 수 있다. 그 발견은 정책을 이행 가능하게 만들 수 있다. 그러나 그 자체로 제10.7조를 활성화하는 합의 정책이 완전히 이행된 것은 아니다.

따라서 12월의 테스트는 테스트이고, 3월의 보고서는 보고서이다. 어느 날짜도 검토된 자료에서 의무의 효력 발생일로 확인되지 않는다. 어느 쪽이든 자동 활성화로 보는 것은 구현 참고 문구가 막으려 한 바로 그 범주 오류를 반복하는 일이다.

인증은 워크플로를 연다. 요청 자체를 판단하지 않는다

"인증됨"이라는 단어는 지나치게 많은 제도적 무게를 짊어질 수 있다. 자격 증명은 요청자가 인정된 법 집행 또는 유자격 기관 범주에 속하는지, 특정 기관이 자격 증명을 통제하는지, 자격 증명이 유효한지, 제시하는 행위자가 그것을 사용할 권한이 있는지를 증명할 수 있다. 그런 주장조차 정의된 보증 수준, 철회 절차, 감사 기록, 프라이버시 경계를 요구한다.

그러나 자격 증명은 요청에 주장된 사실이 참인지 증명하지 않는다. 상황이 제3.8조의 긴급 정의에 부합하는지 확립하지 않는다. 관할권, 법적 근거, 필요성, 비례성, 요청된 모든 필드에 대한 권리를 확립하지 않는다. 공개가 적용법과 충돌하는지도 판단하지 않는다.

정책은 이 구분을 유지한다. 요청자는 요건을 충족하는 긴급 상황을 별도로 확인 진술해야 한다. 구현 참고 문구는 공개 평가에 관할권 및 기타 적용법 요인이 포함될 수 있다고 말한다. 제10.6조는 거절 사유를 포함한 설명된 답변을 보장한다. 제10.8조는 악의적 요청이나 요청자에 대한 시정 조치를 허용한다. 인증은 사슬의 하나의 조건이며, 사슬에 대한 판결이 아니다.

바로 여기서 유용한 글로벌 메커니즘이 위험한 관문이 될 수 있다. 등록기관이 정의된 요청자 속성을 신뢰하도록 하는 좁은 페더레이션은 반복되는 신원 확인 작업을 줄이고 위기 상황에서 시간을 절약할 수 있다. 그러나 누가 정당한지, 어떤 수사가 긴급한지, 어느 관할권이 우선하는지, 어떤 데이터를 내놓아야 하는지를 조용히 결정하는 광범위한 권한은 법적 판단을 기술적 자격 증명 뒤로 중앙집중화한다.

올바른 설계는 얇은 것이다. 독립적 판단자들이 필요로 하는 가장 작은 재사용 가능한 주장만 검증하라. 보증 수준과 발급자를 가시화하라. 철회와 정정을 허용하라. 개인 데이터를 최소화하라. 그런 다음 실질 판단을 정책·계약·법적 책임을 지는 쪽에 돌려라.

인도 교류는 권한 경계를 드러낸다

현재 상태는 ICANN의 8월 11일자인도 전자통신부 S. 크리슈난에 대한 답신에 그대로 나타난다. ICANN의 CEO는 등록 데이터 정책이 이제 인증된 긴급 요청에 대한 24시간 요건을 담고 있지만, 집행은 적절한 인증 메커니즘에 달려 있다고 말한다. 그는 GAC 공공안전 워킹 그룹, 법 집행 대표자들, 새로운 인풋 그룹과의 작업을 가리킨다.

같은 서한은 15일 검증 기간과 추가 보고 의무를 포함한 인도의 다른 제안도 다룬다. 답변은 제도적으로 정확하다. 등록기관과 레지스트리에 대한 새로운 의무는 적절한 정책 또는 계약 절차를 통과해야 한다. ICANN 정관에 따라 GNSO가 gTLD 정책을 개발하고 정책 개발 절차를 관리한다. CEO는 그 작업을 지원하고 채택된 정책을 이행할 수 있지만, GNSO의 우선순위를 지시하거나 PDP의 결과를 결정할 수는 없다.

이 한계는 관료적 회피가 아니다. 그것은 권한의 사슬이다. 정부는 공공안전 필요를 지목할 수 있다. GAC는 조언을 제공할 수 있다. ICANN 조직은 근거와 운영 전문성을 제공할 수 있다. 인풋 그룹은 메커니즘을 테스트할 수 있다. GNSO는 합의 정책을 개발할 수 있다. 이사회는 정관 안에서 행동할 수 있다. 그런 다음 계약 당사자들이 집행 가능한 의무를 이행한다. 사슬을 건너뛰면 더 빨라 보이지만, 그 결과로 만들어진 의무는 더 쉽게 다투어지고 일관되게 적용하기 더 어렵다.

긴급 대응 프로젝트는 이 권한 지도를 공개적으로 유지해야 한다. 그렇지 않으면 개념 실증 화면이 정책만이 만들 수 있는 의무를 만드는 것처럼 보이고, 정책 조항이 합법적 사안 평가만이 권한을 줄 수 있는 공개를 승인하는 것처럼 보일 수 있다.

빠진 것은 활성화 접수증이다

ICANN에는 작업이 진행 중임을 설명할 또 하나의 긴 서사가 필요한 것이 아니다. 제10.7조의 모든 공개 제시에 붙는, 기계 판독 가능하면서 사람이 읽을 수 있는 간결한 활성화 접수증이 필요하다.

접수증은 정확한 정책 버전과 지문(fingerprint), 합의 정책 의존성, 그 조건을 충족시킨 결정 또는 이행 사건, 효력 발생 날짜·시각·시간대, 그리고 의존 당사자가 사건을 검증할 수 있는 권위 있는 공처를 밝혀야 한다. 어떤 요청자 범주가 대상인지, 어떤 자격 증명 또는 페더레이션 버전이 인정되는지, 자격 증명이 무엇을 증명하는지, 지위와 철회를 어떻게 확인하는지, 어떤 제출 채널이 시계를 작동시키는지도 명시해야 한다.

시간을 정의해야 한다. 접수는 RDRS가 요청을 수락할 때인가, 계약 당사자의 엔드포인트가 수신할 때인가, 운영자가 열어볼 때인가? 재시도 시 어떤 타임스탬프가 남는가? 중복 제출은 어떻게 처리되는가? RDRS를 사용할 수 없을 때 어떤 시계가 적용되는가? 효력 발생 시점에 이미 진행 중이던 요청은 어떻게 되는가?

예외 경로도 묶어야 한다. 2시간 접수 확인, 24시간 답변, 24시간 이내 연장 통지, 72시간 외부 한계, 정책의 비예외 목록. 계약 준수 부서가 언제부터 측정을 시작하는지, 그 분모에 무엇이 포함되는지도 밝혀야 한다. 활성화 이전에 제출된 요청, 인증되지 않은 행위자의 요청, 접수 채널에서 거부된 요청은 유효한 인증 집단과 조용히 섞일 수 없다.

가장 중요하게, 접수증은 부정 진술을 담아야 한다. 인증은 위에 열거한 요청자 속성만 증명한다. 긴급성, 관할권, 법적 근거, 필요성, 비례성, 공개 권리를 확립하지 않는다. 그 판단들은 정책과 법이 그곳에 둔 자리에 남는다.

이 접수증은 Daniel Kade의 제안이며, 현행 ICANN 정책이 아니다. 임원, 기관, 대상, 수사의 공개 목록이 아니다. 운영 필드는 공개할 수 있으면서도 요청자 신원, 도메인 이름, 사안 세부사항, 비공개 등록 데이터는 보호된 채로 유지된다.

수사가 아니라 전달을 측정하라

SSAC의 SAC122 조언은 ICANN에 긴급 요청에 관한 상위 수준 정보 수집을 요청했다. 얼마나 도착했는지, 얼마나 빨리 처리되었는지, 몇 건이 스팸이거나 무효였는지, 몇 건이 계약상 시간 요건을 충족했는지. 최종 정책 세부사항 전부가 통제하는 것은 아니다. 최종 텍스트는 SAC122가 제안한 30분 대신 2시간 접수 확인을 채택했다. 그러나 측정 원칙은 여전히 유용하다.

공개적 책임은 수사를 공개할 것을 요구하지 않는다. 신뢰할 수 있는 분모와 상태 전이를 요구한다. 활성화 이후 접수된 인증된 요청을 세고, 자격 증명 검증에 실패한 요청과 인증은 통과했으나 긴급성 또는 법적 검토에서 실패한 요청을 분리하라. 접수 확인 지연, 답변 지연, 연장 사용, 통지된 예외 범주의 분포, 최종 답변이 72시간 안에 도착했는지 여부를 기록하라. 재식별을 막는 임계값을 두고 집계를 공개하라.

거절을 미처리 답변으로 세지 말라. 제10.7조는 응답 시계이지 자동 공개 시계가 아니다. 시의에 맞고 이유가 있는 거절은 데이터가 공개되지 않았더라도 시간상 의무를 충족할 수 있다. 반대로 결국 공개가 이루어졌더라도 놓친 접수 확인이나 답변 한계는 지워지지 않는다. 결과와 시의성은 서로 다른 축이다.

같은 구분이 양쪽을 모두 보호한다. 법 집행 기관은 사안을 노출하지 않으면서 긴급 채널이 응답하는지 확인할 수 있다. 계약 당사자는 인증 실패, 악의적 요청, 합법적 거절이 지연으로 오인되지 않음을 보여줄 수 있다. 데이터 주체는 자격 증명이 결코 백지 수표가 되지 않는 기록 구조를 유지한다.

근거의 한계

이 글은 살아 있는 등록 데이터 정책, ICANN의 5월 12일 발표, 인풋 그룹 페이지와 참여 요청 공고, GAC 조언 현황 페이지, 인도 정부에 대한 8월 11일 ICANN 답신, SAC122, ICANN의 RDRS 작업 요약에 의존한다. 검토된 자료는 최종 활성화 날짜, 최종 신원 제공자, 페더레이션 모델, 보증 프로파일, 전환 규칙, 컴플라이언스 분모를 확정하지 않는다. 2026년 12월의 개념 실증 테스트가 제10.7조를 활성화한다고 말하지 않는다. 이 글은 활성화 이전에도 긴급 요청이 다른 합법적 절차로 처리될 수 없다고 추론하지 않는다. 제안된 활성화 접수증과 얇은 인증 설계는 Daniel Kade의 분석이다.

출처

  1. ICANN — 등록 데이터 정책
  2. ICANN — 긴급 요청 요건 발표
  3. ICANN — 법 집행 기관 인증 메커니즘 인풋 그룹
  4. ICANN — 인증 인풋 그룹 참여 요청
  5. ICANN — GAC 조언 현황
  6. ICANN — Kurt Erik Lindqvist에서 S. Krishnan에게
  7. ICANN SSAC — SAC122 요약
  8. ICANN — RDRS 작업 요약