요약

  • ICANN의 권한은 정관, 계약, 조율된 운영 절차에 걸쳐 분산되어 있으며, 일반적인 정부 관할권과 동격이 아니다.
  • 가장 중요한 책임성 질문은 특정 이의 대상 조치를 정의된 문서, 책임 있는 의사결정자, 그리고 결과를 바꿀 만한 도달력을 지닌 구제 수단에 연결할 수 있는가 하는 것이다.

슬로건보다 문서 사슬이 중요하다

ICANN에 대한 설명은 종종 조율, 계약적 영향력, 공적 권위를 하나의 주장으로 묶어버린다. 가용한 문서들은 그런 지름길을 뒷받침하지 않는다. ICANN의정관은 ICANN의 사명, 권한, 구조, 책임성 체계를 정의한다. 정관은 제도적 출발점이지만, 그것만으로 모든 하위 운영자를 ICANN의 하급 조직으로 만들지는 않는다.

운영 사슬은 더 세분화되어 있다.IANA 네이밍 기능 협약은 네이밍 기능에 대한 책임을 배정하고 성과, 보고, 책임성 요건을 부착한다.루트 존 관리 절차는 ICANN, IANA 기능 운영자, 루트 존 변경을 승인하는 주체가 관여하는 조율된 역할을 기술한다. 따라서 정책 결정과 루트 존 변경은 ICANN이 단독으로 내리는 명령이 아니라 여러 행위자가 관여하는 절차로 연결된다.

같은 구분이 상업 계층에서도 나타난다.레지스트리 계약은 일반 최상위 도메인 운영자에게 의무를 부과한다.등록관 인가 협약은 인가된 등록관에 요건을 설정하고 그 운영을 합의 정책, 컴플라이언스 의무, 집행 메커니즘에 연결한다. ICANN이 이들 기업에 갖는 영향력은 주로 계약적이다. 인가는 정의된 생태계에 대한 접근을 만들어내고, 위반 시 해당 협약에 명시된 통지, 이행 기간, 정지, 계약 해지 또는 기타 구제를 발동할 수 있다.

그 영향력은 주권적이지 않으면서도 중대한 결과를 낳을 수 있다. 레지스트리는 자신의 계약에 따라 자신의 레지스트리 운영을 통제한다. 등록관은 고객 대면 등록 서비스를 수행한다. 루트 서버 운영자와 기타 기술 참여자는 각자의 운영 책임을 진다. 정부는 자국 관할권 내에서 법을 시행할 수 있다. ICANN의 문서화된 역할은 이들 행위자를 연결하는 협약과 정책을 조율·관리하는 것이며, 각 행위자의 법적·기술적 권한을 대체하는 것이 아니다.

운영 통제가 실제로 나타나는 지점

ICANN의 통제 표면을 평가하는 가장 유용한 방법은 한 변경을 결정부터 이행까지 추적하는 것이다.

첫 단계에서 정관과 정책 절차는 ICANN이 무엇을 결정할 수 있고 그 결정을 어떻게 조직해야 하는지 정의한다. 둘째 단계에서 협약 또는 위임된 책임은 해당 기능을 수행할 운영자를 특정한다. 셋째 단계에서 운영 절차는 변경이 효력을 발생하기 전에 어떤 기록, 승인 또는 확인이 필요한지 정한다. 그 결과는 사용자에게 위임 변경, 레지스트리 관행 변화 또는 등록관 컴플라이언스 조치로 보일 수 있지만, 인과 사슬은 분산되어 있다.

루트 존은 이것이 왜 중요한지 보여주는 명확한 사례다.루트 존 관리에 대한 공개 설명은 루트를 편집할 수 있는 무제한적 ICANN 권한이 아니라 조율된 역할을 확인해 준다. 그 기관은 정책·계약 경로에서 중심적일 수 있지만, 특정 변경을 승인하거나 실행하는 주체는 다른 실체일 수 있다. 중심 조율자의 존재를 단독 통제의 증거로 다루면 책임 분할이 만들어낸 안전장치—그리고 실패 지점—가 지워진다.

네이밍 기능 협약은 또 하나의 계층을 더한다. 그것은 제도적 역할을 명시된 산출물, 보고 기대, 성과 의무로 번역한다. 성과를 합의된 기준에 대비해 측정할 수 있으므로 이는 통제 메커니즘이다. 동시에 그것은 제한이기도 하다. 협약은 인터넷 식별자 전반에 대한 무제한적 위임이 아니라 해당 기능과 그 의무를 정의한다.

