Weegloo vs Supabase

한 줄로 답하면

Supabase 는 훌륭한 부품을 줍니다. Weegloo 는 돌아가는 백엔드를 줍니다.

Supabase 는 Postgres 를 중심으로 만들어진 개발자 플랫폼입니다. 데이터베이스, 인증, 오브젝트 스토리지, 실시간 채널, 엣지 함수 — 하나하나가 좋습니다. 다만 그것들을 직접 조립해야 합니다. 스키마, 정책, 스토리지 버킷, 검증 로직, 함수 배포, 그리고 매일 서비스를 운영하는 사람이 쓸 관리 화면까지.

Weegloo 는 한 층 위에서 시작합니다. 엔터프라이즈급 CMS 위에 세운 백엔드 플랫폼이라, 콘텐츠 모델링, 발행 상태, 리비전과 버전 관리, 미디어 처리, 회원 로그인, 세밀한 권한, 데이터 검증, 서버 로직, 스케줄러, 정적 호스팅이 재료가 아니라 이미 기능으로 있습니다.

각각이 그대로 내어 주는 것

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

1. 콘솔이 개발자가 아니라 운영자를 위한 것이다

이 차이는 첫 주가 아니라 석 달째에 체감됩니다.

Supabase Studio 는 스키마를 짠 사람에게 아주 좋은 도구입니다. 테이블과 행과 SQL 을 보여 줍니다. 하지만 서비스가 출시된 다음 날부터 필요한 화면은 주지 않습니다 — 초안이 나가기 전에 검수하는 사람, 태그 분류 체계, 항목에 달리는 댓글 스레드, 남이 쓴 콘텐츠를 가로질러 찾는 검색, 어떤 값이 언제 누구에 의해 바뀌었는지 남는 리비전, 한 명은 일본어로 다른 한 명은 영어로 동시에 편집하는 상황. 순수 BaaS 위에 서비스를 올린 팀은 결국 그 관리 애플리케이션을 직접 만들게 되고, 그것은 좀처럼 작은 프로젝트가 아닙니다.

Weegloo 는 전문 콘텐츠 관리 시스템에서 나왔기 때문에 그 화면이 제품 자체입니다. 별도의 어드민 페이지를 만들 필요가 없습니다. 콘솔이 곧 운영 화면입니다.

2. Script — 함수를 못 만드는 것이 아니라 만들지 않는 것

Weegloo 에는 코드로 작성하는 서버리스 함수가 없습니다. 못 하는 것이 아니라 하지 않기로 한 것이고, 이유가 있습니다.

BFF 가 실제로 하는 일은 놀랄 만큼 뻔합니다. 값을 비교하고, 데이터를 다루고, 이메일을 보내고, 웹훅을 부르고, 외부 API 를 호출해 결과를 저장합니다. Weegloo 는 그것을 꿰뚫어 보고 Script 라는 DSL 로 만들었습니다. 그 대가로 얻은 것이 셋입니다.

• 콜드 스타트가 없습니다. 서버리스 함수는 오래 쉬면 다음 첫 호출이 느려집니다. Script 에는 기동할 컨테이너 자체가 없습니다.
• 대용량 트래픽에서 가볍습니다. 임의의 사용자 코드를 실행하는 런타임을 띄우지 않으므로, 초당 수천 건에서도 처리 부담이 다른 성질을 갖습니다.
• 그래서 쌉니다. 요금이 낮은 것은 인심이 아니라 구조에서 나옵니다.

실행 방식도 하나가 아닙니다. 직접 호출할 수도 있고, 콘텐츠 변경 이벤트로 트리거할 수도 있고, Cron 스케줄러로 돌릴 수도 있습니다. 같은 Script 를 세 경로 모두에서 씁니다 — 예약 작업을 지금 당장 한 번 돌려야 할 때, 그냥 호출하면 됩니다.

이메일 발송이나 서명 검증처럼 매번 다시 구현하던 것들은 Script 안에 문장으로 들어 있습니다. 외부 이벤트가 왔을 때 메일을 보내려고 함수를 만들고 배포할 일이 없습니다.

3. 밖으로 나가는 트래픽이 없다는 것

