IP 주소 차단으로 인한 의도하지 않은 결과

지난 8월, Cloudflare의 고객 지원 팀은 당사 네트워크에 위치한 사이트가 오스트리아에서 다운된다는 불만을 접수했습니다. 외부에서 보기에 오스트리아의 인터넷이 부분적으로 중단되는 문제의 원인을 파악하기 위해 Cloudflare 팀은 즉시 조치를 취했습니다. 팀에서는 오스트리아 현지 인터넷 서비스 공급자에 문제가 있었음을 빠르게 알아낼 수 있었습니다.

하지만 서비스 중단은 기술적인 문제로 초래된 것이 아니었습니다. 이후 언론 보도를 통해 확인된 바와 같이, 이 상황은 법원 명령에 따른 결과였습니다. 오스트리아 법원에서 Cloudflare에 아무런 고지 없이 Cloudflare의 IP 주소 11개를 차단하라고 오스트리아 인터넷 서비스 공급자(ISP)에게 명령했던 것입니다.

저작권을 침해한다고 저작권자가 주장한 웹 사이트 14곳을 차단하려는 시도로 법원에서 IP를 차단하라고 명령한 결과로, 평범한 오스트리아 인터넷 사용자들은 꼬박 이틀 동안 웹 사이트 수천 곳을 이용할 수 없었습니다. 이 수천 곳의 사이트에서 무언가를 잘못했을까요? 전혀 아닙니다. 인터넷의 실제 아키텍처를 반영하는 법적 구제 방법 및 체계가 구축되지 않아 이러한 사이트에서 일시적으로 피해를 입었습니다.

오늘은 IP 차단이 일어나는 이유, 정의, 역할, 영향을 미치는 대상, 온라인에서 콘텐츠를 다루는 데 적절하지 않은 방식인 이유 등 IP 차단에 대해 다루려고 합니다.

가장 말도 안 되는 부분은 이러한 유형의 차단이 전 세계에서 정기적으로 발생한다는 점입니다. 하지만 오스트리아의 경우처럼 대규모로 발생하거나 누군가가 상황을 조명하려 하지 않는 한 일반적으로 외부에서는 잘 보이지 않습니다. 심도 깊은 기술 전문 지식을 갖추고 차단 작동 원리를 이해하는 Cloudflare조차도 IP 주소가 차단된 경우를 일상적으로 확인할 수는 없습니다.

인터넷 사용자에게는 이는 더욱 불분명합니다. 일반적으로 인터넷 사용자는 특정한 웹 사이트에 왜 연결이 안 되는지, 연결 문제가 어디서 발생했는지, 어떻게 해결할 수 있는지 모릅니다. 방문하려 했던 사이트에 액세스할 수 없다는 사실만 알 뿐입니다. 그래서 IP 주소 차단으로 인해 사이트에 액세스할 수 없게 되었을 때, 이를 기록하기는 더 어려울 수 있습니다.  

차단 관행 역시 만연합니다. Freedom House는 최근 인터넷 자유(Freedom on the Net) 보고서를 통해, 조사에 포함된 70개국 중 러시아, 이란, 이집트부터 영국과 독일 등 서구 민주주의 국가에 이르기까지 40여 개의 여러 국가에서 어떠한 형태로든 웹 사이트 차단을 수행했다고 보고했습니다. 이 보고서에서 이들 국가의 차단 방식을 정확하게 조사하지는 않았지만, 대부분은 IP 차단의 형태를 이용했으며 오스트리아에서 확인되었던 부분적 인터넷 중단 상황과 같은 유형의 영향을 미칠 가능성이 있습니다.

IP 차단으로 인한 부수적 피해를 입은 정도를 평가하기는 어렵겠지만, 조직에서 이를 정량화하려고 시도했던 예가 있습니다. 슬로바키아에 위치한 비영리 단체 EISi(European Information Society Institute)에서는 유럽인권재판소에 제소된 사건과 관련해 2017년에 웹 사이트를 차단했던 러시아 정권을 검토했습니다. 러시아는 IP 주소만을 사용해 콘텐츠를 차단했습니다. EISi는 이 IP 차단으로 "부차적인 대규모 웹 사이트 차단"이 발생했다고 결론을 내렸으며, 2017년 6월 28일 기준 "6,522,629개의 인터넷 리소스가 차단되어 있으며, 97%인 6,335,850개는 부차적으로, 즉 법적 근거 없이 차단되었다."고 언급했습니다.

