웹사이트를 새로 만들지 않고 다른 업체로 옮길 수 있을까요?
웹사이트 업체를 바꾼다고 해서 항상 전체를 새로 만들어야 하는 것은 아닙니다. 무엇에 접근할 수 있는지, 무엇을 내보내고 라이선스를 이전할 수 있는지, 현재 플랫폼 밖에서 무엇을 운영할 수 있는지에 따라 달라집니다.

가능한 경우도 있습니다. 일반적인 형식의 접근 가능한 파일, 데이터베이스, 설정, 이전 가능한 라이선스를 사용한다면 사이트를 새로 만들지 않고 다른 업체로 옮길 수 있습니다. 호스팅형 웹사이트 빌더로 만든 사이트는 일부만 옮기거나 콘텐츠만 내보낼 수 있고, 원래 시스템을 플랫폼 밖에서 운영하지 못할 수도 있습니다.
따라서 첫 질문은 “누가 새로 만들까요?”가 아니라 “우리에게 정확히 무엇이 있고, 현재 환경에서 무엇을 가져올 수 있으며, 변경 후에도 무엇이 계속 작동해야 할까요?”입니다.
웹사이트 이전은 실제로 무엇을 뜻하나요?
업체 변경은 다음처럼 서로 다른 작업을 뜻할 수 있습니다.
- 전체 시스템 이전: 웹사이트 파일, 데이터베이스, 설정, 미디어, 계정 및 관련 서비스를 다른 호스팅 환경으로 옮깁니다.
- 시스템 일부 이전: 재사용 가능한 부분은 옮기고 양식, 검색, 결제, 회원 기능처럼 업체에 종속된 기능은 대체합니다.
- 콘텐츠 이전: 페이지, 게시물, 제품 또는 이미지를 내보내 다른 시스템으로 가져오지만 디자인과 기능은 다시 만듭니다.
- 운영 인계: 웹사이트는 현재 위치에 두고 새 업체에 유지보수에 필요한 접근 권한을 전달합니다.
각 방식의 비용과 위험은 다릅니다. 콘텐츠를 내보내면 글과 이미지는 보존해도 템플릿, 관리 기능, 연동, 사이트 작동 방식은 빠질 수 있습니다.
도메인과 웹사이트는 별개인가요?
대개 그렇습니다. 도메인은 사람들이 사용하는 주소이고, 호스팅은 웹사이트를 제공하는 환경입니다. 콘텐츠 관리 시스템, 이메일, DNS도 각각 다른 곳에서 관리될 수 있습니다.
웹사이트 관리 업체를 바꾼다고 해서 반드시 도메인을 이전할 필요는 없습니다. 반대로 도메인 등록 업체를 바꿔도 웹사이트가 옮겨지는 것은 아닙니다. 기존 도메인과 공개 URL을 유지하면서 호스팅만 변경할 수 있습니다.
변경 전에 도메인 등록기관 계정, DNS 레코드, 호스팅 계정, 웹사이트 관리자 권한, 업무용 이메일을 누가 관리하는지 확인하세요. 외부에서는 하나의 서비스처럼 보여도 실제로는 여러 계정으로 운영될 수 있습니다.
현재 시스템을 다른 곳에서 운영할 수 있나요?
전체 이전이 가능한지 보여주는 가장 강한 신호는 일반적인 애플리케이션 구성 요소에 접근할 수 있는지입니다. 소스 파일, 데이터베이스, 미디어, 설정, 필요한 실행 환경 정보, 새 환경에서도 유효한 라이선스가 여기에 포함됩니다.
WordPress가 익숙한 예입니다. 공식 이전 안내는 파일과 데이터베이스를 사용해 서버 간에 사이트를 옮기고 필요하면 설정을 변경할 수 있다고 설명합니다. WordPress는 파일과 데이터베이스가 함께 작동하는 사이트를 구성하므로 하나의 백업 세트로 다루도록 권장합니다. 공식 WordPress 이전 안내와 WordPress 백업 안내를 참고하세요.
그렇다고 모든 WordPress 사이트를 바로 옮길 수 있다는 뜻은 아닙니다. 테마나 플러그인 라이선스가 제한적이거나, 대행사 계정에 의존하거나, 외부 서비스를 호출하거나, 새 호스팅에서 지원하지 않는 서버 기능이 필요할 수 있습니다. 맞춤 코드가 불완전하거나 제공되지 않을 수도 있습니다.
호스팅형 빌더는 다르게 작동합니다. Wix는 독점 기술에 의존하므로 Wix 사이트를 Wix 인프라에서 호스팅하고 운영해야 하지만 도메인은 다른 곳에서 관리할 수 있다고 안내합니다. 내보내기 및 외부 호스팅 안내는 플랫폼 선택이 이전 가능성에 영향을 주는 이유를 보여줍니다.
내보내기에 작동하는 웹사이트 전체가 포함되나요?
꼭 그렇지는 않습니다. 내보내기 버튼이 있다는 것은 일부 자료를 가져올 수 있다는 뜻이지, 시스템 전체를 독립적으로 운영할 수 있다는 증거는 아닙니다.
Webflow는 일부 요금제에서 HTML, CSS, JavaScript와 에셋을 내보낼 수 있습니다. 공식 코드 내보내기 문서에 따르면 CMS, 사용자 계정, 전자상거래 기능, 현지화 콘텐츠, 양식, 사이트 검색 등의 호스팅 기능은 포함되지 않거나 Webflow에서처럼 작동하지 않습니다.
Squarespace는 WordPress용 일부 콘텐츠를 XML로 내보낼 수 있지만, 일부 기능이 Squarespace의 JavaScript와 CSS에 의존하므로 모든 항목을 내보낼 수는 없다고 설명합니다. 사이트 내보내기 안내에 포함 항목과 제외 항목이 나와 있습니다.
따라서 내보낸 자료를 실제 운영 중인 사이트와 비교해야 합니다. 메뉴, 양식, 검색, 고객 계정, 제품, 결제, 예약, 언어, 리디렉션, 관리자 기능이 있고 사용할 수 있는지 확인하세요. 파일이 다운로드됐는지만 확인해서는 충분하지 않습니다.
결정 전에 어떤 자료를 모아야 하나요?
서비스를 해지하거나 재구축을 승인하기 전에 다음 자료를 모으세요.
- 도메인 등록기관 및 DNS 접근 권한;
- 호스팅 제어판, 서버 또는 플랫폼 계정 접근 권한;
- 웹사이트 관리자 권한;
- 소스 파일 또는 저장소 접근 권한;
- 최신 데이터베이스 내보내기와 미디어 보관본;
- 플랫폼 내보내기 자료와 각 자료에서 제외되는 항목;
- 테마, 플러그인, 글꼴 및 기타 소프트웨어 라이선스;
- 양식, 결제 서비스, 예약 도구, 검색 및 기타 연동;
- 분석, 태그 관리, 검색 관리 계정;
- 이메일 서비스 및 관련 DNS 레코드;
- 중요한 랜딩 페이지를 포함한 현재 URL 목록;
- 최근 백업과 복원 가능 여부에 대한 확인.
문서는 유용하지만 접근 권한도 직접 시험해야 합니다. 로그인 정보 목록만으로 계정에 접속되는지, 내보내기가 완료되는지, 결과 데이터를 사용할 수 있는지 알 수 없습니다.
부분적으로 새로 만드는 것이 적절한 경우는 언제인가요?
콘텐츠와 시각 자료는 복구할 수 있지만 기존 플랫폼을 다른 곳에서 운영할 수 없다면 부분 재구축이 합리적일 수 있습니다. 공개 페이지는 괜찮지만 호스팅형 양식, 상점, 회원 공간 또는 검색 기능을 교체해야 할 때도 적절할 수 있습니다.
범위를 분명히 정해야 합니다. 예를 들어 콘텐츠, 이미지, 브랜드 표현, URL은 유지하면서 템플릿과 양식을 바꿀 수 있습니다. 다른 프로젝트에서는 전체 콘텐츠 시스템을 옮기되 라이선스가 있는 테마를 교체할 수 있습니다. 이는 업체를 바꿀 때마다 웹사이트를 처음부터 새로 만들어야 한다고 가정하는 것과 다릅니다.
문제가 호스팅이 아니라 담당 책임이라면 기술 인계만으로 충분할 수 있습니다. LINK-V의 개발자 교체 서비스는 유지보수, 이전, 재구축 중 무엇을 선택할지 정하기 전에 접근 권한, 소유권, 코드, 호스팅, 백업과 현재 위험을 확인합니다.
기존 URL과 검색 노출은 어떻게 되나요?
호스팅 변경 시 같은 도메인과 URL 구조를 유지할 수 있습니다. Google은 눈에 보이는 URL 변경이 없는 호스팅 인프라 변경과 URL이 바뀌는 사이트 이전을 구분합니다. 호스팅 변경 안내는 새 인프라를 준비하고 테스트한 뒤 DNS를 전환하고, 양쪽 환경을 모니터링하며 새 환경이 정상적으로 제공된 뒤에 이전 환경을 종료하도록 권장합니다.
URL이 바뀐다면 페이지별 대응표와 적절한 리디렉션을 준비하세요. Google의 사이트 이전 안내는 내부 링크, 대표 URL 참조, 사이트맵을 업데이트하고 이전을 모니터링하는 것도 권장합니다. 큰 변경 중에는 검색 노출이 변동할 수 있으므로 결과가 전혀 달라지지 않는다고 약속해서는 안 됩니다.
LINK-V는 업체 변경을 어떻게 평가하나요?
LINK-V는 기존 시스템부터 살펴봅니다. 접근 권한, 호스팅, 소스 파일, 데이터베이스, 플랫폼 내보내기, 라이선스, 도메인, DNS, 이메일 의존성, 연동, URL과 백업을 검토한 뒤 전체 이전, 부분 이전, 콘텐츠 이전, 운영 인계 또는 재구축 중 현실적인 방향을 정합니다.
필요한 경우 이전 서비스에는 평가, 이전 계획, 테스트 환경, URL 처리, DNS 전환과 출시 후 점검이 포함됩니다. 기존 웹사이트를 그대로 두고 관리만 새로 맡길 수 있다면 웹사이트 유지보수가 더 적절할 수 있습니다.
답은 현재 플랫폼의 이름이 아니라 확인된 자료에서 나와야 합니다. 새 업체를 선택하거나 재구축을 승인하기 전에 무엇에 접근할 수 있는지, 무엇을 내보낼 수 있는지, 법적·기술적으로 다른 곳에서 계속 운영할 수 있는 부분은 무엇인지, 어떤 업무 기능을 유지해야 하는지 확인하세요.