ZEROSPACE Christian Wittenberg trading as Zerospace Cloud, 랙·트랜짓·수리 창에 의존하는 호스팅 용량 판매

요약

• RIPE RDAP은AS201801을 ZEROSPACE로 식별하고 이를 네덜란드 벨드호베이의 Zerospace Cloud로 거래하는 Christian Wittenberg와 연계하며, RIPEstat의AS 개요는 2026년 7월 15일 기준 해당 AS가 announced 상태라고 보고했습니다.
• 라우팅 자산은 작지만 가시적입니다:routing status는 IPv4 프리픽스 1개, IPv4 주소 256개, IPv6 /48 8개, 관측된 이웃 2개를 보여줬고,announced prefixes는 185.140.53.0/24와 가시적 IPv6 /48 8개를 나열했습니다.
• 경로 출처 위생은 강점입니다: RIPEstat은185.140.53.0/24와2a07:1a84::/48에 대해 유효한 RPKI를 반환했으며, IPv6 검증은 2a07:1a84::/44에 대한 ROA와 최대 길이 /48에 근거합니다.
• 운영 증거는 약합니다:PeeringDB에 Zerospace Cloud가 등재되어 있지만 공개 IX 수와 시설 수가 0이고,geofeed는 주소 슬라이스를 10개 도시 라벨에 매핑하지만 해당 도시의 현지 랙, 전력, 하드웨어, 지원 또는 고객 마이그레이션 역량을 증명하지 못합니다.

기업은 실제 네트워크 신원을 갖고 있지만, 그 신원은 신생입니다

