이전 작업 중 서비스가 멈추면 안 되는 이유
운영 중인 서버나 호스팅사를 옮기는 작업은 언젠가 한 번은 맞닥뜨리게 된다. 성능 문제, 비용, 국내 데이터센터로의 전환 등 이유는 다양하지만 공통적인 걱정은 하나다. 이전 도중 사이트가 몇 시간씩 멈추면 그 시간만큼 매출과 신뢰를 잃는다는 점이다. 다행히 DNS와 배포 방식을 제대로 이해하고 준비하면 사용자가 눈치채지 못할 정도로 이전을 마칠 수 있다.
DNS TTL부터 미리 낮춰둔다
TTL(Time To Live)은 DNS 캐시 서버가 도메인의 IP 정보를 얼마나 오래 기억해둘지를 정하는 값이다. 평소 TTL을 3600초(1시간)나 그 이상으로 길게 잡아둔 도메인이 많은데, 이 상태로 갑자기 IP를 바꾸면 일부 사용자는 새 서버로, 일부는 여전히 옛 서버로 접속하는 상황이 최대 TTL 시간만큼 이어진다. 이전을 계획한 시점보다 최소 하루 전, TTL을 300초 안팎으로 낮춰두는 것이 첫 단계다. 이렇게 하면 실제 전환 시점에 DNS 변경 사항이 대부분의 사용자에게 5분 안에 반영된다.
새 서버를 먼저 완성한다
이전은 옛 서버를 끄고 새 서버를 켜는 작업이 아니라, 새 서버를 완전히 준비해놓고 나서 트래픽을 옮기는 작업이다. 새 서버에 애플리케이션, 데이터베이스, SSL 인증서까지 전부 설치하고, 도메인을 연결하지 않은 상태에서 IP 주소나 hosts 파일 수정으로 미리 접속해 정상 동작을 확인한다. 이 단계에서 이미지·CSS·API 호출까지 깨진 부분이 없는지 점검하고, 데이터베이스는 옛 서버와 동기화된 최신 상태를 유지해둔다.
블루-그린 방식으로 전환한다
같은 역할을 하는 두 개의 서버 그룹(블루=기존, 그린=신규)을 동시에 띄워두고, 로드밸런서나 DNS 레코드에서 트래픽 대상만 블루에서 그린으로 바꾸는 방식이 블루-그린 배포다. 전환 자체는 설정 변경 몇 줄로 끝나기 때문에 사용자 입장에서는 순간적으로 바뀌는 것처럼 보인다. 문제가 생기면 다시 블루로 돌려놓기만 하면 되므로 롤백도 빠르다. 이전 프로젝트라면 옛 서버(블루)를 그대로 살려둔 채 새 서버(그린)를 준비하고, DNS 전환 후에도 일정 기간 옛 서버를 유지하는 방식으로 이 개념을 적용할 수 있다.
전환 순서 체크리스트
- 이전 최소 24~48시간 전: 도메인 TTL을 300초로 낮춘다.
- 새 서버에 애플리케이션·DB·SSL을 세팅하고 IP 직접 접속으로 기능을 검증한다.
- 이전 직전: 옛 서버의 데이터베이스를 최종 동기화해 새 서버에 반영한다.
- DNS A 레코드를 새 서버 IP로 변경한다.
- 전환 후 최소 24시간은 옛 서버를 끄지 않고 유지하며 트래픽 로그로 전환 상태를 확인한다.
- 모든 트래픽이 새 서버로 완전히 넘어온 것을 확인한 뒤 TTL을 원래 값으로 되돌리고 옛 서버를 정리한다.
이메일도 함께 챙긴다
도메인을 이전할 때 가장 자주 놓치는 부분이 메일이다. 웹사이트용 A 레코드만 바꾸고 MX 레코드를 그대로 두면 메일은 옛 서버로 계속 들어오게 되고, 반대로 MX까지 성급하게 옮기면 메일 서버 설정이 끝나지 않은 상태에서 수신 장애가 날 수 있다. 웹과 메일은 별개의 레코드로 관리되므로 전환 계획에 각각을 따로 표시해두는 편이 안전하다.
정리
무중단 이전의 핵심은 결국 준비 시간을 충분히 확보하는 것이다. TTL을 미리 낮추고, 새 서버를 완전히 검증한 뒤에 전환하고, 문제가 생겼을 때 되돌아갈 수 있는 옛 서버를 바로 지우지 않는 것. 이 세 가지만 지켜도 사용자가 이전 사실조차 알아채지 못하는 수준으로 작업을 마칠 수 있다.
