Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — "더 이상 CMS는 단일 카테고리가 아니다"

2010년대 초반 "CMS"라는 단어는 사실상 WordPress 하나를 의미했습니다. 2026년 현재, CMS는 적어도 다섯 가지 다른 카테고리로 분화되어 있습니다.

1. **전통적 CMS (Traditional / Monolithic)** — 콘텐츠 + 프레젠테이션이 한 덩어리. WordPress, Drupal, Joomla.

2. **헤드리스 CMS (Headless)** — 콘텐츠는 API로만 제공, 프런트는 자유. Strapi, Directus, Contentful.

3. **하이브리드 / 비주얼 CMS** — 비주얼 에디터 + 헤드리스 API. Storyblok, Builder.io, Plasmic.

4. **git-backed CMS** — 콘텐츠가 마크다운 파일로 저장되어 리포지토리에 커밋. TinaCMS, Decap CMS, Outstatic.

5. **마크다운 + 코드 기반 CMS** — 사실상 코드와 동일한 워크플로. Contentlayer, Velite, Astro Content Collections, Nuxt Content.

이 글에서는 2026년 5월 기준 오픈소스 진영의 헤드리스 CMS 12개 후보를 정리하고, 관리형(SaaS) 진영의 Sanity · Contentful · Hygraph · Storyblok · DatoCMS · ButterCMS · microCMS · Newt를 비교 축으로 가져온 뒤, 마지막으로 "마케팅 사이트 / 문서 / 이커머스 / 모바일 앱"이라는 네 가지 도메인에 대해 의사결정 매트릭스를 제시합니다.

핵심 결론을 먼저 던지자면 — **2026년에는 "단일 CMS로 모든 것을 다루는" 시대가 끝났습니다.** 팀 사이즈, 데이터 모델 복잡도, 콘텐츠 편집자 수, 셀프 호스팅 여부에 따라 선택지가 다섯 갈래로 갈라집니다.

1. 헤드리스 vs 전통적 CMS — 무엇이 다른가

전통적 CMS와 헤드리스 CMS의 본질적 차이는 단순합니다.

| 축 | 전통적 CMS (WordPress, Drupal) | 헤드리스 CMS (Strapi, Sanity) |

| --- | --- | --- |

| 콘텐츠 + 표현 | 한 시스템에서 모두 처리 | 분리. CMS는 API만 제공 |

| 프런트 자유도 | 테마 시스템에 종속 | 어떤 프레임워크든 가능 |

| 멀티 채널 | 기본 웹만, 모바일은 별도 | 동일 데이터로 웹/앱/디지털 사이니지 |

| SEO | 서버 렌더링 기본 제공 | SSG/SSR을 직접 구성 |

| 학습 곡선 | 비개발자에게 친숙 | 개발자 친화적 |

| 성능 | 플러그인 누적 시 무거움 | API 기반이라 가볍게 시작 |

2026년 시점의 트렌드는 명확합니다.

- **WordPress는 여전히 전 세계 웹의 약 43%를 차지**합니다. W3Techs의 CMS 점유율 데이터는 거의 변함이 없습니다.

- 그러나 **새로 시작하는 마케팅/제품 사이트의 70% 이상이 헤드리스 또는 git-backed**를 선택합니다.

- 헤드리스 시장 자체는 2022년 대비 약 3배 성장했고, 2026년에도 두 자릿수 성장 중입니다.

핵심은 "WordPress가 죽었다"가 아니라 **새로운 프로젝트의 디폴트가 바뀌었다**는 점입니다. 그리고 WordPress조차도 WP-API + Faust.js + ACF 조합으로 **부분적으로 헤드리스화**되는 흐름이 있습니다.

2. Strapi 5 — Node.js 헤드리스의 사실상 표준

Strapi는 **Node.js 기반 오픈소스 헤드리스 CMS의 사실상 표준**입니다. GitHub 스타 65k 이상, 다운로드 누적 1억 회 이상. 2024년 말 출시된 Strapi 5는 **Document 기반 콘텐츠 모델**로 패러다임을 한 차례 갈아탔습니다.

핵심 개념

- **Content-Type Builder** — 어드민 UI에서 데이터 모델 정의. 마이그레이션 자동 생성.

- **Document 모델 (v5)** — 각 콘텐츠가 Document, 그 안에 여러 언어/버전 Locale을 가짐.

- **Draft & Publish** — 초안과 발행본을 분리, 작업자 워크플로 지원.

- **Plugins** — 인증, i18n, 미디어 라이브러리, GraphQL 등이 플러그인 시스템으로 확장.

강점

- 자체 호스팅이 무료 (MIT 라이선스의 Community Edition).

- REST + GraphQL 동시 제공.

- TypeScript 우선 — v5에서 타입 안전성 대폭 강화.