소음으로부터 분리할 가치가 있는 첫 번째 사실은 Zerospace Cloud가 단순한 마케팅 문구가 아니라는 점입니다. RIPE RDAP(https://rdap.db.ripe.net/autnum/201801)은 AS201801을 ZEROSPACE로, 상태를 active로 등록하며 2026년 1월 30일 등록 이벤트와 2026년 3월 13일 최종 변경 이벤트를 기록합니다. 동일 RDAP 응답의 조직 항목은 네덜란드 벨드호베이를 공개 주소 라벨로 하는 Christian Wittenberg trading as Zerospace Cloud입니다. RDAP 응답은 또한 Zerospace Cloud Network Operations를 행정·기술 연락처로, Zerospace Cloud Abuse Department를 어뷰즈 연락처로 명명합니다. 소규모 클라우드·호스팅 제공자로서 이는 유용한 기반입니다: 이름이 명시된 조직, 네트워크, 운영 연락 역할이 존재합니다.

주소 기록은 AS 신원과 일치합니다. RIPE RDAP(https://rdap.db.ripe.net/ip/185.140.53.0/24)은 185.140.53.0~185.140.53.255를 ZEROSPACE-CLOUD로, assigned PA, 국가 NL, 상태 active로 식별하며 geofeed(http://download.zerospace.cloud/ipam/geofeed.csv)를 가리키는 remarks를 포함합니다. RIPE RDAP(https://rdap.db.ripe.net/ip/2a07:1a84::/44)은 2a07:1a84::/44를 ZEROCLOUD로, LIR에 의해 집계된(aggregated by LIR), 국가 NL, 상태 active로 식별하며 동일 조직과 동일 geofeed 참조를 둡니다. RIPEstat의 프리픽스 개요(https://stat.ripe.net/data/prefix-overview/data.json?resource=185.140.53.0/24)는 AS201801을 해당 IPv4 /24의 출처 보유자로 식별합니다.

이 기록들은 성숙한 호스팅 자산을 증명하지 않습니다. 살아있는 등록 자원을 보유한 현재의 경로 보유자임을 증명할 뿐입니다. 나이가 중요합니다. 자율 시스템과 IPv6 집합체는 2026년 1월 말에 등록되었고 IPv4 /24는 2026년 2월에 등록되었습니다. 고객은 공개 운영 증거가 아직 형성 중이라고 봐야 할 만큼 최신입니다. 신규 인프라 제공자는 유능할 수 있고, 라우팅·브랜딩·지원 프로세스·물리적 공급 계약이 아직 강화되는 단계에 있을 수도 있습니다. 올바른 질문은 AS201801이 존재하는지가 아닙니다. 존재합니다. 올바른 질문은 어떤 고객 서비스를 그 위에 안전하게 올릴 수 있는가입니다.

공개 경로 신호는 활성입니다. RIPEstat의 AS 개요(https://stat.ripe.net/data/as-overview/data.json?resource=AS201801)는 2026년 7월 15일 조회 시점에 보유자를 ZEROSPACE Christian Wittenberg trading as Zerospace Cloud로, AS를 announced로 보고했습니다. RIPEstat routing status(https://stat.ripe.net/data/routing-status/data.json?resource=AS201801)는 광범위한 공개 가시성을 보고했습니다: IPv4 RIS 피어 326개 중 324개, IPv6 RIS 피어 322개 중 322개가 해당 라우팅 공간을 보고 있었습니다. 이는 미사용 등록의 특징이 아니라 글로벌 라우팅 시스템에 가시적인 소규모 네트워크의 특징입니다.

인프라 구매자에게 라이브 경로 가시성은 필요하지만 충분하지 않습니다. 제공자는 임대 가상 서버, 리셀러 코로케이션, 단일 원격 지원 공급자 또는 소수의 업스트림에 의존하면서도 /24와 여러 IPv6 /48을 라우팅할 수 있습니다. 경로는 패킷이 announced 프리픽스를 찾을 수 있음을 보여줄 뿐입니다. 고객이 디스크 장애 후 교체 하드웨어를 받을 수 있는지, 시간 압박 속에서 대용량 데이터를 내보낼 수 있는지, 스토리지 고장에서 복구할 수 있는지, 전력 장애를 고칠 권한 있는 담당자에게 연락할 수 있는지는 보여주지 않습니다. 호스팅 용량은 프리픽스 뒤에 랙, 전력, 냉각, 하드웨어 재고, 접근 절차, 지원 커버리지와 탈출 경로가 있을 때에만 경로 가시성을 서비스로 전환합니다.

라우팅 자산은 작고, 가시적이며, 고르지 않게 광고됩니다

IPv4 그림은 콤팩트합니다. RIPEstat announced-prefixes 데이터(https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201801)는 2026년 7월 1일~7월 15일 창에서 185.140.53.0/24가 지속적으로 announced되었음을 보여줬습니다. Routing status는 이를 IPv4 프리픽스 1개, IPv4 주소 256개로 집계했습니다. 호스팅·클라우드 서비스에 /24는 운영적으로 유용할 수 있지만 작습니다. 집중된 anycast 유사 서비스, NAT 게이트웨이, 고객 관리 엔드포인트, 일부 VPS 노드 또는 제한된 수의 직접 할당 고객 주소를 지원할 수 있습니다. 그 자체로 대규모 컴퓨팅 자산의 증거는 아닙니다.

IPv6 그림은 주소 계산상 더 넓고 현재 가시성에서 더 미묘합니다. RDAP 기록은 16개의 /48을 담을 수 있는 2a07:1a84::/44를 커버합니다. PeeringDB의 네트워크 항목(https://www.peeringdb.com/api/net?asn=201801)은 프로필에 IPv4 프리픽스 1개, IPv6 프리픽스 16개를 나열합니다. 그러나 RIPEstat의 announced-prefixes 엔드포인트는 검토 창에서 8개의 IPv6 /48만 가시적이었습니다: 2a07:1a84::/48,:1::/48,:2::/48,:3::/48,:4::/48,:5::/48,:6::/48,:9::/48. RIPEstat의 AS 라우팅 일관성 뷰(https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201801)는 2a07:1a84::/44가 whois에는 있으나 BGP에는 없고, 여러 /48은 whois와 BGP 모두에 있으며, 다른 여러 /48은 whois에는 있으나 BGP에는 없다는 유용한 세부사항을 추가합니다.

이 차이는 설치된 용량과 사용 가능한 용량을 구분할 때 중요합니다. 설치된 주소 용량은 등록된 IPv6 /44와 PeeringDB가 명시한 16개 IPv6 프리픽스입니다. 사용 가능한 라우팅 용량은 해당 기간에 실제로 BGP에서 가시적인 부분집합입니다. 고객 사용 가능 용량은 더 좁습니다: 고객이 계약하고, 알려진 사이트로 라우팅하고, RPKI로 보호하고, 모니터링·지원하며, 제공자·시설·업스트림 장애 시 이동할 수 있는 프리픽스입니다. /44는 종이 위에서는 거대해 보일 수 있지만 공개 라우팅에서 활성인 /48은 일부뿐이고 프로덕션 서비스에 묶인 부분집합은 더 작습니다.

IPv6 타이밍도 활성 변화 중인 네트워크를 가리킵니다. RIPEstat은 2a07:1a84::/48과 2a07:1a84:5::/48을 7월 초부터 가시적으로 보여줬으며,:5::/48은 7월 3일과 5일 사이에 짧은 공백이 있었습니다. 다른 여러 /48은 2026년 7월 12일부터 가시성이 시작되었습니다. 이는 고객 영향을 미치는 의미의 불안정성을 증명하지 않습니다. 신규 IPv6 위치나 서비스 노드는 종종 파상적으로 온라인화됩니다. 다만 고객은 어느 /48이 프로덕션으로 간주되는지, 어느 것이 테스트·스테이징 할당인지, 어느 것이 도시 라벨에 묶여 있는지, 어느 것이 페일오버 테스트를 거쳤는지 물어야 합니다.

경로 출처 검증은 Zerospace 기록의 더 나은 부분 중 하나입니다. RIPEstat은 185.140.53.0/24(https://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=185.140.53.0/24)에 대해 출처 AS201801, 최대 길이 /24로 유효한 상태를 반환했습니다. 2a07:1a84::/48(https://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=2a07:1a84::/48)에 대해서는 최대 길이 /48을 가진 2a07:1a84::/44 ROA 기준으로 유효한 상태를 반환했습니다. RPKI는 서버를 가동 상태로 유지하지 않지만 경로 필터에 승인된 출처 announcement와 승인되지 않은 것을 구분할 방법을 줍니다. 신생 소규모 네트워크에는 이 위생이 중요합니다.

업스트림 그림은 가시적이지만 시설 그림은 아닙니다

업스트림 기록이 시설 기록보다 명확합니다. RIPEstat ASN 이웃(https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201801)은 관측된 이웃 2개, 즉 AS57758과 AS63473을 보여줬습니다. RIPEstat의 AS 개요는 AS57758을 CBWS Holding B.V., AS63473을 HostHatch, LLC로 식별합니다. whois 뷰(https://stat.ripe.net/data/whois/data.json?resource=AS201801)는 AS20473, AS63473, AS57758의 import·export 정책 항목도 나열하며, 공개 이웃 관측은 확인 시점에 AS57758과 AS63473을 보여줬습니다. AS20473은 RIPEstat의 AS 개요에서 The Constant Company, LLC이며 AS 이름에서 Vultr로 흔히 연계됩니다.

이것은 의존성 표면을 기술하기에 충분하지만 다양성을 인증하기에 부족합니다. 관측된 이웃 2개는, 고객 서비스 경로에서 실제로 독립적이고 별도 시설 또는 장애 도메인에 존재하며 고객 프리픽스 모두에 구성되어 있다면 하나보다 낫습니다. 그러나 두 ASN도 같은 건물, 같은 meet-me 룸, 같은 도시 파이버, 같은 전력 이벤트 또는 같은 원격 유지보수 창을 공유할 수 있습니다. 공개 BGP 데이터는 Zerospace 라우터가 한 랙에 있는지 여러 사이트에 있는지 알려줄 수 없습니다. 두 이웃이 모든 프로덕션 프리픽스를 운반하는지, 페일오버가 자동인지, 한 이웃이 백업 전용인지, 고객 컨트롤 플레인이 동일 물리 핸드오프에 의존하는지도 알 수 없습니다.

PeeringDB는 이 주의를 심화합니다. Zerospace Cloud 네트워크 기록(https://www.peeringdb.com/api/net?asn=201801)은 AS201801, 웹사이트https://zerospace.cloud, IRR as-set AS201801:AS-ZEROSPACE-CLOUD, IPv4 프리픽스 1개, IPv6 프리픽스 16개, policy_general Open, 상태 ok, 2022년 10월 생성 타임스탬프, 2026년 2월 8일 업데이트 타임스탬프를 나열합니다. 그러나 PeeringDB의 exchange LAN 엔드포인트(https://www.peeringdb.com/api/netixlan?asn=201801)는 공개 IX LAN 행을 반환하지 않았고, 시설 엔드포인트(https://www.peeringdb.com/api/netfac?net_id=31374)는 공개 시설 행을 반환하지 않았습니다. PeeringDB는 운영자가 유지하며 불완전할 수 있으므로, 빈 시설 목록은 시설 부재의 증거가 아닙니다. 공개 시설 증거가 부재하다는 증거입니다.

클라우드 구매자에게 시설 증거의 부재는 사소한 세부사항이 아닙니다. 시설은 경로 약속이 운영 약속으로 전환되는 곳입니다. 고객은 어느 데이터센터가 서버를 보유하는지, 어느 주체가 랙을 계약하는지, 어느 원격 지원 팀이 하드웨어에 접촉할 수 있는지, 이중 전력 피드가 있는지, 캐비닛이 계약 전력 한도 내인지, 냉각이 어떻게 공급되는지, 어느 크로스 커넥트가 어느 업스트림에 도달하는지 알아야 합니다. 공개 시설 목록이나 1차 시설 성명이 없으면 고객은 직접 물어보고 계약으로 검증해야 합니다.

Zerospace의 경우 geofeed는 글로벌인 반면 가시적인 공개 시설 증거가 비어 있어 특히 그렇습니다. Geofeed는 콘텐츠 로컬라이제이션, 부정 방지 통제, 지연 라우팅, 고객 기대치에 유용할 수 있습니다. 그러나 시설 성명을 대체할 수 없습니다. 제공자는 VM, 터널 엔드포인트, 리셀러 노드, 클라우드 인스턴스 또는 파트너 배치가 있는 도시에 작은 주소 블록을 지오로케이트할 수 있습니다. 이는 소유 랙, 예비 서버, 예비 광학, out-of-band 관리, 배터리 런타임, 발전기 커버리지 또는 현지 지원을 증명하지 않습니다.

Geofeed는 도시 라벨을 기술할 뿐, 보장된 현지 인프라가 아닙니다

Geofeed(https://download.zerospace.cloud/ipam/geofeed.csv)는 Zerospace 기록에서 가장 정보성이 높은 공개 아티팩트 중 하나입니다. 185.140.53.0/29를 암스테르담, 185.140.53.8/29를 런던, 185.140.53.16/29를 스톡홀름, 185.140.53.24/29를 서울, 185.140.53.32/29를 싱가포르, 185.140.53.40/29를 홍콩, 185.140.53.48~185.140.53.55의 일부 /32를 도쿄, 185.140.53.56/29를 시드니, 185.140.53.64/29를 뉴욕, 185.140.53.72/29를 로스앤젤레스에 매핑합니다. IPv6 /48도 동일한 도시 패턴으로 매핑합니다: 2a07:1a84::/48은 암스테르담,:1::/48은 런던,:2::/48은 스톡홀름,:3::/48은 서울,:4::/48은 싱가포르,:5::/48은 홍콩,:6::/48은 도쿄,:7::/48은 시드니,:8::/48은 뉴욕,:9::/48은 로스앤젤레스입니다.

이는 글로벌 용량 증명이 아니라 글로벌 서비스 영역 신호입니다. IPv4에서 대부분의 도시 항목은 /29, 즉 주소 8개씩입니다. 도쿄 IPv4 항목은 개별 /32 또는 매우 작은 그룹이며, geofeed는 /24의 모든 주소를 명시적 도시명으로 커버하지 않습니다. RIPEstat 지오로케이션(https://stat.ripe.net/data/geoloc/data.json?resource=185.140.53.0/24)과 MaxMind GeoLite 뷰(https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=185.140.53.0/24)는 유사한 분포를 반영했지만 조회된 뷰에서 IPv4 /24의 상당 부분이 도시 없는 스웨덴으로 표시되었습니다. 즉 공개 지오로케이션 그림은 혼재됩니다: 일부 주소 슬라이스는 정밀한 도시 라벨을 가지지만 IPv4 주소 공간의 상당 부분은 상세한 도시별 컴퓨팅 맵으로 제시되지 않습니다.

IPv6 위치 뷰도 신중한 해석이 필요합니다. RIPEstat 지오로케이션(https://stat.ripe.net/data/geoloc/data.json?resource=2a07:1a84::/44)과 MaxMind GeoLite 뷰(https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=2a07:1a84::/44)는 /44가 여러 도시 라벨의 /48로 분할되어 있고 집합체의 상당 부분이 도시 없는 스웨덴으로 나타남을 보여줬습니다. Geofeed는 시드니에:7::/48, 뉴욕에:8::/48을 나열하지만, announced-prefixes 엔드포인트는 이 검토 창에서 가시적인 8개 프리픽스에 그 /48들을 포함하지 않았습니다. 이것이 반드시 모순은 아닙니다. geofeed 항목은 의도되거나 등록된 지역을 기술하는 반면 라우팅 가시성은 시간에 따라 변할 수 있습니다. 지역성 주장은 현재 경로 상태와 묶여야 한다는 상기일 뿐입니다.

이 구분의 영향을 받는 고객은 해당 도시의 최종 사용자만이 아닙니다. 소규모 클라우드 제공자는 VPN 게이트웨이, 엣지 노드, 매니지드 호스팅, 개발자 워크로드, 백업 대상, 게임 인프라, 테스트 환경, 중소기업 서비스 또는 지역 접속 지점을 제공 중일 수 있습니다. 암스테르담 라벨 슬라이스가 실패하면 유럽 고객은 지연과 법적 위치에 관심을 가질 것입니다. 홍콩 또는 싱가포르 슬라이스가 실패하면 아시아·태평양 사용자는 더 긴 지연이나 다른 지역으로의 페일오버를 경험할 수 있습니다. 뉴욕 또는 로스앤젤레스 슬라이스가 현재 라우팅되지 않는다면, 북미 배치를 계획하는 고객은 그 위치가 라이브인지, 예약된 것인지, 일시 중지인지, 대기 중인지 알아야 합니다.

올바른 실사 질문은 "geofeed가 내 도시를 언급하는가?"가 아닙니다. "내 도시 라벨 주소를 어느 물리적 또는 가상 사이트가 제공하는가, 누가 그 사이트를 운영하는가, 어느 업스트림이 운반하는가, 그 뒤에 어떤 전력과 하드웨어가 있는가, 복구 또는 마이그레이션은 어떻게 이루어지는가?"입니다. 도시 라벨은 고객이 무엇을 물을지 결정하는 데 도움을 줄 수 있습니다. Zerospace가 10개 도시 모두에 소유 인프라를 보유한다는 증거로 사용되어서는 안 됩니다.

웹사이트와 DNS 기록은 별도의 가용성 의존성을 드러냅니다

메인 웹사이트도 고객 인프라와 분리해서 봐야 합니다. RIPEstat의 DNS-chain 엔드포인트(https://stat.ripe.net/data/dns-chain/data.json?resource=zerospace.cloud)는 zerospace.cloud가 Cloudflare 권한 네임서버 ali.ns.cloudflare.com과 rudy.ns.cloudflare.com을 사용하며, 2026년 7월 15일 조회 시점에 A 레코드 172.67.142.47, 104.21.87.70과 AAAA 레코드 2606:4700:3035::ac43:8e2f, 2606:4700:3036::6815:5746을 가짐을 보여줬습니다. download.zerospace.cloud의 DNS-chain 엔드포인트(https://stat.ripe.net/data/dns-chain/data.json?resource=download.zerospace.cloud)는 다운로드 호스트에 대해 동일한 Cloudflare 프런트 주소를 보여줬습니다. www.zerospace.cloud의 엔드포인트(https://stat.ripe.net/data/dns-chain/data.json?resource=www.zerospace.cloud)는 Cloudflare 권한 네임서버를 반환했으나www.zerospace.cloud의 포워드 레코드는 없었습니다.

2026년 7월 15일 직접 HTTPS 확인에서https://zerospace.cloud는 이 환경의 15초 curl 타임아웃 내에서 사용 가능한 페이지를 반환하지 않았습니다. 이전 Cloudflare 프런트 확인에서는 오리진이 Cloudflare에 응답하지 않을 때 522 유형의 오리진 도달성 실패가 나타날 수 있습니다. 일시적 HTTP 결과 하나에 의존하지 않더라도 DNS 증거는 공개 웹사이트 경로가 Cloudflare로 매개됨을 보여줍니다. 이는 흔하고 종종 합리적입니다. 그러나 이는 웹사이트 가용성이 AS201801의 경로 가용성과 동일하지 않음을 의미합니다.

여기에는 두 개의 별도 의존성이 있습니다. 첫째, Zerospace의 마케팅·컨트롤 웹 존재는 Cloudflare DNS와 프록시, 그리고 Cloudflare 뒤의 오리진 서비스에 의존합니다. 둘째, Zerospace의 라우팅된 고객 프리픽스는 AS201801, 그 업스트림 이웃, 그 프리픽스를 운반하는 물리적·가상 위치에 의존합니다. 구매자는 웹사이트가 Cloudflare 뒤에 있다고 해서 고객 트래픽이 Cloudflare 뒤에 있다고 추론해서는 안 됩니다. 또한 AS201801이 BGP에서 가시적이라고 해서 웹사이트 오리진 장애 중에도 고객 포털, 문서, 상태 통지, 지원 경로가 도달 가능할 것이라고 추론해서는 안 됩니다.

다운로드 호스트는 흥미롭습니다. 확인 당시 주 사이트가 읽을 수 있는 공개 서비스 페이지가 아니었음에도 geofeed를 제공했기 때문입니다. 이는 일부 Cloudflare 프런트 경로는 도달 가능하고 다른 경로는 아닐 수 있음을 시사합니다. 고객 운영 관점에서 질문은 중요 포털, 지원 양식, 컨트롤 패널, 상태 페이지, geofeed, API 엔드포인트가 독립적으로 호스팅되는지 동일 오리진 의존성을 공유하는지입니다. 유일한 고객 지원 경로가 취약한 오리진 뒤의 웹 양식이라면, BGP 경로가 유지되는 동안에도 네트워크 또는 오리진 장애가 복구를 지연시킬 수 있습니다.

웹사이트 증거는 외부인이 이용할 수 있는 1차 서비스 세부사항의 양도 줄입니다. 많은 제공자가 시설 페이지, 제품 약관, 서비스 수준 목표, 지원 절차, 데이터 내보내기 약관, 백업 정책, 법적 문서를 사이트에 게시합니다. 메인 사이트가 안정적으로 읽을 수 없다면 공개 실사는 레지스트리와 라우팅 증거에 더 크게 의존해야 합니다. 이는 네트워크 신원 기사로는 충분하지만, 확신 있는 호스팅 용량 구매로는 충분하지 않습니다.

물리적 의존성은 대부분 네트워크 계층 뒤에 숨겨져 있습니다

Zerospace의 공개 기록은 경로 자원을 주지만 완전한 물리 지도를 주지 않습니다. AS201801의 공개 PeeringDB 시설 행이 없습니다. 이 검토에서 메인 웹사이트에서 이용 가능한 공개 시설 페이지가 없습니다. 이용 가능한 증거에서 게시된 캐비닛 목록, 전력 밀도 성명, 냉각 설계, 원격 지원 공급자, 하드웨어 재고 정책, 백업 아키텍처, 상태 페이지 또는 마이그레이션 가이드가 없습니다. 그것들이 존재하지 않는다는 의미가 아닙니다. 공개적으로 증명되지 않았다는 의미입니다.

고객의 물리적 의존성 스택은 여전히 구체적입니다. Zerospace가 호스팅 용량을 판다면 일부 서버 또는 가상 인스턴스가 어딘가에 존재해야 합니다. 그 어딘가에는 랙 또는 호스트 머신, 전력 피드, 냉각 경로, 관리 네트워크, 업스트림 포트, 스토리지 의존성, 접근 절차가 있습니다. 디스크가 실패하면 누군가 또는 자동화가 교체하거나 워크로드를 이동해야 합니다. 라우터가 실패하면 두 번째 경로가 프리픽스를 운반해야 합니다. 캐비닛 차단기가 트립하면 그 캐비닛에 대한 계획이 있어야 합니다. 시설에 유지보수 창이 있으면 제공자는 어느 고객 서비스가 노출되는지 알아야 합니다. 도시 라벨 주소가 실제로 더 큰 클라우드 지역의 가상 엔드포인트라면 고객도 그것을 알아야 합니다.

전력과 냉각은 Zerospace 기록에서 가장 덜 가시적인 부분입니다. /24와 /44는 매우 적은 물리 인프라, 임대 가상 머신, 파트너 호스트 또는 소수의 코로케이션 서버에서 announce될 수 있습니다. 따라서 IP 주소의 수는 전력 여유에 대해 거의 아무것도 말하지 않습니다. 고객은 설치된 전력 할당, 이중화 후 사용 가능한 전력, 랙당 냉각 밀도, 시설의 UPS와 발전기 가정, 단일 고밀도 배치가 제공자의 현지 여유를 소진할 수 있는지 알아야 합니다. 그 정보 없이는 구매자가 도시 엣지 노드와 복원력 있는 호스팅 지역을 구분할 수 없습니다.

하드웨어 재고도 마찬가지로 불투명합니다. 제공자는 주소를 글로벌로 라우팅하면서도 제한된 호스트 풀에 의존할 수 있습니다. Zerospace가 VPS 또는 매니지드 서비스를 제공한다면 구매자는 각 위치 뒤에 몇 대의 프로덕션 호스트가 있는지, 스토리지가 로컬인지 공유인지, 장애 시 어떻게 대피하는지, 동일 위치에 예비 노드가 있는지, 교체 용량에 제3자 호스트 발주가 필요한지 물어야 합니다. 작은 IPv4 할당은 효율적인 주소 사용을 시사합니다. 공개 IP 희소성이 마이그레이션과 확장 계획에 영향을 줄 수 있음을 의미하기도 합니다.

지원은 네트워크 연락처 수준에서만 가시적입니다. RDAP은 네트워크 운영과 어뷰즈 역할을 명명하며, 이는 경로 운영과 어뷰즈 처리에 중요합니다. 그러나 고객 지원 시간, 에스컬레이션 수준, 인시던트 대응 목표, 유료 지원 등급, 언어, 티켓 도구, 긴급 권한은 보여주지 않습니다. 인프라 용량을 구매하는 고객은 네트워크 연락처의 존재를 바닥값으로 봐야지 지원 약속으로 봐서는 안 됩니다. 실제 복구 질문은 라우터 세션이 끊기거나, 호스트가 실패하거나, 도시 엔드포인트가 사라지거나, 고객이 단기간에 데이터를 대피해야 할 때 누가 행동할 수 있는가입니다.

장애 경로: 경로, 업스트림, 시설, 지원, 마이그레이션

첫 번째 장애 경로는 업스트림 도달성입니다. AS201801은 RIPEstat에서 관측된 이웃 2개(AS57758, AS63473)와 AS20473을 추가로 명명한 whois 정책 목록을 가졌습니다. AS57758 또는 AS63473이 세션을 잃으면 결과는 두 이웃이 영향받는 프리픽스를 모두 운반하는지, 트래픽 엔지니어링이 복귀 경로에 대해 충분히 대칭인지, 장애가 한 업스트림에 격리되는지에 따라 달라집니다. 두 세션이 같은 사이트에서 종료되거나 동일 로컬 핸드오프에 의존한다면 이중화는 ASN 수가 시사하는 것보다 덜 유용할 수 있습니다. 고객은 어느 업스트림이 각 프로덕션 프리픽스를 운반하고 그 세션이 어디에 살아 있는지 보여주는 경로 다이어그램을 요구해야 합니다.

두 번째 장애 경로는 경로 승인 또는 필터링입니다. RPKI는 IPv4 /24와 IPv6 /44~/48 패턴에 대해 유효합니다. 좋은 일입니다. 그러나 고객은 Zerospace가 경로 누수, 무효 announcement, 최대 길이 실수, 지오로케이션 드리프트를 모니터링하는지 물어야 합니다. 유효한 ROA도 제공자가 나중에 최대 길이를 넘는 더 구체적인 경로를 announce하거나, 업스트림이 예기치 않게 필터링하거나, 경로 승인 없이 도시별 /48이 추가되면 운영적으로 고통스러워질 수 있습니다. 현재 RPKI 상태는 긍정적 통제이지 변경 관리의 대체가 아닙니다.

세 번째 장애 경로는 시설 손실 또는 숨겨진 시설 집중입니다. PeeringDB가 공개 시설 행을 0으로 나열하기 때문에, 고객은 여러 도시가 여러 시설을 나타내는지, 한 업스트림 오버레이인지, 리셀러 자산인지 독립적으로 판단할 수 없습니다. 암스테르담 라벨 주소와 런던 라벨 주소가 모두 한 제공자 계정, 한 청구 관계, 한 원격 지원 팀 또는 한 터널 컨센트레이터에 의존한다면, 그 제공자 관계의 장애가 두 개 이상의 겉보기 지역에 영향을 줄 수 있습니다. 다중 도시 geofeed 항목은 독립적인 시설, 공급자, 라우팅 증거로 검증되어야 합니다.

네 번째 장애 경로는 컨트롤·지원 플레인입니다. 주 도메인의 Cloudflare 프런트 DNS, 비어 있는 www 레코드, 확인 당시 접근 불가한 메인 사이트는 장애 중 고객이 지원에 어떻게 도달하는지 아는 것이 얼마나 중요한지 가리킵니다. 고객 포털, 상태 통지, 문서, 지원 양식이 취약한 오리진을 공유한다면, 네트워크 문제가 전개되는 동안 제공자는 통신을 잃을 수 있습니다. 인프라 복구는 패킷만큼이나 연락 경로에 의존합니다. 구매자는 웹 양식뿐 아니라 out-of-band 인시던트 연락처를 요구해야 합니다.

다섯 번째 장애 경로는 마이그레이션입니다. 신규 네트워크는 변합니다. Zerospace의 2026년 등록 날짜, 2026년 7월 IPv6 가시성 변화, 도시 geofeed 구성은 아직 확장 또는 조정 중인 플랫폼을 시사합니다. 유망할 수 있지만 이탈 권리와 마이그레이션 경로를 필수로 만듭니다. 고객은 디스크 이미지, 스냅샷, 데이터베이스 덤프, 로그, DNS 레코드를 내보낼 수 있는지, 이동 중 IPv4 주소를 유지할 수 있는지, IPv6 /48 할당이 Zerospace 위치 내에서 이동 가능한지, 데이터 내보내기에 얼마나 걸리는지, 위치가 폐지되거나 재라우팅되면 무슨 일이 일어나는지 알아야 합니다.

설치 용량, 사용 가능 용량, 구매 용량은 서로 다릅니다

Zerospace 증거는 클라우드 용량이 세 계층을 가지는 이유를 보여주는 유용한 사례입니다. 설치 용량은 제공자가 소유 또는 통제한다고 합리적으로 주장할 수 있는 것입니다: AS201801, 185.140.53.0/24, 2a07:1a84::/44, 등록된 경로 정책, PeeringDB 프로필. 사용 가능한 네트워크 용량은 공개 라우팅에 나타나고 유효한 출처 승인으로 도달할 수 있는 것입니다: IPv4 /24 하나, 검토 창의 가시적 IPv6 /48 8개, 관측된 이웃 2개, 광범위한 RIPE RIS 가시성. 구매 용량은 고객이 계약 하에 실제로 소비할 수 있는 것으로, 컴퓨팅, 스토리지, 대역폭, 지원, 마이그레이션 약관이 붙습니다.

이 계층들 사이의 거리에 리스크가 숨습니다. 고객은 geofeed의 10개 도시를 보고 10개 프로덕션 지역이라고 가정할 수 있습니다. 증거는 그 가정을 지지하지 않습니다. PeeringDB의 16개 IPv6 프리픽스를 보고 16개 모두가 라이브라고 가정할 수 있습니다. RIPEstat은 이 창에서 8개 가시 /48만 보여줬고, 일부 whois 등재 /48은 BGP에 없었습니다. 관측된 업스트림 이웃 2개를 보고 경로 이중화를 가정할 수 있습니다. 그것은 두 이웃이 고객 프리픽스와 장애 도메인에 대해 독립적일 때만 참입니다. 유효한 RPKI를 보고 운영 복원력을 가정할 수 있습니다. RPKI는 경로 진정성에 도움을 주지 서버 수리에는 도움을 주지 않습니다.

이것이 Zerospace를 사용 불가하게 만드는 것은 아닙니다. 좁은 증거 모델로 구매해야 할 제공자로 만드는 것입니다. 작은 라우팅 서비스, IPv6 실험실, 엣지 실험 또는 비필수 호스팅 엔드포인트가 필요한 개발자는 상업 약관이 리스크와 일치한다면 공개 풋프린트로 충분하다고 느낄 수 있습니다. 프로덕션 워크로드, 고객 데이터, 결제 인접 시스템, 건강 데이터 또는 규제 기록을 이전하는 사업체는 공개 라우팅 증거 이상을 요구해야 합니다. 시설 세부사항, 지원 약속, 백업 분리, 고객 이탈 약관, 구매하는 도시 또는 지역이 실제로 라이브라는 증거를 요구해야 합니다.

공개 시설 행의 부재는 이중화 증명의 사고방식도 바꿉니다. 이중화는 도시 이름의 개수가 아닙니다. 두 개의 장애가 동일 원인을 공유하지 않는다는 증명입니다. Zerospace의 경우 그 증명은 최소한 다음을 보여야 합니다: 업스트림 독립성, 시설 독립성, 전력 독립성, 스토리지·백업 독립성, 관리 플레인 독립성, 지원 에스컬레이션 독립성. 하나라도 빠지면 라벨이 붙은 두 번째 지역도 첫 번째와 함께 실패할 수 있습니다.

설치 대 사용 가능 용량 구분은 가격에도 영향을 줍니다. 소규모 제공자는 유연하고, 저렴하고, 기술적으로 직접적이어서 매력적일 수 있습니다. 그러나 저가 오퍼는 대형 클라우드 구매자가 당연하게 여기는 예비 부품, 인력 시간, 트랜짓 여유, 백업 보존을 배제할 수 있습니다. 고객은 빠진 조각을 명시적으로 가격에 반영해야 합니다. 워크로드가 빠른 복구를 필요로 한다면 고객은 그 복구를 위해 지불하고 테스트해야 합니다. 워크로드가 공개 엔드포인트만 필요하고 다른 곳에서 재구축될 수 있다면 더 가벼운 서비스를 수용하고 자체 이식성을 유지할 수 있습니다.

데이터 지역성은 geofeed로 선언되지만 법적·운영적 지역성은 여전히 열려 있습니다

Geofeed는 데이터 지역성 신호를 주지만 데이터 주권 계약은 아닙니다. 지오로케이션 소비자에게 Zerospace가 주소 슬라이스를 어떻게 해석되길 원하는지 알려줍니다. 디스크가 어디에 놓이는지, 백업이 어디에 놓이는지, 어느 회사가 호스트를 운영하는지, 지원 인력이 어디에 있는지, 어느 법이 서비스를 지배하는지, 어느 하도급업체가 고객 데이터에 접근할 수 있는지는 말하지 않습니다. 이 구분은 암스테르담, 런던, 홍콩, 도쿄 또는 뉴욕을 컴플라이언스 또는 지연 성명으로 읽을 수 있는 유럽, 아시아·태평양, 북미 고객에게 필수적입니다.

유럽 고객에게 네덜란드 조직 기록과 주소 기록의 네덜란드 국가 코드는 유용하지만, 모든 고객 데이터가 네덜란드 또는 유럽 경제 지역에 머무른다는 것을 증명하지 않습니다. Geofeed 자체가 여러 슬라이스에서 유럽 밖을 가리킵니다. 아시아·태평양 고객에게 서울, 싱가포르, 홍콩, 도쿄, 시드니 라벨은 지연에 유용할 수 있지만, 데이터가 현지 처리되는지, 다른 국가를 통해 프록시되는지, 다른 곳에 백업되는지, 제3자 호스팅 공급자가 운영하는지 알아야 합니다. 미국 고객에게 뉴욕과 로스앤젤레스 라벨은 동일한 질문을 요구합니다.

가장 안전한 해석은 Zerospace가 주소 블록에 대해 네트워크 지역성을 선언했지 데이터 레지던시 보장을 선언하지 않았다는 것입니다. 고객은 호스팅 공급자 또는 시설 등급을 명명하고, 고객 데이터와 백업의 위치를 정의하고, 지원 접근 위치를 식별하고, 로그·스냅샷·내보내기가 어떻게 처리되는지 기술하는 지역별 약관을 요구해야 합니다. 서비스가 단순한 네트워크 오버레이 또는 소규모 엣지 존재라면 계약이 그렇게 명확히 말해야 합니다. Zerospace에 현지 물리 인프라가 있다면 계약이 운영 경계를 명시해야 합니다.

지역성은 장애 대응과도 교차합니다. 홍콩 라벨 주소가 홍콩의 파트너에 의해 제공된다면 수리 경로는 그 파트너의 지원 대기열에 의존할 수 있습니다. 글로벌 클라우드 제공자의 가상 노드로 제공된다면 수리는 그 제공자 계정과 지역 상태에 의존할 수 있습니다. 다른 위치의 터널을 통해 제공된다면 geofeed 라벨은 애플리케이션에는 유용하지만 물리적 독립성에는 유용하지 않습니다. 이 모델들이 자동으로 잘못된 것은 아닙니다. 중요한 것은 공시입니다. 고객은 도시 이름이 실제로 무엇을 의미하는지 모르면 도시 이름 주위에 복원력을 설계할 수 없습니다.

서비스가 실패하면 누가 영향을 받는가

영향받는 사용자는 Zerospace가 실제로 무엇을 파는지에 따라 달라집니다. 공개 증거는 클라우드·호스팅 스타일의 네트워크 신원을 지지하지만, 이곳에서 독립적으로 읽을 수 있는 제품 카탈로그를 게시하지 않습니다. 그러나 의존성 등급은 명확합니다. 호스팅 엔드포인트, VPS 인스턴스, 엣지 노드, VPN 게이트웨이, DNS 인접 서비스, 중소기업 사이트 또는 애플리케이션 백엔드에 Zerospace를 사용하는 고객은 경로 철회, 업스트림 장애, 서버 장애, 스토리지 손실, 지원 지연 또는 웹사이트·컨트롤 장애의 영향을 받습니다.

지역 최종 사용자는 geofeed 계층을 먼저 인지합니다. 암스테르담, 런던 또는 스톡홀름용 트래픽이 더 먼 위치로 이동하면 지연 민감 애플리케이션이 저하될 수 있습니다. 서울, 싱가포르, 홍콩 또는 도쿄 슬라이스가 불가능하면 아시아·태평양 사용자는 더 긴 경로 또는 서비스 실패를 경험할 수 있습니다. 뉴욕 또는 로스앤젤레스 슬라이스가 기대 시 라우팅되지 않으면 북미 사용자는 상업 설계에서 약속된 지역성을 얻지 못할 수 있습니다. 따라서 geofeed 맵은 용량을 증명하지 않더라도 기대를 만듭니다.

고객은 주소 희소성의 영향도 받습니다. 가시적 IPv4 /24가 하나뿐이므로 IPv4 할당은 유한 자원입니다. 고객이 더 많은 공개 IPv4 주소, 빠른 확장, 또는 다른 제공자로의 깨끗한 마이그레이션을 필요로 하면 제한된 IPv4 풀이 실질적 제약이 됩니다. IPv6는 더 풍부하지만 IPv6 도입은 여전히 고객의 사용자, 네트워크, 애플리케이션에 달려 있습니다. IPv6에서 잘 동작하는 서비스도 고객, 메일, 레거시 시스템 또는 제3자 통합을 위해 IPv4가 필요할 수 있습니다.

가장 노출된 고객은 복구 테스트 없이 Zerospace를 완전한 클라우드 플랫폼으로 취급하는 고객입니다. 서비스가 비필수 엣지 실험에 사용된다면 고객은 다른 곳에서 재구축할 수 있습니다. 주 데이터베이스, 고객 대면 프로덕션 서비스 또는 대체 불가 백업을 보유한다면 더 강한 증거가 필요합니다. 공개 기록은 AS201801을 기본적으로 성숙한 다중 지역 플랫폼으로 취급할 근거를 아직 충분히 보여주지 않습니다.

증거 등급을 높일 수 있는 것

Zerospace는 날짜가 표시된 인프라 성명을 게시하면 증거 등급을 빠르게 높일 수 있습니다. 가장 유용한 공개 성명은 소유 인프라, 임대 코로케이션, 가상화 노드, 파트너 위치를 구분하는 것입니다. Geofeed의 각 도시를 그곳의 배치 유형에 매핑하고, 해당 위치에서 고객 컴퓨팅이 가능한지 명명하고, IPv4와 IPv6가 모두 프로덕션인지 진술하고, 어느 업스트림이 각 프리픽스를 운반하는지 설명합니다. 민감한 세부사항을 밝힐 필요는 없습니다. 마케팅 지리를 운영 의존성에서 분리하면 됩니다.

다음 개선은 시설과 지원 증명입니다. PeeringDB 시설 행, 공개 상태 페이지, 고객 지원 페이지, out-of-band 긴급 연락처, 백업·복원 정책, 마이그레이션 또는 데이터 내보내기 가이드는 구매자 신뢰를 실질적으로 높입니다. 소규모 제공자도 모든 공급자 이름을 게시하지 않고 신뢰할 수 있습니다. 다만 호스트, 경로, 시설 또는 계정이 실패할 때 고객이 어떻게 복구하는지 보여줘야 합니다. 현재 공개 기록은 레지스트리와 BGP 증거에 크게 치우쳐 있습니다.

RPKI는 강점으로 유지되어야 합니다. Zerospace는 이미 검토된 IPv4와 IPv6 경로에 대해 유효한 경로 출처 승인을 갖습니다. 새 /48이 나타날 때 미래의 공개 증거는 그 규율을 유지해야 합니다.:7::/48과:8::/48이 라이브 도시 위치가 될 의도라면 경로 가시성과 검증이 geofeed와 일치해야 합니다. 일부 geofeed 항목이 예약 또는 계획이라면, 고객이 주소-위치 파일에서 프로덕션 지역성을 추론하도록 두지 말고 제공자가 그렇게 말해야 합니다.

증거 등급은 AS201801이 광범위한 경로 가시성을 잃거나, RPKI가 무효가 되거나, geofeed가 설명 없이 라우팅되지 않는 위치를 계속 광고하거나, 웹사이트가 별도 지원 경로 없이 간헐적으로 읽을 수 없는 상태가 되거나, 고객이 시설과 복구 세부사항을 얻지 못하면 낮아질 것입니다. 제공자가 단일 계정, 단일 시설, 단일 지원 대기열 또는 단일 업스트림 장애 도메인에 의존하면서 다중 지역 복원력을 판매하면 역시 낮아질 것입니다.

의존 운영자를 위한 결론

Zerospace Cloud는 실제 라우팅 네트워크로 취급할 만큼의 공개 증거를 갖지만, 입증된 글로벌 호스팅 플랫폼으로 취급할 만큼은 아닙니다. RIPE 기록은 AS201801, 185.140.53.0/24, 2a07:1a84::/44를 Christian Wittenberg trading as Zerospace Cloud와 묶습니다. RIPEstat은 광범위한 IPv4·IPv6 가시성과 함께 AS가 announced되었음을 보여줍니다. RPKI는 검토된 IPv4·IPv6 출처에 유효합니다. PeeringDB는 Zerospace Cloud 네트워크 항목을 나열합니다. Geofeed는 지리적 서비스 설계에 관한 진지한 질문을 지지할 만큼 상세하고 최신입니다.

주의점도 똑같이 명확합니다. IPv4 자산은 하나의 /24입니다. IPv6 가시성은 프로필과 /44가 시사하는 모든 /48이 아니라 검토 창의 8개 /48을 커버합니다. PeeringDB는 공개 시설 또는 IX 행을 보여주지 않습니다. 확인 당시 메인 웹사이트는 신뢰할 수 있는 서비스 세부사항 출처가 아니었습니다. Geofeed는 도시를 매핑하지만 그 도시의 랙, 전력, 냉각, 하드웨어, 지원, 마이그레이션 용량을 증명하지 않습니다. 현재 업스트림 그림은 관측된 이웃 2개를 보여주지만, 공개 라우팅 데이터는 독립적인 장애 도메인을 증명하지 않습니다.

실용적인 구매자는 구매하는 정확한 서비스에 대한 명시적 증거와 함께 Zerospace만 사용해야 합니다. 워크로드가 어디에서 실행되는지, 시설 또는 호스트를 누가 운영하는지, 어느 업스트림이 프리픽스를 운반하는지, 요청된 위치에서 IPv4와 IPv6가 모두 라이브인지, 전력과 하드웨어 장애가 어떻게 처리되는지, 웹사이트 장애 중 지원에 어떻게 도달하는지, 백업이 어떻게 분리되는지, 데이터를 어떻게 내보낼 수 있는지 물으십시오. Geofeed를 보장된 클라우드 지역의 맵이 아니라 주장된 주소 지역성의 맵으로 취급하십시오.

비필수 워크로드에는 공개 기록이 테스트를 정당화하기에 충분할 수 있습니다. 프로덕션 서비스에는 빠진 증거가 무시하기엔 너무 중요합니다. 호스팅 용량은 항상 물리적 의존성으로 귀결됩니다. Zerospace의 경우 공개 인터넷은 경로를 볼 수 있습니다. 고객은 여전히 그 뒤의 랙, 업스트림 독립성, 지원 권한, 마이그레이션 경로의 증명이 필요합니다.