요약

  • 2026-11-01T15:11:50.584130+00:00에 만들어진 BTW 디렉터리 투영은 식별·지리·연락처·인물에서 1점, 법인 형태·통제·서비스·네트워크·사건·증거에서 0점이다. 흐릿한 공백이 여섯 개가 아니라 이름이 붙은 결손이 여섯 개다.
  • 네트워크 블록에는 ASN 0개, 프리픽스 0개, 피어 0개, 상위·하위 연결 0개, 시설 0개, 교환지점 0개, 평가된 RPKI 객체 0개가 들어 있고, 절단 플래그 두 개가 모두 false다. 크기 때문에 잘려 나간 것은 아무것도 없다는 뜻이다.
  • 공개된 연락처 흔적은 alcatel.com 도메인의 가림 처리된 abuse 주소 하나, 신뢰도 0.9가 전부다. 기록 어디에도 네트워크 운영센터, 에스컬레이션 매트릭스, 장애 데스크는 묘사되지 않는다.
  • 검증 조건은 미리 밝혀 둔다. ASN 하나, 공고된 프리픽스 하나, 시설 기록 하나, 교환지점 존재 하나, 통제 관계 하나, 사건 기록 하나, 또는 이 등록 주체에 귀속되는 날짜 있는 역량 진술 하나면 어느 한 칸이 0에서 벗어난다. 우리 기록이 가진 해상도에서는 그중 어느 것도 일어나지 않는다.

2026년 11월 1일 15:11:50 UTC, BTW 디렉터리는 2026년 6월 17일 22:06:08 UTC에 처음 본 한 실체의 투영을 닫았다. 이름은 STC Submarine Systems, Inc., 등록 관할지는 "United States", 별칭은 "Submarine Systems, Inc.", 디렉터리 신뢰도는 0.85이며, 이 이름이 애초에 우리 색인에 존재하는 이유가 원문 그대로 이렇게 적혀 있다. "STC Submarine Systems, Inc. appears in US with 6 supporting public references but no confirmed operator yet; BTW tracks it to link these public clues to a responsible organisation and its relationships." 공개 참조 여섯 건, 확인된 운영자는 아직 없다. 이 색인의 존재 이유는 그 단서들을 책임 있는 조직과 그 관계에 연결하는 것이다.

이틀 뒤 나는 그 문장 뒤에 있는 문서를 열어 보려 다섯 번 시도했다. 이름이 거의 같은 영국 회사 기록과 핸들 SSS-10의 ARIN 조직 객체가, 이 이름이 물리적인 무언가에 매여 있는지를 판정할 두 페이지다. 11월 4일 07:19부터 07:52 UTC 사이에 다섯 번의 시도가 전송 계층에서 실패했다. 한 번은 권한과 과금 거부, 네 번은 "제한된 대기 후 공급자 용량을 사용할 수 없음"이었다. 두 페이지 모두 이 기사를 위해 열리지 않았다. 따라서 아래의 모든 수치는 그 시각에 우리가 저장한 투영을 가리키며, 담당 공무원이 오늘 오후에 읽어 줄 등기 파일이 아니다.

이 제약을 마지막이 아니라 두 번째 문단에 두는 이유는, 쉽게 뒤섞이는 두 가지를 갈라놓기 때문이다. 거기에 아무것도 없다는 것과 우리가 더 멀리 보지 못했다는 것. 이 기록은 이름에 대해 침묵하지 않는다. 절반에서는 이상할 만큼 정확하고 다른 절반에서는 완전히 백지이며, 백지인 쪽이 바로 당신이 사고, 연결하고, 새벽 세 시에 도움을 청할 쪽이다.

채워진 절반

디렉터리 기록 전략 서클 전용은 네 개 절에서 최고 완성도에 이른다. 식별: 1, 완전, 주장 네 건. 지리: 1, 완전, 주장 두 건. 연락처: 1, 완전, 기록 여덟 건. 인물: 1, 완전, 기록 두 건. 전체 주장 수는 일곱이다. 기록 자체의 카운터는 사실 일곱 건, 출처 일곱 건, 출처 관측 일곱 건, 연락처 열두 건, 관계 0개, 식별 충돌 0개, 데이터 결손 여섯 건을 보고한다.

