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

이 글은 WordPress로 만든 중소기업·전문직 사무소 사이트를 운영하는 담당자와, 그 이전을 맡는 제작 회사를 대상으로, 「이전해야 하는지의 판단 기준」과 「실제 이전 절차」를 함께 정리한 것입니다.

CMS 이전을 검색하면 「Movable Type에서 WordPress로」라는 글만 눈에 띕니다. 하지만 실무에서는 WordPress에서 Movable Type(또는 MovableType.net)으로라는 반대 방향의 이전이 합리적인 경우가 분명히 있습니다. 반대 방향이라 정보가 적기 때문에, 이 글에서 이전 판단과 실무 절차를 정리합니다.

「WordPress로 만든 사이트는 있지만, 업데이트는 한 달에 몇 번뿐이다. 그런데도 본체와 플러그인 업데이트 알림에 쫓긴다」──중소기업이나 전문직 사무소 사이트에서 흔한 상태입니다.

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

이 글에서 쓰는 용어

발주 측 담당자도 읽을 수 있도록, 전문 용어를 먼저 정리합니다.

1. 먼저 결론

• WordPress→Movable Type 이전은 기술적으로 확립되어 있으며, MovableType.net의 임포트 기능은 WordPress 형식의 익스포트 파일(XML)을 지원합니다. 게시물·고정 페이지에 더해, 본문이나 커스텀 필드에서 참조하는 이미지·파일도 가져올 수 있습니다.
• 이전이 합리적인 것은 업데이트 빈도가 낮고·업데이트하는 사람이 소수이며·확장 요건이 고정된 사이트입니다. 동적 회원 기능이나 EC를 WordPress 플러그인으로 만든 사이트에는 맞지 않습니다.
• 이전의 성패를 가르는 것은 CMS 기능 차이보다 URL 설계와 301 리다이렉트, 그리고 플러그인 기능의 대체 방침입니다. 여기를 미리 정하지 않고 데이터만 옮기면, SEO와 업무 양쪽에서 막힙니다.
• 커스텀 게시물 타입이나 커스터마이즈된 XML은 그대로 읽히지 않는 경우가 있어, 변환·손질 공수를 잡아 둡니다(공식 매뉴얼에도 명시되어 있습니다).

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 23건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 왜 「반대 방향」 이전이 일어나는가

WordPress는 세계에서 가장 많이 쓰는 CMS이며, 그 자체로 좋은 선택입니다. 한편으로 동적 CMS이기 때문에 운영 부담이 있습니다.

• 업데이트 대응을 멈출 수 없습니다. 본체·테마·플러그인 업데이트는 계속 발생하고, 방치가 곧 리스크가 됩니다. CMS와 플러그인 취약점에 대해서는 IPA가 반복해서 주의를 환기하고 있으며, 특히 플러그인에서 비롯된 문제가 두드러집니다.
• 담당자가 비는 경우가 많습니다. 제작 회사가 납품한 뒤 유지보수 계약이 없어, 「아무도 업데이트 버튼을 누르지 않는」 사이트는 드물지 않습니다.
• 플러그인 궁합 문제. 업데이트할 때마다 화면이 깨지거나 기능이 멈추는 구성에서는, 업데이트 자체가 두려워지고 방치가 더 진행됩니다.

Movable Type은 미리 HTML을 만들어 배포하는 정적 퍼블리싱이 기본인 CMS입니다(필요하면 다이내믹 퍼블리싱도 고를 수 있습니다). 방문자에게 돌려주는 페이지가 정적 파일이면, 공개 측에서 CMS 프로그램이 돌지 않는 만큼 공격 표면과 장애 지점을 줄일 수 있습니다.

여기에 SaaS형 MovableType.net을 고르면, CMS 본체 업데이트와 보안 대책은 서비스 측이 실시하고, SSL(HTTPS)도 추가 비용 없이 쓸 수 있습니다. 「사이트 내용은 손보고 싶지만, CMS 관리는 맡고 싶지 않다」는 체제에 맞는 구성입니다.

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

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

소수 인원으로 운영하는 기업 사이트·전문직 사이트라면, 먼저 MovableType.net을 검토하고, 요건이 들어가지 않을 때 소프트웨어판을 검토하는 순서가 현실적입니다. 승인 흐름(신청·승인)과 스테이징 기능은, 「소장의 확인을 거친 뒤 공개하고 싶다」는 전문직 사무소 운영과 잘 맞습니다.

4. 이전 절차의 전체 그림

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

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

절차 2(URL 설계)를 절차 3(데이터 이전)보다 앞에 두는 이유가 있습니다. URL 규칙은 301 대응표와, 게시물 본문 안의 내부 링크 양쪽에 스며들기 때문입니다. 데이터를 먼저 넣은 뒤 「역시 URL 규칙을 바꾸자」가 되면, 301 대응표를 다시 만드는 것으로 끝나지 않습니다. 이미 임포트한 게시물 본문에 남은 옛 URL 링크를 전부 다시 찾고, 검증도 다시 해야 합니다. 반대로 URL 규칙만 먼저 확정하면, 데이터 이전(절차 3)과 템플릿 재구축(절차 4)은 병행해서 진행할 수 있습니다. 먼저 정할수록 되돌아감이 줄어드는 순서라고 이해하면 됩니다.

5. 콘텐츠 이전의 실무

5.1. WordPress 측 ── 익스포트

WordPress 관리 화면에서 다음처럼 조작합니다(WordPress 공식 「Tools Export screen」).