- 풍부한 플러그인 마켓플레이스.

- 한국어 · 일본어 등 i18n 지원이 견고.

약점

- 자체 호스팅 시 운영 부담 — 데이터베이스, Redis, 미디어 스토리지 직접 관리.

- 대규모 콘텐츠 (수십만 건 이상)에서 어드민 UI가 느려지는 사례.

- Enterprise 기능 (SSO, RBAC 세분화) 일부는 유료.

Strapi Cloud

2023년 출시된 관리형 옵션. **인프라 운영을 원하지 않는 팀**을 위한 유료 SaaS. 자체 호스팅 옵션이 늘 함께 존재한다는 점이 Contentful · Sanity와의 본질적 차이입니다.

언제 선택할까

- Node.js / TypeScript 스택을 선호하는 팀.

- 자체 호스팅을 원하면서도 어드민 UI를 갖춘 CMS가 필요한 경우.

- 마케팅 사이트 + 다국어 + 미디어가 섞인 중간 규모 프로젝트.

3. Directus 11 — "어떤 SQL DB든 즉시 API화"

Directus는 다른 헤드리스 CMS와 출발점이 다릅니다. **콘텐츠를 위한 별도 데이터베이스를 가지지 않습니다**. 기존 PostgreSQL · MySQL · SQLite 위에 어드민 UI와 자동 생성된 REST/GraphQL API를 얹는 구조입니다.

핵심 개념

- **Instant API** — DB 스키마를 읽어 REST + GraphQL을 자동 생성.

- **Schema-on-DB** — 어드민에서 만든 컬렉션이 곧 실제 DB 테이블.

- **Flows** — 노코드 자동화. 데이터 변경 시 Slack/Webhook/이메일 등 트리거.

- **Insights** — 어드민 안에서 대시보드 작성.

- **Files** — S3/GCS/Cloudflare R2 등 다양한 스토리지 지원.

강점

- **데이터 주권** — DB가 사용자 소유 인프라에 그대로 남음.

- **레거시 DB 재활용** — 이미 존재하는 ERP/내부 시스템 DB 위에 어드민을 얹을 수 있음.

- BSL → MIT (2024년 라이선스 단순화).

- 사용자 한도 없는 자체 호스팅 무료 옵션.

약점

- "Headless CMS" 카테고리 안에서는 약간 다른 종(種). 콘텐츠 워크플로(Draft/Publish, 검토)는 Strapi 대비 단순.

- 미디어 라이브러리는 기본 기능이지만 고도화된 자산 관리(DAM)는 별도.

Directus Cloud

관리형 옵션이 존재. **셀프 호스팅 0원 vs Cloud** 둘 다 정식 제품으로 운영됩니다.

언제 선택할까

- 이미 PostgreSQL/MySQL 같은 SQL DB가 핵심 인프라인 조직.

- 사내 백오피스 + 외부 API를 한 시스템에서 처리하고 싶은 팀.

- "데이터는 우리 인프라에 머물러야 한다"는 컴플라이언스 요구가 있는 환경.

4. Payload 3 — Next.js 네이티브 풀스택 CMS

Payload는 **TypeScript 풀스택**을 표방하는 신세대 헤드리스 CMS입니다. 2024년 11월 정식 출시된 Payload 3는 결정적인 한 수를 두었습니다 — **Next.js App Router 내부에서 직접 실행됩니다**. 별도 서버 프로세스 없이 Next.js 앱과 한 코드베이스에 어드민 UI와 API가 함께 살아갑니다.

핵심 개념

- **Code-first Schema** — 콘텐츠 모델을 TypeScript 코드로 정의. UI에서 정의 후 코드 export하는 방식이 아님.

- **Local API** — DB를 거치지 않고 함수 호출로 직접 데이터 접근. SSR/SSG에서 매우 빠름.

- **Access Control** — 함수형 권한 정책. 행 단위, 필드 단위 제어.

- **Lexical Rich Text** — Meta의 Lexical 에디터 채택.

- **Drafts & Versions** — 모든 컬렉션에 버전 관리 기본 지원.

강점

- **MIT 라이선스** + 사용자 한도 없음 + 자체 호스팅 무료.

- **Next.js와 한 프로젝트** — 별도 배포 파이프라인 불필요.

- TypeScript 타입이 콘텐츠 모델로부터 자동 생성.

- MongoDB · PostgreSQL · SQLite 모두 지원 (Adapter 패턴).

약점

- 코드 우선이라 **비개발자가 콘텐츠 모델을 변경하기 어려움**.

- Strapi · Directus 대비 커뮤니티 규모가 아직 작음 (성장 중).

- 모바일 앱처럼 Next.js와 무관한 프런트에서는 장점이 반감.

