요약

  • APNIC이 캡처한 9월 8일 14:00–15:00 UTC 스냅샷은 WHOIS 질의 3,192,583건을 보고하지만, 표시된 질의 유형의 합계는 3,183,463으로 양(+9,120)의 차이가 있습니다. 같은 파일의 RDAP 총계는 정확히 일치합니다.
  • 6월 30일 시작부터 증거 마감 시점까지 WHOIS 트래픽이 포함된 아카이브된 1,690개 시간대 전체에서total_queries가 유형 합계와 달랐습니다. 차이는 1,011개 파일에서 양수, 679개 파일에서 음수였으며, 누락된 비음수 'unknown' 범주로는 양쪽 부호를 설명할 수 없습니다.
  • APNIC이 게시한 APNIC 62 이행 자료는 일부 데이터 정확성 문제가 해결 중이라며 prop-167이 여전히 이행 단계에 있다고 밝힙니다. 다만 이 자료는 본 기사가 다루는 산술 문제를 지목하지는 않습니다. 원시 질의를 노출하지 않으면서 계산 단계, 제외된 분류, 검증 결과 및 정정 내역을 명시하는 프라이버시 안전한 대사(照合) 장부가 필요합니다.

공개 통계 파일의 마지막 등식이 그 파일을 만든 기관에 대한 이론을 요구해서는 안 됩니다. 증거 마감 시점 기준 APNIC의 최신 스냅샷은 2026년 9월 8일 14:00~15:00 UTC의 시간대를 다룹니다. WHOIS 섹션은total_queries를 3,192,583으로 제시합니다. 표시된 분포에는inetnum1,670,618,route1,284,709,aut-num93,537,도메인88,530,organisation31,500,as-set13,888,inet6num질의 721건이 포함됩니다. 이 일곱 개 정수를 더하면 3,183,463입니다.

차이는 9,120건으로 공개된 총계의 0.2857%에 해당합니다. 인접한 RDAP 섹션이 유용한 대조를 제공합니다. RDAP의 다섯 개 표시 질의 클래스 합계는 588,346으로,total_queries필드의 값과 정확히 일치합니다. 스냅샷의 MD5 사이드카 파일도 다운로드한 JSON과 일치합니다. 파일은 온전하게 도착했습니다. 한 서비스의 산술은 맞고 다른 서비스의 산술은 맞지 않습니다.

바쁜 한 시간대에서의 작은 불일치입니다. 그러나 그 시간대가 예외가 아니기 때문에 기관 차원의 질문으로 바뀝니다.

비영(非零) WHOIS 시간대 전체에 나타나는 차이

APNIC은 prop-167 페이지가 'Implementation Complete'로 기록한 날짜인 6월 30일에 아카이브를 시작했습니다. 저는 월별 인덱스를 나열하고, 9월 8일 14:00 UTC에 끝나는 아카이브까지 이용 가능한 모든 압축 시간별 파일을 검사했습니다. 예상 구간은 1,691개였고 파일도 1,691개였습니다. 파일명은 연속적이었습니다. 모든 gzip 스트림이 복호화되었고, 모든 문서가 JSON으로 파싱되었으며, 내장된 반개방 시간 범위는 모두 파일명과 일치했습니다. 동일한 지문(fingerprint)을 가진 압축 해제 파일은 두 개뿐이 아니라 하나도 없었습니다.

서비스와 시간대별로query_type_distribution의 값을 모두 더해total_queries에서 뺐습니다. 표시된 모든 ASN 행에 대해 같은 연산을 수행했습니다. 즉query_count에서query_count_by_type의 합계를 뺐습니다.

RDAP은 1,691개 파일 전체에서, 두 수준 모두에서 맞았습니다. 서비스 전체 부호 차이는 항상 0이었고, 표시된 어떤 ASN 행도 유형 합계가 행의 질의 수와 달랐던 적이 없습니다.

WHOIS은 단 한 개 파일에서만 맞았습니다. 그 예외는 8월 27일 09:00~10:00 UTC로, WHOIS 섹션에 총 질의 0건, ASN 0개, 빈 분포, 행 없음이 담겨 있었습니다. 다시 말해 WHOIS 트래픽이 포함된 아카이브된 1,690개 파일 전부가 서로 다른 두 개의 서비스 전체 총계를 담고 있었습니다. 같은 1,690개 파일에는query_count가 유형별 합계와 달랐던 표시된 ASN 행이 최소 하나씩 있었고, 아카이브 전체에서 그런 성격의 표시 행은 347,490개였습니다.

첫 아카이브 시간대에도 이미 이 패턴이 있었습니다. 6월 30일 03:00~04:00 UTC에 WHOIS는 총 질의 4,774,145건을 보고한 반면 유형 합계는 4,801,599였습니다. 유형 수가 27,454 더 높았습니다. 마지막 아카이브 시간대인 9월 8일 13:00~14:00 UTC에서는 보고된 총계가 2,989,539, 유형 합계는 2,987,334로 이번에는 총계가 2,205 더 높았습니다.

