요약

  • 조직 핸들 ORG-NB187-RIPE 아래에 네덜란드 자율 시스템 네 개가 올라가 있다. AS203326, AS214415, AS213291, AS215169 모두 상태가 ASSIGNED이고 이름이 각각 다르지만 유지관리자 쌍은 RIPE-NCC-END-MNT와 lir-nl-nebius-1-MNT로 동일하다.
  • AS203326과 AS214415의 IPv4 프리픽스는 213.239.160.0/19를 빈틈없이 채우는 듯 보이지만 어느 프리픽스에도 등장하지 않는 /24 여섯 개를 남기고, AS215169는 광고하는 프리픽스도 관측된 피어도 0이다.

하나의 조직, 네 개의 이름

자율 시스템은 한 기관이 관리하고 하나의 번호로 경로를 알리는 주소 묶음이다. 번호 자체는 크기를 말해 주지 않는다. 시스템 하나가 수백 개의 프리픽스를 감출 수도 있고, 등록된 시스템이 프리픽스를 하나도 광고하지 않을 수도 있다. 그래서 이 이야기는 번호를 세는 데서 시작하지 않고 조직 개체에서 시작한다.

ORG-NB187-RIPE 개체는 Nebius B.V.를 네덜란드 소재 LIR, 곧 고객에게 주소를 나눠 주는 지역 인터넷 등록기관으로 규정하고, 생성일을 2022-12-08, 최종 변경을 2026-08-05로 적는다. RIPE 문서를 직접 읽어 보면 ASSIGNED와 LEGACY는 라우팅 활동의 측정값이 아니라 개체의 행정적 상태이고, org 속성은 책임 조직을 가리키며 sponsoring-org는 아예 표시되지 않을 수 있으며, 주소 보유는 inetnum과 inet6num 개체에 살고 프리픽스와 발원 AS를 연결하는 것은 route와 route6 개체라는 설명이 나온다(RIPE 개체 유형 설명). 등록정보는 누가 등록 권한을 쥐었는지를 알려 줄 뿐, 지금 누가 패킷을 보내는지는 알려 주지 않는다.

네 번호는 공통점이 많다. 같은 상태, 같은 조직, 같은 유지관리자 쌍, 그리고 표시되지 않는 sponsoring-org. 다른 것은 이름과 선언된 익스포트 정책, 그리고 보이는 프리픽스 수다.

시스템 이름 선언된 익스포트 프리픽스 (IPv4 / IPv6)
AS203326 NebiusMAD AS174, AS1299 3 / 2
AS214415 NebiusPA10 AS9002, AS1299 9 / 4
AS213291 NebiusCloud AS208722, AS200632 17 / 17
AS215169 CoreNebiusNet AS1299, AS9002, AS6762, AS12849, AS208905 0 / 0

개수가 감추는 산수

가장 오래된 이름처럼 보이는 AS203326, NebiusMAD부터 보자. Hurricane Electric은 이 번호에 IPv4 세 개와 IPv6 두 개를 보고하고, 그 안에 213.239.176.0/24, 213.239.177.0/24, 213.239.184.0/21이 있으며 IPv6로는 2a13:5942:820::/44와 2a13:5947:13a::/48이 있다(bgp.he.net). bgp.tools도 같은 번호에 같은 수를 보여 준다(bgp.tools).

다음은 AS214415, NebiusPA10이다. IPv4 아홉 개와 IPv6 네 개, 그중에 213.239.160.0/21, 213.239.168.0/21, 그리고 2a13:5940:120::/44가 있다(bgp.he.net).

이제 두 묶음을 한 줄에 늘어놓고 산수를 하자. /21 두 개는 213.239.160.0부터 213.239.175.255까지 덮는다. /24 두 개는 213.239.176.0부터 213.239.177.255까지. /21 하나는 213.239.184.0부터 213.239.191.255까지. 남는 것은 213.239.178.0부터 213.239.183.255까지의 /24 여섯 개이고, 이 구간은 두 시스템이 광고하는 어떤 프리픽스에도 등장하지 않는다. 상위 블록 213.239.160.0/19는 213.239.191.255에서 끝난다. 계산은 인상 비평보다 단순하다. 이어 붙인 네 조각 아래에 /24 여섯 개짜리 구멍이 있다.

