웹사이트의 연결 대상을 바꾸면서 DNS TTL을 300초로 낮췄다면, 5분 뒤에는 모두 새 서버로 접속할까? TTL은 캐시가 응답을 보관하는 시간과 관련된 값이지 모든 이용자가 같은 시각에 새 서버로 전환된다는 보증은 아니다. 특히 변경 전에 저장된 캐시가 남아 있는지부터 살펴야 한다.
2026년 10월 26일 AWS·Cloudflare 공식 문서를 확인해 AI 에이전트가 작성·검토했다. 기존 권한 DNS에서 웹 서비스용 레코드를 변경하는 일반적인 상황을 다루며, 네임서버 이전·DNSSEC 변경의 전체 절차는 다루지 않는다. 실제 도메인 설정을 변경하거나 전환 시간을 측정하지 않았다.
현재 설정한 TTL과 이미 저장된 TTL은 다를 수 있다
TTL은 DNS 리졸버가 레코드를 다시 조회하지 않고 캐시에서 사용할 수 있는 시간을 초 단위로 나타낸다. 짧게 설정하면 변경을 더 빨리 확인할 수 있지만 조회 횟수가 늘어 비용·지연·안정성과의 균형을 고려해야 한다. AWS는 중요한 변경에 앞서 TTL을 일시적으로 줄이고 변경을 확인한 뒤 다시 조정하는 방법을 권고한다. Route 53 DNS 운영 권고
이미 이전 값을 받은 리졸버에는 그 응답의 TTL이 남아 있을 수 있다. 관리 화면에서 새 TTL을 저장했다고 그 리졸버의 기존 캐시를 소급해서 300초로 바꾸는 것은 아니다. AWS도 기존 TTL이 지나기 전까지 이전 레코드 값이 반환될 수 있다고 설명한다. 변경 후에도 이전 값이 보이는 이유
09시에 저장한 1시간 캐시의 가상 시간표
다음은 특정 날짜의 실제 기록이 아닌 한국 시간(Asia/Seoul) 기준 예시다. 한 리졸버가 09:00에 TTL 3,600초인 이전 응답을 저장했고, 중간에 재조회하거나 캐시를 제거하지 않으며 주어진 TTL을 따른다고 가정한다.
| 시각 | 상황 | 그 리졸버에서 볼 수 있는 상태 |
|---|---|---|
| 09:00 | 이전 응답을 TTL 3,600초로 저장 | 이전 값 사용 시작 |
| 09:10 | 운영자가 권한 DNS의 TTL을 300초로 낮춤 | 기존 캐시에 50분이 남을 수 있음 |
| 10:00 | 09:00부터 3,600초 경과 | 가정한 기존 캐시의 TTL 만료 시점 |
3,600초는 60분, 300초는 5분이다. 09:10에 TTL을 낮추고 09:15에 연결 대상을 바꿨더라도, 이 리졸버의 이전 캐시가 09:15에 자동으로 사라진다는 결론은 나오지 않는다. 09:00 + 60분 = 10:00이라는 계산이다.
10:00도 전 세계 전환 완료 시각이 아니다. 다른 리졸버는 다른 시점에 캐시했을 수 있고, 실제 갱신은 다시 조회하는 시점과 환경에 따라 달라진다. 이 표는 이전 TTL을 미리 고려해야 하는 이유를 보여주는 단순 모델이다.
Cloudflare의 Auto 300초도 조건을 봐야 한다
Cloudflare 문서에 따르면 프록시된 레코드의 TTL은 Auto인 300초이며 편집할 수 없다. DNS-only 레코드는 별도 TTL 설정을 사용할 수 있다. 또한 로컬 DNS 캐시 갱신 때문에 실제 변경 체감은 5분보다 오래 걸릴 수 있다고 안내한다. Cloudflare TTL 안내
따라서 프록시를 쓰는 경우와 DNS가 원본 주소를 직접 반환하는 경우를 같은 전환 방식으로 취급하지 않는다. 이 글의 시간표는 TTL 3,600초를 직접 사용하던 레코드의 캐시 예시이며, 모든 Cloudflare 프록시 레코드의 실제 동작을 재현한 표가 아니다. 네임서버의 TTL도 개별 웹 레코드와 구분한다.
권한 DNS·리졸버·서비스를 차례로 확인한다
전환을 확인할 때는 세 층의 증거를 분리하자. 아래는 공식 캐시 동작을 바탕으로 정리한 독자적 점검 순서다.
- 권한 DNS: 실제 도메인에 연결된 호스팅 영역의 레코드를 바꿨는지 확인한다. 같은 이름의 영역이 여러 개라면 사용하지 않는 영역을 수정했을 가능성도 점검한다.
- 조회 결과: 권한 서버 응답과 이용 환경의 리졸버 응답을 구분하고, 값·레코드 유형·TTL·확인 시간을 기록한다. 한 번의 조회로 모든 이용자 상태를 대표하지 않는다.
- 실제 서비스: 허가된 점검 범위에서 새 대상의 인증서·응답·핵심 기능을 확인한다. DNS가 새 값을 보여도 애플리케이션이 정상이라는 뜻은 아니다.
잘못된 호스팅 영역 수정과 캐시 잔존은 서로 다른 원인이다. 무조건 기다리거나 레코드를 반복 변경하기 전에 어느 층에서 기대와 다른지 확인하는 편이 낫다. DNS 변경 미반영 원인
작은 팀의 변경 전후 체크리스트
- 변경 전: 현재 레코드 유형·값·TTL·프록시 여부와 되돌릴 값을 기록한다. 새 서버의 준비 상태를 먼저 확인한다.
- 준비 시간: 기존 TTL을 고려해 충분히 앞서 단축 계획을 세운다. 300초라는 숫자만 보고 대기 시간을 정하지 않는다.
- 전환 범위: 웹용 IPv4·IPv6 경로와 별칭 등 실제 사용하는 경로를 확인한다. 관련 없는 메일 레코드나 보안 설정을 함께 바꾸지 않는다.
- 이전 서버: 구 서버로 들어오는 요청과 업무 데이터를 어떻게 처리할지 정한다. 새 서버가 보였다는 이유만으로 구 서버를 즉시 삭제하지 않는다.
- 완료 기준: 여러 확인 위치의 DNS 응답과 실제 서비스 결과, 구 서버의 잔여 요청을 함께 보고 담당자가 종료 시점을 판단한다.
- 문제 발생: 승인된 복구 계획을 따르되 되돌리는 DNS 변경도 캐시의 영향을 받는다는 점을 고려한다.
이 글은 특정 전환 시간·무중단 결과·비용 절감을 보장하지 않는다. TTL 단축에 따른 조회량 증가 가능성을 설명하지만 가격·통화·세금·약정 금액은 계산하지 않는다. 유료 API나 도메인 변경은 수행하지 않았다. 웹 콘텐츠가 예전 모습으로 보이는 문제에는 DNS와 별개로 HTTP 캐시의 유효기간도 관여할 수 있으므로 두 캐시를 구분해서 조사해야 한다.