영국에서는 지나친 차단으로 인해 비영리 단체 ORG(Open Rights Group)가 Blocked.org.uk라는 웹 사이트를 만들게 되었습니다. 이 웹 사이트에는 사용자와 사이트 소유자가 과도한 차단을 보고하고 ISP에 차단을 해제하도록 요청할 수 있는 도구가 있습니다. 이 그룹에는 자선 단체부터 소규모 자영업자에 이르기까지, 웹 사이트가 부당하게 차단된 이들에게 차단이 어떤 영향을 미쳤는지 알리는 수백 가지 개별 사례도 있습니다. 차단에 이용되는 방법이 언제나 명확하지는 않지만, 이러한 사이트가 필요하다는 사실은 과도한 차단의 양이 상당함을 보여줍니다. 웹 사이트를 이용해 서비스를 광고하고 새로운 고객을 확보하려는 재봉사, 시계 기술자, 자동차 판매업자를 생각해보세요. 현지 사용자가 사이트에 접속할 수 없다면 의미가 없습니다.

"제한된 사이트가 제한되지 않는 사이트와 주소를 공유하는 일이 없도록 하면 된다"고 반응할 수도 있습니다. 더 자세히 살펴보겠지만, 이러한 반응은 나타날 수 있는 도메인 이름의 수와 이용 가능한 IP 주소의 수가 크게 차이난다는 점을 무시하고 있으며 인터넷을 구동시키는 바로 그 기술 규격에 위배됩니다. 뿐만 아니라 국가, 커뮤니티, 조직에 따라 제한과 비제한 기준이 다르게 정해져 있습니다. 모든 제한 사항을 파악할 수 있다고 하더라도, 인터넷의 프로토콜, 인터넷 그 자체의 설계 때문에 모든 기관의 제한 사항을 충족하기란 불가능하지는 않더라도 실현하기 어렵습니다.

과도한 웹 사이트 차단은 사용자에게만 문제가 되는 것은 아닙니다. 법적인 함의도 있습니다. 웹 사이트 차단은 온라인으로 권리를 행사하려는 일반 시민에게 영향을 미칠 수 있으므로, 정부 기관(법원과 규제 기관 모두)의 명령은 필요하면서도 비례적이어야 하며, 피해의 원인에 기여하지 않는 이들에게 불필요한 영향을 미쳐서는 안 된다는 법적 의무가 있습니다.

예를 들어, 법원이 범법 혐의에 응해 주소지에 하나의 가정집이 있는지, 6가구가 있는 콘도 건물이 있는지, 별도의 수백 가구로 이루어진 고층 건물이 있는지 생각하지도 않고 거리 주소만으로 무턱대고 수색 영장이나 명령을 발부하는 일은 상상하기 어렵습니다. 하지만 IP 주소의 경우에는 이러한 관행이 만연한 것으로 보입니다.  

2020년, 유럽평의회의 유럽 인권 조약 이행을 감독하는 재판소인 유럽인권재판소(ECHR)는 러시아 정부의 표적이 되어서가 아니라, 차단된 웹 사이트와 IP 주소를 공유한다는 이유로 러시아에서 차단된 웹 사이트와 관련한 사건을 심리하였습니다. 웹 사이트 소유자는 이러한 차단에 대하여 소송을 제기했습니다. ECHR에서는 합법적인 사이트 콘텐츠에 대한 차단이 “해당 웹 사이트 소유자의 권리에 대한 자의적 간섭에 해당한다”는 판결을 내리며 무분별한 차단은 용인할 수 없다고 결론지었습니다. 즉, ECHR은 정부에서 목표로 삼지 않은 사이트가 차단되도록 명령을 내린 것은 부적절했다는 판결을 내린 것입니다.

인터넷 사용자는 대체로 온라인으로 액세스하려는 콘텐츠가 어떻게 전달되는지 별로 생각하지 않습니다. 브라우저에 도메인 이름을 입력하면 콘텐츠가 자동으로 뜰 거라 생각합니다. 콘텐츠가 자동으로 뜨지 않을 때는, 전체 인터넷 연결이 끊어지지 않은 한 웹 사이트 자체에 문제가 있다고 가정하곤 합니다. 하지만 이와 같은 기본 가정에서는 온라인에서의 콘텐츠 액세스를 제한하는 데 웹 사이트 연결이 자주 이용된다는 현실이 고려되지 않습니다.

