8.8.8.8 DNS가 항상 빠르지는 않은 이유: CDN 라우팅과 ISP DNS의 차이

웹사이트가 느릴 때는 "DNS를 8.8.8.8이나 1.1.1.1 등 글로벌 업체의 빠른 DNS로 바꾸면 빨라진다"라는 이야기를 종종 들을 수 있습니다. 실제로 8.8.8.8(Google 퍼블릭 DNS), 1.1.1.1(Cloudflare) 공개 DNS는 상당히 빠르고 안정적인 편입니다. 장애 대응도 좋고, 전세계에 걸친 애니캐스트 인프라도 잘 갖추어져 있습니다.

그런데 이것이 곧 모든 환경에서 가장 빠른 DNS 라는 뜻은 아닙니다. 특히 CloudFront, Akamai, Fastly 같은 CDN을 사용하는 웹사이트에서는 DNS가 단순히 "주소를 알려주는 역할"에서 끝나지 않습니다. 어떤 DNS 리졸버를 쓰느냐에 따라 어느 나라의 CDN Edge로 접속할지가 달라질 수 있습니다.

저희 홈페이지 stdl.kr도 비슷한 관찰 사례가 있었습니다. stdl.kr은 AWS CloudFront CDN을 통해 웹페이지를 서비스하고, 인증 세션과 동적 응답 특성 때문에 캐시를 적극적으로 사용하지 않도록 설계되어 있습니다. 이 상태에서 8.8.8.8로 DNS 질의를 하면 일본 쪽 AWS CloudFront CDN이 잡히고, KT 회선의 ISP DNS로 질의하면 한국 쪽 AWS CloudFront CDN이 잡히는 경우가 있었습니다.

이 글에서는 왜 이런 일이 생기는지, 그리고 가정이나 사무실 네트워크에서 DNS를 고를 때 어떤 기준으로 판단하면 좋은지 정리합니다.

DNS 응답속도와 웹사이트 실제 접속 속도의 차이
DNS 정보를 기반으로 가까운 Edge를 골라주는 CDN
1.1.1.1이 8.8.8.8보다 불리할 수 있는 부분
stdl.kr 사례로 보는 DNS와 CDN Edge 차이
용도가 다른 글로벌 공개 DNS와 ISP DNS
직접 확인하는 방법
사무실 네트워크에서 사용할 DNS
운영 팁과 주의사항

DNS 응답속도와 웹사이트 실제 접속 속도의 차이

DNS만 따로 보면 8.8.8.8, 1.1.1.1의 응답 시간이 매우 빠르게 나오는 경우가 많습니다. 예를 들어 DNS 질의 자체가 5ms, 10ms 안에 끝나면 "이 DNS가 제일 빠르다"고 판단하기 쉽습니다.

하지만 웹사이트 접속 속도가 DNS 응답 시간만으로 결정되는 건 아닙니다. 보통 웹페이지 하나를 열 때 다음과 같은 과정을 거칩니다.

도메인 DNS 조회
응답받은 IP의 서버 또는 CDN Edge로 TCP 연결
HTTPS라면 TLS 협상
CDN Edge가 캐시에 있는 콘텐츠를 주거나, 캐시에 없으면 Origin 서버로 요청 토스
HTML, 이미지, 스크립트, API 응답을 받아 클라이언트에서 렌더링

여기서 DNS 조회는 첫 단계일 뿐입니다. DNS 응답이 5ms 빨라도, 그 결과로 어느 지역의 CDN Edge를 받는지에 따라 이후 TCP, TLS, TTFB(Time To First Byte), Origin 왕복 시간이 더 크게 달라질 수 있습니다.

DNS 정보를 기반으로 가까운 Edge를 골라주는 CDN

CDN(Content Delivery Network)은 사용자를 가능한 가까운 Edge 서버로 보내기 위해 여러 정보를 활용합니다. 그중 하나가 DNS입니다.

일반적으로 사용자가 어떤 도메인에 접속하면, 사용자의 기기가 직접 권한 DNS 서버에 묻지 않고 재귀 DNS 리졸버(Recursive DNS Resolver) 에 물어봅니다. 가정에서는 보통 공유기가 ISP DNS를 받고, PC나 스마트폰은 공유기를 DNS로 사용합니다. 반대로 사용자가 수동으로 8.8.8.8이나 1.1.1.1을 지정하면 공개 DNS 리졸버를 사용하게 됩니다.

CDN 입장에서는 "이 요청이 어느 지역 사용자에게서 왔는지"를 알아야 가까운 Edge를 줄 수 있습니다. 이때 판단 기준은 대략 다음과 같습니다.

