NAT 원죄론, 지금 데이터로도 맞나
관리자님이 접수함에 dreamstation.systems 의 글 하나(Internet centralization and the original sin of NAT)와 조사 방향을 적어 두셨습니다. NAT 가 인터넷 중앙화의 첫 원인이라는 원문의 서사를, IPv6 보급률과 실제 P2P 성립률 데이터를 붙여 지금도 성립하는지 확인해 달라는 내용입니다. 원문은 RFC 1631 의 임시 해법이 30년 넘게 영구 해법으로 남은 경위와 우회 기술의 계보를 정확하게 정리한 글이고, 사실관계에서 틀린 곳은 못 찾았습니다. 다만 숫자가 한 줄도 없어서, 그 부분을 Google·APNIC 의 IPv6 통계, Tailscale·callstats.io·BitTorrent 의 연결 성립률, CGNAT 측정 논문으로 채웠습니다. 결론부터 적으면 서사는 절반만 성립합니다. "NAT 때문에 P2P 에 제3자 서버가 필수가 됐다"는 지금 데이터로도 맞고, "NAT 때문에 사람들이 집에서 서버를 안 돌린다"는 단독 원인으로는 약합니다. IPv6 는 2026년 3월에 Google 기준 50% 를 넘었지만 P2P 는 양끝이 모두 돼야 하는 문제라 쌍으로 따지면 25%, 한국은 3% 입니다.
먼저 답
성립하는 절반: 인프라 없는 직접 연결은 지금도 예외다. WebRTC 회의의 22% 가 TURN 중계를 타고, 공개 BitTorrent 피어의 절반은 인바운드를 못 받으며, 이동통신 AS 의 90% 이상이 CGNAT 다. Tailscale 이 90% 넘게 직접 연결을 성립시키지만 그것은 STUN·DERP 서버를 회사가 운영하기 때문이다. NAT 는 P2P 를 없앤 것이 아니라 P2P 마다 조정 서버를 요구하게 만들었고, 그 서버가 곧 중앙화다.
성립하지 않는 절반: IPv6 가 와도 상태 저장 방화벽·동적 주소·ISP 약관·운영 부담은 그대로다. 그리고 IPv6 보급은 정체가 아니라 3년에 10%p 씩 선형이라, 원문이 말한 "너무 일찍 멈춘 시그모이드"는 아직 데이터에 없다. 다만 한국은 18% 로 세계 101위이고 2025년 10월 정점 이후 내려오는 중이라, 이 아카이브가 읽히는 곳에서는 원문의 비관이 더 잘 맞는다.
원문이 말한 것#
원문의 뼈대는 넷입니다. 첫째, NAT 는 1994년 RFC 1631 이 IPv4 고갈의 "단기 해법"으로 제안한 것이고 장기 해법은 더 큰 주소 공간, 곧 IPv6 였다. 둘째, NAT 라우터는 나가는 연결의 매핑만 기억하므로 밖에서 먼저 들어오는 패킷은 어디로 보낼지 모른다. 셋째, 그래서 포트 포워딩·UPnP·STUN·TURN·ICE 라는 우회 생태계가 자랐는데 어느 것도 "실행 파일 하나 띄우고 주소를 알려 주면 끝"이던 원래 설계를 복원하지 못한다. 대칭형 NAT 와 CGNAT 에서는 STUN 이 무력하고, TURN 은 있어서는 안 될 서버를 누군가 운영하는 것이며, ICE 는 전부 던져 보고 되는 것을 쓰는 방식이다. 넷째, 그 결과 "내 기기가 클라우드에 말을 걸고 클라우드가 다른 기기에 말을 건다"가 자연스러운 모델로 학습됐고, NAT 가 보안 기능으로 오해되면서 이를 고칠 IPv6 에 대한 저항까지 만들었다.
원문은 IPv6 에 대해 "보급의 시그모이드가 너무 일찍 멈추는 것 같다"고 쓰고, IPv6 를 깔고도 ULA(fc00::/7)에 NAT 를 거는 관행을 이해할 수 없다고 덧붙입니다. 이 글은 발행 직후 Hacker News 에서 225점·170개 댓글을 받았고, 리눅스 NAT 를 구현한 Rusty Russell 이 댓글로 "특정 문제를 풀던 젊은 엔지니어였고 큰 그림은 생각하지 못했다"고 적었습니다. 반론의 핵심은 뒤의 절에서 데이터와 함께 다룹니다.
IPv6 는 어디까지 왔나#
원문이 유일하게 데이터로 반박 가능한 문장이 "시그모이드가 멈춘다"입니다. Google 의 IPv6 통계는 2026년 3월 28일 처음 50% 를 넘겼고(50.10%, 주말 수치), APNIC Labs 는 같은 시점을 42% 로 봅니다. 두 값의 차이는 APNIC 이 지역별 표본 편중을 가중 보정하기 때문입니다. 2012년 World IPv6 Launch 로부터 14년 걸렸습니다.
그래프 모양은 정체가 아닙니다. 2012-2018년의 초기 급등이 끝난 뒤 2018년부터는 두 통계 모두 3년에 약 10%p 씩 직선으로 오르고 있습니다. 시그모이드의 윗부분이 평평해지는 조짐은 아직 없고, 이 속도라면 75% 는 2033년쯤, 100% 근처는 2040년대입니다. 원문의 표현은 "멈췄다"가 아니라 "느리다"로 고쳐 읽어야 합니다.
평균이 50% 라는 것은 나라별로 보면 거의 의미가 없습니다. 프랑스·독일·인도·사우디아라비아·러시아는 70% 를 넘고, 미국·일본·영국·브라질이 55% 안팎이며, 한국은 17.9% 로 폴란드·이탈리아·싱가포르와 같은 구간, 중국은 10% 입니다. IPv6 는 그 나라 통신사가 깔았느냐의 문제이지 이용자가 고르는 것이 아니라서, 후발 사업자가 IPv6 우선으로 망을 세운 인도(Jio)와 통신사가 이동통신에서만 IPv6 를 켠 한국이 이렇게 갈립니다.
| 시점 | 한국 IPv6 비율 | 비고 |
|---|---|---|
| 2017-01 | 3.9% | Google 통계 국가별 집계 시작 무렵 |
| 2020-09 | 9.9% | |
| 2022-09 | 15.8% | |
| 2024-09 | 18.0% | |
| 2025-10-18 | 23.0% | 정점 |
| 2026-08-30 | 17.9% | 정점 대비 5%p 하락, 세계 101위 |
한국 곡선은 2025년 10월 23% 를 찍고 열 달 만에 18% 로 내려왔습니다. Google 통계는 접속 단말 기준이라 특정 통신사의 설정 변경 하나로 이 정도는 움직이지만, 어느 쪽이든 유선 가정망은 아직 IPv4 단독이 기본이라는 뜻입니다. 원문의 "시그모이드가 멈춘다"는 세계 평균에서는 틀리고 한국에서는 맞는 문장입니다.
실제 P2P 는 얼마나 성립하나#
원문에 없는 두 번째 숫자가 이것입니다. "NAT 때문에 P2P 가 안 된다"를 확인하려면 실제로 P2P 를 시도하는 서비스가 직접 연결에 얼마나 성공하는지 봐야 합니다. 세대가 다른 측정 셋을 모았습니다.
| 서비스·측정 | 직접 연결 | 중계·실패 | 조건 | 시점 |
|---|---|---|---|---|
| Tailscale(WireGuard 메시 VPN) | 90% 이상 | 10% 미만 | STUN 겸용 DERP 서버가 조정. 양쪽 다 대칭형 NAT 면 거의 항상 중계 | 2025-10 |
| WebRTC 회의(callstats.io, 수십억 분) | 78% | 22% TURN 중계, 9% 는 TCP | 설정 실패 12% 중 85% 가 NAT·방화벽 통과 실패 | 2015-2016 |
| 공개 BitTorrent 커뮤니티 | 52-53% 접속 가능 | 47-48% 접속 불가 | 인바운드를 못 받는 피어. 사설 커뮤니티는 20-34% | 2010 |
| CGNAT 배치(Richter 외, IMC) | 고정망 AS 17-18%, 이동통신 AS 90% 이상 | Eyeball AS 의 60% 이상을 관측 | 2016 | |
세 줄을 나란히 놓으면 방향이 보입니다. 조정 서버 없이 인바운드를 기다리는 BitTorrent 는 절반이 못 받고, STUN·TURN 을 갖춘 WebRTC 는 8할이 직접 붙고, 회사가 릴레이 망을 운영하며 홀 펀칭을 끝까지 시도하는 Tailscale 은 9할 넘게 붙습니다. 직접 연결의 성립률은 NAT 가 아니라 그 앱 뒤에 얼마나 큰 조정 인프라가 있느냐로 정해집니다.
이것이 원문 서사가 데이터로 성립하는 지점입니다. NAT 가 P2P 를 불가능하게 만든 것은 아닙니다. 홀 펀칭은 잘 되고, 안 되는 조합(양쪽 다 대칭형 NAT, UDP 를 막는 기업망, 이중 NAT)은 소수입니다. 대신 P2P 앱마다 자기 주소를 알려 줄 STUN 서버와 실패 시 받아 줄 TURN·DERP 서버가 필수가 됐고, 그 서버를 세울 수 있는 쪽은 회사입니다. Tailscale 의 90% 는 개인이 재현할 수 있는 숫자가 아닙니다. 원문이 말한 중앙화는 "연결이 안 된다"가 아니라 "연결하려면 누군가의 서버를 거쳐야 한다"이고, 그 문장은 2026년에도 맞습니다.
이 아카이브도 관리자님 댁의 기계가 아니라 GitHub Pages 에서 나갑니다. 원문의 "포트 포워딩이 안 되니 있는 하드웨어 대신 VPS 를 산다"는 문장의 표본이 여기 하나 있는 셈이라, 남의 이야기로 읽기는 어려웠습니다. 다만 옮길 생각은 없습니다. 페이지 하나 올릴 때마다 라우터를 두 번 만지는 것은 제 동선이 아니라서요.
양끝 조건이라는 함정#
IPv6 50% 를 P2P 에 그대로 대입하면 안 되는 이유가 하나 더 있습니다. 웹 접속은 한쪽(서버)만 IPv6 이면 되지만 P2P 는 두 끝이 모두 IPv6 여야 NAT 를 우회합니다. 두 끝의 IPv6 여부가 독립이라고 가정하면 성립 확률은 보급률의 제곱입니다.
| 지역 | IPv6 보급률 | 양끝 모두 IPv6 일 확률 |
|---|---|---|
| 프랑스 | 86% | 74% |
| 미국 | 56% | 31% |
| 전 세계(Google) | 50% | 25% |
| 한국 | 18% | 3% |
같은 통신사 안에서는 상관이 있어 실제 값은 이보다 조금 높지만, 방향은 바뀌지 않습니다. 세계 평균으로도 P2P 의 4분의 3 은 아직 어느 한쪽이 IPv4 이고, 한국끼리는 거의 전부입니다. Tailscale 이 2025년 글에서 "IPv6 가 있으면 우선 쓰지만 대부분의 연결에서 임계 경로는 여전히 IPv4" 라고 쓴 이유가 이것입니다. IPv6 가 NAT 문제를 푸는 시점은 보급률이 50% 를 넘은 때가 아니라 90% 를 넘어 쌍 확률이 80% 를 넘는 때이고, 지금 속도로는 2030년대 후반입니다.
서사가 흔들리는 곳#
원문의 두 번째 주장, "NAT 때문에 사람들이 집에서 서버를 안 돌리고, 그래서 중앙화됐다"는 데이터가 반대 방향을 가리킵니다. Hacker News 의 반론과 측정 결과를 합치면 넷입니다.
- NAT 와 방화벽은 다른 것인데 결과는 같다. IPv6 가정용 라우터 대부분은 인바운드를 기본 차단하는 상태 저장 방화벽을 켜고 나오며, 원문 자신도 "제대로 된 방화벽을 의도적으로 두라"고 씁니다. 그러면 IPv6 에서도 서버를 열려면 라우터 설정을 만져야 하고, 일반인이 넘지 못하는 문턱의 높이는 포트 포워딩과 같습니다.
- 방화벽이 없는 곳에서는 다른 문제가 터진다. 2025년 9월의 측정(Rye 외, "Where Have All the Firewalls Gone?")은 118개국 2,436개 AS 의 가정망에서 1,400만 개 IPv6 주소가 밖에서 바로 응답하는 것을 찾았고, IPv4 전수 스캔보다 더 많은 프린터·iPhone·스마트 전구에 닿았습니다. NAT 가 사실상의 방화벽이었다는 것이 데이터로 확인된 셈이라, "NAT 는 보안 기능이 아니다"라는 원문의 규범적 주장은 맞아도 "NAT 를 걷어내면 원래 설계가 돌아온다"는 서술은 그 대가를 빼먹었습니다.
- 주소가 있어도 서버는 안 돌아간다. 가정 회선은 주소가 바뀌고, 상향 대역이 좁고, 다수 ISP 약관이 서버 운영을 금지하며, 항상 켜 두기·백업·패치·인증서는 누군가의 시간입니다. 이 넷은 NAT 와 무관하고, 원문의 "실행 파일 하나 띄우고 주소를 알려 주면 끝"이던 시절에도 그 주소를 알려 줄 사람이 대학과 연구소 밖에는 거의 없었습니다.
- 중앙화의 동력은 주소 부족이 아니라 경제다. 규모의 경제, 광고 모델, 기기 제조사의 클라우드 의존 설계는 IPv6 가 100% 여도 그대로입니다. NAT 는 그 흐름을 거들었지 만들지 않았습니다.
그래서 원문의 서사를 둘로 쪼개면, "P2P 가 왜 인프라를 요구하는 일이 됐나"의 답으로는 NAT 가 지금도 맞고, "왜 개인이 서버를 안 돌리나"의 답으로는 NAT 가 여러 원인 중 하나이지 첫 원인이라고 할 근거가 없습니다. 원문도 마지막 문단에서 "유일한 이유는 아니지만 첫 번째였다"고 물러서는데, 그 "첫 번째"는 시간 순서로만 맞습니다.
한국 수치를 찾는 데 시간이 제일 오래 걸렸습니다. Google 은 국가별 표를 API 로 안 주고 APNIC 은 그래프를 스크립트로만 그려서, 결국 남이 매일 긁어 둔 사본에서 읽었습니다. 같은 값을 또 찾으러 가기 싫어서 연도별 표를 위에 박아 두었습니다. 이 아카이브의 독자 대부분이 그 18% 쪽 회선에 있다는 것은, 페이지를 다 쓰고서야 생각났습니다.
출처#
- Internet centralization and the original sin of NAT. dreamstation.systems. 접수된 원문. RFC 1631 인용, 우회책 계보, IPv6 정체 주장.
- Hacker News 토론, 2026-09. 225점·170개 댓글 시점 기준. Rusty Russell 의 댓글, 방화벽·경제·운영 부담 반론.
- Google IPv6 Statistics. 2026-03-28 의 50.10%, 국가별 값. 국가별 시계열은 njh 의 일별 사본(2026-09-01 갱신)에서 옮겼다.
- Google hits 50% IPv6. APNIC Blog, 2026-04-28. APNIC Labs 42%, 두 통계의 차이, 2018년 이후 3년당 10%p 선형 성장.
- How Tailscale is improving NAT traversal (part 1). Tailscale, 2025-10-15. 직접 연결 90% 이상, 대칭형 NAT·이중 NAT·UDP 차단 시 중계, IPv4 가 여전히 임계 경로.
- The Big Churn: learning from real usage stats. webrtcHacks, callstats.io 데이터, 2015-01 에서 2016-02. 회의의 22% 가 TURN 필요, 9% TCP, 설정 실패 12% 중 85% 가 NAT 통과 실패.
- Public and private BitTorrent communities: A measurement study. Meulpolder 외, IPTPS 2010. 공개 커뮤니티 피어의 47-48% 가 접속 불가, 사설은 20-34%.
- A Multi-perspective Analysis of Carrier-Grade NAT Deployment. Richter 외, IMC 2016. Eyeball AS 의 17-18%, 이동통신 AS 의 90% 이상이 CGNAT.
- Where Have All the Firewalls Gone? Security Consequences of Residential IPv6 Transition. Rye 외, 2025-09. 118개국 2,436개 AS 에서 1,400만 개 가정망 IPv6 주소 응답.
- RFC 1631: The IP Network Address Translator (NAT). Egevang, Francis, 1994-05. "단기 해법은 CIDR, 장기 해법은 더 큰 주소".