이 구멍이 태만을 증명하지는 않는다. 계획된 성장을 위해 비워 둔 자리일 수도 있고, 읽지 못한 inetnum 개체 안에서 더 큰 할당의 일부일 수도 있다. 다만 한 가지는 분명히 증명한다. 프리픽스 총계는 회사가 실제로 돌리는 블록을 말해 주지 않으며, 그 블록은 공개 등록정보에서 완전히 채워져 있지도 않다.

등록됐지만 라우팅되지 않는 망

등록이 행정 행위이고 라우팅이 사실이라는 점을 가장 선명하게 보여 주는 사례는 AS215169, CoreNebiusNet이다. 선언된 익스포트 정책에는 다섯 개의 트랜짓이 적혀 있다. AS1299, AS9002, AS6762, AS12849, AS208905. 서류는 다섯 방향에 동시에 연결된 망을 말하고 있는 셈이다. 그런데 실제로 광고되는 것을 보면 IPv4 프리픽스 0개, IPv6 프리픽스 0개, 관측된 피어 0개이며, 페이지 갱신 시각은 2026년 11월 10일로 찍혀 있다(bgp.he.net). IPinfo는 같은 번호를 비활성으로 분류하고 IPv4 0개, IPv6 0개, 업스트림과 다운스트림과 피어가 없다고 적는다(IPinfo).

여기서 0은 없음의 증명이 아니라 한 시점의 측정이다. 이 시스템이 전 세계에 광고되지 않는 사설 라우팅을 들고 있을 수도 있고, 막 할당받아 아직 관측자에게 도달하지 못한 프리픽스가 있을 수도 있으며, 가시성이 낮아 기본 조회에서 잘려 나간 경로가 있을 수도 있다. RIPEstat 문서는 min_peers_seeing 값이 기본 10이라고 밝히며, 그보다 적은 피어가 보는 광고는 기본 조회에서 제외된다고 설명한다(RIPEstat). 서류에서 다섯 방향을 말하는 망이 관측기에서 0으로 보인다면, 정확한 서술은 그날 공개적으로 보이지 않았다는 것이지 존재하지 않는다는 것이 아니다.

그래도 다섯 개 익스포트와 0개 광고 사이의 간격은 짚어 둘 만하다. 배치하기 전에 등록하는 것은 업계에서 낯선 일이 아니다. 번호와 이름과 정책을 먼저 잡아 두고 트래픽이 붙으면서 라우팅이 따라오는 순서다. 이 순서가 빠르게 자라는 클라우드 기업에 던지는 질문은 "등록이 운영보다 앞서는가"가 아니라 "서류와 경로 사이의 이 거리에 인프라가 얼마나 서 있는가"다.

세 개의 숫자, 세 개의 질문

세 번째 시스템 AS213291, NebiusCloud는 세는 순간 숫자가 흔들려서 더 눈에 띈다. Hurricane Electric은 IPv4 열일곱 개와 IPv6 열일곱 개를 보여 주고 별도로 광고 23개를 적는다(bgp.he.net). bgp.tools는 같은 번호에 IPv4 열일곱 개, IPv6 열여섯 개를 보여 준다(bgp.tools). 같은 기간에 IPv6 한 개가 어긋난다. 이것은 검증된 라우팅 변경이 아니라 동기화되지 않은 관측이다. 17과 16의 차이는 판단을 바꾸지 않지만 신뢰를 바꾼다. 숫자 하나를 고정된 사실로 읽는 사람은 망이 아니라 도구를 읽고 있는 것이다.

더 중요한 것은 AS213291의 프리픽스가 모두 같은 블록에 살지 않는다는 점이다. 목록에 오른 주소 공간에는 89.169.96.0/20이 포함되어 있고, 이는 213.239.160.0/19 바깥이다. 그러므로 네덜란드 Nebius의 모든 주소가 한 블록 안에 있다는 서술은 듣기 좋지만 틀렸다. 정확히는 AS203326과 AS214415의 프리픽스가 그 블록을 채우고, AS213291은 다른 곳에서 온 공간을 더한다.

PeeringDB도 한몫한다. AS213291 기록은 조직을 Nebius B.V.로, IRR as-set을 AS213291:AS-NEBIUS로, info_prefixes4와 info_prefixes6를 각각 10으로 적고 마지막 갱신을 2024-10-10으로 남긴다(PeeringDB). PeeringDB의 운영자 문서는 이 두 값이 피어가 기대할 수 있는 프리픽스의 최대치이지 실제 광고의 관측값이 아니라고 설명한다(운영자 문서). 플랫폼의 10은 의향의 진술이고, 관측기의 17은 한 시점의 측정이며, 둘 다 각자의 맥락에서 맞을 수 있다.

