ICANN 규칙 뒤의 집행 연쇄

요약

• ICANN의 공개 기록은 미션·책임성 문서에서 커뮤니티 정책 수단, 레지스트리 및 등록 기관(registrar) 계약, 계약 이행 준수(compliance)까지 이어지는 다층적 연쇄 구조를 보여준다. 그러나 이 연쇄는 단일 규제 기관과 같은 공적 권한 부여와 동일한 것이 아니다.
• 본고에서 검토한 자료들은 관련 문서와 행정 기능을 식별하지만, 모든 계약 당사자에게 적용되는 현재 개정안 집합이나, 재고(reconsideration) 신청·독립 검토 절차(Independent Review Process) 도전·계약 분쟁 제기가 구현을 자동으로 중단시키는지는 입증하지 못한다.

권한 연쇄는 단일 위임이 아니라 스택이다

ICANN은 문서 목록이 권력 주장으로 전환되는 지점에서 가장 오해하기 쉽다. 정관(Bylaws) 페이지, 정책 색인, 레지스트리 계약, 등록 기관 계약, 컴플라이언스 페이지, 검토 메커니즘은 같은 기관 생태계에 속할 수 있지만, 동일한 역할을 수행하지는 않는다.

어떤 문서는 기관의 미션과 책임성 아키텍처를 정의한다. 다른 문서는 커뮤니티가 승인한 정책을 식별한다. 계약은 의무를 레지스트리 운영자나 등록 기관에 연결한다. 행정 기능은 불만을 접수하고, 이행을 모니터링하거나 통지를 발행할 수 있다. 검토 절차는 결정을 검증할 수 있다. 이 어느 단계도 다른 단계의 대체물로 취급되어서는 안 된다.

공개 기록은 이러한 층위적 독해를 뒷받침한다. ICANN은 미션, 책임성, 검토 아키텍처와 관련된 정관 페이지를 공개하면서 동시에 별도의 계약 및 정책 자료를 공개한다. 따라서 정관 페이지는 기관의 내부 한계와 검토 구조에 대한 중요한 출처지만, 그 자체로 레지스트리나 등록 기관 계약은 아니다.ICANN Bylaws

Internet Corporation for Assigned Names and Numbers의 디렉터리 기록은 이 조사의 대상이 글로벌 기관 주체임을 확인하는 데 유용하다. 그러나 이는 계약상 권한, 공법상 위임 또는 구제수단의 증거가 아니다. 이러한 명제에는 해당 문서와 그 실효 버전이 필요하다.

이 구분이 중요한 이유는 'authority(권한)'라는 단어가 여러 관계를 숨길 수 있기 때문이다. 기술적 조율은 공유 식별자 체계의 운영과 관련된다. 계약상 권한은 레지스트리 운영자나 등록 기관이 수락한 의무와 관련된다. 공적 권한은 별도의 근거를 요구하며, 생태계에서 조직이 중심적 위치를 차지한다는 이유만으로 추론되어서는 안 된다. 본고에서 검토한 자료들은 이 층위들이 어디서 만나는지 묻는 근거는 되지만, 이를 하나로 뭉개는 근거는 되지 않는다.

같은 원칙이 책임성에도 적용된다. 절차가 조치에 도전할 수 있는 형식적 경로를 제공하더라도, 그 경로가 구현 전에 개입할 수 있고, 이전 상태를 보존하며, 원상 회복을 강제할 수 있다는 보장은 아니다. 따라서 본고의 핵심 질문은 ICANN이 'policy', 'compliance', 'review'라는 이름의 문서를 갖고 있는지가 아니라, 그 문서들이 주장된 권한에서 운영적 결과로, 그리고 시의성 있고 사용 가능한 구제로 이어지는 추적 가능한 연쇄를 형성하는지 여부다.

정책이 어떻게 계약 당사자의 의무가 되는가

연쇄의 첫 고리는 정책 수단 그 자체다. ICANN은 합의 정책(Consensus Policy)과 관련 정책 문서의 공식 색인을 유지한다. 이 색인은 독자가 제목, 날짜, 상태 정보를 확인하는 데 도움을 줄 수 있지만, 색인 자체가 모든 계약상 구제수단이나 변경 없는 실효 문안의 증명은 아니다.ICANN Consensus Policies

