DNS 캐시와 전파 지연 완전 가이드 : 도메인 변경 후 '어떤 사람만' 안 되는 현상 이해

DNS 캐시와 전파 지연은 도메인 변경 후 어떤 사람만 사이트가 안 되는 상황에서 원인을 좁히는 기준이 된다.

서버는 정상인데 내 폰에서는 열리고, 거래처 PC에서는 "사이트에 연결할 수 없음"이 뜨는 경우가 있다.

이때 문제는 서버 자체보다 "어디가 예전 정보를 들고 있느냐"에 달린 경우가 많다. DNS는 도메인 이름을 IP로 바꾸는 과정이고, 이 과정에는 캐시와 전파(퍼짐)라는 특성이 붙는다.

처음엔 도메인을 바꿨으니까 모든 사람이 새 서버로 바로 가야 한다고 생각했다. 하지만 DNS 캐시 개념을 배우니까 일부만 못 붙는 이유가 명확해졌다.

도메인 변경 후 "어떤 사람만" 접속이 안 되는 장면

이 현상은 단순한 서버 장애가 아니라, 여러 계층의 DNS 캐시가 다른 시점에 업데이트되는 것에서 나온다.

같은 건물에서도 휴대폰과 PC가 다른 결과를 보이는 경험을 하게 된다면, 그것이 바로 DNS 전파 지연을 직접 관찰하는 것이다.

핵심 개념 1: DNS 캐시가 무엇인지, 왜 남아 있는지

DNS 캐시는 도메인→IP 변환 결과를 잠시 저장해 다음 요청을 더 빠르게 처리하는 저장본이다.

핵심 특징은 캐시가 한 군데만 있는 것이 아니라는 점이다. 브라우저, 운영체제, 공유기, 통신사 DNS, 회사 내부 DNS, 그리고 CDN/리졸버까지 여러 계층에 저장될 수 있다.

또 다른 특징은 캐시의 유효기간이 TTL(Time To Live)로 관리된다는 점이다. TTL 동안은 "예전 IP"를 계속 쓰는 사용자가 생길 수 있다.

주의점은 캐시가 '악성'이 아니라 정상 동작이라는 점이다. 캐시가 없으면 DNS 조회가 느려지고, 트래픽이 불필요하게 늘어난다.

핵심 개념 2: DNS 전파 지연이란 무엇이며 왜 사람마다 다르게 보이는가

DNS 전파 지연은 도메인 정보가 갱신된 뒤, 전 세계의 리졸버와 캐시에 새 값이 반영되기까지 시간이 걸리는 현상이다.

핵심 특징은 "동시에 바뀌지 않는다"는 점이다. 어떤 사용자는 새 IP로 이미 바뀌었는데, 다른 사용자는 TTL이 남아 예전 IP로 계속 접근한다.

또 다른 특징은 사용자가 쓰는 DNS 경로가 다르다는 점이다. 같은 집 안에서도 휴대폰은 이동통신 DNS를, PC는 공유기/통신사 DNS를 쓰면 결과가 달라질 수 있다.

주의점은 전파 지연이 "DNS 레코드만"의 문제가 아닐 수 있다는 점이다. CDN 캐시, 브라우저의 HSTS, 프락시, 회사 보안 장비가 "예전 경로"를 유지해 비슷한 증상을 만들기도 한다.

DNS 캐시가 남는 위치와 사용자별 다른 결과

DNS 캐시 vs 전파 지연을 구분하는 비교표

현상은 비슷해 보여도 "캐시가 남아서" 안 되는지, "전파가 덜 끝나서" 안 되는지에 따라 확인 순서가 달라진다.

항목	DNS 캐시가 원인인 경우	DNS 전파 지연이 원인인 경우
주요 특징	특정 기기/브라우저/회사망에서만 지속된다.	같은 사용자라도 DNS 서버를 바꾸면 결과가 달라진다.
확인 포인트	로컬 캐시를 비우면 즉시 개선되는 경우가 있다.	권한(Authoritative)에는 새 값이 있으나 리졸버가 옛 값을 준다.
흔한 오해	서버가 다운됐다고 판단하고 롤백을 서두른다.	"전파는 몇 분이면 끝난다"로 단정한다.