부호의 반전이 누적 차이보다 더 중요합니다. 1,011개 파일에서total_queries가 유형 합계보다 컸습니다. 그럴듯한 설명은 서비스가 수용했으나 명명된 객체 유형 중 하나로 배정되지 못한 요청일 수 있습니다.unknown또는other버킷을 추가하면 그런 시간대는 닫힐 수 있습니다.

그러나 679개 파일에서는 방향이 반대입니다. 명명된 유형 수의 합이 선언된 총계보다 큽니다. 7월 14일 05:00~06:00 UTC 파일은 WHOIS 질의 3,288,941건과 유형 합계 3,652,538을 보고합니다. 합계가 총계를 363,597, 즉 11.0551% 초과합니다. 누락된 비음수 범주로는 그만큼 빼낼 수 없습니다. 8월 20일 03:00~04:00 UTC에서는 총계가 유형 합계를 80,961, 즉 2.3823% 초과합니다. 하나의 고정된 산술 보정으로 두 사례를 모두 해결할 수 없습니다.

정직한 두 개의 계산 단계도 여전히 하나의 오해를 일으키는 파일을 만들 수 있다

가장 강력한 반론은 산술이 선택 사항이라는 것이 아니라, 필드들이 서로 다른 질문에 답하고 있을 수 있다는 것입니다.

total_queries는 서비스 경계에서 수용된 요청을 세는 반면,query_type_distribution은 파싱 이후의 객체를 셉니다. 유형 카운터는 더 늦은 컴포넌트에서 출력되거나, 다른 이벤트 시각을 쓰거나, 재시도된 내부 작업을 포함하거나, 형식이 맞지 않는 명령을 제외하거나, 총계가 확정된 뒤에 정산될 수 있습니다. ASN 보강(enrichment)은 한 레코드에는 성공하고 다른 레코드에는 실패할 수 있습니다. 서비스가 명령 구문을 기록하는 방식에 따라 하나의 질의가 하나 이상의 클래스에 속할 수도 있습니다. 이 중 어떤 배치도 운영상으로는 정당할 수 있습니다.

공개 README는 이것이 실제 배치라고 말하지 않습니다. README는 각 WHOIS 및 RDAP 섹션에 총 질의 수와 질의 유형별 질의 수 매핑이 담겨 있다고만 설명합니다. 1시간 시간 창과 ASN별 필드는 정의하지만, 별도의 계산 경계, 지연 도착 규칙, 재시도 처리, 제외 기준, 다중 클래스 규칙은 명시하지 않습니다.unclassified필드, 검증 결과, 정정된 파일이 대체하는 이전 버전에 대한 포인터도 제공하지 않습니다.

바로 이 누락 때문에 본 기사는 어느 쪽이 맞다고 판단할 수 없습니다. 증거는 3,192,583과 3,183,463 중 어느 것이 적절히 정의된 어떤 질문에 대한 올바른 답인지 보여주지 않습니다. 증거가 보여주는 것은, 질문을 구분하는 데 필요한 정의 없이 두 답이 함께 제공된다는 사실입니다.

이것이 체크섬이 불충분한 이유이기도 합니다. 체크섬은 독자가 다운로드한 바이트가 APNIC이 공개한 바이트임을 증명할 뿐, 그 바이트 안의 두 필드가 같은 분모를 공유함을 증명하지 못합니다. 파일 무결성과 지표의 일관성은 별개의 속성입니다.

APNIC 자신의 상태 표시에 이제 해결되지 않은 층위가 있다

정책 기록과 회의 자료는 함께 신중하게 읽어야 합니다. prop-167 페이지는 여전히Implemented라고 표시하고 6월 30일 'Implementation Complete'를 기록합니다. 반면 9월 10일에 열리도록 예정된 APNIC 62 Open Policy Meeting용으로 게시된 발표 자료는 다른 언어를 씁니다. prop-167 슬라이드는 'Status: In Implementation'이라고 밝히고, 통계가 6월 30일에 처음 공개되었음을 언급하며, 이어 'Some issues with data accuracy – Currently being resolved'라고 덧붙입니다. 완료는 3분기 말까지 예상된다고 합니다.

그 자료는 예정된 세션 이전에 이미 공개되어 있었습니다. 이것은 APNIC이 준비한 문서의 증거이지, Dave Phelan이 이미 Policy SIG에 그 말을 전달했다는 증거는 아닙니다. 더 중요한 것은, 그 슬라이드가 어떤 데이터 문제를 의미하는지 지목하지 않는다는 점입니다. APNIC이 본 기사에서 문서화한 산술 문제를 진단했거나, 그 불일치가 상태 변경의 원인이라고 주장하는 것은 무책임할 것입니다.

슬라이드가 확립하는 더 좁은 사실은 이것입니다. APNIC 자신이 더는 초기 공개를 이행 과정의 끝으로 제시하지 않는다는 점입니다. 공개 정책 페이지와 게시된 이행 업데이트는 서로 다른 층위의 완료를 기술합니다. 하나는 서비스가 시작되었음을 기록하고, 다른 하나는 데이터 정확성을 열어 둔 채로 둡니다.