기준	설명
DNS 리졸버의 위치	사용자가 ISP DNS를 쓰면 대체로 사용자의 회선망과 가까운 위치로 추정하기 쉽습니다.
ECS 지원 여부	ECS(EDNS Client Subnet)를 지원하면 리졸버가 사용자의 IP 일부를 잘라서 권한 DNS 쪽에 전달할 수 있습니다.
CDN 사업자의 정책	CDN마다 DNS 기반 라우팅, Anycast, 실시간 트래픽 상태, 장애 회피 정책이 다릅니다.
ISP와 CDN의 피어링	같은 국가라도 ISP와 CDN 사이의 연결 품질에 따라 체감 속도가 달라질 수 있습니다.

여기서 중요한 개념이 ECS(EDNS Client Subnet) 입니다. ECS는 DNS 리졸버가 사용자의 전체 IP가 아니라 일부 네트워크 대역 정보를 권한 DNS 서버에 전달할 수 있게 해 주는 확장 기능입니다. CDN은 이 정보를 참고해 "이 사용자는 한국 KT망 쪽에 가까우니 한국 Edge를 주는 것이 낫겠다"처럼 판단할 수 있습니다.

반대로 ECS가 없으면 권한 DNS 서버는 사용자가 아니라 DNS 리졸버의 위치 를 기준으로 추정해야 합니다. 공개 DNS가 전 세계 Anycast 구조로 동작하고, 해당 질의가 어느 노드에서 처리되는지에 따라 CDN 응답이 달라질 수 있는 이유입니다.

1.1.1.1이 8.8.8.8보다 불리할 수 있는 부분

여기에서 Cloudflare가 제공하는 1.1.1.1이 속도 면에서 8.8.8.8에 비해 불리할 수 있는 부분이 나옵니다. Cloudflare의 1.1.1.1은 개인정보 보호를 중요하게 설계된 공개 DNS입니다. 이 방향 자체는 장점이지만, CDN 라우팅 관점에서는 때때로 불리하게 작용할 수 있습니다.

핵심은 1.1.1.1이 일반적으로 ECS를 보내지 않는다는 점 입니다. 사용자의 네트워크 위치를 권한 DNS 서버에 전달하지 않기 때문에, CDN이나 지리 기반 DNS가 사용자의 실제 위치를 더 세밀하게 판단하기 어렵습니다.

반면 Google Public DNS의 8.8.8.8은 조건이 맞는 권한 DNS 서버에 대해 ECS를 활용할 수 있습니다. 그래서 일부 CDN 환경에서는 8.8.8.8이 1.1.1.1보다 더 적절한 CDN Edge를 받는 경우가 생길 수 있습니다.

Cloudflare의 선택은 성능보다 프라이버시를 우선한 설계 에 가깝습니다. DNS 선택은 결국 아래의 균형 문제입니다.

선택지	장점	주의할 점
ISP DNS	국내 CDN, 통신사망 피어링, 지역 기반 응답에서 유리할 수 있습니다.	ISP DNS 장애나 정책 영향을 받을 수 있습니다.
Google Public DNS	안정적이고 ECS 기반 지리 응답에서 유리한 경우가 있습니다.	모든 도메인에서 항상 최적 Edge를 보장하지는 않습니다.
Cloudflare 1.1.1.1	개인정보 보호, 응답 속도, DoH/DoT 사용성이 좋습니다.	ECS 미전달 정책 때문에 일부 CDN 라우팅에서 불리할 수 있습니다.
내부 DNS/로컬 리졸버	사무실, NAS, 내부 도메인, 보안 정책을 통제하기 좋습니다.	구성 품질이 낮으면 오히려 장애 지점이 됩니다.

stdl.kr 사례로 보는 DNS와 CDN Edge 차이

저희 홈페이지 stdl.kr은 AWS CloudFront CDN을 기반으로 방문자에게 가장 빠른 Edge로부터 데이터를 전달하는 방식을 운영 중입니다. 실제 운영 환경에서 DNS를 바꿔 질의해 보면, 같은 도메인이라도 응답되는 AWS CloudFront CDN 위치가 다르게 관찰됩니다.

예를 들어 다음과 같은 식입니다.

DNS 리졸버	결과
`8.8.8.8`	일본 쪽 AWS CloudFront CDN으로 연결
KT ISP DNS	한국 쪽 AWS CloudFront CDN으로 연결

이 차이는 정적 이미지 하나를 받을 때보다, 캐시가 잘 먹지 않는 HTML 응답이나 인증 세션이 걸린 요청 에서 더 중요해질 수 있습니다. CDN Edge가 캐시된 파일을 바로 주면 Origin까지 가지 않아도 되지만, 캐시하지 않는 응답은 Edge가 Origin 서버로 다시 요청해야 합니다.