YES/NO 체크리스트로 원인 후보 빠르게 좁히기

• YES: 같은 네트워크에서 어떤 기기는 되고 어떤 기기는 안 되는가?
• YES: 휴대폰 LTE/5G에서는 되는데 집 와이파이에서는 안 되는가(또는 반대인가)?
• YES: 접속이 안 되는 사람에게서 "예전 IP"로 해석되는 흔적이 보이는가?
• YES: DNS 서버(예: 다른 공용 DNS)로 바꾸면 즉시 결과가 달라지는가?
• YES: 도메인 변경 직후부터 1~2시간 내에 증상이 집중되어 있는가?

네 번째가 YES면 전파 지연 또는 리졸버 캐시 영향 가능성이 커진다. 첫 번째가 YES면 로컬/사내 DNS 캐시 계층을 우선 의심한다.

실전 점검 절차: "어디에 옛 DNS가 남아 있는지" 찾는 순서

핵심은 "같은 도메인을 서로 다른 DNS 경로로 조회해 결과를 비교"하는 것이다.

1. 현재 기대하는 IP를 확정한 다경로: DNS 관리 콘솔에서 A/AAAA 레코드 확인
2. 체크 포인트: 새 IP, TTL 값, 레코드 타입을 기록한다.
3. 문제 사용자에게서 실제 조회 결과를 확보한 다경로: nslookup 또는 dig
4. 체크 포인트: 응답 IP와 TTL 잔여값을 함께 확인한다.
5. DNS 서버를 바꿔 재조회한다경로: 같은 명령에서 서버 지정 또는 네트워크 DNS 변경
6. 체크 포인트: 다른 서버에서는 새 IP가 나오는데 기존 서버만 옛 IP면 리졸버 캐시 가능성이 크다.
7. 로컬 캐시 계층을 정리한 다경로: 브라우저 DNS 캐시/OS DNS 캐시 플러시
8. 체크 포인트: 플러시 후에도 동일하면 상위(공유기/ISP/사내)로 올라간다.
9. 공유기/사내 DNS를 확인한 다경로: 공유기 재부팅 또는 사내 DNS 서버 캐시 정책 확인
10. 체크 포인트: 내부 DNS가 자체 캐시를 오래 유지하는지 본다.
11. 전파 대기/완화 전략을 적용한 다경로: TTL 전략, 임시 안내
12. 체크 포인트: TTL 만료 예상 시점을 기준으로 고객 공지와 모니터링을 맞춘다.

실전 예시: 일부 고객만 "사이트를 찾을 수 없음"이 뜨는 경우

상황: 도메인 A 레코드를 새 서버 IP로 바꾼 직후, 일부 고객이 접속 실패를 겪는다.

나도 이런 상황을 겪으면서 한동안 헤맸다. 서버는 정상인데 왜 안 되지? 싶어서 불필요한 롤백까지 했던 경험이 있다.

오해/착각으로 "변경했으니 전 세계가 바로 새 서버로 가야 한다"를 떠올리기 쉽다. 그러나 TTL이 남아 있으면 일부는 계속 예전 IP를 사용한다.

현장감 있는 확인 결과는 다음처럼 나타날 수 있다(표시는 예시다).

nslookup 예시(샘플)
Name:    example.com
Address: 203.0.113.10

추가 정보(샘플)
TTL remaining: 1420 seconds

이 결과가 "예전 IP"이고 TTL이 아직 남아 있다면, 그 사용자는 리졸버 또는 로컬 캐시가 만료되기 전까지 같은 값을 받을 수 있다.

여기서 적합한 선택은 두 가지다. 하나는 TTL 만료를 기다리며 고객에게 "특정 네트워크에서만 지연될 수 있다"는 안내를 제공하는 방식이다.

다른 하나는 임시 우회 안내를 준비하는 방식이다. 예를 들어 다른 DNS 서버로 변경하거나, 모바일 데이터로 접속해 보도록 안내해 원인이 DNS 경로 차이인지 바로 확인할 수 있다.

