목차

WordPress를 떠나는 이유

WordPress는 전체 웹사이트의 약 40%를 구동하고 있지만, 2024년 이후 그 비율은 꾸준히 줄어들고 있습니다. 수많은 팀과 이야기를 나눠보면 이유는 한결같습니다. 보안 피로, 플러그인 과부하, 그리고 성능의 한계입니다.

테마와 필수 플러그인만 설치한 WordPress 사이트도 초기 로드 시 30~80개의 HTTP 요청이 발생합니다. 플러그인을 하나 추가할 때마다 PHP 실행 시간과 데이터베이스 쿼리가 늘어나고, 보안 취약점도 함께 늘어납니다. 결국 개발팀은 새로운 기능을 만들기보다 플러그인 업데이트와 보안 패치에 더 많은 시간을 쏟게 됩니다.

Next.js는 이 구조를 완전히 뒤집습니다. 매 요청마다 HTML을 생성하는 단일 PHP 애플리케이션 대신, 빌드 시점에 페이지를 사전 렌더링하고 엣지 CDN에서 제공하며 클라이언트에서 인터랙티브하게 동작하는 React 프레임워크를 사용합니다. 그 결과 페이지 로딩은 1초 이내로 줄어들고, 방문자에게 데이터베이스 쿼리는 제로가 되며, 코드베이스는 개발팀이 직접 완전히 통제할 수 있게 됩니다.

한계에 부딪히는 순간들

대부분의 팀은 마이그레이션을 결정하기 전에 다음 중 하나를 경험합니다.

  • Core Web Vitals 실패 — Elementor나 WPBakery 같은 페이지 빌더를 사용하면 LCP와 CLS 점수가 기준을 통과하기 어렵습니다
  • 플러그인 충돌 — 플러그인 업데이트 하나로 사이트 전체가 망가지고, 원인을 찾으려면 플러그인을 하나씩 비활성화해야 합니다
  • 호스팅 비용 — WP Engine, Kinsta 같은 매니지드 WordPress 호스팅은 월 3만~20만 원을 받지만, 무료 Vercel 배포로도 동일한 성능을 낼 수 있습니다
  • 개발자 경험 — 컴포넌트 기반 React 개발에 익숙한 개발자에게 PHP 템플릿은 구시대의 유물처럼 느껴집니다
  • 보안 사고 — WordPress 취약점의 97%는 코어가 아닌 플러그인과 테마에서 발생합니다

Next.js vs WordPress: 직접 비교

항목 WordPress Next.js
렌더링 매 요청마다 서버사이드 PHP 정적 생성 + ISR + 서버 컴포넌트
성능 일반적으로 LCP 2.5~6초 일반적으로 LCP 0.5~1.5초
보안 지속적인 플러그인/테마 취약점 공격 표면 없음 (CDN의 정적 파일)
호스팅 비용 매니지드 월 3만~20만 원 Vercel 무료 플랜으로 대부분 커버
SEO 제어 테마 + Yoast에 의존 메타, 구조화 데이터, 사이트맵 완전 제어
콘텐츠 편집 내장 관리자 패널 헤드리스 CMS (Sanity, Strapi, Payload, Supabase)
확장성 캐싱 레이어, CDN, DB 튜닝 필요 엣지 네이티브, 설정 없이 수백만 요청 처리
개발자 경험 PHP + 훅 + 템플릿 계층 구조 React + TypeScript + 현대적 툴링
빌드 시간 없음 (런타임 렌더링) 페이지 수에 따라 수 초~수 분
이미지 처리 플러그인 필요 (Smush, ShortPixel) 자동 최적화가 내장된 next/image

WordPress가 여전히 유리한 경우

WordPress가 모든 상황에서 나쁜 선택인 것은 아닙니다. 개발자가 없는 팀이 간단한 블로그나 소개 사이트를 빠르게 만들어야 한다면, 매니지드 호스팅과 함께 WordPress를 사용하는 것이 여전히 가장 빠른 길입니다. 방대한 테마와 플러그인 생태계 덕분에 코드를 한 줄도 작성하지 않고도 비기술 사용자가 실용적인 사이트를 구축할 수 있습니다.

하지만 커스텀 기능, 성능 최적화, 또는 빠른 개발 속도가 필요한 순간, WordPress는 발목을 잡는 존재가 됩니다.

기대할 수 있는 성능 향상

