github.com과 국내 서비스 16곳에는 IPv6 주소가 없습니다 — 개발 인프라 68곳 직접 조회

핵심 요약

50%는 주말에만 넘습니다

IPv6가 얼마나 쓰이는지는 누가 어떻게 재느냐에 따라 값이 다릅니다. 자주 인용되는 공개 측정 두 가지를 봤습니다. 구글은 자기 서비스에 IPv6로 들어온 사용자 비율을 공개합니다. APNIC Labs(아시아·태평양 지역 인터넷 주소 등록 기관의 연구 조직)는 온라인 광고에 측정 스크립트를 실어 사용자 브라우저가 IPv6로만 받을 수 있는 객체를 가져오는지 봅니다. 가져오면 IPv6 가능(capable), 두 버전으로 다 받을 수 있는 객체를 IPv6로 가져오면 IPv6 선호(preferred)로 셉니다. 그리고 나라별 인터넷 사용자 수로 가중치를 줍니다.

구글의 세계 값이 처음 50%를 넘은 날은 2026-03-28(50.10%)입니다. 구글이 공개한 일별 데이터 파일을 받아 세어 보니 2026년에 50% 이상이었던 날은 20일이고, 그중 19일이 토요일, 1일이 일요일이었습니다. 평일에 50%를 넘은 날은 없습니다. 최근 30일(2026-08-22~09-20)만 보면 주말 평균이 49.74%, 평일 평균이 46.66%입니다.

나라별 차이는 큽니다. 같은 날 구글 값으로 프랑스 86.25%, 독일 75.40%, 인도 68.47%, 일본 56.89%, 미국 55.54%였고, 한국은 17.42%, 중국은 8.12%였습니다. 한국의 APNIC 값(IPv6 가능, 매년 9월 20일 기준 30일 평균)은 2021년 17.03%, 2024년 21.17%, 2025년 30.82%로 올랐다가 2026년 28.49%로 조금 내려왔습니다. 같은 기간 세계는 27.73% → 37.79% → 41.25% → 43.79%로 계속 올랐습니다.

구글 값(17.42%)과 APNIC 값(28.49%)이 한국에서 10퍼센트포인트 넘게 차이 나는 이유는 확인하지 못했습니다. 표본(구글 이용자 대 광고 노출 사용자)과 가중 방식이 다르다는 것까지가 공개된 사실입니다. 어느 한쪽이 맞다고 보지 말고 범위로 읽으세요.

한국은 망에 따라 1%에서 94%까지 다릅니다

나라 평균은 한국에서 특히 쓸모가 적습니다. APNIC은 망(AS, 인터넷에서 한 조직이 운영하는 네트워크 단위)별 값도 공개하는데, 한국 통신사 망은 서로 수십 퍼센트포인트씩 차이가 납니다. 아래는 표본 수가 많은 망을 골라 APNIC 한국 페이지(2026-09-25 열람, 30일 평균)에서 옮긴 값입니다.

SK텔레콤 망에서는 측정된 사용자의 94%가 IPv6를 쓸 수 있었고, 같은 그룹의 SK브로드밴드 망에서는 1%였습니다. 표본이 가장 큰 KT 망은 14.41%입니다. 이동통신 망으로 알려진 두 AS(SK텔레콤·LGTELECOM)가 가장 높고, 가정·기업용 인터넷으로 알려진 망이 낮습니다. 다만 망의 용도는 AS 이름과 회사 연혁으로 추정한 것이고, KT처럼 한 AS에 여러 용도가 섞여 있을 수 있습니다.

개발 인프라 68곳을 조회했습니다

개발자가 빌드·배포·운영 중에 호출하는 호스트 68곳을 골라 A 레코드와 AAAA 레코드를 조회했습니다. AAAA가 없으면 IPv6만 있는 기기는 그 호스트에 직접 닿을 수 없습니다.