한 망에 세 개의 숫자가 붙는다. 관측기에서 17, 다른 관측기에서 16, 플랫폼에서 선언 10. 하나만 골라 쓰는 사람은 서로 다른 결론에 도착하지만, 세 번의 독해 사이에서 망은 변하지 않았다.

같은 교훈이 반대로도 작동한다

문제가 전부 부풀리기에 있는 것처럼 보였지만 등록정보는 반대 방향으로도 움직인다. AS401712는 네덜란드 법인이 아니라 미국의 Nebius Inc. 명의로 등록되어 있다. Hurricane Electric은 이 번호에 IPv4 한 개와 IPv6 두 개, 그리고 광고 4개를 보고하며 그 안에 2607:e840:220::/44와 2607:e840:221::/48을 적는다(bgp.he.net). 그런데 bgp.tools의 머리글에는 104.204.96.0/24만 보이고, IPv6 두 개는 가시성 낮은 경로를 보여 주는 설정을 켜야 드러난다(bgp.tools).

여기서는 개수가 부풀리지 않고 깎인다. 등록된 두 프리픽스의 광고가 워낙 희미해서 평범한 집계에 들어가지 않는다. 가장 단순한 해석은 이 경로들이 전 세계 라우팅 표에서 충분한 확산을 얻지 못했다는 것이고, 그것은 가능성일 뿐 확정된 진단이 아니다. 요점은 도구의 방향성이다. 네덜란드에서는 실제보다 많은 것을 보여 주던 계수가 미국에서는 실제보다 적은 것을 보여 준다. 개수는 한쪽으로 치우친 것이 아니라 애초에 측정값이 아니다.

개수가 쓸모를 잃는 지점

그러면 무엇이 망을 재는가. 등록정보는 서로 다른 세 층을 내놓고, 혼동은 이 층을 섞는 데서 생긴다.

첫 층은 행정이다. 조직 개체와 그 아래 네 개의 번호. 누가 등록 권한을 갖는지, 누가 지역 등록기관 앞에서 책임을 지는지, 소유자가 바뀌면 누가 번호를 물려받는지를 말한다. 둘째 층은 산수다. 213.239.160.0/19의 경계, 그 위를 채우는 조각들, 그리고 남겨진 구멍. 등록정보에서 실제로 할당된 공간이 얼마인지를 말한다. 셋째 층은 운영이다. 무엇이 광고되고 누가 보고 누가 통과시키는가. 지금 작동하는 것을 말하는 층은 이것 하나뿐이다.

계산 능력을 파는 클라우드 기업에는 세 층이 모두 필요하지만, 동시에 필요하지는 않다. 번호를 먼저 등록하고, 주소를 먼저 할당하고, 광고를 먼저 하고, 고객의 워크로드는 그 뒤에 도착한다. 첫 층을 셋째 층으로 읽는 사람은 실제보다 큰 망 그림을 만들고, 셋째 층만 읽는 사람은 성장의 실제 예산인 주소 블록을 놓친다.

이 독해가 확정하는 것과 확정하지 못하는 것

경계는 한 번만 분명히 말해 두자. 이 작업에서 aut-num, organisation, inetnum, inet6num, route 개체의 원문을 RIPE 데이터베이스에서 직접 읽지 못했다. REST와 RDAP 경로가 오류로 돌아왔고 RIPEstat 인터페이스도 쓸 만한 결과를 내놓지 않았으며, RIPE 문서가 설명하는 /{source}/{objectType}/{key} 형식의 조회조차 이 원문을 가져오는 데 도움이 되지 않았다(RIPE 조회 안내). 그래서 여기 적힌 모든 등록 속성의 출처는 명시적으로 수정된 WHOIS 사본과 감시 페이지이고, 모든 라우팅 수치는 날짜가 붙은 게시자 관측이다. 관측기의 0은 한 시점의 측정으로 남으며, 어떤 시스템이 한 번도 쓰이지 않았거나 사설 라우팅을 전혀 나르지 않는다는 증명이 아니다. 여기 적힌 Nebius B.V.의 자율 시스템 개수는 검증된 총계가 아니라 이번에 확인한 개체의 수다. 213.239.160.0/19 안의 프리픽스가 하나의 할당에서 나왔는지, 그 할당의 경계가 정확히 어디인지는 해당 inetnum 개체를 읽기 전까지 열린 질문이다.

BTW 디렉터리의 Nebius B.V. 항목: entity:nebius-b-v-nl