이전 작업 중 서비스가 멈추면 안 되는 이유
운영 중인 서버나 호스팅사를 옮기는 작업은 언젠가 한 번은 맞닥뜨리게 된다. 성능 문제, 비용, 국내 데이터센터로의 전환 등 이유는 다양하지만 공통적인 걱정은 하나다. 이전 도중 사이트가 몇 시간씩 멈추면 그 시간만큼 매출과 신뢰를 잃는다는 점이다. 다행히 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 전환 후에도 일정 기간 옛 서버를 유지하는 방식으로 이 개념을 적용할 수 있다.
되돌릴 수 있는지는 데이터가 결정한다
주문이나 회원 정보가 계속 쌓이는 사이트에서는 접속 대상을 바꾸는 것과 데이터를 옮기는 것을 따로 설계해야 한다. AWS의 블루-그린 배포 문서는 신규 환경뿐 아니라 롤백할 기존 환경에도 최신 데이터가 필요하다고 설명한다. 전환 뒤 새 서버에만 저장된 주문이 있는데 옛 데이터베이스로 되돌아가면, 그 주문을 조회하지 못할 수 있다는 뜻이다. 이전 계획에는 전환 이후의 변경분을 어디에 기록하고 복구할지도 포함해야 한다.
두 환경이 같은 데이터 저장소를 쓰는 방식은 이런 문제를 줄이는 선택지다. 다만 웹 서버와 데이터베이스를 모두 옮기는 작업이라면 저장소 공유만으로 이전이 끝나지는 않는다. 별도 데이터베이스로 복제하는 구성에서는 변경분이 새 환경에 도착하기까지의 지연을 점검해야 한다. Amazon RDS도 전환 전에 복제 지연을 확인하도록 권고하며, 신규 환경에서 시험 삼아 쓰기를 수행하면 복제 충돌이나 의도하지 않은 데이터가 생길 수 있다고 경고한다.
데이터 구조를 뜻하는 스키마 변경도 이전 작업과 분리하는 편이 안전하다. AWS는 기존 프로그램과 함께 쓸 수 있도록 필드를 먼저 추가하거나, 새 프로그램이 기존 구조에서도 동작하도록 만드는 방식을 안내한다. 반대로 옛 프로그램이 사용하는 필드를 삭제하면 그 프로그램으로 돌아갈 수 없게 된다. 서버를 남겨두었는지만 확인하지 말고, 기존 프로그램이 현재 데이터 구조를 읽고 저장할 수 있는지도 되돌리기 조건에 넣어야 한다.
검색로봇이 들어오는 길도 열어둔다
호스팅사를 바꾸는 일과 페이지 주소를 바꾸는 일은 검색엔진에서 구분된다. Google은 사용자에게 보이는 주소가 그대로인 호스팅 이전과, 도메인이나 경로가 달라지는 이전에 서로 다른 지침을 제공한다. 주소까지 바꾼다면 기존 페이지와 새 페이지의 대응 관계 및 리디렉션을 별도로 준비해야 한다. 서버 이전과 사이트 개편을 함께 계획했다면 변경을 나누어 진행하는 편이 문제의 원인을 좁히기 쉽다.
테스트 사이트의 검색 노출을 막으려고 넣어둔 설정은 공개 전에 다시 점검한다. robots.txt의 크롤링 차단이나 HTML·HTTP 헤더의 noindex가 운영 사이트에 남아 있으면 검색로봇의 수집 또는 색인 등록을 막을 수 있다. Google은 방화벽과 서비스 거부 공격 방어 설정이 Googlebot 접근을 차단하지 않는지도 확인하도록 안내한다. 브라우저로 페이지가 열린다는 사실과 검색로봇이 접근할 수 있다는 사실을 따로 검증해야 하는 이유다.
Search Console 소유권을 HTML 파일로 인증했다면 인증 파일도 새 호스팅에 복사해야 한다. 메타 태그로 인증했다면 새 페이지 템플릿에 해당 태그가 유지되는지 확인한다. 공개 후에는 Search Console의 URL 검사로 접근 상태를 확인하고 색인 관련 보고서를 관찰한다. Google은 호스팅 이전 직후 크롤링 속도가 일시적으로 낮아졌다가 며칠에 걸쳐 늘어날 수 있다고 설명한다. 수집량 감소만으로 장애를 단정하기보다 접근 오류나 서버 지연이 함께 나타나는지 확인하는 편이 낫다.
전환 순서 체크리스트
- 이전 최소 24~48시간 전: 도메인 TTL을 300초로 낮춘다.
- 새 서버에 애플리케이션·DB·SSL을 세팅하고 IP 직접 접속으로 기능을 검증한다.
- 이전 직전: 옛 서버의 데이터베이스를 최종 동기화해 새 서버에 반영한다.
- DNS A 레코드를 새 서버 IP로 변경한다.
- 전환 후 최소 24시간은 옛 서버를 끄지 않고 유지하며 트래픽 로그로 전환 상태를 확인한다.
- 모든 트래픽이 새 서버로 완전히 넘어온 것을 확인한 뒤 TTL을 원래 값으로 되돌리고 옛 서버를 정리한다.
이메일도 함께 챙긴다
도메인을 이전할 때 가장 자주 놓치는 부분이 메일이다. 웹사이트용 A 레코드만 바꾸고 MX 레코드를 그대로 두면 메일은 옛 서버로 계속 들어오게 되고, 반대로 MX까지 성급하게 옮기면 메일 서버 설정이 끝나지 않은 상태에서 수신 장애가 날 수 있다. 웹과 메일은 별개의 레코드로 관리되므로 전환 계획에 각각을 따로 표시해두는 편이 안전하다.
정리
무중단 이전의 핵심은 결국 준비 시간을 충분히 확보하는 것이다. TTL을 미리 낮추고, 새 서버를 완전히 검증한 뒤에 전환하고, 문제가 생겼을 때 되돌아갈 수 있는 옛 서버를 바로 지우지 않는 것. 이 세 가지만 지켜도 사용자가 이전 사실조차 알아채지 못하는 수준으로 작업을 마칠 수 있다.
