WordPress에서 Movable Type으로의 이전 ── '반대 방향'이기에 더욱 정리해 두어야 할 실무 절차

· · 홈페이지 제작, 기존 사이트 개선, SEO 대책, CMS, WordPress, Movable Type, 사이트 이전, 중소기업

“CMS 이전”이라고 검색하면 대부분 “Movable Type에서 WordPress로”라는 방향의 글만 나옵니다. 하지만 실무에서는 WordPress에서 Movable Type(또는 MovableType.net)으로라는 반대 방향의 이전이 합리적인 경우가 실제로 존재합니다. 반대 방향이기에 정보가 적기 때문에, 이 글에서는 이전 여부를 판단하는 기준과 실무 절차를 함께 정리합니다.

“WordPress로 만든 사이트가 있지만 업데이트하는 것은 한 달에 몇 번뿐. 그런데도 본체와 플러그인의 업데이트 알림에 계속 쫓기고 있다” ── 중소기업이나 전문직 사무소 사이트에서 흔히 볼 수 있는 상황입니다.

사이트의 목적이 문의 유치와 신뢰 형성이고, 업데이트는 공지사항과 칼럼이 중심이라면, 그런 사이트가 CMS에 요구하는 것은 확장성보다 손이 덜 가고 잘 망가지지 않는 것입니다. 이 글에서는 WordPress에서 Movable Type으로의 이전을 검토할 때의 판단 기준과, 실제 이전 절차를 해설합니다.

1. 먼저 결론부터

  • WordPress→Movable Type 이전은 기술적으로 확립되어 있으며, MovableType.net의 임포트 기능WordPress 형식의 익스포트 파일(XML)에 대응합니다. 게시물·고정 페이지뿐 아니라 본문이나 커스텀 필드에서 참조하는 이미지·파일도 가져올 수 있습니다.
  • 이전이 합리적인 경우는 업데이트 빈도가 낮고, 업데이트하는 사람이 소수이며, 확장 요건이 고정적인 사이트입니다. 동적인 회원 기능이나 이커머스를 WordPress 플러그인으로 구현한 사이트에는 적합하지 않습니다.
  • 이전의 성패를 가르는 것은 CMS의 기능 차이보다 URL 설계와 301 리다이렉트, 그리고 플러그인 기능의 대체 방침입니다. 이 부분을 사전에 정하지 않고 데이터만 옮기면 SEO와 업무 양쪽에서 문제가 생깁니다.
  • 커스텀 게시물 타입이나 커스터마이징된 XML은 그대로 읽어들이지 못하는 경우가 있으므로 변환·수작업 공수를 예상해 두어야 합니다(공식 매뉴얼에도 명시되어 있습니다).

2. 왜 “반대 방향”의 이전이 일어나는가

WordPress는 전 세계에서 가장 많이 사용되는 CMS이며, 그 자체로 훌륭한 선택지입니다. 하지만 동적 CMS이기 때문에 발생하는 운영 부담도 있습니다.

  • 업데이트 대응이 끊이지 않는다. 본체·테마·플러그인의 업데이트는 계속해서 발생하며, 방치하는 것 자체가 리스크가 됩니다. CMS와 플러그인의 취약점에 대해서는 일본 IPA(정보처리추진기구)가 반복적으로 주의를 환기하고 있으며, 특히 플러그인에서 비롯된 문제가 두드러집니다.
  • 담당자가 없어지기 쉽다. 제작 회사가 납품한 채로 유지보수 계약이 없어서, “아무도 업데이트 버튼을 누르지 않는” 사이트가 드물지 않습니다.
  • 플러그인 궁합 문제. 업데이트할 때마다 레이아웃이 깨지거나 기능이 멈추는 구성에서는 업데이트 자체가 두려워져, 방치가 더욱 진행됩니다.

Movable Type은 미리 HTML을 생성해서 배포하는 정적 퍼블리싱을 기본으로 하는 CMS입니다(필요하면 다이내믹 배포도 선택할 수 있습니다). 방문자에게 반환하는 페이지가 정적 파일이면, 공개 측에서 CMS 프로그램이 동작하지 않는 만큼 공격 표면과 장애 지점을 줄일 수 있습니다.