저희는 200개 이상의 WordPress 사이트를 Next.js로 마이그레이션했습니다. 일관되게 나타나는 수치를 공유합니다.

LCP (최대 콘텐츠풀 페인트): 평균 3.2초에서 0.9초로 — 72% 향상. 정적 생성 덕분에 요청이 도착하기 전에 HTML이 이미 준비되어 있습니다.

CLS (누적 레이아웃 이동): 0.18에서 0.02로. Next.js Image 컴포넌트가 이미지 크기를 자동으로 처리해 WordPress 테마에서 흔히 발생하는 레이아웃 흔들림이 사라집니다.

FID (첫 번째 입력 지연) / INP (다음 페인트까지의 상호작용): 180ms에서 45ms로. jQuery도 없고, 메인 스레드를 점유하는 플러그인 JavaScript도 없습니다.

TTFB (첫 번째 바이트까지의 시간): 캐시 상태에서 600ms에서 50ms로. 엣지 CDN과 오리진 서버는 처음부터 공정한 비교가 아닙니다.

페이지 용량: 평균 2.8MB에서 340KB로. 테마의 불필요한 CSS도, 렌더링을 막는 플러그인 스크립트도 없습니다.

이 수치들은 곧바로 비즈니스 성과로 이어집니다. Google은 Core Web Vitals를 검색 순위 신호로 활용합니다. 빠른 사이트는 더 높은 전환율을 기록합니다. 로딩 시간이 100ms 개선될 때마다 전환율이 약 1% 향상된다는 데이터가 있습니다.

단계별 마이그레이션 프로세스

1단계: 콘텐츠 감사 및 내보내기

코드에 손대기 전에 WordPress의 모든 것을 먼저 정리하세요.

  • 페이지와 포스트 — 커스텀 필드(ACF, 메타 박스)를 포함한 모든 콘텐츠 내보내기
  • 미디어 라이브러리 — 모든 이미지와 파일 다운로드
  • URL 구조 — 모든 퍼머링크, 카테고리 URL, 커스텀 포스트 타입 슬러그 문서화
  • 리다이렉트 — 기존 리다이렉트 규칙 내보내기
  • 폼 — 모든 폼 설정과 전송 목적지 문서화
  • 서드파티 연동 — 모든 플러그인과 그 용도 목록화

내보내기에는 wp-cli 또는 WordPress 내장 내보내기 도구를 사용하세요. ACF 필드와 커스텀 포스트 타입은 REST API를 통해 구조화된 JSON으로 받아올 수 있습니다.

2단계: 콘텐츠 레이어 선택

마이그레이션에서 가장 중요한 결정은 WordPress 이후 콘텐츠를 어디에 저장하느냐입니다. 선택지를 살펴봅니다.

헤드리스 WordPress — WordPress를 백엔드로 유지하고 REST API 또는 WPGraphQL을 통해 Next.js에 콘텐츠를 공급합니다. 좋은 중간 단계이지만, WordPress 유지 관리 부담은 그대로입니다.

헤드리스 CMS — Sanity, Strapi, Payload CMS, Contentful 등 헤드리스 아키텍처에 최적화된 플랫폼입니다. 유연성 면에서 Sanity와 Payload를 가장 추천합니다.

데이터베이스 직접 연결 — Supabase 또는 PlanetScale. 커스텀 관리 인터페이스와 함께 PostgreSQL에 콘텐츠를 저장합니다. 최대한의 제어권을 갖지만 초기 작업량이 많습니다.

Markdown/MDX — 개발자 블로그나 문서 사이트에 적합합니다. 콘텐츠가 저장소 안에 git으로 버전 관리됩니다.

3단계: Next.js 사이트 구축

App Router를 사용해 create-next-app으로 시작하세요. WordPress의 템플릿 계층 구조를 Next.js 레이아웃과 페이지로 매핑합니다.

  • header.php / footer.php → app/layout.tsx
  • page.php → app/page.tsx
  • single.php → app/blog/[slug]/page.tsx
  • archive.php → app/blog/page.tsx
  • functions.php → app/api/ 내 API 라우트

React 컴포넌트로 디자인을 새롭게 구현하세요. 수년간 쌓인 CSS 부채를 청산하고 현대적인 디자인 시스템으로 새 출발할 수 있는 기회입니다.

4단계: SEO 마이그레이션

마이그레이션의 성패를 가르는 단계입니다. 다음 섹션에서 자세히 다룹니다.

