오픈소스 헤드리스 CMS 2026 완벽 가이드 - Strapi 5 · Directus 11 · Payload 3 · KeystoneJS · Sanity · Storyblok · TinaCMS · Decap CMS 심층 분석

• 프롤로그 — "더 이상 CMS는 단일 카테고리가 아니다"
• 1. 헤드리스 vs 전통적 CMS — 무엇이 다른가
• 2. Strapi 5 — Node.js 헤드리스의 사실상 표준
  • 핵심 개념
  • 강점
  • 약점
  • Strapi Cloud
  • 언제 선택할까
• 3. Directus 11 — "어떤 SQL DB든 즉시 API화"
  • 핵심 개념
  • 강점
  • 약점
  • Directus Cloud
  • 언제 선택할까
• 4. Payload 3 — Next.js 네이티브 풀스택 CMS
  • 핵심 개념
  • 강점
  • 약점
  • Payload Cloud
  • 언제 선택할까
• 5. KeystoneJS 6 — GraphQL-first, Thinkmill의 선택
  • 핵심 개념
  • 강점
  • 약점
  • 언제 선택할까
• 6. Sanity — GROQ와 실시간 협업의 관리형 챔피언
  • 핵심 개념
  • 강점
  • 약점
  • 언제 선택할까
• 7. Storyblok — Visual Editor의 강자
  • 핵심 개념
  • 강점
  • 약점
  • 언제 선택할까
• 8. TinaCMS — git-backed, 마크다운 중심
  • 핵심 개념
  • 강점
  • 약점
  • 언제 선택할까
• 9. Decap CMS — 옛 Netlify CMS의 후신
  • 핵심 개념
  • 강점
  • 약점
  • 언제 선택할까
• 10. Webiny · Apostrophe · Plone · Drupal — 그 외 후보들
  • Webiny
  • Apostrophe
  • Plone CMS
  • Drupal 10/11
• 11. WordPress의 헤드리스 진영 — WP-API + Faust.js + ACF
  • 핵심 도구
  • 강점
  • 약점
  • 언제 선택할까
• 12. 관리형 헤드리스 시장 — Contentful · Hygraph · DatoCMS · ButterCMS · Cosmic
  • 신흥/중간 카테고리
  • Builder.io · Plasmic — 비주얼 페이지 빌더
• 13. 일본 헤드리스 CMS — microCMS · Newt · a-blog cms
  • microCMS
  • Newt
  • a-blog cms
  • Movable Type
  • Sanity · Contentful의 일본 진출
• 14. 한국 시장의 CMS — 어떻게 다른가
• 15. 마크다운/MDX 기반 — Contentlayer · Velite · Astro · Nuxt Content
  • Contentlayer 2
  • Velite
  • Astro Content Collections
  • Nuxt Content
  • Outstatic
  • MDX의 위상
• 16. 데이터 모델 — Document vs Collection vs Block
  • Document 모델 (Sanity, Strapi 5)
  • Collection 모델 (Directus, Payload, KeystoneJS)
  • Block 모델 (Storyblok, Builder.io)
  • Portable Text (Sanity)
  • 어떤 모델을 골라야 하나
• 17. API — REST vs GraphQL vs GROQ
  • CDN과 캐시
• 18. 이커머스 헤드리스 — Medusa · Saleor · Crystallize
  • Medusa
  • Saleor
  • Crystallize
  • Shopify의 헤드리스 진영
  • 다음 글 후보
• 19. 사용 사례별 추천 — 결정 매트릭스
  • 마케팅 사이트
  • 기술 문서
  • 모바일 앱 백엔드
  • 이커머스 + 콘텐츠
  • 사내 백오피스 + 외부 API
• 20. 의사결정 체크리스트
• 21. 흔히 하는 7가지 실수
• 22. 2026년 트렌드 — AI · 협업 · Edge
  • AI 콘텐츠 어시스턴트
  • 실시간 협업의 일반화
  • Edge 배포 + 콘텐츠
  • 다음 글 후보
• 참고 문헌

프롤로그 — "더 이상 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의 본질적 차이는 단순합니다.

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는 오픈소스와 다른 게임을 합니다. 인프라 운영을 사지 않는 것이 핵심 가치.

신흥/중간 카테고리

• 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의 모양으로 차별화됩니다.

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 공식 문서
• Strapi GitHub - strapi/strapi
• Strapi 5 Document Service API
• Directus 공식 문서
• Directus GitHub - directus/directus
• Payload CMS 공식 문서
• Payload GitHub - payloadcms/payload
• KeystoneJS 공식 문서
• Keystone GitHub - keystonejs/keystone
• Sanity 공식 문서
• Sanity GROQ Reference
• Storyblok 공식 문서
• TinaCMS 공식 문서
• TinaCMS GitHub - tinacms/tinacms
• Decap CMS 공식 사이트
• Decap CMS GitHub - decaporg/decap-cms
• Webiny 공식 문서
• Apostrophe CMS
• Plone CMS
• Drupal 11 Release Notes
• WPGraphQL
• Faust.js by WP Engine
• Advanced Custom Fields
• Contentful 공식 문서
• Hygraph 공식 사이트
• DatoCMS
• ButterCMS
• Cosmic
• Builder.io
• Plasmic
• microCMS (Japan)
• Newt (Japan)
• Movable Type
• a-blog cms
• Contentlayer GitHub - contentlayerdev/contentlayer
• Velite
• Astro Content Collections
• Nuxt Content
• Outstatic
• Medusa
• Saleor
• Crystallize
• Shopify Hydrogen
• W3Techs - CMS Usage Statistics
• Jamstack.org
• Headless CMS Comparison - headlesscms.org