Payload Cloud

관리형 호스팅 옵션. Vercel 친화적 배포가 디폴트.

언제 선택할까

- Next.js 풀스택 팀이 한 프로젝트 안에서 모든 것을 처리하고 싶을 때.

- TypeScript 타입 안전성을 콘텐츠까지 확장하고 싶은 팀.

- 어드민 커스텀이 깊게 필요한 프로젝트 (Payload는 React 컴포넌트로 어드민 확장이 직관적).

5. KeystoneJS 6 — GraphQL-first, Thinkmill의 선택

KeystoneJS는 호주 기반 Thinkmill이 주도하는 **GraphQL-first** 헤드리스 CMS입니다. 2022년 KeystoneJS 6 정식 출시 후 안정 궤도. 2026년에도 꾸준한 유지보수와 점진적 기능 추가가 이어지고 있습니다.

핵심 개념

- **Code-first Schema** — TypeScript로 데이터 모델 정의.

- **Prisma ORM 기반** — DB 연결 및 마이그레이션을 Prisma가 담당.

- **자동 생성 GraphQL** — 모델로부터 CRUD 쿼리/뮤테이션 자동 생성.

- **Admin UI** — React 기반 어드민, 강력한 필드 커스터마이즈.

강점

- **GraphQL이 1급 시민** — REST는 별도 구성이 필요.

- Prisma 기반이라 마이그레이션 워크플로가 견고.

- TypeScript 타입 안전성.

약점

- 커뮤니티 규모는 Strapi · Directus 대비 작음.

- 자체 호스팅 외 공식 Cloud가 없음 (Thinkmill의 사업 모델은 CMS 자체 제품화보다는 컨설팅 위주).

- GraphQL을 쓰지 않는 팀에게는 매력 반감.

언제 선택할까

- GraphQL을 적극 사용하는 프로덕트 팀.

- Prisma 기반 풀스택 일관성을 원하는 팀.

- 안정성과 단순성을 Strapi의 다양한 플러그인보다 우선시할 때.

6. Sanity — GROQ와 실시간 협업의 관리형 챔피언

Sanity는 노르웨이 기반 회사가 운영하는 **관리형(SaaS) 헤드리스 CMS**입니다. 콘텐츠 스튜디오 자체는 오픈소스(MIT)이지만, 데이터셋과 CDN은 Sanity Cloud에서 운영됩니다.

핵심 개념

- **GROQ (Graph-Relational Object Queries)** — Sanity가 만든 자체 쿼리 언어. GraphQL/SQL과 다른 그래프형 트래버스 문법.

- **Real-time Collaboration** — 콘텐츠 편집이 Google Docs급 실시간 동기화.

- **Portable Text** — JSON 기반 리치 텍스트 포맷. 헤드리스에 가장 잘 맞는 표현.

- **Studio Customization** — React 기반 스튜디오를 자유롭게 커스텀.

강점

- 실시간 협업이 가장 매끄러움.

- 콘텐츠 모델 유연성 (GROQ로 임의 트래버스).

- 무료 티어가 관대 (3 사용자, 10k 문서까지).

- Image Pipeline (자동 변환, CDN) 기본 제공.

약점

- **콘텐츠 데이터가 Sanity 인프라에 거주** — 자체 호스팅 옵션 없음.

- GROQ는 학습 필요 (GraphQL과 다름).

- 대량 사용자/문서 시 가격이 빠르게 증가.

언제 선택할까

- 콘텐츠 에디터가 다수이고 실시간 협업이 핵심.

- 자체 호스팅 운영 인력이 없거나 원하지 않는 팀.

- 콘텐츠 모델이 복잡하고 자주 변경되는 프로덕트.

7. Storyblok — Visual Editor의 강자

Storyblok은 오스트리아 기반 회사의 관리형 헤드리스 CMS. 차별화 포인트는 단 하나로 요약됩니다 — **Visual Editor가 가장 좋다**.

핵심 개념

- **Visual Editor** — 실제 프런트엔드 사이트를 어드민 안에서 미리보기하며 편집.

- **Blocks** — 재사용 가능한 콘텐츠 블록 (Hero, Feature, CTA 등).

- **Stories** — 페이지 단위. 블록 트리로 구성.

- **Field Plugins** — 어드민 필드를 커스텀 React 컴포넌트로 확장.

강점

- 마케터/콘텐츠 에디터가 페이지를 직접 조립.

- 다국어 (Spaces 단위 분리)가 견고.

- 100+ 통합 (이커머스, 분석, 자동화).

약점

- 관리형 전용 (자체 호스팅 옵션 없음).

- 가격이 사용자/스페이스 단위로 빠르게 증가.

- Visual Editor에 강하게 결합 — 프런트엔드도 그 구조를 따라가야 함.

