Weegloo vs Sanity

한 줄로 답하면

Sanity 는 콘텐츠를 아주 잘 다루고, Weegloo 는 콘텐츠를 다루면서 서비스의 나머지도 운영합니다.

Sanity 는 훌륭한 제품입니다. Studio 는 코드로 원하는 만큼 손볼 수 있고, 실시간 협업 편집이 자연스럽게 되고, 전송망도 빠릅니다. 콘텐츠 편집 경험만 놓고 보면 이 목록에서 가장 잘 다듬힌 축에 듭니다.

차이는 어디에서 멈추는가입니다. Sanity 는 콘텐츠에서 멈춥니다 — 제품에 가입하는 회원, 폼 제출에 답하는 메일, 매일 새벽 도는 작업은 다른 곳의 일입니다. Weegloo 는 같은 CMS 깊이를 가진 채로 계속 갑니다. 사용자 로그인, 개인 단위로 좁혀지는 권한, 콜드 스타트 없는 서버 로직, Cron 스케줄러까지.

각각이 그대로 내어 주는 것

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

1. 회원이 있는 제품인가

Sanity 의 사용자와 역할은 편집자에 관한 것입니다. 누가 어떤 콘텐츠를 발행할 수 있는가 — 그 층은 잘 만들어져 있습니다.

Weegloo 에도 같은 층이 있고, 그 위에 한 겹이 더 있습니다. ServiceUser 는 제품에 가입한 최종 사용자이고 그들에게도 별도의 역할이 붙습니다. createdBy: :self 는 로그인한 회원이 자기가 만든 행만 읽고 편집한다는 뜻입니다. 두 층은 서로를 대체하지 않고 함께 존재합니다 — 팀은 콘텐츠를 운영하고, 회원은 자기 데이터만 다룹니다.

가입해서 무언가를 올리고 자기 것만 봐야 하는 사용자가 있는 제품이라면, 이 한 겹이 있고 없고가 플랫폼 하나를 더 붙이느냐 마느냐를 가릅니다.

2. Script — CMS 가 백엔드 노릇까지 하게 만드는 것

콘텐츠 플랫폼으로 제품을 만들면 반드시 마주치는 순간이 있습니다. "폼이 제출되면 메일을 보내고, 외부 API 를 호출해 응답을 저장해야 한다."

Weegloo 에는 Script 가 있습니다. 콘텐츠를 읽고 쓰고, 외부 API 를 호출하고, 메일을 보내고, 서명을 검증하는 선언형 문장이고, 이메일 발송은 문장 하나입니다. 부르는 방법도 셋입니다 — 직접 호출, 콘텐츠 변경 이벤트, Cron 스케줄러. 코드 기반 함수를 못 만드는 것이 아니라 만들지 않는 것이고, 그 대가로 콜드 스타트가 없고 대용량 트래픽에서 가볍고 요금이 쌉니다.

코드를 쓰지 않는 사람에게는

이 항목에서 Sanity 는 갈립니다. 편집자에게는 좋습니다 — Studio 는 잘 만들어진 편집 화면입니다. 다만 그 Studio 자체가 코드로 정의되고 배포되는 React 애플리케이션이라, 스키마를 바꾸거나 화면을 손보는 일에는 개발자가 필요합니다.

Weegloo 는 콘텐츠 타입도, 값 검증도, 권한도 콘솔에서 설정합니다. 서버 로직은 코드가 아니라 Script 문장이고, 그 문장마저 AI 에게 한 문장으로 말하면 대신 써 줍니다. 엔지니어가 아닌 사람이 멈추는 지점이 훨씬 뒤에 있습니다.

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

Sanity 의 플러그인과 스타터는 Studio 와 프로젝트를 거들어 줍니다. Weegloo 의 마켓플레이스는 서비스 자체를 설치합니다.

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

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

전부 다 쓸 필요는 없습니다

필요한 부분만 써도 됩니다. 콘텐츠는 Sanity 를 계속 쓰면서 Weegloo 는 회원과 Script 에만 쓸 수도 있고, 미디어와 CDN 전송이나 정적 호스팅만 쓸 수도 있습니다.

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

Sanity 가 더 나은 경우

• 편집 화면을 깊이 손봐야 할 때. Studio 를 코드로 원하는 만큼 바꿀 수 있다는 것은 Weegloo 가 줄 수 없는 것입니다. 편집자의 작업 흐름이 제품의 경쟁력인 조직이라면 그 자유가 큽니다.
• 실시간 공동 편집이 중요할 때. 여러 편집자가 같은 문서를 동시에 만지는 경험은 Sanity 의 강점이고, 실시간 구독 자체가 Weegloo 에는 없습니다.
• GROQ 로 질의하고 싶을 때. 콘텐츠 질의 언어를 쥐고 싶다면 그쪽입니다.
• 콘텐츠가 정말로 제품 전부이고 이미 생태계에 올라타 있을 때. 플러그인과 연동을 이미 쌓아 두었다면 옮기는 비용이 얻는 것보다 클 수 있습니다.

자주 묻는 질문

Weegloo 는 Sanity 대안인가요?

콘텐츠에 더해 회원·서버 로직·호스팅이 필요한 제품에는 그렇습니다. 콘텐츠 모델링, 리비전, 다국어, 미디어, 전송 API 라는 핵심을 같이 덮고, 거기에 사용자 인증과 사용자별 권한 범위, Script, 스케줄러, 정적 호스팅이 더해집니다. 다만 Studio 수준의 편집 화면 커스터마이즈와 실시간 공동 편집은 Sanity 가 앞섭니다.

편집 화면을 코드로 바꿀 수 있나요?

없습니다. Weegloo 의 콘솔은 설정으로 다루는 화면이고, Sanity Studio 처럼 React 로 다시 짜는 방식이 아닙니다. 뒤집어 말하면 개발자 없이도 콘텐츠 타입과 검증과 권한을 바꿀 수 있다는 뜻이기도 합니다. 어느 쪽이 나은지는 팀에 무엇이 있는지에 달려 있습니다.

실시간 기능이 있나요?

없습니다. 실시간 구독은 Sanity 가 제공하고 Weegloo 는 제공하지 않습니다. 콘텐츠 변경을 계기로 서버 쪽에서 무언가를 실행하는 일은 되지만, 클라이언트가 변경을 구독해 즉시 받아 보는 것은 다른 기능입니다.

우리 앱의 사용자가 로그인할 수 있나요?

가능합니다. ServiceLogin 이 제품에 자체 최종 사용자 디렉터리를 제공하고, Google · GitHub · Facebook · GitLab · LINE · Kakao · Naver 로 OAuth 로그인합니다. 이 회원들은 팀이 쓰는 계정과 별개이고, 권한은 자기 레코드까지 좁힐 수 있는 역할이 정합니다. Sanity 의 역할은 편집자를 위한 것이라 이 자리는 제공자를 따로 붙이게 됩니다.

서버 로직도 Weegloo 안에서 처리되나요?

됩니다. Script 가 콘텐츠를 읽고 쓰고, 외부 API 를 호출하고, 메일을 보냅니다. 이메일 발송은 문장 하나이고, 실행은 직접 호출, 콘텐츠 변경 이벤트, Cron 스케줄러 세 경로 모두 됩니다. 콜드 스타트도 없습니다.

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

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

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

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