DNS 전파는 왜 최대 48시간이나 걸리나 — TTL의 원리

가이드 · 2026-08-19 최종 확인

서버를 이전하거나 도메인 IP를 바꾼 뒤 "왜 아직도 예전 서버로 연결되지?"라는 질문을 한 번쯤 겪어봤을 겁니다. DNS 설정 화면에는 분명 새 값이 저장돼 있는데, 실제로는 며칠씩 예전 값이 계속 보이는 경우도 있습니다. 이 현상의 정체는 서버 간 "전파"가 느려서가 아니라, 전 세계에 흩어진 수많은 DNS 캐시가 각자 다른 시점에 만료되기 때문입니다. 그 만료 시점을 결정하는 값이 바로 TTL입니다.

1. TTL이 실제로 하는 일

TTL(Time To Live)은 도메인의 권한 있는 네임서버가 각 DNS 레코드에 붙이는 값으로, 초 단위입니다. "이 답을 얼마 동안 캐시해도 되는지"를 리졸버(내 ISP의 DNS 서버, 회사 네트워크의 DNS 서버, 운영체제, 브라우저 등 실제로 조회를 대신 처리해주는 모든 중간 단계)에게 알려주는 지시입니다. 리졸버는 TTL이 만료되기 전까지는 다시 권한 네임서버에 물어보지 않고, 캐시해둔 이전 답을 그대로 재사용합니다.

2. "전파"는 사실 방송이 아니라 수만 개의 개별 만료다

흔히 "DNS가 전 세계에 전파된다"는 표현을 쓰지만, 실제로는 어딘가에서 새 값을 능동적으로 밀어 보내는 과정이 아닙니다. 도메인을 바꾼 그 순간에도 권한 네임서버는 이미 새 값을 갖고 있습니다. 문제는 전 세계에 흩어진 무수한 리졸버들이 저마다 다른 시점에 예전 값을 캐시해뒀다는 점입니다. 어떤 리졸버는 방금 캐시해서 TTL이 거의 다 남았고, 어떤 리졸버는 이미 만료 직전일 수 있습니다. 즉 "전파 시간"의 정체는 이 흩어진 캐시들이 각자의 타이머대로 하나씩 만료되며 새 값을 다시 받아가는 시간입니다.

3. 그럼 "최대 48시간"은 어디서 나온 숫자인가

낮은 TTL(예: 300초)이 붙은 레코드는 이론상 전 세계에 최대 몇 분~몇 시간 안에 퍼집니다. 그런데도 "최대 48시간"이 관용적인 안전 기준으로 널리 쓰이는 이유는, 일부 등록기관·리졸버가 과거에 매우 긴 TTL(24시간 이상)을 기본값으로 쓰거나 권장했고, 일부 ISP·기업망 리졸버는 TTL 만료 시점에 정확히 재조회하지 않고 자체적인 주기적 갱신 스케줄을 따르는 경우가 있었기 때문입니다. 즉 48시간은 "보통 이렇게 오래 걸린다"는 뜻이 아니라, 느리게 반응하는 소수의 예외적 캐시까지 포함한 보수적인 안전 여유값입니다.

4. 실전 전략: 변경 전에 TTL부터 낮춰라

서버 이전처럼 예정된 DNS 변경이 있다면, 실제 값을 바꾸기 며칠~몇 시간 전에 먼저 TTL만 낮춰두는 것이 표준적인 방법입니다. 이렇게 하면:

1. TTL을 낮추는 그 순간에는 기존(긴) TTL이 아직 유효하므로, 낮춘 TTL 값 자체가 퍼지는 데는 원래 설정돼 있던 만큼의 시간이 걸립니다.
2. 하지만 일단 대부분의 리졸버가 짧아진 TTL을 인식하고 나면, 그 이후 실제 IP를 변경하는 진짜 전환 작업은 훨씬 빠르게(짧아진 TTL만큼만) 전 세계에 반영됩니다.

반대로 아무 준비 없이 TTL이 긴 상태에서 곧바로 IP를 바꾸면, 원래의 긴 TTL이 만료될 때까지 예전 서버로 계속 트래픽이 흘러들어갈 수 있습니다.

자주 묻는 질문