언제 선택할까

- 마케팅 사이트가 메인 워크로드.

- 비개발자가 페이지 레이아웃을 직접 조정해야 하는 환경.

- Builder.io · Plasmic과 같은 비주얼 페이지 빌더 카테고리에서 가장 성숙.

8. TinaCMS — git-backed, 마크다운 중심

TinaCMS는 git을 백엔드로 사용하는 헤드리스 CMS입니다. 콘텐츠가 **데이터베이스가 아니라 마크다운/MDX 파일로 리포지토리에 저장**됩니다.

핵심 개념

- **git-backed** — 저장은 리포지토리에 commit. 콘텐츠 히스토리가 곧 git 히스토리.

- **Visual Editing** — Next.js · Hugo · Astro 등의 프런트엔드를 어드민에서 편집.

- **TinaCMS Cloud** — git 브랜치 워크플로를 관리해주는 관리형 옵션.

강점

- 콘텐츠가 **개발자 워크플로 안에 있음** — PR/리뷰 자연스러움.

- 정적 사이트 생성기와 궁합이 좋음 (Hugo, Astro, Next.js).

- 콘텐츠가 인프라에 락인되지 않음.

약점

- 콘텐츠 에디터가 git을 이해해야 함 (Cloud가 가려주지만).

- 대규모 콘텐츠 (수만 건)에서 빌드 속도가 병목.

- 권한 모델이 git 권한과 강하게 묶임.

언제 선택할까

- 개발자 중심 문서 사이트 (예: 기술 블로그, 제품 문서).

- 콘텐츠 변경량이 적고 히스토리가 중요한 환경.

- 마크다운/MDX 우선 워크플로.

9. Decap CMS — 옛 Netlify CMS의 후신

Decap CMS는 2022년 Netlify CMS에서 분리된 후속 프로젝트입니다. TinaCMS와 같은 카테고리(git-backed)이지만 출발이 다릅니다 — **Jamstack 초기부터의 정통 git-backed CMS**.

핵심 개념

- **git-backed** — GitHub · GitLab · Bitbucket 위에 동작.

- **단일 HTML + JS 어드민** — 정적 사이트의 `/admin` 경로에 어드민이 위치.

- **Open Authoring** — 외부 기여자가 fork → PR로 콘텐츠 기여.

강점

- 정말 가볍다 (어드민이 단일 정적 자산).

- Jamstack 사이트(Hugo, Eleventy, Jekyll)와 자연스럽게 결합.

- 비용 0원 (호스팅이 정적이라 거의 무료).

약점

- 커뮤니티가 Netlify CMS 시절보다 작음.

- 기능 발전이 다소 정체.

- 대규모 콘텐츠 / 복잡한 워크플로에는 부적합.

언제 선택할까

- 작은 정적 사이트, 개인 블로그, 오픈소스 프로젝트 문서.

- 외부 기여자를 받는 오픈소스 사이트.

- 가장 가벼운 CMS가 필요할 때.

10. Webiny · Apostrophe · Plone · Drupal — 그 외 후보들

Webiny

- 서버리스(AWS Lambda · DynamoDB · S3 · CloudFront) 위에 동작하는 오픈소스 헤드리스.

- 멀티테넌시가 강점. 대규모 SaaS 운영 사례.

- AWS 비용이 사용량과 함께 움직임.

Apostrophe

- Node.js 기반, 페이지 편집 UX가 강점.

- "In-context editing" — 사이트를 보면서 그대로 편집.

- 마케팅/홍보 사이트가 주 타깃.

Plone CMS

- 파이썬(Zope) 기반의 오래된 엔터프라이즈 CMS.

- 보안, 권한 모델, 다국어가 견고.

- 정부 · 대학 · 비영리 등에서 여전히 사용.

Drupal 10/11

- PHP 기반. 2025년 Drupal 11 출시.

- 복잡한 콘텐츠 모델, 다국어, 권한이 강점.

- JSON:API · GraphQL 모듈로 **세미 헤드리스** 운영 가능.

- 전통적 CMS와 헤드리스의 경계에 위치.

11. WordPress의 헤드리스 진영 — WP-API + Faust.js + ACF

WordPress 자체는 전통적 CMS이지만, 2026년에는 **헤드리스로 사용하는 흐름이 안정화**되었습니다.

핵심 도구

- **WP REST API** — WordPress 코어에 내장된 REST 엔드포인트.

- **WPGraphQL** — 커뮤니티 플러그인. GraphQL 엔드포인트 제공.

- **ACF (Advanced Custom Fields)** — 커스텀 필드 정의. 헤드리스에서도 핵심.

- **Faust.js** — WP Engine이 만든 Next.js 프레임워크. WordPress를 백엔드로 한 SSR/SSG.