국가에서는 왜 웹 사이트 연결을 차단할까요? 온라인 도박이나 성인용 자료와 같이 불법 콘텐츠라 여기는 사이트에 국민들이 액세스하지 못하도록 제한하려는 것일 수 있습니다. 이는 세계 어디에서든 용인됩니다. 국가에서 허위 정보가 대부분이라고 여기는 외국 뉴스원을 볼 수 없게 막으려고 할 수도 있습니다. 아니면 지적 재산권이 침해되고 있다고 여겨 웹 사이트 액세스를 차단하고 콘텐츠 확인을 제한하려는 저작권자를 지원하려는 것일 수도 있습니다.

분명히 얘기하자면, 액세스 차단은 인터넷에서 콘텐츠를 삭제하는 것과 같지 않습니다. 불법 콘텐츠를 실제로 제거하도록 허용하기 위해 고안된 법률상 의무와 권한은 다양합니다. 실제로 다수 국가에서의 법적 기대에 따르면, 차단이란 소스에서 콘텐츠를 삭제하려고 시도한 다음에 시행하는 마지막 수단입니다.

차단은 차단하는 ISP를 이용해 인터넷에 액세스하는 특정한 조회자가 웹 사이트에 액세스할 수 없게 방지할 뿐입니다. 사이트 자체는 계속 온라인에 존재하며 차단된 사람 외에는 누구나 액세스할 수 있습니다. 하지만 콘텐츠가 다른 위치에서 생성되어 쉽게 삭제할 수 없는 경우라면 국가에서 최선의 방법 또는 유일한 방법으로 차단을 고려할 수도 있습니다.

때로 국가에서 차단을 시행하도록 만드는 우려 사항이 있음을 우리는 잘 알고 있습니다. 하지만 근본적으로는, 액세스하려는 웹 사이트가 언제 차단되었는지, 볼 수 없게 차단한 사람은 누구이며 왜 차단했는지를 가능하다면 최대한으로 사용자가 알아야 한다고 우리는 생각합니다. 그리고 타인의 권리를 침해하지 않도록 콘텐츠 제한을 최소화하여 피해를 해결하는 게 중요합니다.

IP 주소 차단을 무차별적으로 시행한다면 그럴 수 없습니다. 이는 인터넷 사용자가 완전히 파악할 수 없는 관행입니다. 이 관행은 다른 콘텐츠에 의도하지 않았지만 불가피한 결과를 초래합니다. 그리고 인터넷 구조 자체로 인해, IP 차단 이전이나 차단하는 와중에 어떤 웹 사이트가 영향을 받을 수 있을지 제대로 파악할 방법이 없습니다.

단순히 IP 주소만으로 콘텐츠를 차단하다가 오스트리아에서 일어났던 상황과 전 세계 여러 국가에서 일어나고 있는 상황을 이해하려면 그 이면을 이해해야 합니다. 기술적인 세부 사항 몇 가지를 알아봐야 한다는 것입니다.

차단의 기술적인 현실을 설명하기 전에, 콘텐츠를 처리할 때는 소스에서 처리하는 것이 최우선이며 가장 좋은 선택지라는 점을 강조하는 것이 중요합니다. 웹 사이트 소유자나 호스팅 공급자는 웹 사이트 전체를 중단시키지 않고도 세부적인 수준에서 콘텐츠를 삭제하도록 선택할 수 있습니다. 더 기술적인 측면에서 보자면, 도메인 이름 등록 기관이나 레지스트리에서는 인터넷에서 도메인 이름과 그에 따른 웹 사이트를 완전히 중단시킬 수 있습니다.    

하지만 어떠한 이유로든 콘텐츠 소유자나 콘텐츠 출처에서 인터넷에서 콘텐츠를 삭제할 수 없거나, 삭제할 의사가 없다면 어떻게 웹 사이트 액세스를 차단할 수 있을까요?  가능한 제어점은 세 곳뿐입니다.

첫 번째는 도메인 네임 시스템(DNS)을 통하는 것입니다. DNS는 사이트를 찾을 수 있도록 도메인 이름을 IP 주소로 바꿉니다. DNS 확인자는 도메인 이름에 유효한 IP 주소를 반환하는 대신, "이와 같은 이름은 없다"는 의미로 NXDOMAIN 코드를 허위로 응답할 수 있습니다. 2020년에 표준화된 순수한 오류 번호 하나를 사용하는 것이 더 나은 방법일 수도 있습니다. 현재 폭넓게 사용되지는 않지만, 오류 번호에는 차단을 나타내는 오류 15, 검열을 나타내는 오류 16, 필터링을 나타내는 17, 금지를 나타내는 18 이 있습니다.