이 구분은 유용합니다. 피드는 실시간, 시간별, 연속, 체크섬 검증 상태이면서도 공개된 필드의 의미론적 대사(照合)를 여전히 필요로 할 수 있습니다. 'Implemented'는 가용성을, 'in implementation'은 보증 수준을 각각 정직하게 기술할 수 있습니다. 실수는 둘을 하나의 무차별적 상태로 강제로 합치는 것입니다.

분모가 아카이브가 증명할 수 있는 것을 바꾼다

이 피드에는 실질적 가치가 있습니다. 출처 IP 주소나 조회 대상 레코드를 공개하지 않으면서 집계적 WHOIS 및 RDAP 사용 현황을 가시화합니다. 연구자는 서비스 볼륨, 객체 유형 구성, 출처 ASN 집중도, 고유 출처 IP 수를 볼 수 있습니다. 운영자는 시간대를 비교하고 예외적 패턴을 조사할 수 있습니다. 결과를 다운로드 가능하게 만들고 시간별 파일을 보존한 점에서 APNIC은 공을 인정받아야 합니다.

그러나 모든 재사용은 분석자가 인식하든 아니든 하나의 분모를 선택합니다. ASN 행을total_queries로 나눈 집중도 지분과 유형 합계로 나눈 지분은 서로 다릅니다. 총계를 쓴 추세선과 유형을 더해 만든 추세선은 다르게 움직일 수 있습니다. 음의 차이가 다중 클래스 계산 때문이라면 유형 합계는 고유 요청 수를 의도적으로 과대계일 수 있습니다. 양의 차이가 미분류 요청 때문이라면 유형 구성은 서비스 부하의 일부를 누락할 수 있습니다. 단계 정의가 없으면 완벽히 정확한 차트가 명시되지 않은 질문에 답할 수 있습니다.

ASN별 행은 또 하나의 경계를 더합니다. 각 서비스는 수천 개의 출처 ASN을 보고할 수 있지만, 관찰된 파일들에서asns배열은 최대 1,000행입니다. 이는 의도적인 상위 목록 한도일 수 있으나 README는 그렇게 표시하지 않습니다. 따라서 표시된 행의 합계는 그 내부 유형 산술이 보정된 후에도 서비스 총계와 같을 필요가 없습니다. 완전한 공개 계약은 잘린 순위표와 모집단 총계를 구분해야 합니다.

이 중 어느 것도 서비스 장애를 증명하지 않습니다. 질의가 누락, 중복 또는 오답되었다는 것을 보여주지 않습니다. 결함이 있는 ASN을 지목하거나, 출처 주소를 노출하거나, 악의적 자동화를 암시하지도 않습니다. 질의가 없었던 그 한 시간대는 그 자체로 장애의 증거가 아닙니다. 본 기사의 발견은 증거 표면, 즉 제3자가 공개된 파일에서 재구성할 수 있는 것에 관한 것입니다.

다리와 정정 사슬을 공개하라

그 증거 표면을 수리하기 위해 APNIC이 원시 로그를 공개할 필요는 없습니다. 시간대별로 작은 프라이버시 안전 대사(照合) 기록이 필요할 뿐입니다.

그 기록은 계산 등식에서 시작해야 합니다. 외부 경계에서 수용된 요청 수, 성공적으로 파싱되어 분류된 수, 형식 불량·미지원·시간 초과 또는 기타 미해결로 제외된 수를 명시하십시오. 하나의 질의가 여러 유형에 기여할 수 있다면 그 규칙을 명시하고 결과적인 다중 클래스 증분을 공개하십시오. 총계와 유형이 서로 다른 시각에 확정된다면 두 마감 시각과 지연 도착 처리 방식을 제시하십시오.

다음으로 변환을 식별하십시오. 실행 식별자, 수집 버전, 분류기 버전, 그리고 표시된 모든 등식을 재계산하는 자동 검증의 결과를 공개하십시오. 출처 ASN 보강의 성공과 미확인은 주소가 아니라 집계로 보고하십시오. 1,000행 배열이 순위표인지 전체 모집단인지 표시하고 선정 규칙을 명시하십시오.

마지막으로 정정을 일급 이벤트로 만드십시오. 각 시간별 파일은 품질 상태—임시, 검증됨, 정정됨, 철회됨—와 지문(fingerprint)을 가져야 합니다. 대체 파일은 대체된 지문, 정정 시각, 사유 범주, 영향받는 필드를 명시해야 합니다. 이전 버전은 계속 검색 가능해야 합니다. 그러면 독자는 과거 차트가 초기 공개를 사용했는지, 수리된 측정치를 사용했는지 판별할 수 있습니다.

이 설계는 소박합니다. 질문이 소박하기 때문입니다. APNIC에게 누가 무엇을 조회했는지를 요구하지 않습니다. 두 총계의 게시자에게 그것들이 어떻게 결합되는지를 밝히도록 요구할 뿐입니다. 이 아카이브는 이미 값비싼 기관적 작업—정기 생성, 공개 접근, 보존, 무결성 검사—을 해냈습니다. 대사(照合)는 그 파일들을 관찰 가능한 산출물에서 재사용 가능한 증거로 바꾸는 영수증입니다.

출처