도메인을 바꾸지 않고 WordPress 호스트 옮기기: 이전, 테스트, DNS 전환

몇 년간 운영한 작업실 사이트를 다른 호스트로 옮기되 명함을 다시 인쇄하거나 글 URL을 바꾸고 싶지 않을 수 있습니다. 이런 이전에서는 도메인과 경로를 대개 그대로 두고 사이트를 제공하는 호스팅 환경만 바꿀 수 있습니다. 처음부터 DNS를 변경하기보다 새 사이트를 먼저 시험하고 트래픽을 옮겨야 문제를 확인하기 쉽습니다.

자주 과소평가하는 것은 파일 크기보다 이전 중에도 들어오는 데이터입니다. 첫 복사 후 기존 사이트가 댓글이나 문의를 더 받을 수 있습니다. 새 사이트도 바로 열면 기록이 양쪽에 나뉠 수 있습니다. 아래 절차는 마지막 데이터 인계를 별도 단계로 다뤄 사이트를 어디로 옮겼는지뿐 아니라 최신 기록이 어디에 남았는지도 확인합니다.

인계표를 만들어 이전 범위 확인하기

기존 호스트, 새 호스트, 도메인 등록업체, DNS 제공업체를 적습니다. 한 회사가 네 역할을 모두 맡거나 전부 다를 수 있습니다. 웹 호스트만 바꿀 때 도메인 등록업체를 옮길 필요는 없습니다. 네임서버까지 바꾼다면 웹사이트 IP만이 아니라 DNS 레코드 전체를 살펴야 합니다.

WordPress, PHP, 데이터베이스 버전, 디스크 사용량, 주요 플러그인을 기록합니다. 메일, 예약 작업, 발신 메일 서비스, CDN, 외부 서비스 콜백 URL도 별도로 적습니다. 이전 플러그인이 가져갈 수 있는 내용은 버전과 실제 설정에 따라 확인해야 합니다. 내보내기 파일 하나가 호스팅 제어판의 모든 서비스를 인계했다는 뜻은 아닙니다.

1. 기존 호스트, 새 호스트, DNS, 백업 저장소에 누가 로그인할 수 있는지 확인합니다.
2. 현재 DNS 레코드와 전체 사이트 백업을 저장하고 가져오는 방법을 적습니다.
3. 전환 시간을 정하고 사이트를 업데이트하거나 주문을 처리하는 사람에게 알립니다.

새 호스트에 테스트 가능한 복사본 만들기

새 호스트에 사이트 공간, 데이터베이스, 필요한 소프트웨어 버전을 마련한 뒤 호스트의 이전 서비스나 선택한 도구의 절차에 따라 파일과 데이터베이스를 들여옵니다. 데이터베이스 연결을 조정해야 한다면 새 호스트가 제공한 값을 쓰고 기존 호스트의 계정과 암호로 덮어쓰지 마세요. 사용자 정의 서버 규칙이 새 환경에서도 맞는지 확인합니다.

같은 URL을 유지하는 호스트 이전에서는 사이트에 저장된 공개 주소도 그대로 두어야 합니다. UpdraftPlus는 이 경우를 위한 별도 공식 절차를 제공하며 데이터베이스 URL을 함부로 치환하지 말라고 안내합니다. 임시 URL로 미리 보면 링크나 로그인 동작이 바뀔 수 있습니다. 운영 URL을 보존하면서 미리 보는 방법을 호스트 제공업체에 문의하세요.

복사본 접근을 제한하고 실제 결제, 알림, 외부로의 쓰기를 중지합니다. 특히 예약 작업이 기존 환경과 새 환경 양쪽에서 메일을 보내지 않게 합니다. 격리 방법과 공개할 때 다시 켜야 할 기능을 목록으로 남겨 필요한 서비스를 꺼 둔 채 놓치지 마세요.

정말 새 호스트를 보고 있는지 확인하기

브라우저 화면이 같으면 기존 사이트를 새 사이트로 착각하기 쉽습니다. 호스트가 제공하는 미리 보기 주소를 쓰거나 컴퓨터 설정에 익숙한 사람이 로컬 hosts 파일을 잠시 바꿔 원래 도메인이 새 IP로 연결되게 합니다. 이는 테스트 컴퓨터에만 영향을 주며 전 세계 DNS를 바꾸는 것이 아닙니다. 검증 후에는 테스트 설정을 제거해야 합니다.