흥미롭게도, 제어점으로서 DNS의 정확성과 효율성은 DNS 확인자가 비공개인지 공개인지 여부에 따라 달라집니다. 비공개 또는 '내부' DNS 확인자는 ISP와 엔터프라이즈 환경에서 알려져 있는 자체 클라이언트를 대상으로 운영하므로, 운영자가 콘텐츠 제한을 정확하게 적용할 수 있습니다. 반면에 개방형 또는 공개 확인자는 이 정도로 정밀할 수 없습니다. 특히, 고정된 우편 지도나 거리 지도 상의 주소 및 경로와는 대조적으로 인터넷 지도에서의 라우팅 및 주소 지정은 전역적이고 끊임없이 변화하기 때문입니다. 예를 들어서, 비공개 DNS 확인자는 지정된 지리적 영역 내에서 최소한의 정확도 수준으로 웹 사이트 액세스를 차단할 수 있습니다. 이는 공개 DNS 확인자는 할 수 없는 방식입니다. 전 세계의 이질적인(일관성도 없는) 차단 체제를 고려하면 이는 매우 중요합니다.

두 번째 방식은 제한된 도메인 이름에 대한 개별 연결 요청을 차단하는 것입니다. 사용자나 클라이언트가 웹 사이트를 방문하려 할 때는 클라이언트에서 서버 이름, 즉, 도메인 이름으로 연결이 시작됩니다. 네트워크나 경로상 장치가 서버 이름을 확인할 수 있으면 연결을 종료하는 것입니다. DNS와 달리 서버 이름에 대한 액세스가 차단되었다는 사실이나 그 이유를 사용자에게 알리는 메커니즘은 없습니다.

세 번째 방법은 도메인 이름을 확인할 수 있는 IP 주소 액세스를 차단하는 것입니다. 이는 물리적인 하나의 주소로 향하는 모든 우편물 배달을 차단하는 것과 비슷합니다. 예를 들어, 그 주소에 서로 관련이 없고 독립적인 거주자가 많은 고층 건물이 있다고 생각해보세요. 이 고층 건물 주소로 오는 우편물 배달을 중단하면 이 주소에 있는 모든 대상에게도 예외 없이 영향을 미치므로 부차적인 피해가 발생합니다. IP 주소도 똑같이 기능합니다.

특히 IP 주소는 세 가지 선택지 중에서 유일하게 도메인 이름과 연결되지 않습니다. 데이터 패킷을 라우팅하고 전달하는 데에는 웹 사이트 도메인 이름이 필요하지 않습니다. 실제로는 완전히 무시됩니다. 어떤 IP 주소든 웹 사이트를 구동할 수 있으며, 심지어 동시에 여러 IP 주소에서 구동할 수도 있습니다. 웹 사이트가 위치한 IP 주소 세트는 언제든 바뀔 수 있습니다. DNS 쿼리로는 IP 주소 세트를 명확하게 알 수 없습니다. 1995년 이후 DNS는 언제든, 무슨 이유로든, 모든 유효한 주소를 반환할 수 있습니다.

주소가 신원을 나타낸다는 개념은 인터넷 설계와 완전히 반대됩니다. 다음에서 설명하는 내용처럼 이름에서 주소를 분리하는 것은 인터넷 표준과 프로토콜에 깊이 뿌리 내렸기 때문입니다.

IP 주소가 하나의 웹 사이트를 나타낸다고 잘못 생각하는 사람들이 아직도 많습니다. 초기에 연결된 인터넷 구성 요소가 하나의 컴퓨터, 하나의 인터페이스, 하나의 주소, 하나의 이름으로 형성되었다는 점을 감안하면 이름과 주소의 연관성을 이해할 수 있다는 설명을 이전에 드렸습니다. 이와 같은 일대일 연관성은 인터넷 프로토콜이 배포된 생태계의 산물이었고, 당시의 요구 사항에 잘 맞았습니다.