여기에 SaaS형인 MovableType.net을 선택하면, CMS 본체의 업데이트나 보안 대책은 서비스 측이 실시하며, SSL(HTTPS)도 추가 비용 없이 이용할 수 있습니다. “사이트 내용에는 신경 쓰고 싶지만, CMS 관리는 신경 쓰고 싶지 않다”는 체제에 맞는 구성입니다.

3. 이전 대상 선택지 ── Movable Type과 MovableType.net

이전 대상은 크게 두 가지입니다.

관점 Movable Type(소프트웨어판) MovableType.net(SaaS)
서버 자사·호스팅으로 준비 불필요(서비스에 포함)
본체 업데이트·보안 자사(또는 유지보수 업체)가 실시 서비스 측이 실시
커스터마이징 플러그인·독자 개발까지 가능 템플릿 커스터마이징 중심
승인 흐름·스테이징 구성에 따라 다름 비즈니스 플랜 이상에서 표준 탑재
적합한 경우 확장 요건이 많거나 기존 기반에 올리고 싶은 경우 운영을 가볍게 하고 싶고 전담 담당자가 없는 경우

소규모 인원으로 운영하는 회사 사이트·전문직 사이트라면 먼저 MovableType.net을 검토하고, 요건이 부족할 경우 소프트웨어판을 검토하는 순서가 현실적입니다. 승인 흐름(신청·승인)과 스테이징 기능은 “소장의 확인을 거친 뒤 공개하고 싶다” 같은 전문직 사무소의 운영과 궁합이 좋은 기능입니다.

4. 이전 절차의 전체 흐름

이전은 다음 순서로 진행합니다. 데이터 이전(절차 3)보다 URL 목록화(절차 2)를 먼저 두는 것이 포인트입니다.

1. 현황 목록화 ── 페이지·기능·플러그인 목록화
2. URL 설계 ── 신구 URL 대응표(301 매핑) 확정
3. 데이터 이전 ── WordPress 익스포트 → 임포트
4. 템플릿 재구축 ── 디자인과 메타 정보 구현
5. 기능 대체 구현 ── 폼·검색 등
6. 검증 ── 신구 대조, 리다이렉트 실측
7. 공개 ── DNS 전환, 사이트맵 제출, Search Console 확인

5. 콘텐츠 이전의 실무

WordPress 측에서는 관리 화면의 익스포트 기능으로 XML(WXR 형식)을 출력합니다. MovableType.net 측에서는 툴의 임포트 화면에서 이 파일을 읽어들입니다. 공식 매뉴얼에 따르면 가져오기 대응 범위는 다음과 같습니다.

항목 이전되는 방식
게시물(글) 엔트리로 임포트
고정 페이지 엔트리(웹페이지)로 임포트
이미지·첨부 파일 본문·커스텀 필드 내의 URL을 추출해 파일을 다운로드한 뒤 아이템으로 가져옴
카테고리 이전 가능(계층 구조는 방법에 따라 주의 필요)
커스텀 게시물 타입 그대로 읽어들이지 못하는 경우가 있어 변환·수작업 필요
커스텀 필드 변환 툴 대응 또는 수작업 대응

WordPress의 커스텀 게시물 타입·커스텀 필드를 많이 사용하고 있다면, 공식 변환 툴과 절차 해설을 참고하면서 이전 대상 콘텐츠 종류별로 “자동으로 이전되는 것/변환이 필요한 것/직접 다시 만들어야 하는 것”으로 분류합니다. 이 분류표가 그대로 이전 견적이 됩니다.

또한 게시물 수가 많거나 구성이 복잡한 경우를 대비해 공식 이전 지원 창구도 마련되어 있습니다. 소프트웨어판 Movable Type으로의 이전에 대해서도 공식 Q&A가 공개되어 있습니다.

6. URL과 SEO의 승계

