WordPress를 업무에 맞추기 어려워졌다면 맞춤형 웹사이트가 일상적인 게시와 업무를 더 쉽게 만들 수 있습니다. 먼저 현재 사이트를 개선해서 해결할 수 있는지 확인하세요. 교체할 가치가 있다면 콘텐츠, 편집 도구, 연결 서비스, 출시와 지속 관리를 함께 계획해야 합니다.
현재 웹사이트가 사업에 필요한 일을 계속 방해한다면 맞춤형 웹사이트에 투자할 이유가 있을 수 있습니다. 편집자가 같은 정보를 여러 곳에 입력할 수도 있습니다. 문의를 여러 팀에 보내는 규칙이 점점 유지하기 어려워질 수도 있습니다. 상품 목록이 커져 현재 페이지 구조로 다루기 힘들 수도 있습니다.
그런 경우 사람들이 실제로 하는 일에 맞춰 콘텐츠, 편집 화면, 시스템 연결을 설계할 수 있습니다. 편집자가 행사를 한 번 입력하면 날짜가 사이트 전체에 일관되게 표시될 수 있습니다. 직원이 문의를 받을 때 필요한 고객 정보가 이미 첨부될 수도 있습니다. 모든 요구를 기존 플러그인에 맞추는 대신 다음에 중요한 변경을 합의할 수 있습니다.
이런 개선은 설계하고 만들고 시험해야 합니다. WordPress를 교체하는 것만으로 생기지 않습니다. 계획이 부족한 맞춤형 시스템은 편집 기능이 더 부족하고 유지보수 비용은 더 클 수 있습니다.
먼저 사업 관점에서 문제를 설명하세요. 사람들이 무엇을 하기 어려운지, 얼마나 자주 일어나는지, 시간이나 놓친 일의 비용이 얼마나 되는지, 만족할 결과는 어떤 모습인지 살펴봅니다. 그런 뒤 해결 방법을 비교하세요. 요구를 충족하고 누군가 계속 운영할 수 있는 선택지 가운데 부담이 가장 적은 것을 고릅니다.
재구축의 유용한 이유는 구체적입니다. “편집자가 행사를 한 번 입력하고 미리 본 뒤 올바른 곳에 게시할 수 있어야 한다.” 그러면 발주하고 시험할 수 있습니다.
사람들이 말하는 ‘새 웹사이트’는 서로 다른 여러 프로젝트를 가리킵니다. 가격을 비교하기 전에 무엇을 구매할지 분명히 하세요.
개편은 웹사이트의 모습과 사용 방식을 바꿉니다. 호스팅이나 업체 변경은 누가 어디서 운영하는지 바꿉니다. 어느 쪽이든 WordPress와 기존 구현의 상당 부분을 유지할 수 있습니다.
WordPress를 유지하면서 전용 테마, 구조화한 콘텐츠, 특정 기능을 만들 수 있습니다. 기존 편집 도구와 생태계도 해결책의 일부로 남습니다.
WordPress가 콘텐츠 시스템으로 남고 별도 애플리케이션이 사이트를 표시합니다. 특정 화면 요구에 맞을 수 있지만 두 부분이 함께 작동하고 관리돼야 합니다.
다른 시스템이 게시와 합의한 기능을 맡습니다. 표준 콘텐츠 시스템에 맞춤형 개발을 더하거나 필요에 맞춰 만든 관리 시스템을 포함할 수 있습니다.
기본 웹사이트는 적합하고 운영 방식이 문제라면 제공업체를 바꾸는 것으로 충분할 수 있습니다. 저희의 재구축 없이 웹사이트 제공업체를 바꾸는 안내에서 그 결정을 별도로 설명합니다.
헤드리스 WordPress도 실제 선택지입니다. WordPress REST API를 통해 별도 애플리케이션이 접근 권한 범위에서 콘텐츠를 다룰 수 있습니다. 하지만 모든 플러그인의 데이터와 동작이 그 API로 제공된다는 뜻은 아닙니다. 새 화면이 여전히 기존 콘텐츠 구조와 플러그인 규칙에 의존할 수 있습니다. 무엇을 해결하는지, 무엇이 WordPress에 남는지, 연결은 누가 관리하는지 물어보세요.
팀이 편하게 게시할 수 있고, 필요한 기능이 잘 작동하며, 변경도 비교적 간단하다면 유지하는 편이 합리적일 수 있습니다. 일반적인 게시 업무만으로 교체를 발주할 이유가 생기지는 않습니다.
불편한 사이트라도 고칠 수 있는 문제일 수 있습니다. 페이지가 느리다면 이미지, 호스팅, 데이터베이스 작업 또는 특정 기능을 조사해야 할 수 있습니다. 편집 도구가 어렵다면 콘텐츠 구조를 명확히 하거나 WordPress를 더 잘 개발해서 개선할 수 있습니다. 플러그인 수만 보고 결론 내리지 말고 문제와 그 영향을 살펴보세요.
적합한 표준 플랫폼도 비교하세요. 이미 예약, 상점, 게시 요구를 잘 처리하는 서비스가 있다면 설정하고 신중히 옮기는 편이 맞춤형 시스템보다 지속적인 수고가 적을 수 있습니다.
조직의 역량도 중요합니다. 맞춤형 시스템이 무엇을 해야 할지 결정하고, 제대로 하는지 확인하고, 관리 비용을 지불할 사람이 필요합니다. 기술 관리는 맡길 수 있지만 사업 내부에는 결정을 내리고 결과를 승인할 사람이 있어야 합니다. 그런 여력이 없다면 관리하기 쉬운 기존 플랫폼이 더 적합할 수 있습니다.
페이지 수는 출발점입니다. 이전 범위는 그 페이지 뒤에 있는 콘텐츠, 관계, 업무에서 결정됩니다.
웹사이트를 사용하고 운영하는 사람들과 함께 살펴보세요. 방문자에게 보이지 않는 부분도 포함합니다.
각 항목을 유지, 교체, 중단 중 하나로 결정하세요. 누가 결정할 수 있고 결과가 잘 작동하는지 어떻게 확인할지 기록합니다. 버려진 플러그인은 없앨 수 있지만, 다른 플러그인은 영업팀이 의지하는 문의를 조용히 전송하고 있을 수 있습니다.
상품, 회원권, 예약을 판매한다면 그 업무의 범위를 따로 정하세요. 상품, 주문, 고객 접근 권한, 갱신, 이용 가능 여부, 연결된 제공업체는 명확한 결정이 필요합니다. 콘텐츠 이전만으로 진행 중인 구독이나 기존 예약을 어떻게 이어 갈지 결정되지 않습니다. 이동 가능하다고 약속하기 전에 실제 시스템과 제공업체를 조사해야 합니다.
유용한 목록은 한 업무를 처음부터 끝까지 따라갑니다. 문의라면 양식, 저장된 기록, 확인, 이메일 수신자, 연결된 시스템, 응답할 담당자를 확인하세요.
WordPress를 떠나더라도 관리 시스템은 유지할 수 있습니다. 팀이 무엇을 할 수 있어야 하는지 명시하세요. 맞춤형 개발에 편집자가 익숙한 모든 기능이 자동으로 포함되지는 않습니다.
콘텐츠 종류마다 무엇이 들어가는지 결정하세요. 행사에는 날짜, 장소, 예약 링크, 관련 글이 있을 수 있습니다. 각 부분을 별도 필드로 만들면 재사용하고 검증하기 쉬울 수 있습니다. 동시에 며칠 동안 이어지는 행사, 미정인 장소, 나중에 추가하는 예약 링크 같은 예외도 합의해야 합니다.
다음으로 누가 콘텐츠를 만들고 승인하고 게시할지 합의하세요. 팀에 필요하다면 초안, 예약 게시, 미리보기, 수정 이력, 미디어 관리, 메뉴, 검색, 리디렉션 편집을 포함합니다. 편집자가 실수를 어떻게 고치고 변경을 취소할 수 있는지도 결정하세요.
편집 도구를 승인하기 전에 실제 사용자가 대표적인 일을 마쳐 보게 하세요. 글을 준비하고, 이미지와 대체 텍스트를 추가하고, 휴대전화에서 미리 보고, 게시를 예약하고, 실수를 고치고, 오래된 항목을 찾게 합니다. 어디에서 도움이 필요한지 살펴보세요. 보기 좋은 시연보다 팀이 평범한 업무를 끝내는 모습이 더 유용합니다.
WordPress에는 내보내기 도구가 있습니다. WXR 내보내기 형식에는 글, 페이지, 맞춤형 콘텐츠 종류, 댓글, 필드, 카테고리, 태그처럼 문서화된 콘텐츠가 담깁니다. 유용한 원본 데이터이지만 웹사이트 전체의 실행 가능한 복사본은 아닙니다.
이전 팀은 실제 설치본에 무엇이 저장돼 있는지 조사해야 합니다. 데이터베이스, 업로드 파일, 내보낸 파일, API 응답, 플러그인 전용 기록을 살펴봅니다. 변환하기 전에 안전한 원본을 보관하세요. 필요한 각 필드가 어디에 있고 기록들이 어떻게 연결되는지 확인합니다.
매핑은 이전 값마다 새 시스템의 어디에 둘지 정하는 일입니다. 작성자는 여전히 올바른 글에 연결돼야 합니다. 카테고리는 주제가 될 수 있습니다. 관련 기사 링크는 그 기사의 새 주소를 가리켜야 합니다. 빠진 값과 중복 항목은 조용히 버리지 말고 처리 방법을 합의해야 합니다.
남은 모든 페이지의 가격을 같은 기준으로 매기기 전에 대표 표본으로 이전을 입증하세요. 일반 글, 복잡한 레이아웃, 오래된 페이지, 번역 항목, 플러그인에 의존하는 기능을 포함합니다.
이미지는 따로 옮기고 확인해야 합니다. 파일이 새 위치에 있고 올바른 콘텐츠에 연결되며 적절한 크기로 표시되는지 확인하세요. 필요하면 글 안의 이미지와 다운로드 URL을 바꿉니다. 이전한 페이지에 이미지가 보이더라도 닫을 예정인 옛 사이트가 계속 제공하고 있다면 충분하지 않습니다.
콘텐츠 레이아웃도 확인해야 합니다. WordPress는 블록에 마크업과 속성이 저장될 수 있고 동적 블록에는 나중에 생성할 출력의 자리표시자만 남을 수 있다고 설명합니다. 따라서 복사한 글에는 새 시스템이 이해하지 못하는 명령이 들어 있을 수 있습니다. 페이지 빌더도 자체 구조가 있어 별도로 살펴봐야 합니다.
콘텐츠를 지원되는 구성 요소로 바꾸거나, 일부 레이아웃을 다시 만들거나, 편집팀의 승인을 받아 옛 페이지를 단순하게 할 수 있습니다. 화면에 보이는 HTML을 복사하면 경우에 따라 모습은 유지되지만, 편집자가 이후 결과를 제대로 수정할 수 있다는 증거는 아닙니다. 공개 화면과 편집 방식 모두 합의하세요.
WordPress 사이트를 옮기는 출판사를 상상해 보세요. 가상의 예시이며 고객 성과가 아닙니다. 시험 글에는 작성자, 대표 이미지, 관련 기사 두 개, 광고 문의 양식이 있습니다.
글 제목과 본문이 올바르게 들어왔습니다. 팀은 작성자와 게시일이 보존됐는지, 관련 기사가 맞는 페이지로 연결되는지, 이미지가 캡션과 대체 텍스트와 함께 옮겨졌는지 확인합니다. 편집자는 글을 열어 도입부를 바꾸고 결과를 미리 봅니다. 콘텐츠와 편집 방식을 함께 시험합니다.
양식은 별도의 일입니다. 새 양식은 합의한 정보를 수집하고, 원하는 곳에 저장하거나 전송하고, 방문자에게 유용한 확인 메시지를 보여 줘야 합니다. 누군가 시험 제출 후 실제 도착을 확인합니다. 옛 페이지에 양식이 있었다고 그 동작이 글과 함께 이전되는 것은 아닙니다.
이제 출판사는 네 가지에 대한 근거를 갖습니다. 글, 이미지, 편집자의 작업, 방문자의 문의입니다. 사이트의 다른 구조에도 같은 방식을 적용하면 ‘글을 가져올 수 있다’는 말보다 범위를 정하기 좋은 근거가 됩니다.
콘텐츠 시스템을 교체해도 도메인과 기존 페이지 경로를 유지할 수 있는 경우가 많습니다. 그 주소가 여전히 유용하다면 명확히 요구하세요. CMS를 바꾼다고 새 도메인이나 URL 형식이 필요한 것은 아닙니다.
주소를 바꿔야 한다면 옛 주소를 적절한 새 페이지와 연결하고 리디렉션을 시험하세요. 모든 옛 페이지를 홈페이지로 보내지 마세요. 삭제한 글, 합친 주제, 옮긴 상품은 방문자가 무엇을 찾으려 했는지에 맞춰 결정해야 합니다.
URL 변경을 동반한 사이트 이전에 대한 Google 안내는 URL 매핑, 영구 리디렉션, 표준 주소, 내부 링크, 이미지, 언어별 참조, 사이트맵 점검을 다룹니다. 표준 주소는 검색엔진에 어느 페이지 버전을 우선하는지 알려 줍니다. 테스트 사이트나 옛 주소가 아닌 실제로 운영 중인 새 페이지를 가리켜야 합니다.
변경을 이해하기 쉽게 하세요. 가능하다면 플랫폼 이전과 도메인, 콘텐츠, 레이아웃의 큰 변경을 나눕니다. 문제가 생겼을 때 조사하기 쉽고 이유 없이 여러 위험을 합치지 않게 됩니다.
콘텐츠 전반의 제목과 설명, 색인 규칙, 언어별 경로, 링크를 검토하세요. 출시 시 시험 환경의 제한을 올바르게 처리하세요. 필요한 경우 시험 사이트는 비공개로 유지하고 공개하려는 페이지는 접근과 색인이 가능해야 합니다.
Google의 주소 변경 도구는 도메인 또는 하위 도메인 이전을 위한 것입니다. 같은 주소에서 WordPress만 교체하는 경우에는 그것만으로 이 도구가 필요하지 않습니다.
큰 변경 뒤 검색 순위가 흔들릴 수 있습니다. 무엇을 지켜보고, 누락 페이지나 예상치 못한 방문 변화는 누가 조사하며, 어떻게 고칠지 합의하세요. 이전 계획을 순위 손실 제로나 자동 성장의 약속으로 바꿀 수는 없습니다.
웹사이트가 해야 하는 일을 기준으로 인수 검사 항목을 적으세요. 콘텐츠, 이미지, 링크를 비교한 다음 실제 동작을 시험합니다. 양식은 메시지를 올바른 곳으로 보내야 합니다. 검색은 대표 항목을 찾아야 합니다. 권한 있는 사용자는 로그인할 수 있어야 하고 권한 없는 사람은 거부돼야 합니다. 편집자는 합의한 일을 마쳐야 합니다.
구매, 예약, 연동이 범위에 있다면 그 흐름과 중요한 예외도 시험하세요. 연결된 시스템이 기록을 받아야 하는 경우 화면의 성공 표시만으로는 결과가 완성되지 않습니다.
이 작업에는 보호된 시험 환경을 사용하세요. 개인정보 접근을 제한하고 시험 때문에 실제 고객에게 메시지가 가거나 뜻하지 않은 운영 작업이 시작되지 않게 하세요. 어떤 데이터를 쓰고 시험용 복사본을 어떻게 다룰지 합의합니다.
업무를 승인할 사람과 출시 여부를 결정할 사람을 지정하세요. 남은 결함, 접근, 백업, 마지막 콘텐츠 이전, 기술적 전환 담당을 합의합니다.
양식, 오류, 중요한 사용자 흐름, 연결 서비스를 살펴볼 사람을 정하세요. 문제를 알리는 방법, 현장에서 고칠 때, 복귀가 필요한 때를 합의합니다.
새 사이트를 준비하는 동안의 변경도 계획하세요. 게시를 잠시 멈추고 마지막 변경을 옮기거나, 첫 가져오기 이후 추가된 기록을 마지막에 다시 이전할 수 있습니다. 각 단계에서 어느 시스템이 공식 기록을 보유하는지 명시하세요. 그렇지 않으면 편집자는 한곳에서 기사를 고치고 방문자는 다른 곳에서 문의할 수 있습니다.
시스템 교체 중 기존 시스템과 새 시스템을 함께 운영하는 방법 안내에서 이런 책임과 전환 결정을 더 자세히 다룹니다.
현실적인 복귀 계획도 합의하세요. WordPress의 백업 안내는 복구에 필요한 데이터베이스와 파일을 구분합니다. 복사본은 출발점일 뿐, 필요한 서비스를 복구할 수 있다는 근거도 있어야 합니다. 저희의 웹사이트 백업은 무엇을 복구해야 하나 글에서 점검할 내용을 설명합니다.
새 사이트가 문의, 주문, 편집 내용을 받거나 다른 서비스에 명령을 보낸 뒤에는 되돌리기가 더 복잡합니다. 그런 기록과 작업을 대조해야 합니다. 어제의 데이터베이스를 복원한다고 오늘의 업무가 보존된다고 가정할 수 없습니다. 출시 전에 복귀 조건과 책임자를 정하세요.
콘텐츠 양도 중요하지만 종류의 다양성도 그만큼 중요합니다. 구조가 같은 수천 개의 글은 특별한 동작이 있는 개별 페이지 몇 개보다 작업량을 예측하기 쉬울 수 있습니다.
비교 가능한 견적에는 업무의 가정이 설명돼야 합니다.
자체 팀의 시간도 확보하세요. 접근 권한을 제공하고, 질문에 답하고, 없앨 것을 결정하고, 콘텐츠를 정리하고, 편집 도구를 시험하고, 결과를 승인해야 합니다. 결정권자가 자리를 비우면 개발이 계속될 준비가 돼 있어도 일이 기다릴 수 있습니다.
공급업체에는 확정된 업무와 아직 조사할 항목을 나눠 달라고 하세요. 어려운 페이지나 플러그인 의존 기능을 시험 변환하면 전체 구축을 약속하기 전에 비용이 큰 불확실성을 줄일 수 있습니다. 조사하지 않은 내보내기 자료로 낸 고정 가격은 업체마다 다른 가정을 숨길 수 있습니다.
구축 비용뿐 아니라 각 선택지의 운영 비용도 비교하세요. 호스팅, 라이선스, 외부 서비스, 보안 업데이트, 백업, 모니터링, 지원, 이후 변경을 포함합니다. WordPress 유지에도 비용이 들고 맞춤형 소프트웨어에도 비용이 듭니다. 사용할 기간 동안 각 방법이 무엇을 제공하며 책임이 어떻게 나뉘는지 비교해야 합니다.
해결책을 고를 때 합의하세요. 맞춤형 웹사이트도 소프트웨어 프레임워크, 라이브러리, 호스팅, 연결된 서비스에 의존하며 이를 관리해야 합니다. 보안도 계속되는 일입니다. WordPress의 보안 안내는 위험 완화와 책임 분담을 설명합니다. 플랫폼을 바꿔도 그 책임을 맡을 사람은 정해야 합니다.
보안 업데이트, 백업, 모니터링, 사고 지원을 계약에 넣으세요. 누가 경고를 받고 조치할 수 있는지, 긴급 문제를 어떻게 알리는지, 실제 지원 범위가 무엇인지 명시합니다. 고장뿐 아니라 일반적인 개선을 진행할 절차도 마련합니다.
접근과 인계를 명확히 하세요. 호스팅과 배포 계정, 인증 정보, 데이터 내보내기, 문서, 라이선스, 해당하는 경우 저장소나 소스코드 접근 등이 있습니다. 소스에 접근할 수 있다는 것만으로 저작권이 이전되거나 다른 업체가 시스템을 운영할 수 있다는 뜻은 아닙니다. 유용한 인계에는 배포, 복구, 의존 구성 요소를 다루는 방법도 포함됩니다.
원래 개발자가 떠난 뒤 웹사이트를 어떻게 업데이트하고 복구하고 지원할지 설명해 달라고 하세요. 계약상 권리뿐 아니라 담당자, 접근 권한, 쓸 수 있는 문서가 나와야 합니다.
Google의 Acacio Cruz와 Ashish Bhambhani는 서비스 준비에 관한 글에서 문서화, 교육, 운영 책임의 이전을 설명합니다. 작은 기업이 Google의 팀 구조를 따를 필요는 없습니다. 책임을 맡는 사람에게 일을 할 지식과 접근 권한이 필요하다는 점은 같습니다.
LINK-V는 웹사이트와 맞춤형 시스템, 이전, 연동, 디자인, 지속적인 유지보수를 제공합니다. 구축, 권리, 인계, 지속 관리는 프로젝트에 맞춰 합의해야 합니다. 필요한 업무에 따라 맞춤형 개발이나 개별 서비스를 살펴볼 수 있습니다.
기술 명세서를 들고 올 필요는 없습니다. 문제를 볼 수 있도록 다음 정보를 준비하세요.
이 정보를 바탕으로 다음 상담의 목적이 구체적이 됩니다. 현재 사이트를 개선하면 충분한지 판단하고, 모르는 것을 찾아내며, 교체를 발주하기 전에 무엇을 입증해야 할지 합의할 수 있습니다.
대체 콘텐츠 시스템에 다른 공개 주소가 꼭 필요한 것은 아니므로 가능한 경우가 많습니다. 유용한 URL 유지 범위를 정하고 변경할 주소는 매핑해 리디렉션을 시험하세요.
기능과 데이터마다 평가해야 합니다. 없애거나 기존 서비스로 대체하거나 다시 만들어야 할 수 있습니다. WordPress 콘텐츠 내보내기만으로 모든 플러그인 기록과 동작이 옮겨진다고 알 수 없습니다.
네. WordPress를 콘텐츠 관리용으로 유지하고 별도의 애플리케이션으로 사이트를 표시할 수 있습니다. 필요한 콘텐츠와 기능에 접근할 수 있는지 확인하고 WordPress, 프런트엔드, 두 시스템의 연결을 유지보수하는 일도 계획하세요.
발주하는 편집 도구에 따라 다릅니다. 일상 업무, 권한, 미리보기 요구를 정의하고 실제 편집자가 승인 전에 시험하게 하세요. 어떤 변경에 개발이 필요한지도 합의합니다.
목록, 대표적인 어려운 페이지, 필요한 업무 흐름, 연결 서비스, 지속 운영 요구를 제공하세요. 조사와 시험 이전으로 남은 업무를 파악할 수 있습니다. 자체 팀의 결정과 시험 시간도 포함하세요.
계약에 명시된 사람이나 업체가 합니다. 접근과 문서와 함께 유지보수, 모니터링, 복구, 사고 지원을 정하세요. 맞춤형 개발에 지속 관리가 자동으로 포함되지는 않습니다.
이전을 고려하고 있다면 현재 웹사이트의 어려움과 조사할 만한 범위를 함께 논의할 수 있습니다.
지난 뉴스레터: 이미 보유한 구독형 사이트나 앱에서 더 많은 수익을 내는 법.
그 전 편: 진짜 성공 사례에서 AI 헛소리를 가려내는 법.
관심 있으세요?
매주 또는 알려 주시면 원하시는 대로 맞춰 드립니다. 괜찮으시죠?