만약 방문자가 한국에 있고 웹사이트의 Origin도 한국 또는 한국과 가까운 위치에 있는데, DNS 결과 때문에 일본 Edge로 먼저 들어간다면 경로가 다음처럼 길어질 수 있습니다.

한국 사용자
  -> 일본 CloudFront Edge
  -> 한국 Origin
  -> 일본 CloudFront Edge
  -> 한국 사용자

반대로 한국 Edge로 들어가면 경로가 아래처럼 작동하며 지리적으로 더 가까운 만큼 응답 속도도 빨라집니다.

한국 사용자
  -> 한국 CloudFront Edge
  -> 한국 Origin
  -> 한국 CloudFront Edge
  -> 한국 사용자

Origin이 한국에 가깝고 캐시 미스나 동적 요청 비중이 높다면, 한국 CDN Edge를 받는 쪽이 당연히 유리합니다.

용도가 다른 글로벌 공개 DNS와 ISP DNS

공개 DNS는 분명한 장점이 있습니다. 다음과 같은 경우에는 장점이 있을 수 있습니다.

ISP DNS 장애가 잦거나 응답 품질이 불안정한 경우
DNS over HTTPS, DNS over TLS 같은 암호화 DNS를 적극적으로 쓰려는 경우
기기와 회선이 자주 바뀌는 노트북, 모바일, 외근 환경
특정 보안 필터링, 악성 도메인 차단, 가족 보호 DNS가 필요한 경우
ISP DNS의 정책이나 캐시 상태를 우회해 장애를 진단해야 하는 경우

반대로 ISP DNS나 내부 DNS가 더 나은 경우도 있습니다.

국내 사용자가 국내 CDN 또는 국내 Origin 기반 서비스를 많이 쓰는 경우
사무실에서 NAS, 프린터, 그룹웨어, 내부 서버 도메인을 함께 운영하는 경우
Active Directory, 내부 DNS Zone, Split-horizon DNS를 쓰는 업무망
통신사망과 CDN 사이의 피어링 품질이 중요한 환경
CDN Edge 위치가 실제 업무 서비스의 응답 속도에 큰 영향을 주는 경우

WARNING

회사나 병원, 학원, 제조 현장처럼 내부 서버와 NAS를 함께 쓰는 네트워크에서는 DNS를 임의로 8.8.8.8로 바꾸면 내부 도메인, 파일 서버, 프린터, 인증 서버 연결이 깨질 수 있습니다. 업무망에서는 DNS를 단순 속도 튜닝 값이 아니라 인프라 설계 요소 로 봐야 합니다.

직접 확인하는 방법

DNS 차이는 추측보다 실측이 중요합니다. macOS나 리눅스에서는 dig를 쓰면 편하고, Windows에서는 WSL, PowerShell의 Resolve-DnsName, 또는 nslookup을 사용할 수 있습니다.

가장 먼저 DNS 응답이 실제로 다른지 확인합니다.

# Google Public DNS
dig @8.8.8.8 mysite.com A +short

# Cloudflare 1.1.1.1
dig @1.1.1.1 mysite.com A +short

# KT DNS
dig @168.126.63.1 mysite.com A +short

CNAME 체인이 있는 도메인이라면 CNAME도 함께 확인합니다.

dig @8.8.8.8 mysite.com CNAME +short
dig @168.126.63.1 mysite.com CNAME +short

IP가 다르게 나온다면, 해당 IP로 HTTPS 접속 시간을 비교할 수 있습니다. curl --resolve를 쓰면 DNS만 우회하면서 Host와 SNI는 원래 도메인으로 유지할 수 있습니다.

curl -o /dev/null -s \
  --resolve mysite.com:443:여기에_8.8.8.8에서_받은_IP \
  -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
  https://mysite.com/

curl -o /dev/null -s \
  --resolve mysite.com:443:여기에_KT_DNS에서_받은_IP \
  -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
  https://mysite.com/

여기서 특히 볼 값은 ttfb와 total입니다. DNS 조회 자체는 --resolve 때문에 거의 의미가 없고, 실제 비교 대상은 연결 이후 첫 응답이 얼마나 빨리 오는지입니다.

TIP

ping만으로 CDN 품질을 판단하지 않는 것이 좋습니다. 많은 CDN과 클라우드 사업자는 ICMP 응답을 실제 HTTPS 트래픽과 다르게 처리하거나 우선순위를 낮게 둘 수 있습니다. 가능하면 curl, 브라우저 개발자 도구, mtr, 실제 페이지 로딩 시간을 함께 보는 편이 정확합니다.

사무실 네트워크에서 사용할 DNS

