서버 위의 계층들: 도메인, CDN, 트랜짓

서버가 어디에 있을지는 세 가지 결정 중 하나일 뿐이며, 결과를 좌우하는 결정인 경우는 드뭅니다. 서버 위에는 다른 누군가가 운영하는 이름(도메인)이 있습니다. 서버 앞에는, 대부분의 사이트의 경우, 또 다른 누군가가 운영하는 역방향 프록시가 있습니다. 이 둘 중 어느 쪽도 호스팅 업체의 정책에 구속되지 않고, 호스팅 업체의 사법 관할 안에도 있지 않으며, 둘 다 호스팅 업체에는 전혀 손이 닿지 않는 법원의 명령에 따라 움직일 수 있습니다. 이는 오프쇼어 호스팅이 다루지 않는 스택의 부분이며, 그것이 정확히 어디에서 멈추는지 알아 둘 가치가 있습니다.

세 계층, 세 개의 서로 다른 소유자

어떤 사이트든 접속이 가능하려면 적어도 세 개의 별개 사업자에 의존해야 하며, 이들은 서로 독립적으로 장애를 일으킵니다.

이름(도메인). 등록대행자가 그것을 고객님께 판매했고, 레지스트리가 그것이 속한 확장자를 운영합니다. 두 개의 회사, 대개는 두 개의 나라이며, 그중 두 번째는 고객님에 대해 들어 본 적조차 없습니다.

앞단. CDN, 역방향 프록시, 애니캐스트 엣지 등 고객님을 대신해 응답하는 무언가가 있다면, 그것은 방문자의 연결을 고객님의 서버가 보기도 전에 종료시킵니다. 따라서 그것은 구조상 오리진 주소를 알고 있으며, 신고를 받는 쪽도 바로 그것입니다.

회선과 머신. 호스팅 업체, 그 트랜짓 사업자, 시설, 그리고 서버가 속한 주소 대역입니다. 사람들이 비교하며 고르는 계층이 바로 이것이며, 셋 중 호스팅의 사법 관할이 실제로 규율하는 유일한 계층이기도 합니다.

버려야 할 습관은 이 셋을 하나의 구매로 여기는 것입니다. 이들은 셋이며, 이 셋을 한 손에 — 또는 하나의 법체계 안에 — 몰아넣는 것이야말로 명령 하나로 모든 것이 한꺼번에 무너지는 원인이 됩니다.

도메인: 등록대행자, 그리고 그 위의 레지스트리

등록대행자는 소매상입니다. 레지스트리는 그 확장자를 운영하는 도매상이며, 구매 전에 거의 아무도 확인하지 않는 계층입니다.

등록대행자를 움직이는 것

2024년 4월 5일부터, 인가받은 등록대행자는 ICANN이 DNS 어뷰즈라 부르는 것에 대응할 계약상 의무를 지게 되었습니다. 조치 가능한 증거를 확보하면, 이름을 무력화하는 데 합리적으로 필요한 완화 조치를 신속히 취해야 합니다. 이 규정에서 쓸모 있는 절반은 그 정의입니다. DNS 어뷰즈란 악성코드, 봇넷, 피싱, 파밍, 그리고 이들 중 하나의 전달 수단으로 쓰이는 스팸을 뜻합니다. 웹사이트 콘텐츠는 범위 밖이고, 저작권도 명시적으로 범위 밖입니다.

이를 위안이 아니라 문턱으로 읽으십시오. 이는 등록대행자가 움직일 의무를 지기 전에 신고가 어떤 형태를 갖춰야 하는지를 알려 줍니다. 동시에 그 목록 바깥의 모든 것은 법원이나 당국의 명령이라는 형태로 도착해야 한다는 것도 알려 줍니다 — 그리고 그 경로는 더 느리고, 확인 가능하고, 불복이 가능합니다. 두 사실 모두 고객님이 곧 받게 될 신고를 접수하기 전에 알아 둘 가치가 있습니다.

레지스트리가 할 수 있는 일, 그리고 그것이 놓인 자리