일대일로 명명하는 인터넷 초기의 관행에도 불구하고, 언제나 서버(또는 ‘호스트’)에 둘 이상의 이름을 할당할 수 있었습니다. 예를 들어 서버는 ‘mail.example.com’, ‘www.example.com’과 같이 제공하는 서비스를 반영하는 이름으로 구성되는 경우가 (지금과 마찬가지로) 많았는데, 기본 도메인 이름은 공유되었습니다. 완전히 다른 웹 사이트를 하나의 서버에 함께 배치해야 하는 경우가 아니라면 도메인 이름이 완전히 달라야 할 이유가 거의 없었습니다. 이 관행은 호스트 헤더(HTTP/1.1 표준)로 인해 1997년에 더 간편해졌습니다. 이는 2003년 TLS 확장에서 SNI 필드에 남은 기능입니다.

이러한 변화가 일어나는 동안 인터넷 프로토콜, 그리고 DNS 프로토콜은 별개의 프로토콜로서 속도를 맞춰왔을 뿐만 아니라 근본적으로는 바뀌지 않은 채로 남아있었습니다. 이러한 이유로 인터넷이 규모를 커지고 발전될 수 있었습니다. 주소, 연결, 임의의 이름과 IP 주소와의 관계를 다루기 때문입니다.

마찬가지로 IP와 DNS의 설계도 완전히 독립적이므로, 이름과 주소가 별개라는 개념이 강화되었습니다. 프로토콜 설계 요소를 면밀히 살펴보면, IP 주소를 차단해 콘텐츠 액세스를 제어하는 오늘날의 일반적 관행을 야기하는 정책이 오해에서 비롯되었음을 명확하게 밝힐 수 있습니다.

대규모 토건 프로젝트가 건축법과 모범 관행에 의존하는 것처럼, 인터넷도 경험을 통해 전달되고 국제적 합의가 이루어진 일련의 공개 표준과 규격을 이용해 구축됩니다. 하드웨어와 애플리케이션을 연결하는 인터넷 표준은 국제 인터넷 표준화 기구(IETF)에서 “의견 요청서”, 즉 RFC의 형식으로 공개합니다. 불완전한 상태를 나타내려는 게 아니라 지식과 경험을 통해 표준을 발전시킬 수 있어야 한다는 점을 반영하여 이러한 이름이 붙었습니다. IETF 및 RFC는 1969년에 공개된 첫 번째 RFC와 같은 예시를 통해 통신 구조 자체에 자리를 확고히 잡았습니다. 1981년에 인터넷 프로토콜(IP) 규격은 RFC 상태에 도달했습니다.

표준 기구와 더불어, 마찬가지로 1981년에 규정되고 몇 년 간의 시행착오 경험에 기반한 핵심 아이디어인 엔드투엔드(e2e) 원칙의 도움으로 인터넷은 성공할 수 있었습니다. 엔드투엔드 원칙은 형식이 다양함에도 불구하고 인터넷 프로토콜 규격의 핵심 개념을 강력하게 나타냅니다. 네트워크는 연결을 설정해야 할 책임만 있고 존재할 수 있는 다른 기능에는 비용이나 위험이 있다는 개념입니다.

인터넷 프로토콜의 “연결” 개념은 IP 주소 자체의 설계에도 반영되어 있습니다. 인터넷 프로토콜 규격인 RFC 791을 살펴보면, 다음의 섹션 2.3 발췌 내용에는 IP 주소가 이름, 인터페이스 등 그 무엇과도 연관되지 않는다는 것이 명시되어 있습니다.

실제 세계에서 고층 건물의 우편 주소와 흡사하게, IP 주소도 종이에 적힌 거리 주소에 불과합니다. 그리고 종이에 적힌 거리 주소의 경우처럼 IP 주소에 위치한 엔티티나 조직을 확신할 수는 없습니다. Cloudflare와 같은 네트워크에서는 하나의 IP 주소가 서버 수천 개를 나타내며, 경우에 따라 수백만 개에 달할 정도로 많은 웹 사이트와 서비스를 나타낼 수도 있습니다. 분명히, 이러한 상황이 가능하게끔 인터넷 프로토콜이 설계되어 있기 때문입니다.

Addressing

    A distinction is made between names, addresses, and routes [4].   A
    name indicates what we seek.  An address indicates where it is.  A
    route indicates how to get there.  The internet protocol deals
    primarily with addresses.  It is the task of higher level (i.e.,
    host-to-host or application) protocols to make the mapping from
    names to addresses.   The internet module maps internet addresses to
    local net addresses.  It is the task of lower level (i.e., local net
    or gateways) procedures to make the mapping from local net addresses
    to routes.
                            [ RFC 791, 1981 ]

