# Google IPv6 접속 비율 50% 도달
> Clean Markdown view of GeekNews topic #30706. Use the original source for factual precision when an external source URL is present.
## Metadata
- GeekNews HTML: [https://news.hada.io/topic?id=30706](https://news.hada.io/topic?id=30706)
- GeekNews Markdown: [https://news.hada.io/topic/30706.md](https://news.hada.io/topic/30706.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-22T10:03:06+09:00
- Updated: 2026-06-22T10:03:06+09:00
- Original source: [blog.apnic.net](https://blog.apnic.net/2026/04/28/google-hits-50-ipv6/)
- Points: 2
- Comments: 2
## Topic Body
- 2026년 4월 23일 Google의 IPv6 통계가 처음 **50%** 에 도달해, Google 서비스 접속의 절반이 IPv6로 이뤄지는 단계에 들어섬
- 같은 날 APNIC Labs의 전 세계 **IPv6 capability**는 42%로 낮아, 두 수치는 측정 방식과 가중 모델 차이를 함께 봐야 함
- APNIC은 Google Ads 기반 측정 데이터를 단순 합산하지 않고, 경제권별 인터넷 사용자 규모를 반영하는 **가중치**를 적용함
- India, Viet Nam, Saudi Arabia처럼 채택 곡선이 크게 다른 경제권이 있어, 전 세계 평균만으로는 **지역별 현실**을 설명하기 어려움
- IPv6는 이제 고정망·모바일·개인 기기·데이터센터 서비스에서 매일 쓰이는 **인터넷 운영의 일부**가 됨
---
### Google IPv6 통계의 50% 이정표
- Google의 IPv6 통계가 2026년 4월 23일 처음 **50%** 를 기록함
- 이 통계는 Google 서비스에 IPv6로 접속한 사용자 비율을 반영함
- Google 사용자의 IPv6 연결 가능성을 지속적으로 관찰하는 지표임
- IPv6 50% 도달: {p:50}
- 이 수치는 IPv6가 전 세계 실제 네트워크에서 쓰이는 **성숙한 프로토콜**이 됐다는 이정표로 볼 수 있음
### 전 세계 평균만으로 보이지 않는 지역 차이
- IPv6 채택은 지역과 경제권별 차이가 커서, 하나의 전 세계 추세선만으로 판단하기 어려움
- Google은 지역별 IPv6 통계를 공개하지 않고, 경제권별 데이터도 전체 합계로 제한함
- APNIC Labs 데이터에서는 경제권별 채택 곡선이 전 세계 평균과 크게 다를 수 있음
- [APNIC Labs measurements](https://labs.apnic.net/measurements/)
- [India](https://stats.labs.apnic.net/ipv6/IN)
- [Viet Nam](https://stats.labs.apnic.net/ipv6/VN)
- [Saudi Arabia](https://stats.labs.apnic.net/ipv6/SA)
### APNIC Labs 측정값은 42%
- APNIC의 자체 측정은 2026년 4월 23일 기준 전 세계 **IPv6 capability**를 42%로 기록함
- APNIC Labs 전 세계 측정: [Source](https://stats.labs.apnic.net/ipv6/XA?c=XA&x=1&v=1&p=1&r=1&w=30&p=0)
- APNIC IPv6 capability: {p:42}
- Google의 50%와 APNIC의 42% 사이에는 뚜렷한 차이가 있음
- 개별 경제권 수준에서는 APNIC Labs 측정이 대체로 Google, Cloudflare, Akamai, Cisco 등의 데이터와 일치함
- 전 세계 수준의 큰 차이는 기초 측정 자체보다 APNIC의 **가중 모델** 차이에서 비롯될 가능성이 있음
- APNIC 측정값은 실무적으로 Google 측정값보다 낮게 나오는 경향이 있음
- 두 데이터셋을 함께 보면 특정 시점의 실제 IPv6 capability 범위를 양쪽에서 감싸는 값으로 해석할 수 있음
### APNIC의 광고 기반 측정 방식
- APNIC의 측정 프로그램은 APNIC Labs가 운영하며, Google Ads를 통해 최종 사용자 웹 브라우저, 게임, 앱에 배포되는 온라인 광고를 활용함
- 특정 사용자를 골라 측정하지 않고, 모든 경제권에서 24/7 가능한 한 넓은 노출을 추구함
- 일반 광고 추적 시스템에 APNIC Labs 로직을 결합해 고유한 테스트 세트를 실행함
- IP, BGP 라우팅, DNS 및 기타 기술 선택을 측정함
- 최종 사용자의 **개인식별정보(PII)** 는 보관하지 않음
- 원시 측정값은 공유하지 않고 ISP, 경제권, 지역 수준의 집계만 공개함
- 이 측정 작업은 Google Research, ICANN 및 기타 기관의 자금과 지원을 받아 수행됨
### 원시 샘플을 그대로 합산하지 않는 이유
- APNIC은 수집 데이터에 통계적 가중치를 적용하고, World Bank 통계 같은 외부 자료로 경제권별 인터넷 사용량을 모델링함
- APNIC Labs가 매일 받는 측정 샘플 수는 균등하지 않음
- Google의 광고 배치는 전달량과 수익을 극대화하도록 최적화되므로, 특정 날 일부 경제권에서 광고와 측정 샘플이 더 많이 나올 수 있음
- 예를 들어 Egypt나 Tunisia 같은 North African 경제권의 광고 수요가 높은 날에는 해당 지역 측정이 더 많이 수집될 수 있음
- 같은 날 South America나 Asia에서는 상대적으로 더 적은 샘플이 나올 수 있음
- APNIC Labs는 원시 샘플 수를 단순 합산하지 않음
- 각 경제권의 측정된 IPv6 capability를 먼저 집계함
- 이후 해당 경제권의 추정 인터넷 사용자 수에 따라 가중함
- India, China, Indonesia 및 기타 주요 경제권처럼 인터넷 인구가 큰 곳은 특정일 원시 샘플 수와 무관하게 전 세계 결과에서 더 큰 비중을 가짐
- 이 방식은 최종 측정값이 일별 광고 배포 패턴보다 **전 세계 인터넷 사용량**을 더 잘 반영하도록 하기 위한 것임
### IPv6 전환이 오래 걸린 배경
- IPv6가 50% 채택 이정표에 도달하는 데 오래 걸렸다는 점을 IPv6의 시스템적 실패 증거로 보는 시각이 있음
- IPv6 배포에는 상당한 기술적 노력과 큰 자본 투자가 필요했음
- 지역과 경제권별 진척 차이는 ISP와 경제권이 네트워크 성장, 사용자 기대, 인터넷 인프라 운영 현실 사이에서 각자 판단한 결과임
- 전 세계 인터넷은 **계획경제**가 아니며, 시장 주도 조건 안에서 협업과 협력을 통해 진화함
- 많은 제공자는 과거 IPv4에 큰 자본을 투자했고 그 투자 수익을 극대화하려고 했음
- 그 과정에서 기존 서비스 범위 안에서 지속 가능하고 상업적으로 성립하는 IPv4 기반 네트워크를 구축함
- 신규 시장 진입자에게는 IPv6를 기본 프로토콜로 채택하는 편이 더 합리적인 경우가 많았음
- IPv6는 **총소유비용(TCO)** 을 줄일 수 있음
- 이 패턴은 모바일 부문에서 특히 두드러짐
- India의 [Reliance Jio network](https://stats.labs.apnic.net/ipv6/AS55836?c=IN&p=1&v=1&w=30&x=1)가 대규모 IPv6 배포 사례로 제시됨
### IPv4와 IPv6가 함께 돌아가는 현재 인터넷
- 현재 전 세계 인터넷은 두 프로토콜 세계에서 동작함
- 단일 프로토콜로 운영하는 편이 물류적으로는 더 쉬웠겠지만, 실제 환경은 그렇게 되지 않았음
- 오늘날 인터넷에는 여러 연결 형태가 섞여 있음
- 직접 IPv4 연결
- 가정망 NAT 또는 통신사급 **Carrier-Grade NAT(CGNAT)** 를 통한 IPv4
- IPv6
- NAT를 통한 주소 변환 관리는 프로토콜 변환, IPv6 위의 IPv4 캡슐화, 기타 전환·프록시 메커니즘보다 본질적으로 덜 복잡하지 않음
- “IPv4 is working fine”이라는 말은 현대 IPv4 네트워크가 이미 여러 층의 운영 복잡성에 의존한다는 현실을 놓치기 쉬움
- IPv4만으로는 본질적으로 더 저렴하거나 더 단순한 접근법이 없음
### IPv4·IPv6 상호운용성의 실제 위치
- IPv4와 IPv6 사이에 직접 상호운용성이 없다는 점은 처음부터 해결해야 할 과제로 이해됐음
- 관련 설명: [the lack of direct interoperability between IPv4 and IPv6](https://github.com/becarpenter/misc/blob/main/why6why.md)
- 초기에는 IPv4를 변경 없이 포섭하고 두 세계 간 직접 연결을 가능하게 하는 프로토콜 아이디어가 탐색됐지만, 실행 가능한 방식으로 입증되지 않았음
- 상호운용성은 IP 버전과 독립적으로 동작하는 TCP, UDP, QUIC 같은 전송 프로토콜을 통해 더 높은 계층에서 형성됨
- 이 모델은 어떤 형태로든 **중간자**를 필요로 함
- Cloudflare 같은 대형 콘텐츠·캐싱 제공자가 백엔드 시스템의 양쪽 프로토콜 지원 여부와 관계없이 dual-stack 서비스를 제공하는 방식에서 이 구조를 볼 수 있음
### 일부 서비스에 dual-stack이 없는 이유
- 일부 서비스가 native dual-stack capability를 갖추지 않은 점은 IPv6 진전에 대한 큰 장벽으로 여겨지곤 함
- 예시로 특정 Git 플랫폼이나 전국 단위 TV 방송사가 언급됨
- 이런 상황은 IPv6에 대한 저항이라기보다 **운영 복잡성**을 반영할 수 있음
- 전국 단위 방송사의 경우 데이터 접근과 geolocation 관련 법적·규제 요구 같은 실용적 제약이 영향을 줄 수 있음
### IPv6는 일상 운영의 일부
- IPv6는 이제 전 세계 규모로 배포되어 있음
- Google에 보이는 인터넷 사용자 중 약 절반은 이미 Google 서비스에 IPv6로 접속함
- 선진국과 개발도상국, 고정망과 모바일 네트워크, 개인용 소형 기기와 대규모 데이터센터 기반 서비스에서 IPv6가 매일 매시간 사용됨
- IPv6는 더 이상 실험적이거나 주변적인 기술이 아니라 인터넷의 **일상 운영** 일부임
## Comments
### Comment 60119
- Author: purely4959
- Created: 2026-06-22T10:40:13+09:00
- Points: 1
한국 가정용 인터넷에 IPv6이 언제 도입될까
### Comment 60113
- Author: neo
- Created: 2026-06-22T10:03:07+09:00
- Points: 1
###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48616800)
- “ISP들은 아직도 안 한다”는 사례를 하나 더 보태면, 영국의 주요 ISP인 **Virgin Media**는 2011년 World IPv6 Day에 2012년 말까지 IPv6를 완전히 지원하겠다고 공개적으로 말했지만 15년이 지나도 아직 스위치를 켜지 못함
[https://havevirginmediaenabledipv6yet.co.uk/]()
당시 발표: [https://ispreview.co.uk/story/2011/06/08/uk-isp-fluidata-hai...]()
- ISP가 IPv6를 지원하게 압박하는 방법은 바보 같지만 효과적일 수 있음. 쇼핑 비교 사이트가 **IPv6 미지원 ISP**에 큰 빨간 경고 표시를 붙이고, 웹사이트도 “당신의 ISP가 이 사이트가 쓰는 정상적인 인터넷 연결을 지원하지 않는다”는 배너를 띄우면 됨
소비자는 IPv6가 뭔지는 몰라도, 큰 빨간 경고와 짜증 나는 배너는 이해함
- 예전에 Virgin Media에 1Gb DIA 회선에서 **IPv6 활성화**가 가능한지 물었더니, “회선을 IPv6로 전환할 수는 있지만 IPv4는 포기해야 한다”는 답을 받았음
그 뒤로는 다시 물어볼 마음이 사라짐
- 순수하게 사업 관점에서는 VM이 굳이 할 이유가 없음. **IPv4 주소**가 충분하고, 아주 작은 기술 사용자층을 빼면 고객은 IPv6의 이점을 체감하지 못함
여기에 다른 ISP들의 IPv6 구현이 무작위로 뭔가를 깨뜨리는 사례까지 있으니, 안 하는 이유도 이해됨
- 네덜란드에는 [https://heeftodidoipv6.nl]() 같은 사이트가 있음
이 ISP는 핵심망에는 IPv6가 있지만 고객에게는 제공하지 않고, 네덜란드 통신 시장 점유율이 **17%** 나 됨
- 미국은 그래도 드디어 가까워지고 있음. 상위 ASN들은 **IPv6 가능 비율이 75% 이상**임
다만 Optimum Communications와 Frontier가 각각 15% 안팎으로 수치를 크게 끌어내리고 있고, Frontier는 아주 천천히 개선 중이지만 Optimum 쪽은 변화의 증거가 별로 없음
- 두 달 전에도 **626개 댓글**짜리 스레드가 있었음: [https://news.ycombinator.com/item?id=47777894]()
- 최근 IPv6 관련 스레드만 더 봐도 댓글이 천 개쯤 더 나옴
IPv6 traffic crosses the 50% mark - [https://news.ycombinator.com/item?id=47777894]() - 2026년 4월
The world in which IPv6 was a good design (2017) - [https://news.ycombinator.com/item?id=47821429]() - 2026년 4월
IPv6 is the only way forward - [https://news.ycombinator.com/item?id=47680124]() - 2026년 4월
IPv6 Adoption in 2026 - [https://news.ycombinator.com/item?id=47083086]() - 2026년 2월
IPv6 is not insecure because it lacks a NAT - [https://news.ycombinator.com/item?id=46696303]() - 2026년 1월
- “순수” IPv6 서버를 세팅해보니 **GitHub가 IPv6를 지원하지 않는 것**에 놀랐음. [https://nat64.xyz/]()에 올라온 자발적 NAT64 운영자들이 없으면 IPv6 환경에서 GitHub에 닿을 수 없음
- GitHub의 **IPv6 미지원**은 전혀 용서하기 어려움
- 인터넷은 또다시 문제를 우회함. 2020년대에도 실질적으로는 여러 인터넷이 아니라 **하나의 인터넷**만 존재한다는 좋은 예시임
- 안 돼, 내 **/22 IPv4 서브넷**은 개인 401k 같은 거라 은퇴 자금으로 써야 함
- 농담 같지만, 사회가 주택을 바라보는 방식이 정확히 이렇기도 함
- 이제 현금화할 때인가?
- 2100년쯤 되면 정말 곤란해질 듯
- 네덜란드의 T-Mobile/Odido는 몇 년째 작업 중이라고 약속해놓고도 아직 **IPv6를 지원하지 않음**
Ubiquiti 게이트웨이도 아쉽게 지원이 부족해 보이고, Hurricane Electric 터널링 같은 기능을 지원하면 좋겠음
- 여기서는 Ubiquiti 게이트웨이를 통해 `news.ycombinator.com`의 IPv6 주소 `2606:7100:1:67::26`로 접속이 잘 됨
- **HE 터널 주소 대역**은 이제 비거주지/비사무실 주소로 꽤 강하게 불이익을 받아서 결국 꺼야 했음
예를 들어 YouTube는 로그인하지 않은 HE 대역 사용자를 대체로 막는 것처럼 보이고, 끝없는 CAPTCHA도 자주 만났음
- 미국 T-Mobile은 정반대로 IPv4를 지원하지 않고, IPv6만 할당한 뒤 **464XLAT**으로 IPv4용 “가짜 NAT”를 제공한다는 점이 흥미로움
- T-Mobile US는 2018년쯤부터 **IPv6 전용**이었음: [https://www.youtube.com/watch?v=d6oBCYHzrTA]()
- 모든 ISP는 Hurricane Electric 터널 비용을 지불해야 하고, 그래서 사용자에게는 무료임. 충분히 많은 사람이 HE 터널을 쓰기 시작하면 ISP들이 네이티브 IPv6를 제공하게 될 것임
하지만 실제로는 방문하는 웹사이트마다 차단당하기 쉽고, CGNAT 뒤에 있거나 홈 라우터에 DMZ가 없으면 쓰기도 어려움
- AWS에 **공인 IPv4 주소 비용**을 그만 내고 싶지만, 고객 쪽 ISP들이 지원하지 않는 곳이 많아서 완전 IPv6 전환은 불가능함
지금은 ISP가 IPv6로 옮겨가도록 압박하는 요인이 없고, 오히려 정반대임. ISP들은 고정 IP 요금을 받는 걸 좋아함
- 공정하게 말하면 Google이 IPv4 지원을 중단한다면 ISP들이 줄 맞추게 만드는 꽤 강한 유인이 될 것임
- 특히 주말에 IPv6 비율이 올라간다면, **기업/업무용 네트워크** 쪽이 구현을 미루고 있다는 신호처럼 보임
- 진짜 이정표는 항상 50%를 넘는 시점임
- “귀찮아서 안 한다”는 식으로 말하지만, IPv6가 체크박스 하나 켜면 끝나는 일은 아님
왜 조직 개편까지 하면서 온갖 작업을 해야 하나? 숫자 몇 개 바꾸려고? IPv4가 동작하는데 왜?
- Google의 IPv6가 50%에 도달한 건 웹사이트 접속 측면에서는 아주 좋음
하지만 내 **TP-Link 라우터**는 기본적으로 들어오는 IPv6 연결을 차단하고, 설정 옵션도 없어서 순수 IPv6 양방향 스트리밍, 게임, 홈 네트워크 서비스에는 여전히 좋지 않음
- 그 장비에 **OpenWRT**를 올리면 원하는 대로 할 수 있음. IPv4의 포트 포워딩 규칙 대신, 거의 같은 포트에 대해 IPv6 접근 규칙을 추가하는 즐거움을 맛보게 됨
- 무료 VPS를 쓰는 **WireGuard VPN** 위에서 웹과 이메일을 셀프호스팅하고 있음. OCI에서 무료로 했고, AWS Lightsail에서도 싸게 가능했음
Tailscale처럼 설정이 쉬운 솔루션을 써도 되고, 이렇게 하면 집 네트워크를 인터넷에 직접 노출하지 않아도 됨
- 소비자용 라우터 제조사들이 대체로 다 별로라 큰 차이는 없지만, **TP-Link는 정말 나쁨**. 해당 하드웨어는 쓰지 않는 걸 강하게 권함
- 이런 시스템들은 설계된 시대를 반영함. IPv6는 30년 전 기술이고, 당시에는 지금의 많은 위협이 존재하지 않았음
예를 들어 기본값을 **/64 블록**으로 잡은 결정은 48비트 MAC 주소를 일부로 쓸 거라는 믿음에서 나왔지만, 지금은 그게 개인정보 악몽이라는 걸 알고 아무도 그렇게 하지 않음. 그런데도 그 결과로 나온 128비트 주소 체계에는 여전히 묶여 있음
IPv6는 NAT를 충분한 주소로 대체하려 했지만, 흥미롭게도 이 때문에 의도 표현 문제가 생겼음. NAT에서는 컴퓨터의 서비스가 들어오는 연결용 포트를 요청하면 서비스 소유자의 의도가 드러났지만, IPv6에는 그런 의도 신호가 없음. 그래서 홈 라우터 제조사는 기본적으로 주소를 막을 수밖에 없고, 그렇지 않으면 외부에서 PC를 스캔해 의도치 않은 서비스가 공개 인터넷에 노출될 수 있음
더 큰 주소 공간이 기술적으로 더 나을 수는 있지만, 기본값과 사용자 의도를 고려해야 함. 좋은 기술적 해법도 이 지점에서 나쁜 해법이 되거나 수많은 문제를 만들 수 있음
- Cloudflare에서는 IPv6가 **40% 이상**으로 보이지만, 전체 트래픽 증가에도 지난 1년 동안 크게 오르지 않았음. APNIC 글의 관측처럼 실제 전체 채택률은 Google과 Cloudflare 사이 어딘가일 듯함
[https://radar.cloudflare.com/adoption-and-usage#ipv4-vs-ipv6]()
다만 이는 클라이언트 쪽 채택률을 반영함. 유명 서비스 중에도 여전히 IPv4 전용이 많아서, 공용 인터넷을 흐르는 실제 IPv6 비중은 훨씬 낮을 수 있음
이제는 IPv4 신규 할당이 오래전에 고갈됐으니, 예전과는 다른 **전환 유인**이 필요해 보임
- 트래픽 비중으로 보면 대역폭을 많이 쓰는 대형 서비스, 즉 동영상 스트리밍 사이트와 CDN은 대부분 IPv6 위에 있음. IPv4 전용인 긴 꼬리 서비스들은 대체로 대역폭을 덜 쓰는 쪽임
- 요즘에는 **속도 제한**이 큰 역유인일 수 있음. IPv4에서는 범위 차단이 어느 정도 효과가 있지만, IPv6에서는 훨씬 덜함
HE Tunnelbroker가 요즘 나쁘게 표시되는 이유도 여기에 있음. Discord 음악 봇들이 YouTube 오디오 데이터를 가져오려고 터널브로커 IP들 사이에서 부하분산을 했고, /64를 차단해도 /48 이상으로 우회할 수 있었음. Discord가 IPv6를 비활성화했던 주된 이유도 IP 기반 차단과 API 속도 제한 때문이었다고 봄
- 국가별 비율을 보면 흥미로움. **프랑스는 85%** 까지 올라간 듯함
[https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...]()
- 모바일 트래픽이 많을수록 IPv6 비율도 높아짐. 인도를 보면, 모든 사람이 IPv6가 되는 광회선을 쓰는 상황은 아님
- 그 그래프에서 장기 추세 위에 얹힌 **고주파 신호**가 왜 생기는지 궁금함
[https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...]()
- 인도가 75%라는 건 정말 좋은 소식임. 아니었다면 **IPv4 주소 가격 압박**이 말도 안 되게 심했을 것임