Contentful vs Sanity vs Payload: 헤드리스 CMS 비교 2026
지난 4년간 이 세 가지 CMS 모두로 프로덕션 프로젝트를 구축했습니다. 어떤 것은 새로운 구축이었고, 다른 것은 WordPress에서 마이그레이션하거나 무너져 가고 있던 레거시 시스템에서의 이전이었습니다. 클라이언트가 "어떤 헤드리스 CMS를 사용해야 하나요?"라고 물어볼 때마다 일률적인 답변을 피하려고 하지만, 2025년을 거쳐 2026년까지 수십 개의 프로젝트를 출시한 후, 실제 현장의 상흔에 뒷받침된 강한 의견을 가지고 있습니다.
이 글은 실제로 무언가를 구축할 때 중요한 측면들을 중심으로 Contentful, Sanity, Payload CMS를 분석합니다: 규모별 가격, 현장에서의 개발자 경험, 콘텐츠 모델링 유연성, API 설계, 그리고 콘텐츠 팀이 사랑하거나 미워할 일상적인 편집 워크플로우.
목차
- 30초 개요
- 가격 분석: 실제로 지불할 비용
- 개발자 경험
- 콘텐츠 모델링
- APIs: REST, GraphQL, 그리고 그 사이의 모든 것
- 편집 경험
- 자체 호스팅 vs SaaS: 실제 장단점
- 성능 및 확장성
- 에코시스템 및 커뮤니티
- 결론
- FAQ
30초 개요
Contentful은 기존 업체입니다. 2013년부터 존재했으며 규모가 있는 엔터프라이즈 사이트를 지원합니다. 세련되고 신뢰할 수 있으며 비쌉니다.
Sanity는 실시간, 구조화된 콘텐츠 접근 방식과 맞춤 가능한 스튜디오를 갖춘 개발자 최고의 선택입니다. 강력하지만 학습 곡선이 있고 가격 책정 모델이 놀라울 수 있습니다.
Payload는 조용히 심각한 경쟁자가 된 신흥주자입니다. 오픈소스이고, 기본적으로 자체 호스팅되고(이제 클라우드 옵션도 있음), TypeScript로 작성되어 있으며, 라이선스 비용이 없습니다. 2025년에 Payload 3.0은 Next.js 기반의 완전한 재작성과 함께 출시되었으며, 이것이 전체 상황을 바꾸었습니다.
| 기능 | Contentful | Sanity | Payload |
|---|---|---|---|
| 유형 | SaaS | SaaS (스튜디오 자체 호스팅) | 오픈소스 / 자체 호스팅 |
| 언어 | N/A (API 전용) | JavaScript/React | TypeScript/Next.js |
| 라이선스 비용 | 있음 | 있음 (사용량 기반) | 없음 (MIT) |
| GraphQL | 있음 | 있음 (GROQ 선호) | 있음 (자동 생성) |
| REST API | 있음 | 있음 | 있음 (자동 생성) |
| 실시간 협업 | 제한적 | 우수함 | 좋음 (2.0+) |
| 자체 호스팅 | 없음 | 스튜디오만 | 전체 스택 |
| 데이터베이스 | 독점 | 독점 | MongoDB 또는 Postgres |
가격 분석: 실제로 지불할 비용
여기서 현실이 드러납니다. 가격은 프로젝트 중간에 CMS를 전환한 팀의 제일 이유이며, 평가 중에 사람들이 과소평가하는 제1의 대상입니다.
Contentful 가격 책정 (2026)
Contentful의 무료 계층은 1개 공간, 5명 사용자, 25K API 호출을 제공합니다. 블로그에는 괜찮습니다.
Basic 계획은 월 $300부터 시작하며 더 많은 환경과 역할을 제공합니다. Premium 계획 — 대부분의 심각한 팀이 필요로 하는 계획 — 은 맞춤형 가격이지만 일반적으로 중규모 조직의 경우 월 $2,000~$3,000부터 시작합니다. 연간 $80K 이상의 엔터프라이즈 계약을 봤습니다.
함정은 API 호출 초과입니다. Contentful은 Content Delivery API 호출, Content Management API 호출, 자산 대역폭을 별도로 청구합니다. 월 1,000만+ 페이지뷰를 하는 높은 트래픽 사이트에서는 포함된 할당량을 쉽게 초과할 수 있습니다. 함께 일했던 한 클라이언트는 바이럴 제품 출시 후 CDN 및 API 초과 비용 때문에 월 청구서가 $2,500에서 $4,800로 뛰었습니다.
Sanity 가격 책정 (2026)
Sanity는 "성장에 따라 지불"이라고 부르는 사용량 기반 모델을 사용합니다. Free 계획에는 3명의 비관리자 사용자, 500K API 요청, 20GB 대역폭, 10GB 스토리지가 포함됩니다. 시작하기에 충분합니다.
Growth 계획은 월 사용자당 $15 + 사용량 초과입니다. Enterprise 계획은 맞춤형 가격입니다.
사람들에게 물리는 Sanity 가격 책정의 점은: GROQ 쿼리 및 API CDN 요청이 측정되고, 비용이 콘텐츠 복잡도에 따라 확장됩니다. 깊게 중첩된, 참조된 콘텐츠를 가져오는 단일 GROQ 쿼리는 예상보다 더 많은 할당량을 소비할 수 있습니다. Sanity는 투명성을 개선했지만, 팀이 조기에 예산 알림을 설정하도록 권장합니다.
일반적인 중규모 프로젝트 비용: 팀 규모 및 트래픽에 따라 월 $200~$800.
Payload 가격 책정 (2026)
Payload는 MIT 라이선스입니다. CMS 자체는 $0입니다. 영원히. 사용자당 수수료 없음, API 호출 계량 없음, Payload의 대역폭 요금 없음.
비용은 인프라입니다: Node.js 앱과 데이터베이스를 호스팅하는 것입니다. Railway, Render, 또는 기본 AWS/DigitalOcean 설정 같은 서비스에서는 대부분의 프로젝트에 대해 월 $20~$100을 보고 있습니다. AWS RDS의 관리 Postgres, 적절한 크기의 EC2 또는 ECS, 앞단의 CloudFront를 갖춘 대규모 배포도 거의 월 $300~$500을 초과하지 않습니다 — 그리고 이것은 심각한 트래픽을 위한 것입니다.
Payload Cloud (그들의 호스팅 서비스)는 월 $50부터 시작하며 스토리지 및 대역폭에 따라 계획이 확장되지만, 완전히 선택사항입니다.
| 시나리오 | Contentful | Sanity | Payload (자체 호스팅) |
|---|---|---|---|
| 솔로 개발자, 소규모 사이트 | $0 (무료 계층) | $0 (무료 계층) | 월 $20~40 (호스팅) |
| 5명 팀, 중간 트래픽 | 월 $300~500 | 월 $200~400 | 월 $50~100 (호스팅) |
| 10명 팀, 높은 트래픽 | 월 $2,000~4,000 | 월 $500~1,500 | 월 $150~400 (호스팅) |
| 엔터프라이즈, 50명+ 편집자 | 월 $5,000~10,000+ | 월 $2,000~5,000 | 월 $300~800 (호스팅) |
가격 이야기는 명확합니다. Payload는 모든 계층에서 이깁니다.
개발자 경험
가격은 문을 열게 합니다. 개발자 경험은 사람들을 그곳에 계속 있게 합니다 — 또는 그들을 몰아냅니다.
Contentful DX
Contentful의 개발자 경험은... 괜찮습니다. 광범위한 SDK 지원 (JavaScript, Python, Ruby, Java, Swift 등), 성숙한 문서, 그리고 잘 문서화된 REST 및 GraphQL API가 있습니다.
하지만 제를 좌절하게 하는 점은: 모든 것이 웹 UI를 통해 구성됩니다. 콘텐츠 유형, 필드, 검증 — 모든 것이 브라우저에서 클릭-클릭-클릭입니다. 예, Contentful CLI 및 마이그레이션 스크립트를 사용하여 스키마 버전을 제어할 수 있지만, 볼트온으로 느껴집니다. 코드 우선이 아니라 UI 우선이며 코드 탈출구가 있습니다.
마이그레이션 도구는 contentful-migration 패키지로 개선되었지만, TypeScript에서 스키마를 정의하고 즉시 타입 안전성을 얻는 것과 비교하면? 한 세대 뒤떨어진 느낌입니다.
Sanity DX
Sanity의 개발자 경험은 많은 측면에서 정말 우수합니다. 스키마는 JavaScript/TypeScript 파일에 정의됩니다. 스튜디오는 광범위하게 맞춤할 수 있는 React 앱입니다 — 맞춤 입력 컴포넌트, 맞춤 보기, 워크플로우 플러그인.
GROQ, 그들의 쿼리 언어는 강력하지만 학습한 후입니다. 그 문장에서 "학습한 후"는 많은 무거운 짐을 짓고 있습니다. GROQ는 SQL이 아닙니다. GraphQL도 아닙니다. 그것 자체이며, 팀의 모든 새로운 개발자는 그것을 배워야 합니다. 주니어 개발자들이 GROQ 프로젝션으로 몇 주를 고생하는 것을 봤습니다.
// GROQ 쿼리 - 강력하지만 고유한 구문
*[_type == "post" && publishedAt < now()] | order(publishedAt desc) [0...10] {
title,
slug,
"author": author->{ name, image },
"categories": categories[]->{ title, slug },
body[] {
...,
_type == "image" => {
"url": asset->url
}
}
}
하지만 Sanity의 실시간 기능은 놀랍습니다. 같은 문서를 여러 편집자가 작업할 때 현재 상태 표시기와 저장 충돌이 없음 — 그냥 작동합니다. 콘텐츠 레이크 아키텍처는 경쟁자들이 일치할 수 없는 방식으로 이를 가능하게 합니다.
Payload DX
Payload 3.0은 모든 것을 바꿨습니다. Next.js 기반, 완전히 TypeScript로 작성, 단일 진실 공급원으로서 구성 파일이 있습니다. 컬렉션, 필드, 훅, 접근 제어, 그리고 맞춤 엔드포인트를 모두 코드에서 정의합니다.
일반적인 Payload 컬렉션은 다음과 같습니다:
import { CollectionConfig } from 'payload'
export const Posts: CollectionConfig = {
slug: 'posts',
admin: {
useAsTitle: 'title',
defaultColumns: ['title', 'status', 'publishedAt'],
},
access: {
read: () => true,
create: ({ req: { user } }) => Boolean(user),
update: ({ req: { user } }) => Boolean(user),
delete: ({ req: { user } }) => user?.role === 'admin',
},
fields: [
{
name: 'title',
type: 'text',
required: true,
},
{
name: 'content',
type: 'richText',
},
{
name: 'author',
type: 'relationship',
relationTo: 'users',
},
{
name: 'status',
type: 'select',
options: ['draft', 'published'],
defaultValue: 'draft',
},
{
name: 'publishedAt',
type: 'date',
admin: {
position: 'sidebar',
},
},
],
hooks: {
beforeChange: [
({ data, operation }) => {
if (operation === 'create') {
data.publishedAt = new Date()
}
return data
},
],
},
}
모든 것이 타입화됩니다. IDE가 필드 이름을 자동완성합니다. 훅은 라이프사이클 제어를 제공합니다. 접근 제어는 필드 바로 옆에 함수로 정의되며, 별도의 권한 UI가 아닙니다. 그리고 그것은 단지 Next.js 앱이므로, 맞춤 페이지, API 경로, 또는 서버 작업을 CMS 코드 옆에 추가할 수 있습니다.
Next.js 개발을 하는 팀의 경우, Payload 3.0은 DX 측면에서 당연한 선택입니다. CMS와 프론트엔드가 같은 프로젝트에 있습니다. 같은 배포. 같은 리포지토리.
콘텐츠 모델링
콘텐츠 모델링은 성공을 위해 자신을 설정하거나 몇 년간 살아갈 악몽을 만드는 곳입니다.
Contentful의 접근 방식
Contentful은 전통적인 콘텐츠 유형 → 항목 모델을 사용합니다. 필드를 가진 콘텐츠 유형을 정의하고, 편집자가 항목을 만듭니다. 콘텐츠 유형 간의 참조는 명시적입니다. 간단한 콘텐츠 구조에 잘 작동합니다.
한계는 리치 텍스트로 나타납니다. Contentful의 리치 텍스트 필드는 콘텐츠를 구조화된 JSON 트리로 저장하며, 이는 렌더링 유연성에 좋지만, 중첩된 컴포넌트를 가진 복잡한 페이지 레이아웃을 모델링하려면 임베드된 항목과 참조의 창의적인 사용이 필요합니다. 번거로워질 수 있습니다.
Contentful은 Basic 계획에서 50개의 콘텐츠 유형과 Premium에서 100+ 개를 지원합니다. 많은 콘텐츠 유형을 가진 대규모 사이트의 경우, 이것이 제약이 될 수 있습니다.
Sanity의 접근 방식
Sanity의 콘텐츠 모델링은 아마도 세 가지 중 가장 유연합니다. 그들의 블록 콘텐츠 (Portable Text)는 리치 텍스트를 위한 오픈 스펙이며 콘텐츠를 구조화된 데이터로 저장합니다. 맞춤 블록 유형, 인라인 객체, 및 주석을 정의할 수 있습니다.
스키마 시스템은 깊게 중첩된 객체 유형, 조건부 필드, 및 맞춤 검증을 지원합니다. 저는 Sanity에서 Contentful에서 고통스러울 일부 진정으로 복잡한 콘텐츠 모델을 구축했습니다.
// Portable Text 맞춤 Sanity 스키마
export default {
name: 'post',
type: 'document',
fields: [
{
name: 'body',
type: 'array',
of: [
{ type: 'block',
marks: {
annotations: [
{ name: 'internalLink', type: 'object',
fields: [{ name: 'reference', type: 'reference', to: [{ type: 'post' }] }]
}
]
}
},
{ type: 'image', options: { hotspot: true } },
{ type: 'codeBlock' },
{ type: 'callout' },
]
}
]
}
Payload의 접근 방식
Payload의 콘텐츠 모델링은 Contentful의 구조화된 단순성과 Sanity의 자유로운 유연성 사이에 있습니다 — 하지만 완전히 TypeScript에 있다는 장점이 있습니다.
Payload의 blocks 필드는 특히 페이지 구축에 강력합니다. 각각의 필드로 블록 유형을 정의하고, 편집자가 이러한 블록으로부터 페이지를 구성할 수 있습니다. layout 필드 유형과 조건부 로직과 결합되면, 거의 모든 것을 모델링할 수 있습니다.
Payload 3.0의 Lexical 리치 텍스트 편집기는 뛰어난 점입니다. Slate를 대체했으며(괜찮았지만 노후화됨), 현대적인 편집기를 사용하며 맞춤 노드, 인라인 블록, 그리고 기본으로 서버 측 렌더링을 지원합니다. 리치 텍스트 콘텐츠에 React 컴포넌트를 직접 임베드할 수 있습니다.
버전 관리 시스템도 언급할 가치가 있습니다. Payload는 초안/게시 워크플로우와 확산을 포함한 전체 문서 버전 역사를 제공합니다. 이것은 기본으로 들어있으며, 유료 추가 기능이 아닙니다.
APIs: REST, GraphQL, 그리고 그 사이의 모든 것
Contentful APIs
Contentful은 배포 (CDN 캐시됨, 읽기 전용), 미리보기 (캐시 안 됨, 초안 콘텐츠), 관리 (CRUD), 및 이미지용 별도의 API를 제공합니다. 분리는 합리적이지만 여러 API 토큰과 기본 URL을 저글링하고 있음을 의미합니다.
GraphQL API는 견고하지만 깊이 제한 및 깊게 참조된 콘텐츠를 모델링할 때 답답할 수 있는 속도 제한이 있습니다. 복잡한 쿼리는 여러 왕복을 필요로 할 수 있습니다.
Sanity APIs
Sanity의 기본 쿼리 언어는 GROQ이며, HTTP를 통해 서빙됩니다. 그들은 GraphQL API를 제공하지만, 별도로 배포되며 이차 시민으로 느껴집니다. GROQ는 어쨌든 대부분의 Sanity 사용 사례에 더 강력합니다.
진정한 마법은 Sanity의 실시간 리스너 API입니다. 모든 쿼리의 변경 사항을 구독하고 즉시 업데이트를 얻을 수 있습니다. 이것은 정말로 인상적인 라이브 미리보기 경험을 가능하게 합니다.
Payload APIs
Payload는 컬렉션 구성으로부터 REST 및 GraphQL API 모두를 자동 생성합니다. 추가 설정 없음. 컬렉션을 정의하면, 즉시 REST 및 GraphQL 모두에 대한 전체 CRUD 엔드포인트를 얻습니다.
# 자동 생성 GraphQL 쿼리
query {
Posts(where: { status: { equals: published } }, sort: "-publishedAt", limit: 10) {
docs {
id
title
content
author {
name
}
publishedAt
}
totalDocs
hasNextPage
}
}
하지만 Payload가 고유한 장점을 갖는 부분은 여기입니다: Next.js 앱과 같은 프로세스에서 실행되므로, API를 완전히 건너뛰고 Payload의 Local API를 서버 측 데이터 가져오기에 사용할 수 있습니다. 같은 접근 제어, 훅, 및 검증을 가진 직접 데이터베이스 쿼리 — 하지만 HTTP 오버헤드 없음.
// Local API - HTTP 없음, 직렬화 오버헤드 없음
const posts = await payload.find({
collection: 'posts',
where: { status: { equals: 'published' } },
sort: '-publishedAt',
limit: 10,
})
이것은 서버 렌더링 페이지에 대한 거대한 성능 승리입니다. CMS API로의 네트워크 왕복 없음. 함수 호출입니다.
편집 경험
개발자가 CMS를 선택하지만, 편집자는 매일 그것에서 살아갑니다. 그들의 경험을 무시하면 대가를 치릅니다.
Contentful은 가장 성숙한 편집 UI를 가집니다. 깨끗하고 예측 가능하며 비기술 팀이 빠르게 습득할 것입니다. Premium 계획의 스케줄링, 워크플로우, 및 승인 체인은 견고합니다. 하지만 경직될 수 있습니다 — 편집 인터페이스를 맞춤하려면 전체 별도의 React 앱인 Contentful App을 구축해야 합니다.
Sanity Studio는 가장 맞춤 가능합니다. 완전히 맞춤 편집 경험을 구축할 수 있습니다. 하지만 그 맞춤은 대가가 따릅니다: 기본적으로, Sanity Studio는 비기술 편집자에게 압도적으로 느껴질 수 있습니다. 구조 빌더는 잘 구성하기 위해 개발자 시간이 필요합니다.
Payload의 관리 패널은 3.0에서 극적으로 개선되었습니다. 깨끗하고 빠르며 (Next.js 앱입니다), 맞춤 컴포넌트, 조건부 필드 렌더링, 그리고 라이브 미리보기를 지원합니다. Contentful의 UI만큼 광택이 나지는 않지만, Contentful보다 더 맞춤 가능하며 노력이 덜 들고, Sanity보다 더 접근 가능합니다.
자체 호스팅 vs SaaS: 실제 장단점
이것은 철학적 분열입니다. Contentful과 Sanity는 SaaS 플랫폼입니다. 인프라를 관리하지 않습니다; 그들에게 지불합니다. Payload는 기본적으로 자체 호스팅됩니다.
SaaS 주장: 운영 오버헤드 감소, 기본으로 CDN, 관리형 가동 시간. 이것들은 실제 이점이며, 특히 DevOps 경험이 없는 작은 팀의 경우입니다.
자체 호스팅 주장: 데이터 소유권, 벤더 종속성 없음, 예측 가능한 비용, 규제 준수 (GDPR, HIPAA, 데이터 상주), 그리고 모든 것을 맞춤할 자유.
헤드리스 CMS 개발을 하는 기관으로서 우리의 경우, 자체 호스팅은 2026년 대부분 클라이언트에 대한 권장 사항이 되었습니다. 인프라 도구는 Payload 앱을 Railway, Vercel, 또는 AWS에 배포하는 것이 간단할 정도로 성숙했습니다. Docker는 재현 가능하게 합니다. 그리고 비용 절감은 SaaS CMS를 통해 해마다 복합됩니다.
운영 부담에 대해 우려하면, Payload Cloud가 오픈소스 이점을 유지하면서 호스팅을 처리합니다.
성능 및 확장성
Contentful의 CDN 지원 배포 API는 빠릅니다. 엣지 노드로부터의 일반적인 응답 시간은 50~100ms입니다. 10년 동안 규모로 전투 테스트되었습니다.
Sanity의 CDN API는 캐시된 콘텐츠에 대해 유사한 성능을 배포하며, 그들의 실시간 계층이 라이브 쿼리에 20~30ms를 추가합니다.
Payload의 성능은 인프라에 따라 다르지만, 여기서 문제는 — Next.js 서버 컴포넌트와 함께 Local API를 사용할 때, 로컬 데이터베이스에 함수 호출을 하고 있습니다. 응답 시간은 10ms 미만일 수 있습니다. 프론트에 CDN을 추가하면 (Vercel, CloudFront 등) Next.js 출력이 SaaS 옵션과 일치하거나 이깁니다.
Astro 기반 프로젝트의 경우, 세 가지 모두 API 소스로 잘 작동하지만, Payload의 REST 및 GraphQL API는 Astro의 데이터 가져오기 계층에서 소비하기에 특히 간단합니다.
에코시스템 및 커뮤니티
Contentful은 가장 큰 엔터프라이즈 에코시스템을 가집니다. 많은 통합, 마켓플레이스의 앱, 그리고 광범위한 기관 지원.
Sanity는 열정적인 개발자 커뮤니티, 우수한 문서, 그리고 성장하는 플러그인 에코시스템을 가합니다. 그들의 커뮤니티 Slack은 정말로 도움이 됩니다.
Payload는 세 가지 중 가장 빠르게 성장하는 커뮤니티를 가집니다. 그들의 Discord는 극도로 활발하며, 핵심 팀이 정기적으로 질문에 응답합니다. 플러그인 에코시스템은 더 작지만 빠르게 성장하고 있습니다 — 그리고 Payload가 단지 Node.js/TypeScript이므로, 필요한 모든 것을 npm 설치할 수 있습니다.
Payload의 GitHub는 2026년 초 현재 30K+ 스타를 가지고 있으며 궤도가 가파릅니다.
결론
직설적으로: Payload는 2026년 대부분의 프로젝트에 최고의 헤드리스 CMS입니다.
이유는 여기입니다:
- 규모별로 라이선스 수수료 없음. 50명 편집자 엔터프라이즈 팀도 Payload에 한 푼을 지불하지 않습니다.
- TypeScript 네이티브 구성은 콘텐츠 모델이 코드, 버전 제어, 타입 안전, 및 PR에서 검토 가능함을 의미합니다.
- Local API + Next.js 통합은 SaaS CMS가 물리적으로 일치할 수 없는 성능을 제공합니다.
- 데이터 소유권 — 콘텐츠는 누군가 다른 고유 저장소가 아닌 데이터베이스에 있습니다.
- 벤더 종속성 없음 — 떠나고 싶으면, 데이터는 Postgres 또는 MongoDB에 있습니다. 그냥 쿼리하세요.
다른 것들이 이기는 시나리오가 있습니다:
- Contentful을 선택하세요 엔터프라이즈 콘텐츠 팀의 설정된 Contentful 워크플로우가 필요하고, 광택 있고 영 운영 편집 경험을 원하며, 예산이 있는 대규모 엔터프라이즈인 경우.
- Sanity를 선택하세요 실시간 협업이 워크플로우에 대해 중요하면, Portable Text의 비교할 수 없는 구조화된 리치 텍스트가 필요하면, 또는 고도로 맞춤 스튜디오 경험을 구축하는 경우.
- Payload를 선택하세요 다른 모든 것. 스타트업, 기관, 중견 기업, 개발자 주도 팀, 데이터 제어가 필요한 규제 산업, 그리고 깜짝 청구서로 잠들고 싶지 않은 누구나.
새로운 프로젝트에 대해 헤드리스 CMS를 평가 중이고 구체성을 통해 대화하고 싶다면, 우리가 도와 도와 도와를 즐깁니다. 우리는 프로덕션 Payload, Sanity, 및 Contentful 프로젝트를 출시했으며 실제 요구 사항 및 예산에 따라 정직한 조언을 줄 수 있습니다.
FAQ
Payload CMS는 정말 무료인가요?
네. Payload는 MIT 라이선스 오픈소스 소프트웨어입니다. 라이선스 수수료가 없고, 사용자당 수수료가 없으며, Payload 자체로부터의 API 호출 제한이 없습니다. 유일한 비용은 호스팅 인프라 (서버 및 데이터베이스)이며, 일반적으로 규모에 따라 월 $20~$500입니다. Payload Cloud는 인프라를 관리하지 않으려면 유료 호스팅 옵션으로 사용 가능합니다.
Sanity를 자체 호스팅할 수 있나요?
부분적으로. Sanity Studio (관리 UI)는 어디든 배포할 수 있는 React 앱입니다. 하지만 콘텐츠 레이크 — 실제 데이터가 있는 곳 — 는 Sanity가 관리하는 호스팅 서비스입니다. 데이터 계층을 자체 호스팅할 수 없습니다. 이것은 콘텐츠가 항상 Sanity의 인프라에 있음을 의미하며, 데이터 상주 또는 준수 요구 사항에 우려가 될 수 있습니다.
어떤 헤드리스 CMS가 가장 좋은 GraphQL 지원을 가지나요?
Contentful과 Payload는 모두 강한 GraphQL API를 제공합니다. Payload는 컬렉션 구성으로부터 GraphQL 스키마를 자동 생성하며, 수동 스키마 유지 관리가 없음을 의미합니다. Contentful의 GraphQL API는 성숙하고 잘 문서화되어 있습니다. Sanity는 GraphQL을 제공하지만 기본 쿼리 언어로 GROQ를 선호하며, 그들의 GraphQL 구현은 모든 GROQ 기능을 지원하지 않습니다.
Contentful이 2026년에 가치가 있나요?
복잡한 콘텐츠 작업, 기존 Contentful 워크플로우, 그리고 영 운영 SaaS 접근 방식을 값지게 하는 팀을 가진 대규모 엔터프라이즈의 경우 — 네, 그럴 수 있습니다. 작은~중간 규모 팀의 경우, 비용은 Payload가 비교 가능한 (그리고 어떤 측면에서 우월한) 기능을 가격의 일부로 제공할 때 정당화하기 점점 더 어려워집니다. 우리는 구체적으로 비용 때문에 Contentful에서 떠난 여러 클라이언트를 봤습니다.
Payload CMS는 이미지 최적화를 어떻게 처리하나요?
Payload는 기본으로 이미지 크기 조정 및 초점 지점 자르기를 가집니다. 이미지를 업로드할 때, Payload는 구성에 따라 자동으로 여러 크기를 생성할 수 있습니다. Next.js가 있는 Payload 3.0에서, 당신은 이것을 다음과 결합할 수 있습니다 이것을 반응형, WebP/AVIF 서빙을 위해 최적화를 이미징합니다. Contentful의 이미지 API만큼 기능 풍부하지 않습니다 (URL 기반 변환을 제공합니다), 하지만 90%의 사용 사례를 타사 서비스 없이 다룹니다.
Contentful에서 Payload로 마이그레이션할 수 있나요?
네. Payload는 표준 데이터베이스를 사용하므로 (Postgres 또는 MongoDB), 마이그레이션은 Management API를 통해 Contentful 콘텐츠를 내보내고 Payload 컬렉션으로 가져오는 것입니다. Contentful 콘텐츠 유형에서 Payload 컬렉션으로의 콘텐츠 모델 변환은 일반적으로 간단합니다. 우리는 이러한 마이그레이션의 여러 개를 처리했습니다 — 가장 까다로운 부분은 구조화된 데이터가 아닌 일반적으로 리치 텍스트 변환입니다.
어떤 CMS가 비기술 편집자에게 최고인가요?
Contentful은 비기술 사용자를 위해 가장 직관적인 기본 편집 경험을 가집니다. Payload의 관리 패널은 가깝고 개선 중입니다. Sanity Studio는 개발자가 맞춤을 위해 시간을 투자하면 세 가지 중 최고일 수 있지만, 기본 경험은 편집자에게 더 가파른 학습 곡선을 가집니다.
Payload CMS가 Next.js 이외의 프레임워크와 함께 작동하나요?
절대적으로. Payload 3.0이 Next.js를 관리 UI 프레임워크로 사용하는 동안, REST 및 GraphQL API는 모든 프론트엔드에서 작동합니다 — Astro, Nuxt, SvelteKit, Remix, 또는 모바일 앱까지. Local API는 Next.js 특정이지만, 외부 API는 프레임워크 종속성이 없습니다. 우리는 프로젝트 요구 사항에 따라 Next.js와 Astro 모두와 Payload를 정기적으로 쌍으로 합니다.