1. 왼쪽 메뉴의 「도구」→「내보내기」를 엽니다.
2. 내보낼 범위를 고릅니다. 「모든 콘텐츠」를 고르면 게시물·고정 페이지·댓글·커스텀 필드·텀(카테고리, 태그)·내비게이션 메뉴·커스텀 게시물 타입이 하나의 파일로 모입니다.
3. 「내보내기 파일 다운로드」 버튼을 누르면 XML 파일이 저장됩니다. 이것이 WXR 형식 파일입니다.

파일이 너무 커질 때는 이 화면에서 나눌 수 있습니다. 「모든 콘텐츠」가 아니라 「게시물」을 고르면, 카테고리·작성자·기간(시작일과 종료일)·상태로 좁혀 내보낼 수 있습니다. 「고정 페이지」도 작성자·기간·상태로 좁힐 수 있습니다. 게시물이 많은 사이트는 「2023년」「2024년」…처럼 기간으로 잘라 여러 파일로 나눈 뒤 차례로 읽는 편이 확실합니다. 「미디어」만 골라 내보낼 수도 있습니다.

5.2. MovableType.net 측 ── 임포트

1. 관리 화면 왼쪽 사이드바에서 「도구」→「임포트」를 클릭합니다.
2. 읽을 파일을 지정합니다. 지원 형식은 MovableType.net에서 내보낸 파일, Movable Type 형식, WordPress 형식, CSV 형식입니다. WordPress에서 낸 XML은 「WordPress 형식」으로 그대로 읽을 수 있습니다.
3. 「아이템 임포트」를 켜면 게시물 본문이나 커스텀 필드에서 URL을 추출하고, 파일을 다운로드해 아이템(이미지·첨부 파일)으로 가져옵니다.

공식 매뉴얼에는 실제 작업에서 중요한 주의가 명시되어 있습니다.

• 읽기에 시간이 걸릴 수 있습니다. 끝나면 등록 메일 주소로 완료 메일이 오는 구조입니다. 「화면이 멈췄다」고 오해하고 중간에 조작하지 마십시오. 파일 크기나 건수 상한은 공식 매뉴얼에 명시되어 있지 않지만, 한 번에 통과하지 않거나 너무 오래 걸리면 5.1의 기간 분할이 현실적인 우회입니다.
• 게시물의 BASENAME(URL에 쓰이는 문자열)은 반각 영숫자가 들어 있는 경우 반각 영숫자만 이어받습니다. 다른 게시물과 겹치면 숫자가 붙습니다. 일본어 슬러그를 쓰던 사이트는 여기서 URL이 바뀝니다. 6장의 신구 URL 대응표에서 반드시 반영하십시오.
• 웹페이지는 기사로 임포트됩니다.

공식 매뉴얼에 따르면, 가져오기 범위는 다음과 같습니다.

카테고리 계층이 깨졌을 때의 고치는 방법은 공식 매뉴얼의 「임포트」 페이지에 구체적으로 나와 있습니다. Movable Type 형식으로 임포트할 때, 익스포트 파일 안의 PRIMARY CATEGORY:와 CATEGORY: 값을 루트카테고리명/서브카테고리명처럼 슬래시로 구분한 형태로 바꾸면, 계층을 유지한 채 가져올 수 있습니다. 카테고리 계층을 업무상 반드시 유지해야 하는 사이트에서는, 이 바꾸기를 이전 작업 절차에 넣어 두십시오. 절차 원문은 MovableType.net의 임포트 매뉴얼에 있습니다.

같은 매뉴얼에는 커스텀 게시물 타입에 대한 구체적인 수정 예도 있습니다. 예를 들어 <wp:post_type>portfolios</wp:post_type>을 <wp:post_type>page</wp:post_type>으로 바꾸는 식입니다. 「읽히지 않았다」로 끝내지 않고, XML을 텍스트로 고치면 통과하는 경우가 있다는 것만 알아도 견적이 달라집니다.

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에서 이전할 때 플러그인 목록은 불안의 씨앗처럼 보입니다. 하지만 기능마다 정리하면, 대부분은 다음 셋으로 나뉩니다.

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

8. 정리 ── 어떤 사이트에 맞는가(전문직·소수 인원 운영의 기업 사이트)

WordPress→Movable Type(특히 MovableType.net) 이전이 맞는 사이트 모습을 듭니다.

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

반대로, 플러그인 확장을 앞으로도 적극 쓸 계획이 있는 사이트나, 동적 기능이 사이트의 핵심인 사이트는 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 플러그인으로 구현하던 기능은 어떻게 되나요?

플러그인이라는 구조 자체는 가져올 수 없으므로 기능마다 대체 방법을 정합니다. 문의 폼은 이전 대상의 폼 기능이나 외부 폼 서비스로 다시 만들고, SEO 계열 플러그인이 출력하던 메타 정보는 템플릿으로 구현하며, 관련 게시물과 브레드크럼도 템플릿에 넣습니다. 한편 보안 대책이나 백업 계열 플러그인은 정적 배포·SaaS형 구성에서는 역할 자체가 필요 없어지는 경우가 많아, '대체할 기능을 찾는 일'과 '애초에 필요 없어지는 기능'을 나누어 보는 것이 핵심입니다.

Movable Type과 MovableType.net 중 어느 쪽을 골라야 하나요?

자사에서 서버를 관리하고, 플러그인이나 데이터베이스 연동까지 자유롭게 확장하고 싶다면 소프트웨어판 Movable Type이, 서버 관리와 CMS 본체 업데이트를 맡기고 운영을 가볍게 하고 싶다면 SaaS형 MovableType.net이 맞습니다. 중소기업 기업 사이트나 전문직 사이트처럼 전담 웹 담당자가 없는 체제에서는, 본체 업데이트와 보안 대응을 서비스 측에 맡길 수 있는 MovableType.net을 출발점으로 검토하는 편이 현실적입니다.

저자 프로필

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

Go Komura

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

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