사무실, 매장, 병원, 학원, 디자인 스튜디오처럼 여러 사용자가 같은 회선을 쓰는 환경에서는 DNS를 PC마다 제각각 넣기보다 공유기, 방화벽, 내부 DNS에서 일관되게 관리하는 편이 좋습니다.

보통 다음과 같이 구성하는 경우가 많습니다.

환경	권장 방향
일반 가정	ISP DNS와 공개 DNS를 직접 비교해 실제 사용 속도가 빠른 쪽을 선택합니다.
소규모 사무실	공유기 또는 방화벽에서 DNS를 중앙 관리하고, DHCP로 클라이언트에 배포합니다.
NAS 운영 환경	NAS, 백업 서버, 내부 서비스 이름 해석을 고려해 내부 DNS 또는 로컬 리졸버를 둡니다.
보안이 중요한 업무망	DNS 필터링, 로그, 내부 도메인, 장애 대응까지 포함해 설계합니다.
CDN 성능이 중요한 서비스	ISP DNS, Google Public DNS, Cloudflare, Quad9 등을 실제 서비스 기준으로 비교합니다.

특히 "기본 DNS는 KT, 보조 DNS는 8.8.8.8"처럼 섞어 넣는 구성을 조심해야 합니다. 많은 사용자가 보조 DNS를 단순한 장애 대비용으로 생각하지만, 운영체제나 공유기, 브라우저, 앱에 따라 보조 DNS가 평소에도 질의될 수 있습니다.

그 결과 같은 사무실 안에서도 어떤 사용자는 한국 CDN Edge를 받고, 어떤 사용자는 일본 또는 다른 지역 Edge를 받는 식의 차이가 생길 수 있습니다.

CAUTION

기본 DNS와 보조 DNS는 항상 "1번이 죽었을 때만 2번을 쓴다"는 방식으로 동작하지 않습니다. 업무망에서 CDN 위치, 내부 도메인, 보안 필터링의 일관성이 중요하다면 서로 성격이 다른 DNS를 무심코 섞지 않는 것이 좋습니다.

운영 팁과 주의사항

DNS를 바꾸기 전에 아래와 같이 확인하면 좋습니다.

첫째, 브라우저의 보안 DNS 설정 을 확인해야 합니다. 운영체제나 공유기 DNS를 바꿔도 Chrome, Edge, Firefox가 자체 DNS over HTTPS 설정으로 다른 리졸버를 사용할 수 있습니다. 이 경우 공유기에서 설정한 DNS와 실제 브라우저 질의 DNS가 달라집니다.

둘째, DNS 캐시와 TTL 을 고려해야 합니다. DNS를 바꾼 직후에도 운영체제, 브라우저, 공유기, 로컬 DNS 캐시에 이전 결과가 남아 있을 수 있습니다. 테스트할 때는 캐시를 비우거나 충분한 시간을 두고 여러 번 측정해야 합니다.

셋째, 정적 파일과 동적 페이지를 구분 해야 합니다. 이미지, CSS, JavaScript처럼 CDN Edge에 잘 캐시되는 파일은 Edge 위치의 영향이 상대적으로 작을 수 있습니다. 반대로 HTML, API, 로그인 세션처럼 Origin 왕복이 잦은 요청은 Edge와 Origin 사이의 거리도 중요해집니다.

넷째, DNS만으로 모든 네트워크 품질을 설명할 수는 없습니다. CDN 라우팅은 DNS뿐 아니라 BGP, Anycast, ISP 피어링, CDN 내부 부하, 장애 회피 정책을 함께 봅니다. DNS 변경은 빠르게 시도할 수 있는 튜닝 포인트이지만, 최종 판단은 실제 서비스 응답 시간으로 해야 합니다.

마치며

8.8.8.8과 1.1.1.1은 좋은 공개 DNS입니다. 다만 이게 내 환경에서 가장 빠른 속도를 제공하는 DNS가 되지는 않습니다.

국내 사용자가 국내 Origin 또는 국내 CDN을 많이 쓰는 환경에서는 ISP DNS가 더 자연스러운 CDN Edge를 돌려줄 수 있습니다. 반대로 개인정보 보호, 암호화 DNS, 회선 독립성, 장애 우회가 중요하면 공개 DNS가 더 적합할 수 있습니다.

핵심은 하나입니다.

DNS는 단순한 주소록이 아니라, CDN 라우팅과 서비스 체감 속도에 영향을 주는 네트워크 설계 요소입니다.

가정에서는 직접 비교해 보면 되고, 업무망에서는 내부 도메인, NAS, 보안 정책, CDN 성능까지 함께 놓고 설계하는 것이 좋습니다. 특히 여러 사용자가 같은 서비스를 반복적으로 사용하는 사무실이라면 DNS 하나만 정리해도 체감 품질이 달라지는 경우가 있습니다.