서버를 옮길 때 도메인과 DNS 체크리스트

서버 이전의 성패는 전환 당일이 아니라 준비 단계에서 갈립니다. 어느 도메인 이름이 어느 IP를 가리키는지 전부 적어 두고, TTL을 미리 낮추고, hosts 파일로 새 서버를 실제 도메인 이름으로 먼저 검증하면 전환은 레코드 값 한두 개를 바꾸는 짧은 작업이 됩니다. 서버 이전은 도메인 등록기관 이전과 무관하므로 등록기관이나 네임서버는 건드리지 않아도 됩니다.

이 문서는 IP가 바뀌는 서버 이전을 다룹니다. 네임서버나 DNS 제공자 자체를 옮기는 경우는 절차가 달라지므로 운영 중인 서비스 무중단 이관을 보세요. 그쪽 문서에 TTL 설계와 전파 검증이 자세히 들어 있어 여기서는 반복하지 않습니다.

준비 시작 시점

전환 예정일 기준 최소 2일 전 (기존 TTL이 길면 더 앞서)

선검증 방법

로컬 hosts 파일로 도메인 이름 그대로 새 서버 점검

옛 서버 유지

전환 뒤 최소 48시간, 권장 1주일

1. 인벤토리를 먼저 만듭니다

"웹사이트만 옮기면 된다"고 생각했다가 빠뜨리는 것이 이 단계에서 드러납니다. 옛 서버 IP를 가리키는 모든 이름과, 그 IP를 등록해 둔 모든 바깥 설정을 적습니다.

• DNS 존에서 옛 서버 IP를 값으로 가진 레코드 전부 (apex, www, api, admin, 스테이징, 캠페인용 하위 도메인)
• 메일 관련 레코드 (MX, SPF에 적힌 IP, 발송 전용 하위 도메인)
• 외부 서비스에 등록해 둔 허용 IP 목록 (결제사, 문자 발송, 오픈 API, 거래처 방화벽, 데이터베이스 접근 허용 IP)
• 콜백과 웹훅 수신 주소, 그리고 상대가 IP로 화이트리스트를 걸어 둔 경우
• 크론 작업과 배치, 외부로 나가는 연동의 출발 IP
• 모니터링과 로그 수집 대상에 적힌 IP와 호스트 이름
• SSL 인증서 파일 위치와 만료일, 갱신 방식

표 한 장으로 정리하면 충분합니다. 이름, 레코드 종류, 현재 값, 전환 후 값, 현재 TTL, 담당자 정도를 열로 둡니다. 현재 값은 조회로 확인해 실제 응답을 기준으로 적습니다.

dig +short example.com A
dig +short www.example.com A
dig +short example.com MX
dig +short example.com TXT

레코드 종류와 의미는 DNS 레코드 종류와 입력 방법에 정리되어 있습니다.

2. TTL을 낮추고 전환 시각을 정합니다

전환 전에 TTL을 낮추는 이유는 빠르게 바뀌기 위해서가 아니라 빠르게 되돌리기 위해서입니다.

1. 현재 TTL을 확인합니다

   dig example.com A +noall +answer
   

   응답 줄의 숫자가 현재 TTL입니다. 86400이면 24시간입니다.

2. 기존 TTL만큼 앞서 값을 낮춥니다

   전환 대상 레코드의 TTL을 300초 정도로 낮춥니다. 낮춘 값이 전 세계 리졸버에 반영되려면 기존 TTL만큼 기다려야 하므로, 기존이 24시간이면 최소 하루 전에 낮춰야 합니다.

3. 전환 시각을 트래픽이 가장 적은 시간대로 정합니다

   전환 자체는 짧지만 문제가 생겼을 때 대응 시간이 필요합니다. 작업 창은 예상 소요의 두 배 이상으로 잡고, 담당자가 붙어 있을 수 있는 시간으로 정합니다.

4. 공지 대상과 문구를 미리 준비합니다

   내부 공지, 고객 공지, 연동 거래처 통보를 각각 준비합니다. 정지 시간이 있다면 시작과 종료 예정 시각을 숫자로 적습니다.

전파는 일괄로 끝나지 않습니다. 낮춘 TTL이 반영되었는지는 여러 리졸버에서 직접 확인하세요.

dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer

3. 새 서버를 hosts 파일로 먼저 검증합니다

