Weegloo vs Payload

한 줄로 답하면

Payload 는 코드로 정의하는 CMS 이고, Weegloo 는 콘솔에서 설정하는 플랫폼입니다.

Payload 는 개발자에게 아주 매력적인 제품입니다. 컬렉션과 필드와 검증을 TypeScript 로 선언하고, 그 설정이 곧 형상 관리 대상이 되며, Next.js 애플리케이션 안에서 함께 돌릴 수도 있습니다. 런타임이 내 것이라 임의의 코드를 얼마든지 얹을 수 있고, 서버리스가 아니므로 콜드 스타트도 없습니다.

그래서 이 비교는 기능의 많고 적음이 아니라 어디에 무게를 둘 것인가입니다. 전부 코드로 쥐고 직접 굴릴 것인가, 아니면 설정으로 다루고 운영을 넘길 것인가.

각각이 그대로 내어 주는 것

실제로 결정을 가르는 두 가지

1. 스키마를 코드로 쥐고 싶은가, 설정으로 다루고 싶은가

코드로 쥐는 쪽의 장점은 분명합니다. 컬렉션 정의가 저장소에 들어가 리뷰를 거치고, 브랜치마다 다르게 가고, 배포와 함께 움직입니다. 타입도 그대로 따라옵니다. 개발자로 이루어진 팀이라면 이보다 편한 것이 드뭅니다.

설정으로 다루는 쪽의 장점은 사람에 있습니다. 필드를 하나 더하거나 검증을 거는 일에 배포가 필요 없고, 개발자가 아닌 사람도 할 수 있습니다. 그리고 MCP 로 열려 있어서 AI 에이전트에게 말로 시킬 수도 있습니다.

어느 쪽이 맞는지는 팀의 모양이 정합니다. 전원이 개발자라면 Payload 의 방식이 자연스럽고, 콘텐츠를 만지는 사람이 개발자가 아니라면 배포를 거치지 않는 쪽이 낫습니다.

2. 런타임을 누가 굴리는가

Payload 는 여러분의 애플리케이션 안에서 돕니다. 임의의 코드를 얹을 수 있다는 뜻이고 — 이건 실제로 큰 자유입니다 — 동시에 그 애플리케이션과 데이터베이스를 누군가 운영해야 한다는 뜻입니다. 배포, 백업, 업그레이드, 트래픽이 몰릴 때의 확장이 그 사람의 일입니다.

Weegloo 에서는 그 일 자체가 없습니다. 서버 로직은 Script 로 처리하고, 직접 호출 · 콘텐츠 변경 이벤트 · Cron 스케줄러 셋 모두 같은 Script 를 씁니다. 이메일 발송은 문장 하나이고, 호스팅과 CDN 이 포함되어 있어 그 사이를 오가는 아웃바운드 트래픽도 없습니다.

대신 임의의 라이브러리를 서버에서 돌리는 일은 되지 않습니다. 못 하는 것이 아니라 하지 않기로 한 선택이고, 그 대가로 콜드 스타트가 없고 대용량 트래픽에서 가볍고 요금이 쌉니다.

코드를 쓰지 않는 사람에게는, 여기가 가장 확실한 선택입니다

Payload 는 이름 그대로 코드 우선입니다. 컬렉션 하나를 더하려면 TypeScript 를 쓰고 배포해야 합니다. 편집 화면은 그다음에야 생깁니다.

Weegloo 는 콘텐츠 타입도, 값 검증도, 권한도, 회원 로그인도 콘솔에서 설정합니다. 서버 로직은 코드가 아니라 Script 문장이고, 그 문장마저 AI 에게 한 문장으로 말하면 대신 써 줍니다. 엔지니어가 아닌 사람이 프로토타입이 아니라 실제 서비스를 운영할 수 있다는 뜻입니다.

마켓플레이스 — 화면조차 직접 만들지 않는 길

Payload 에서는 컬렉션과 필드와 검증을 TypeScript 로 직접 선언합니다. Weegloo 에는 그 모델링을 아예 건너뛰는 길이 있습니다 — 이미 모델링된 것을 설치해 그대로 씁니다.

마켓플레이스에는 완성된 앱이 올라옵니다. 앱 하나에 Content Type, Content, Media, SpaceRole, Locale, Script, Webhook, 그리고 화면(Web Hosting)까지 함께 실립니다. 설치하면 그것들이 내 Space 안으로 들어옵니다 — 남의 서비스에 세 들어 사는 것이 아니라 데이터도 화면도 내 것인 서비스가 하나 생기는 것입니다.

화면이 있는 앱이라면 설치하고 데이터만 내 것으로 바꿔도 바로 서비스가 됩니다. 화면이 없는 앱이라면 데이터 구조를 어떻게 짤지 고민하고 Script 를 처음부터 쓰는 일을 건너뜁니다 — 이미 모델링된 것을 받아 그 위에 원하는 프론트엔드를 얹으면 됩니다.

