하나의 포털, 완성되지 않은 네 개의 시계

요약

• AFRINIC의 2026년 6월 회의 기록은 AS0 ROA 전면 시행, 기술적 이전 시스템, 어뷰즈 연락처 업데이트를 MyAFRINIC v2에 의존하거나 그 이후에 우선 처리되는 경로에 두었고, 별도의 사무국 평가는 아직 최종 의견 수렴(Last Call) 단계에 있는 계층형 AS-SET 제안에 대해서도 같은 사실을 기록했습니다.
• 이들은 하나의 기능이 네 번 나타난 것이 아닙니다. 서로 다른 정책 상태에서 출발하며, RPKI, RIR 간 절차, 내부 검증, WHOIS 및 IRR에 걸쳐 있고, 서로 다른 사용자, 테스트, 통지, 정정 경로를 요구합니다.
• 따라서 포털이 가동 중이라는 사실은 정책이 활성화되었다는 증거도, 작성된 대로 작동한다는 증거는 더더욱 아닙니다. AFRINIC에는 릴리스 기준선, 부분 상태와 전면 상태, 테스트 결과, 활성화와 출시 후 근거를 구분하는 정책별 의존성·수용 대장이 필요합니다.
• 공유 인프라는 일관되지 않은 레거시 워크플로를 정리하고 중복 엔지니어링을 피하는 신중한 방법이 될 수 있습니다. 그 위험은 공통 코드 자체가 아니라 공통 언어입니다. 진전을 담은 구분 없는 한 문장은 어떤 정책의 시계가 실제로 멈췄는지 가릴 수 있습니다.

AFRINIC의 현재 정책 파이프라인 중심에는 하나의 소프트웨어 이정표가 있습니다. 한쪽에는 회원 포털을 전면적으로 재구축한 MyAFRINIC v2가 있고, 다른 쪽에는 서로 다른 네 개의 시계가 있습니다. 하나는 미할당·미지정 주소 공간에 대한 AS0 경로 출처 인증(ROA)이 내부 테스트와 부분 상태에서 전면 시행으로 이동했는지를 측정합니다.

또 하나는 비준된 이전 정책이 적격 이전을 처리하는 데 필요한 레지스트리 간 절차와 기술적 경로를 모두 확보했는지를 측정합니다. 셋째는 비준된 어뷰즈 연락처 규칙이 실제로 작동하는 검증·통지·정정 절차가 되었는지를 측정합니다. 넷째는 아직 비준에 도달하지 않았습니다. 신규 생성 AS-SET에 계층형 이름을 요구하는 최종 의견 수렴(Last Call) 제안입니다.

네 시계는 의존 관계를 공유합니다. 그러나 법적 상태, 시스템 경계, 완료의 정의는 공유하지 않습니다.

이 구분은 프로그램 업데이트에서 쉽게 사라집니다. 포털에는 알아볼 수 있는 공개 이벤트가 있습니다. 출시하거나, 베타에 들어가거나, 특정 사용자층에 개방하는 것입니다. 정책 구현은 그만큼 단일하지 않습니다.

규칙의 비준, 적용 버전을 해석할 소프트웨어, 데이터 준비, 권한 제한, 사무국 절차 매핑, 영향받는 사용자의 경로 테스트, 시작 시점 공표, 원래 이벤트를 지우지 않고의 오류 정정이 필요할 수 있습니다. 이 상태들이출시라는 단어 하나로 압축되면, 플랫폼 이정표는 그것이 입증하지 못하는 네 개의 정책 성과의 의미를 떠안을 수 있습니다.

공식 기록은 이런 일이 실제로 일어났다고 확립하지 않습니다. 더 좁고 더 유용한 사실을 확립합니다. AFRINIC이 구현 의존성의 집중을 공개적으로 기술했다는 것입니다. 이 집중은 누군가 기한 누락, 결함 있는 기능, 피해를 입은 회원을 주장해야 하기 전에 감사할 수 있습니다.

공유된 이정표