흥미로운 질문을 하나 하겠습니다. Cloudflare든, 그 어떤 콘텐츠 서비스 공급자든, 모든 IP 주소를 단 하나의 이름에 일치시킬 수 있을까요? 분명히 그럴 수 없다는 게 답입니다. 마찬가지로 프로토콜 설계(이 경우 DNS) 때문입니다.

인터넷 규격을 고려하면 이름과 주소를 일대일로 관련시키는 것은 불가능합니다. 실제 세계에서 실현할 수 없는 이유와 같습니다. 사람과 조직이 주소를 바꿀 수 있다는 점은 잠깐 무시합시다. 기본적으로는 전 세계의 사람과 조직의 수가 우편 주소의 수보다 많습니다. 우리는 인터넷에서 주소보다 이름이 더 많기를 바랄 뿐만 아니라, 그래야만 합니다.

이름과 주소의 규모 차이도 규격에 기록되어 있습니다. IPv4 주소는 32비트고 IPv6 주소는 128비트입니다. DNS로 쿼리할 수 있는 도메인 이름의 수는 253옥텟, 즉 2,024비트(1987년에 공개된 RFC 1035의 섹션 2.3.4)입니다. 아래 표에서 이러한 차이를 살펴볼 수 있습니다.

2022년 11월 15일 UN에서는 세계 인구가 80억 명을 넘었다고 발표했습니다. 우리는 우편 주소가 절대로 그만큼 많을 수는 없다는 점을 직관적으로 알 수 있습니다. 인터넷 환경과 유사하게 지구상에 존재할 수 있는 이름의 수는 쓸 수 있는 주소의 수를 넘으며 그럴 수밖에 없습니다.

이제 국제 표준의 IP 주소와 DNS 이름에 대한 관련 원칙 두 가지를 이해했습니다. IP 주소와 도메인 이름은 다른 목적으로 이용되며 둘 사이에는 일대일 관계가 없다는 것입니다. IP 주소를 이용하여 콘텐츠를 차단한 최근의 사례를 검토해보면 문제가 되는 이유를 살펴볼 수 있습니다. 지난 2022년 8월 오스트리아에서 벌어진 IP 차단 사건이 그 예입니다. 목표는 IP 주소 11개를 차단하여 대상 도메인 14개를 제한하는 것이었습니다(출처: RTR.Telekom. Internet Archive를 통해 공개). 두 숫자가 일치하지 않음을 경고 사인으로 여겨 IP 차단으로는 원하는 효과를 내지 못할 거라는 점을 인지했어야 할 것입니다.

IP 차단을 피해야 하는 이유를 비유와 국제 표준으로 설명할 수도 있지만, 인터넷 규모 데이터를 보면 문제의 규모를 알 수 있습니다. IP 차단의 심각성을 더 잘 이해하고 설명하기 위해 도메인 이름과 IP 주소를 국제적으로 확인할 수 있게 만들었습니다(박사 연구 인턴 Sudheesh Singanamalla의 수고에 감사드립니다). 2022년 9월, Cloudflare에서는 최상위 도메인(TLD)인 .com, .net, .info, .org의 권한 있는 영역 파일을 상위 1백만 웹 사이트 목록과 함께 사용해 총 255,315,270개의 고유한 이름을 찾았습니다. 그런 다음 5개 지역 각각에서 DNS를 쿼리하고 반환된 IP 주소 집합을 기록했습니다. 조사 결과는 아래 표에 요약되어 있습니다.

위의 표를 보면 지구상의 모든 지역에서 2억 5,531만 5,270개의 이름에 연결하는 데는 1,070만 개의 주소면 충분하며, 이러한 이름에 대한 모든 위치의 IP 주소 총합은 1,600만 개 정도라는 점을 분명히 알 수 있습니다. 이름과 IP 주소의 비율은 유럽에서는 거의 24배, 세계적으로는 16배입니다.

위 숫자와 관련해 의미 있는 정보가 하나 더 있습니다. IP 주소는 IPv4와 IPv6 주소를 모두 합한 총계이므로, 2억 5,500만 개 웹 사이트 모두에 연결하는 데 필요한 주소는 훨씬 적다는 사실입니다.

