요약

  • AFRINIC의 2026년 9월 25일 DRAFT02는 자동화 점검이 가능한 비준수 징후를 제안할 수 있다고 명시하며, RSA 또는 정관에 따른 추가 조사나 조치에 앞서 직원이 정보를 검증해야 한다고 규정한다.
  • DRAFT01과 비교하면 개정문은 자동화 결과의 의미를 바꾼다. 테스트 출력은 이제 준수 판정이 아니라 검토용 단서로 기술된다.
  • 버전화된 정책–테스트 매핑은 각 경보를 만든 규칙, 시행일, 데이터 출처, 회원·자원 범위, 테스트 버전—그리고 그 결과가 입증할 수 없는 것—을 보여줄 것이다.
  • 이 제안은 여전히 논의 중(Under Discussion)이다. 공개 기록에는 가동 중인 대시보드, 회원 통지, 준수 판정, 제재가 나타나지 않는다.

대시보드는 필드를 관찰할 수 있다. 스스로 규칙을 선택할 수는 없다.

자원 보유자가 레지스트리 레코드가 기대 조건과 일치하지 않는다는 경보를 받았다고 상상해 보자. 소프트웨어가 연락처 필드를 읽거나 경로 객체를 비교하거나 자원 레코드를 규칙과 대조했을 수 있다. 그 비교는 반복 가능할 수 있다. 하지만 그것만으로 이 회원에게 올바른 정책이 적용되는지, 출처 레코드가 최신인지, 회원이 의무를 위반했는지는 입증되지 않는다.

바로 이 차이가 AFRINIC의 개정된 정책 준수 대시보드 제안,AFPUB-2026-GEN-002-DRAFT02의 중심에 놓여 있다. 9월 25일에 제출된 버전은 자동화가 가능한 한 객관적으로 측정할 수 있는 조건에 집중하고 가능한 비준수 징후를 제안해야 한다고 규정한다. 또한 대시보드가 결과의 최종 판정자가 아니며, 자동화 테스트로 얻은 정보를 직원이 검증해야 한다고 명시한다. 증거가 비준수를 시사하는 경우에만 문안은 RSA 또는 정관에 따른 보다 철저한 조사와 가능한 추가 조치를 기술한다.

이 조항들은 가동 중인 제품을 기술하지 않는다. 현재 제안 색인은 여전히 DRAFT02를 논의 중으로 표시한다. 이 글은 초안에 담긴 설계 경계와, AFRINIC이 나중에 이를 구축한다면 필요한 증거에 관한 것이다.

DRAFT02는 자동화 결과가 허용되는 의미를 바꾼다

보관된 DRAFT01은 더 단정적인 언어를 사용했다. 비준수가 감지되면 통지할 것을 요구했고, 별도로 상기 통지, 지속적 비준수에 대한 직원 정의 기간, 직원 절차, 그리고 서비스 보류·자원 회수·회원 종료에 관해 이후 정해질 규칙을 기술했다. 또한 일부 핵심 인프라 또는 예외적 사례에 대한 이사회 예외를 제안했다.

DRAFT02는 단지 시한을 줄인 같은 문안이 아니다. 지속 기간과 제재 규칙을 미래의 직원 절차에 할당하던 독립 조항을 제거했다. 그 자리에 두 가지 한정을 명시했다. 즉 준수는 완전한 객관성으로 측정될 수 없으며, 자동화 점검은 가능한 징후만 제시할 수 있다. 직원 검증이 이제 제안된 정책 문안 자체에 등장한다. 초안은 여전히 서비스 보류, 회수, 종료를 포함한 RSA·정관에 따른 추가 조치를 언급하며, 개정은 그 가능성을 지우지 않았다.

이는 소프트웨어에 부여된 역할에서 의미 있는 변화다. 구 문안은 비준수라 불리는 기계 감지 상태에서 시작했다. 새 문안은 틀리거나 불완전하거나 범위 밖일 수 있는 지표에서 시작한다. 직원 검토가 그 둘 사이의 다리다. 그 다리가 신뢰할 수 있는지는 검토자가 무엇을 볼 수 있고 회원이 무엇을 재현할 수 있는지에 달려 있다.

정책 버전은 테스트 결과 옆에 놓여야 한다

제안에 따르면 대시보드의 자동화는 통합 정책 매뉴얼이 바뀜에 따라 진화해야 한다. 이는 사소한 유지보수 사안이 아니다. 어제의 규칙을 정확히 반영하던 테스트는 정책 변경 후 자원을 오분류하거나, 시행일 이전에 새 기준을 적용할 수 있다. 규칙 버전 없는 녹색 또는 적색 상태는 그 구분을 숨긴다.

