TTL 설계, 이전 전에 낮추고 끝난 뒤 올립니다

보관 시간은 전환 속도를 그대로 정합니다

레코드의 보관 시간은 중간 해석기가 그 답을 얼마나 오래 들고 있을지를 정합니다. 그래서 이 값이 사이트 이전이나 서버 교체의 전환 속도를 결정합니다. 2026년 10월 19일 공식 문서에서 확인한 값으로, 프록시를 통과하는 레코드는 보관 시간이 자동으로 300초, 즉 5분으로 고정됩니다. 프록시를 쓰지 않는 레코드는 60초에서 1일 사이에서 고를 수 있고, 상위 요금제에서는 30초부터 가능합니다. 기본값이 1일로 되어 있는 경우가 많은데, 1일은 86,400초이므로 24시간 동안 예전 주소가 계속 쓰일 수 있다는 뜻입니다.

낮추고 바꾸고 올리는 세 단계를 지킵니다

전환 작업의 순서는 정해져 있습니다. 1단계는 보관 시간을 낮추는 것입니다. 바꾸기 최소 하루 전에 낮춰야 이전 값이 만료되어 새 값이 빠르게 퍼집니다. 당일에 낮추면 이미 퍼진 긴 보관 시간이 그대로 남아 효과가 없습니다. 2단계는 레코드를 바꾸는 것입니다. 3단계는 전환이 끝난 뒤 보관 시간을 다시 올리는 것입니다. 짧게 유지하면 조회 요청이 늘어 비용과 지연이 증가하므로 평시에는 긴 값이 유리합니다. 이 세 단계를 일정표에 날짜로 적습니다. 특히 3단계를 빠뜨리면 평시에 계속 짧은 값으로 운영되어 불필요한 조회가 쌓입니다.

전환 대기 시간을 숫자로 비교합니다

학습용 가정으로 계산합니다. 프록시 레코드의 보관 시간 300초는 300을 60으로 나눈 5분입니다. 기본값 1일인 레코드는 86,400초이고 3,600으로 나누면 24시간입니다. 24시간은 1,440분입니다. 중간 계산값으로 두 경우를 비교하면 1,440을 5로 나눈 288배의 차이입니다. 즉 보관 시간을 낮추지 않고 전환하면 최악의 경우 288배 긴 시간 동안 예전 주소로 가는 요청이 남습니다. 최종 판단은 되돌리기 시간으로 합니다. 문제가 생겨 되돌릴 때도 같은 보관 시간이 적용되므로, 짧게 두는 것은 복구 속도를 확보하는 일이기도 합니다.

보관 시간을 지키지 않는 해석기가 있습니다

결론을 뒤집는 조건은 중간 해석기의 동작입니다. 일부 해석기와 운영체제, 애플리케이션은 보관 시간을 무시하고 더 오래 결과를 들고 있습니다. 그래서 보관 시간을 5분으로 낮춰도 일부 사용자는 더 긴 시간 동안 예전 주소로 접속합니다. 대응 방법은 양쪽을 동시에 살려 두는 것입니다. 전환 뒤에도 예전 서버를 일정 기간 유지하고 새 서버로 넘기는 처리를 두면, 늦게 따라오는 요청도 정상 처리됩니다. 그래서 전환 계획에는 예전 서버 유지 기간을 날짜로 적습니다. 기간이 끝나기 전에 예전 서버 접속 기록이 0이 되는지 확인한 뒤 종료합니다.

웹호스팅 실행 전 점검표

• 레코드별 현재 보관 시간을 확인했다
• 변경 최소 하루 전에 보관 시간을 낮췄다
• 전환 뒤 보관 시간을 다시 올리는 일정을 적었다
• 예전 서버 유지 기간과 접속 기록 확인 절차를 정했다