레지스트리는 단 하나의, 절대적인 지렛대를 가지고 있습니다. 고객님의 이름에 상태를 설정해 존에서 제외할 수 있다는 것입니다. 그러면 그 이름은 등록대행자가 무엇을 생각하든, 서버가 어디에 있든 상관없이, 어디에서도, 누구에게도 응답하지 않습니다. 호스팅 계층의 그 무엇도 이를 완화하지 못합니다. 호스팅 계층은 애초에 관여하지 않기 때문입니다.

이는 이론상의 이야기가 아닙니다. 2026년 6월, 텍사스주 지방법원은 .com을 운영하는 Verisign에 motherless.com을 레지스트리 보류 상태로 두라는 가압류 영장을 발부했습니다. 운영사는 텍사스주의 연령 확인법에 따른 텍사스 판결을 무시해 온 룩셈부르크 회사였습니다. 명령은 이름을 되찾기 위한 조건으로 미화 914만 달러의 보증금을 설정했습니다. 그 사이트는 텍사스에서 호스팅되지 않았고, 그 회사도 텍사스에 있지 않았습니다. 다만 이름이 .com 안에 있었고, .com은 미국 관할 아래 미국 회사가 운영합니다. 그것으로 충분했습니다.

여기서 얻을 일반적인 교훈은 그 사건 자체에 있지 않습니다. 고객님이 고르는 확장자는, 서버가 위치한 나라를 고르는 것과 똑같이, 하나의 사법 관할 선택이라는 것이며, 대부분의 사람은 이를 그저 습관적으로 고릅니다. 그 확장자를 누가, 어떤 법 아래에서 운영하는지, 그리고 그 법체계가 레지스트리에 명령을 내리는 관행이 있는지를 물으십시오. 그런 다음 고객님의 유일한 이름을 그곳에 두고 싶은지 결정하십시오.

이름에 대한 프라이버시는 지식이 아니라 공개에 관한 문제

WHOIS와 RDAP의 정보 비공개 처리는 대량 스크레이핑 봇과 가벼운 조회를 막아 줍니다. 그렇다고 등록대행자가 아무것도 모르게 되는 것은 아닙니다. 인가 조건상 등록대행자는 등록 데이터를 보유해야 하고, 다른 누구와 마찬가지로 법적 절차에 따라 그 데이터를 공개합니다. 기록 앞에 놓인 프라이버시 서비스는 방패가 아니라 공개 설정일 뿐입니다 — 반면 애초에 고객님께 아무것도 요구하지 않은 등록대행자는 가지고 있지 않은 것을 공개할 수 없습니다. 이는 전혀 다른 성질이며, 돈을 낼 가치가 있는 유일한 것입니다.

앞단의 프록시: 무엇을 지우고, 무엇을 전달하는가

CDN은 캐싱 중개자입니다. 사이트를 영구적으로 저장하지 않으므로, ‘파일을 내린다’는 것은 대개 CDN이 할 수 있는 일이 아닙니다. CDN이 할 수 있는 일은 프록시 역할을 그만두는 것입니다 — 그리고 접속 유지와 오리진 은닉을 프록시에 의존하는 사이트에게, 이는 테이크다운과 정보 공개가 한 번의 동작으로 동시에 일어나는 것과 같습니다.

더 흥미로운 것은 특별한 상황이 아니라 일상적인 동작이며, 가장 큰 제공업체는 이를 공공연히 공개하고 있습니다. 단순히 프록시만 해 주는 사이트에 대한 어뷰즈 신고를 받으면, 그 업체는 신고 내용을 웹사이트 운영자와 호스팅 업체에 전달하고, 문제가 된 콘텐츠의 오리진 IP 주소를 호스팅 업체에 제공합니다. 이 둘 다 그 업체 자신의 어뷰즈 정책에서 그대로 인용한 것이며, 구매자들이 돈을 내며 기대하는 바와는 정반대입니다.

즉 프록시는 고객님과 호스팅 업체의 어뷰즈 대응 부서 사이의 완충 장치가 아닙니다. 그것은 전달자입니다. 신고를 호스팅 업체까지 실어 나르고, 어느 머신을 봐야 하는지까지 정확히 알려 줍니다. 신고를 다루는 방식을 보고 호스팅 업체를 골랐다면 문제없습니다 — 신고는 고객님이 원했던 곳에 도착합니다. 신고가 프록시에서 멈추기를 바라며 프록시를 골랐다면, 그런 일은 일어나지 않습니다.