새 서버를 IP로 직접 열어 보는 점검은 한계가 있습니다. 많은 애플리케이션이 호스트 이름을 기준으로 동작하고, 리다이렉트와 쿠키 도메인, 절대 경로 링크, 인증 콜백이 도메인 이름에 묶여 있기 때문입니다. 로컬 hosts 파일을 쓰면 나만 새 서버로 접속하면서 도메인 이름은 그대로 유지할 수 있습니다.

macOS와 리눅스는 /etc/hosts, 윈도우는 C:\Windows\System32\drivers\etc\hosts 에 한 줄을 추가합니다.

203.0.113.50  example.com www.example.com

이 상태로 점검할 항목입니다.

• 메인 페이지와 주요 화면이 정상 렌더링되는지
• 로그인과 세션 유지, 로그아웃
• 파일 업로드와 다운로드, 이미지 경로
• 결제와 외부 인증 콜백 (테스트 모드로)
• 관리자 화면과 배치 작업 수동 실행
• 메일 발송 (수신지에 도착하는지, 발신 도메인 인증이 통과하는지)
• 데이터베이스 연결과 캐시, 백그라운드 작업 큐
• 로그가 정상 기록되고 권한 문제가 없는지
• HTTPS 가 동작하고 인증서 이름이 맞는지

서버 기본 설정이 덜 되어 있다면 VPS 첫 세팅을 먼저 끝내고 오세요. 옮겨 갈 곳이 Plesk 기반 웹호스팅이라면 제어판에서 도메인과 문서 루트, 데이터베이스, 메일 계정을 먼저 만들어 두어야 hosts 파일 검증이 의미가 있습니다. 준비 순서는 웹호스팅 첫 세팅에 있습니다. 자체 장비를 데이터센터에 들이는 경우라면 코로케이션 입고 준비와 절차가 선행 작업입니다.

레토 클라우드 인스턴스끼리 옮긴다면 콘솔의 이미지 복제로 옛 서버를 그대로 찍어 새 서버를 올릴 수 있습니다. 패키지와 설정을 처음부터 다시 맞추지 않아도 되므로 선검증 단계가 짧아지고, 복제한 이미지에는 옛 서버의 호스트 이름과 IP 설정, 크론 작업이 함께 따라오므로 새 서버에서 IP 관련 설정과 크론만 정리하면 됩니다.

4. 데이터 동기화와 정지 시간 계산

정지 시간은 DNS 전파가 아니라 데이터 동기화에서 생깁니다. 전파 중에는 양쪽이 모두 응답하지만, 양쪽이 서로 다른 데이터를 쓰면 그때부터 문제가 됩니다.

1. 먼저 전체를 한 번 복사합니다

   전환 며칠 전에 파일과 데이터베이스 전체를 새 서버로 옮깁니다. 이때는 시간이 오래 걸려도 괜찮습니다.

   rsync -az --delete /var/www/ deploy@203.0.113.50:/var/www/
   

2. 차이만 반복해서 따라잡습니다

   같은 명령을 여러 번 돌려 변경분만 전송되게 합니다. 마지막 회차가 몇 분 안에 끝나는 상태가 되면 전환 준비가 된 것입니다. 이 마지막 소요 시간이 곧 최소 정지 시간입니다.

3. 쓰기를 멈출 구간을 정합니다

   데이터베이스는 파일과 달리 중간 상태를 복사하면 깨질 수 있습니다. 읽기 전용 모드나 점검 페이지로 쓰기를 잠시 막고, 그 시점의 덤프를 새 서버에 적용하는 방식이 가장 단순합니다. 복제를 걸어 두고 전환 직전에 역할만 바꾸는 방법도 있지만 준비가 더 필요합니다.

4. 정지 시간을 숫자로 확정합니다

   쓰기 차단, 마지막 동기화, 적용, 기본 동작 확인까지 더한 값이 공지할 정지 시간입니다. 여유를 더해 공지하고 실제로는 그보다 짧게 끝나는 편이 낫습니다.

세션, 업로드 파일, 캐시, 크론 작업은 빠뜨리기 쉬운 항목입니다. 세션 저장소가 서버 로컬에 있다면 전환과 함께 전체 로그아웃이 발생합니다. 크론은 양쪽에서 동시에 돌면 중복 처리가 생기므로, 전환 전까지 새 서버에서는 꺼 두었다가 전환과 함께 켜고 옛 서버에서 끕니다.

5. 전환, 병행 운영, 인증서와 메일

레코드 값을 바꾸는 순간부터 양쪽이 동시에 서비스되는 기간이 시작됩니다.