5단계: 테스트 및 론칭

두 사이트를 병행 운영하면서 Screaming Frog 등의 도구로 새 사이트를 크롤링해 기존 사이트와 비교하세요.

  • 모든 기존 URL에 리다이렉트 또는 일치하는 새 URL이 있는지 확인
  • 모든 메타 타이틀과 설명이 유지되거나 개선되었는지 확인
  • 구조화 데이터(schema.org)가 올바르게 렌더링되는지 확인
  • XML 사이트맵이 유효하고 Search Console에 제출되었는지 확인
  • 캐노니컬 태그가 올바른 URL을 가리키는지 확인
  • Open Graph와 Twitter Card 메타가 있는지 확인
  • 내부 링크가 모두 정상 작동하는지 확인

마이그레이션 중 SEO 관리

SEO는 WordPress에서 마이그레이션하는 모든 팀의 최대 관심사입니다. 검색 순위를 잃으면 새 사이트가 아무리 빨라도 마이그레이션은 실패입니다.

URL 매핑

기존 URL과 새 URL의 완전한 매핑 표를 만드세요. 단 하나의 페이지도 빠뜨리면 안 됩니다. 스프레드시트나 스크립트를 사용해 리다이렉트 규칙을 생성하고, next.config.js 또는 호스팅 플랫폼에서 301 영구 리다이렉트로 구현하세요.

메타 데이터 보존

Yoast 또는 RankMath에서 모든 SEO 제목, 메타 설명, Open Graph 데이터를 추출하세요. 이를 Next.js의 해당 페이지에 매핑합니다. 자동 생성 메타에 의존하지 말고, 트래픽 상위 50개 페이지는 수동으로 직접 확인하세요.

구조화 데이터

WordPress 플러그인은 스키마 마크업을 자동으로 생성합니다. Next.js에서는 이를 직접 제어합니다. 홈페이지에 Organization, 블로그 포스트에 Article, 모든 페이지에 BreadcrumbList, FAQ 섹션이 있는 페이지에 FAQPage, 해당되는 경우 LocalBusiness를 JSON-LD로 구현하세요.

XML 사이트맵

next-sitemap 또는 커스텀 API 라우트를 사용해 동적 사이트맵을 생성하세요. 론칭 직후 Google Search Console에 즉시 제출하세요.

론칭 후 모니터링

처음 4주간 Search Console을 매일 확인하세요. 크롤링 오류 및 404 오류, 색인 감소, 순위 변동(2~4주간은 정상), Core Web Vitals 개선 여부를 주시하세요.

WordPress 이후 콘텐츠 관리

WordPress를 떠나는 것에 대한 가장 흔한 반대 이유는 관리자 패널을 잃는다는 것입니다. 콘텐츠 편집자들은 익숙한 WordPress 에디터를 선호합니다.

하지만 현대적인 헤드리스 CMS 플랫폼들은 이 격차를 완전히 좁혔습니다. Sanity Studio, Payload CMS, Strapi 모두 실시간 미리보기, 드래그앤드롭, 미디어 관리를 갖춘 풍부한 편집 환경을 제공합니다. 적응 기간이 지나면 오히려 더 선호하는 편집자들이 많습니다.

가장 간단한 옵션을 원하는 팀이라면 Payload CMS를 주목하세요. Next.js 앱 내부에서 실행되고, 기존 데이터베이스를 그대로 사용하며, WordPress에 버금가는 관리자 패널을 제공합니다 — 보안이나 성능 문제는 전혀 없이 말이죠.

흔히 저지르는 마이그레이션 실수

모든 URL을 리다이렉트하지 않는 것. WordPress에 존재했던 모든 URL에는 리다이렉트가 필요합니다. 페이지네이션 URL, 첨부 파일 페이지, 작성자 아카이브, 피드 URL까지 포함해서요. 하나라도 놓치면 링크 에쿼티가 새어 나갑니다.

모니터링 없이 론칭하는 것. 업타임 모니터링, 오류 추적(Sentry), 분석 도구는 론칭 후가 아니라 론칭 전에 준비해야 합니다.

첫 버전부터 과도하게 설계하는 것. 콘텐츠와 디자인 마이그레이션을 먼저 완료하세요. 새로운 기능은 마이그레이션이 안정된 후에 추가하세요. 리디자인과 플랫폼 전환을 동시에 진행하면 리스크가 두 배로 늘어납니다.