다음 고리는 계약이다. ICANN은 신규 gTLD 레지스트리 계약(New gTLD Registry Agreement)과 그에 편입된 사양에 대한 공개 문서 기록을 유지한다. 이 계약 자료는 레지스트리 운영자의 의무, 정책 편입, 기술적 책무, 연속성 요건, 종료 및 전환 조항이 어떻게 연결되는지 조사할 적절한 장소다. 그러나 공개 기록이 존재한다는 사실만으로 어느 기준 양식이 모든 레지스트리에 대해 현재 유효하다는 것은 입증되지 않는다.

검색된 기록은 기본 레지스트리 계약(Base Registry Agreement) PDF가 2017년 7월 31일에 승인된 것으로 식별한다. 이는 공개된 기준 양식에 붙은 날짜다. 그것이 문안이 개정되지 않았다는 증명이고, 모든 레지스트리가 동일한 조건으로 운영된다는 증명이며, 이후의 쌍방약속과 사양에 영향이 없다는 증명은 아니다.기본 레지스트리 계약, 2017년 7월 31일 승인

ICANN은 또한 등록 기관 인증 계약(Registrar Accreditation Agreement)과 그 부속 사양에 대한 공식 페이지를 유지한다. 본고에서 검토한 기록은 해당 페이지를 2013년 9월 17일 기준으로 명시한다. 이 역시 공개된 기준 기록을 설명하는 날짜일 뿐, 모든 등록 기관에 적용되는 현재 계약, 개정안 집합 또는 부칙을 확정하지 않는다.2013 등록 기관 인증 계약

따라서 유용한 조사는 다음 다섯 고리 검증을 따라야 한다:

1. 어떤 정책이나 기관적 조치에 의존하고 있으며, 현재 출처는 그 상태에 대해 무엇이라고 말하는가?
2. 현재 어느 계약, 사양, 개정안 또는 부칙이 이를 해당 당사자에 대해 편입하거나 작동시키는가?
3. 누가 구속되며, 어떤 주체가 의무를 이행할 것으로 기대되는가?
4. 어떤 통지, 정보 요청, 이행 기회 또는 상급 절차가 의심되는 위반을 행정적 대응으로 연결하는가?
5. 어떤 구제가 가능하고, 누가 청구할 수 있으며, 도전이 계류되는 동안 그 구제는 무엇을 하는가?

이 고리들이 문서화된 경우에만, 독자는 특정 정책이 특정 계약 당사자에게 특정 운영적 효과를 가진다고 책임 있게 말할 수 있다. 정책 색인만으로는 두 번째 질문에 답할 수 없다. 기준 계약만으로는 이후 개정안이 지배하는지에 답할 수 없다. 컴플라이언스 웹페이지만으로는 다섯 번째 질문에 답할 수 없다.

이전 정책(Transfer Policy)은 이 구분이 왜 중요한지 보여주는 유용한 예다. ICANN은 등록 기관 의무와 관련된 공식 이전 정책 페이지를 공개한다. 이는 조사할 정책 수단을 식별하지만, 본고에서 검토한 증거는 그 실효 조항이나 효력 발생일을 독립적으로 검증하지 않는다. 기록은 해당 페이지가 완전한 현재 실효 문안인지, 후속 정책이나 단계적 시행이 적용되지 않는지, 모든 주장된 위반에 어떤 구제가 따르는지를 확정하지 않는다.이전 정책

따라서 인과 메커니즘은 단순히 '정책 곧 이행'이 아니다. 정책, 편입, 의무, 통지, 이행, 검토에 가깝다. 각 전환에는 고유한 출처가 필요하다. 정책이 최신이 아니면 연쇄는 잘못된 문안에서 시작될 수 있다. 계약이 적용 버전이 아니면 의무가 잘못 기술될 수 있다. 컴플라이언스 절차가 설명만 제공하면 법적 권력을 공급하지 않고 행정을 묘사할 수 있다. 검토 경로가 구현 후에 도달하면, 형식적 검토 가능성이 도전을 유발한 실무적 지위를 보존하지 못할 수 있다.

계약 컴플라이언스가 할 수 있는 것과 입증할 수 없는 것

ICANN의 공식 계약 컴플라이언스 자료는 레지스트리 계약, 등록 기관 인증 계약 및 적용 정책에 따라 불만, 모니터링, 이행을 다루는 기능으로 이를 묘사한다. 그 묘사는 행정적 접점을 식별한다. 불만이나 모니터링 사건에서 계약상 대응에 이르는 단계는 여전히 적용 절차와 계약에서 검증되어야 한다.ICANN 계약 컴플라이언스

공개 컴플라이언스 허브는 해당 기능에 대한 또 다른 공식 정보 입구를 제공한다. 허브는 절차와 링크가 바뀌면서 바뀔 수 있으며, 그 자체가 계약은 아니다.ICANN 계약 컴플라이언스 허브