AFRINIC-37 회의록(2026년 6월 24일 개최)에 따르면 MyAFRINIC v2 작업은 2020년에 시작해 수년간 예산 등 자원 제약에 부딪혔고 이후 재개되었습니다. 포털은 그 시점에 2026년 말까지 가동될 것으로 기대되었습니다. 회의록은 또한 범위 확산을 막기 위해 범위를 제한할 필요를 기록하고 있습니다.

이 진술은 양방향으로 정확해야 합니다. 범위 통제는 실패의 증거가 아닙니다. 중요한 회원 포털을 재구축하는 제품 팀이 커지는 요구 목록으로부터 릴리스를 보호할 이유는 충분히 있습니다. 대표 사용자가 테스트하지 못한 명목상 포괄적 릴리스보다 작지만 일관된 릴리스가 더 안전할 수 있습니다. 동시에 회의록은 어떤 기능이 보호된 범위 안에 있고 밖에 있었는지 밝히지 않습니다.

네 개의 정책 경로 중 하나라도 잘렸다고 추론하는 것은 잘못입니다.

AFRINIC의AfPIF 2026 페이지는 또 하나의 상태 표지를 제공합니다. 이 페이지는 MyAFRINIC v2를 전면 재구축이라 부르고, AFRINIC이 사용자 수용 테스트(UAT)와 라이브 베타에 앞서 피드백을 수집 중이었다고 밝힙니다. 이 프로그램에 회원 담당자를 초청했고 실제 워크플로에 대한 짧은 인터뷰를 요청했습니다. 이 페이지는 준비와 모집의 증거입니다.

UAT가 끝났거나, 베타가 시작되거나 끝났거나, 운영 포털이 개방되었다는 증거는 아닙니다. 그 이후 상태는 더 나은 기록이 필요로 합니다.

또한 출처가 허용하는 것 이상을 한 날짜에 지워서는 안 됩니다. AS-SET 제안의 사무국 평가는 자원이 MyAFRINIC v2에 배분되었으며 이 포털이 2026년 11월 15일까지 가동될 것으로 기대되었다고 말합니다. 회의록은 더 포괄적인 연말 기대를 사용합니다.

두 표현은 같은 프로그램을 서로 다른 수준의 구체성으로 기술한 것일 수 있지만, 의존하는 모든 정책이 11월 15일에 구현될 것이라는 보편적 약속은 아닙니다. 정확한 날짜는 AS-SET 평가에, 포괄적 날짜는 6월 상황 보고에 속합니다. 어느 쪽도 현재 완료를 입증하지 않습니다.

하나의 백로그가 아니라 네 개의 경로

현재 정책 대장은 AS0 정책AFPUB-2019-GEN-006-DRAFT03을 비준되었고구현 대기(Awaiting Implementation)상태로 식별합니다. AFRINIC-37 회의록은 더 세분화된 단면을 제공합니다. 진화된 KRILL 소프트웨어를 사용한 내부 테스트가 진행 중이었고, 그 달 말까지 베타가 예상되며부분 구현(partly implemented)으로 공표될 예정이었습니다. 정책 문서에 적힌 대로의 전면 구현은 MyAFRINIC v2에 의존했습니다.

그만큼 이미 최소 네 개의 상태가 있습니다. 비준, 내부 테스트, 부분 구현, 문서대로의 전면 구현. 이 구분은 AS0가 단순히 포털의 한 페이지가 아니기 때문에 가치가 있습니다. 이 정책은 AFRINIC이 할당하거나 지정하지 않은 주소 공간에 대한 RPKI ROA를 다룹니다. 부분 상태는 대상 항목, 공표 범위, 예외 처리, 통합 또는 정정 동작에서 전면 상태와 다를 수 있습니다.

확인된 출처는 그 경계를 충분히 상세하게 정의하지 않습니다. 그러나 그 경계를 이분법적 라벨로 대체하지 말라고 경고합니다.