• 언제·어디서: 2026-09-25, 한국의 가정용 회선, dig 9.10.6
• 리졸버 두 곳: 리졸버는 DNS 질의를 대신 처리해 주는 서버입니다. Cloudflare(1.1.1.1)와 Google(8.8.8.8)에 각각 물었고, 68곳 모두 두 리졸버의 AAAA 유무가 같았습니다
• 권한 네임서버 재확인: 권한 네임서버는 도메인의 원본 레코드를 가진 서버입니다. 결과가 리졸버 탓이 아닌지 보려고 www.naver.com·kapi.kakao.com·api.tosspayments.com·github.com은 각 도메인의 권한 네임서버에 직접 물었고, 역시 AAAA가 없었습니다
• 지역 차이 확인: 한국에서 물으면 github.com이 한국 근처 주소로 답하므로, 미국 주소 대역(8.8.8.0/24)에서 묻는 것처럼 요청해 봤습니다. A 레코드는 미국 주소로 바뀌었고 AAAA는 여전히 없었습니다
• 실제 연결 확인: 측정한 가정 회선에는 공인 IPv6가 없어서, 저희가 운영하는 AWS 서울 리전의 Ubuntu 24.04 서버(IPv4·IPv6 이중 스택)에서 68곳에 IPv6로만, IPv4로만 HTTPS 요청을 한 번씩 시도했습니다. 응답이 오면 HTTP 상태 코드(401·404 포함)와 상관없이 성공으로 셌습니다. 이 서버가 두 버전으로 실제로 나가는지는 6장에서 설명하는 방법(상대 서버가 본 버전 확인)으로 확인했고, AAAA가 없는 호스트에 가짜 IPv6 주소를 만들어 주는 DNS64가 없다는 것도 확인했습니다
• DNS 응답이 바뀌는지 확인: 같은 서버에서 35초 간격으로 여섯 번, 리졸버 세 곳(서버 기본값·1.1.1.1·8.8.8.8)에 물었습니다. 호스트당 18번 물어 AAAA 유무가 바뀐 곳은 없었습니다

국내 16곳: www.naver.com, openapi.naver.com, ncloud.apigw.ntruss.com, clovastudio.stream.ntruss.com, www.kakao.com, kapi.kakao.com, kauth.kakao.com, dapi.kakao.com, www.daum.net, api.tosspayments.com, api.portone.io, api.iamport.kr, www.coupang.com, api.channel.io, api.upstage.ai, api.solapi.com.

IPv6 주소가 있는 41곳은 모두 IPv6로 응답했습니다. AAAA가 없는 27곳은 IPv6로는 모두 이름 해석 단계에서 실패했고, IPv4로는 68곳이 모두 응답했습니다. 적어도 이 목록에서는 IPv6 주소를 공개한 곳이 실제로 그 주소로 응답하고 있었습니다.

GitHub — 8곳 중 2곳에만 IPv6 주소가 있습니다

GitHub 호스트 8곳 중 AAAA가 있는 것은 raw.githubusercontent.com과 pkg-containers.githubusercontent.com 두 곳뿐이었습니다. 그래서 IPv6만 있는 기기에서 raw.githubusercontent.com은 IPv6로 닿을 수 있는 주소가 있지만, git clone(github.com), gh CLI와 API 호출(api.github.com), 소스 압축 파일(codeload.github.com), 릴리스 파일(release-assets.githubusercontent.com)은 IPv6 주소가 없어 직접 닿지 못합니다. 릴리스 파일 주소는 github.com/.../releases/download/...를 요청해 돌아온 리다이렉트 주소로 확인했습니다. 컨테이너 이미지는 파일 조각을 받는 pkg-containers.githubusercontent.com에는 AAAA 레코드가 있지만, 그 앞에서 인증과 목록을 처리하는 ghcr.io에는 AAAA 레코드가 없어 다운로드가 시작되지 않습니다.

이중 스택 서버에서 git clone --ipv6(IPv6로만 접속하라는 git 옵션)로 시험하니 GitHub 저장소는 "Could not resolve host: github.com"으로 실패했고, 같은 명령이 GitLab·Codeberg 저장소에서는 성공했습니다. IPv6만 쓰도록 강제한 curl에서도 릴리스 파일과 ghcr.io는 같은 단계에서 실패했고, raw.githubusercontent.com의 파일은 1바이트만 요청해 HTTP 206(부분 응답)을 받았습니다.