강점

- 기존 WordPress 콘텐츠/플러그인 자산을 그대로 활용.

- 콘텐츠 에디터가 익숙한 WordPress 어드민 사용.

- 무료 + 광범위한 호스팅 옵션.

약점

- WordPress 코어의 무거움이 그대로 남음.

- 플러그인 호환성 (헤드리스에서 동작하지 않는 플러그인 다수).

- PHP 운영 부담.

언제 선택할까

- 이미 거대한 WordPress 콘텐츠 자산이 있는 미디어/출판.

- 콘텐츠 에디터들이 WordPress 외 다른 시스템 학습을 거부할 때.

- 점진적 마이그레이션 전략.

12. 관리형 헤드리스 시장 — Contentful · Hygraph · DatoCMS · ButterCMS · Cosmic

관리형(SaaS) 헤드리스 CMS는 오픈소스와 다른 게임을 합니다. **인프라 운영을 사지 않는** 것이 핵심 가치.

| 제품 | 특징 | 적합한 팀 |

| --- | --- | --- |

| Contentful | 관리형 헤드리스의 사실상 리더. 엔터프라이즈 가격. | 대기업, 글로벌 마케팅 사이트 |

| Hygraph (구 GraphCMS) | GraphQL 우선. Content Federation. | GraphQL 우선 팀 |

| DatoCMS | 이미지/미디어 파이프라인이 강점. | 디자인 무거운 사이트 |

| ButterCMS | 가장 단순한 SaaS 헤드리스. 빠른 시작. | 블로그/마케팅 위주 소규모 |

| Cosmic | 멀티테넌트 친화. 콘텐츠 API + CLI. | 빠른 프로토타입 |

신흥/중간 카테고리

- **Caisy** — 독일계 신생, 멀티 프로젝트 콘솔.

- **Prepr CMS** — 개인화 + A/B 테스트 통합.

- **Magnolia** — 엔터프라이즈 전용. 헤드리스 + 전통적 하이브리드.

- **Crystallize** — 이커머스 친화 헤드리스.

Builder.io · Plasmic — 비주얼 페이지 빌더

- **Builder.io** — 비주얼 편집기 + 헤드리스 API + A/B 테스트 + AI 페이지 생성.

- **Plasmic** — Figma → 코드 가까운 표현력. 디자이너 친화.

이 두 제품은 **"비주얼 페이지 빌더 + 헤드리스 CMS"**라는 하이브리드 카테고리에서 가장 두드러집니다. Storyblok과 직접 경쟁.

13. 일본 헤드리스 CMS — microCMS · Newt · a-blog cms

일본 시장에는 자체 헤드리스 CMS 진영이 견고하게 자리잡고 있습니다. 한국어 사용자에게도 참고가 됩니다.

microCMS

- 일본 헤드리스 CMS의 사실상 리더.

- 일본어 UI · 일본 IP 데이터센터 · 일본 기업의 EC 계약 호환성.

- 가격이 명확하고 무료 티어가 관대.

- 일본 내 대형 미디어, EC 사이트 다수 사용.

Newt

- 일본의 신세대 헤드리스 CMS. microCMS보다 더 풀스택 친화.

- Sanity 스타일의 콘텐츠 모델링 + GROQ 유사 쿼리.

- 일본 스타트업 중심으로 빠르게 성장 중.

a-blog cms

- 일본 어플리(Apple)社의 전통적 CMS. PHP 기반.

- 일본 내 기업 사이트 점유율이 높음.

- 헤드리스 모드도 지원하지만 전통적 모드가 주.

Movable Type

- 일본 식스애파트(Six Apart)가 인수해 일본 기업 사이트에서 강세.

- 정적 출력 + CMS의 원조 격.

Sanity · Contentful의 일본 진출

- Sanity는 일본 진출이 빠르고, microCMS와 직접 경쟁.

- Contentful의 일본 사용자도 꾸준히 증가.

14. 한국 시장의 CMS — 어떻게 다른가

한국 시장은 일본과 또 다른 특수성이 있습니다.

- **NAVER 카페 · 블로그** — 사실상 CMS의 역할을 일부 대체. 콘텐츠 생산자 다수가 여전히 NAVER 생태계.

- **자체 개발 CMS** — 대형 미디어/이커머스 (네이버, 카카오, 쿠팡, 우아한형제들)는 자체 CMS를 가짐.

- **Strapi · WordPress가 SMB에서 우세** — 한국어 호스팅 + 한글 입력기 호환성 측면에서 검증.

- **microCMS는 한국 진출 미미** — 일본어 인터페이스 외 한국 시장 직접 대응 부재.

- **국산 CMS 시도** — 트레저(Treasure Korea), 모두스(Modus) 등 시도가 있었으나 글로벌 진영 대비 점유율 낮음.