데이터, 미디어, 콘텐츠, 서버 로직이 한 플랫폼 안에 있으면 그 사이를 오가는 통신이 인터넷을 건너지 않습니다. 규모가 커질수록 이것이 두 곳에서 갈립니다.

하나는 비용입니다. 조립한 스택에서는 데이터베이스와 함수 사이, 함수와 CDN 사이에서 아웃바운드 트래픽이 계속 발생하고, 그 청구서는 트래픽에 비례해 커집니다. 다른 하나는 지연 시간입니다. 호출이 서비스 경계를 넘을 때마다 왕복이 하나씩 쌓입니다.

Weegloo 의 아키텍처가 새것이 아니라는 점도 여기 걸립니다. SNOW Corp. 가 ZEPETO 규모의 글로벌 서비스 — 가입자 3억 명이 넘는 앱 — 를 운영하던 아키텍처를 제품으로 다듬은 것이고, 초당 수천 건의 요청과 발행 스냅샷 기반 캐시는 그 설계가 처음부터 상대한 조건이었습니다.

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

Supabase 는 개발자 플랫폼이고 그것을 숨기지도 않습니다. 쓴다는 것은 SQL 을 쓰고, Row Level Security 정책을 쓰고, 엣지 함수를 배포한다는 뜻입니다. 팀에 엔지니어가 있어야 합니다.

Weegloo 는 비개발자에게 이 목록에서 가장 좋은 선택이고, 그것은 우연이 아닙니다.

• 콘솔이 곧 제품입니다. 콘텐츠, 미디어, 회원, 권한을 거기서 관리합니다. 다른 플랫폼에서 발주해야 하는 그 어드민 애플리케이션이 Weegloo 에서는 이미 만들어져 나옵니다.
• 검증은 클릭 몇 번입니다. 값이 범위 안에 있어야 한다거나, 고유해야 한다거나, 정해진 형식이어야 한다는 것은 필드의 설정이지 누군가 짜고 시험해야 할 코드 경로가 아닙니다.
• 서버 로직이 코드가 아니라 DSL 입니다. 어떤 일이 생겼을 때 메일을 보내고, 외부 API 를 호출하고, 매일 새벽에 작업을 돌리는 것 — 전부 Script 문장이고, 그 문장은 AI 에게 한 문장으로 말하면 알아서 씁니다.
• 고를 스택이 없습니다. 어떤 데이터베이스를 쓸지, 어떤 인증 제공자를 쓸지, 어떤 CDN 과 어떤 호스트를 쓸지 정할 일이 없고, 그것들을 잇는 작업도 없습니다.

엔지니어가 아닌 사람이 프로토타입이 아니라 실제 서비스를 운영할 수 있다는 뜻입니다. 그러다 정말로 엔지니어링이 필요한 부분이 생기면 그 부분만 개발자에게 넘기면 되고, 플랫폼을 옮길 필요는 없습니다.

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

Supabase 에서는 부품을 받아 직접 조립합니다. Weegloo 에는 조립조차 하지 않는 길이 하나 더 있습니다.

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

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

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

전부 다 쓸 필요는 없습니다

Weegloo 를 "풀스택 백엔드" 로만 이해하면 오해입니다. 필요한 부분만 써도 됩니다.

콘텐츠 관리만 Weegloo 로 하고 데이터베이스는 계속 Supabase 를 쓸 수 있습니다. 미디어와 CDN 전송만 쓸 수도 있고, 정적 호스팅만 쓸 수도 있습니다. 전부를 옮기는 결정과 한 조각을 얹는 결정은 다른 문제이고, 후자부터 시작해도 됩니다.

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

Supabase 가 더 나은 경우

이 대목을 솔직하게 적는 편이, 문단에서 이기는 것보다 중요합니다.