같은 업체의 문서는 고객님에게도 의무를 부과합니다. 실제로 관리되고 모니터링되는 어뷰즈 연락처를 유지할 것, 그리고 어떤 어뷰즈 신고 통지에도 24시간 안에 응답할 것입니다. 제때 응답하지 못하면 신고된 콘텐츠가 삭제되거나 차단될 수 있고, 계정이 정지되거나 해지될 수 있습니다. 고객님의 콘텐츠를 직접 내릴 수 없는 이 중개자가, 그럼에도 스스로에게 삭제 조항과 시계를 하나 써 넣은 셈입니다.

중요한 예외가 하나 있습니다. 같은 회사가 오브젝트 스토리지, 서버리스 플랫폼, 미디어·페이지 제품처럼 호스팅도 함께 제공하는 경우, 그 콘텐츠에 대해서는 그 회사가 호스팅 업체이며, 스스로도 그렇다고 밝히고 있고, 미국 법이 정한 형태의 반론 통지를 갖춘 notice-and-takedown 절차에 따라 콘텐츠를 삭제합니다. 한 업체의 두 제품이 완전히 다른 두 개의 답을 내놓는 셈입니다. 지금 실제로 어느 쪽을 쓰고 있는지 알아 두십시오.

CDN이 숨기지 못하는 것, 그리고 오리진이 발견되는 경로

많은 사람이 오직 한 가지 이유로 서버 앞에 프록시를 둡니다. 오리진 주소를 공용 인터넷에서 감추기 위해서입니다. 실제로 이것이 얼마나 잘 통하는지는 알아 둘 가치가 있으며, 솔직한 답은 이렇습니다 — 다섯 가지 흔한 실수 중 하나가 그것을 무너뜨리기 전까지는 통한다는 것입니다. 어느 것 하나 특별한 것이 없으며, 프록시 업체들 스스로가 이 실수들을 문서로 남겨 두고 있습니다.

프록시로 옮기기 전에 공개해 둔 레코드. DNS는 공개되어 있고 기록으로 남습니다. 프록시 뒤로 옮긴 사이트 거의 전부가, 이전 주소를 어딘가의 과거 데이터셋 안에 영구히 남겨 두고 있습니다. 업체 자신의 안내조차 온보딩 이후 오리진 주소를 바꾸라는 것입니다 — 바꾸지 않았다면, 그 이전은 겉모습만 바뀐 것입니다.

프록시를 거치지 않게 남겨 둔 레코드. 머신을 곧바로 가리키는 서브도메인 하나면 충분합니다. mail, ftp, cpanel, dev, staging, vpn, 한 번 설정해 두고 잊어버린 모니터링 호스트까지 말입니다. 기억나는 레코드만이 아니라 존 안의 모든 레코드를 점검하십시오.

머신을 떠나는 메일. 오리진이 메일을 보내면, 그 주소는 헤더에 실려 함께 이동합니다. 존재하지 않는 주소로 메일을 보내 보면, 반송 메일이 그 주소를 담고 돌아옵니다. 메일은 숨기려는 그 머신이 아니라 다른 머신에 맡겨야 합니다.

인증서 투명성. 공개적으로 신뢰되는 인증서는 모두 그것이 포괄하는 이름과 함께 로그에 남습니다. 그 로그는 주소를 직접 내주지는 않지만, 시도해 볼 서브도메인의 전체 목록을 — 고객님이 비공개라고 여겼던 것까지 포함해 — 그대로 내줍니다.

전면적인 스캐닝. 전체 주소 공간은 끊임없이 스캐닝되어, 무엇이 응답하는지에 따라 색인됩니다. 노출된 주소에서 제공되는 특징적인 페이지 하나는, 조사가 아니라 그저 데이터베이스 조회 한 번으로 찾아낼 수 있습니다.