레지스트리·등록관 계약은 다른 형태의 통제를 만든다. 이들은 계속적 참여를 정의된 조건의 준수에 조건부로 만든다.레지스트리 계약 자료는 기술 운영, 보고, 데이터 에스크로, 합의 정책, 분쟁 관련 의무, 위반 구제를 포괄할 수 있는 의무를 기술한다.등록관 협약도 마찬가지로 인가된 등록관을 컴플라이언스·집행 프레임워크 안에 두었다. 따라서 통제 표면은 한 주체가 인가 또는 계약적 지위에 의존하는 곳에서 가장 강하고, 그 계약 사슬 밖에 있는 행위자에 대해서는 약하다.

이 구분은 ICANN의 결정이 주변의 모든 분쟁을 해소하지 않으면서도 실질적 효과를 가질 수 있는 이유도 설명한다. 정책 또는 컴플라이언스 조치는 계약 운영자가 무엇을 해야 하는지 정할 수 있다. 그러나 정부, 법원, 독립 기술 운영자가 모든 목적에서 같은 결론을 받아들여야 하는지까지 정하지는 않는다. 이행 메커니즘과 법적 구제는 서로 다른 기관에 속할 수 있다.

구제 수단은 그 범위만큼만 강하다

ICANN의 책임성 프레임워크는 여러 경로를 제공하지만, 이는 보편적 항소 체계로 기능하지 않는다.책임성 메커니즘 개요는 재고려(reconsideration), 옴부즈먼 절차, 독립 검토 절차(IRP), 커뮤니티 권한을 이용 가능한 메커니즘으로 제시한다. 각 메커니즘은 고유한 자격 요건, 대상 사안, 구제 또는 권고 형태를 지닌다.

독립 검토 절차는 이 경계를 가장 명확하게 보여준다. 자격을 갖춘 청구인은 특정 ICANN 이사회의 작위 또는 부작위가 정관 또는 정관 부칙(Bylaws)과 일치하지 않음을 주장하여 이의를 제기할 수 있다. IRP 패널은 그 일치 여부를 평가한다. 이는 ICANN의 책임성 구조 안에 외부 검토 기능을 만들어내므로 중요하다. 그러나 이는 모든 운영 선택에 대한 일반 항소가 아니며, 법원이나 규제 기관을 자동으로 대체하지도 않는다.

따라서 구제 수단 질문은 세 부분으로 나누어 물어야 한다. 첫째, 청구인이 해당 메커니즘에서 적격성 또는 소송적격을 갖는가? 둘째, 이의 대상 행위가 그 메커니즘의 범위 안에 드는가? 셋째, 그 결과 결정이 실질적 교정을 만들어낼 수 있는가, 아니면 절차적·제도적 결함만 확인하는가?

형식적 경로가 존재하면서도 이행의 불확실성이 남을 수 있다. 분쟁 중인 조치가 이미 레지스트리 절차를 바꾸었거나, 계약적 지위를 변경했거나, 시간에 민감한 운영 기록에 영향을 주었다면, 이후의 판정이 이전 상태를 자동으로 회복하지 못할 수 있다. 구제의 가치는 시기, 그것을 이행할 의사결정자의 권한, 검토 기구와 원래 조치를 수행한 운영자 사이의 관계에 달려 있다.

그래서 "책임성"이라는 언어에는 구체적 대상이 필요하다. 책임성은 결정 기록의 재고려일 수 있고, 지배 문서와의 일치 여부에 대한 IRP 판정일 수 있고, 옴부즈먼 개입일 수 있고, 커뮤니티 권한이거나 계약상 이행 절차일 수 있다. 이 메커니즘들은 행위를 제약할 수 있지만, 모두가 운영 결과를 되돌릴 동일한 능력을 지니지는 않는다.

권한에서 구제로 이어지는 사슬

유용한 검증 사례는 다음 사슬을 통과하는 모든 쟁송 조치다:

  1. 제도적 규칙에 따라 정책 또는 이사회 결정이 이루어진다.
  2. 계약 또는 위임된 기능이 이행 책임 주체를 특정한다.
  3. 운영 기록이 변경되거나 보존된다.
  4. 영향을 받은 참여자가 검토, 컴플라이언스 또는 법적 메커니즘을 발동한다.
  5. 검토 기구가 결정, 권고 또는 구제를 발행한다.
  6. 책임 운영자가 그 결과가 라이브 시스템을 어떻게 바꾸는지 결정한다.