이 카운터를 두 번 읽으면 서로 어긋나기 시작한다. 여기서는 연락처 기록이 여덟 건, 저기서는 연락처가 열두 건, 또 다른 층에서는 공개 연락처 주장이 일곱 건이다. 등기부 대량 추출로 조립된 기록에서는 정상적인 동작이며, 매끄럽게 덮는 대신 그대로 말하는 편이 낫다. 카운터들은 조금씩 다른 것을 세고 있고, 그것들이 맞아떨어지기를 기대하는 독자는 아직 등기부끼리의 조인을 만나지 못한 것이다.

식별 절이 확립하는 것은 소박하고 단단하다. 법인명 칸에는 STC Submarine Systems, Inc.가 들어 있다. 별칭은 "Submarine Systems, Inc."다. 등록 관할지는 "United States"이고 지역 패싯은 US다. 기록은 이를 회사("company")로 분류한다. 신뢰도는 0.85, 작업용 식별이지 검증된 식별이 아니다.

0점인 절반

이제 다른 절반이다. 여섯 개 절이 정확히 0점이고 각각 이름 붙은 결손을 달고 있다. 법인 형태: 0, 비어 있음, "no_legal_claims", 그리고 법인 형태 칸에는 문자 그대로 "unknown"이 들어 있다. 통제: 0, 비어 있음, "no_control_relationships". 서비스: 0, 비어 있음, "no_service_claims". 네트워크: 0, 비어 있음, "no_network_resources_or_relationships". 사건: 0, 비어 있음, "no_event_claims". 증거: 0, 비어 있음, "no_observed_or_counted_evidence".

결손 여섯, 이름 여섯, 회사 하나. "모른다"고 적힌 기록이 그럴듯한 추측으로 칸을 채운 기록보다 쓸모 있다. 적어도 이 기록은 추측을 거부한다. 그러나 결손의 모양이 중요하다. 법인 형태는 단순히 채워지지 않은 것이 아니다. 칸은 존재하고 그 안에 "unknown"이라는 문자열이 들어 있다. 통제 칸이 비어 있는데, 이 기록의 유일한 존재 이유가 공개 단서를 "책임 있는 조직과 그 관계"에 연결하는 것이다. 그것은 BTW가 6월에 스스로에게 부여한 작업이고, 11월 1일 기준으로 여전히 미완이다.

절 뒤에는 숫자가 있다. 전체 주장: 일곱. 네트워크 기록: 0. 서비스 기록: 0. 사건 기록: 0. 도메인 주장: 0. 웹사이트 주장: 0. 멤버십: 0. 회사 도시에의 재무 블록과 거버넌스 블록은 모두 "identity_unresolved"로 적혀 있다.

네트워크 산수, 전부

운영 질문을 한 화면에서 보고 싶다면, 네트워크 블록은 등기부가 잠깐 공학 문서인 척하는 자리다. ASN 수: 0. 프리픽스 수: 0. 프리픽스 합계: 0. 네트워크 관계 기록: 0. 교환지점 수: 0. 시설 수: 0. 피어: 0. 상위: 0. 하위: 0. RPKI 객체: 총 0, 평가 0.

이력 블록은 모든 칸이 비어 있다. 최초 관측 null, 최종 관측 null, 프리픽스 연표 비어 있음, 할당 이력 비어 있음, 관계 이력 비어 있음. 그리고 결손을 측정값으로 바꾸는 두 플래그가 뒤따른다. 절단 플래그가 false다. 이 절에서 크기 때문에 잘린 것은 아무것도 없다. 이 절은 우리가 보여 주기를 거부한 더 큰 집합의 요약이 아니다. 집합 전부다.

이것이 중요한 이유는 잘린 0과 완전한 0이 서로 다른 말을 하기 때문이고, 그 차이는 정확히 "우리가 보지 않았다"와 "우리가 보았는데 시야에 아무것도 없었다"의 차이다. 여기의 부기는 우리 손에 어느 쪽이 들려 있는지 말해 줄 만큼 정직하다.