해결책은 이미 잘 알려져 있으며, 편한 순서가 아니라 강도가 높은 순서대로 적용할 가치가 있습니다.

1. 아웃바운드 전용 터널. 오리진이 엣지로 향하는 연결을 직접 열고, 정작 자신은 아무 포트도 열어 두지 않습니다. 찾아낼 포트 자체가 없으므로, 주소가 유출되더라도 더 이상 흥미로운 정보가 되지 않습니다. 이 목록에서 규칙을 제대로 설정했는지에 의존하지 않는 유일한 선택지입니다.
2. 엣지 쪽 mTLS. 오리진은 프록시의 인증서를 제시하는 클라이언트에만 응답합니다. 주소는 유출될 수 있어도, 응답하지는 않습니다. 강력하며, 주소가 공개되어도 버텨 냅니다.
3. 프록시가 공개한 대역으로 방화벽 제한. 안 하는 것보다는 낫고 적용도 쉽지만, 그 대역은 바뀌며, 업체 자신의 비교 문서조차 이 방식이 스푸핑에 취약하다고 지적합니다. 해법이 아니라 최소한의 바닥으로 취급하십시오.
4. 기본 정리. 엣지 뒤로 들어간 뒤에는 오리진 주소를 바꾸고, 메일을 그 머신에서 내보내고, 변경할 때마다 프록시를 거치지 않는 레코드를 점검하십시오. 노출 사고 대부분은 정교한 공격이 아니라 이 세 가지 중 하나입니다.

프록시는 브라우저를 든 낯선 사람에게서 오리진을 감춰 줍니다. 프록시 자신에게서 오리진을 감춰 주지는 않습니다 — 프록시는 정의상 그것을 알고 있으며, 신고를 접수하면 호스팅 업체에 그것이 무엇인지 알려 주기로 되어 있기 때문입니다.

머신 아래: 트랜짓, 프리픽스, 시설

서버 아래에는 한 겹의 당사자들이 더 있으며, 호스팅 업체가 대개 가장 언급하고 싶어 하지 않는 이들이 바로 이들입니다.

트랜짓 사업자. 호스팅 업체는 누군가로부터 회선을 구매합니다. 그 트랜짓 사업자들은 각자 자기 나름의 어뷰즈 대응 부서, 계약, 위험 감수 수준을 가지고 있으며, 고객님을 골칫거리로 판단한 사업자가 호스팅 업체 대신 결정을 내려 버릴 수도 있습니다. 트랜짓 사업자가 몇 곳인지 물으십시오 — 하나뿐이 라면 정책의 단일 지점이자 장애의 단일 지점이기도 합니다 — 그리고 더 예리한 질문도 던지십시오. 호스팅 업체가 고객님의 트래픽에 대해 트랜짓 사업자 쪽의 차단 목록을 조용히 받아들이고 있지는 않습니까?

함께 쓰는 프리픽스. 평판 시스템은 고객이 아니라 주소 대역 단위로 작동합니다. 고객님은 이웃을 물려받으며, 그 이웃이 누구인지 듣지도 못한 채 물려받습니다. 이는 무엇이든 받아 주는 피난처를 자처하는 업체가 치르는 실질적인 대가입니다. 차단 목록은 그 대역 전체에 도달하고, 고객님의 메일과 API 호출도 그 대역 안에 있습니다.

시설과 하드웨어. 캐비닛을 임대한다는 것은, 호스팅 업체 위에 자기 나름의 어뷰즈 정책을 가진 임대인이 보이지 않게 자리 잡고 있다는 뜻이며, 호스팅 업체 위에 놓인 모든 층은 고객님이 결코 보지 못할 이유로 서비스를 종료할 수 있는 또 하나의 당사자입니다.