번호 자원 이전 정책AFPUB-2020-GEN-006-DRAFT03은 다른 경로를 따릅니다. AFRINIC의비준 정책 개요는 비준을 2026년 2월 4일로 기록합니다. AFRINIC-37 회의록은 이 정책이 RIR 내부 이전과 RIR 간 이전을 모두 포괄한다고 밝히고, 4월 기준 다른 네 개 RIR과의 상호주의가 확인되었다고 보고합니다. 구현이 진행 중이었고, 회원 서비스 팀이 상대 기관과 절차를 매핑하고 있었습니다.

기술 시스템 구현은 MyAFRINIC v2 이후에 우선 처리될 예정이었습니다.

여기서 소프트웨어는 의존성 중 하나일 뿐입니다. 이전 경로는 두 개의 행정 체계, 적격성 규칙, 증거 교환, 상태 메시지, 레지스트리 업데이트를 연결합니다. 인터페이스가 존재하더라도 특정 경로는 절차적으로 이용 불가할 수 있습니다. 반대로 회원 대면 도구가 준비되기 전에 사무국이 합의된 수동 절차를 가질 수도 있습니다. 수용 질문은 이전 화면이 나타나는지 여부가 아닙니다.

각 적격 경로가 유효한 요청에서 상대 기관 조율을 거쳐 귀속 가능한 레지스트리 결과로 이동할 수 있는지, 중단·거부·정정·재개의 가시적 방법이 있는지입니다.

어뷰즈 연락처 정책 업데이트AFPUB-2018-GEN-001-DRAFT07도 2026년 2월 4일 비준으로 기록되어 있습니다. 6월 회의록은 내부 시스템에 대한 기술 구현이 MyAFRINIC v2 배포 완료 후에 우선 처리되도록 예정되어 있다고 말합니다. 이 경로는 또 다릅니다. 작동하는 어뷰즈 연락처 정책에는 필드 하나 이상이 필요합니다.

테스트할 레코드의 정의, 검증 이벤트, 전달과 응답 상태, 영향받는 당사자에 대한 통지, 정정 경로, 결과에 대한 규율 있는 기술이 필요합니다. 본 글은 그 결과가 무엇이어야 하는지 다시 다루지 않습니다. 비준된 버전 — 이전 초안이나 비공식 근사가 아니라 — 이 구현된 워크플로를 지배한다는 것이 무엇으로 입증되는지를 묻습니다.

마지막으로AFPUB-2026-ASN-001-DRAFT02가 있습니다. 정책 대장은 이 제안을 최종 의견 수렴(Last Call) 단계로 표기합니다.제안서와 사무국 평가에 따르면 새로운 비계층형 AS-SET 생성을 막기 위해 WHOIS 접점과 MyAFRINIC IRR 인터페이스에 변경이 필요합니다. 기존 AS-SET은 이름이 바뀌지 않습니다. 구현 계획은 이 작업이 MyAFRINIC v2 종료 후에 우선 처리될 수 있다고 말합니다.

이 경로는 채택된 규칙의 구현으로 보고될 수 없습니다. 확인된 기록은 비준을 보여주지 않기 때문입니다. 비준 전 소프트웨어 준비는 합리적일 수 있습니다. 영향 평가는 제안이 논의되는 동안 실현 가능성, 영향받는 시스템, 비용을 식별해야 합니다. 그러나 준비 계획과 정책 권위는 다릅니다.

제안이 나중에 비준되면 첫 수용 테스트는 배포된 동작을 적용 문서와 효력 발생 시점에 묶어야 합니다. 비준 전 적절한 공개 상태는 정책 활성화가 아니라 제안 평가입니다.

릴리스 결합이 증거 부담을 바꾸는 이유

공통 인프라는 결함이 아닙니다. 일관되지 않은 레거시 시스템에 대한 올바른 답일 수 있습니다. 한 정책이 회원의 자원 레코드, 권한, 레지스트리 항목, 내부 워크플로에 걸쳐 있다면, 하나의 일관된 플랫폼을 구축하는 것이 또 하나의 고립된 패치를 추가하는 것보다 안전할 수 있습니다. 공유 식별, 공통 감사 이벤트, 일관된 통지는 상충하는 상태를 줄일 수 있습니다. 같은 릴리스가 이전과 새 동작을 구분하는 규율 있는 지점이 되기도 합니다.

