MODX 사용자가 2026년에 Next.js로 마이그레이션해야 하는 이유: 솔직한 분석
MODX 사용자들이 2026년에 Next.js로 마이그레이션해야 하는 이유: 솔직한 평가
Evolution 시절부터 MODX로 사이트를 구축해왔습니다. 저는 커스텀 스니펫을 작성했고, TV(템플릿 변수, 텔레비전이 아닙니다)와 씨름했으며, 수많은 CMS 논쟁에서 MODX를 옹호했습니다. 따라서 이것이 비판적인 글이 아니라는 것을 믿으실 수 있습니다. 이것은 이 플랫폼을 정말 사랑했던 사람으로부터의 깨우침의 메시지입니다.
하지만 현실은 이렇습니다: 웹 개발 세계는 진화했고, MODX는 따라가지 못했습니다. 커뮤니티는 축소되고 있고, 릴리스 사이클은 극도로 느려졌으며, 인재 풀은 7월의 웅덩이처럼 빠르게 말라가고 있습니다. 2026년에 여전히 MODX에서 프로덕션 사이트를 운영하고 있다면, 출구 전략을 심각하게 고려해야 합니다. 그리고 대부분의 팀에게 그 출구는 Next.js로 향합니다.
이유를 단계별로 설명해드리겠습니다. 과장 없이, 솔직하게요.
목차
- 2026년 MODX의 현황
- MODX가 올바르게 한 것들(그리고 여전히 하는 것들)
- 더 이상 무시할 수 없는 문제들
- Next.js가 자연스러운 마이그레이션 목표인 이유
- 마이그레이션 경로: MODX에서 Next.js로
- MODX를 대체할 헤드리스 CMS 선택
- 실제 성능 향상: 전후 비교
- 당신이 놓칠 것들(그리고 놓치지 않을 것들)
- 비용 비교: MODX vs Next.js 운영
- FAQ
2026년 MODX의 현황
숫자를 솔직하게 살펴봅시다. MODX 3.x는 이미 출시된 지 한동안 됐지만, 채택률은 미지근합니다. MODX 포럼은 한때 활발했지만, 이제는 일주일에 겨우 몇 개의 게시물만 올라옵니다. 공식 GitHub 저장소는 점점 더 희소한 커밋 활동을 보여줍니다. 2018년이나 2019년과 비교해보면 커뮤니티가 여전히 힘껏 밀어붙이던 시절과는 다릅니다.
2026년 초 BuiltWith 데이터는 MODX가 약 0.3%의 CMS 감지 웹사이트를 지원한다고 추정합니다. 이는 2021년의 약 0.7%에서 감소한 것입니다. WordPress는 여전히 약 62%로 지배적이며, Next.js 기반 사이트(종종 헤드리스 CMS와 쌍을 이룸)는 연 약 40%씩 성장하고 있습니다.
MODX 마켓플레이스(이전 Extras 저장소)는 몇 개월 동안 의미 있는 새로운 확장 기능을 보지 못했습니다. 많은 인기 있는 확장 기능들은 유지보수되지 않거나 MODX 3.x와만 부분적으로 호환됩니다. 에코시스템이 생산을 중단하면, 그것은 경고 신호가 아닙니다. 항복 신호입니다.
MODX가 죽었다는 것은 아닙니다. 여전히 작동합니다. 당신의 사이트는 여전히 실행됩니다. 하지만 "여전히 작동한다"는 것은 웹 개발에서 위험한 위치입니다.
MODX가 올바르게 한 것들(그리고 여전히 하는 것들)
비판하기 전에 공정하게 말하자면, MODX는 대부분의 CMS가 여전히 잘못하고 있는 여러 가지를 올바르게 했습니다:
진정한 콘텐츠 유연성
MODX는 절대 "포스트와 페이지" 패러다임을 강요하지 않았습니다. 템플릿 변수, 청크, 그리고 스니펫은 "구조화된 콘텐츠"가 유행어가 되기 수년 전에 진정한 콘텐츠 모델링 자유도를 제공했습니다. 당신은 무엇이든 만들 수 있었습니다.
깨끗한 출력
MODX는 자신의 마크업을 주입하지 않았습니다. 신비로운 CSS 클래스도, 요청하지 않은 래퍼 div도 없었습니다. 당신의 HTML은 당신의 HTML이었습니다. 공예를 신경 쓰는 프론트엔드 개발자들에게 이는 혁명이었습니다.
개발자 친화적인 테마 지정
배워야 할 테마 시스템도, 기억해야 할 템플릿 계층 구조도 없었습니다. 당신은 템플릿을 작성했습니다. 그게 전부였습니다. 청크는 재사용 가능한 부분이었습니다. 스니펫은 PHP 로직이었습니다. 간단한 정신 모델, 강력한 결과.
태그 문법
[[*pagetitle]] 및 [[!MySnippet]]에 대해 뭐라고 해도, 한번 배우면 복잡한 페이지를 빠르게 구축할 수 있었습니다. ! 캐시되지 않은 플래그가 있는 캐싱 계층은 우아했습니다.
이러한 강점들은 실제로 MODX 개발자들을 현대적인 헤드리스 아키텍처의 훌륭한 후보자로 만듭니다. 이미 구조화된 콘텐츠와 컴포넌트 기반 템플릿을 생각한다면, 당신은 이미 Next.js의 절반을 완성한 것입니다.
더 이상 무시할 수 없는 문제들
여기서 저는 솔직해야 합니다.
보안 우려
MODX 3.x는 많은 역사적 취약점을 해결했지만, 공개 관리 패널을 가진 PHP 모놀리식을 실행하는 것 자체가 내재된 위험 벡터입니다. 2025년에 MODX 설치에 영향을 미치는 최소 두 가지 중요한 CVE가 있었으며, 패치는 몇 주가 소요되었습니다. 축소되는 보안 팀의 경우, 대응 시간은 개선되지 않고 있습니다.
Vercel이나 Netlify에 배포된 Next.js 사이트와 비교해보면, 공격할 서버가 문자 그대로 없습니다. 무차별 공격을 할 관리 패널도 없고, 악용할 PHP도 없습니다. 공격 표면은 근본적으로 더 작습니다.
인재 위기
2026년에 MODX 개발자를 채용해 보세요. 시작해보세요. 구인 공고를 올리고 침묵을 기다리세요. 개발자 풀은 React, Next.js 및 현대적인 JavaScript 프레임워크로 마이그레이션했습니다. PHP 인재도 MODX가 아닌 Laravel로 가고 있습니다.
이것은 이론적인 우려가 아닙니다. 저는 유지보수할 개발자를 문자 그대로 찾을 수 없는 MODX 사이트를 가진 에이전시와 이야기했습니다. 원래 개발자가 떠나면 사이트는 부채가 됩니다.
PHP 8.x 호환성 골치
MODX 3.x는 PHP 8에서 실행되지만 많은 확장 기능은 그렇지 않습니다. 사이트가 타사 스니펫이나 플러그인에 의존한다면, PHP 업그레이드는 종종 문제가 됩니다. 결국 구버전 PHP에 고정되어 보안 문제로 다시 돌아갑니다.
최신 개발자 경험 부재
핫 모듈 리로딩도 없고, 컴포넌트 기반 아키텍처도 없고, TypeScript 지원도 없고, 내장된 이미지 최적화도 없고, 에지 렌더링도 없고, ISR도 없습니다. 계속할 수도 있습니다.
MODX의 개발 워크플로우는 본질적으로: 관리자(또는 동기화 도구를 통해 IDE에서)에서 파일이나 청크를 편집하고, 캐시를 지우고, 브라우저를 새로 고칩니다. 그것은 작동하지만, 최신 DX와 비교하면 느립니다.
성능 한계
MODX는 빠를 수 있습니다. 저는 그것으로 2초 미만의 사이트를 구축했습니다. 하지만 그곳에 도달하려면 상당한 최적화가 필요합니다: 전체 페이지 캐싱, CDN 설정, 데이터베이스 튜닝 및 신중한 스니펫 아키텍처. Next.js는 정적 생성을 통해 본질적으로 즉시 1초 미만의 성능을 제공합니다. MODX에서는 성능을 위해 싸우고 있고, Next.js에서는 그것을 망치기 위해 싸우고 있습니다.
Next.js가 자연스러운 마이그레이션 목표인 이유
당신이 물을 수 있습니다: WordPress는 안 되나요? Astro는? 정적 사이트 생성기는?
모두 타당한 옵션이지만, Next.js는 대부분의 MODX 마이그레이션에서 최적의 지점을 맞춥니다. 이유는 다음과 같습니다:
렌더링 유연성이 MODX 사고를 반영합니다
MODX 개발자들은 이미 다른 페이지가 다른 캐싱 전략이 필요하다는 것을 이해합니다. MODX에서는 스니펫을 캐시되거나 캐시되지 않은 것으로 표시합니다. Next.js에서는 페이지당 SSG(정적 사이트 생성), ISR(증분 정적 재생성) 및 SSR(서버 사이드 렌더링) 중에서 선택합니다. 같은 개념, 더 나은 실행.
컴포넌트 아키텍처가 청크를 대체합니다
MODX 청크는 재사용 가능한 HTML 부분입니다. React 컴포넌트는 내장된 로직이 있는 재사용 가능한 UI 부분입니다. [[!$header]] 및 [[!$footer]]처럼 청크를 작성했다면, 당신은 이미 컴포넌트를 생각합니다. 당신은 단지 props를 가지지 못했을 뿐입니다.
API 라우트가 스니펫을 대체합니다
MODX 스니펫은 서버 측 로직을 처리합니다. 폼 처리, API 호출, 커스텀 쿼리. Next.js API 라우트(또는 Next.js 14+의 Server Actions)는 같은 것을 하지만 더 나은 도구 및 테스트 지원으로 JavaScript/TypeScript에서 합니다.
대안을 고려하는 팀의 경우, Astro는 많은 상호작용이 필요하지 않은 콘텐츠가 많은 사이트에 대해 평가할 가치가 있습니다. 하지만 동적 기능, 인증된 경험 또는 복잡한 데이터 가져오기가 필요하면 Next.js가 더 강력한 선택입니다.
마이그레이션 경로: MODX에서 Next.js로
실질적인 부분으로 들어가봅시다. MODX에서 Next.js로의 마이그레이션이 실제로 어떻게 작동하는지입니다.
1단계: 콘텐츠 모델 감사
모든 MODX 템플릿, 템플릿 변수 및 리소스 유형을 매핑합니다. 이것은 당신이 선택한 헤드리스 CMS의 콘텐츠 모델이 됩니다. 모든 것을 문서화합니다:
## 리소스: 블로그 포스트
- pagetitle → title (텍스트)
- longtitle → seo_title (텍스트)
- content → body (리치 텍스트)
- TV: hero_image → hero_image (미디어)
- TV: author → author (참조)
- TV: category → category (분류)
2단계: 콘텐츠 내보내기
MODX는 좋은 내보내기 도구가 없습니다. 아마 modx_site_content 및 TV 테이블을 쿼리하는 커스텀 스니펫 또는 스크립트를 작성한 다음 JSON을 출력해야 할 것입니다:
<?php
// 빠르고 간단한 MODX 콘텐츠 내보내기
$resources = $modx->getCollection('modResource', [
'published' => 1,
'deleted' => 0
]);
$output = [];
foreach ($resources as $resource) {
$output[] = [
'id' => $resource->get('id'),
'title' => $resource->get('pagetitle'),
'slug' => $resource->get('alias'),
'content' => $resource->get('content'),
'template' => $resource->get('template'),
'tvs' => $resource->getTemplateVars(),
'parent' => $resource->get('parent'),
'publishedon' => $resource->get('publishedon'),
];
}
header('Content-Type: application/json');
echo json_encode($output, JSON_PRETTY_PRINT);
그런 다음 대상 CMS의 가져오기 스크립트를 작성합니다. 화려하지는 않지만, 일회성 작업입니다.
3단계: Next.js 프론트엔드 구축
create-next-app으로 시작하고 템플릿을 페이지 컴포넌트로 구축합니다. MODX 템플릿 → 페이지 레이아웃 매핑은 다음과 같을 수 있습니다:
| MODX 개념 | Next.js 동등물 |
|---|---|
| 템플릿 | 레이아웃 컴포넌트 |
| 청크 | React 컴포넌트 |
| 스니펫 | Server Action / API 라우트 |
| 템플릿 변수 | CMS 필드 |
| 리소스 | 페이지 / 콘텐츠 항목 |
[[*field]] 태그 |
Props / 데이터 가져오기 |
| 플러그인 (이벤트 훅) | 미들웨어 |
[[!uncached]] |
SSR / 동적 렌더링 |
[[cached]] |
SSG / ISR |
4단계: URL 리디렉션 처리
여기서 사람들이 실수합니다. 모든 이전 MODX URL은 새로운 Next.js 동등물로 301 리디렉션이 필요합니다. 리디렉션 맵을 구축하고 next.config.js에 추가합니다:
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-modx-path.html',
destination: '/new-path',
permanent: true,
},
// ... 수백 개 더, 내보내기로부터 생성됨
]
},
}
이것을 건너뛰지 마세요. SEO가 달려 있습니다.
5단계: 2~4주 동안 병렬 실행
Next.js를 기존 MODX 사이트와 함께 배포합니다. 모든 것을 테스트합니다. 분석을 확인합니다. 폼이 작동하는지 확인합니다. 그런 다음 DNS를 뒤집습니다.
MODX를 대체할 헤드리스 CMS 선택
Next.js는 당신의 프론트엔드이지만, 여전히 콘텐츠를 관리할 곳이 필요합니다. 다음은 MODX 난민을 위해 인기 있는 옵션들을 비교한 것입니다:
| CMS | MODX 개발자를 위한 학습 곡선 | 콘텐츠 모델링 | 가격 (2026) | 자체 호스팅 옵션 |
|---|---|---|---|---|
| Sanity | 중간 | 우수 (코드 정의 스키마) | 무료 계층, 그 다음 $15/사용자/월 | 아니요 (클라우드 전용) |
| Strapi | 낮음 | 좋음 (UI 기반) | 무료 (자체 호스팅), 클라우드 $29/월부터 | 예 |
| Contentful | 중간 | 좋음 | 무료 계층, 그 다음 $300/월 | 아니요 |
| Payload CMS | 낮음 | 우수 (코드 정의) | 무료 (자체 호스팅), 클라우드 $50/월부터 | 예 |
| Directus | 낮음 | 유연함 | 무료 (자체 호스팅), 클라우드 $99/월부터 | 예 |
MODX의 유연성과 자체 호스팅 기능을 사랑했다면, Payload CMS나 Strapi가 가장 친숙할 것입니다. 최고의 개발자 경험을 원하고 클라우드 전용이라는 것이 괜찮다면, Sanity는 이기기 어렵습니다.
우리는 우리의 헤드리스 CMS 개발 관행을 통해 이 모든 것들과 광범위하게 작업했으며, 올바른 선택은 정말로 당신의 팀의 편안함 수준과 예산에 달려 있습니다.
실제 성능 향상: 전후 비교
저는 2025년 말에 중간 규모 MODX 사이트(약 400개 페이지, 블로그 + 서비스 + 포트폴리오)를 Sanity가 있는 Next.js로 마이그레이션했습니다. 다음은 실제 숫자입니다:
| 지표 | MODX (최적화됨) | Vercel의 Next.js | 개선 |
|---|---|---|---|
| Lighthouse 성능 | 72 | 98 | +36% |
| 최대 콘텐츠풀 페인트 | 2.8초 | 0.9초 | -68% |
| 첫 바이트까지의 시간 | 680ms | 45ms | -93% |
| 코어 웹 바이탈 통과 | 부분 | 완전 통과 | ✅ |
| 빌드/배포 시간 | 수동 FTP | 42초 자동 배포 | 밤과 낮 |
| 월간 호스팅 비용 | $45/월 (VPS) | $0 (Vercel 무료 계층) | -100% |
TTFB 개선만 해도 어마어마합니다. MODX는 PHP를 부팅하고, MySQL에 연결하고, 스니펫을 실행하고, 청크를 조립하고, 응답을 제공해야 합니다. 캐싱이 있더라도 말입니다. 정적으로 생성된 Next.js 페이지는 밀리초 단위로 CDN 에지 노드에서 제공됩니다.
당신이 놓칠 것들(그리고 놓치지 않을 것들)
놓칠 것들
- 관리자 UI: MODX의 관리 패널은 콘텐츠 편집자에게 진정으로 직관적입니다. 대부분의 헤드리스 CMS 관리 패널은 학습 곡선이 있습니다.
- 상황에 맞는 편집: 렌더링된 곳에서 콘텐츠를 편집합니다. 대부분의 헤드리스 설정은 CMS와 미리보기 사이를 전환해야 합니다. (Sanity의 Presentation 도구와 Payload의 Live Preview가 이 격차를 좁히고 있습니다.)
- 단순성: 하나의 서버, 하나의 데이터베이스, 하나의 코드베이스. 그것에는 아름다움이 있습니다. 헤드리스 스택은 더 많은 움직이는 부분이 있습니다.
- 커뮤니티 분위기: MODX 커뮤니티는 작지만 밀접하고 진정으로 도움이 됩니다.
놓치지 않을 것들
- 캐시 지우기: 끝없는 캐시 지우기-새로고침 사이클.
- TV 관리: 모든 필드에 대해 UI를 통해 템플릿 변수를 만들고 관리합니다.
- 데이터베이스 불안감: 트래픽 증가로 MySQL 연결이 최대치에 도달할 때의 그 침침한 느낌.
- FTP 배포: 또는 변경 사항을 푸시하기 위해 사용한 모든 수동 프로세스.
- 플러그인 이벤트 디버깅: 어떤 플러그인이 언제 어느 순서로 실행되었는지 파악하려고 시도합니다.
비용 비교: MODX vs Next.js 운영
총 소유 비용에 대해 솔직하게 이야기합시다. 단순히 호스팅만이 아닙니다.
| 비용 범주 | MODX (연간) | Next.js + 헤드리스 CMS (연간) |
|---|---|---|
| 호스팅 | $540-$1,200 (VPS/공유) | $0-$240 (Vercel/Netlify) |
| CMS 라이선스 | $0 (오픈 소스) | $0-$3,600 (CMS에 따라 다름) |
| SSL 인증서 | $0-$100 | $0 (포함됨) |
| CDN | $0-$600 | $0 (포함됨) |
| 보안 모니터링 | $200-$500 | 최소 (서버 없음) |
| 서버 유지보수 | $500-$2,000 (시간 또는 외주) | $0 |
| 개발자 시간당 요율 | $75-$120 (희소 인재) | $100-$175 (풍부한 인재) |
| 총 (개발 시간 제외) | $1,240-$4,400 | $0-$3,840 |
와일드카드는 개발자 요율입니다. MODX 개발자는 시간당 더 저렴합니다. 찾을 수 있다면. 하지만 희소성은 시간이 지나면서 요율을 올립니다. 그리고 당신은 종종 최고의 적합자가 아닌 이용 가능한 모든 사람과 함께 갇히게 됩니다.
당신의 특정 상황에 대한 마이그레이션 비용을 평가 중이라면, 우리는 가격 접근 방식에 대해 상세히 설명합니다. 우리는 이러한 프로젝트가 실제로 비용이 얼마나 되는지에 대해 투명합니다.
FAQ
일반적인 MODX에서 Next.js로의 마이그레이션은 얼마나 오래 걸립니까?
100-500개 페이지가 있는 사이트의 경우, 전담 팀과 함께 610주를 예상하세요. 콘텐츠 모델링 및 마이그레이션은 약 2주, Next.js 프론트엔드 구축은 35주, QA/테스트/리디렉션이 나머지를 채웁니다. 복잡한 커스텀 스니펫이나 무거운 전자상거래 통합이 있는 더 큰 사이트는 12~16주가 걸릴 수 있습니다. 가장 큰 변수는 얼마나 많은 커스텀 PHP 로직을 다시 작성해야 하는지입니다.
MODX 관리 패널을 유지하고 프론트엔드에만 Next.js를 사용할 수 있습니까?
기술적으로 예입니다. MODX에서 REST API 계층을 구축하고 Next.js로 소비할 수 있습니다. 하지만 이것은 양쪽의 최악을 제공합니다: 여전히 PHP 서버, MySQL 데이터베이스 및 모든 보안 우려를 유지하면서 별도의 프론트엔드도 유지합니다. 매우 구체적인 이유가 없는 한, 콘텐츠를 목적으로 구축된 헤드리스 CMS로 마이그레이션하는 것이 낫습니다.
마이그레이션 중에 SEO 순위를 잃게 될까요?
아니요, 리디렉션을 올바르게 처리하면 됩니다. 중요한 단계는: 가능한 경우 동일한 URL 구조 유지, URL이 변경되는 경우 301 리디렉션 설정, 메타데이터 유지, 배포 후 업데이트된 사이트맵을 Google Search Console에 제출입니다. 우리가 마이그레이션한 대부분의 사이트는 더 나은 Core Web Vitals 점수로 인해 4~8주 내에 순위 개선을 봅니다.
FormIt 폼과 복잡한 워크플로우가 있는 MODX 사이트는 어떻게 됩니까?
폼은 마이그레이션의 더 까다로운 부분 중 하나입니다. FormIt는 유효성 검사, 이메일 전송, 훅 및 스팸 방지를 모두 하나의 패키지로 처리했습니다. Next.js에서는 일반적으로 처리를 위한 Server Actions, 유효성 검사를 위한 Zod, 이메일 배달을 위한 Resend 또는 SendGrid 같은 서비스를 결합합니다. 그것은 더 명시적이지만 더 테스트 가능하고 신뢰할 수 있습니다.
간단한 브로셔 사이트에는 Next.js가 과한가요?
어쩌면요. MODX 사이트가 문자 그대로 정적 페이지 10개와 연락처 폼뿐이라면, Astro가 더 나은 적합자일 수 있습니다. 기본적으로 JavaScript가 없으며 설정이 더 간단합니다. 하지만 나중에 동적 기능, 인증 또는 복잡한 데이터 가져오기가 필요할 가능성이 있다면, Next.js로 시작하면 또 다른 마이그레이션을 피할 수 있습니다.
MODX 확장 기능과 커스텀 스니펫은 어떻게 됩니까?
다시 구축해야 합니다. 자동 변환이 없습니다. 커스텀 스니펫은 Next.js의 API 라우트 또는 서버 작업이 됩니다. Gallery, Articles 또는 MIGX 같은 확장 기능은 헤드리스 CMS의 기본 기능(보통 더 나음)으로 교체됩니다. Foxy나 SimpleCart 같은 전자상거래 확장은 Shopify의 Storefront API, Snipcart 또는 Medusa로 교체될 것입니다. 마이그레이션 타임라인에서 이 작업을 명시적으로 계획하세요.
비기술 이해관계자에게 이 마이그레이션을 승인하도록 설득하려면 어떻게 해야 합니까?
그들이 신경 쓰는 세 가지에 초점을 맞추세요: 위험, 비용 및 결과. 위험: MODX의 축소되는 커뮤니티는 긴급 상황에 개발자를 찾기가 매년 더 어려워진다는 뜻입니다. 비용: 서버 유지보수와 보안 패칭이 무료가 아니며, CMS 라이선스가 무료라도 마찬가지입니다. 결과: Core Web Vitals 비교를 보여주고 Google이 페이지 속도를 순위 매기기 요소로 사용하는 방법을 설명합니다. 경쟁사가 1초 미만으로 로드되고 그들의 경쟁사가 3초라면, 그것은 비즈니스 문제입니다.
증분으로 마이그레이션할 수 있습니까, 아니면 한 번에 해야 합니까?
증분 마이그레이션은 역방향 프록시 설정을 사용하여 가능합니다. 새로운 페이지를 Next.js에서 제공하고 레거시 페이지를 MODX 서버로 라우팅합니다. nginx 구성으로 특정 경로가 이전 서버에 프록시되는 동안 다른 모든 것이 새로운 Next.js 배포로 가도록 우리는 이 작업을 했습니다. 복잡성을 추가하지만, 수백 개의 페이지가 있는 사이트의 경우, 위험한 대규모 전환을 하기보다는 몇 주 또는 몇 개월 동안 단계적으로 마이그레이션할 수 있습니다.
MODX 사이트에 앉아 있고 제가 설명한 문제점을 느낀다면, 계획을 시작하기에 최선의 시간은 지금입니다. 하늘이 무너지고 있어서가 아니라 압력 속에서 수행되는 마이그레이션(보안 침해 후, 개발자가 그만둔 후, PHP 버전이 생명 종료에 도달한 후)이 계획된 것보다 항상 더 비싸고 스트레스가 많기 때문입니다. 연락주세요 특정 상황에 대해 이야기하고 싶으시다면. 우리는 이것을 충분히 많이 거쳤기 때문에 지뢰가 어디 있는지 알고 있습니다.