다른 방식으로도 데이터를 살펴보자 몇 가지 흥미로운 관찰 결과를 얻을 수 있었습니다. 예를 들어, 아래 그림에는 각각의 추가 IP 주소를 이용해 방문할 수 있는 웹 사이트 비율에 대한 누적 분포(CDF)가 나와있습니다. y축에는 IP 주소가 주어졌을 때 연결할 수 있는 웹 사이트의 비율이 표시됩니다. X축에는 가장 순위가 높은 도메인을 왼쪽에, 낮은 도메인을 오른쪽에 배치하여 IP 주소 1,600만 개의 순위를 매겼습니다. 여기서 IP 주소는 모두 DNS의 응답이므로 도메인 이름이 최소 하나는 있어야 하며, 전체 숫자에서 IP 주소에 대해 가장 높은 도메인의 수는 8자리 수(수백만 개)입니다.

CDF를 살펴보면 놀라운 사항을 몇 가지 관찰할 수 있습니다.

• 전체 도메인 중 20%, 약 5,100만 개의 도메인에 연결하는 데 필요한 IP 주소는 10개 미만입니다.

• 약 50%의 도메인에 연결하려면 IP 100개면 충분합니다.

• 60%의 도메인에 연결하려면 IP 1000개면 충분합니다.

• 80%, 약 2억 400만 개의 도메인에 연결하려면 IP 10,000개면 충분합니다.

실제로 총 1,600만 개의 주소 중에서, 이름이 하나만 있는 주소는 데이터세트의 절반 미만인 710만 개(43.7%)였습니다. 이 ‘하나의’ 지점에 명확히 해야 할 점이 있습니다. 도메인 이름은 .com, .org, .info, .net에 포함되는 것 이외에도 훨씬 많으므로, 이러한 주소에 이름이 단 하나만 있는지 확인할 수는 없다는 점입니다. 해당 주소에 다른 이름이 있을 수도 있습니다.

하나의 IP 주소에 도메인이 여러 개 있기도 하지만, 도메인의 IP 주소는 시간에 따라 바뀔 수도 있습니다.  IP 주소를 주기적으로 바꾸면 보안과 성능을 확보하고 웹 사이트 안정성을 높이는 데 도움이 될 수 있습니다. 여러 작업에서 흔히 사용되는 예는 부하 분산입니다. 이는 시간이 지나거나 위치가 달라지면 같은 웹 사이트에 DNS를 쿼리해도 다른 IP 주소가 반환될 수도 있다는 것을 의미합니다. 이는 시간이 지나면 IP 주소를 기반으로 한 차단으로 의도한 목적을 달성할 수 없게 되는 또 다른 별개의 이유입니다.

궁극적으로, 지구상 모든 위치에서 매 순간 DNS에 있는 모든 이름을 검사하지 않는 한 IP 주소에 있는 도메인의 수를 신뢰할 수 있을 만큼 파악할 방법은 없습니다. 이는 완전히 실현할 수 없는 과제입니다.

인터넷을 관리하고 작동시키는 프로토콜의 정의 자체에 따라, IP 주소에 어떤 조치를 취하든 부차적인 영향이 미칠 수밖에 없습니다.

IP 주소를 차단하면 부차적인 영향이 미칠 거라고 예상해야 하고, 도메인이 여러 개 있는 IP 주소를 차단하여 과도한 차단이 일어나는 상황은 부적절하며 심지어 법적으로 용인될 수 없다는 데 공통적으로 의견이 일치하고 있다면, IP 차단은 왜 아직도 발생할까요? 그 이유는 확실하게 알 수 없으므로 추측만 할 수 있습니다. 특히 기술자가 아닌 판사 등의 주체가 미칠 수 있는 영향을 기술적으로 충분히 이해하지 못하고 있는 현실이 반영되는 경우가 있습니다. 인터넷 중단의 경우처럼 그저 정부가 부차적인 피해를 무시하는 경우도 있습니다. 차단에 따른 실익이 있다고 여기기 때문입니다. 부차적인 피해가 발생하는 경우 보통은 외부에서는 명확히 볼 수 없으므로, 이를 해결하려는 외부 압력이 거의 없을 수 있습니다.

이 점은 강조할 가치가 있습니다. IP가 차단될 때 사용자는 연결이 실패했다는 사실만 알 수 있습니다. 연결이 왜 실패했는지, 실패하게 만든 원인 제공자가 누구인지는 모릅니다. 한편 웹 사이트를 작동시키는 서버에서는 사이트를 이용할 수 없다는 불만이 접수되기 전까지 차단되었다는 사실조차 알 수 없습니다. 과도한 차단에 대해서는 사실상 투명성이나 책임이 없습니다. 게다가, 웹 사이트 소유자가 차단에 이의를 제기하거나 부적절하게 차단된 것에 배상을 청구하기란 불가능하지는 않더라도 어려울 수 있습니다.  