그러나 공통 인프라는 공통 일정 경계를 만듭니다. 식별, 권한, 데이터 이행, 기반 워크플로의 지연은 여러 정책 기능을 뒤로 미룰 수 있습니다. 릴리스 범위를 좁히는 결정은 한 경로를 이후 증분으로 밀어넣을 수 있습니다. 공유 계층의 결함은 정책적 목적이 무관한 기능에 영향을 줄 수 있습니다. 이런 결과 어느 것도 확인된 기록에서 확립되지 않습니다.

이들은 공유 의존성이 상관된 구현 리스크를 만드는 통상적 메커니즘입니다.

따라서 공개 증거 부담은 집중이 커질수록 올라갑니다. MyAFRINIC v2가 가동 중이라는 일반 진술은 최대한 플랫폼 상태를 확립할 뿐입니다. AS0 베타가 여전히 부분 상태인지, RIR 간 이전 경로가 상대 기관 테스트를 통과했는지, 어뷰즈 연락처 통지가 정정될 수 있는지, AS-SET 규칙에 법적 권위가 있고 모든 생성 경로를 포괄하는지 말하지 않습니다. 하나의 건강한 로그인 화면으로는 네 개의 정책 질문에 답할 수 없습니다.

반대 오류도 가능합니다. 정책 기능은 포털이 일반 공개되기 전에 내부 경로나 포털 외 경로로 작동할 수 있습니다. 하나의 공개 인터페이스가 없다는 이유만으로 정책 전체를 미구현이라 부르는 것은 실제 진행을 과소평가할 수 있습니다. 그래서 수용은 정책별로 이루어져야 하고, 대장은 모든 것을시작 안 함(not started)이나완료(done)로 밀어넣기보다 한정된 상태를 허용해야 합니다.

최소한의 수용 대장

필요한 기록은 공개 티켓 시스템이나 소스 코드 저장소일 필요가 없습니다. 행이 정책 경로이고 항목이 추가 전용 상태 이벤트로 갱신되는 간결한 표면 됩니다.

첫째, 각 행은 정책 제목, 식별자, 버전, 법적 상태를 식별해야 합니다. 그래야 나중의 인터페이스가 잘못된 초안에 귀속되지 않습니다. AS-SET의 경우 비준이 일어나지 않는 한 행은 제안 기록으로 남아야 합니다. 다른 셋은 비준된 문서와 효력 발생 해석을 인용해야 합니다.

둘째, 정확한 포털 기준선을 명명해야 합니다.MyAFRINIC v2는 프로그램 이름이지 테스트 가능한 빌드가 아닙니다. 수용에는 코드를 공개하지 않고 상태를 재현할 수 있을 만큼 충분한 릴리스 식별자나 날짜 기준선이 필요합니다. 이후 패치가 정책 동작을 바꾸면 행은 원래 주장을 조용히 대체하는 대신 새 이벤트를 추가해야 합니다.

셋째, 의존성 클래스가 가시적이어야 합니다. 포털 사용자 인터페이스, WHOIS 규칙, IRR 기록 경로, RPKI 공표 프로세스, 내부 사무국 워크플로, 데이터 이행, RIR 간 절차는 서로 다른 의존성입니다. 라벨링은 프런트엔드 릴리스가 손대지 않은 백엔드나 외부 프로세스의 완료 크레딧을 떠안는 것을 막습니다.

넷째, 각 선행 조건과 담당 주체는 귀속 가능해야 합니다. 소유는 비난이 아닙니다. 누가 선행 조건 충족을 증명할 수 있는지 독자에게 알려줍니다. 플랫폼 기준선은 레지스트리 제품 팀, 매핑된 이전 절차는 회원 서비스, 공표 또는 검증 프로세스는 해당 운영 팀, 적용 문서는 권한 있는 정책 기구가 담당합니다.