보관된 DRAFT01의 직원 영향 평가는 연락처 정확성, 어뷰즈 연락처 유효성, 경로 객체 일관성, 관련 시의 RPKI 커버리지, 역방향 DNS 요건 같은 예를 나열했다. 이는 선행 문서 평가에서 온 예시일 뿐, 최종 DRAFT02 테스트 목록도 아니고 해당 점검이 배치되었다는 증거도 아니다. 이들은 '자동화된' 것이 '자명한' 것을 의미하지 않는 이유를 보여준다. 누락된 연락처 필드는 직접 관찰할 수 있다. 그러나 적용 정책상 이 자원에 그 필드가 요구되는지는 별개의 질문이다. 경로 또는 RPKI 비교 역시 확인된 출처, 관측 시점, 범위를 필요로 한다.

따라서 유용한 점검에는 연결된 두 기록이 필요하다. 첫째는 규칙 맵이다. 정책 식별자, 버전, 시행일, 영향받는 자원 클래스, 적용 조건. 둘째는 테스트 영수증이다. 데이터 출처, 수집 시점, 변환 과정, 테스트 버전, 결과, 알려진 한계. 직원은 영수증을 출처까지 추적해 규칙이 적용되는 이유—또는 경보가 해제되어야 하는 이유—를 말할 수 있어야 한다. 회원은 타인의 비공개 운영 데이터를 받지 않으면서 같은 근거를 볼 수 있어야 한다.

이는 권고이며, AFRINIC이 발표한 기능이 아니다. DRAFT02는 완전한 테스트 목록, 버전화 방법, 정확도 측정, 직원 처리 기록을 명시하지 않는다. 가능한 신호와 검증된 정보 사이의 제안 자체의 구분 때문에 이 누락은 중요한 결과를 낳는다. 입력과 적용 규칙이 보이지 않으면 검토자가 결과를 의미 있게 검증할 수 없다.

데이터에서 조치로 가는 경로는 별개의 단계들로 이루어진다

방어 가능한 사슬에는 최소 네 상태가 있다. 기록된 네트워크 또는 레지스트리 상태, 가능한 신호를 제기하는 자동화 비교, 출처와 적용 규칙을 검증하는 직원 확인, 그리고 별도로 RSA 또는 정관에 따라 승인된 조치. 이들은 서로 다른 주장이다. 대시보드 라벨이 첫째를 네째로 조용히 바꿔서는 안 된다.

이 분리는 양쪽을 보호한다. 회원은 부정확한 레코드를 바로잡거나 규칙이 적용되지 않는 이유를 설명할 수 있다. 직원은 데이터 품질 문제를 정책 문제와 구분할 수 있다. AFRINIC은 이후 조사를 뒷받침하는 증거가 무엇인지 설명할 수 있다. 점검이 틀렸다면 설명되지 않은 준수 상태가 회원 기록에 남지 않도록 경보를 정정할 수 있다.

경제적 경로는 미래지향적이지만 단순하다. 제안 자체가 RSA에 따라 향후 요청, 서비스, 회원 자격이 영향을 받을 수 있다고 말한다. 잘못된 상태는 운영자의 시간을 소모하거나 이후 검토에 영향을 줄 수 있고, 정확한 경고는 회원이 문제가 커지기 전에 바로잡도록 돕는다. 공개 출처는 오늘날 어느 쪽 결과도 보여주지 않는다. 이들은 설계 질문을 뒷받침한다. 유용한 경고와 낡거나 잘못 적용된 테스트를 어떻게 구분할 수 있을까?

버전 이력은 판정이 아니라 경계를 정한다

AFRINIC-37은 6월 24일 DRAFT01을 검토했다. 회의록에 따르면 공동의장들이 대략적 합의가 없다고 판단해 그 버전을 메일링 리스트로 돌려보냈고, 8월 공지가 같은 결과를 기록한다. DRAFT02는 9월 25일에 이어졌으며, 자체 개정 이력은 RPD 토론과 영향 평가를 반영했다고 밝힌다. 이전 회의 결과는 DRAFT01에 속하며, 현재 버전에 대한 결정이 아니다.

이 개정은 자동화가 결정해야 하는 범위를 좁히고 인적 검증을 추가한다. 더 강한 증거 경계이지만, 가동 중 입증된 안전장치는 아니다. 다음 정책 단계는 테스트 목록을 구현하는 정책과 함께 검토 가능하게 만들어야 한다. 버전, 시행일, 범위, 출처, 테스트 논리, 결과 한계, 직원 검증 기록이 그것이다. 그렇게 되면 회원과 운영자가 경보를 단서 이상으로 다루기 전에 그 메커니즘을 점검할 수 있다.

출처와 범위.AFRINIC의DRAFT02 제안과현재 제안 색인은 현재 문안과 상태를 확정한다.보관된 DRAFT01과 그 영향 평가는 선행 문안과 예시적 점검을 제공한다.AFRINIC-37 회의록과8월 12일 공동의장 공지는 DRAFT01이 메일링 리스트로 돌려진 것을 문서화한다. 어느 것도 배치 또는 회원 단위 결과를 확정하지 않는다.