Contentful vs Sanity vs Payload: Which CMS Survives Real Clients?
당신의 클라이언트가 3월에 Contentful을 승인합니다. 8월이 되면 개발팀은 이를 제거할 생각에 Slack에서 논의하고 있습니다. 저는 2022년 이후 40개 이상의 프로젝트에서 Contentful, Sanity, Payload로 프로덕션 빌드를 운영했습니다 — 어떤 것들은 greenfield Next.js 앱이었고, 다른 것들은 테이프와 기도로 버티고 있는 WordPress 설치에서의 복구였습니다. 각 CMS는 다른 방식으로, 비싼 방식으로 실패했습니다. Contentful의 API 제한은 화요일 오전 6시 제품 출시를 막았습니다. Sanity의 GROQ 학습 곡선은 마케팅팀을 두 스프린트 동안 정체시켰습니다. Payload의 셀프 호스팅 비용은 "오픈 소스"가 "무료"를 의미한다고 생각했던 씨앗 단계의 창립자를 놀라게 했습니다. 한 가지 선택은 다른 것들보다 일관되게 오전 2시 Slack 핑을 덜 유발했습니다.
이 글은 실제로 뭔가를 구축할 때 중요한 차원들을 중심으로 Contentful, Sanity, Payload CMS를 분석합니다: 규모 시 가격, 현장의 개발자 경험, 컨텐츠 모델링 유연성, API 설계, 그리고 당신의 컨텐츠팀이 좋아하거나 싫어할 일상적인 편집 워크플로우입니다.
목차
- 30초 개요
- 가격 분석: 실제로 지불할 비용
- 개발자 경험
- 컨텐츠 모델링
- API: REST, GraphQL, 그리고 그 사이의 모든 것
- 편집 경험
- 셀프 호스팅 vs SaaS: 실제 트레이드오프
- 성능 및 확장성
- 에코시스템 및 커뮤니티
- 결론
- FAQ