• SQL 을 직접 쥐어야 할 때. 집계와 윈도 함수, PostGIS, pgvector, 직접 만든 인덱스와 실행 계획이 제품의 핵심이라면 Postgres 를 직접 쓰는 편이 맞습니다. 다만 보통의 조회는 여기 해당하지 않습니다 — 조건을 겹치고, 정렬하고, 필요한 필드만 받고, 참조를 따라가고, 전문 검색을 하는 일은 Weegloo 의 REST API 로 그대로 표현됩니다. 문법이 SQL 이 아닐 뿐입니다.
• 소스 코드를 손에 쥐고 직접 고쳐야 할 때. Supabase 는 오픈소스이고 Weegloo 는 아닙니다. 다만 흔히 이 항목으로 묶이는 요건 둘은 여기 해당하지 않습니다. "우리가 만든 앱을 우리 인프라에서 돌린다" 는 Weegloo 로도 그대로 됩니다 — 사이트나 서버를 원하는 곳에 올리고 데이터만 REST API 로 받아 쓰면 되고, 실제로 그렇게 운영되어 온 프로젝트들이 있습니다. 인프라를 분리하거나 폐쇄망으로 가야 하는 요건은 Enterprise 의 전용 클러스터로 다룹니다.
• 제품 자체가 데이터베이스일 때. 분석 워크로드, 무거운 관계형 모델링, 질의 자체가 핵심인 일은 Postgres 의 몫입니다.
• 실시간 구독이 핵심일 때. Supabase 의 Realtime 채널은 Weegloo 에 대응물이 없습니다.
• 임의의 코드를 서버에서 돌려야 할 때. 이미지 변환 알고리즘을 직접 짜거나 특정 라이브러리를 서버에서 실행해야 한다면 엣지 함수가 맞습니다. Script 는 그 자리를 노린 물건이 아닙니다.

요금의 모양

Weegloo 의 공개 요금제는 Free, Basic 월 $8, Pro 월 $80 이고 그 위에 Enterprise 가 있습니다. Free 는 체험판이 아닙니다 — Space 5개, 콘텐츠 20,000건, 미디어 2,000건, 월 API 호출 500,000회, 커스텀 도메인 웹 호스팅, 최종 사용자 계정 100,000개까지 포함합니다.

다만 비교할 숫자는 등급 대 등급이 아니라 하나의 구독 대 직접 조립했을 스택 전체입니다. Supabase 기반 제품은 보통 프론트엔드 호스팅 비용을 따로 내고, 서비스 사이를 오가는 아웃바운드 트래픽 비용을 내고, 개발자가 아닌 사람이 페이지를 고쳐야 하는 순간 CMS 비용이 하나 더 붙습니다.

각 회사의 요금은 바뀝니다. 결정 전에 supabase.com 과 요금제 페이지 에서 현재 값을 확인하세요.

자주 묻는 질문

Weegloo 는 Supabase 대안인가요?

Supabase 를 "Postgres 데이터베이스" 가 아니라 "백엔드" 로 쓰는 대부분의 제품에는 그렇습니다. 구조화된 데이터, 인증, 파일 스토리지, 권한, 서버 로직이라는 같은 범위를 덮고, 거기에 운영 콘솔과 데이터 검증, 다국어 콘텐츠, 스케줄러, 정적 사이트 호스팅이 더해집니다. 다만 원하는 것이 내가 통제하는 Postgres 인스턴스에 직접 SQL 을 쓰는 것이라면 대체재가 아닙니다.

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

쓸 수 있고, 이 비교에서 격차가 가장 큰 대목입니다. 콘텐츠·미디어·회원·권한은 콘솔에서 관리하고, 검증 규칙은 클릭으로 설정하며, 서버 로직은 코드가 아니라 Script 문장입니다 — 그 문장은 AI 에게 평범한 한 문장으로 말하면 대신 써 줍니다. 발주할 어드민 애플리케이션도, 조립할 스택도 없습니다. 반면 Supabase 는 SQL 과 Row Level Security 정책, 배포되는 함수를 전제합니다.

전부 옮겨야 하나요? 일부만 쓸 수는 없나요?

일부만 써도 됩니다. Weegloo 는 전부 아니면 아무것도 아닌 플랫폼이 아닙니다. 콘텐츠 관리만 쓰고 나머지는 지금 쓰는 서비스를 그대로 둘 수 있고, 미디어와 CDN 전송만 쓸 수도 있고, 정적 호스팅만 쓸 수도 있습니다.

