2026년 AI 통합을 위한 최고의 헤드리스 CMS: 빌더의 솔직한 의견
지난 3년간 Series A 스타트업부터 엔터프라이즈 미디어 회사까지 다양한 클라이언트를 위해 헤드리스 CMS 아키텍처를 구축해왔습니다. 그 기간 동안 저는 "AI 통합"이 로드맵 슬라이드의 글머리 기호에서 내 책상에 들어오는 모든 프로젝트 기획서의 가장 요청된 기능으로 변모하는 것을 지켜봤습니다. 문제는? 대부분의 비교 기사는 벡터 임베딩 파이프라인을 CMS 웹훅에 실제로 연결해본 경험이 없는 사람들이 작성합니다. 저는 했습니다. 여러 번. 그리고 결과는 놀라웠습니다.
이 글은 2026년 헤드리스 CMS 환경에 대한 제 솔직한 평가입니다. 특히 AI 통합의 관점을 통해서 말입니다. 저는 실제 워크플로우에 대해 이야기하고 있습니다. 자동화된 콘텐츠 생성, 의미론적 검색, AI 기반 개인화, RAG 파이프라인을 위한 구조화된 데이터, 그리고 지능형 기능을 위에 구축하려고 할 때 싸우지 않는 콘텐츠 모델링.
목차
- AI 통합이 CMS 선택에 중요한 이유
- 경쟁자들: 누가 선정되었는가
- Payload CMS 상세 분석: 빌더를 위한 CMS
- Sanity vs Contentful: 엔터프라이즈 헤비급
- Supabase를 헤드리스 CMS로: 비정통적 선택
- 면대면 비교: 실제로 중요한 AI 기능
- AI 기반 콘텐츠를 위한 아키텍처 패턴
- 2026년 가격 현실 확인
- Social Animal에서 실제로 사용하는 것
- 자주 묻는 질문
AI 통합이 CMS 선택에 중요한 이유
솔직하게 말하겠습니다. AI 통합을 생각하지 않고 2026년에 헤드리스 CMS를 선택한다면, 첫 날부터 기술 부채를 만들고 있는 것입니다. 이유는 다음과 같습니다.
콘텐츠 운영 환경은 근본적으로 변했습니다. 편집팀은 AI 보조 작성을 원합니다. SEO팀은 자동화된 메타 설명과 내부 링크 제안을 원합니다. 엔지니어링팀은 구조화된 콘텐츠를 LLM 컨텍스트로 가져오는 RAG(Retrieval-Augmented Generation) 파이프라인을 구축하고 싶어합니다. 제품팀은 사용자 행동 모델에 의해 구동되는 개인화된 콘텐츠 블록을 원합니다.
이 모든 사용 사례는 CMS에서 세 가지에 달려 있습니다:
- 구조화된 콘텐츠 모델링 -- 단순히 "폼의 필드"가 아니라, 머신이 추론할 수 있는 깊게 타입이 지정된 관계형 콘텐츠
- 프로그래머블 훅 및 웹훅 -- Zapier를 덕트테이프처럼 붙이지 않고 콘텐츠 변경 시 AI 워크플로우를 트리거할 수 있는 능력
- API 유연성 -- GraphQL, REST, 실시간 구독, 그리고 이상적으로는 무거운 AI 워크로드를 위한 직접 데이터베이스 액세스
이 세 가지를 모두 확인하는 CMS가 승리합니다. 두 개를 확인하고 플러그인으로 세 번째를 가짜하는 것... 그것이 프로젝트가 옆으로 빠지는 곳입니다.
경쟁자들: 누가 선정되었는가
저는 AI 기능을 포함하여 프로덕션에 실제로 배포한 네 가지 플랫폼으로 이를 좁혔습니다. 수십 개의 헤드리스 CMS 옵션이 있지만, 저는 전투 테스트를 하지 않은 것들에 당신의 시간을 낭비하지 않을 것입니다:
- Payload CMS 3.x -- 오픈소스, 자체 호스팅, TypeScript 네이티브
- Sanity -- 클라우드 호스팅, 실시간, GROQ 기반
- Contentful -- AI 기능이 추가된 엔터프라이즈 기존 플레이어
- Supabase -- 기술적으로는 CMS가 아니지만 점점 더 CMS로 사용되고 있음
저는 Strapi(v5는 여전히 AI 워크로드에 미완성인 것 같음), Directus(훌륭한 관리자 패널, 제한된 AI 이야기), Hygraph(괜찮지만 규모에서의 가격이 끔찍함)를 제외했습니다.
Payload CMS 상세 분석: 빌더를 위한 CMS
Payload CMS는 v2 이후 제 조용한 최애작이었고, 버전 3.x가 이를 확정했습니다. 대부분의 기사가 놓치는 Payload의 핵심은 단순히 CMS가 아니라는 것입니다. 관리자 패널을 주는 전체 애플리케이션 프레임워크입니다.
Payload가 AI 통합에 승리하는 이유
Payload는 당신의 자체 서버에서 실행됩니다. 이 하나의 사실이 AI 통합에 대한 모든 것을 변경합니다. 당신은 타사 API를 호출하고 웹훅을 기다리지 않습니다. 당신은 CMS와 동일한 프로세스 내부에서 코드를 실행합니다.
// 저장 시 임베딩을 생성하는 Payload 훅
const Articles: CollectionConfig = {
slug: 'articles',
hooks: {
beforeChange: [
async ({ data, operation }) => {
if (operation === 'create' || operation === 'update') {
const embedding = await openai.embeddings.create({
model: 'text-embedding-3-large',
input: `${data.title} ${data.body}`,
});
data.embedding = embedding.data[0].embedding;
}
return data;
},
],
},
fields: [
{ name: 'title', type: 'text', required: true },
{ name: 'body', type: 'richText' },
{ name: 'embedding', type: 'json', admin: { hidden: true } },
],
};
그게 전부입니다. 외부 웹훅 서비스, 큐, 별도의 마이크로서비스 없음. 임베딩은 콘텐츠 저장과 같은 트랜잭션에서 생성됩니다. AI 파이프라인과 동기화를 유지해야 하는 헤드리스 CMS 아키텍처를 구축할 때, 이러한 종류의 콜로케이션은 매우 귀중합니다.
Payload의 강점
- 전체 TypeScript -- 당신의 콘텐츠 타입이 자동으로 TypeScript 인터페이스를 생성합니다. AI 기능을 구축할 때, 콘텐츠 스키마에 대한 타입 안전성은 벡터 검색이 쓰레기를 반환하게 만드는 종류의 무음 버그를 방지합니다.
- 데이터베이스 액세스 -- Payload 3.x는 MongoDB와 Postgres를 모두 지원합니다. Postgres의 경우, 외부 서비스 없이 벡터 유사성 검색에 pgvector를 사용할 수 있습니다.
- 커스텀 엔드포인트 --
/api/semantic-search엔드포인트가 벡터 스토어를 쿼리해야 하나요? 해킹이 아닌 일급 기능입니다. - Lexical 리치 텍스트 -- v3의 Lexical로의 전환은 리치 텍스트가 적절한 AST로 저장된다는 것을 의미하며, 이는 AI 처리를 위한 구형 Slate 형식보다 훨씬 쉽게 파싱할 수 있습니다.
Payload의 약점
- 자체 호스팅 복잡성 -- 인프라가 당신의 것입니다. DevOps 경험이 없는 팀의 경우, 이는 실제 비용입니다.
- 내장 AI 기능 없음 -- 모든 것이 DIY입니다. Sanity와 Contentful은 기본으로 AI 어시스턴트를 제공합니다. Payload는 자신의 것을 구축하는 도구를 제공하며, 이는 더 강력하지만 더 많은 작업입니다.
- 더 작은 생태계 -- 더 적은 플러그인, 더 적은 튜토리얼, 주요 플레이어보다 더 작은 커뮤니티.
Payload Cloud(관리형 호스팅)는 첫 번째 포인트를 도와주며, 2026년 초 기준으로 Pro 계층에서 월 $50로 가격이 책정됩니다. 하지만 그것은 여전히 근본적으로 자체 호스팅 도구입니다.
Sanity vs Contentful: 엔터프라이즈 헤비급
Sanity: 개발자의 좋아하는 것
Sanity는 2025-2026년 AI 통합을 향해 공격적인 움직임을 했습니다. 이제 AI Assist 기능이 Studio에 내장되어 있으며, GROQ(그들의 쿼리 언어)는 AI 시스템으로 공급되는 콘텐츠 파이프라인을 구축하기에 놀랍도록 좋습니다.
AI 작업을 위해 Sanity를 좋아하는 것:
- GROQ 프로젝션 -- 쿼리 시간에 콘텐츠를 재형성할 수 있으므로, AI 파이프라인이 변환 레이어 없이 필요한 정확한 콘텐츠 모양을 요청할 수 있습니다
- 실시간 리스너 -- WebSocket을 통해 콘텐츠 변경을 구독합니다. 편집자가 게시하면, AI 파이프라인이 즉시 알고 있습니다
- Content Lake 아키텍처 -- 모든 문서의 모든 버전이 API를 통해 이용 가능합니다. 이는 훈련 데이터 파이프라인에 금입니다
- Sanity AI Assist -- 그들의 내장 AI 기능은 기본 항목들(alt 텍스트 생성, 제목 제안, 콘텐츠 번역)을 처리하므로 당신의 팀은 커스텀 AI 기능에 집중할 수 있습니다
단점? Sanity의 가격 모델은 API 요청당 그리고 데이터 세트 크기로 청구합니다. 임베딩 업데이트, 의미론적 검색 쿼리, 콘텐츠 강화를 위해 수천 개의 API 호출을 생성하는 AI 워크로드를 실행할 때, 이러한 비용은 빠르게 증가합니다. 파이프라인을 최적화하기 전에 클라이언트가 월 $800의 초과 요금에 도달한 경우가 있었습니다.
// RAG 컨텍스트 구축을 위해 최적화된 GROQ 쿼리
*[_type == "article" && defined(embedding)] {
title,
"plainBody": pt::text(body),
"category": category->title,
"tags": tags[]->name,
publishedAt,
embedding
} | order(publishedAt desc)[0...100]
Contentful: 엔터프라이즈 기본값
Contentful은 "Contentful AI" 우산 아래에서 2025년 내내 AI 기능을 추가했습니다. 그들의 AI Content Generator와 AI 기반 검색은 적절하지만 제품 팀이 설계한 것처럼 느껴집니다. 엔지니어링 팀이 아니라. 그것이 완전한 비판은 아닙니다 -- 덜 기술적인 팀의 경우, 광택난 UI가 중요합니다.
AI를 위한 Contentful의 강점:
- AI Content Types -- 전용 임베딩 필드 타입을 포함한 AI 생성 필드에 대한 일급 지원을 도입했습니다(마침내, 2025년 말에)
- Composition API -- 그들의 더 새로운 콘텐츠 조합 도구는 개인화된 콘텐츠 경험을 구축하기에 좋습니다
- 마켓플레이스 통합 -- OpenAI, Anthropic, Cohere와의 사전 구축된 통합
Contentful의 약점:
- 요청 한도 -- API 요청 한도(표준 플랜에서 초당 7-10개)는 AI 배치 처리에 대한 실제 문제입니다
- 콘텐츠 모델 경직성 -- 시작 후 스키마 변경은 고통스럽습니다. AI 실험이 새 필드 타입이 필요할 때, 이 마찰을 느낄 것입니다
- 가격 -- Contentful의 Enterprise 계층은 월 $2,500경부터 시작합니다. 월 $489의 Team 플랜은 더 작은 프로젝트에는 좋지만, AI 워크로드로 빠르게 한계에 도달할 것입니다
솔직히, 저는 새로운 프로젝트를 위해 Contentful에서 클라이언트를 옮기고 있습니다. 나쁘기 때문이 아니라 -- 견고하고 성숙한 플랫폼입니다. 하지만 Contentful과 Sanity/Payload 간의 개발자 경험 격차가 상당히 확대되었습니다.
Supabase를 헤드리스 CMS로: 비정통적 선택
여기가 일부 사람들을 잃을 수도 있는 부분입니다. Supabase는 CMS가 아닙니다. 인증, 스토리지, 실시간 구독, 엣지 함수가 있는 Postgres 데이터베이스입니다. 하지만 저를 믿으세요.
콘텐츠 모델이 "편집 콘텐츠"보다 더 "구조화된 데이터"인 AI 중심 프로젝트의 경우, Supabase는 진정으로 탁월합니다. 우리는 AI 기능이 애드온이 아닌 핵심 제품인 여러 Next.js 프로젝트에 대한 콘텐츠 백엔드로 사용했습니다.
Supabase가 AI 콘텐츠에 작동하는 이유
-- Supabase의 네이티브 pgvector 지원
create extension if not exists vector;
create table articles (
id uuid primary key default gen_random_uuid(),
title text not null,
body text,
metadata jsonb,
embedding vector(1536),
created_at timestamptz default now()
);
-- 순수 SQL의 유사성 검색
create function match_articles(
query_embedding vector(1536),
match_threshold float,
match_count int
) returns table (id uuid, title text, similarity float)
language sql as $$
select id, title, 1 - (embedding <=> query_embedding) as similarity
from articles
where 1 - (embedding <=> query_embedding) > match_threshold
order by similarity desc
limit match_count;
$$;
그것이 데이터베이스 내부에서 실행되는 네이티브 벡터 유사성 검색입니다. 외부 벡터 DB, Pinecone 청구서, 동기화 악몽이 없습니다.
트레이드오프
명백한 트레이드오프: Supabase에는 편집 UI가 없습니다. 당신의 콘텐츠 편집자는 미리보기, 초안, 게시 워크플로우가 있는 멋진 관리자 패널을 갖지 않을 것입니다. 당신은 그것을 직접 구축하거나 Astro와 경량 관리 프레임워크와 Supabase를 쌍으로 할 필요가 있습니다.
콘텐츠가 주로 구조화된 데이터(제품 카탈로그, 지식 기반, 문서)가 편집 콘텐츠(블로그 게시물, 랜딩 페이지)라기보다 그런 프로젝트의 경우, 이 트레이드오프는 종종 가치가 있습니다.
면대면 비교: 실제로 중요한 AI 기능
| 기능 | Payload CMS 3.x | Sanity | Contentful | Supabase |
|---|---|---|---|---|
| 네이티브 벡터 저장소 | pgvector를 통해(Postgres) | 아니오(외부 필요) | 아니오(임베딩 필드, 검색 없음) | 예(pgvector) |
| 내장 AI 어시스턴트 | 아니오 | 예(AI Assist) | 예(AI Content Generator) | 아니오 |
| 웹훅 안정성 | 탁월(프로세스 내 훅) | 좋음(클라우드 웹훅) | 좋음(그러나 요청 제한) | 좋음(데이터베이스 트리거 + 엣지 함수) |
| 훈련을 위한 콘텐츠 버전 관리 | 전체(데이터베이스 레벨) | 탁월(Content Lake) | 좋음(낮은 플랜에서 최대 10개 버전) | 수동(당신이 구축) |
| 실시간 콘텐츠 구독 | 커스텀 WebSocket을 통해 | 네이티브 | 제한됨 | 네이티브(Postgres LISTEN/NOTIFY) |
| RAG를 위한 구조화된 콘텐츠 | 탁월(타입이 지정된 스키마) | 탁월(GROQ 프로젝션) | 좋음(GraphQL) | 좋음(JSON/관계형) |
| 자체 호스팅 가능 | 예 | 아니오 | 아니오 | 예 |
| 배치 처리 친화적 | 예(요청 한도 없음) | 중간(API 한도) | 나쁨(엄격한 요청 한도) | 예(직접 DB 액세스) |
| TypeScript SDK 품질 | 탁월(네이티브) | 좋음 | 좋음 | 탁월 |
| 편집 경험 | 좋음 | 탁월 | 탁월 | 없음(자신의 것을 구축) |
AI 기반 콘텐츠를 위한 아키텍처 패턴
여기에 프로덕션에 사용한 세 가지 아키텍처 패턴이 있습니다. 올바른 패턴은 팀의 강점과 프로젝트의 AI 포부에 따라 달라집니다.
패턴 1: CMS + 외부 AI 파이프라인
최적: Sanity 또는 Contentful을 사용하고 AI 기능을 증분적으로 추가하려는 팀.
CMS(Sanity/Contentful) → 웹훅 → 큐(SQS/Inngest) → AI Worker → 벡터 DB(Pinecone/Qdrant) → API
이것이 가장 일반적인 패턴이며 기본 사용 사례에는 잘 작동합니다. 문제는 지연 시간과 복잡성입니다. 모든 콘텐츠 변경은 일련의 서비스를 트리거하고, 해당 체인 전체에서 실패를 디버깅하는 것은 고통스럽습니다.
패턴 2: Payload 모놀리식
최적: 모든 것을 한 곳에서 원하고 이를 실행할 ops 기술이 있는 팀.
Payload CMS(훅이 프로세스 내에서 임베딩을 생성) → Postgres + pgvector → Next.js API 경로
AI가 핵심 기능인 프로젝트에 대한 제 선호 패턴입니다. 모든 것이 한 곳에 살아 있습니다. 콘텐츠 변경, 임베딩 생성, 벡터 검색은 모두 동일한 프로세스나 최소한 동일한 데이터베이스에서 일어납니다. 우리는 Next.js 개발 관행을 통해 여러 프로젝트를 이런 방식으로 구축했으며, 운영 단순성은 과장하기 어렵습니다.
패턴 3: Supabase + 엣지 함수
최적: 콘텐츠가 편집 콘텐츠보다 구조화된 데이터에 더 가까운 데이터 중심 애플리케이션.
Supabase(Postgres + pgvector) → 데이터베이스 트리거 → 엣지 함수(임베딩 생성) → 동일한 DB의 검색
작동하는 AI 콘텐츠 시스템으로의 가장 빠른 경로. 오후에 의미론적 검색을 실행할 수 있습니다. 제한은 편집 도구(또는 부족)가 콘텐츠 작업이 복잡해지면 미달할 것입니다.
2026년 가격 현실 확인
중간 규모 프로젝트의 실제 숫자를 살펴보겠습니다: 10,000개의 콘텐츠 항목, 5명의 편집자, 의미론적 검색 및 콘텐츠 생성 지원을 포함한 AI 기능, 월 약 100K API 요청.
| 플랫폼 | 월간 비용 | AI 애드온 비용 | 총 예상 |
|---|---|---|---|
| Payload CMS(Railway에서 자체 호스팅) | $20-50(호스팅) | OpenAI API: ~$30-80 | $50-130 |
| Payload Cloud Pro | $50 | OpenAI API: ~$30-80 | $80-130 |
| Sanity Team | $99 + ~$150 초과 | AI Assist 포함, OpenAI: ~$30 | $279 |
| Sanity Enterprise | 맞춤(~$1,200+) | 포함 | $1,200+ |
| Contentful Team | $489 | 이 계층에서 포함되는 AI 기능 | $489 |
| Contentful Enterprise | $2,500+ | 포함 | $2,500+ |
| Supabase Pro | $25 | OpenAI API: ~$30-80 | $55-105 |
이 숫자는 AI 기능을 번들로 제공하지 않는 플랫폼에 대해 자신의 AI API 키를 가져온다고 가정합니다. OpenAI 비용은 text-embedding-3-large와 gpt-4o-mini를 사용하여 임베딩 생성 + 가끔의 콘텐츠 생성에 대한 것입니다.
비용 차이는 극명합니다. Payload와 Supabase는 Contentful Enterprise보다 10배 더 저렴합니다. 이것이 중요한지는 당신의 예산과 당신이 가치있게 여기는 것에 달려 있습니다 -- Contentful의 엔터프라이즈 지원과 규정 준수 인증은 제공하는 것이 무료가 아닙니다.
Social Animal에서 실제로 사용하는 것
Social Animal에서 대부분의 헤드리스 CMS 프로젝트에 대해 첫 번째로 도달하는 것에 대해 투명하겠습니다. Payload CMS. TypeScript 네이티브 아키텍처, 자체 호스팅 유연성, 프로세스 내 훅은 클라이언트가 일반적으로 필요로 하는 종류의 커스텀, AI 강화 빌드에 이상적입니다.
큰 편집팀이 있는 클라이언트에 대해 최고의 편집 경험을 원할 때, 우리는 Sanity를 권장합니다. Studio는 콘텐츠 편집자에게 진정으로 최고의 클래스이며, GROQ 쿼리 언어는 함께 작업하기에 기쁨입니다.
우리는 Supabase를 CMS 옆에 있는 데이터 집약적 기능의 백엔드로 사용합니다 -- 사용자 생성 콘텐츠, 분석, 편집 CMS 대신에 옆에 앉는 AI 기능 스토어 같은 것들.
Contentful은 클라이언트 팀이 이미 Contentful 생태계에 깊숙이 있을 때 또는 엔터프라이즈 규정 준수 요구사항이 필드를 좁힐 때 권장됩니다.
당신의 프로젝트에 어떤 접근 방식이 맞는지 알아내려고 할 때, 우리는 그것을 통해 이야기하는 것을 좋아합니다 -- 여기에 연락하거나 우리의 가격 페이지를 확인하여 우리가 이러한 종류의 결정을 어떻게 범위 지정하는지 보세요.
자주 묻는 질문
2026년에 가장 좋은 내장 AI 기능을 가진 헤드리스 CMS는 어느 것입니까? Sanity AI Assist는 현재 가장 광택나는 내장 AI 제안입니다. 편집 인터페이스에서 콘텐츠 생성, 번역, alt 텍스트, 필드 수준 제안을 직접 처리합니다. Contentful의 AI 기능이 매우 가깝지만 네이티브 기능이라기보다 애드온처럼 느껴집니다. 그러나 "최고 내장"은 "AI에 최고"를 의미하지 않습니다 -- Payload CMS의 확장성은 사전 구축된 솔루션보다 훨씬 더 강력한 커스텀 AI 기능을 구축할 수 있게 합니다.
Supabase를 헤드리스 CMS로 사용할 수 있습니까? 예, 주의 사항이 있습니다. Supabase는 Postgres 데이터베이스, REST/GraphQL API, 인증, 스토리지 -- CMS의 기술적 재료의 모든 것을 제공합니다. 제공하지 않는 것은 편집 관리 패널, 콘텐츠 미리보기, 또는 게시 워크플로우입니다. 제품 카탈로그, 지식 기반, AI 훈련 데이터세트 같은 구조화된 데이터의 경우, 탁월합니다. 비기술 편집자가 있는 편집 콘텐츠의 경우, 적절한 CMS를 원하거나 당신의 자신의 관리 UI를 구축할 준비가 되어 있습니다.
헤드리스 CMS에 AI 기능을 추가하는 데 비용이 얼마나 들합니까? CMS 비용 자체는 월 $25(Supabase Pro)에서 $2,500+(Contentful Enterprise)까지 범위가 있습니다. 이것 위에 볼륨에 따라 월 $30-200을 AI API 비용(OpenAI, Anthropic, 또는 Cohere)으로 예산을 세우세요. Pinecone 같은 전용 벡터 데이터베이스가 필요하면 월 $70-200을 추가하세요. 가장 저렴한 프로덕션 준비 설정은 Railway의 Payload(~$30) + OpenAI API($~30) = 총 월 약 $60입니다.
Payload CMS는 AI 통합을 위해 Strapi보다 낫습니까? 제 경험에서 예입니다. Payload의 TypeScript 네이티브 아키텍처, 프로세스 내 훅, Postgres 지원(pgvector 포함)은 AI 워크로드에 대해 의미 있는 장점을 제공합니다. Strapi v5는 개선되었지만, 플러그인 아키텍처는 긴밀한 AI 통합을 더 어렵게 하는 간접성을 추가합니다. Payload는 컬렉션 훅에서 직접 AI 로직을 작성할 수 있게 하며, 추상화 레이어 없이, 이는 오전 2시에 임베딩이 정확하게 생성되지 않는 이유를 디버깅할 때 중요합니다.
헤드리스 CMS와 함께 사용할 최고의 벡터 데이터베이스는 무엇입니까? Postgres가 있는 Payload CMS 또는 Supabase를 사용하는 경우, pgvector를 사용하세요 -- 기존 데이터베이스에 내장되어 있으므로 관리하거나 지불할 것이 추가로 없습니다. Sanity와 Contentful의 경우, 외부 벡터 DB가 필요합니다. Pinecone($70+/월 Starter)이 가장 인기 있지만, Qdrant Cloud(무료 계층 사용 가능, 프로덕션 월 $25)와 Weaviate도 강력한 대안입니다. 1M 벡터 미만의 대부분의 프로젝트의 경우, pgvector는 충분 이상이며 운영 관점에서 훨씬 더 간단합니다.
헤드리스 CMS로 의미론적 검색을 구현하려면 어떻게 합니까?
워크플로우는: (1) 콘텐츠가 생성되거나 업데이트될 때, OpenAI의 text-embedding-3-large 같은 API를 사용하여 임베딩을 생성합니다, (2) 해당 임베딩을 콘텐츠 옆에 저장합니다, (3) 사용자가 검색할 때, 동일한 모델로 쿼리를 임베딩합니다, (4) 코사인 유사성을 사용하여 가장 유사한 임베딩을 가진 콘텐츠를 찾습니다. Payload CMS + Postgres/pgvector를 사용하면, 1-2단계는 beforeChange 훅에서 일어나고, 3-4단계는 커스텀 API 엔드포인트에서 일어납니다. Sanity/Contentful을 사용하면, 웹훅 트리거 함수와 외부 벡터 스토어가 필요합니다.
AI 기능을 위해 호스팅되거나 자체 호스팅된 CMS를 사용해야 합니까? 자체 호스팅(Payload, Supabase)은 더 많은 제어, 더 낮은 비용, 그리고 요청 한도가 없음 -- AI 워크로드에 대해 중요한 모두 -- 배치 처리와 실시간 임베딩 생성이 포함됩니다. 호스팅(Sanity, Contentful)은 더 적은 운영 부담과 내장 AI 기능을 제공합니다. AI가 핵심 기능이고 팀에 DevOps 경험이 있다면, 자체 호스팅하세요. AI가 좋은 점이고 팀이 콘텐츠 편집자 중심이라면, 호스팅으로 가세요.
AI 워크플로우를 위해 여러 CMS 플랫폼을 함께 사용할 수 있습니까? 절대로 그렇고, 생각하는 것보다 더 일반적입니다. 우리가 사용하는 패턴: 편집 콘텐츠(블로그 게시물, 랜딩 페이지)에 대한 Sanity + AI 기능 데이터(임베딩, 사용자 신호, 추천 점수)에 대한 Supabase. Sanity 웹훅은 콘텐츠 변경을 Supabase로 푸시합니다. 여기서 임베딩이 생성되고 저장됩니다. 프론트엔드는 둘 다를 쿼리합니다: 렌더링된 콘텐츠에 대한 Sanity, "관련 기사"와 의미론적 검색 같은 AI 기반 기능에 대한 Supabase. 이것은 편집자에게 훌륭한 UX를 제공하면서 엔지니어에게 AI 워크로드에 대한 전체 데이터베이스 액세스를 제공합니다.