오스트리아를 포함해 일부 정부에서는 현재의 차단 목록을 게시하며 이는 투명성을 향한 중요한 단계입니다. 하지만 앞서 언급한 모든 이유로 인해, 의도치 않게 차단되었을 수 있는 모든 사이트를 게시된 IP 주소로 확인할 수는 없습니다. 그리고 영향을 받는 이들에게 과도한 차단에 이의를 제기할 수단이 주어지지도 않습니다. 다시 말하지만, 예로 들었던 실제 세계에서는 법원 명령이 고층 건물의 문에 게시되지 않는 상황을 상상하기 어렵지만, 가상 공간에서는 이와 같은 적법 절차와 통지 요건이 간과되는 경우가 많습니다.

온라인 콘텐츠를 차단하는 국가가 점점 더 늘어나고 있으므로 IP 차단으로 발생하는 문제의 결과를 이야기하는 것이 그 어느 때보다 중요하다고 우리는 생각합니다. 안타깝게도 ISP에서 그러한 요건을 이행하기 위해 IP 차단을 이용하는 경우가 많습니다. 이러한 ISP가 규모가 더 큰 ISP에 비해 새로 만들어졌거나 힘이 더 약할 수는 있지만, 큰 ISP에서도 이러한 관행에 동참하고 있습니다. IP 차단에는 조금만 노력을 들여도 되고 대부분의 장비에 쉽게 적용할 수 있으므로 당연합니다.

같은 IP 주소 숫자에 도메인이 더 많이 포함되고 있으니 문제는 더 악화될 것입니다.

그러면 우리는 어떤 조치를 취할 수 있을까요?

첫 번째 단계는 IP 차단 이용에 관한 투명성을 개선하는 것이라고 생각합니다. IP 차단이 미치는 부차적 피해를 포괄적으로 기록할 방법은 잘 모르지만, 이 관행을 더 널리 인식하게끔 조치를 취할 수는 있다고 생각합니다. 우리는 Cloudflare Radar 중단 센터에서 진행했던 것처럼 이러한 인사이트를 강조할 새로운 이니셔티브를 추진하기 위해 노력하고 있습니다.

또한, 이 문제가 인터넷 전체의 문제이므로 더 폭넓은 활동의 일환으로 추진되어야 한다는 점도 인식하고 있습니다. IP 주소를 통한 차단은 관련 없는(겨냥하지도 않은) 도메인 전체에 액세스하는 데 제한이 생길 가능성이 크므로 누구에게도 적합하지 않은 방법입니다. 그래서 Cloudflare에서는 시민사회 파트너 및 의견이 같은 기업들과 협력하여 콘텐츠 문제를 해결하는 방법으로 IP 주소 차단을 사용하는 것에 이의를 제기하고 부차적인 피해가 확인되었을 때 이를 지적하는 목소리를 내고 있습니다.

명확하게 말하자면, 국가에서 불법 온라인 콘텐츠 문제를 해결하려면 권리를 존중하는 방식으로 콘텐츠를 제거하거나 제한하는 법적 장치를 갖추어야 합니다. 우리는 대부분의 경우 소스에서 콘텐츠를 다루는 게 최선이며 필수적인 첫 번째 단계라고 생각합니다. EU의 새로운 디지털 서비스법(Digital Services Act)이나 디지털 밀레니엄 저작권법(Digital Millennium Copyright Act) 등의 법률은 중요한 적법 절차 원칙을 준수하면서도 소스에서 불법 콘텐츠를 다루는 데 사용할 수 있는 도구를 제공해줍니다. 정부는 인권에 대한 기대를 충족하면서, 사람들의 권리에는 최소한의 영향만 미치는 방식으로 법적 장치를 구축하고 적용하는 데 집중해야 합니다.

간단히 말해서, IP 주소 차단으로는 이러한 요구 사항을 충족할 수 없습니다.

Cloudflare에서는 네트워크 활동과 중단의 경우에, 그리고 특히 액세스에 불필요한 제한을 초래하는 경우에 이에 대하여 목소리를 높일 새로운 방법을 끊임없이 찾을 것입니다. Cloudflare에서 온라인에서 확인한 상황에 대한 인사이트를 Cloudflare Radar에서 자세히 확인해보세요.