거의 무중단으로 웹사이트를 새 호스트로 마이그레이션하는 방법

마이그레이션이 다운타임을 유발하는 이유 (그리고 이를 피하는 방법)

대부분의 웹사이트 이전에서 발생하는 장애는 파일 전송의 어려움이 아니라 "DNS 전파(propagation)" 때문입니다. 핵심 문제는 리졸버가 도메인 레코드를 얼마나 오래 캐싱할지 결정하는 DNS TTL(Time To Live) 설정에서 비롯됩니다. 도메인을 새 서버로 리디렉션할 때 TTL 값이 높으면 방문자는 몇 분에서 몇 시간 동안 계속 기존 서버에 접속할 수 있습니다. 이 기간 중에 기존 인프라를 폐기하면 요청이 유실됩니다.

해결책은 전환 기간 동안 원래 사이트를 유지하면서 새 호스트에 완전한 복제본을 구축하고, 전환 전에 철저히 테스트하며, 빠른 전환을 위해 사전에 TTL을 낮춘 뒤에야 DNS 레코드를 수정하는 것입니다. 이 접근 방식은 WordPress, Laravel, 맞춤형 애플리케이션 등 다양한 플랫폼에서 작동하며 전용 서버와 관리형 호스팅 계정 모두에 적용됩니다.

1단계 — 먼저 DNS TTL을 낮추기 (24~48시간 전)

이 기초 단계는 다른 모든 작업에 앞서 진행해야 합니다. TTL은 DNS 리졸버가 레코드를 얼마나 오래 캐싱할지 제어합니다. 14400초(4시간) TTL은 전환 시간을 상당히 늘릴 수 있습니다.

DNS 제공업체를 통해 A, AAAA, CNAME, www 레코드의 TTL 값을 300초(5분)로 변경하세요.

Type   Name    Value             TTL
A      @       <OLD_SERVER_IP>   300
A      www     <OLD_SERVER_IP>   300

중요: 이 단계에서는 IP 주소를 변경하지 말고 TTL만 수정하세요. 캐싱된 모든 사본이 만료되도록, 다음 단계로 넘어가기 전에 이전 TTL 기간만큼 기다리세요. 전환 후에는 TTL을 3600 이상으로 되돌릴 수 있습니다.

2단계 — 새 호스트 프로비저닝 및 파일 복사

새 호스팅 플랫폼에서 계정 또는 서버를 생성하세요. 나중에 참조할 수 있도록 새 서버의 IP 주소를 기록해 둡니다.

SSH 접근이 가능한 서버의 경우, rsync는 효율적이고 재개 가능한 파일 전송을 제공하며 권한도 보존합니다.

rsync -avz --progress -e ssh /var/www/html/ user@NEW_SERVER_IP:/var/www/html/

플래그 의미:

• -a 권한, 소유권, 타임스탬프, 심볼릭 링크를 유지합니다
• -v 자세한 출력을 활성화하며, -z 전송 중 압축합니다
• 원본 경로 끝의 슬래시는 디렉터리 자체가 아니라 디렉터리의 내용을 복사합니다

cPanel 간 전송의 경우, 내장 백업 유틸리티나 제공업체 지원 전송이 일반적으로 수동 rsync 작업보다 우수합니다.

3단계 — 데이터베이스 마이그레이션

원래 서버에서 데이터베이스를 내보냅니다.

mysqldump -u DB_USER -p --single-transaction --quick DB_NAME > backup.sql

--single-transaction 플래그는 활성 사이트를 잠그지 않고 일관된 InnoDB 스냅샷을 제공합니다. 새 서버로 전송하여 가져옵니다.

scp backup.sql user@NEW_SERVER_IP:~/
mysql -u DB_USER -p NEW_DB_NAME < backup.sql

애플리케이션 구성을 새 데이터베이스 자격 증명으로 업데이트하세요 — WordPress는 wp-config.php, Laravel은 .env, 또는 그에 상응하는 설정 파일입니다.

4단계 — DNS를 변경하기 전에 새 사이트 테스트하기

이 단계는 기존 사이트를 계속 운영하면서 새 서버를 완전히 검증할 수 있게 하여 다운타임을 방지합니다. 로컬 hosts 파일을 편집하여 본인 기기에서만 도메인이 새 IP로 해석되도록 하세요.

