요약

  • abuse-c 검증 캠페인은 커뮤니티가 의무화한 매년 반복되는 점검으로, RIPE 데이터베이스의 abuse-mailbox 속성이 메일을 수신할 수 있는지 — 즉 도착한 내용을 누군가 읽고 조치하는지가 아니라 — 확인한다.
  • 공표된 수치는 규모가 크고 일관적이다. 2019년 초기 전수조사에서 77,168개, 이후 84,868개(2023), 83,509개(2024), 86,959개(2025)이며, 반복적으로 6–8%의 실패 대역과 함께 수작업 부담의 꼬리가 커지고 있다.
  • 캠페인 문서와 레지스트리 연차보고서 어디에도, 검증된 메일함에 abuse 신고가 도착한 이후 어떤 일이 벌어지는지를 추적하는 공표 통계는 존재하지 않는다.
  • 이 검증 캠페인은 절차적 컴플라이언스의 증명으로 기능하며, 책임성 증거로 기능한 적이 있는지는 기록이 답하지 않는 질문이다.

RIPE NCC는 서비스 지역 내 abuse 연락처 데이터에 대해 문서상 측정 가능한 조치를 하는 것으로 확인될 수 있는 유일한 당사자다. 2019년 말 이후 RIPE NCC는 RIPE 데이터베이스의 모든 abuse-mailbox 속성을 매년 최소 한 번 검증해 왔으며, 그 결과를 차트 수준의 정밀도로 보고한다. 검증 대상 주소 수, 자동 통과 수, 사람이 직접 추적해야 하는 수까지다. 수치는 실재하고, 공개되어 있고, 감사 가능하다. 본 보고서는 이를 그만큼 진지하게 받아들여 면밀히 읽는다.

의무

이 캠페인은 RIPE 커뮤니티가 그렇게 하기로 결정했기 때문에 존재한다. 정책 제안 2017-02 "Regular abuse-c Validation"은 2018년 6월 1일 최종 합의에 도달했고 2019년 10월 10일에 전면 시행되었다(출처 1). 같은 합의일에 RIPE-705로 공표된 이 정책 문서는 RIPE NCC가 "abuse-mailbox:" 속성을 최소 매년 검증하도록, 각 abuse-c role 객체가 단일 abuse-mailbox 속성을 포함하도록, 그 속성이 "whois, API 및 향후 기법을 통해 제한 없이 이용 가능"하도록 요구한다. 속성이 부정확하다고 판단될 경우 정책은 레지스트리에 "관련 RIPE 정책 및 RIPE NCC 절차에 따라 후속 조치"하도록 지시한다(출처 0).

정확히 읽으면 이 의무는 두 부분으로 나뉜다. 첫째는 명확하다. 매년 최소 한 번 메일함을 검증하라. 둘째 — "관련 정책에 따라" 부정확한 속성에 후속 조치하라 — 는 실질을 다른 문서에 위임하며, 본 보고서가 보여주듯 실제로는 abuse 신고 자체에 대한 어떤 책임성도 아니라 기술적 시정 절차의 사다리만 산출한다.

레지스트리가 시작 전에 공표한 방법

2018년 10월, 첫 전수조사 전에 RIPE NCC 직원들이 RIPE Labs에 의도된 방법론을 공표했고, 그것은 이후 줄곧 이 캠페인의 운영 설명으로 남아 있다. 자동 검증 도구는 이메일 주소의 형식 오류를 검사하고, DNS 항목을 확인하며, 가짜 주소나 허니팟 주소를 찾고, 메일 서버에 ping을 보내 메일함이 존재하고 메일을 수신할 수 있는지 확인한다. 결정적으로, 이 도구는 "어떤 이메일도 보내지 않으며 abuse 연락처에게 어떤 조치도 요구하지 않는다" — 부담을 줄이기 위한 의도된 설계 선택이지만, 동시에 그 검증이 메일함을 사람이 읽는지는 절대 확인하지 않는다는 뜻이다(출처 2).

실패한 주소에는 검증 링크가 발송되며, 1주 간격으로 최대 3회 후속 이메일이 전송되고, 약 3주 후에야 직원이 개입한다. 레거시 자원은 이 정책의 범위 밖이다. 그리고 레지스트리는 자기 의무의 경계를 한 문장으로 밝혔고, 그 문장은 이후 줄곧 이 캠페인을 정의해 왔다. "네트워크 운영자가 수신한 abuse 신고를 어떻게 처리하는지에 대해 우리는 발언권이 없다"(출처 2).