CMS 이전에서 SEO 평가를 떨어뜨리는 원인의 대부분은 CMS의 종류가 아니라 URL 처리 방식에 있습니다.

WordPress의 퍼머링크 설정(/?p=123, /2024/05/post-name/, /category/post-name/ 등)과 이전 후의 URL 구조는 보통 일치하지 않습니다. 다음 절차로 승계합니다.

  1. 전체 URL 목록화. 게시물·고정 페이지·카테고리·태그·이미지 페이지를 포함해 공개 중인 전체 URL을 목록화합니다(사이트맵이나 크롤링 툴을 이용).
  2. 새 URL로의 대응표 확정. 이전 후의 URL 규칙을 먼저 정하고, 기존 URL→새 URL의 대응표(301 매핑)를 만듭니다. 검색 유입이 많은 페이지부터 우선적으로 확인합니다.
  3. 301 리다이렉트 설정. 바뀌는 URL에는 영구 리다이렉트(301)를 설정합니다.
  4. 페이지 내 요소 승계. 타이틀, 메타 디스크립션, 제목 구조, 구조화 데이터는 템플릿 재구축 시 의식적으로 승계합니다. SEO 플러그인이 출력하던 요소는 이전 후 템플릿 구현으로 대체됩니다.
  5. 공개 후 확인. XML 사이트맵 재제출, Search Console에서 인덱스와 오류 모니터링, 주요 페이지의 리다이렉트 실측(상태 코드 확인)을 실시합니다.

이 “URL 설계가 먼저, 데이터 이전과 디자인은 나중”이라는 순서는 CMS 이전에 국한되지 않고 사이트 리뉴얼 전반의 원칙입니다. 당사의 사이트 리뉴얼 사례에서도 가장 먼저 한 것은 디자인이 아니라 URL 목록화였습니다.

7. 플러그인 기능의 대체 ── “찾는다”와 “필요 없어진다”를 나누기

WordPress에서 이전할 때 플러그인 목록은 불안 요소로 보이기 쉽습니다. 하지만 기능별로 정리하면 대부분 다음 세 가지로 분류할 수 있습니다.

분류 예시 이전 후 처리
다시 만든다 문의 폼, 사이트 내 검색 이전 대상의 폼 기능·검색 기능, 또는 외부 폼 서비스로 구현
템플릿에 구현한다 SEO 계열(메타 출력), 관련 게시물, 브레드크럼, OGP 템플릿에 직접 포함(플러그인 업데이트에서 해방)
필요 없어진다 보안 대책 계열, 캐시 계열, 백업 계열 정적 배포·SaaS 구성에서는 역할 자체가 사라지는 경우가 많음

특히 문의 폼은 고객 유치 사이트의 생명선입니다. 이전을 계기로 폼의 알림 메일이 도착하지 않게 되는 사고는 실제로 일어나므로, 공개 전에 반드시 실제로 전송해 확인합니다. 폼 메일 미도착에 대해서는 “문의 폼 메일이 도착하지 않을 때의 조사 방법“에 정리해 두었습니다.

8. 어떤 사이트에 적합한가 ── 전문직·소규모 인원 운영의 회사 사이트

정리하자면, WordPress→Movable Type(특히 MovableType.net)으로의 이전이 적합한 사이트의 특징은 다음과 같습니다.

  • 업데이트는 공지사항·칼럼·실적 소개가 중심이며 업데이트 내용이 정형적
  • 전담 웹 담당자가 없어 CMS 유지보수에 인력을 할애할 수 없음
  • 세무사·법무사 등 전문직 사이트처럼 공개 전에 확인·승인을 거치고 싶음
  • 회원 기능·이커머스·예약 시스템 같은 동적 기능이 없음(또는 외부 서비스로 분리 가능)
  • 보안 사고가 곧바로 신용 문제로 이어지는 업종이라 공격 표면을 줄이고 싶음

반대로 플러그인을 통한 확장을 앞으로도 적극적으로 사용할 계획이 있는 사이트나, 동적 기능이 사이트의 핵심인 사이트는 WordPress에 남아서(그리고 유지보수 체제를 갖추는 편이) 합리적입니다. 이전은 목적이 아니라 운영 체제와 사이트 요건을 맞추기 위한 수단입니다.