1. 전환 직전 상태를 스냅샷으로 남깁니다

   레토 클라우드 인스턴스는 콘솔에서 스냅샷을 뜰 수 있습니다. 쓰기를 막은 시점에 옛 서버와 새 서버 양쪽에서 한 장씩 떠 두면 되돌릴 기준 시점이 분명해집니다. 스냅샷 없이 전환하면 롤백 수단이 DNS 레코드를 되돌리는 것뿐이어서, 디스크 상태가 이미 바뀐 경우에는 손쓸 방법이 없습니다.

2. A 레코드 값을 새 IP로 바꿉니다

   A 레코드를 먼저 하나만 바꿔 확인한 뒤 나머지를 바꾸는 방법도 안전합니다. 옛 레코드를 삭제하는 것이 아니라 값을 교체하는 것입니다.

3. 실제 응답을 확인합니다

   dig +short example.com A
   curl -sI https://example.com | head -n 1
   

   여러 리졸버와 외부 회선에서 같이 확인합니다. 사내망에서만 확인하면 캐시 때문에 오판할 수 있습니다.

4. 옛 서버를 내리지 않고 그대로 둡니다

   최소 48시간, 권장 1주일입니다. 옛 서버에서 데이터를 계속 쓰게 두면 데이터가 갈라지므로, 옛 서버는 새 서버로 전달만 하게 두거나 읽기 전용 안내 화면으로 바꿉니다. 옛 서버 접근 로그를 보면 아직 옛 IP로 오는 요청이 얼마나 남았는지 알 수 있습니다.

5. 인증서를 확인하고 자동 갱신을 세웁니다

   인증서 파일을 복사했다면 체인과 권한, 만료일을 확인합니다. 새로 발급한다면 전환 후 바로 발급하고 갱신 타이머가 도는지 확인합니다.

   echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
   

   인증서 종류와 선택 기준은 SSL 인증서에 있습니다.

6. 메일과 발송 IP를 맞춥니다

   서버에서 메일을 보낸다면 SPF에 적힌 IP를 새 주소로 고칩니다. MX가 이 서버를 가리킨다면 수신 쪽도 함께 전환 대상입니다. 레코드 설정은 SPF, DKIM, DMARC에, 발송 IP가 바뀔 때 확인할 항목은 메일 도달률 높이기에 정리되어 있습니다.

6. 롤백 조건과 전환 후 정리

되돌릴 기준을 미리 정해 두지 않으면, 문제가 생긴 순간에 고칠지 되돌릴지로 시간을 흘려보냅니다. 전환 전에 조건을 문장으로 적어 두세요.

이 중 하나라도 해당하면 되돌립니다

• 작업 창 안에 주요 기능 점검을 통과하지 못함
• 결제, 로그인, 메일 수신 중 하나라도 정상 동작하지 않음
• 오류율이 평소 대비 뚜렷하게 올라가고 원인이 바로 잡히지 않음
• 데이터 정합성이 의심되는 징후가 보임

롤백은 A 레코드 값을 옛 IP로 되돌리는 것으로 시작합니다. TTL을 미리 낮춰 두었다면 몇 분 안에 반영됩니다. 옛 서버를 그대로 띄워 두었다면 여기서 끝나고, 옛 서버를 이미 건드렸다면 전환 직전에 떠 둔 스냅샷으로 그 시점 상태를 복원합니다. 전환 뒤 새 서버에 들어온 쓰기 데이터를 어떻게 처리할지도 미리 정해 두어야 합니다. 이것이 쓰기를 잠시 막고 전환하는 방식을 권하는 이유입니다.

안정화가 확인되면 정리합니다

• TTL을 원래 값으로 되돌리기 (낮은 TTL을 계속 두면 질의량이 늘어납니다)
• 옛 서버 접근 로그에 유입이 멈춘 것을 확인한 뒤 서비스 중지, 스냅샷 한 장을 남긴 다음 반납
• 인벤토리의 외부 등록 IP가 모두 새 값으로 반영되었는지 재확인
• 모니터링과 알림 대상의 IP와 호스트 이름 갱신
• 백업이 새 서버에서 정상 생성되는지 확인하고 복원을 한 번 시험
• 문서와 관리 대장의 서버 정보 갱신 (IP, 용도, 담당자, 결제 주체)
• 옛 서버의 접속 키와 권한 회수

마지막 확인은 감시가 실제로 붙어 있는지입니다. 무엇을 보고 어떤 임계값에서 알림을 받을지는 서비스 감시와 장애 알림 기본에 정리했습니다.