호스팅을 바꾸고 싶지만 기존 도메인과 게시글 주소는 그대로 유지하고 싶은 경우가 있습니다. 이때 도메인을 새로 구매하거나 사이트 주소를 바꿀 필요는 없습니다.
기존 사이트의 파일과 데이터베이스를 새 서버로 복사한 뒤 마지막 단계에서 도메인의 DNS가 새 서버를 가리키도록 변경하면 주소는 그대로 두고 호스팅만 이전할 수 있습니다.
중요한 것은 DNS부터 변경하지 않는 것입니다. 기존 서버를 계속 운영하면서 새 서버를 먼저 완성하고 충분히 테스트한 뒤 연결을 전환해야 다운타임과 데이터 누락 가능성을 줄이기 쉽습니다.
핵심요약
- 사이트 주소가 그대로라면 도메인을 새로 구매할 필요가 없습니다.
- 워드프레스는 사이트 파일과 데이터베이스를 모두 새 서버로 옮겨야 합니다.
- 새 서버에서 정상 작동을 확인한 뒤 마지막에 DNS를 변경합니다.
- 이전 중 새 글·주문·회원 데이터가 생긴다면 최종 데이터 동기화가 필요할 수 있습니다.
- DNS 변경 직후 기존 호스팅을 바로 해지하지 않는 것이 좋습니다.
- 네임서버까지 변경한다면 메일·인증용 DNS 레코드도 함께 옮겨야 합니다.
목차
사이트 주소를 그대로 두고 서버만 옮기는 원리
도메인은 사용자가 입력하는 주소이고 호스팅은 사이트 파일과 데이터베이스를 보관하는 서버입니다. 따라서 도메인을 그대로 유지하면서 해당 도메인이 연결되는 서버만 변경할 수 있습니다.
이전 전에는 도메인 → 기존 서버로 연결되어 있었다면 이전 후에는 도메인 → 새 서버로 연결되는 구조입니다. 사이트 주소와 게시글 URL은 그대로 유지됩니다.
WordPress 공식 문서에서도 도메인 이름과 URL을 유지하는 서버 이전이라면 파일과 데이터베이스를 새 서버로 복사하는 방식으로 이전할 수 있다고 설명합니다. 데이터베이스 정보가 달라졌다면 `wp-config.php`만 새 환경에 맞게 수정합니다.
이전 전에 반드시 백업할 항목 확인하기
워드프레스는 파일과 데이터베이스가 함께 있어야 기존 사이트를 제대로 복원할 수 있습니다. 따라서 둘 중 하나만 백업하는 방식은 피하는 것이 좋습니다.
파일 백업에는 일반적으로 워드프레스 코어, 테마, 플러그인, 업로드 이미지, `wp-content`, `.htaccess`, `wp-config.php`와 직접 추가한 파일 등이 포함됩니다.
데이터베이스에는 게시글·페이지·댓글·사용자·워드프레스 설정과 여러 플러그인 설정이 저장됩니다.
호스팅 업체의 자동 이전 도구를 사용하더라도 별도의 전체 백업을 먼저 확보해두면 이전 과정에서 문제가 생겼을 때 기존 상태로 돌아가기 쉽습니다.
새 호스팅 환경을 먼저 준비하기
기존 사이트를 계속 운영하는 동안 새 호스팅 계정을 먼저 준비합니다. 새 서버가 기존 워드프레스 사이트를 운영할 수 있는 환경인지 확인하는 것이 중요합니다.
- PHP 버전과 필요한 확장 기능
- MySQL 또는 MariaDB 지원
- SSL·HTTPS 설정 방법
- 저장공간과 전송량
- 데이터베이스 생성 가능 여부
- 파일 업로드 제한
- 캐시 기능
- 백업과 복구 기능
특히 오래된 테마나 플러그인을 사용하고 있다면 새 서버의 PHP 환경에서 정상적으로 작동하는지 확인합니다. 새 호스팅 업체가 임시 URL이나 미리보기 기능을 제공하는지도 함께 살펴보면 좋습니다.
파일과 데이터베이스를 새 서버로 옮기기
수동으로 이전한다면 기존 서버에서 파일을 내려받고 데이터베이스를 내보낸 뒤 새 서버에 각각 업로드·가져오기 하는 방식이 기본입니다.
- 기존 사이트 파일 전체 백업
- 기존 데이터베이스 내보내기
- 새 서버에 데이터베이스 생성
- 데이터베이스 가져오기
- 사이트 파일 업로드
- `wp-config.php`의 DB 정보 확인
- 새 환경에서 사이트 작동 점검
새 서버에서 데이터베이스 이름이나 사용자·비밀번호가 달라졌다면 `wp-config.php`를 수정합니다. 도메인 자체가 그대로라면 사이트 전체에서 기존 도메인을 새 도메인으로 바꾸는 검색·치환 작업은 일반적으로 필요하지 않습니다.
호스팅 업체에서 공식 이전 서비스나 워드프레스 마이그레이션 기능을 제공한다면 이를 이용할 수도 있습니다. 어떤 방식을 사용하더라도 최종적으로 파일과 DB가 모두 정상적으로 옮겨졌는지 확인해야 합니다.
DNS 변경 전에 새 사이트 테스트하기
파일과 데이터베이스를 새 서버에 올렸다고 바로 DNS를 변경하지 않는 것이 좋습니다. 먼저 새 서버에서 사이트가 정상적으로 작동하는지 확인합니다.
호스팅 업체가 제공하는 미리보기 주소나 스테이징 기능, 또는 환경에 따라 로컬 hosts 파일을 이용해 실제 DNS를 변경하지 않고 새 서버를 테스트할 수 있습니다.
- 홈페이지가 정상적으로 열리는지
- 관리자 로그인이 가능한지
- 게시글과 페이지가 열리는지
- 이미지가 모두 표시되는지
- 내부링크가 정상인지
- 메뉴와 검색이 작동하는지
- 문의 폼과 주요 플러그인이 정상인지
- HTTPS 적용에 문제가 없는지
- 모바일 화면이 정상인지
고유주소를 사용하는 사이트에서 게시글이 404로 열리는 경우에는 새 서버의 rewrite 설정과 워드프레스 고유주소 설정을 함께 확인합니다.
DNS를 새 서버로 변경하는 방법
새 서버 확인이 끝나면 도메인의 DNS를 새 서버로 변경합니다. 반드시 네임서버를 바꿔야 하는 것은 아닙니다.
현재 DNS 서비스를 그대로 사용하고 있다면 웹사이트를 가리키는 A·AAAA·CNAME 레코드만 새 서버 정보로 변경하는 방식이 가능합니다.
반대로 DNS 관리 자체를 새로운 업체로 옮긴다면 도메인 등록기관에서 네임서버를 변경해야 합니다. 이 경우 기존 DNS 레코드가 자동으로 따라오지 않을 수 있으므로 웹사이트뿐 아니라 메일·도메인 인증 관련 레코드까지 확인해야 합니다.
다운타임을 줄이기 위한 이전 순서
호스팅 이전에서는 작업 속도보다 순서가 중요합니다. 새 서버를 모두 준비하기 전에 DNS를 바꾸면 방문자가 아직 완성되지 않은 사이트에 접속할 수 있습니다.
| 순서 | 작업 |
|---|---|
| 백업 | 기존 파일·DB 확보 |
| 새 서버 준비 | DB·SSL·환경 설정 |
| 데이터 이전 | 파일·DB 복사 |
| 사전 확인 | 페이지·이미지·기능 테스트 |
| 최종 동기화 | 새로 생긴 데이터 확인 |
| DNS 변경 | 새 서버로 연결 |
| 기존 서버 유지 | DNS 전환 상태 확인 |
게시글이 자주 올라오지 않는 정보형 블로그라면 데이터 차이가 크지 않을 수 있습니다. 반대로 쇼핑몰·회원제 사이트·커뮤니티처럼 데이터가 계속 추가되는 사이트는 처음 백업 이후 생긴 데이터가 누락되지 않도록 최종 동기화 시점을 더 신중하게 잡아야 합니다.
DNS 레코드의 TTL은 해당 DNS 정보가 캐시에 유지되는 시간에 영향을 줍니다. 기존 TTL이 길다면 변경 전에 미리 낮추는 방법도 사용할 수 있지만 실제 반영 시점은 로컬 DNS 캐시 등 여러 요소의 영향을 받을 수 있습니다.
메일을 사용한다면 DNS 레코드까지 확인하기
회사 도메인으로 이메일을 사용하고 있다면 호스팅 이전 시 웹사이트 연결만 확인해서는 부족할 수 있습니다.
특히 네임서버를 새 업체로 옮기는 경우에는 기존 DNS에 있던 메일·도메인 인증 관련 설정을 새 DNS에도 빠짐없이 등록해야 합니다.
- MX 레코드
- SPF 관련 TXT 레코드
- DKIM
- DMARC
- 메일 서비스용 CNAME
- Google·Microsoft 등 서비스 확인 레코드
웹사이트는 정상적으로 열리는데 메일이 오지 않는다면 서버 이전 자체보다 DNS에서 메일 관련 레코드가 빠졌는지 먼저 확인할 수 있습니다.
이전 후 반드시 점검할 항목 정리하기
DNS 변경 후에는 메인 화면 하나만 확인하고 작업을 끝내지 않는 것이 좋습니다. 서버 환경이 달라지면서 이전에는 없던 오류가 나타날 수 있습니다.
| 확인 항목 | 점검 내용 |
|---|---|
| 접속 | 메인·게시글·관리자 |
| URL | 기존 주소 유지 여부 |
| 이미지 | 누락·깨짐 여부 |
| SSL | HTTPS·인증서 확인 |
| 기능 | 폼·검색·플러그인 |
| 메일 | 송수신·MX·인증 |
| 백업 | 새 서버 백업 생성 여부 |
검색 유입이 있는 사이트라면 `robots.txt`와 검색엔진 접근도 확인합니다. 서버만 바꾸고 URL을 그대로 유지했다면 기존 게시글 전체에 새로운 리디렉션을 설정할 필요는 없습니다.
기존 호스팅은 언제 해지하는 것이 좋을까?
DNS를 변경한 직후 기존 호스팅을 바로 삭제하는 것은 피하는 것이 좋습니다. 일부 사용자의 DNS 캐시에는 이전 서버 정보가 남아 있을 수 있기 때문입니다.
기존 호스팅을 유지한 상태에서 여러 환경에서 새 서버 접속을 확인하고, 새 서버에서 주요 기능과 백업이 정상적으로 작동하는지 확인합니다.
또 이전 중 새로 작성된 게시물이나 폼 접수 데이터가 기존 서버에 남아 있지 않은지도 확인해야 합니다. 모든 데이터와 DNS 전환이 정상적이라는 것을 확인한 뒤 기존 호스팅을 종료하는 편이 안전합니다.
FAQ
호스팅을 바꾸면 도메인도 다시 사야 하나요?
아닙니다. 기존 도메인을 그대로 사용하면서 파일과 데이터베이스만 새 서버로 옮긴 뒤 DNS가 새 서버를 가리키도록 변경할 수 있습니다.
같은 도메인을 사용하면 워드프레스 주소도 변경해야 하나요?
도메인과 URL 구조를 그대로 유지하는 서버 이전이라면 일반적으로 WordPress Address와 Site Address를 다른 주소로 변경할 필요는 없습니다.
파일만 새 서버로 옮기면 되나요?
아닙니다. 워드프레스의 게시글과 설정 등은 데이터베이스에도 저장되기 때문에 파일과 데이터베이스를 함께 이전해야 합니다.
DNS를 변경하면 바로 새 서버가 보이나요?
항상 즉시 모든 사용자에게 동일하게 적용되는 것은 아닙니다. DNS 정보는 TTL과 로컬 캐시 등의 영향을 받을 수 있으므로 일정 시간 동안 기존 서버와 새 서버 접속이 나뉠 가능성을 고려하는 것이 좋습니다.
기존 호스팅은 언제 해지하는 것이 좋나요?
새 서버 접속과 주요 기능, 메일, 백업, DNS 전환을 충분히 확인한 뒤 해지하는 것이 좋습니다. DNS 변경 직후 바로 삭제할 필요는 없습니다.
마치며
사이트 주소를 그대로 유지하는 호스팅 이전은 도메인을 바꾸는 작업이 아니라 기존 사이트를 새 서버에 복제한 뒤 도메인이 바라보는 목적지만 바꾸는 작업에 가깝습니다.
저라면 DNS부터 변경하지 않고 백업 → 새 서버 준비 → 파일·DB 이전 → 새 서버 테스트 → 최종 데이터 확인 → DNS 변경 → 기존 서버 유지 → 최종 점검 순서로 진행할 것 같습니다.
이렇게 하면 문제가 발견되더라도 기존 사이트를 계속 사용할 수 있고, 새 서버가 완전히 준비된 뒤 연결만 전환할 수 있습니다. 결국 다운타임을 줄이는 가장 중요한 방법은 빠르게 옮기는 것보다 새 서버를 먼저 완성한 뒤 DNS를 마지막에 변경하는 것입니다.

댓글 남기기