요약

  • ICANN의 FAQ에 따르면 신청자는 통지를 받은 날로부터 21일 이내에 문자열 유사성 평가(String Similarity Evaluation) 결과에 대해 이의를 제기할 수 있으며, 2026년 신청자 안내서는 이 기간을 ICANN이 결정을 전송한 시점부터 계산한다.
  • 이의신청은 제한 없는 재평가가 아니다. 안내서는 '명백한 오류(clearly erroneous)' 기준을 적용하며, 원래 심사 패널의 결정을 수용하지 않는 예외는 절차 미준수 또는 필요한 중요한 증거·정보의 처리 실패로 한정한다.
  • 이 글이 제안하는 첫날 기록은 거버넌스 권고사항이며 ICANN이 요구하는 양식이 아니다. 그 목적은 정확한 결정 이벤트, 후보 오류 근거, 증거 출처, 기한 계산과 이후 제출을 하나의 감사 가능한 사슬로 보존하는 것이다.

논거가 완성되기 전에 시계가 먼저 돌아간다

신청자는 불리한 문자열 유사성 평가(SSE) 결과가 실제로 이의신청이 가능한 것인지 판단하는 데 며칠이 필요할 수 있다. 그러나 그 법적·기술적 판단을 기다리며 기록을 미뤄서는 안 된다.

ICANN의 공개 FAQ는 신청자가 패널이 사실 오류, 절차 오류 또는 시스템 오류를 저질렀다고 판단할 경우 평가 결과 통지를 받은 날로부터 21일 이내에 이의를 제기할 수 있다고 명시한다. 2026년 신청자 안내서 제7.10.4절은 더 운영적인 표현을 쓴다: 이의신청은 ICANN이 SSE 결정을 전송한 날로부터 21일 이내에 이루어질 수 있다는 것이다.

이 두 진술은 서로 다른 관찰 가능한 이벤트를 서술하면서 동일한 짧은 기간을 규정한다. 신중한 대응은 어느 타임스탬프가 중요한지 임의로 정하는 것이 아니라 둘 다 보존하는 것이다: ICANN이 결정을 전송한 시점과 신청자의 시스템이 통지를 수신하거나 노출한 시점. 기록에는 시간대, 메시지 식별자, 전달 경로, 그리고 해당 이벤트와 함께 도착한 원본 그대로의 결정문도 함께 보존해야 한다.

이 글은 나중 타임스탬프가 기한을 연장한다고 주장하지 않는다. 다만 기한을 보수적으로 계산하고 그 계산을 설명할 수 있을 만큼 충분한 증거를 보존할 것을 권고한다.

요약하기 전에 결정 자체를 보존하라

실무 팀은 긴 결정문을 빠르게 작업 목록, 슬라이드, 티켓 또는 이메일로 변환한다. 그것은 협업에 유용하지만, 요약물이 결코 증거상의 원본이 되어서는 안 된다.

첫날 패키지는 결정문 또는 보고서의 정확한 바이트, 파일명과 검색 경로, SHA-256 무결성 해시, 평가 대상 문자열과 변형 문자열, 결과 범주, ICANN이 표시한 날짜·시각, 그리고 분석에 사용된 신청자 안내서의 버전을 보존해야 한다. 이러한 사실들을 원본 파일을 변경하지 않고 안정적인 내부 사안 식별자에 연결해야 한다.

해싱은 결정이 올바른지, ICANN이 특정 시점에 이를 전송했는지를 증명하지 않는다. 해싱이 증명하는 것은 더 좁지만 여전히 가치 있는 사실이다: 나중에 검토한 파일이 신청자가 보존한 파일과 동일하다는 점이다. 전송 증거는 메시지, 포털 또는 전달 기록 그 자체에서 나와야 한다.

이의신청 기준이 첫 검토의 범위를 좁힌다

안내서에 따르면 이의신청은 '명백한 오류' 기준 하에서 평가된다. 평가 이의신청 서비스 제공자(Evaluation Challenge Service Provider)는 패널이 확립된 평가 절차를 따르지 않았거나 필요한 중요한 증거나 정보를 고려하지 않았거나 요청하지 않은 경우를 제외하고 원래 패널 결정을 수용해야 한다. ICANN의 FAQ 역시 사실 오류, 절차 오류, 시스템 오류를 명시한다.

이 틀은 우선순위 판단(triage)에 반영되어야 한다. 첫 내부 검토는 단순히 신청자가 결과에 불만족하는지, 더 매력적인 유사성 분석을 제시할 수 있는지를 묻는 데서 그쳐서는 안 된다. 후보 근거를 분리해야 한다:

  1. 어떤 사실적 전제가 틀렸을 가능성이 있는가?
  2. 어떤 확립된 절차가 준수되지 않았을 가능성이 있는가?
  3. 어떤 필요한 중요한 증거나 정보가 누락되었거나 요청되지 않았을 가능성이 있는가?
  4. 어떤 시스템 동작이 결정에 영향을 미쳤을 가능성이 있는가?

