Payload CMS 2026: 피그마가 인수한 이유와 도입 여부

Payload CMS 2026: 피그마가 인수한 이유와 도입 여부

Payload는 별도의 컨테이너나 옆에 있는 서비스가 아니라, literally 여러분의 Next.js 앱 내부(/app 폴더 안)에 존재하는 오픈소스 TypeScript 기반 헤드리스 CMS입니다. 좌석당 요금을 청구하거나 독점 API 뒤에 콘텐츠를 가두는 호스팅형 CMS 플랫폼 때문에 곤란을 겪은 적이 있다면, Payload는 진지하게 검토해 볼 만한 가치가 있습니다.

하지만 2026년에는 예상치 못한 변수가 등장했습니다. 피그마(Figma)가 Payload를 인수했고, Payload Cloud는 신규 가입을 중단했으며, 개발자들은 이제 호스팅 문제를 스스로 해결해야 하게 되었습니다. 이 가이드는 첫 설치부터 프로덕션 배포까지 모든 것을 다루며, 최신 Payload 3 코드 예제와 Payload가 빛나는 부분과 그렇지 않은 부분에 대한 솔직한 평가를 제공합니다.

Payload CMS란 무엇인가? (그리고 개발자들이 사랑하는 이유)

Payload는 Next.js 앱 내부에서 실행되는 오픈소스 TypeScript 기반 헤드리스 CMS이자 애플리케이션 프레임워크입니다. 호스팅형 CMS 플랫폼과 달리 Payload는 코드 우선(code-first) 설정, 세 가지 내장 API(REST, GraphQL, Local), 그리고 완전히 커스터마이징 가능한 관리자 패널을 단일 코드베이스에서 제공합니다. 공식 Payload 문서에 따르면, 이는 "현대적인 백엔드를 구축하는 가장 좋은 방법"으로 설계되었습니다.

이 프로젝트는 2021년 Node.js/Express CMS로 시작되었습니다. 2023년에는 향상된 TypeScript 지원을 갖춘 Payload 2가 출시되었습니다. 이후 Payload 3는 게임의 규칙을 완전히 바꾸었습니다. CMS가 Next.js 애플리케이션 내부로 이동한 것입니다. 별도의 서버 프로세스도, 별도의 배포도 필요 없습니다. CMS와 프론트엔드가 동일한 Next.js 런타임, 동일한 라우트, 동일한 빌드 파이프라인을 공유합니다.

이는 Sanity, Strapi 또는 Contentful이 제공하는 것과 근본적으로 다른 아키텍처입니다. 그리고 이는 콘텐츠를 구축하고 배포하며 사고하는 방식에 실질적인 영향을 미칩니다.

코드 우선(Code-First) 철학

대부분의 CMS 플랫폼은 콘텐츠 모델을 정의하기 위한 GUI를 제공합니다. "필드 추가"를 클릭하고 "텍스트"를 선택한 후 "title"이라고 이름을 짓습니다. Payload는 이를 뒤집습니다. 모든 것을 TypeScript 파일로 정의합니다. 스키마가 곧 코드입니다. 버전 관리 시스템에 저장되며, 풀 리퀘스트(PR)에서 검토할 수 있습니다.

이는 환경 간 스키마 불일치를 방지하고, "누군가 스테이징 환경에서 콘텐츠 모델을 변경했는데 무슨 일이 일어났는지 아무도 모른다"는 식의 놀라운 상황을 예방합니다. 콘텐츠 모델이 클라우드 대시보드에 존재하는 팀에서 작업해 본 적이 있다면, 이것이 왜 중요한지 정확히 알 것입니다.

Payload 3 아키텍처, Next.js 네이티브

Payload 3는 Next.js 앱 옆에서 실행되지 않습니다. 그 안에서 실행됩니다. 관리자 패널은 /app/(payload)/admin에 위치하고, API 라우트는 /app/(payload)/api에 있으며, 프론트엔드 페이지는 동일한 프로젝트 내에 공존합니다. 이전에 Next.js를 프로덕션에서 사용해 본 적이 있다면 매우 익숙하게 느낄 것입니다.

Payload를 차별화하는 주요 기능