양방향 모두 대칭적으로 비어 있다. 나가는 것도, 들어오는 것도 없다. 모회사도, 자회사도, 공급자도, 고객도, 피어도, 승계자도 없다. 보존된 증거 링크는 여섯 개, 모두 ARIN에서 나왔다. ARIN의 네트워크 대량 파일, 그중 세 개는 ASN 등록부 추출본, 하나는 SSS-10 조직 객체, 그리고 나머지 둘은 URL이 아예 없다. 여섯 개 모두 같은 일반 문구 "supports"를 달고 있다. 등기부 값을 인용한 것은 하나도 없다.

기록 자체의 증거 조회는 아무것도 돌려주지 않는다. 보존된 발췌 없음, 이 여섯 라벨 뒤에 출처 스냅숏은 하나도 없다. 즉 증거 계층은 다른 회사들의 기록으로 가득 찬 수 메가바이트짜리 파일들을 가리키는 포인터 묶음이다. 그것은 이 회사에 대한 증거와 같지 않으며, 기록은 그런 척하지 않는다. 증거 절은 0점이고 그렇게 이름 붙어 있다.

기록 전체에서 서비스 영역 주장은 단 하나이고, 그것은 자기 지움에 이를 만큼 정직하다. 유형은 "resource_holder_footprint", 역할은 "resource_holder", 서비스는 "enterprise_network_footprint"다. 그 자체의 설명 문구를 그대로 인용하면 이렇다. "This records resource-holder context, not a connectivity-provider service claim." 등기부 모양의 발자국은 네트워크가 아니다. "발자국"이라는 단어를 읽고 이 파일에 케이블 인하, 용량 포지션, 유지보수 의무가 있다고 결론지어서는 안 된다.

새벽 세 시에 가림 처리된 우편함이 할 수 있는 일

연락처 절은 언뜻 보면 답처럼 보이는 부분이다. 공개 형태에는 alcatel.com 도메인의 가림 처리된 abuse 주소가 신뢰도 0.9로, 가림 처리된 전화번호 두 개가 0.9로, 그리고 ARIN 조직 객체와 ARIN 대량 파일을 가리키는 URL 연락처가 0.85로 들어 있다. 행 자체는 등기부 REST 서비스의 ARIN 연락 지점 기록에 대응한다. 그 기록의 식별 정보는 여기 옮기지 않는다.

연락처 절에 없는 것이 있는 것보다 흥미롭다. 네트워크 운영센터를 묘사한 곳은 없다. 에스컬레이션 매트릭스를 묘사한 곳은 없다. 장애 데스크를 묘사한 곳은 없다. 공개 연락처 주장 일곱 건, 그중 운영 서비스 연락처는 하나도 없다. 가림 처리된 abuse 주소는 선언된 특정 유형의 경로다. abuse 신고를 받는 투입구이며, 장애 데스크의 증거가 아니고, 이 기록은 그렇게 주장한 적도 없다.

그 뒤에 물리적 자산을 놓으면 결손은 구체적으로 바뀐다. 유지보수 계약을 갱신하려는 독자, 용량 값을 매기려는 독자, 새벽 세 시에 장애를 에스컬레이션하려는 독자가 종이에서 이 이름을 발견했을 때 등기부 계층에서 받는 것은 그룹 도메인의 가림 처리된 우편함, 신뢰도 0.9다. 새벽 세 시에 그것은 에스컬레이션 경로가 아니다. 대기열이다. 등기부는 물리적 자산의 책임 계층이 될 수 없다. 계약이 되어야 하며, 이 기록은 그 이유를 정밀하게 그린 지도다.

그 칸의 도메인은 실제 데이터 지점이고 해석은 한 문장이면 충분하다. 연락처 칸의 도메인은 등록 주체 또는 등기부 원본 파일이 연락 도메인으로 제공한 것이다. 소유나 모자 관계나 승계의 진술이 아니며, 그렇게 다루는 것이 바로 메일 접미사에서 회사 역사를 연역해 내는 길이다. 11월 4일 나는 도메인을 관계로 바꿔 줄 문서를 열지 못했다.