이 구분은 컴플라이언스 자료가 입증할 수 있는 것에 유용한 한계를 설정한다. ICANN이 기능을 어떻게 묘사하는지, 참여자가 어디서 접촉하도록 안내되는지는 보여줄 수 있다. 그러나 적용 계약 없이는 정확한 이행 기간, 정지나 종료의 정확한 조건, 특정 레지스트리나 등록 기관의 권리, 도전 이후의 구제를 확정하지 못한다.

이 차이는 법적 형식주의 이상의 의미를 갖는다. 행정적 묘사는 여러 계약 양식과 정책 수단을 하나의 공개 설명에 압축하는 경우가 많다. 독자는 불만이 검토되고 의무가 집행된다는 것을 배우면서도, 어느 조항이 특정 단계를 승인하는지, 통지가 요구되었는지, 이행 기회가 있었는지, 계약별 전환 메커니즘이 조치를 제한하는지를 여전히 알지 못할 수 있다.

따라서 본고에서 검토한 증거는 절제된 결론을 지지한다. 계약 컴플라이언스는 관련 계약과 정책에 따라 의무를 접수, 모니터링, 집행하기 위한 행정 메커니즘으로 제시된다. 모든 불만이 같은 경로를 따르거나 모든 계약이 같은 구제를 제공한다는 더 넓은 결론은 지지하지 않는다.

여기서 기술적 조율과 계약상 권한은 분리된 상태를 유지해야 한다. 체계가 계속 운영되기 위해 기술적으로 조율된 대응이 필요할 수 있다. 그 운영적 필요 자체가 특정 결과를 부과할 계약상 권리를 확립하지는 않는다. 반대로 계약이 한 단계를 승인하더라도 그 계약이 일반적 공적 위임이 되는 것은 아니다. 기술적 요건의 출처, 계약상 의무의 출처, 공법상 주장의 출처는 각각 별도로 식별되어야 한다.

같은 경계는 연속성 주장에도 적용된다. 레지스트리 및 등록 기관 계약은 운영, 데이터, 서비스 또는 전환 조항을 포함할 수 있지만, 본고에서 검토한 기록은 모든 조항과 모든 계약 당사자에 대해 검토된 현재 문안을 제공하지 않는다. 따라서 특정 연속성 보호, 통지 기간 또는 전환 구제가 보편적으로 제공된다고 말하는 것은 오도적일 수 있다. 책임 있는 서술은 이것들이 결론에 앞서 확인해야 할 적용 문서의 부분이라는 것이다.

분리된 책임성 경로들

조사자가 도전받은 조치의 출처 대신 원하는 구제에서 출발하면, 도전은 잘못 분류될 수 있다. 첫 질문은 해당 조치가 계약에 따라, 합의 정책에 따라, 내부 이사회나 직원 결정에 따라, 또는 그 조합에 따라 이루어지는지 여부여야 한다.

계약 기반 분쟁은 당사자들의 계약이 그 단계를 승인하는지, 요구된 절차가 따라졌는지, 어떤 계약상 구제가 가능한지를 묻는다. 정책 질문은 어느 정책이 실효적이며 어떻게 편입되었는지를 묻는다. 정관 기반 책임성 질문은 어떤 행위나 태만이 기관의 검토 아키텍처에 속하는지, 청구인이 이를 발동할 자격이 있는지를 묻는다. 이 경로들은 상호작용할 수 있지만, 서로 교체 가능하지는 않다.

정관 페이지는 책임성, 재고, 독립 검토와 관련되며, 레지스트리 및 등록 기관 자료는 별도의 계약 문서 기록을 제공한다.ICANN Bylaws신규 gTLD 레지스트리 계약 문서 기록

이 분리는 어떤 예상되는 도전에 대해서도 네 가지 실무 질문을 만든다:

• 누가, 어떤 자격으로, 어느 결정자를 상대로 제기할 수 있는가?
• 포럼이 검토할 수 있는 행위나 태만은 무엇인가?
• 어떤 제출 기한, 통지 규칙 또는 절차 소진 요건이 적용되는가?
• 그 경로는 구현에 영향을 주는가, 아니면 이후 선언이나 다른 최종 결과만을 산출하는가?

검색된 증거는 관련 경로 전반에 대해 이 질문들의 현재 답을 확정하지 않는다. 독립 검토 절차에서 잠정 구제에 관한 정관 조항의 정확한 실효 문안도 확정하지 않는다. 재고 신청, 독립 검토 절차 도전 또는 계약 중재가 도전받은 운영 조치를 자동으로 정지시킨다는 것도 확정하지 않는다.

