Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — "더 이상 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강점약점대표 제품
REST단순, 캐시 친화오버페치/언더페치Strapi, Directus, WordPress
GraphQL클라이언트 주도 쿼리캐시 어려움, 학습 곡선KeystoneJS, Hygraph, Contentful
GROQ그래프 트래버스, Sanity 전용학습 필요, Sanity 외 사용 불가Sanity
OData / JSON:API표준 명세점유율 낮음Drupal JSON: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, 끝.

참고 문헌

Discuss on Twitter • View on GitHub