미디어 라이브러리를 간과하는 것. WordPress는 업로드마다 여러 사이즈의 이미지를 생성합니다. 마이그레이션 전에 이미지 전략을 결정하고, 이미지를 일괄 변환하세요.

RSS 피드를 잊는 것. WordPress 블로그에 RSS 구독자가 있다면, 피드 URL을 유지하거나 리다이렉트해야 합니다.

WordPress를 유지해야 할 때

상황을 솔직하게 평가하세요. WordPress가 여전히 올바른 선택인 경우도 있습니다.

  • 개발자가 없고 개발 예산도 없는 경우
  • 콘텐츠 팀이 헤드리스 대안이 없는 특정 WordPress 플러그인에 크게 의존하는 경우
  • 복잡한 상품 구성이 있는 WooCommerce 쇼핑몰을 운영하는 경우 (이 경우 Next.js보다 Shopify나 Medusa로 마이그레이션하는 것이 적합합니다)
  • 월 방문자가 1만 명 미만이고 성능이 비즈니스에 중요하지 않은 경우

그 외의 경우 — 특히 마케팅 사이트, SaaS 랜딩 페이지, 콘텐츠 플랫폼, 또는 성능과 개발자 경험이 중요한 모든 프로젝트 — 2026년에는 Next.js가 명확한 승자입니다.

자주 묻는 질문

WordPress에서 Next.js로 마이그레이션하는 데 얼마나 걸리나요? 일반적인 소개 사이트(1030페이지)는 36주가 소요됩니다. 수백 개의 포스트가 있는 콘텐츠 중심 사이트는 6~12주가 걸립니다. 소요 기간은 페이지 수보다 콘텐츠 복잡도와 커스텀 기능에 따라 결정됩니다.

Google 검색 순위를 잃게 되나요? 리다이렉트와 SEO 마이그레이션을 제대로 처리하면 그렇지 않습니다. Google이 재크롤링하고 재색인하는 동안 13주간의 짧은 변동이 있을 수 있습니다. 대부분의 사이트는 Core Web Vitals 개선 덕분에 48주 안에 오히려 순위가 향상됩니다.

비개발자도 콘텐츠를 편집할 수 있나요? 네. Sanity, Payload, Strapi 같은 헤드리스 CMS는 시각적 편집 환경을 제공합니다. 일부는 실시간 미리보기 기능도 지원해 편집자가 변경 사항을 즉시 확인할 수 있습니다.

Next.js 사이트 호스팅 비용은 얼마인가요? Vercel의 무료 플랜으로 대부분의 사이트를 커버할 수 있습니다. Pro 플랜(월 약 2만 8천 원)은 커스텀 도메인과 분석 기능이 필요한 상업용 프로젝트에 적합합니다. 매니지드 WordPress 호스팅의 월 3만~20만 원과 비교해보세요.

React를 배워야 하나요? 개발자라면 네 — React는 Next.js의 기반입니다. 콘텐츠 편집자나 마케터라면 그럴 필요가 없습니다. CMS가 여러분의 워크플로우를 처리하며, 기반 프레임워크는 보이지 않는 곳에서 작동합니다.

이커머스는 어떻게 하나요? 간단한 쇼핑몰은 Shopify와 Next.js 스토어프론트(Storefront API 활용) 조합이 탁월합니다. 복잡한 B2B 커머스는 Next.js와 Medusa.js 또는 Saleor를 조합하면 완전한 제어권을 가질 수 있습니다. WooCommerce에서 Next.js로의 마이그레이션은 기술적으로 가능하지만, 전용 커머스 플랫폼으로 이전하는 것이 훨씬 효율적입니다.

WordPress를 백엔드로 계속 사용할 수 있나요? 네. 헤드리스 WordPress(WPGraphQL 또는 REST API 활용)를 사용하면 WordPress 에디터를 유지하면서 프론트엔드를 Next.js로 제공할 수 있습니다. 좋은 과도기적 접근 방식이지만, WordPress 유지 관리 부담은 여전히 남습니다.

WordPress 멀티사이트는 어떻게 되나요? 멀티 테넌트 아키텍처는 미들웨어를 활용한 도메인 라우팅으로 Next.js에서 잘 작동합니다. 각 사이트가 컴포넌트를 공유하면서 별도의 콘텐츠와 설정을 유지할 수 있습니다. WordPress 멀티사이트보다 훨씬 깔끔하고 관리도 쉽습니다.