플러그인이나 템플릿을 내려 주는 생태계와는 층위가 다릅니다. 그쪽은 제품을 넓혀 주거나 코드 저장소를 복제해 주고 그 다음부터는 직접 굴리는 일이 남지만, 여기서 설치되는 것은 내 Space 안에서 이미 돌아가는 서비스 한 벌입니다.

전부 다 쓸 필요는 없습니다

필요한 부분만 써도 됩니다. Payload 로 데이터를 계속 다루면서 Weegloo 는 미디어와 CDN 전송에만 쓸 수도 있고, 정적 호스팅만 쓸 수도 있습니다.

더 넓은 비교가 필요하시면 Appwrite · Directus · Strapi · Sanity · Supabase · Firebase · Vercel · Contentful 까지 열 개 플랫폼을 20개 항목으로 견준 표를 비교 문서 모음에 두었습니다. 자체적으로 제공하지 않는 기능은 0점으로 친 표입니다.

Payload 가 더 나은 경우

• 스키마가 코드여야 할 때. 형상 관리, 코드 리뷰, 브랜치별 차이, 타입 생성 — 이 전부가 그냥 따라옵니다. Weegloo 의 설정 방식으로는 같은 것을 주지 못합니다.
• 임의의 코드를 서버에서 돌려야 할 때. 훅과 엔드포인트에 무엇이든 얹을 수 있습니다. Script 는 그 자리를 노린 물건이 아닙니다.
• Next.js 애플리케이션 안에 함께 두고 싶을 때. 한 저장소, 한 배포로 끝내는 구성은 Payload 의 강점입니다.
• 오픈소스여야 하거나 데이터베이스를 직접 쥐어야 할 때. 소스 코드를 고쳐야 한다면 그쪽입니다. 인프라 분리나 폐쇄망만이 요건이라면 Weegloo 의 Enterprise 전용 클러스터로도 해결됩니다.

자주 묻는 질문

Weegloo 는 Payload 대안인가요?

콘텐츠·회원·미디어·서버 로직이 필요하고 그것을 직접 굴리고 싶지 않은 제품에는 그렇습니다. 데이터 모델링, 검증, 리비전, 다국어라는 핵심을 같이 덮고, 거기에 호스팅·CDN·스케줄러·사용량 알림이 더해집니다. 다만 스키마를 코드로 쥐는 것과 임의의 코드를 서버에서 돌리는 것이 목적이라면 대안이 아닙니다. 그것이 Payload 의 존재 이유입니다.

스키마를 코드로 관리할 수 있나요?

콘솔에서 설정하는 방식이 기본입니다. 다만 REST API 와 MCP 로 전체 표면이 열려 있어서, 정의를 스크립트로 만들어 두고 재현하는 일은 가능합니다. TypeScript 설정 파일이 곧 스키마가 되는 Payload 의 방식과는 성격이 다릅니다.

임의의 코드를 서버에서 돌릴 수 있나요?

없습니다. 대신 Script 가 있고, 그것은 못 하는 것이 아니라 하지 않기로 한 설계입니다. 값 비교, 데이터 가공, 이메일 발송, 웹훅 호출, 외부 API 연동처럼 BFF 가 실제로 하는 일을 DSL 로 만들었고, 그 대가로 콜드 스타트가 없고 대용량 트래픽에서 가볍습니다. 특정 라이브러리를 서버에서 실행해야 한다면 Payload 가 맞습니다.

직접 운영해야 하나요?

아닙니다. Weegloo 는 관리형이라 배포·백업·업그레이드·확장이 여러분의 일이 아니고, 호스팅과 CDN 도 포함되어 있습니다. Payload 는 애플리케이션과 데이터베이스를 직접 굴리게 됩니다.

정기 실행(cron) 이 되나요?

됩니다. Scheduler 로 Cron 일정에 Script 를 겁니다. 같은 Script 를 직접 호출하거나 콘텐츠 변경 이벤트로 트리거할 수도 있어서, 스케줄 작업을 지금 한 번만 돌리는 일도 그냥 호출로 해결됩니다.

사용량은 어떻게 확인하나요? 한도를 넘기 전에 알 수 있나요?

콘솔에서 Metric 기반으로 사용량을 확인합니다. 그리고 임계치를 퍼센트로 걸어 두면 그 지점에 도달했을 때 이메일이 먼저 옵니다.

개발자가 아니어도 쓸 수 있나요?

쓸 수 있고, 이 비교에서 격차가 가장 큰 대목입니다. Payload 는 컬렉션 하나를 더하는 데도 TypeScript 와 배포가 필요합니다. Weegloo 는 콘텐츠 타입·검증·권한·회원 로그인을 콘솔에서 설정하고, 서버 로직은 코드가 아닌 Script 문장이며, 그 문장도 AI 가 대신 씁니다.

AI 에이전트가 꼭 있어야 하나요?

아닙니다. REST API 와 콘솔이 있고 그것으로 충분합니다. 다만 MCP 로 전체 표면이 열려 있어서, Claude · Cursor · Codex 같은 에이전트에게 말로 시키는 편이 더 빠를 뿐입니다.