macOS/Linux에서는 /etc/hosts를 수정하고, Windows에서는 C:\Windows\System32\drivers\etc\hosts를 편집합니다.

NEW_SERVER_IP   example.com www.example.com

이제 브라우저는 새 서버에서 로드되는 반면, 전 세계 트래픽은 여전히 원래 서버에 접속합니다. 페이지가 로드되는지, 인증이 작동하는지, 폼이 정상적으로 제출되는지, SSL이 올바르게 작동하는지, 이메일 라우팅이 그대로 유지되는지 확인하세요. 발견된 문제를 모두 수정합니다. 모든 것이 정상적으로 작동하면 hosts 항목을 제거하세요.

검증 체크리스트:

• 페이지가 500/데이터베이스 오류 없이 렌더링됨
• 로그인 세션 및 관리자 접근이 정상 작동함
• 폼 제출 및 결제 프로세스가 데이터베이스에 도달함
• SSL 인증서가 올바르게 검증됨
• 이메일이 예상대로 계속 라우팅됨

5단계 — 최종 동기화 및 DNS 전환

최종 동기화 중 새 데이터 쓰기를 방지하기 위해 원래 사이트에서 유지보수 모드 또는 읽기 전용 모드를 활성화하세요. rsync를 다시 실행하고(변경 사항만 복사) 최근 수정 사항을 반영하도록 최종 mysqldump/가져오기를 수행합니다. 그런 다음 DNS를 업데이트하세요.

Type   Name    Value             TTL
A      @       <NEW_SERVER_IP>   300
A      www     <NEW_SERVER_IP>   300

300초 TTL이면 대부분의 방문자가 5분 이내에 전환됩니다. 캐싱된 DNS 레코드를 여전히 사용하는 사용자에게 서비스를 제공하여 요청 유실을 방지하기 위해, 전환 후 24~48시간 동안 원래 서버를 유지하세요.

6단계 — 이메일, SSL, 검증을 잊지 마세요

• 이메일(MX 레코드): 웹사이트 마이그레이션 중에는 MX 레코드를 변경하지 마세요. 이메일 호스팅은 별도의 단계가 필요한 별개의 프로세스입니다.
• SSL: DNS 변경 직후 HTTPS가 즉시 작동하도록, 전환 전에 새 호스트에서 새 인증서를 발급받으세요(Let's Encrypt 또는 제어판을 통한 자동 SSL).
• 전파 확인: 여러 위치에서 DNS 해석을 확인하세요.

dig +short example.com

모든 리졸버가 새 IP를 가리킬 때까지 여러 네트워크에서 명령을 실행하거나 글로벌 DNS 전파 확인 도구를 사용하세요.

7단계 — 전환 후

모든 트래픽 마이그레이션이 완료되고 기존 서버가 며칠간 유휴 상태를 유지한 후:

1. 안정성과 DNS 조회 감소를 위해 TTL을 다시 3600 이상으로 높입니다.
2. 원래 서버의 최종 백업을 만든 다음 폐기합니다.
3. 모니터링 시스템, 크론 작업, 애플리케이션이나 방화벽에 하드코딩된 IP를 업데이트합니다.
4. 운영 중인 새 환경에서 최종 테스트를 수행합니다.

마이그레이션 체크리스트

• [ ] TTL을 300으로 낮춤 (24~48시간 전)
• [ ] 새 호스트 프로비저닝, rsync로 파일 복사
• [ ] 데이터베이스 내보내기 및 가져오기, 구성 업데이트
• [ ] hosts 파일을 통해 새 사이트 테스트
• [ ] 원래 사이트를 읽기 전용으로 설정, 최종 동기화 완료
• [ ] DNS를 새 IP로 전환
• [ ] 원래 서버를 24~48시간 유지
• [ ] 이메일/MX 및 SSL 검증
• [ ] TTL 상향, 원래 서버 폐기

결론

체계적으로 실행하면 마이그레이션은 서비스 중단 없이 사용자 경험을 유지하며, 눈에 띄는 다운타임 없이 더 빠른 사이트를 제공합니다.