각 고리는 서로 다른 질문을 던진다. 첫째는 정관상 권한의 문제다. 둘째는 계약적 배분의 문제다. 셋째는 기술적·행정적 실행의 문제다. 넷째는 구제 접근의 문제다. 다섯째는 검토 범위의 문제다. 여섯째는 구제가 통제가 행사된 지점까지 도달하는가의 문제다.

이 사슬은 제도적 정당성을 기술하는 규율된 방법도 제공한다. 결정은 절차적으로 승인되었으면서 실질에 대해 다투어질 수 있다. 계약은 당사자 사이에서 집행 가능하면서도 공법적 질문을 해소하기에 불충분할 수 있다. 운영 변경은 기술적으로 완료되면서도 사법 심사에 계속 열려 있을 수 있다. 이 명제들은 서로를 무효화하지 않는다.

기존의 공개 논의는 흔히 표면적 질문—ICANN이 권한을 갖는가—에 집중하지만, 더 중대한 질문은 권한이 어떻게 이동하는가이다. 지배 문서가 불명확하면 결정은 제도 수준에서 취약할 수 있다. 계약은 명확하지만 운영자의 이행이 다투어진다면, 구제는 정책 검토가 아니라 컴플라이언스나 소송에 있을 수 있다. 검토 메커니즘이 좁은 절차적 문턱을 넘은 뒤에만 이용 가능하다면, 책임성의 형식적 존재가 되돌릴 수 없는 운영 효과를 막지 못할 수 있다.

문서가 확립하는 것과 하지 않는 것

근거 기록은 몇 가지 한정된 결론을 뒷받침한다.

첫째, ICANN은 사명, 권한, 거버넌스, 검토 절차를 정의하는 문서화된 제도적 프레임워크를 갖는다. 둘째, 그 네이밍 역할은 협약과 조율된 루트 존 절차를 통해 운영화되어 있다. 셋째, 레지스트리·등록관 관계는 컴플라이언스 및 위반 구제가 뒷받침하는 계약적 영향력을 만든다. 넷째, 책임성 체계는 정관과 정관 부칙에 대비해 특정 이사회 작위 또는 부작위를 검토하는 IRP를 포함한 여러 검토 채널을 담고 있다.

같은 기록은 ICANN이 정부이거나, 모든 레지스트리·등록관에 직접 명령할 수 있거나, 모든 책임성 절차가 모든 운영 결정을 되돌릴 수 있음을 입증하지 않는다. 또한 메커니즘에 대한 공개 설명이 현재 유효한 협약, 규칙 세트 또는 법원 명령 아래에서 특정 분쟁이 어떻게 해결될지를 증명하지 않는다. 각 문서의 적용 버전이 중요하다.

이 한계는 분석의 약점이 아니다. 그것은 다음 단계에 필요한 근거를 특정한다. 분쟁 조치를 지배하는 유효 문서, 결정 기록, 이행 로그, 청구인의 적격성, 그리고 요구된 정확한 구제. 이 자료들이 없으면 "ICANN 통제"는 입증된 인과 사슬이 아니라 광범위한 라벨로 남는다.

정당성에 대한 실용적 검증

네트워크 운영자, 레지스트리, 등록관, 정부에 대해 실용적 검증은 ICANN이 일관된 거버넌스 모델을 설명할 수 있는가가 아니다. 영향을 받은 주체가 권한에서 결과로 이어지는 경로를 재구성하고, 그 결과를 되돌리기 어렵게 되기 전에 관련 고리에 이의를 제기할 수 있는가 하는 것이다.

이 검증은 구체성에 보상한다. 문서를 특정하라. 행위자를 밝혀라. 조치를 명시하라. 운영 효과의 위치를 파악하라. 그다음 이를 검토할 수 있는 포럼과 그 포럼이 실제로 전달할 수 있는 구제를 특정하라.

ICANN의 정당성은 이 다섯 요소가 공개 기록에서 가시적이고 구제가 통제 지점과 일치할 때 가장 강하다. 제도적 결정은 명확하지만 이행 책임이 불투명하거나, 검토 경로는 존재하되 라이브 기록에 영향을 줄 현실적 방법이 없을 때 약하다. 따라서 이 조직의 권한은 순수하게 자발적이지도, 공적 관할과 동등하지도 않다. 그것은 그 계층들이 압박 아래에서도 추적 가능하게 유지되는지에 따라 정당성이 결정되는 층위적 배열이다.