이 글의 목적이 각 계층에 책임을 묻는 것이므로, 저희 자신의 이 계층도 같은 기준으로 밝힙니다. 트랜짓 사업자 두 곳, BGP로 분산, 블렌디드 대역폭 20기가비트를 Chișinău로 들여옵니다. 모든 포트 앞단에서 전 고객에게 레이어3·레이어4 필터링을 제공하며, 별도로 구매할 것이 없습니다. 트랜짓 사업자 쪽 차단 목록은 고객 트래픽에 적용하지 않습니다. 무언가를 차단해야 한다면 법원이 그렇게 판단한 것이고, 저희는 고객님께 그 사실을 알립니다. 하드웨어는 임대가 아니라 소유이며, 한 나라 안에서, 고객님이 계약하는 바로 그 회사가 소유합니다 — 자세한 내용은 네트워크 페이지와 시설 페이지에서 확인하실 수 있습니다.

그리고 그 공백을 있는 그대로 말씀드리면, 저희는 도메인을 판매하지 않고, 고객님이 서버 앞에 두는 프록시도 운영하지 않습니다. 그 두 계층은 고객님의 몫입니다. 레지스트리와 신고 전달에 관해 앞서 설명한 모든 내용은 고객님에게 그대로 적용되며, 저희를 포함해 그 어떤 호스팅의 사법 관할도 그중 단 한 마디도 바꾸지 못합니다.

세 계층을 세 개의 서로 다른 손에 맡기기

이 글 전체는 몇 가지 결정으로 요약되며, 그중 어느 것도 비용이 들지 않습니다.

1. 세 계층, 세 공급자, 세 법체계. 이름, 엣지, 서버가 한 회사의 손안에 있다면, 명령 하나로 모든 것이 사라지기까지 딱 한 걸음입니다. 세 손에 나뉘어 있다면, 그중 하나를 겨눈 명령이 있어도 나머지 둘은 계속 작동하며, 고객님에게는 시간이 남습니다.
2. 모든 계층에 같은 세 가지 질문을 던지십시오. 무엇을 전달하도록 강제당할 수 있는지, 무엇을 삭제하도록 강제당할 수 있는지, 무엇을 공개하도록 강제당할 수 있는지 말입니다. 이 셋은 서로 독립적으로 무너지며, 세 질문 모두를 한 문장으로 답하는 공급자는 질문을 이해하지 못한 것입니다.
3. 프록시가 전달한다는 전제로 구성하십시오. 실제로 전달하기 때문입니다. 모든 신고가 오리진 주소까지 붙은 채 호스팅 업체에 도달한다고 가정하십시오. 그 결과가 문제라면, 해법은 호스팅 계층에 있거나 고객님이 공개하는 내용에 있습니다 — 중개자를 하나 더 추가하는 데 있지 않습니다.
4. 오리진을 제대로 닫으십시오. 아웃바운드 전용 터널이나 mTLS, 다른 머신에서의 메일 처리, 온보딩 이후 주소 교체, 프록시를 거치지 않는 레코드 점검. 네 가지 항목이며 하나같이 지루하지만, 실제 노출 사고의 거의 전부를 막아 줍니다.
5. 이름을 단일 장애 지점으로 간주하고 대비하십시오. 어느 레지스트리가 어떤 법 아래에서 고객님의 확장자를 운영하는지 알아 두십시오. 다른 확장자로, 다른 등록대행자에게, 두 번째 이름을 하나 더 확보해 두고, 사람들에게 그것을 어떻게 안내할지 미리 정해 두십시오.

이상의 어느 것도 서버 앞에 프록시를 두는 것에 반대하는 논거가 아니며, 오프쇼어 호스팅에 반대하는 논거도 아닙니다 — 저희가 그런 주장을 펼 리도 없습니다. 이 글이 말하는 것은, 세 계층이 세 개의 별개 구매이며 세 개의 별개 실패 방식을 갖는다는 것, 그리고 사람들이 가장 꼼꼼히 따지는 계층이 가장 큰 위협이 되는 계층은 아니라는 것입니다. 저희가 실제로 운영하는 계층도 같은 기준으로 검증하고 싶으시다면, 분기별 수치와 법 집행기관 페이지에서 확인하실 수 있습니다.

이 플랫폼을 운영하는 엔지니어들이 작성했으며, 오늘에 다시 검토했습니다. 여기 내용 중 잘못되었거나 오래된 부분이 있다면 고객 패널을 통해 알려주십시오 — 실제로 이 중 절반가량이 그렇게 접수된 내용입니다.