헤드리스 CMS 2026 — Sanity / Contentful / Strapi 5 / Payload (Figma 인수) / Directus / Keystatic / Storyblok 심층 비교

프롤로그 — "콘텐츠는 어디에 살아야 하는가"

2026년 한 마케팅 PM이 한 말.

"우리는 Next.js로 새로 만들고 있어요. 콘텐츠 모델은 누가 잡지요? 마케터가 직접 텍스트랑 이미지를 바꿀 수 있어야 하고, 다국어도 돼야 하고, 빌더로 페이지 조립도 하고 싶고, 그런데 개발자가 MDX로도 쓸 수 있으면 좋겠어요."

이게 2026년의 평범한 요구사항이다. "CMS 하나 깔자"가 더 이상 정답이 아니다. 에디터 UX, 데이터 모델, API 형태, 배포 모델, 가격, 락인 이 다섯 축의 매트릭스에서 우리 팀의 위치를 찾아야 한다.

이 글은 2026년 5월 현재 헤드리스 CMS 시장 전체를 한 장에 펼치고, 각 CMS의 강점·약점·지난 12개월 변화를 짚는다. Strapi 5의 Document Service(2024.9), Payload의 Figma 인수(2024.9)에 따른 오픈소스 커뮤니티 논란, Hygraph로 개명된 GraphCMS의 현재까지 — 결정을 미루지 말고 한 번 정리하자.

1장 · 2026년 헤드리스 CMS 지도 — 네 부족

먼저 시장 전체를 네 부족으로 자른다. 한 CMS가 두 부족에 걸치는 경우도 있지만, 주된 운영 모델로 분류한다.

이 분류가 중요한 이유는, 에디터 UX·운영 책임·락인 정도가 부족마다 다르기 때문이다.

• SaaS: 에디터 UX 최고, 운영 책임 없음, 락인 큼(데이터 export는 가능하지만 API·이미지 변환·실시간이 사라짐).
• 오픈소스 셀프호스트: 락인 작음, 운영 책임 큼(DB·백업·확장). 컨테이너로 띄우면 단순하지만 마케터에 친화적인 UX는 본인이 책임진다.
• Git 기반: 락인 거의 없음(콘텐츠가 본인 repo에 마크다운으로 있음), 다만 마케팅팀이 GitHub 로그인을 해야 하는 마찰.
• 비주얼: 마케터 자율성 최고, 개발자가 통제하기 어려운 페이지가 생긴다(디자인 시스템 일관성).

축으로 정리하면 이렇다.

이제 부족별로 들어간다.

2장 · Sanity — 리얼타임의 표준

Sanity는 2017년 노르웨이에서 시작했고, 2026년 헤드리스 CMS 시장에서 개발자가 가장 좋아하는 SaaS의 자리를 점점 굳히고 있다.

핵심 특징

• Sanity Studio — 콘텐츠 모델을 TypeScript 코드로 정의하는 에디터 UI. 마케터가 쓰는 화면 자체가 본인 repo 안의 코드다.
• GROQ — GraphQL이 아닌 자체 쿼리 언어. JSON-처럼 생긴 문법으로 깊은 조인·필터링.
• Portable Text — 단순 마크다운이 아닌, 임의의 블록을 끼울 수 있는 JSON 기반 리치 텍스트.
• 리얼타임 — 다수 에디터가 동시에 같은 문서를 편집하면 Google Docs처럼 보인다.
• Content Lake — 호스티드 데이터스토어, asset CDN·이미지 변환 내장.

// schemaTypes/post.ts — Sanity Studio 스키마
import { defineField, defineType } from 'sanity'

export const post = defineType({
  name: 'post',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string', validation: (r) => r.required() }),
    defineField({ name: 'slug', type: 'slug', options: { source: 'title' } }),
    defineField({ name: 'body', type: 'array', of: [{ type: 'block' }] }),
    defineField({
      name: 'author',
      type: 'reference',
      to: [{ type: 'author' }],
    }),
  ],
})

GROQ 쿼리는 이렇게 생겼다.

// Next.js에서 글 목록 가져오기
import { createClient } from '@sanity/client'

const client = createClient({
  projectId: 'abc',
  dataset: 'production',
  apiVersion: '2026-05-16',
  useCdn: true,
})