GitHub 커뮤니티의 "IPv6 support for cloning Git repositories" 논의(#10539)는 2022-01-25에 열렸고, 2026-09-25 기준 추천(upvote) 1,310개와 댓글 236개가 달린 채 열려 있습니다. 두 값은 GitHub GraphQL API의 upvoteCount와 댓글 수로 확인했습니다.

Hugging Face — 사이트에는 있고 모델 파일 서버에는 없습니다

huggingface.co에는 AAAA가 있습니다. 그런데 모델 파일(gpt2의 model.safetensors)을 요청하니 us.aws.cdn.hf.co로 리다이렉트됐고, 이 호스트에는 AAAA가 없었습니다. 사이트에는 IPv6 주소가 있지만 파일을 내려주는 호스트에는 없으므로, IPv6만 있는 기기는 파일 받기 단계에서 막힙니다. 이중 스택 서버(AWS 서울)에서 IPv6로만 요청해 보니 huggingface.co는 IPv6로 리다이렉트 응답을 줬고, 다음 단계인 us.aws.cdn.hf.co에서 이름 해석에 실패했습니다. 가정 회선과 AWS 서울 모두 같은 호스트로 넘어갔지만, 다른 파일이나 지역에서는 다를 수 있습니다.

AI API — DeepSeek와 Bedrock 기본 엔드포인트에는 없습니다

조회한 AI API 중 Anthropic, OpenAI, Gemini(generativelanguage.googleapis.com), Vertex AI, Mistral, Groq, Together, xAI, OpenRouter에는 AAAA가 있었습니다. DeepSeek(api.deepseek.com)과 AWS Bedrock의 기본 엔드포인트(bedrock-runtime.us-east-1.amazonaws.com)에는 없었습니다.

AWS는 일부 서비스에 IPv6용 이름을 따로 둡니다. ec2.us-east-1.api.aws와 s3.dualstack.us-east-1.amazonaws.com에는 AAAA가 있었습니다. 같은 규칙을 Bedrock 런타임에 적용한 이름 두 개(bedrock-runtime.us-east-1.api.aws, bedrock-runtime.dualstack.us-east-1.amazonaws.com)는 DNS에서 주소가 나오지 않았습니다. Bedrock에 IPv6 엔드포인트가 없다는 증거는 아니고, 이 두 이름으로는 찾지 못했다는 뜻입니다.

국내 서비스 — 조회한 16곳 모두 IPv4만 있습니다

네이버·카카오의 웹과 API, 네이버 클라우드 API 게이트웨이와 CLOVA Studio, 토스페이먼츠·포트원 결제 API, 채널톡·업스테이지·솔라피 API, 쿠팡과 다음 웹까지 AAAA 레코드가 하나도 없었습니다. 3장에서 본 것처럼 SK텔레콤·LG유플러스 이동통신 사용자는 대부분 IPv6를 쓸 수 있는데, 이들이 이 서비스에 접속할 때는 통신사가 제공하는 IPv4 경로로 들어온다는 뜻입니다. 통신사가 그 경로를 어떻게 구성하는지는 이 조회로 알 수 없습니다.

IPv6 전용 서버에서 끊기는 것

IPv6 전용(IPv6-only) 서버는 공인 IPv4 주소 없이 IPv6 주소만 가진 서버입니다. 공인 IPv4 주소에는 요금이 붙으므로 IPv6 전용 서버는 비용을 줄이는 방법으로 검토할 수 있습니다.

AWS 가격 페이지는 직접 가져온 IPv4 대역(BYOIP)에는 이 요금이 붙지 않는다고 적고 있습니다. 가격은 2026-09-25에 확인했습니다.

무엇이 끊기나

4장의 조회를 IPv6 전용 서버의 하루로 옮기면 이렇습니다. npm install, pip install, cargo build, go mod download, docker pull(Docker Hub), apt-get이 호출하는 호스트에는 AAAA 레코드가 있으므로 IPv4 없이 직접 닿을 수 있는 주소가 있습니다(실제 연결은 재지 않았습니다). 반면 다음은 호스트에 IPv6 주소가 없어, IPv4로 나가는 경로가 없으면 실패합니다.

• git clone https://github.com/..., GitHub Actions용 스크립트가 호출하는 api.github.com, 릴리스 파일을 받는 설치 스크립트
• ghcr.io에 올린 컨테이너 이미지
• Hugging Face 모델 파일 받기, DeepSeek API, Bedrock 기본 엔드포인트
• 조회한 국내 결제·로그인·지도·메시지 API 전부

반대 방향도 있습니다. Supabase 문서는 모든 데이터베이스의 직접 연결 주소가 IPv6 주소로 연결된다고 적고(IPv4 애드온을 켜지 않은 기본 상태), 같은 문서에서 Retool·Vercel·GitHub Actions·Render를 IPv4 연결만 지원하는 대표 서비스로 꼽습니다. 이런 환경에서 Supabase에 연결할 때 문서가 권하는 방법은 연결 풀러(Supavisor, 트랜잭션 모드 포트 6543·세션 모드 포트 5432) 주소를 쓰거나, Supabase 클라이언트 라이브러리를 쓰거나, 유료 IPv4 애드온을 켜는 것입니다.

우회하는 법 — NAT64와 DNS64

IPv6 전용 서버가 IPv4 전용 호스트에 닿게 하는 표준 방법은 두 가지를 함께 쓰는 것입니다. DNS64는 AAAA 레코드가 없는 호스트를 질의받으면, A 레코드의 IPv4 주소 앞에 표준 접두사 64:ff9b::/96(RFC 6052)을 붙여 합성한 IPv6 주소를 돌려줍니다. NAT64는 그 주소로 온 IPv6 패킷을 IPv4로 바꿔 내보내고 응답을 다시 IPv6로 돌려줍니다.

AWS 문서에 따르면 NAT 게이트웨이는 NAT64를 별도 설정 없이 지원하고, DNS64는 서브넷 단위로 켭니다. 호스트에 AAAA가 있으면 DNS64는 원래 주소를 그대로 돌려주므로 변환 없이 IPv6로 연결됩니다.

# IPv6 전용 서버가 있는 서브넷에서 DNS64를 켭니다
aws ec2 modify-subnet-attribute --subnet-id subnet-XXXX --enable-dns64

# 합성된 주소(64:ff9b::/96)로 가는 트래픽을 NAT 게이트웨이로 보냅니다
aws ec2 create-route --route-table-id rtb-XXXX \
  --destination-ipv6-cidr-block 64:ff9b::/96 --nat-gateway-id nat-XXXX

# 나머지 IPv6 트래픽은 송신 전용 인터넷 게이트웨이로
aws ec2 create-route --route-table-id rtb-XXXX \
  --destination-ipv6-cidr-block ::/0 --egress-only-internet-gateway-id eigw-XXXX

curl -6이 성공해도 IPv6가 아닐 수 있습니다

curl -6은 IPv6로만 접속하라는 옵션입니다. 이 명령이 성공하면 IPv6가 된다고 보기 쉽습니다. 이 글을 쓴 PC에서 그 가정이 틀렸습니다.

$ curl -6 -sv https://myip.helpmek.com/json
*   Trying [::ffff:172.67.191.248]:443...
* Connected to myip.helpmek.com (::ffff:172.67.191.248) port 443
  ...
  "version": 4,

접속은 성공했지만, 서버가 돌려준 version 값은 4였습니다. 연결한 주소 ::ffff:172.67.191.248은 IPv4 주소를 IPv6 모양으로 적은 IPv4 매핑 주소(RFC 4291 §2.5.5.2)이고, 이 주소로 연 연결은 실제로는 IPv4로 나갑니다. 이 PC에는 공인 IPv6 주소가 없고, 같은 링크 안에서만 쓰는 링크 로컬 주소와 내부망용 ULA(Unique Local Address) 주소만 있었습니다. 운영체제의 주소 해석 함수(getaddrinfo)가 IPv6 주소를 달라는 요청에 IPv4 주소를 매핑 주소로 바꿔 돌려준 것입니다. Python으로 같은 함수를 불러 이 동작을 확인했습니다. 측정 환경은 macOS 26.7, curl 8.7.1입니다.

확인 대상인 myip.helpmek.com에는 AAAA 레코드가 두 개 있습니다. 호스트가 IPv6를 지원하는데도 내 쪽에 IPv6가 없으면 이렇게 IPv4로 조용히 바뀔 수 있습니다.

IPv4·IPv6가 모두 되는 Linux 서버(Ubuntu 24.04, curl 8.5.0)에서는 결과가 달랐습니다. curl -6으로 같은 주소를 부르니 실제 IPv6로 연결됐고 서버가 "version": 6으로 확인했습니다. IPv6 주소가 없는 github.com에는 curl·wget·Python·Node.js·nc를 IPv6로만 접속하게 했을 때 모두 실패했습니다. IPv4를 IPv6 모양으로 바꿔 연결하는 현상은 이번 측정에서는 macOS에서만 나타났습니다.

믿을 수 있는 확인 세 가지

1. 상대 서버가 본 버전을 묻습니다. 내 쪽 명령의 성공 여부가 아니라 서버 로그에 찍힌 주소가 기준입니다.

   $ curl -s https://myip.helpmek.com/json
   # "version": 6 이면 IPv6로 도착한 것, 4면 IPv4입니다

2. AAAA만 있는 호스트로 접속합니다. A 레코드가 없으면 IPv4로 바꿔 줄 주소가 없으므로 결과가 정직합니다. 같은 PC에서 curl -6 https://ipv6.icanhazip.com은 호스트 이름을 해석하지 못해(종료 코드 6) 실패했습니다. 이 실패가 이 PC에서 IPv6로 나갈 수 없다는 실제 상태를 보여 줍니다.
3. 브라우저에서는 두 버전을 따로 시험하는 페이지를 씁니다. 아래 설명한 IPv6 테스트 페이지가 이 방식입니다.

저희가 만든 확인 도구 — myip.helpmek.com

이 글의 확인에 쓴 기능은 세 가지입니다.

• 명령줄 API: curl myip.helpmek.com은 내 공인 IP를 평문으로, /json은 ip·version·asn·organization·국가·도시·시간대를 JSON으로 돌려줍니다. API 문서에 따르면 키가 필요 없고, 두 엔드포인트에는 요청 한도가 없으며 캐시되지 않습니다(Cache-Control: no-store). 서버 배포 스크립트에서 "이 서버가 밖에서 어떤 주소로 보이는가"를 확인할 때 씁니다.
• IPv6 테스트: IPv4로만 접속되는 확인용 호스트(프로브)와 IPv6로만 접속되는 프로브(각각 Cloudflare가 운영하는 ipv4.icanhazip.com·ipv6.icanhazip.com)를 따로 불러 두 버전을 각각 판정하고, 브라우저가 실제로 어느 버전을 골랐는지도 보여 줍니다. 브라우저는 두 주소가 다 있으면 IPv6부터 시도하고 늦으면 IPv4로 넘어가므로(Happy Eyeballs, RFC 8305가 권하는 기본 대기 시간 250ms), 고른 쪽이 IPv4였다고 IPv6가 없다는 뜻은 아닙니다. 이 페이지가 두 버전을 따로 시험하는 이유입니다.
• VPN 점검: VPN이 IPv4만 터널로 보내면 IPv6 연결은 VPN을 거치지 않고 바로 나갈 수 있습니다. VPN을 켠 상태에서 IPv6 트래픽이 VPN을 우회하는 것으로 보이는지 확인합니다.

5장의 NAT64 구성에도 같은 방법을 쓸 수 있습니다. AWS 문서의 동작대로라면 DNS64를 켠 IPv6 전용 서버에서 curl -s https://myip.helpmek.com/json은 AAAA가 있으므로 변환 없이 나가 "version": 6과 서버의 IPv6 주소를 보여 주고, A 레코드만 있는 curl -s https://ipv4.icanhazip.com은 NAT 게이트웨이를 거쳐 그 탄력적 IP를 보여 줘야 합니다. 두 값이 이렇게 나오면 두 경로가 모두 설계대로 동작하는 것입니다.

오늘 할 수 있는 것

1. 서버가 호출하는 외부 호스트를 뽑아 AAAA를 확인하세요. 패키지 저장소만 보지 말고 설치 스크립트가 받는 릴리스 파일, 리다이렉트되는 파일 서버, 결제·로그인·알림 API까지 넣어야 합니다. 이 글에서 AAAA가 없던 곳 대부분이 그런 호스트였습니다.

   # hosts.txt에 한 줄에 하나씩 적은 뒤
   while read h; do
     a=$(dig +short A "$h" | grep -cE '^[0-9.]+$')
     q=$(dig +short AAAA "$h" | grep -c ':')
     printf "%-45s A:%s AAAA:%s %s\n" "$h" "$a" "$q" \
       "$([ "$q" -eq 0 ] && echo '← IPv6 전용이면 NAT64 필요')"
   done < hosts.txt

2. IPv6 전용으로 옮기기 전에 NAT64·DNS64부터 설계하세요. GitHub와 국내 API를 호출하는 서버라면 거의 확실히 필요합니다. 설계 없이 옮기면 배포가 git clone에서 멈춥니다.
3. AAAA를 공개했다면 IPv6 망에서 직접 접속해 보세요. 한국에서는 사무실 유선 회선이 IPv6를 거의 쓰지 않으므로, 휴대폰 이동통신 데이터로 서비스를 열어 보는 것이 가장 간단한 확인입니다. 같은 휴대폰으로 IPv6 테스트를 열면 그 망에서 IPv6가 되는지도 함께 보입니다.
4. 로그·접근 제어·요청 제한이 IPv6 주소를 처리하는지 확인하세요. IPv6에서는 기기가 개인정보 보호를 위해 임시 주소를 주기적으로 바꿉니다. RFC 8981이 정한 기본값은 새 연결에 쓰는 기간 하루, 유효 기간 이틀입니다(운영체제마다 다를 수 있습니다). 주소 하나 단위로 차단하거나 사용자를 세면 같은 기기가 다른 사용자로 잡힙니다. IPv6 서브넷은 보통 /64이므로(RFC 4291은 인터페이스 식별자를 64비트로 정합니다) /64 단위로 묶어 보는 방식을 검토하세요.
5. curl -6의 성공을 IPv6의 증거로 쓰지 마세요. 상대 서버가 본 버전(/json의 version)이나 AAAA만 있는 호스트로 확인하세요.
6. VPN을 쓴다면 IPv6가 VPN을 우회하지 않는지 확인하세요. IPv4만 터널로 보내는 VPN에서는 IPv6 연결이 원래 회선으로 나갈 수 있습니다.

아직 결론이 아닌 것

• 실제 연결은 서버 한 대에서 호스트마다 요청 한 번씩으로 확인했습니다. 응답이 오면 HTTP 상태 코드와 상관없이 성공으로 셌습니다. AWS 서울에서 그 주소가 응답한다는 것까지가 확인된 것이고, 모든 API 호출이나 큰 파일 받기가 IPv6로 끝까지 된다거나 다른 망에서도 같다는 뜻은 아닙니다. 리다이렉트된 다음 호스트가 IPv4 전용일 수도 있습니다(Hugging Face가 그랬습니다).
• 조회 위치는 모두 한국입니다. 가정 회선에서 한 번, AWS 서울 서버에서 약 3분 동안 18번 물었고 결과가 같았습니다. github.com은 미국 대역으로도 물어 확인했지만, 나머지는 다른 나라에서 물으면 답이 다를 수 있습니다. 같은 날 따로 확인한 js.stripe.com은 권한 네임서버 응답 30번 중 15번만 AAAA가 있는 CDN을 가리켜, 한 번의 조회로는 틀릴 수 있는 호스트가 있다는 것도 보여 줬습니다.
• 68곳은 제가 고른 목록입니다. 국내 16곳 전부 AAAA가 없었다는 것이 국내 서비스 전체가 그렇다는 뜻은 아닙니다. 국내에서 IPv6를 지원하는 서비스가 있을 수 있습니다.
• 망의 용도(이동·유선)는 추정입니다. APNIC의 AS 이름과 회사 연혁으로 추정했고, 한 AS에 여러 용도가 섞여 있을 수 있습니다. KT(AS4766)의 이동통신 사용자가 이 AS에 포함되는지도 확인하지 못했습니다.
• 구글과 APNIC의 한국 값 차이(17.42% 대 28.49%)의 원인은 확인하지 못했습니다.
• curl -6이 IPv4로 나간 현상은 macOS 26.7과 curl 8.7.1에서 재현했습니다. 이중 스택 Linux 서버(Ubuntu 24.04, curl 8.5.0)에서는 나타나지 않았습니다. Windows와 다른 macOS 버전은 확인하지 않았습니다.
• AWS NAT64·DNS64 구성은 직접 만들어 보지 않았습니다. 5장과 6장의 설명은 AWS 문서를 옮긴 것입니다. NAT 게이트웨이 요금은 지역마다 다르므로 가격 페이지에서 확인하세요.
• 가격과 조회 결과는 2026-09-25 기준입니다. AAAA 레코드는 언제든 추가될 수 있습니다. 옮기기 전에 다시 조회하세요.

참고자료

1차 출처는 전부 2026-09-25에 직접 열어 확인했습니다. 조회 결과는 자체 측정입니다. 발행 당일 개정: 첫 판은 AAAA 조회만 담았고, 이 판에 이중 스택 서버에서 확인한 실제 연결 결과를 더했습니다.

구글 값은 구글 서비스 이용자 기준이고 APNIC 값은 광고 노출 사용자 기준이어서 서로 직접 비교할 수 없습니다. 이 글의 평균·요일별 값은 구글이 공개한 일별 데이터에서 직접 계산한 파생값입니다.