Weegloo 에는 서버리스 함수가 없나요?

코드로 작성하는 함수는 없습니다. 못 만드는 것이 아니라 만들지 않기로 한 것입니다. BFF 가 하는 일 — 값 비교, 데이터 가공, 이메일 발송, 웹훅 호출, 외부 API 연동 — 이 사실 정해져 있어서, 그것을 Script 라는 DSL 로 만들었습니다. 그 대가로 콜드 스타트가 없고, 대용량 트래픽에서 가볍고, 그래서 요금이 쌉니다. 반대로 임의의 라이브러리를 서버에서 돌려야 한다면 Script 는 맞는 도구가 아닙니다.

Script 는 어떻게 실행하나요?

세 가지 방법이 모두 됩니다. 프론트엔드나 외부에서 직접 호출하고, 콘텐츠 변경 이벤트로 트리거하고, Cron 스케줄러로 정기 실행합니다. 같은 Script 를 세 경로에서 그대로 쓰므로, 스케줄에 걸어 둔 작업을 지금 한 번 돌려야 할 때도 그냥 호출하면 됩니다.

데이터 검증은 직접 구현해야 하나요?

아닙니다. 값의 범위, 고유값, 형식 같은 제약은 플랫폼에 내장되어 있어 콘솔에서 몇 번의 클릭으로 설정합니다. Postgres 제약과 트리거를 쓰거나 애플리케이션 코드에 검증을 넣는 대신, 필드를 정의할 때 함께 정해 둡니다.

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

콘솔에서 Metric 기반으로 사용량을 확인합니다. 무엇을 얼마나 썼는지가 항목별로 그대로 보입니다.

그리고 임계치를 퍼센트로 걸어 둘 수 있습니다. 그 지점에 도달하면 이메일이 먼저 옵니다 — 한도를 넘고 나서 알게 되는 것이 아니라, 넘기 전에 대응할 시간을 받습니다.

Supabase 와 Vercel 을 한꺼번에 대체할 수 있나요?

대개 가능합니다. Weegloo 에는 커스텀 도메인을 지원하는 정적 프론트엔드용 Web Hosting 이 있어서, Next.js 정적 익스포트 · Vite · Astro · 순수 HTML 로 만든 사이트를 Weegloo 에 배포하고 같은 플랫폼에서 데이터를 받아 쓸 수 있습니다. 구독 두 개가 하나로 줄고, 그 사이의 아웃바운드 트래픽도 사라집니다.

Supabase 처럼 무료 플랜이 있나요?

있습니다. Free 플랜에 Space 5개, 콘텐츠 20,000건, 미디어 2,000건, 미디어 저장 공간 10 GiB, 월 API 호출 500,000회, 커스텀 도메인 1개, 최종 사용자 계정 100,000개가 포함됩니다. 프로토타입만이 아니라 작은 서비스를 실제로 운영할 수 있는 크기입니다.

Weegloo 도 Postgres 를 쓰나요?

Weegloo 는 데이터베이스를 사용자에게 노출하지 않습니다. 데이터는 Content Type 으로 모델링하고 전송 API 로 읽습니다. 조회가 줄어드는 것은 아닙니다 — 조건을 겹치고, 정렬하고, 필요한 필드만 받고, 참조를 따라가고, 전문 검색을 하는 일이 질의 문자열로 그대로 표현됩니다. 문법이 SQL 이 아닐 뿐입니다.

의도적인 교환입니다. 스키마와 인덱스를 직접 쥐는 대신, 발행 상태와 리비전, 필드 단위 다국어, 미디어 처리, 데이터 검증, 권한 필터를 스키마 위에 직접 구현하지 않고 플랫폼의 기본 동작으로 받습니다.

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

아닙니다. Weegloo 는 전통적인 방식으로 개발자가 직접 다뤄도 아무 문제가 없습니다. REST API 와 콘솔이 있고 그것으로 충분합니다. 다만 MCP 로 전체 표면이 열려 있어서, Claude · Cursor · Codex 같은 에이전트에게 말로 시키는 편이 더 빠를 뿐입니다. AI 는 선택지이지 전제 조건이 아닙니다.