이는 정지나 잠정 메커니즘이 존재하지 않는다는 발견이 아니다. 이는 이 조사에 이용 가능한 증거에 대한 발견이다. 어떤 답이 현재 법이나 보편적 관행으로 서술되기 전에, 현재 공개 기준, 개정 이력, 규칙, 계약별 조건을 직접 검토해야 한다.

형식적 접근과 실무적 구제의 구분이 핵심이다. 개인이나 조직은 도전을 제기할 수 있으면서도, 변경 전 상태를 유지하는 메커니즘이 없을 수 있다. 검토자는 최종 선언을 발행할 수 있으면서도 이미 변화된 운영 지위를 복원할 경로가 없을 수 있다. 계약은 분쟁 절차를 포함하면서도 구현이 별도의 통지, 이행, 정지 또는 전환 조항의 영향을 받도록 둘 수 있다. 이 가능성들은 상호 교체되지 않으며, 실효 문안 없이 확정된 것으로 취급되어서는 안 된다.

누락된 정지(stay) 질문

가장 중요한 미해결 질문은 검토가 계류되는 동안 구현이 일시 중단되는지 여부다. 본고에서 검토한 기록은 자동 정지를 확립하지 않는다. 또한 재량적 잠정 보호의 정확한 기준, 결정자, 시기, 효과도 확립하지 않는다.

이 공백은 책임성의 의미를 바꾼다. 완전한 기록이 답해야 할 질문들을 보라:

형식적 검토 명칭은 이 질문들에 답할 수 없다. 공개 정관 페이지나 계약 색인의 존재도 마찬가지다. 적용되는 현재 규칙, 계약, 절차 기록을 함께 읽어야 한다.

이것이 본고의 결론이 의도적으로 한정된 이유다. 공개 자료는 정지 질문이 어디에 속하는지 보여준다. 정관이나 검토 규칙, 적용 계약, 구현 절차, 분쟁의 시기 사이의 상호작용에 속한다. 그러나 현재 모든 레지스트리, 등록 기관, 조치 유형에 대한 답을 보여주지는 않는다.

자동 중단을 추론해서는 안 되는 또 다른 이유가 있다. 서로 다른 수단은 서로 다른 목표를 추구할 수 있다. 컴플라이언스 절차는 계약 이행을 보호할 수 있다. 정책 절차는 공통 규칙을 확립할 수 있다. 검토 메커니즘은 기관의 의사결정을 검증할 수 있다. 어느 한 층에서 의미 있는 구제가 다른 층을 지배하지 않을 수 있다. 정관 기반 검토 경로를 계약 집행 단계의 정지로 자동 취급해서는 안 되고, 계약 분쟁 경로를 기관의 더 넓은 책임성에 대한 본안 검토로 자동 취급해서도 안 된다.

따라서 안전한 분석 순서는 다음과 같다. 예정된 조치를 식별하고, 이를 승인한다고 주장되는 수단을 식별하고, 이행 주체를 식별하고, 영향받는 당사자의 경로를 식별하고, 잠정 보호 요청이 있으면 식별하고, 구현 시계와 검토 시계를 비교한 뒤, 최종 구제가 여전히 무엇을 달성할 수 있는지 묻는다. 이 순서는 책임성에 관한 막연한 질문을 검증 가능한 타임라인으로 전환한다.

운영적 의존과 검토의 실무적 한계

서면상 가장 강력한 책임성 메커니즘도, 운영적 의존성이 변하기 전에 개입할 수 없다면 실무에서 약할 수 있다. 이는 ICANN의 체계가 효과적이거나 비효과적이라는 결론이 아니라 결과에 대한 검증이다.

가상으로, 어떤 계약 당사자가 D일에 통지를 받고, D+2일에 운영 변화가 예정되고, D+3일에 도전이 제기되며, 잠정 보호에 대한 결정이 D+10일에 도착한다고 하자. 형식적 검토 경로는 열려 있을 수 있다. 그러나 그 실무적 효과는 D+2일과 D+10일 사이에 무엇이 일어났는지, 결정자가 이전 상태를 복원할 수 있었는지, 그 기간 동안 누가 구현을 통제했는지에 달려 있다.

이 순서의 날짜는 예시이며, ICANN 절차나 특정 분쟁에 대한 주장이 아니다. 이는 본안 타임라인이 구현 타임라인을 대체할 수 없는 이유를 보여준다. 이전 상태를 복원할 수 있다면 이후의 유리한 결정은 강력할 수 있다. 운영 변화가 합리적 비용으로 재구성할 수 없는 기록, 관계, 서비스 배열, 협상 지위를 변경했다면 덜 유용할 수 있다.