Payload의 standout 기능으로는 콘텐츠 모델링을 위한 컬렉션(Collections), 트리플 API 레이어(REST, GraphQL, Local), 필드 단위 세분성을 갖춘 역할 기반 접근 제어(RBAC), 내장 인증, Lexical 리치 텍스트 에디터, 그리고 시각적 편집을 위한 라이브 미리보기 등이 있습니다. 이러한 기능이 실제 코드베이스에 어떤 의미를 갖는지 살펴보겠습니다.

컬렉션, 글로벌 및 필드

컬렉션은 Payload의 핵심 콘텐츠 모델링 기본 요소입니다. 데이터베이스 테이블과 유사하지만 완전히 TypeScript로 정의된다고 생각하면 됩니다. 각 컬렉션은 단일 구성 파일에서 생성된 고유한 REST 및 GraphQL 엔드포인트, 고유한 관리자 패널 뷰, 그리고 고유한 접근 제어 규칙을 가집니다.

// collections/Posts.ts
import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'updatedAt'],
  },
  versions: {
    drafts: true,
    maxPerDoc: 10,
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'content', type: 'richText' },
    {
      name: 'status',
      type: 'select',
      defaultValue: 'draft',
      options: ['draft', 'published', 'archived'],
    },
    { name: 'author', type: 'relationship', relationTo: 'users' },
    { name: 'publishedAt', type: 'date' },
  ],
}

글로벌(Global)도 비슷하게 작동하지만 싱글톤 데이터(사이트 설정, 탐색 구성, 푸터 콘텐츠 등)용입니다. 컬렉션 목록 뷰는 없으며, 편집 가능한 단일 문서만 존재합니다.

트리플 API 레이어 (REST, GraphQL, Local)

이 부분이 Payload가 다른 오픈소스 CMS들을 압도하는 지점입니다. 서로 다른 컨텍스트에 최적화된 세 가지 콘텐츠 조회 방식을 제공합니다.

• 로컬 API(Local API): HTTP 오버헤드가 없는 서버 사이드 쿼리. Next.js 서버 컴포넌트에서 CMS를 직접 호출합니다. 네트워크 왕복 시간도, 직렬화 비용도 없습니다. 테스트 결과, 동일 서버에서의 REST 호출 대비 페이지 로드 시간이 약 40ms 단축되었습니다.
• REST API: 외부 클라이언트, 모바일 앱 또는 서드파티 통합을 위한 자동 생성 엔드포인트.
• GraphQL API: 데이터 요청을 정밀하게 shaping해야 하는 프론트엔드를 위한 유연한 쿼리.

Next.js 서버 컴포넌트에서 로컬 API 호출이 어떻게 이루어지는지 확인해 보세요.

// app/(frontend)/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })

  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug }, status: { equals: 'published' } },
    depth: 2,
  })

  return <article>{/* render post.docs[0] */}</article>
}

fetch 호출 없음. API URL 없음. 인증 토큰 없음. 서버 컴포넌트에서 데이터베이스를 직접 쿼리하며, TypeScript는 응답에 대한 완전한 타입 안전성을 제공합니다. 이것보다 더 좋을 수는 없습니다.

접근 제어 및 인증

Payload의 접근 제어 시스템은 함수 기반입니다. 대시보드에서 권한을 구성하는 대신, true 또는 false를 반환하는 TypeScript 함수를 작성합니다. 필드 수준, 컬렉션 수준 또는 작업 수준에서 세분성을 결정할 수 있습니다.