const posts = await client.fetch(`
  *[_type == "post" && defined(slug.current)]
  | order(publishedAt desc)[0...10]{
    title, "slug": slug.current, publishedAt,
    author->{name, avatar}
  }
`)

2026년의 변화

• AI Assist — 2024–2025년에 추가된 LLM 기반 번역·요약·alt 생성이 안정화됨.
• Sanity Connect — Shopify·Stripe 같은 외부 시스템에서 데이터를 끌어오는 connector.
• Live Content API — GROQ 쿼리를 구독해서 데이터 변경 시 자동으로 push받는 방식. 대시보드·실시간 사이트에 유용.

강점과 약점

누가 골라야 하나

• 콘텐츠 모델이 복잡하고 자주 바뀌는 팀.
• 다국어·다채널·다지역 콘텐츠를 한 곳에서 관리해야 하는 팀.
• 에디터가 동시에 여러 명 작업하는 매거진·미디어.

3장 · Contentful — 엔터프라이즈의 기본값

Contentful은 2013년 베를린에서 시작했고, 2026년에도 여전히 엔터프라이즈 헤드리스 CMS의 기본값이다. 큰 기업이 RFP를 돌리면 거의 항상 들어간다.

핵심 특징

• Content Model — Web UI에서 필드 정의, 타입 시스템(Symbol·Text·Reference·Asset·JSON).
• Compose — 페이지 단위 편집 UI(엔터프라이즈 부가).
• GraphQL / REST / CDN API — 둘 다 지원, 글로벌 CDN.
• App Framework — 에디터에 자체 앱을 끼워 워크플로 확장.
• Locales — 다국어 첫 클래스 지원.

// Contentful GraphQL 쿼리
const query = `
  query {
    postCollection(limit: 10, order: publishDate_DESC) {
      items {
        title
        slug
        publishDate
        author { name }
      }
    }
  }
`