각 근거는 결정문 내 정확한 구절, 적용되는 규칙 또는 절차, 그리고 뒷받침하는 출처를 가리켜야 한다. 출처 없는 근거는 가설이다. 근거에 매핑되지 않은 출처는 논거가 아직 아닌 보관함이다.

여섯 개의 연결된 객체가 이의신청을 재구성 가능하게 만든다

최소한으로 유용한 기록은 여섯 개의 객체를 담는다.

첫째는전송 이벤트이다: 발신자, 수신처, 경로, 타임스탬프, 시간대, 메시지 식별자 및 포털 이벤트. 둘째는수신 통지이다: 신청자의 통제하에 있는 시스템이 이를 수신하거나 노출한 시점, 그리고 최초 접근한 사람. 셋째는권위 있는 결정문이다: 원본 그대로의 파일, 그 해시, 결과, 평가 대상 문자열, 안정적인 참조.

넷째는규칙 스냅샷이다: 안내서 버전, 관련 조항, 그리고 기한이나 근거에 관해 참조한 공식 FAQ. 다섯째는근거-증거 장부이다: 주장된 오류마다 한 행씩, 주장, 인용된 결정 구절, 적용 규칙, 뒷받침 자료, 출처, 담당자, 검토 상태를 담는다. 여섯째는기한 및 제출 기록이다: 보수적인 기한 계산, 내부 승인, 실제 제출 바이트, 제출 해시, 제출 타임스탬프, 접수 확인.

이 객체들은 서로 연결되어야 하며 하나의 편집 가능한 문서로 병합되어서는 안 된다. 원본 통지와 결정문은 분석이 그 주위에서 진화하는 동안 불변으로 유지되어야 한다.

30일 결론은 두 번째 시계이며 수신의 대체물이 아니다

안내서에 따르면 SSE 패널은 신청자가 이의를 제출한 후 30일 이내에 그 결론을 전달한다. 이는 두 번째 이벤트 사슬을 만든다. 따라서 제출 기록은 접수 확인, 예상 결론일, 절차 관련 메시지, 실제 수신한 결론의 부모가 되어야 한다.

오류가 발견되면 이의신청 결과를 반영하여 평가가 재평가된다. 사실·절차·시스템 오류가 발견되지 않으면 원래 결과가 그대로 유지된다. 어느 분기도 첫날 증거를 쓸모없게 만들지 않는다. 보존된 기록은 무엇을, 어떤 근거로 이의를 제기했는지, 그리고 나중의 결론이 동일한 근거를 다루었는지를 설명한다.

공식 자료가 확립하지 않는 것들

공식 자료는 기간, 검토 기준, 결론 시점, 조건부 결과를 확립한다. 그러나 이 글이 제안하는 기록 구조를 규정하지는 않는다. 2026년 이의신청 성공률, 번복률 또는 결과를 예측할 수 있는 완결된 신청 단위 사례를 제공하지도 않는다.

또한 해시, 스크린샷 또는 내부 승인이 이의신청을 적시적이거나 설득력 있게 만든다고 말하지 않는다. 그러한 통제는 출처와 조직 기억을 보존할 뿐이며, 적용되는 제출 규칙이나 신청자의 전문적 조언을 대체하지 않는다.

루헝(Lu Heng)의 원칙은 규범적 관점으로만 관련이 있다. 안정적 정체성, 출처, 추적 가능한 상태 전이에 대한 강조는 결정 사슬의 보존을 뒷받침한다. 그것은 ICANN이 무엇을 했는지, 규칙이 무엇을 요구하는지, 패널이 어떻게 판단할지에 대한 증거가 아니다.

거버넌스의 시험은 기록이 인사 변동을 견디는가이다

21일은 여러 사람이 사안에 손을 대기에 충분히 길고, 책임이 분산되기에 충분히 짧다. 신뢰할 수 있는 기록은 새로운 의사결정자가 기억에 의존하지 않고 다섯 가지 질문에 답할 수 있게 한다: 무엇이 도착했는가, 언제 도착했는가, 어떤 규칙이 적용되었는가, 어떤 오류가 주장되었는가, 정확히 무엇이 제출되었는가.

이것이 첫날 보존의 진정한 목적이다. 이의신청을 미리 판단하는 것이 아니다. 누락된 타임스탬프, 덮어쓴 파일, 근거 없는 기억 속으로 사라지기 전에, 정보에 기반한 출처 연결형 결정을 내릴 수 있는 선택권을 지키는 것이다.

출처