핵심 관찰: 한국 시장에서 오픈소스 헤드리스 CMS 도입은 **Strapi · Payload · TinaCMS** 순서로 빈도가 높고, 관리형은 **Contentful · Sanity · Storyblok**이 주로 검토 대상이 됩니다.

15. 마크다운/MDX 기반 — Contentlayer · Velite · Astro · Nuxt Content

"CMS"라는 단어를 넓게 정의하면, **마크다운 파일 + 정적 사이트 생성기**도 CMS의 한 형태입니다. 2026년에는 이 카테고리가 개발자 블로그/문서 시장의 디폴트입니다.

Contentlayer 2

- 마크다운/MDX 파일에서 타입 안전한 데이터 생성.

- Next.js와 가장 좋은 궁합.

- **2024년부터 공식 개발이 중단(paused)** — 커뮤니티 포크 (Contentlayer 2)가 유지보수 중.

Velite

- Contentlayer의 사실상 후속. 타입 안전 + 스키마 검증(Zod).

- 빌드 속도 우수.

- 2025년 이후 신규 프로젝트의 디폴트 선택.

Astro Content Collections

- Astro 프레임워크에 내장된 콘텐츠 시스템.

- 스키마 검증, 타입 생성, 자동 라우팅 모두 내장.

- 문서 사이트(Starlight)와 함께 사용.

Nuxt Content

- Nuxt(Vue) 진영의 콘텐츠 시스템.

- 마크다운 + 컴포넌트 임베드 + 검색까지 내장.

Outstatic

- Next.js 네이티브 git-backed CMS.

- TinaCMS와 유사하지만 더 가벼움.

- 개발자 블로그/포트폴리오에 적합.

MDX의 위상

- 마크다운 + JSX = MDX. 2026년 모든 주요 정적 사이트 생성기의 1급 시민.

- 코드 블록 안에 React 컴포넌트 임베드 → 인터랙티브 문서.

- 단점: 빌드 시 JSX 검증이 엄격해 콘텐츠 작성자가 실수하기 쉬움 (이 블로그의 `mdxValidation.ts` 같은 검증기가 필요해진 이유).

16. 데이터 모델 — Document vs Collection vs Block

헤드리스 CMS의 본질은 데이터 모델입니다. 2026년 시점의 표준 패턴.

Document 모델 (Sanity, Strapi 5)

- 각 콘텐츠 = 하나의 Document.

- Document 안에 임의 필드 구조.

- 다국어/버전이 Document에 부속.

Collection 모델 (Directus, Payload, KeystoneJS)

- 콘텐츠 = Collection(테이블) + Row(항목).

- SQL 친화. JOIN 자연스러움.

- 관계형 데이터 모델링이 명료.

Block 모델 (Storyblok, Builder.io)

- 콘텐츠 = Page + Block 트리.

- 비주얼 에디터 친화.

- 마케팅 사이트에 최적.

Portable Text (Sanity)

- 리치 텍스트가 JSON 트리.

- 임의 커스텀 블록 삽입 가능.

- 가장 헤드리스 친화적인 리치 텍스트 표현.

어떤 모델을 골라야 하나

- 콘텐츠가 비교적 단순 + 다국어 = Document.

- 관계형 + 백오피스 = Collection.

- 페이지 빌더 = Block.

- 임의 구조의 긴 글 = Portable Text 또는 MDX.

17. API — REST vs GraphQL vs GROQ

헤드리스 CMS는 API의 모양으로 차별화됩니다.

| API | 강점 | 약점 | 대표 제품 |

| --- | --- | --- | --- |

**2026년 디폴트는 "REST + GraphQL 동시 제공"**. 클라이언트가 둘 중 선택하게 합니다.

CDN과 캐시

헤드리스의 진짜 가치는 **API 응답이 CDN에서 캐시되는 것**. Sanity의 CDN, Contentful의 Edge Cache, Strapi Cloud의 캐시. 자체 호스팅이면 Cloudflare/Fastly로 직접 구성.

18. 이커머스 헤드리스 — Medusa · Saleor · Crystallize

CMS와 이커머스의 경계가 흐려지고 있습니다. 헤드리스 이커머스 진영을 간단히.

Medusa

- Node.js 기반 오픈소스 이커머스 백엔드.

- 헤드리스 + 모듈러 아키텍처.

- Shopify의 오픈소스 대안으로 부상.

Saleor

- Python · GraphQL 기반.

- 엔터프라이즈 친화.

- 다채널, 다국어 강함.

Crystallize

- 헤드리스 CMS + 이커머스 하이브리드.

- 콘텐츠와 상품 데이터를 동일 모델로 다룸.

Shopify의 헤드리스 진영

