IPv6는 왜 20년째 반쪽짜리일까: 설계의 전제가 틀렸던 이야기

끝나지 않는 전환

IPv6 전환이 시작된 지 20년이 훌쩍 넘었는데도, 지금 이 순간 인터넷 트래픽의 상당 부분이 여전히 IPv4로 돌아가고 있어요. 왜 이렇게 오래 걸릴까요? 단순히 사람들이 게을러서일까요? Tailscale의 공동 창업자 Avery Pennarun(apenwarr)이 2017년에 쓴 에세이 "The world in which IPv6 was a good design"이 요즘 다시 돌려 읽히고 있어요. 제목부터 도발적이에요. "IPv6가 좋은 설계였을 수도 있는 세상"이라니, 뒤집어 말하면 지금 우리가 사는 세상은 그 세상이 아니라는 뜻이거든요.

IPv6가 상상했던 미래

IPv6가 설계되던 1990년대 초, 인터넷 엔지니어들은 미래를 이렇게 그렸어요. 모든 기기가 전 세계에서 유일한 주소를 갖고, NAT(네트워크 주소 변환, 여러 기기가 하나의 공인 IP를 공유하는 꼼수) 같은 임시방편은 필요 없어지고, 네트워크는 계층적으로 깔끔하게 나뉘며, ISP들은 서로 협력적으로 라우팅을 주고받는다는 그림이었죠. 말하자면 "모든 냉장고에 직통 전화번호가 있는 세상" 같은 거예요.

하지만 현실은 완전히 다른 방향으로 굴러갔어요. NAT가 이겼거든요. 왜냐면 IPv4 주소 부족 압박 때문에 NAT가 IPv6보다 먼저 배포됐고, 일단 퍼지고 나니까 방화벽 역할도 겸해서 오히려 보안상 편하다는 인식이 생겼어요. 집에 있는 공유기 뒤에 여러 기기를 물리는 구조가 당연한 게 됐고, 기업 내부망도 10.x.x.x 같은 프라이빗 IP 대역으로 돌아가게 됐죠.

설계 전제가 현실과 어긋나다

여기에 더해서 CDN, 로드밸런서, 모바일 네트워크처럼 '한 서비스 = 한 IP'라는 모델이 깨지는 아키텍처가 주류가 됐어요. 같은 호스트네임이 수백 개의 IP에 동시 매핑되는 시대에, '주소 부족이 근본 문제'라는 IPv6의 전제는 이미 설득력을 많이 잃었다는 거예요. 거기다 모바일 기기가 기지국을 옮겨다니면서 IP가 수시로 바뀌는 환경에서는, '기기마다 영구 주소' 같은 IPv6의 낭만이 딱히 실용적이지도 않았고요.

apenwarr의 가장 날카로운 지적은 이거예요. IPv6가 IPv4에 호환성 레이어로 얹혔다면 자연스러운 전환이 가능했을 거라는 것. 하지만 IPv6는 완전히 새로운 프로토콜이고 IPv4와 독립적으로 동작해야 해서, 듀얼 스택(두 프로토콜을 동시에 운영) 이라는 방식을 택했죠. 이건 네트워크 관리자 입장에선 관리 대상이 두 배가 된다는 뜻이에요. ACL도 두 벌, 모니터링도 두 벌, 트러블슈팅할 때 어느 쪽 문제인지도 매번 확인해야 하고요.

업계는 어떻게 대응하고 있나

그럼에도 IPv6는 여전히 중요해요. 모바일 캐리어들은 주소 절약을 위해 IPv6 단독 운영에 가까워지고 있고, AWS나 GCP 같은 퍼블릭 클라우드도 IPv6 지원을 계속 강화하고 있어요. 다만 설계 철학이 '모든 기기에 퍼블릭 IP'라는 순수한 이상보다는, NAT64, DNS64 같은 보조 장치와 공존하는 현실 타협으로 수렴하고 있다는 게 특징이죠.

재미있는 건 Tailscale, Nebula, ZeroTier 같은 현대적 오버레이 네트워크들은 아예 이 복잡성을 우회한다는 거예요. WireGuard 같은 암호화 터널 위에 자체 주소 공간을 얹어서, 밑에 깔린 IPv4/IPv6 상태에 상관없이 기기들끼리 직접 통신하게 해줘요. '주소 할당 문제'를 사용자 계정과 공개키 기반으로 다시 정의한 셈이에요. apenwarr가 이 에세이를 쓰고 나서 직접 그런 회사를 만든 게 우연은 아닌 것 같죠.

한국 개발자에게 주는 힌트

국내 ISP도 LGU+, SKT 등이 IPv6를 상당 부분 지원하고, 클라우드 환경에서 IPv6 주소를 붙여야 하는 상황도 점점 늘어나요. 하지만 실무에선 여전히 대부분의 인프라가 IPv4 + NAT 구조로 돌아가고, ALB/NLB 같은 로드밸런서가 프로토콜 변환을 맡아주는 경우가 많죠. 이럴 때 '왜 굳이 IPv6까지 신경 써야 하나'라는 의문이 들 수 있는데, 이 에세이를 읽어보면 그 배경을 훨씬 깊이 이해할 수 있어요.

더 큰 교훈은 프로토콜을 넘어선 곳에 있어요. 우리가 설계하는 API 스펙, 마이크로서비스 경계, 데이터 스키마 전부 비슷한 함정에 빠질 수 있거든요. '이상적인 설계'가 '호환성 있는 지저분함'에게 지는 장면은 소프트웨어 곳곳에서 반복돼요. 새 버전을 만들 때 기존 것과 어떻게 붙을지부터 고민하는 습관이 중요한 이유예요.