따라서 조사는 최소한 세 가지 상태를 기록해야 한다:

1. 법적·기관적 상태: 어느 수단이 그 조치를 승인한다고 주장되는가?
2. 운영적 상태: 실제로 무엇이 변했으며, 누가 이를 이행하거나 되돌릴 수 있는가?
3. 검토 상태: 누가, 어떤 타임라인과 어떤 잠정·최종 권한으로 결정을 검토할 수 있는가?

이 삼상 모델은 흔한 오류, 즉 검토 절차를 검토 대상 체계를 자동으로 통제하는 것처럼 취급하는 오류를 막는다. 반대 오류, 즉 운영적 통제를 권원, 주권 또는 무제한 권한의 증명으로 취급하는 오류도 막는다.

공개 기록은 이 문제를 검토할 근거를 제공한다. 레지스트리 및 등록 기관 계약 자료는 계약 문서 기록을 식별한다. 합의 정책 색인은 정책 층을 식별한다. 컴플라이언스 자료는 행정적 집행 기능을 식별한다. 정관 페이지는 별도의 책임성·검토 아키텍처를 식별한다. 확립되지 않은 것은 이 층들이 현재, 사실 특정적인 구현 분쟁에서 어떻게 상호작용하는가이다.

운영적 의존은 인센티브에도 영향을 준다. 구현을 통제하는 주체는 검토를 구하는 당사자보다 더 많은 시간과 정보를 가질 수 있다. 영향받는 당사자는 최종적으로 승소하더라도 지연, 이전, 불확실성 또는 변경된 운영 지위의 비용을 부담할 수 있다. 검토자는 기반 체계를 통제하지 않으면서 법적 질문을 결정할 수 있다. 이들은 실제 기록의 증거에 대해 검증되어야 할 분석적 가능성이며, 보편적 사실로 가정되어서는 안 된다.

운영자와 법률 자문에게 이는 분쟁 파일이 각 계약과 정책의 정확한 버전, 통지 및 응답 날짜, 구현 일정, 잠정 보호 요청, 조치를 정지하거나 되돌릴 수 있는 주체의 신원을 보존해야 함을 의미한다. 기관 웹페이지로의 일반 링크로는 부족하다. 기준 계약의 날짜로는 부족하다. 검토가 존재한다는 서술로는 부족하다.

한정된 결론

공개 기록은 층위적 기관 아키텍처를 지지한다. ICANN의 식별자 조율 권한은 하나의 무차별적 위임으로 적절히 묘사될 수 없다. 이용 가능한 자료는 대신 미션·책임성 문서, 커뮤니티 정책 수단, 레지스트리 및 등록 기관 계약, 편입된 의무, 계약 컴플라이언스, 별도의 검토 경로를 포함하는 연쇄를 가리킨다.

증거는 또한 명확한 한계를 지지한다. 2017년 레지스트리 계약 자료와 2013년 등록 기관 인증 계약 페이지는 공개 기준 문서 기록을 확립하지만, 그 날짜는 모든 계약 당사자에 대한 현재 개정안 집합을 확립하지 않는다. 합의 정책 색인은 정책 수단을 찾는 데 도움이 되지만, 모든 계약상 구제를 독립적으로 입증하지는 않는다. 컴플라이언스 자료는 행정 기능을 묘사하지만, 적용 계약을 대체하지 않는다. 정관 페이지는 책임성과 검토와 관련되지만, 본고에서 검토한 증거는 잠정 구제나 구현의 자동 정지를 지배하는 정확한 현재 규칙을 확립하지 않는다.

따라서 미해결 질문은 ICANN이 검토 메커니즘을 갖고 있는지 여부가 아니다. 특정 영향받는 당사자가 특정 운영 조치가 검토 대상 지위를 바꾸기 전에 사용 가능한 보호를 얻을 수 있는지 여부다. 여기에는 출처-조치 연쇄, 버전 관리된 문서 기록, 구현과 검토를 비교하는 타임라인이 필요하다.

이 요소들이 직접 검증되기 전까지, 책임 있는 결론은 책임성이 허구라는 것도 아니고, 형식적 검토가 연속성을 보장한다는 것도 아니다. 공개 기록은 수단과 통제 표면을 식별한다. 구제의 실무적 강도는 현재 문안, 도전받은 조치, 보호가 이용 가능해지는 시점에 의존하도록 남겨둔다.