- **Hydrogen** + **Oxygen** — Shopify가 만든 Remix 기반 헤드리스 프레임워크.

- 콘텐츠 부분은 Sanity/Contentful과 자주 결합.

다음 글 후보

이커머스 헤드리스는 자체로 한 편의 글이 됩니다. **Medusa vs Saleor vs Hydrogen 비교 + 콘텐츠 CMS 결합 패턴**을 후속편으로 다루겠습니다.

19. 사용 사례별 추천 — 결정 매트릭스

이제 네 가지 도메인에 대해 직설적인 추천을 합니다.

마케팅 사이트

- **소규모 (1-3 페이지)**: TinaCMS 또는 Decap CMS — git-backed의 가벼움.

- **중간 (10-50 페이지, 다국어)**: Strapi 5 또는 Sanity — 콘텐츠 모델 유연성.

- **대규모 (블록 빌더, 비개발자 다수)**: Storyblok 또는 Builder.io — 비주얼 에디터.

기술 문서

- **개발자 중심 문서**: Contentlayer/Velite + MDX 또는 Astro Starlight.

- **대규모 문서 (검색, 다국어)**: TinaCMS + 자체 검색, 또는 Nextra.

- **다양한 기여자**: Decap CMS (Open Authoring).

모바일 앱 백엔드

- **단일 백엔드로 웹 + 앱 + IoT**: Strapi 5 또는 Directus.

- **TypeScript 일관성 우선**: Payload 3.

- **실시간 동기화 필요**: Sanity 또는 Firebase의 결합.

이커머스 + 콘텐츠

- **Shopify 사용자**: Hydrogen + Sanity/Contentful.

- **오픈소스**: Medusa + Strapi 또는 Payload.

- **콘텐츠와 상품 통합**: Crystallize.

사내 백오피스 + 외부 API

- **첫 선택**: Directus 11 — 기존 DB를 그대로 사용.

- **풀스택 통합**: Payload 3 — Next.js와 한 코드베이스.

20. 의사결정 체크리스트

다음 다섯 가지 질문을 순서대로 답하면 헤드리스 CMS 선택이 80% 좁혀집니다.

1. **셀프 호스팅 vs 관리형** — 인프라 운영 인력이 있는가, 데이터 주권이 필수인가?

- 셀프 호스팅: Strapi, Directus, Payload, KeystoneJS.

- 관리형: Sanity, Contentful, Storyblok, Hygraph.

2. **콘텐츠 에디터 수** — 비개발자가 일상적으로 콘텐츠를 다루는가?

- 많음: Sanity, Storyblok, Strapi.

- 적음 / 개발자만: TinaCMS, Payload, Velite.

3. **데이터 모델 복잡도** — 관계형/JOIN이 많은가, 페이지 빌더형인가?

- 관계형: Directus, KeystoneJS, Payload.

- 페이지 빌더형: Storyblok, Builder.io.

- 긴 글 중심: Sanity, Strapi.

4. **프런트엔드 스택** — Next.js에 락인되는가, 멀티 채널인가?

- Next.js 우선: Payload (Local API), Sanity, Contentlayer/Velite.

- 멀티 채널 (웹 + 앱 + 사이니지): Strapi, Sanity, Contentful.

5. **예산 / 라이선스** — 무료 자체 호스팅이 필수인가?

- 무료 필수: Strapi (CE), Directus, Payload, KeystoneJS, TinaCMS, Decap.

- 유료 가능: Sanity (Free → 유료), Contentful, Storyblok.

21. 흔히 하는 7가지 실수

1. **"WordPress는 끝났다"고 가정** — 점유율 43%는 여전히 사실. 마이그레이션 비용을 과소평가하면 안 됨.

2. **데이터 모델을 코드와 분리하지 않음** — 콘텐츠 모델이 코드 PR 흐름에 들어오지 않으면 운영 부담이 큼.

3. **셀프 호스팅의 운영 비용을 0원으로 가정** — Strapi Community라도 DB · Redis · S3 · 모니터링은 필요.

4. **GraphQL이 항상 옳다고 가정** — 캐시가 중요한 마케팅 사이트는 REST + CDN이 더 빠른 경우가 많음.

5. **이미지 파이프라인을 직접 만든다** — Sanity · Contentful · DatoCMS 같은 관리형의 image transform이 압도적으로 빠르고 싸다.

6. **Visual Editor가 만능이라고 믿음** — 디자인 시스템이 부재한 상태에서 Visual Editor를 도입하면 페이지 일관성이 깨짐.

7. **다국어를 나중에 추가** — i18n은 데이터 모델 초기 결정. 나중에 끼우면 마이그레이션이 지옥.

22. 2026년 트렌드 — AI · 협업 · Edge

마지막으로 2026년의 세 가지 큰 흐름.