이 문장이 이후 모든 것의 경첩이다. 즉 검증은 전달 가능성(deliverability)만 측정한다. 레지스트리 자신의 프레이밍이 작동하는 메일함과 작동하는 abuse 처리 프로세스 사이의 선을 그으며, 공표된 수치는 전부 전달 가능성 쪽에 머문다.

2019: 초기 전수조사

초기 검증은 2019년 2월부터 10월까지 약 77,200개의 서로 다른 abuse-mailbox 속성에 걸쳐 진행되었다. RIPE 79에서 RIPE NCC 직원들이 제시한 결과: 77,168개의 서로 다른 속성이 검사되었고, 그중 71,711개 — 93% — 가 자동 검증을 통과했으며 5,457개 — 7% — 가 실패했다. 그 결과로 2019년에 약 8,000개의 abuse-mailbox 속성이 갱신되었다. 작업 부담도 만만치 않았다. 수개월간 상근 임시 직원 3명, 그리고 티켓의 20–25%가 수동 후속 조치를 요구했다(출처 4).

2019년 5월의 중간 진행 보고서가 세부 기전을 채워 준다. 그 시점까지 약 67,000개 연락처 검사, 약 9,500개 갱신(보고서 자체가 경고하듯 중복을 포함하는 집계), 약 60%의 사례가 직원 개입 없이 자동 프로세스로 해결, 그리고 초기 라운드 완료 후 신규 회원 및 갱신 연락처에 대해 하루 약 10건의 티켓으로 상시 검증이 이어짐(출처 3).

초기 캠페인에는 이후 보고서들이 대개 건너뛰는 두 가지가 주목할 만하다. 첫째, 실패율은 반올림 오류가 아니었다. 커뮤니티 정책이 전면 시행된 그날, 열네 개 메일함 중 하나가 abuse 신고 경로 전체가 의존하는 메일을 받을 수 없었다. 둘째, 시정은 속성 수준에서 작동했다. 메일함이 갱신되고, 티켓이 닫히고, 데이터베이스가 고쳐졌다. 수치가 보여줄 수 없는 것은, 작동하게 된 그 메일함들이 실제 불만 접수를 받아 조치했는지 여부다. 캠페인의 완료 기준은 애초에 데이터베이스 전역의 최초 검증 완료로 정의되어 있었다(출처 1) — 전적으로 내부적 척도였다.

안정 상태: 연간 기계

2019년 이후 이 캠페인은 연례 반복 운영으로 정착했고, 그 형태는 2023년 말 RIPE 87에서 문서화되었다. 연간 검증은 LIR 조직 객체 내 약 19,600개 abuse 연락처, LIR 자원 객체 내 약 58,100개, 독립 자원 객체(PI 및 ASN) 내 약 15,400개를 커버한다 — 전체 약 93,000개 연락처 배치, 주당 약 2,000개 연락처 검사, 매 차수 6–8%의 실패율(출처 5).

같은 발표는 시행 결과도 밝히는데, 비대칭적이다. 자원 객체 내부의 무효한 abuse-c는 단순히 LIR의 작동 중인 abuse-c로 교체된다 — 레지스트리가 일방적으로 수행하는 행정적 수정이다. 반면 LIR 조직 객체 자체의 무효한 abuse-c는 "광범위한 조사"를 촉발하고, 사다리 끝에서 회원 자격 종료로 이를 수 있다(출처 5). 요컨대 심각성 사다리는 존재하고 실재하다 — 그러나 그 모든 단계는 전달 가능성에 의해서만 작동하며, 절대 행위에 의해서 작동하지 않는다. 매년 검증은 모두 통과하지만 abuse 대기열을 수년째 방치하는 회원은 사다리의 어떤 단계도 밟지 않는다.

연차보고서가 세는 것들, 2023–2025

최근 3개년 연차보고서는 레지스트리 자체의 감사된 수치로 추세선을 보여 준다.

2023 연차보고서는 2023년에 검증된 abuse-c 이메일 주소 84,868개를 기록했으며, 이 중 84,219개가 자동 프로세스를 통과하고 649개가 수동 개입을 요구했다. abuse-c 검증 조사 2,503건 — LIR 자원 910건, LIR 853건, 최종 사용자 740건으로 분류 — 이며, 연간 생성 및/또는 갱신된 abuse-c role 객체는 149,228개였다(출처 6).