잘못 처리하면 "서버가 문제다"로 결론 내리고 불필요한 롤백이나 재배포를 반복해 장애 시간을 늘릴 수 있다.

확인은 "안 되는 사용자"와 "되는 사용자"가 동일 도메인을 조회했을 때 IP가 다르게 나오는지로 끝장을 볼 수 있다.

DNS 캐시와 전파 지연 점검 6단계 흐름

배포·운영 체크리스트: DNS 변경 시 불필요한 장애를 줄이기

• 사전 준비: 변경 1~2일 전 TTL을 낮춰(300~600초) 전파 지연을 단축할 준비를 한다.
• 변경 직후: 여러 리졸버(8.8.8.8, 1.1.1.1 등)로 조회해 결과가 일관성 있는지 확인한다.
• 고객 공지: "네트워크별로 1~2시간 반영 시간 차이가 있을 수 있다"는 안내를 미리 제공한다.
• 모니터링: 변경 후 2~3시간 동안 주기적으로 여러 위치/네트워크에서 접속 테스트를 진행한다.
• 사후 관리: TTL을 정상값(3600~86400초)으로 복원해 불필요한 DNS 조회를 줄인다.

결론

DNS 캐시는 조회를 빠르게 하기 위해 여러 위치에 남고, TTL이 남아 있으면 일부 사용자는 예전 IP로 계속 접근할 수 있다.

DNS 전파 지연은 리졸버별 캐시 만료 시점이 달라서 생기며, DNS 서버를 바꿔 조회하면 차이가 드러나는 경우가 많다.

지금은 도메인 변경 후 일부만 안 되는 현상을 냉정하게 분석할 수 있어서, 불필요한 롤백이나 서버 재배포를 피할 수 있게 됐다.

도메인 변경 후 "어떤 사람만" 안 될 때는 기대 IP 확정→여러 리졸버 비교→로컬/공유기/사내 캐시 순으로 확인하면 불필요한 롤백을 줄일 수 있다.

다음 글에서는 "TTL 설계: 변경 빈도와 안정성의 균형", "CDN과 도메인: 원본 서버 전환 시 캐시 무효화 전략", "HSTS와 브라우저 캐시: DNS 레코드 없이도 캐시 되는 경우"를 다룰 예정이다. DNS 운영을 더 깊게 이해하려면 꼭 읽어보길 추천한다!

FAQ

Q1. DNS 변경 후 전파는 보통 얼마나 걸리는가?

정해진 "고정 시간"은 없고 TTL과 리졸버 캐시 정책에 따라 달라진다.

관리 콘솔에서 설정한 TTL이 길수록 일부 사용자가 예전 값을 더 오래 볼 가능성이 커진다.

Q2. 내 폰에서는 되는데 회사 PC에서만 안 되는 이유는 무엇인가?

회사 네트워크가 자체 DNS 서버를 쓰거나 보안 장비를 통해 DNS를 중계해 캐시 계층이 하나 더 생길 수 있다.

이 경우 같은 도메인이라도 회사 DNS가 예전 IP를 주는 동안 회사 PC만 실패하는 현상이 나타난다.

Q3. 가장 빠른 확인 방법은 무엇인가?

문제 기기에서 nslookup/dig로 나온 IP를 확인하고, 다른 DNS 서버로 다시 조회해 결과가 달라지는지 비교하는 방식이 빠르다.

결과가 다르면 DNS 캐시/전파 지연 가능성이 높고, 결과가 같으면 서버/라우팅/방화벽 쪽을 함께 의심한다.

Q4. TTL을 미리 낮추면 얼마나 빨리 반영되는가?

TTL을 낮추면 기존 캐시가 더 빨리 만료되므로 새 값으로 업데이트될 가능성이 높아진다.

다만 이미 캐시 된 긴 TTL 값을 줄인다고 해서 과거 캐시가 즉시 삭제되는 것은 아니므로, 변경 24~48시간 전부터 미리 낮추는 방식이 효과적이다.