AI 콘텐츠 어시스턴트

- Sanity, Contentful, Storyblok 모두 **AI 콘텐츠 생성/요약/번역**을 어드민에 통합.

- Builder.io는 **AI 페이지 생성** (프롬프트 → 페이지 트리)을 정식 기능화.

- Strapi는 플러그인 형태로 AI 워크플로 지원.

실시간 협업의 일반화

- Sanity가 시작한 실시간 협업이 Storyblok · Contentful로 확산.

- Strapi · Directus도 멀티유저 잠금/머지 모델 강화.

Edge 배포 + 콘텐츠

- Cloudflare Workers · Vercel Edge · Netlify Edge에서 CMS API를 직접 호출.

- Sanity의 GROQ는 Edge 친화적.

- Contentful · Hygraph는 GraphQL CDN을 제공.

다음 글 후보

- **헤드리스 이커머스 심층 - Medusa · Saleor · Hydrogen 실전 비교**

- **MDX 콘텐츠 파이프라인 - Contentlayer 종료 이후 Velite/Astro Content로의 마이그레이션**

- **Visual Editor의 끝 - Storyblok · Builder.io · Plasmic의 실제 운영 노하우**

> "CMS는 더 이상 단일 제품 카테고리가 아니다. 팀의 데이터 모델, 콘텐츠 에디터 수, 셀프 호스팅 여부에 따라 다른 답이 나온다. 한 도구로 모든 것을 다루려는 시도는 거의 항상 실패한다."

— 오픈소스 헤드리스 CMS 2026, 끝.

참고 문헌

- [Strapi 공식 문서](https://docs.strapi.io/)

- [Strapi GitHub - strapi/strapi](https://github.com/strapi/strapi)

- [Strapi 5 Document Service API](https://docs.strapi.io/dev-docs/api/document-service)

- [Directus 공식 문서](https://docs.directus.io/)

- [Directus GitHub - directus/directus](https://github.com/directus/directus)

- [Payload CMS 공식 문서](https://payloadcms.com/docs)

- [Payload GitHub - payloadcms/payload](https://github.com/payloadcms/payload)

- [KeystoneJS 공식 문서](https://keystonejs.com/docs)

- [Keystone GitHub - keystonejs/keystone](https://github.com/keystonejs/keystone)

- [Sanity 공식 문서](https://www.sanity.io/docs)

- [Sanity GROQ Reference](https://www.sanity.io/docs/groq)

- [Storyblok 공식 문서](https://www.storyblok.com/docs)

- [TinaCMS 공식 문서](https://tina.io/docs)

- [TinaCMS GitHub - tinacms/tinacms](https://github.com/tinacms/tinacms)

- [Decap CMS 공식 사이트](https://decapcms.org/)

- [Decap CMS GitHub - decaporg/decap-cms](https://github.com/decaporg/decap-cms)

- [Webiny 공식 문서](https://www.webiny.com/docs)

- [Apostrophe CMS](https://apostrophecms.com/)

- [Plone CMS](https://plone.org/)

- [Drupal 11 Release Notes](https://www.drupal.org/about/11)

- [WPGraphQL](https://www.wpgraphql.com/)

- [Faust.js by WP Engine](https://faustjs.org/)

- [Advanced Custom Fields](https://www.advancedcustomfields.com/)

- [Contentful 공식 문서](https://www.contentful.com/developers/docs/)

- [Hygraph 공식 사이트](https://hygraph.com/)

- [DatoCMS](https://www.datocms.com/)

- [ButterCMS](https://buttercms.com/)

- [Cosmic](https://www.cosmicjs.com/)

- [Builder.io](https://www.builder.io/)

- [Plasmic](https://www.plasmic.app/)

- [microCMS (Japan)](https://microcms.io/)

- [Newt (Japan)](https://www.newt.so/)

- [Movable Type](https://www.movabletype.jp/)

- [a-blog cms](https://www.a-blogcms.jp/)

- [Contentlayer GitHub - contentlayerdev/contentlayer](https://github.com/contentlayerdev/contentlayer)

- [Velite](https://velite.js.org/)

- [Astro Content Collections](https://docs.astro.build/en/guides/content-collections/)

- [Nuxt Content](https://content.nuxt.com/)

- [Outstatic](https://outstatic.com/)

- [Medusa](https://medusajs.com/)

- [Saleor](https://saleor.io/)

- [Crystallize](https://crystallize.com/)

- [Shopify Hydrogen](https://hydrogen.shopify.dev/)

- [W3Techs - CMS Usage Statistics](https://w3techs.com/technologies/overview/content_management)

- [Jamstack.org](https://jamstack.org/)

- [Headless CMS Comparison - headlesscms.org](https://headlesscms.org/)