새 사이트에 접근을 제한한 식별용 표시를 두고 새 호스트의 접근 로그를 함께 확인해 요청이 실제로 도착하는지 검증할 수 있습니다. HTTPS 인증서도 정상이어야 하며 브라우저 경고를 건너뛰는 것을 정상 공개 조건으로 삼으면 안 됩니다. 인증서 발급 전에 도메인 확인이 필요하다면 호스트가 제공하는 방법에 따라 준비하세요.

1. 첫 화면, 글, 이미지, 다운로드 파일, 로그인 페이지를 열어 임시 URL로 되돌아가지 않는지 확인합니다.
2. 검색, 메뉴, 양식, 필요한 기능을 사용하고 알림이 테스트 수신처에 오는지 확인합니다.
3. 모바일 화면, 이전 글의 고유 주소, 오류 페이지를 확인하고 문제 목록을 저장합니다.

마지막 데이터 차이 처리하기

첫 복사본은 기능 검증에 적합하지만 운영 전환에는 명확한 데이터 기준 시점이 필요합니다. 변경이 적은 사이트라면 조율한 시간에 게시와 상호작용을 잠시 멈추고 마지막 백업과 가져오기를 마친 뒤 최신 내용을 비교합니다. 거래를 계속 받는 사이트는 해당 시스템을 아는 사람이 동기화와 중복 제거를 설계해야 하며 데이터베이스 전체를 덮어쓰면 안 됩니다.

기능을 멈출 때 방문자에게 예상 재개 시간과 연락 방법을 분명히 알립니다. 전환 전후의 기록 수, 최신 항목 시각, 관련 식별자를 보관하되 개인정보를 공개 문서에 넣지 마세요. 데이터가 일치하는지 먼저 검증하고 쓰기를 다시 켤지 결정해야 점검 중 새로운 차이가 생기지 않습니다.

DNS를 전환하고 다른 네트워크에서 결과 확인하기

DNS 서비스에서 적절한 TTL을 미리 설정하면 새 레코드가 적용될 때까지의 대기 시간을 줄일 수 있습니다. 이미 캐시된 이전 값은 저장을 누른 즉시 사라지지 않습니다. 전환할 때는 계획한 웹 레코드만 바꾸고 최상위 도메인, www, IPv4, IPv6에 이전 목적지가 남았는지 확인하며 사용 중인 메일 레코드는 보존합니다.

공개 전에 테스트 사이트의 접근 제한과 테스트 전용 색인 차단 설정을 해제하고 필요한 연동을 켭니다. 집과 이동통신망에서 확인하며 두 호스트의 로그를 비교합니다. Google의 호스트 변경 안내도 양쪽 트래픽을 관찰하라고 권장합니다. 한 컴퓨터에서 잘 열린다고 모든 방문자의 전환이 끝난 것은 아닙니다.

되돌릴 조건을 먼저 정하고 이전 호스트는 마지막에 종료하기

핵심 서비스의 제출 실패, 누락된 데이터, 많은 개별 페이지의 오류 등 어떤 상황에서 되돌릴지 전환 전에 합의합니다. DNS를 되돌려야 한다면 새 호스트에 생긴 데이터를 먼저 목록화하고 저장하세요. 그렇지 않으면 기존 사이트로 돌아온 뒤 방금 받은 내용이 사라질 수 있습니다. 되돌리기는 IP를 원래대로 하는 것만이 아니라 데이터 인계 작업입니다.

문제 발견 시각, URL, 사용한 네트워크, 예상 결과와 실제 결과를 기록하는 장애 목록도 유지합니다. 문제마다 담당자 한 명을 정해 추적하세요. 여러 사람이 동시에 DNS, 플러그인, 호스트 설정을 바꾸면 원래 확인할 수 있던 문제를 재현하기 어려워집니다.

새 호스트가 트래픽을 안정적으로 제공하고 기존 사이트에 처리할 방문자나 서비스가 더는 없으며 새 환경의 백업이 성공했을 때만 이전 호스트 중단을 계획합니다. 기존 요금제가 메일이나 DNS도 제공한다면 먼저 그 서비스를 인계하세요. 갱신 중단과 즉시 서비스 삭제는 결과가 다를 수 있으므로 실행 전 청구 화면을 읽어야 합니다.

복원 가능한 웹사이트 백업 먼저 만들기

DNS 레코드와 조회 문제 이해하기

웹사이트 HTTPS 인증서 설정하기

• 튜토리얼
• 앱·소프트웨어
• 웹사이트·이커머스
• WordPress