const res = await fetch(
  `https://graphql.contentful.com/content/v1/spaces/${process.env.CONTENTFUL_SPACE_ID}/environments/master`,
  {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${process.env.CONTENTFUL_TOKEN}`,
    },
    body: JSON.stringify({ query }),
  },
)

강점과 약점

누가 골라야 하나

• 대기업·금융·미디어처럼 컴플라이언스·SLA가 필수인 팀.
• 콘텐츠 워크플로(작성 → 리뷰 → 승인)가 정형화된 조직.
• 다국어 가지 수가 많고 가지별로 별도 에디터가 붙는 운영.

4장 · Strapi 5 (2024.9) — Plugins v5 + Document Service

Strapi는 프랑스 출신 오픈소스 헤드리스 CMS다. Node/TS 기반, MIT 라이선스. 2024년 9월 Strapi 5가 정식 출시됐고, 2026년 현재의 기본 진입점은 v5다.

v5의 핵심 변화

• Document Service API — v4의 Entity Service를 대체. drafts·publish·locales를 일관된 API로.
• Plugins v5 — 플러그인 마켓을 정비, TypeScript 우선.
• Server-side React Admin — 어드민 패널 재작성.
• Vite 기반 빌드 — 어드민 빌드 시간 대폭 감소.

// Strapi 5 Document Service API 예시 (커스텀 라우트 안에서)
const documents = await strapi.documents('api::article.article').findMany({
  filters: { publishedAt: { $notNull: true } },
  sort: { publishedAt: 'desc' },
  populate: ['author'],
  status: 'published',
  locale: 'en',
})

// drafts와 published를 명시적으로 다루는 게 v5의 차이
const draft = await strapi.documents('api::article.article').findOne({
  documentId: 'abc123',
  status: 'draft',
})

강점과 약점

누가 골라야 하나

• 자체 인프라(쿠버네티스, Vercel 외부)에서 운영하고 싶은 팀.
• 데이터를 본인 DB(Postgres)에 두고 백업·복제까지 통제하고 싶은 조직.
• 플러그인을 직접 만들어 워크플로를 확장할 의지가 있는 팀.

5장 · Payload (Figma 인수 2024.9) — TS-first의 논란

Payload는 TypeScript-first 헤드리스 CMS다. 2021년 등장 후 빠르게 개발자 팬덤을 모았다. 2024년 9월 Figma가 Payload를 인수했고, 그 직후 오픈소스 커뮤니티에서 우려·논란이 일었다 — "Figma가 Payload를 자사 제품에 통합하면서 오픈소스 정체성이 흐려질 것 아니냐"는 걱정.

2026년 5월 현재까지의 관찰: Payload는 MIT 라이선스를 유지하고 있고, 코어는 계속 오픈소스로 개발 중이다. 그러나 Payload Cloud(호스티드) 와 Figma 측 통합 기능이 이전보다 빠르게 늘고 있다. 커뮤니티 일부는 "이건 점진적 enclosure다"라고 본다.

핵심 특징

• TypeScript-first — 스키마가 TS 타입과 통합, 어드민 컴포넌트도 React/TS.
• Code-first config — 콘텐츠 모델을 payload.config.ts에 정의.
• 로컬 API — Next.js 서버 컴포넌트에서 DB에 바로 접근하는 함수 호출.
• Access Control — 함수로 정의하는 권한.
• Blocks — 페이지 빌더 비슷한 컴포넌트 조립.

// payload.config.ts
import { buildConfig } from 'payload'
import { mongooseAdapter } from '@payloadcms/db-mongodb'

export default buildConfig({
  collections: [
    {
      slug: 'posts',
      fields: [
        { name: 'title', type: 'text', required: true },
        { name: 'slug', type: 'text', required: true, unique: true },
        {
          name: 'content',
          type: 'richText',
        },
        {
          name: 'author',
          type: 'relationship',
          relationTo: 'users',
        },
      ],
      access: {
        read: () => true,
        create: ({ req }) => Boolean(req.user),
      },
    },
  ],
  db: mongooseAdapter({ url: process.env.MONGODB_URI! }),
})

// Next.js 서버 컴포넌트에서 직접 조회
import { getPayload } from 'payload'
import config from '@/payload.config'

export default async function PostPage({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })
  const result = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug } },
    limit: 1,
  })
  const post = result.docs[0]
  return <article>{post.title}</article>
}

Figma 인수의 함의

• 긍정 — 자본·인력 확보로 코어 개발 속도 증가, Figma 디자인 시스템과의 통합 잠재력.
• 우려 — 호스티드 제품에 기능이 먼저 들어가고 OSS는 뒤처질 위험, 라이선스 변경 가능성(과거 다른 회사 사례).
• 현재 — MIT 유지, 코어 활발한 커밋. 단, 의사결정 권한은 인수 회사에 있으므로 락인 리스크 평가는 본인이.

누가 골라야 하나

• TS 개발자가 코어 사용자인 팀.
• 콘텐츠 모델이 코드로 버전 관리돼야 하는 워크플로.
• Next.js·React와 깊게 통합하고 싶은 팀(서버 컴포넌트에서 직접 호출 가능).

6장 · Directus — DB에서 API로 거꾸로 만든다

Directus의 출발점이 독특하다. 대부분의 CMS가 "어드민 UI → DB"로 가는데, Directus는 이미 있는 SQL DB에 붙여서 자동으로 어드민 UI와 REST/GraphQL API를 생성한다. 즉, 기존 데이터를 그대로 CMS로 만든다.

핵심 특징

• DB-first — Postgres·MySQL·SQLite·MSSQL을 그대로 쓴다.
• 자동 API — 테이블 정의에서 REST·GraphQL 자동 생성.
• No-code 어드민 — 마케터가 쓰는 화면.
• Flows — 조건·웹훅·스크립트 자동화.
• 확장 — Extensions로 hooks·endpoints·panels 추가.

-- 기존 DB의 articles 테이블
CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  content TEXT,
  published_at TIMESTAMPTZ
);

이 테이블을 Directus에 연결만 하면 즉시 어드민 UI와 API가 생긴다.

# REST로 조회
curl "https://cms.example.com/items/articles?fields=*,author.*&filter[status][_eq]=published"

# GraphQL로 조회
curl -X POST https://cms.example.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query":"{ articles(filter:{status:{_eq:\"published\"}}){ title slug }}"}'

강점과 약점

누가 골라야 하나

• 이미 SQL DB로 운영하는 데이터를 마케터에 노출하고 싶은 팀.
• 사이트뿐 아니라 내부 운영 툴까지 한 어드민으로 묶고 싶은 조직.
• 데이터·CMS·관리 도구 세 가지를 하나로 합치고 싶을 때.

7장 · Cosmic / Builder.io — 비주얼 + 헤드리스

이 두 곳은 "마케터가 페이지를 직접 만든다"가 핵심 가치다.

Cosmic

• 2014년 시작, SaaS 헤드리스 CMS.
• 좀 더 SaaS 표준적인 콘텐츠 객체 모델(오브젝트·메타필드).
• Next.js·React 스타터가 풍부, 작은 팀이 빠르게 셋업하기 좋음.
• 최근 AI 기반 콘텐츠 생성·번역 기능 강화.

Builder.io

• 비주얼 페이지 빌더 + 헤드리스 API.
• 드래그앤드롭 에디터에서 마케터가 React 컴포넌트로 페이지를 조립.
• Visual Copilot — Figma 디자인을 코드로 변환.
• A/B 테스트·개인화 내장.
• Mitosis로 컴포넌트를 여러 프레임워크로 변환.

// Builder.io에서 Next.js 페이지 렌더
import { builder, BuilderComponent } from '@builder.io/react'

builder.init(process.env.NEXT_PUBLIC_BUILDER_KEY!)

export default async function Page({ params }: { params: { slug: string[] } }) {
  const content = await builder
    .get('page', { url: '/' + params.slug.join('/') })
    .toPromise()

  return <BuilderComponent model="page" content={content} />
}

누가 골라야 하나 (둘 다)

• 마케팅·콘텐츠팀이 개발자 없이 페이지를 직접 만들기를 원할 때.
• 랜딩 페이지·캠페인이 잦은 e-commerce·SaaS.
• A/B 테스트와 개인화가 페이지 단위로 필요한 운영.

단, 디자인 시스템 일관성을 잃기 쉽다. 사용 가능한 컴포넌트 카탈로그를 미리 좁혀두는 게 핵심.

8장 · Keystatic (Thinkmill) — Git 기반 TS-first

Keystatic은 호주의 Thinkmill이 만들었고, Mark Pinches가 코어 메인테이너 중 한 명이다. 2023년 등장, 2026년 현재 Git 기반 CMS의 TS-first 대표주자로 자리를 잡았다.

핵심 특징

• 콘텐츠가 Git repo의 마크다운/YAML/JSON으로 저장됨 — DB 없음.
• 스키마가 TypeScript 코드 — 타입 안전.
• 로컬 어드민 UI — localhost에서 마크다운을 시각적으로 편집.
• GitHub 앱 모드 — GitHub OAuth로 마케터가 어드민에 로그인, 변경은 commit/PR로.
• Next.js·Astro·Remix 통합.

// keystatic.config.ts
import { config, fields, collection } from '@keystatic/core'

export default config({
  storage: { kind: 'github', repo: 'me/blog' },
  collections: {
    posts: collection({
      label: 'Posts',
      slugField: 'title',
      path: 'content/posts/*',
      format: { contentField: 'content' },
      schema: {
        title: fields.slug({ name: { label: 'Title' } }),
        publishedAt: fields.date({ label: 'Published' }),
        content: fields.markdoc({ label: 'Content' }),
      },
    }),
  },
})

강점과 약점

누가 골라야 하나

• 블로그·문서 사이트·소규모 마케팅 사이트.
• 콘텐츠도 PR 기반 워크플로로 관리하고 싶은 개발자 팀.
• "외부 SaaS에 콘텐츠 두기 싫음"이 강한 요구사항인 조직.

9장 · Storyblok — 비주얼 에디터의 강자

Storyblok은 오스트리아 출신 SaaS 헤드리스 CMS. 2017년 시작, 비주얼 에디터가 가장 큰 차별점이다.

핵심 특징

• Visual Editor — 사이트 미리보기 위에서 직접 클릭해 편집.
• Bloks — 페이지 = 블록의 조합. 블록 = 컴포넌트.
• CDN API — 글로벌 캐시.
• 다국어 — Field-level translation 또는 Folder-level.
• Pipelines — 워크플로 관리.

// Next.js에서 Storyblok 페이지 가져오기
import { storyblokInit, apiPlugin, getStoryblokApi } from '@storyblok/react'

storyblokInit({ accessToken: process.env.STORYBLOK_TOKEN, use: [apiPlugin] })

export default async function Page({ params }: { params: { slug: string[] } }) {
  const slug = params.slug?.join('/') || 'home'
  const sb = getStoryblokApi()
  const { data } = await sb.get(`cdn/stories/${slug}`, { version: 'published' })
  return <StoryblokComponent blok={data.story.content} />
}

강점과 약점

누가 골라야 하나

• 마케팅팀이 페이지를 직접 만들면서도 컴포넌트 통제는 유지하고 싶을 때.
• 다국어 사이트로 글로벌 캠페인을 자주 도는 브랜드.
• e-commerce·B2B SaaS의 마케팅 사이트.

10장 · Hygraph (구 GraphCMS) — GraphQL 우선

GraphCMS는 2022년 Hygraph로 리브랜딩했다. 이름이 바뀌었지만 GraphQL 우선 헤드리스 CMS라는 정체성은 그대로다.

핵심 특징

• GraphQL-native — REST가 아닌 GraphQL이 1차 API.
• Content Federation — 외부 GraphQL 소스를 결합.
• i18n 첫 클래스 — Localizations.
• Stages — DRAFT·PUBLISHED 등 단계 모델.
• Asset Pipeline — 이미지 변환·최적화 내장.

# Hygraph GraphQL 쿼리
query Posts {
  posts(orderBy: publishedAt_DESC, first: 10, locales: [en, ko]) {
    id
    title
    slug
    publishedAt
    author {
      name
    }
  }
}

누가 골라야 하나

• 기존 인프라가 이미 GraphQL 중심.
• 여러 데이터 소스를 GraphQL Federation으로 묶고 싶은 팀.
• 다국어가 콘텐츠 모델의 핵심 차원.

11장 · Prismic / Hashnode / Outstatic — 그 외 SaaS와 Git

Prismic

• 2013년 프랑스 출신, 오래된 SaaS CMS.
• Slices — 재사용 컴포넌트 조각, 마케터가 페이지에 끼움.
• 가격이 작은 팀에 합리적.
• 강점: 안정성·다국어. 약점: 혁신 속도는 Sanity·Storyblok에 비해 느림.

Hashnode

• 개발자 블로그·뉴스레터 특화 SaaS.
• 자체 CDN·SEO·뉴스레터 발송 내장.
• 무료 tier가 관대, custom domain 무료.
• Headless API도 제공해 자체 사이트에서 Hashnode를 콘텐츠 백엔드로 쓸 수 있음.
• 누가: 개인 개발자·기술 블로거.

Outstatic

• Next.js 친화 Git 기반 CMS.
• Keystatic과 비슷한 결, Next.js 통합이 가장 우선.
• GitHub OAuth로 어드민, 마크다운 commit.
• 누가: Next.js로 작은 사이트 빠르게 띄우는 1인 개발자.

12장 · Dato CMS / ButterCMS / KeystoneJS — 그 외 헤드리스

Dato CMS

• 이탈리아 출신 SaaS 헤드리스 CMS.
• Modular Content — 블록 기반 리치 텍스트.
• 이미지 파이프라인 — imgix 통합.
• 강점: 풍부한 필드 타입·이미지 처리. 약점: 가격이 빠르게 오름.

ButterCMS

• API-first SaaS CMS, 작은 팀에 친화적.
• 가격이 명확하고 단순.
• 멀티-사이트 지원이 강점.
• 누가: 작은 회사가 블로그·마케팅 페이지를 빠르게 띄울 때.

KeystoneJS

• TypeScript-first OSS 헤드리스 (Thinkmill 제작 — Keystatic과는 별개 프로젝트).
• Prisma 기반 데이터 모델, GraphQL API 자동 생성.
• 어드민 UI 포함.
• 누가: 셀프호스트로 강력한 데이터 모델이 필요한 팀.

13장 · Ghost / WordPress headless / Webflow / Notion — 비-전통 CMS

이 네 가지는 "헤드리스 전용으로 태어나지 않았지만 헤드리스처럼 쓰는" 부족이다.

Ghost

• 노드 기반 블로그·뉴스레터 플랫폼.
• 자체 에디터 UX가 가장 깔끔한 축.
• Content API로 헤드리스로 사용 가능.
• 누가: 작가·뉴스레터·미디어 1인.

WordPress headless

• 2026년에도 인터넷의 큰 부분이 WordPress.
• WP REST API 또는 WPGraphQL로 헤드리스 모드.
• 강점: 풍부한 플러그인·마케터 친숙. 약점: WP 운영 부담, 보안.
• 누가: 이미 WP에 콘텐츠가 많은 조직이 프론트엔드만 Next.js로 옮기고 싶을 때.

Webflow

• 사이트 빌더이지만 CMS Collections를 API로 노출.
• 디자이너·마케터가 직접 디자인·콘텐츠 동시 운영.
• Headless 모드: Webflow를 콘텐츠 백엔드로 두고 프론트는 Next.js.
• 누가: 디자이너 주도 마케팅 사이트.

Notion as CMS

• Notion API + 빌드 타임 fetch로 사이트를 만드는 패턴.
• 가장 마찰 없는 에디터(모든 회사가 이미 Notion 씀).
• 약점: API rate limit, 이미지 URL 만료, 콘텐츠 모델링 제약.
• 누가: 스타트업 초기 마케팅 사이트·문서 사이트.

14장 · decap CMS (구 Netlify CMS) / Statamic — Git 기반과 플랫파일

decap CMS (구 Netlify CMS)

• 원래 Netlify CMS, 2023년에 decap CMS로 개명·커뮤니티 관리로 이관.
• Git 기반, 마크다운 commit, GitHub/GitLab/Bitbucket OAuth.
• 정적 사이트 생성기(Hugo·Jekyll·Astro·Next.js)와 함께 자주 쓰임.
• 강점: 무료, 락인 0. 약점: 커뮤니티 주도, 업데이트 속도가 들쭉날쭉.

Statamic

• Laravel 기반 플랫파일 CMS (DB 불필요).
• 콘텐츠가 YAML/마크다운으로 파일 시스템에 저장.
• 자체 admin UI 포함.
• 헤드리스 모드(GraphQL/REST API)도 지원.
• 누가: Laravel 친숙한 팀이 콘텐츠도 파일 기반으로 가져가고 싶을 때.

15장 · 한국 — 마크다운 CMS 트렌드와 카카오 컨텐츠

한국 헤드리스 CMS 사용 패턴의 2026년 특징.

마크다운/Git 기반 사용 증가

• velog·tistory 같은 호스티드 블로그에서 Next.js + Contentlayer/Keystatic/Outstatic으로 자체 사이트를 짓는 개발자가 늘었다.
• 2024–2026년 채용 시장에서 "본인 기술 블로그"가 평가 요소가 되면서, 락인이 없는 마크다운 CMS의 수요가 늘었다.

카카오 컨텐츠 / 브런치 / 네이버

• 카카오 브런치스토리는 작가 등록제 SaaS로, API 노출은 거의 없음. 헤드리스 사용은 어렵다.
• 네이버 블로그·티스토리도 RSS 정도만 외부에 노출.
• 한국 미디어 기업(중앙일보·한경 등)은 자체 CMS(주로 사내 빌드 + WP/Drupal) 사용이 많고, 점진적으로 헤드리스로 이동 중.

SaaS 사용

• 한국 기업도 Contentful·Sanity·Storyblok을 도입하는 사례가 늘었다. 특히 글로벌 사이트(EN/KO/JA/ZH) 가 필요한 e-commerce·게임사.
• 라인·카카오·쿠팡 등 규모가 큰 곳은 자체 CMS·툴체인을 유지.

한글 검색·SEO 고려

• 한국 SEO는 네이버 검색 점유가 여전히 크고, 네이버 콘텐츠 색인은 사이트맵·RSS 의존이 크다. 헤드리스 사이트일수록 SSG·ISR로 정적 HTML을 잘 노출하는 게 중요.

16장 · 일본 — microCMS, Newt, Storyblok 일본

일본은 로컬 SaaS CMS가 강한 시장이다.

microCMS

• 일본에서 만든 SaaS 헤드리스 CMS, 2019년 시작.
• 일본어 UI·일본어 문서가 완비, 일본 기업이 가장 자주 쓰는 헤드리스 CMS 중 하나.
• 콘텐츠 API·관리 API·이미지 API 분리.
• 가격이 일본 기업에 친화적, JPY 결제.
• 누가: 일본 시장 중심 사이트(EC·미디어·기업 사이트).

// microCMS 클라이언트
import { createClient } from 'microcms-js-sdk'

const client = createClient({
  serviceDomain: 'example',
  apiKey: process.env.MICROCMS_API_KEY!,
})

const data = await client.get({
  endpoint: 'posts',
  queries: { limit: 10, orders: '-publishedAt' },
})

Newt

• 2021년 일본 출시 SaaS 헤드리스 CMS, microCMS의 경쟁자.
• 일본어 우선 UX·로컬 결제.
• GraphQL·CDN API 모두 지원.
• 누가: microCMS와 거의 같은 페르소나, 좀 더 모던한 UX 선호.

Storyblok 일본 진출

• Storyblok이 2023–2024년 일본 시장에 본격 진출.
• 일본어 UI·일본 결제 지원.
• 일본 대기업이 글로벌 사이트를 만들 때 microCMS 대신 Storyblok을 고르는 사례 등장.

Contentful·Sanity 사용

• 일본 대기업 중 일부는 Contentful 사용. 특히 글로벌 컴플라이언스가 필요한 금융·자동차.
• Sanity는 일본 시장 점유는 낮으나 디자인·미디어 스타트업에서 선택지로 부상.

17장 · 누가 무엇을 골라야 하나 — 결정 가이드

잘못된 선택의 신호

• 마케터가 매번 개발자에게 변경 요청을 한다 → 에디터 UX가 잘못된 CMS.
• 콘텐츠 export가 두려워서 CMS를 못 바꾼다 → 락인이 너무 큰 SaaS.
• 빌드 시간이 콘텐츠 양에 비례해 폭증한다 → SSG-only를 ISR/SSR로 옮길지, 헤드리스 SaaS의 CDN을 더 쓸지 검토.
• 다국어가 자꾸 손이 간다 → i18n이 첫 클래스가 아닌 CMS를 골랐을 가능성.
• 이미지 변환을 직접 한다 → CDN 내장 CMS로 이전, 또는 Cloudinary·imgix 추가.

마이그레이션 비용 추정

• SaaS → SaaS: 데이터 export → import 매핑 + 이미지 재업로드. 콘텐츠 1000건당 1–2주.
• SaaS → 셀프호스트: 위 + 인프라 셋업. 2–4주.
• WP → 헤드리스: 콘텐츠 모델 재정의 + 라우팅 재설계. 2–6주(블로그) / 2–6개월(대형 사이트).
• Git → SaaS: 마크다운 → CMS 필드 매핑 스크립트. 1–2주.

마치며 — 콘텐츠는 자산이다

CMS를 고르는 일은 콘텐츠 자산을 어디에 둘지를 정하는 일이다. 도구는 다섯 해마다 갈아탈 수 있지만, 그동안 쌓은 콘텐츠는 본인 회사의 자산이다.

2026년 5월 현재, 한 줄 요약.

• 자유와 통제: Strapi 5, Payload, Directus, Keystatic.
• 마케터 UX와 다국어: Sanity, Contentful, Storyblok.
• 락인 없는 작은 사이트: Keystatic, Outstatic, Hashnode, decap.
• 비주얼·페이지 빌더: Builder.io, Storyblok, Webflow.
• 일본 시장: microCMS, Newt.

규칙은 두 가지뿐이다. 첫째, 데이터 export를 보장하는 CMS를 골라라. 둘째, 마케터가 매일 쓸 UI를 본인이 한 번 써봐라. 나머지는 카탈로그의 디테일이다.

참고 / References

• Sanity — https://www.sanity.io/
• Sanity GROQ docs — https://www.sanity.io/docs/groq
• Contentful — https://www.contentful.com/
• Strapi 5 release notes — https://strapi.io/blog/strapi-5
• Strapi Document Service API — https://docs.strapi.io/dev-docs/api/document-service
• Payload CMS — https://payloadcms.com/
• Payload joins Figma (2024-09) — https://payloadcms.com/blog/payload-joins-figma
• Directus — https://directus.io/
• Cosmic CMS — https://www.cosmicjs.com/
• Builder.io — https://www.builder.io/
• Keystatic — https://keystatic.com/
• Storyblok — https://www.storyblok.com/
• Hygraph (formerly GraphCMS) — https://hygraph.com/
• Prismic — https://prismic.io/
• Hashnode — https://hashnode.com/
• Outstatic — https://outstatic.com/
• Dato CMS — https://www.datocms.com/
• ButterCMS — https://buttercms.com/
• KeystoneJS — https://keystonejs.com/
• Ghost — https://ghost.org/
• WPGraphQL — https://www.wpgraphql.com/
• Webflow — https://webflow.com/cms
• Notion API — https://developers.notion.com/
• decap CMS — https://decapcms.org/
• Statamic — https://statamic.com/
• microCMS — https://microcms.io/
• Newt — https://www.newt.so/