2024 연차보고서는 검증된 주소 83,509개 — 자동 82,658개, 수동 851개 — 와 검증 조사 2,366건(LIR 계정 841건, LIR 자원 774건, 최종 사용자 751건), 그리고 abuse-c 정책 준수를 포함한 시정 조치 5,500건을 산출한 지원 레지스트리 점검(Assisted Registry Checks) 2,445건을 기록했다(출처 7;Annual Report 2024, RIPE-840 문서 페이지).

2025 연차보고서는 전년 83,509개 대비 검증된 주소 86,959개, 수동 개입 899건(2024년 851건 대비), 검증 조사 2,320건(LIR 계정 801건, LIR 자원 764건, 최종 사용자 755건), 그리고 목표 2,400건 대비 완료된 지원 레지스트리 점검 2,825건을 기록했다. 보고서 본문은 조사 건수를 "2,300건 이상"으로 반올림하며 명확히 밝힌다. "또한 RIPE-705 준수를 위해 모든 abuse-c 주소를 성공적으로 검증했다"(출처 9;RIPE-855 PDF, ripe.net 미러).

이 세 해를 함께 읽으면 세 가지 관찰이 나온다.

첫째, 검증 대상 모집단은 안정적이고 깨끗한 핵심으로 수렴하지 않고 있다. 2024년과 2025년 사이에 83,509개에서 86,959개로 — 검증할 메일함이 4.1% 증가 — 성장했으며, 수동 개입의 꼬리도 함께 커졌다. 649건(2023), 851건(2024), 899건(2025), 2년간 38.5% 증가다. 기계는 확장되지만, 인력 작업도 함께 확장된다.

둘째, 연간 "검증 조사" 수치 — 약 2,300건에서 2,500건 — 는 결과 지표가 아니라 업무량 지표다. 개시된 사례 수를 계정 유형별로 분포하여 세는 것이다. 소유자가 얼마나 해결했는지, 몇 건이 속성 교체로 끝났는지, 몇 건이 종료 사다리 조사 단계에 도달했는지, 몇 건이 아예 응답하지 않았는지는 말해 주지 않는다. 세 보고서 어느 것도 해결 분류를 공표하지 않는다.

셋째, 2025년 보고서의 완결성 주장 — "모든 abuse-c 주소"가 검증됨 — 는 모집단에 대한 단정이다. 커버리지를 확인할 뿐, 결과를 확인하지 않는다. 같은 보고서의 차트는 자동 검증에 실패해 사람이 필요했던 899개 주소를 보여 준다. 본문 단정과 차트가 공존하는 이유는 검증-완료와 검증-성공이 서로 다른 주장이기 때문이며, 보고서는 독자가 가장 인용하기 쉬운 문장에서 그 둘을 구분하지 않는다.

수치가 전제하고 있는 부재

캠페인 자체 문서들을 나란히 놓으면 외부 데이터 없이도 구조적 패턴이 보인다. 의무는 전달 가능성을 검증한다(출처 0). 방법은 메일이 읽히고 조치되는지를 검증하지 않는다고 명시한다(출처 2). 시행 사다리는 전달 가능성에 작동하며, 절대 행위에 작동하지 않는다(출처 5). 그리고 연차보고서는 검증된 주소, 개시된 조사, 완료된 점검을 측정한다(출처 6;출처 7;출처 9) — 검증된 메일함에 제3자의 abuse 신고가 몇 건 전달되었는지, 몇 건이 응답을 받았는지, 몇 건이 신고된 abuse의 확인된 시정으로 끝났는지에 대한 공표 수치는 이 사슬 어디에도 없다.

이는 레지스트리가 부여받은 과제를 실패했다는 주장이 아니다. 여기서 조합된 기록상, 그 과제는 애초에 부여된 적이 없다. RIPE-705는 부정확한 속성에 대해 "관련 RIPE 정책 및 RIPE NCC 절차에 따라" 후속 조치하라고 지시한다 — 기술적 시정 지시다(출처 0). 운영자 행위에 대한 발언권 부인은 이 캠페인을 시작한 같은 문서 세트에서 공표되었다(출처 2). 정확한 서술은 더 좁고 더 불편하다. 이 지역의 유일하게 측정 가능하고, 반복적이며, 공개적으로 보고되는 abuse 연락처 프로세스는 신고를 제출하는 사람들에게 결과를 가장 덜 좌우하는 문제 부분을 정확히 측정하도록 설계되어 있다.