30초 개요
Contentful은 기존 진영입니다. 2013년부터 존재해왔으며 엔터프라이즈급 사이트를 규모 있게 운영합니다. 광택이 나고 신뢰할 수 있으며 비싼 편입니다.
Sanity는 실시간, 구조화된 컨텐츠 접근 방식과 커스터마이징 가능한 스튜디오를 갖춘 개발자의 즐겨찾기입니다. 강력하지만 학습 곡선이 있고 가격 모델이 놀랄 수 있습니다.
Payload는 조용히 진지한 경쟁자가 된 신생 기업입니다. 오픈 소스이고 기본적으로 셀프 호스팅 가능하며(현재 클라우드 옵션도 있음) TypeScript로 작성되었고 라이센스 수수료가 없습니다. 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이며, 평가 중에 사람들이 저평가하는 것의 #1입니다.
Contentful 가격 (2026)
Contentful의 무료 티어는 1개 공간, 5명의 사용자, 25K API 호출을 제공합니다. 블로그에는 괜찮습니다.
Basic 플랜은 $300/월부터 시작하며 더 많은 환경과 역할을 제공합니다. Premium 플랜 — 대부분의 진지한 팀에 필요한 — 은 맞춤형 가격이지만 일반적으로 중간 규모 조직의 경우 약 $2,000-$3,000/월부터 시작합니다. 저는 연간 $80K 이상의 엔터프라이즈 계약을 봤습니다.
함정은 API 호출 초과입니다. Contentful은 Content Delivery API 호출, Content Management API 호출, 자산 대역폭에 대해 별도로 청구합니다. 월간 10M+ 페이지 뷰를 수행하는 높은 트래픽 사이트에서 포함된 할당량을 쉽게 초과할 수 있습니다. 제가 작업한 한 클라이언트는 바이럴 제품 출시 후 월간 청구서가 $2,500에서 $4,800로 뛰었습니다. 이는 예상하지 못한 CDN 및 API 초과 요금 때문이었습니다.
Sanity 가격 (2026)
Sanity는 "성장에 따른 결제"라고 부르는 사용량 기반 모델을 사용합니다. 무료 플랜에는 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 query - powerful but unique syntax
*[_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 앱이기 때문에 CMS 코드와 함께 커스텀 페이지, API 경로 또는 서버 액션을 추가할 수 있습니다.
Next.js 개발을 수행하는 팀의 경우, Payload 3.0은 DX 관점에서 내기할 가치가 없습니다. CMS와 프론트엔드가 동일한 프로젝트에 있습니다. 동일한 배포. 동일한 repo.

컨텐츠 모델링
컨텐츠 모델링은 당신이 성공을 위해 자신을 설정하거나 몇 년 동안 당신과 함께 살 악몽을 만드는 곳입니다.
Contentful의 접근 방식
Contentful은 전통적인 컨텐츠 유형 → 항목 모델을 사용합니다. 필드가 있는 컨텐츠 유형을 정의하면 편집자가 항목을 만듭니다. 컨텐츠 유형 간의 참조는 명시적입니다. 간단한 컨텐츠 구조에는 잘 작동합니다.
제한 사항은 풍부한 텍스트로 표시됩니다. Contentful의 리치 텍스트 필드는 렌더링 유연성에 좋지만 중첩 컴포넌트를 가진 복잡한 페이지 레이아웃 모델링은 포함된 항목 및 참조의 창의적인 사용을 요구합니다. 번거로워질 수 있습니다.
Contentful은 Basic 플랜에서 50개의 컨텐츠 유형 및 Premium에서 100개 이상을 지원합니다. 많은 컨텐츠 유형이 있는 대규모 사이트의 경우 이는 제약이 될 수 있습니다.
Sanity의 접근 방식
Sanity의 컨텐츠 모델링은 논쟁의 여지없이 3개 중 가장 유연합니다. 그들의 블록 컨텐츠(Portable Text)는 리치 텍스트용 열린 사양입니다. 구조화된 데이터로 컨텐츠를 저장합니다. 커스텀 블록 유형, 인라인 객체, 주석을 정의할 수 있습니다.
스키마 시스템은 깊게 중첩된 객체 유형, 조건부 필드, 커스텀 검증을 지원합니다. 저는 Contentful에서 고통스러울 수 있는 Sanity에서 진정으로 복잡한 컨텐츠 모델을 구축했습니다.
// Sanity schema with Portable Text customization
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의 블록 필드는 특히 페이지 빌드에 강력합니다. 각각의 필드를 가진 블록 유형을 정의하면 편집자는 이 블록에서 페이지를 구성할 수 있습니다. 레이아웃 필드 유형 및 조건부 로직과 결합하면 거의 모든 것을 모델링할 수 있습니다.
Payload 3.0의 Lexical 리치 텍스트 편집기는 눈에 띄는 것입니다. 이는 Slate (괜찮았지만 오래된)를 커스텀 노드, 인라인 블록, 서버 측 렌더링 지원을 즉시 지원하는 현대 편집기로 교체했습니다. React 컴포넌트를 리치 텍스트 컨텐츠에 직접 포함할 수 있습니다.
버전 관리 시스템도 언급할 가치가 있습니다. Payload는 초안/게시 워크플로우 및 전체 문서 버전 기록에 difing을 제공합니다. 이는 기본 제공되며 유료 추가가 아닙니다.
API: REST, GraphQL, 그리고 그 사이의 모든 것
Contentful API
Contentful은 배달(CDN 캐시, 읽기 전용), 미리 보기(캐시되지 않음, 초안 컨텐츠), 관리(CRUD), 이미지용 별도 API를 제공합니다. 분리는 합리적이지만 여러 API 토큰과 기본 URL을 저글링하고 있다는 의미입니다.
그들의 GraphQL API는 견고하지만 깊이 제한과 깊게 참조된 컨텐츠를 모델링할 때 좌절할 수 있는 속도 제한이 있습니다. 복잡한 쿼리는 여러 라운드 트립을 요구할 수 있습니다.
Sanity API
Sanity의 기본 쿼리 언어는 HTTP를 통해 제공되는 GROQ입니다. 그들은 GraphQL API를 제공하지만 별도로 배포되며 2등급 시민처럼 느껴집니다. GROQ는 대부분의 Sanity 사용 사례에 어쨌든 더 강력합니다.
진짜 마법은 Sanity의 실시간 리스너 API입니다. 모든 쿼리의 변경 사항을 구독하고 즉시 업데이트를 받을 수 있습니다. 이것은 정말로 인상적인 라이브 미리 보기 경험을 가능하게 합니다.
Payload API
Payload는 컬렉션 구성에서 REST 및 GraphQL API를 자동 생성합니다. 추가 설정이 없습니다. 컬렉션을 정의하면 두 REST와 GraphQL 모두에 대한 전체 CRUD 엔드포인트를 즉시 얻습니다.
# Auto-generated GraphQL query
query {
Posts(where: { status: { equals: published } }, sort: "-publishedAt", limit: 10) {
docs {
id
title
content
author {
name
}
publishedAt
}
totalDocs
hasNextPage
}
}
하지만 Payload가 고유한 이점을 가진 곳: Payload가 Next.js 앱과 동일한 프로세스에서 실행되기 때문에 API를 완전히 건너뛰고 Payload의 로컬 API를 서버 측 데이터 가져오기에 사용할 수 있습니다. 동일한 접근 제어, 후크, 검증을 포함한 직접 데이터베이스 쿼리 — 하지만 0 HTTP 오버헤드로.
// Local API - no HTTP, no serialization overhead
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, 데이터 거주), 모든 것을 커스터마이징할 자유.
headless CMS 개발을 수행하는 에이전시의 경우 2026년 대부분의 클라이언트에 대한 권장 사항은 셀프 호스팅이 되었습니다. 인프라 도구는 Railway, Vercel 또는 AWS에 Payload 앱을 배포하는 것이 간단한 지점까지 성숙했습니다. Docker가 이를 재현 가능하게 만듭니다. SaaS CMS 비용은 해마다 누적됩니다.
운영 부담에 대해 걱정하는 경우 Payload Cloud는 오픈 소스 이점을 유지하면서 호스팅을 처리합니다.
성능 및 확장성
Contentful의 CDN 백업 배달 API는 빠릅니다. 엣지 노드에서의 일반적인 응답 시간은 50-100ms입니다. 10년 동안 규모로 전투 테스트되었습니다.
Sanity의 CDN API는 캐시된 컨텐츠에 유사한 성능을 제공하며 실시간 레이어는 라이브 쿼리에 대해 20-30ms를 추가합니다.
Payload의 성능은 인프라에 따라 달라지지만 여기서 중요합니다 — Next.js 서버 컴포넌트와 함께 로컬 API를 사용할 때 로컬 데이터베이스에 함수 호출을 만드는 것입니다. 응답 시간은 10ms 미만일 수 있습니다. Next.js 출력 앞에 CDN을 추가합니다 (Vercel, CloudFront 등) 그리고 당신은 SaaS 옵션과 일치하거나 이기고 있습니다.
Astro 기반 프로젝트의 경우 3개 모두 API 소스로도 작동하지만 Payload의 REST 및 GraphQL API는 Astro의 데이터 가져오기 레이어에서 소비하기에 특히 간단합니다.
에코시스템 및 커뮤니티
Contentful은 가장 큰 엔터프라이즈 에코시스템을 가지고 있습니다. 수많은 통합, 마켓플레이스의 앱, 광범위한 에이전시 지원.
Sanity는 열정적인 개발자 커뮤니티, 우수한 문서, 성장하는 플러그인 에코시스템을 가집니다. 그들의 커뮤니티 Slack은 정말 도움이 됩니다.
Payload는 3개 중 가장 빠르게 성장하는 커뮤니티를 가지고 있습니다. 그들의 Discord는 매우 활동적이며 핵심 팀이 정기적으로 질문에 응답합니다. 플러그인 에코시스템은 더 작지만 빠르게 성장하고 있습니다 — 그리고 Payload는 단지 Node.js/TypeScript이기 때문에 필요한 모든 것을 npm install할 수 있습니다.
Payload의 GitHub는 2026년 초 현재 30K 이상의 별을 가지고 있으며 궤도는 가파릅니다.
결론
직설적입니다: Payload는 2026년 대부분의 프로젝트에 최고의 headless CMS입니다.
이유:
- 규모에 상관없이 0 라이센스 수수료. 50명 편집자 엔터프라이즈 팀은 Payload에 한 푼도 지불하지 않습니다.
- TypeScript 네이티브 구성은 컨텐츠 모델이 코드이고, 버전 제어되고, 유형 안전하며, PR에서 검토 가능함을 의미합니다.
- 로컬 API + Next.js 통합은 SaaS CMS가 물리적으로 일치할 수 없는 성능을 제공합니다.
- 데이터 소유권 — 컨텐츠가 당신의 데이터베이스에 있고, 다른 사람의 소유권 저장소가 아닙니다.
- 공급 업체 잠금 없음 — 벗어나고 싶으면 데이터는 Postgres 또는 MongoDB에 있습니다. 그냥 쿼리합니다.
다른 사람들이 우승하는 시나리오가 있습니다:
- Contentful을 선택합니다 큰 엔터프라이즈이고 설정 컨텐츠 팀이 광택 있는 0 운영 편집 경험이 필요한 경우이고 예산이 있습니다.
- Sanity를 선택합니다 실시간 협업이 워크플로우에 중요한 경우, Portable Text의 비교할 수 없는 구조화된 리치 텍스트가 필요한 경우, 또는 수정된 스튜디오 경험을 구축하는 경우입니다.
- Payload를 선택합니다 다른 모든 것. 스타트업, 에이전시, 중견 기업, 개발자 중심 팀, 데이터 제어가 필요한 규제 산업, 놀라운 청구서를 원하지 않는 누구든.
새로운 프로젝트에 headless CMS를 평가하고 구체적인 사항을 논의하고 싶으신 경우 저희가 도움을 드릴 수 있습니다. 우리는 프로덕션 Payload, Sanity, Contentful 프로젝트를 운영했으며 실제 요구 사항 및 예산을 기반으로 정직한 조언을 줄 수 있습니다.
FAQ
Payload CMS는 정말 무료인가요?
Netflix. Payload는 MIT 라이선스 오픈 소스 소프트웨어입니다. 라이센스 수수료, 사용자당 요금, Payload 자체의 API 호출 제한이 없습니다. 유일한 비용은 호스팅 인프라(서버 및 데이터베이스)이며, 이는 일반적으로 규모에 따라 $20-$500/월을 실행합니다. Payload Cloud는 인프라를 관리하지 않으려는 경우 유료 호스팅 옵션으로 제공됩니다.
Sanity는 셀프 호스팅될 수 있나요?
부분적으로. Sanity Studio (관리 UI)는 어디든지 배포할 수 있는 React 앱입니다. 하지만 컨텐츠 호수 — 실제 데이터가 있는 곳 — Sanity가 관리하는 호스팅 서비스입니다. 데이터 레이어를 셀프 호스트할 수 없습니다. 이는 컨텐츠가 항상 Sanity의 인프라에 있다는 의미이며, 이는 데이터 거주 또는 준수 요구 사항에 대한 관심사일 수 있습니다.
어느 headless CMS가 최고의 GraphQL 지원을 합니까?
Contentful과 Payload 모두 강한 GraphQL API를 제공합니다. Payload는 컬렉션 구성에서 직접 GraphQL 스키마를 자동 생성하며, 0 수동 스키마 유지 보수를 의미합니다. Contentful의 GraphQL API는 성숙하고 잘 문서화되어 있습니다. Sanity는 GraphQL을 제공하지만 기본 쿼리 언어로 GROQ를 선호하며, 그들의 GraphQL 구현은 모든 GROQ 기능을 지원하지는 않습니다.
Contentful은 2026년에 가격 가치가 있습니까?
복잡한 컨텐츠 작업, 기존 Contentful 워크플로우, 번거로운 SaaS 접근 방식을 소중히 생각하는 팀이 있는 대규모 기업의 경우 — 네, 그럴 수 있습니다. 소규모 ~ 중간 규모 팀의 경우 비용은 점점 더 Payload가 분수의 가격으로 비교 가능한 (그리고 어떤 면에서는 우월한) 기능을 제공할 때 정당화하기가 어려워집니다. 우리는 특히 비용 때문에 Contentful에서 마이그레이션된 여러 클라이언트를 봤습니다.
Payload CMS는 이미지 최적화를 어떻게 처리합니까?
Payload는 기본 제공 이미지 크기 조정 및 초점 자르기가 있습니다. 이미지를 업로드할 때 Payload는 구성을 기반으로 여러 크기를 자동으로 생성할 수 있습니다. Payload 3.0과 Next.js에서 Next.js 이미지 최적화와 이를 결합하여 반응형, WebP/AVIF 제공이 가능합니다. Contentful의 이미지 API만큼 기능이 풍부하지는 않습니다 (URL 기반 변환을 제공하는), 하지만 그것은 타사 서비스 없이 90%의 사용 사례를 커버합니다.
Contentful에서 Payload로 마이그레이션할 수 있습니까?
Netflix. Payload가 표준 데이터베이스(Postgres 또는 MongoDB)를 사용하므로 마이그레이션은 Management API를 통해 Contentful 컨텐츠를 내보내고 Payload 컬렉션에 가져오는 것과 관련이 있습니다. Contentful 컨텐츠 유형에서 Payload 컬렉션으로의 컨텐츠 모델 변환은 일반적으로 간단합니다. 우리는 이들 마이그레이션 중 몇 가지를 처리했습니다 — 가장 까다로운 부분은 일반적으로 구조화된 데이터가 아닌 리치 텍스트 변환입니다.
어느 CMS가 비기술 편집자에게 가장 좋습니까?
Contentful은 비기술 사용자를 위한 가장 직관적인 즉시 편집 경험을 가지고 있습니다. Payload의 관리 패널은 가깝고 있으며 빠르게 개선되고 있습니다. Sanity Studio는 개발자가 커스터마이징을 위해 시간을 투자하면 3개 모두 중 가장 좋을 수 있지만 기본 경험은 편집자를 위해 더 가파른 학습 곡선을 가집니다.
Payload CMS는 Next.js 이외의 프레임워크로 작동합니까?
절대적으로. Payload 3.0이 관리 UI 프레임워크로 Next.js를 사용하는 동안 REST 및 GraphQL API는 모든 프론트엔드 — Astro, Nuxt, SvelteKit, Remix 또는 모바일 앱에서도 작동합니다. 로컬 API는 Next.js 특정이지만 외부 API는 프레임워크 종속성이 없습니다. 프로젝트 요구 사항에 따라 Payload를 Next.js 및 Astro와 쌍으로 정기적으로 사용합니다.