// Example: Only published posts are publicly readable
access: {
  read: ({ req }) => {
    if (req.user) return true // Logged-in users see everything
    return { status: { equals: 'published' } } // Public sees only published
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

인증 기능도 내장되어 있습니다. JWT 토큰, 리프레시 토큰, 비밀번호 찾기 흐름, 이메일 검증 등이 포함됩니다. 특별히 원하지 않는 한 Clerk나 NextAuth가 필요하지 않습니다. 많은 프로젝트에서 Payload의 인증 기능만으로 충분합니다.

Lexical 리치 텍스트 에디터

Payload는 Meta의 리치 텍스트 프레임워크인 Lexical을 사용합니다(Draft.js를 만든 팀이지만 더 개선되었습니다). 사용자 정의 블록, 인라인 요소 및 슬래시 명령을 추가할 수 있습니다. 에디터는 HTML이나 React 컴포넌트로 변환할 수 있는 구조화된 JSON 형식으로 직렬화됩니다.

이는 중요합니다. 대부분의 CMS 리치 텍스트 에디터는 너무 기본적이거나(일반 텍스트 영역), 너무 불투명하기 때문입니다(WYSIWYG가 예측 불가능한 HTML을 생성). Lexical은 사용자가 완전히 통제할 수 있는 구조적이고 예측 가능한 출력을 제공합니다.

라이브 미리보기 및 시각적 편집

Payload 3에는 라이브 미리보기 기능이 포함되어 있습니다. 편집자는 관리자 패널과 나란히 실제 프론트엔드에서 콘텐츠 변경 사항이 실시간으로 반영되는 것을 볼 수 있습니다. 시각적 편집 기능이 전혀 없는 Strapi와 비교할 때 이는 상당한 격차를 메우는 기능입니다.

Sanity Studio의 실시간 협업 기능만큼 완벽하지는 않습니다. Sanity의 시각적 편집은 정말 최고 수준입니다. 하지만 Sanity의 좌석당 가격 정책을 지불하지 않고 "충분히 좋은" 시각적 미리보기가 필요한 팀이라면 Payload의 구현체로 충분히 목적을 달성할 수 있습니다.

버전 관리, 초안 및 자동 저장

Payload에는 내장된 초안 관리, 버전 기록 및 자동 저장 기능이 포함되어 있는데, 상위 순위 Payload 가이드 중 어느 것도 언급하지 않는 기능들입니다. 컬렉션별로 버전 관리를 활성화할 수 있으며(위의 Posts 예제에서 versions: { drafts: true }로 수행), 최대 버전 수를 설정하고 관리자 UI에서 수정 사항을 비교할 수 있습니다.

편집 팀에게는 "실수로 초안을 게시했다"는 재난이 사라진다는 의미입니다. 개발자에게는 별도의 버전 관리 시스템을 추가로 붙일 필요가 없다는 뜻입니다.

Payload CMS 시작하기

새로운 Payload 프로젝트를 시작하려면 npx create-payload-app@latest를 실행하고, 템플릿(웹사이트 또는 blank)을 선택한 후, 데이터베이스 어댑터(PostgreSQL, MongoDB 또는 SQLite)를 선택하면 2분 이내에 localhost:3000/admin에서 작동하는 관리자 패널을 사용할 수 있습니다. 공식 설치 가이드에서는 엣지 케이스들도 다루고 있습니다.

설치

Node.js 18 이상과 패키지 매니저만 필요합니다. 그게 전부입니다.

# Create a new Payload project
npx create-payload-app@latest my-cms

# The CLI asks you:
# - Project name
# - Template (website, blank, e-commerce)
# - Database (postgres, mongodb, sqlite)

cd my-cms
npm run dev
# Admin panel: http://localhost:3000/admin

웹사이트 템플릿은 대부분의 프로젝트에 가장 적합한 시작점이며, 작동하는 블로그, 페이지 컬렉션, 미디어 업로드 및 프론트엔드가 포함되어 제공됩니다. blank 템플릿은 처음부터 구축하고자 할 때 적합합니다.

프로젝트 구조

설치 후 프로젝트는 Payload가 첨가된 표준 Next.js 앱처럼 보입니다.

my-cms/
  app/
    (frontend)/          # Your website pages
    (payload)/
      admin/             # Admin panel routes (auto-generated)
      api/               # REST + GraphQL endpoints
  collections/           # Your content model definitions
  globals/               # Singleton content (settings, nav)
  payload.config.ts      # Main Payload configuration
  payload-types.ts       # Auto-generated TypeScript types

payload.config.ts 파일은 모든 것의 핵심입니다.

// payload.config.ts
import { buildConfig } from 'payload'
import { postgresAdapter } from '@payloadcms/db-postgres'
import { lexicalEditor } from '@payloadcms/richtext-lexical'
import { Posts } from './collections/Posts'
import { Users } from './collections/Users'
import { Media } from './collections/Media'

export default buildConfig({
  admin: { user: Users.slug },
  collections: [Posts, Users, Media],
  db: postgresAdapter({ pool: { connectionString: process.env.DATABASE_URI } }),
  editor: lexicalEditor({}),
  secret: process.env.PAYLOAD_SECRET,
  typescript: { outputFile: './payload-types.ts' },
})

첫 번째 컬렉션 만들기

개발 서버가 실행 중이면 /collections에 파일을 추가하여 새 컬렉션을 만듭니다. Payload는 구성에서 관리자 UI, API 엔드포인트 및 TypeScript 타입을 자동으로 생성합니다. 다음은 간단한 Pages 컬렉션 예제입니다.

// collections/Pages.ts
import type { CollectionConfig } from 'payload'

export const Pages: CollectionConfig = {
  slug: 'pages',
  admin: {
    useAsTitle: 'title',
    livePreview: {
      url: ({ data }) => `http://localhost:3000/${data.slug}`,
    },
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    {
      name: 'layout',
      type: 'blocks',
      blocks: [
        {
          slug: 'hero',
          fields: [
            { name: 'heading', type: 'text' },
            { name: 'subtitle', type: 'textarea' },
            { name: 'image', type: 'upload', relationTo: 'media' },
          ],
        },
      ],
    },
  ],
}

이를 payload.config.ts의 컬렉션 배열에 추가하고 개발 서버를 재시작하면, 시각적 관리자 인터페이스를 갖춘 완전한 기능의 페이지 빌더가 완성됩니다. 플러그인도, 마켓플레이스 다운로드도 필요 없습니다.

데이터베이스 옵션: Postgres, MongoDB 및 SQLite

Payload는 세 가지 데이터베이스 어댑터를 지원합니다. PostgreSQL(프로덕션 권장), MongoDB(문서 중심 모델 또는 기존 Mongo 스택용), SQLite(로컬 개발 및 프로토타이핑 전용). 어댑터 패턴 덕분에 선택한 데이터베이스와 관계없이 애플리케이션 코드는 동일하게 유지됩니다.

새롭게 시작한다면 PostgreSQL을 선택하세요. 관계형 데이터를 더 잘 처리하며(대부분의 CMS 데이터는 관계형임), Neon과 Supabase를 통해 우수한 서버리스 옵션을 제공하며, Payload 팀이 권장하는 방식입니다. Postgres가 현대 앱 개발을 지배하는 이유에 대한 자세한 내용은 PostgreSQL vs MySQL 비교를 참조하세요.

전문가 팁: Vercel에 배포한다면 Payload를 Neon Postgres와 함께 사용하세요. Neon의 연결 풀링은 서버리스 콜드 스타트를 원활하게 처리합니다. Vercel은 새로운 함수 인스턴스를 지속적으로 회전시키기 때문에 이는 중요한 사항입니다.

피그마 인수: 개발자에게 미치는 영향

피그마는 2025년 6월 Payload를 인수했습니다. MIT 라이선스와 오픈소스 코드베이스는 변경되지 않았습니다. 팀이 대체품을 구축하는 동안 Payload Cloud는 신규 가입을 중단했지만, 자체 호스팅에는 영향을 미치지 않습니다. 개발자들에게 가장 큰 질문은 "Payload가 죽었는가?"가 아니라 "호스팅을 어떻게 해야 하는가?"입니다.

우리는 인수 소식이 발표될 당시 고객 프로젝트를 위해 Payload Cloud를 호스팅 옵션으로 추적하고 있었습니다. 자체 호스팅으로 전환하면서 배운 점과 인수가 실제 프로젝트에 미치는 의미를 공유합니다.

2025년 6월 17일, 피그마는 블로그를 통해 인수를 발표했습니다. Payload 팀도 같은 날 자체 발표를 했습니다. 전체 Payload 팀이 피그마로 흡수되었습니다.

변경된 점과 변하지 않은 점

변하지 않는 점:

• MIT 라이선스. 이는 철회할 수 없습니다. GitHub 저장소는 여전히 활성 상태이며 커뮤니티 기여에 개방되어 있습니다.
• 코드베이스. Payload 3는 인수 전과 정확히 동일하게 작동합니다.
• 자체 호스팅. Payload는 어디서든 영구적으로 배포할 수 있습니다.

변경된 점:

• Payload Cloud 신규 가입 중단. 기존 고객은 계속 사용할 수 있지만, 새 프로젝트는 Payload의 관리형 호스팅을 사용할 수 없습니다.
• 팀 포커스 전환. Payload 팀은 이제 피그마 디자인과 실제 콘텐츠 간의 격차를 해소할 것으로 보이는 "Figma CMS"를 구축하고 있습니다. 구체적인 내용은 추측성이지만 방향성은 명확합니다.
• 커뮤니티 관심. 일부 개발자들은 오픈소스 프로젝트를 괴롭히는 "인수 후 방치" 패턴을 우려합니다. MIT 라이선스가 최악의 상황을 완화하지만, 이는 합리적인 우려입니다.

여전히 Payload를 선택해야 할까?

솔직히 말하면? 예, 단서가 있습니다.

좋은 점: 피그마의 자원은 프로젝트背后에 더 많은 엔지니어링 인재가 있다는 것을 의미합니다. MIT 라이선스는 최악의 경우 포크(fork)하면 된다는 것을 의미합니다. 코드베이스는 성숙하고 문서화가 잘 되어 있으며 수천 개의 프로젝트에서 프로덕션으로 활발히 사용되고 있습니다.

우려스러운 점: 시간이 지남에 따라 피그마의 인센티브가 오픈소스 커뮤니티의 요구 사항과 diverge될 수 있습니다. Payload Cloud의 공백은 호스팅을 직접 처리하도록 강요합니다. 그리고 리스크 회피 성향이라면 장기적인 방향성에 대한 불확실성이 현실적입니다.

우리의 견해: 자체 호스팅에 익숙하다면(어렵지 않으므로 익숙해져야 합니다), Payload는 여전히 이용 가능한 최고의 오픈소스 코드 우선 헤드리스 CMS입니다. "Figma CMS"를 기다리지 마세요. 오늘 Payload 3로 구축하고, 자체 호스팅하며 진행하세요.

2026년 Payload CMS 배포 방법

Payload Cloud가 신규 가입을 중단함에 따라, 2026년의 주요 배포 옵션은 다음과 같습니다. Vercel(가장 빠른 설정, 콜드 스타트 주의), VPS의 Docker(활발한 편집자에게 최적, 월 EUR 7-45), Railway/Render/Fly.io(관리형 컨테이너), 또는 Cloudflare Workers(월 ~$5-10로 가장 저렴). Payload의 배포 문서에 따르면 Next.js를 지원하는 모든 Node.js 호스팅 환경에서 작동합니다.

우리는 Payload를 Vercel과 Docker 기반 VPS 모두에 배포해 보았습니다. 놀랐던 점은 Vercel의 콜드 스타트로 인해 일주일에 몇 번만 로그인하는 편집자들의 관리자 패널이 느려졌다는 것입니다. 설정이 더 필요하지만 VPS는 일관되게 더 나은 편집 경험을 제공했습니다.

Vercel (가장 빠른 설정)

Neon Postgres와 파일 업로드를 위한 Vercel Blob을 사용한 원클릭 배포. 프로덕션으로 가는 가장 빠른 길입니다.

장점: 인프라 관리 제로, 우수한 CDN, 편집 활동이 적은 사이트에 적합. 단점: 관리자 패널 콜드 스타트(비활성 후 3-5초), 무거운 쿼리 시 Postgres 연결 고갈, 10초 타임아웃 한도로 인해 대량 작업 중단 가능성. 최적 용도: 마케팅 사이트, 포트폴리오, 편집이 드문 블로그.

Vercel의 강점과 한계에 대한 자세한 내용은 Vercel vs Netlify 비교를 참조하세요.

VPS의 Docker (프로덕션 최적)

Hetzner, DigitalOcean 또는 AWS EC2에서의 Docker Compose 설정. Payload는 영구적인 서버 프로세스를 기대하므로 이는 서버리스보다 Payload의 아키텍처와 더 잘 맞습니다.

# docker-compose.yml
version: '3.8'
services:
  payload:
    build: .
    ports:
      - '3000:3000'
    environment:
      - DATABASE_URI=postgresql://payload:secret@db:5432/payload
      - PAYLOAD_SECRET=${PAYLOAD_SECRET}
      - NEXT_PUBLIC_SERVER_URL=https://your-domain.com
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=payload
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=payload

volumes:
  pgdata:

장점: 영구 서버(콜드 스타트 없음), 예측 가능한 비용(Hetzner 기준 월 EUR 7-45), 스택에 대한 완전한 제어. 단점: 서버, SSL, 백업 및 업데이트를 직접 관리해야 함. 최적 용도: 에이전시, 활발한 편집 팀, 멀티 테넌트 설정, 관리자 사용량이 많은 앱.

Build with Matija의 상세 호스팅 비교에서는 추가 VPS 제공업체와 구성을 다루고 있습니다.

관리형 컨테이너 (Railway, Render, Fly.io)

VPS의 Docker 설정이 너무 많은 운영 작업처럼 들린다면, 관리형 컨테이너 플랫폼이 중간 지점을 제공합니다. Railway는 Payload 커뮤니티에서 특히 인기가 많으며, 한 번의 클릭으로 배포되는 Payload 템플릿을 보유하고 있습니다.

이러한 플랫폼에 대한 심층적인 내용은 Railway vs Render vs Fly.io 비교를 확인하세요.

최적 용도: 인프라를 직접 관리하지 않고 영구 서버를 원하는 팀.

Cloudflare Workers (가장 저렴)

가장 새로운 옵션입니다. Payload는 D1(SQLite) 또는 Hyperdrive(Postgres 프록시)와 함께 엣지 함수에서 실행되는 Cloudflare Workers 어댑터를 추가했습니다. 아직 실험 단계이지만 비용은 비교할 수 없습니다. 대부분의 프로젝트에서 월 ~$5-10입니다.

최적 용도: 사이드 프로젝트, 개인 사이트, 새롭고 덜 테스트된 인프라에 익숙한 예산 중심 배포.

우리의 결론: 활발한 편집자가 있는 대부분의 프로덕션 Payload 프로젝트에는 VPS의 Docker가 기본값으로 가장 좋습니다. 생각보다 저렴하고, 콜드 스타트 문제를 제거하며, 완전한 제어권을 제공합니다. 편집자가 드물고 운영 오버헤드를 제로로 하고 싶다면 Vercel을 사용하세요.

Payload CMS 가격: 실제 비용

Payload 자체는 무료이며 MIT 라이선스를 따릅니다. 실제 비용은 호스팅과 (선택 사항인) 전문 개발 비용입니다. 실제 설정과 Build with Matija의 가격 분석을 기반으로 한 실제 숫자는 다음과 같습니다.

참고용: Contentful의 Team 플랜은 월 $300부터 시작합니다. Sanity의 Team 플랜은 프로젝트당 월 $99입니다. Strapi Cloud는 월 $29부터 시작합니다. Payload의 $0 소프트웨어 비용과 월 $7-25 호스팅 비용은 특히 좌석당 가격 정책이 마진을 위협하는 고객 프로젝트를 구축하는 에이전시에게 설득력이 높습니다.

Payload vs Sanity vs Strapi vs Contentful: 빠른 비교

코드 우선 제어와 자체 호스팅을 원한다면 Payload를 선택하세요. 최고의 시각적 편집과 실시간 협업을 원한다면 Sanity를 선택하세요. 플러그인 생태계와 빠른 관리자 패널을 원한다면 Strapi를 선택하세요. SLA 보증이 있는 엔터프라이즈급 인프라를 원한다면 Contentful을 선택하세요. 우리는 techsy.io에 Sanity를 사용하므로 이러한 플랫폼을 비교한 firsthand 경험을 가지고 있습니다.

데이터 소유권과 자체 호스팅이 필요한 고객을 위해 Payload 기반 프로젝트를 구축했으며, 우리 자신의 콘텐츠 파이프라인은 Sanity로 운영합니다. 둘 다 훌륭하며, 올바른 선택은 팀의 기술적 숙련도와 호스팅 선호도에 따라 달라집니다. 프로젝트용 헤드리스 CMS 옵션을 평가 중이라면 우리가 선택을 도와드릴 수 있습니다.

각 플랫폼에 대한 심층 분석은 다음 가이드를 확인하세요: 2026년 최고의 헤드리스 CMS, 그리고 곧 출시될 Sanity, Strapi 및 Contentful 개별 가이드.

Payload CMS를 사용하면 안 되는 경우

팀이 비기술적이고 WordPress 같은 GUI가 필요한 경우, 자체 호스팅 작업 없이 즉시 관리형 클라우드 호스팅이 필요한 경우, 편집자가 Sanity Studio 수준의 시각적 편집을 원하는 경우, 또는 빠른 기능 확장을 위한 플러그인 마켓플레이스가 필요한 경우 Payload는 건너뛰세요. 한계를 정직하게 인정하는 것이 존재하지 않는다고 pretending하는 것보다 더 많은 신뢰를 구축합니다.

TypeScript 경험이 전혀 없는 편집 팀을 가진 고객에게는 Payload 사용을 권장하지 않았습니다. 다음과 같은 경우에는 다른 곳을 살펴봐야 합니다.

• 비기술적 팀. Payload는 구성을 위해 TypeScript 지식이 필요합니다. 고객의 편집자가 코드를 건드릴 수 없고 콘텐츠 모델을 직접 수정해야 한다면 WordPress나 Sanity가 더 적합합니다.
• 지금 바로 관리형 호스팅이 필요한 경우. Payload Cloud가 신규 가입을 중단했으므로 자체 호스팅해야 합니다. 서버 관리(간단한 Docker 설정이라도)가 거래 거부 사항이라면, Contentful이나 Sanity의 클라우드 호스팅 방식이 그 부담을 제거해 줍니다.
• 강력한 편집 협업. Sanity Studio의 실시간 협업(여러 편집자가 presence indicator와 함께 동시에 동일한 문서에서 작업)은 Payload가 제공하는 것보다 더 정교합니다. 대규모 편집 팀이 있다면 여기서 Sanity가 승리합니다.
• 플러그인 중심 개발. Strapi는 더 큰 플러그인 마켓플레이스를 보유하고 있습니다. SEO 플러그인, 사이트맵 생성기, 이메일 통합이 필요하신가요? Strapi에는 아마 있을 것입니다. Payload의 생태계는 성장 중이지만 더 작습니다.
• Next.js를 사용하지 않는 경우. Payload 3는 아키텍처적으로 Next.js와 결합되어 있습니다. 프론트엔드가 Astro, Remix, Nuxt 또는 SvelteKit이라면 Payload의 가장 큰 장점(서버 컴포넌트의 로컬 API)이 적용되지 않습니다. REST와 GraphQL은 여전히 얻을 수 있지만, 그 시점에서는 Strapi나 Directus가 더 자연스럽게 느껴질 수 있습니다.

FAQ

Payload CMS란 무엇이며 어떻게 작동하나요?

Payload는 Next.js 기반으로 구축된 오픈소스 TypeScript 네이티브 헤드리스 CMS 및 애플리케이션 프레임워크입니다. TypeScript 구성 파일에서 콘텐츠 모델을 정의하면 Payload는 관리자 패널, REST API, GraphQL API 및 로컬 API를 자동으로 생성합니다. 단일 배포 단위로 Next.js 앱 내부에서 실행됩니다.

Payload CMS는 무료로 사용할 수 있나요?

Payload는 MIT 라이선스 하에 완전히 무료입니다. 소프트웨어는 다운로드, 사용 또는 수정하는 데 비용이 들지 않습니다. Payload Cloud(관리형 호스팅)는 월 $35-199였지만 피그마 인수 이후 신규 가입이 현재 중단되었습니다. VPS에서의 자체 호스팅은 제공 업체에 따라 월 EUR 7-45 정도입니다.

Payload와 피그마 사이에 무슨 일이 있었나요?

피그마는 2025년 6월 17일 Payload를 인수했습니다. 전체 Payload 팀이 피그마에 합류했습니다. 오픈소스 MIT 라이선스와 GitHub 저장소는 변경되지 않았습니다. Payload Cloud는 신규 가입을 중단했습니다. 자체 호스팅은 정상적으로 계속 작동합니다. 팀은 아마도 피그마 통합 CMS 제품을 구축하고 있지만 구체적인 사항은 발표되지 않았습니다.

Payload CMS는 어떤 데이터베이스를 사용하나요?

Payload는 어댑터 패턴을 통해 세 가지 데이터베이스를 지원합니다. PostgreSQL(프로덕션 권장, Neon 및 Supabase와 함께 서버리스에서 작동), MongoDB(문서 중심 모델 또는 Payload 2 업그레이드에 좋음), SQLite(로컬 개발 및 CI 전용). 선택한 어댑터와 관계없이 애플리케이션 코드는 동일하게 유지됩니다.

2026년에 Payload CMS를 어떻게 배포하나요?

Payload Cloud가 중단됨에 따라, Neon Postgres와 함께 Vercel에 배포(가장 쉬움), Hetzner와 같은 VPS의 Docker(활발한 편집자가 있는 프로덕션에 최적), Railway 또는 Render(관리형 컨테이너), 또는 Cloudflare Workers(가장 저렴)로 배포하세요. 정기적인 편집 활동이 있는 대부분의 프로덕션 사이트에는 Docker 기반 VPS가 가장 좋은 경험을 제공합니다.

Payload CMS가 Strapi보다 낫나요?

Payload는 TypeScript 네이티브 개발자 경험, Next.js 통합 및 오버헤드가 없는 서버 사이드 쿼리를 위한 고유한 로컬 API에서 우위를 차지합니다. Strapi는 플러그인 마켓플레이스, GUI 기반 스키마 편집 및 더 넓은 프레임워크 호환성에서 우위를 차지합니다. 팀이 TypeScript를 작성하고 Next.js를 사용한다면 Payload가 더 강력한 선택입니다. 그렇지 않다면 Strapi를 평가해 보세요.

Payload의 로컬 API란 무엇인가요?

로컬 API는 HTTP 오버헤드가 제로인 상태로 데이터베이스를 직접 호출하는 서버 사이드 쿼리 레이어입니다. REST 또는 GraphQL 호출을 하는 대신, Payload를 가져와 Next.js 서버 컴포넌트에서 컬렉션을 직접 쿼리합니다. 이는 네트워크 왕복 시간과 직렬화 비용을 제거하여 페이지 로드를 빠르게 합니다. 이러한 기능을 제공하는 헤드리스 CMS는 없습니다.

Payload CMS는 대규모 애플리케이션을 처리할 수 있나요?

Payload는 연결 풀링(Neon 또는 PgBouncer経由), 필드 단위 세분성을 갖춘 역할 기반 접근 제어, 초안 및 버전 관리 워크플로우, 멀티 테넌트 아키텍처를 지원합니다. 엔터프라이즈와 에이전시는 콘텐츠 중심 애플리케이션을 위해 프로덕션에서 Payload를 사용합니다. 로컬 API의 제로 오버헤드 쿼리는 실제로 확장 시 성능을 향상시킵니다.

Payload는 Sanity와 어떻게 비교되나요?

Payload는 자체 호스팅, 코드 우선, MIT 라이선스이며 서버 사이드 성능을 위한 로컬 API를 제공합니다. Sanity는 우수한 시각적 편집, 실시간 협업 및 GROQ 쿼리 언어를 갖춘 클라우드 호스팅 서비스입니다. Payload는 더 많은 인프라 제어와 낮은 비용을 제공합니다. Sanity는 더 나은 편집 도구와 호스팅 관리 제로를 제공합니다.

Payload CMS의 단점은 무엇인가요?

Payload는 구성을 위해 TypeScript 지식이 필요하며, 피그마 인수 이후 새 사용자를 위한 관리형 클라우드 호스팅이 없으며, Strapi보다 작은 플러그인 생태계를 제공하며, 버전 3에서 아키텍처적으로 Next.js와 결합되어 있습니다. 비기술적 팀은 코드 우선 접근 방식으로 어려움을 겪을 수 있으며, 피그마 인수는 일부 장기적인 불확실성을 야기합니다.