다섯째, 각 경로에는 테스트 사례와 수용 기준이 필요합니다. AS0에는 정의된 적용 범위와 실패/정정 사례가 필요합니다. 이전에는 상대 기관 상태가 권위를 갖게 되는 시점을 포함한 적격 경로 시나리오가 필요합니다. 어뷰즈 연락처에는 성공 검증, 실패 통지, 정정, 예외 상태 테스트가 필요합니다. AS-SET은 비준되면 모든 생성 접점이 규칙이 금지하는 것을 거부하면서 기존 항목에 약속된 처리를 유지한다는 증명이 필요합니다.

여섯째, 대장은 누가 경로를 테스트했는지 기록해야 합니다. 내부 테스트, 회원 UAT, 라이브 베타는 서로 다른 질문에 답합니다. 내부 직원은 규칙 엔진을 검증할 수 있습니다. 회원은 일반 권한과 워크플로가 기능을 사용 가능하게 하는지 보여줍니다. 베타는 기능과 라이브 유사 데이터 사이의 상호작용을 노출할 수 있습니다. 결과에는 개별 회원 레코드를 공표하지 않으면서 중요한 제외 사항과 미해결 사례를 기록해야 합니다.

일곱째, 부분 구현과 전면 구현은 어느 라벨이든 쓰기 전에 정의되어야 합니다.부분 구현은 무엇이 존재하고, 무엇이 없고, 어떤 이벤트가 상태를 바꾸는지 명명할 때만 정보적입니다. 그렇지 않으면 반증 가능한 출구가 없는 영구적 휴식처가 됩니다.

마지막으로, 행에는 통지, 활성화, 정정, 관찰이 필요합니다. 독자는 사용자가 언제 통지받았는지, 규칙이 언제부터 행동을 지배했는지, 잘못된 활성화를 어떻게 롤백하거나 정정하는지, 출시 후 어떤 증거가 지속 작동을 보여줄지 알아야 합니다.

가용성 백분율은 플랫폼에 유용할 수 있지만, 정책 성과에는 자체 신호가 필요합니다. 공표 적용 범위, 완료된 적격 경로, 검증과 정정 상태, 관련 기록 경로 전반의 규칙 집행입니다.

현재 기록이 말할 수 없는 것

공식 페이지는 단면입니다. 6월에 기대를, 8월에 테스트 초청을 기술했다는 이유만으로 2026년 8월 27일 현재 상태를 입증하지 않습니다. 11월 15일이 놓쳤다는 것을 보여주지 않습니다. 증거 기준 시점에 그 날짜가 아직 오지 않았습니다. 중단, 실패한 테스트, 거부된 이전, 무효 어뷰즈 연락처, AS-SET 충돌, RPKI 경로 영향을 확립하지 않습니다. 공유 의존성으로 피해를 입은 회원을 식별하지 않습니다.

이 부재들은 편집상의 불편이 아닙니다. 검토의 적절한 대상을 정의합니다. 주제는 가정된 실패가 아니라, 보고 체계가 성공이 도착했을 때 성공을 구분할 수 있는지 — 그리고 어떤 성공이 도착했는지 식별할 수 있는지입니다.

AFRINIC은 이미구현 대기, 내부 테스트,부분 구현, 절차 매핑, 포털 이후 우선 처리, 최종 의견 수렴을 구분함으로써 그 체계의 시작을 제공했습니다. 다음 단계는 이 단어들을 정책별 수용 증거에 연결하는 것입니다. 그렇게 한다면 MyAFRINIC v2는 공유 플랫폼으로 남을 수 있고 공유 알리바이가 되지 않을 수 있습니다.

출처

• AFRINIC-37 공개 정책 회의록
• 신규 생성 AS-SET에 계층형 이름 요구 — Draft 2 및 사무국 평가
• AfPIF 2026의 AFRINIC — MyAFRINIC v2 테스트 초청
• 2026년 2월 4일 비준 정책 개요
• 현재 AFRINIC 정책 제안 및 상태 대장