두 등기부, 한 이름, 다리 없음

BTW는 2026년 10월 21일 이 객체에 관한 브리핑을 발행했다(BTW, 두 등기부, 한 이름). 그것은 영국 회사 번호 01750343이 1983년 9월 6일 설립되었고 현재 ALCATEL SUBMARINE NETWORKS UK LTD로 영업하며 STC SUBMARINE SYSTEMS LIMITED를 과거 상호 가운데 하나로 기재하고 있다는 점, 그리고 ARIN 핸들 SSS-10이 별도로 "STC Submarine Systems, Inc."를 기록한다는 점을 담았다. 그 글의 결론은 상호 참조의 결손이지 운영 역량이 아니며, 나는 그것을 다시 논하지 않겠다. 다만 그것이 남긴 것을 짚겠다.

이번 실행의 기록에서 영국 회사 01750343과 미국 디렉터리의 이 항목을 잇는 문서는 하나도 없다. 이름의 유사성은 이름의 유사성일 뿐이다. 한 등기부에는 과거 상호가, 다른 등기부에는 조직 핸들이 있고, 그 사이에 우리 기록이 "unknown"이라고 적는 법인 형태가 놓여 있다. 이 핸들 위에 누가 있는지를 확립하는 것도 우리 기록에는 없다. 모회사도, 그룹도, 승계자도, 인수자도 없다. 이 업계에서 이십 년을 보낸 독자는 여기서 기억으로 회사 역사를 메울 것이고, 세상에 관해서는 대체로 옳을 것이다. 그러나 그는 이 기록을 읽는 것이 아니다. 이 기록이 말하는 것은, 한 이름이 서로 다른 법인 형태로 두 등기부에 살아남아 있고 우리가 가진 것 가운데 둘을 잇는 것은 아무것도 없다는 것이다.

그것은 스캔들이 아니다. 회사 이름이 주주보다 오래 살고 등기부가 등록자보다 오래 사는, 지극히 평범한 결과다. 동시에 실사 파일이 복사·붙여넣기로 해결할 수 없는 바로 그 사안이기도 하다.

수명주기는 needs_source_coverage에서 멈춘다

기록 자체의 수명주기는 "needs_source_coverage"에서 멈춘다. 그것은 사용 가능한 커버리지의 직전 상태다. 가장 먼저 나열된 데이터 결손은 원문 그대로 이렇다. "Verify STC Submarine Systems, Inc.'s legal entity country, current services, visible assets, parent or subsidiary links, and responsible public leadership contacts." 우리 디렉터리가 스스로에게 자기 말로 써 준 할 일 목록이며, 위의 모든 내용을 적절히 요약한다.

미리 밝힌 검증 조건

무엇이 이 기사를 바꿀지를, 누군가 찾으러 나서기 전에 적어 둔다. ASN 하나. 공고된 프리픽스 하나. 시설 기록 하나. 교환지점 존재 하나. 통제 관계 하나, 들어오거나 나가는 쪽. 사건 기록 하나. 도메인 또는 웹사이트 주장 하나. 날짜 있는 역량 진술 하나. 이 등록 주체에 귀속되는, 이름 있는 선박·조선소·정비 구역·컨소시엄 좌석 가운데 하나. 그중 하나라도 있으면 적어도 한 절이 0에서 벗어나고, 실체는 이름이기를 그치고 추적 가능한 표면을 가진 공급망 당사자가 된다.

혹은 더 깊은 기록이 그중 아무것도 주지 않는다면, 그 이름의 운영 역사는 오늘 그룹의 의무를 지고 있는 자에게 속한다. 다른 등기부의 다른 실체이고, 아마 찾을 수 있으며, 확실히 이 행은 아니다.

두 결말 모두 공개한다. 검증 조건을 미리 적는 이유가 그것이다. 나는 어느 방향으로도 승리를 선언하지 않는다. 지금의 기록은 아무것도 존재하지 않는다는 증거가 아니다. 우리가 가진 해상도에서 당신이 사고, 연결하고, 도움을 청할 모든 것이 미지라는 증거다.