사이트 전체 구성이나 비용감으로 검토하고 싶다면 “중소기업의 홈페이지 제작 비용“과 “기술계 B2B 서비스 페이지 구성“도 함께 참고해 주세요.

CMS 이전을 검토 중이신 분께

WordPress의 유지보수 부담으로 고민하고 계셔도 바로 이전을 결정할 필요는 없습니다. 우선 현재 사이트의 페이지·기능·플러그인을 목록화하고, 이전했을 때 무엇이 바뀌는지(무엇이 필요 없어지고, 무엇을 다시 만들어야 하는지)를 정리하는 것부터 시작하는 것이 안전합니다.

합동회사 코무라소프트에서는 CMS 이전을 포함한 홈페이지 제작과, 이전 방침 정리를 포함한 기술 상담을 제공하고 있습니다. 현황 목록화부터 상담을 원하시면 문의를 통해 연락해 주세요.

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

WordPress의 게시물을 Movable Type으로 그대로 옮길 수 있나요?
게시물·고정 페이지 등 기본적인 콘텐츠는 이전할 수 있습니다. MovableType.net의 임포트 기능은 WordPress 형식의 익스포트 파일(XML)에 대응하며, 본문이나 커스텀 필드에서 참조하는 이미지·파일도 함께 가져올 수 있습니다. 다만 커스텀 게시물 타입이나 크게 커스터마이징된 데이터는 그대로 읽어들이지 못하는 경우가 있어 변환이나 수작업이 필요합니다. 이전 전에 어떤 콘텐츠가 WordPress의 표준 기능이고 어떤 콘텐츠가 플러그인·커스터마이징에 의존하는지 분류하는 것이 중요합니다.
CMS를 이전하면 SEO 평가가 떨어지지 않나요?
CMS의 종류 자체보다 URL이 바뀌는지 여부와 리다이렉트를 올바르게 설정했는지가 영향을 미칩니다. 이전 전에 전체 URL 목록표를 만들고, 새 URL로의 대응표를 확정한 뒤, 바뀌는 URL에는 301 리다이렉트를 설정합니다. 타이틀·메타 디스크립션·제목 구조를 승계하고, 공개 후 XML 사이트맵을 재제출하고 Search Console에서 확인하면 이전을 이유로 한 큰 하락은 피할 수 있습니다. 반대로 이 작업을 생략하면 CMS가 무엇이든 평가는 떨어집니다.
WordPress 플러그인으로 구현했던 기능은 어떻게 되나요?
플러그인이라는 구조 자체는 그대로 가져올 수 없으므로 기능별로 대체 방법을 정합니다. 문의 폼은 이전 대상 CMS의 폼 기능이나 외부 폼 서비스로 다시 만들고, SEO 계열 플러그인이 출력하던 메타 정보는 템플릿에 구현하며, 관련 게시물이나 브레드크럼도 템플릿에 포함시킵니다. 한편 보안 대책이나 백업 관련 플러그인은 정적 배포·SaaS형 구성에서는 역할 자체가 필요 없어지는 경우가 많아, '대체할 기능'과 '애초에 필요 없어지는 기능'을 나누어 생각하는 것이 핵심입니다.
Movable Type과 MovableType.net 중 어느 쪽을 선택해야 하나요?
직접 서버를 관리하며 플러그인이나 데이터베이스 연동을 포함해 자유롭게 확장하고 싶다면 소프트웨어판 Movable Type이, 서버 관리와 CMS 본체 업데이트에서 벗어나 운영을 가볍게 하고 싶다면 SaaS형 MovableType.net이 적합합니다. 중소기업의 회사 사이트나 전문직 사이트처럼 전담 웹 담당자가 없는 체제라면, 본체 업데이트와 보안 대응을 서비스 측에 맡길 수 있는 MovableType.net을 우선 검토하는 것이 현실적입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.

블로그 목록으로 돌아가기