Weegloo vs Appwrite

한 줄로 답하면

Appwrite 는 개발자를 위한 오픈소스 BaaS 이고, Weegloo 는 서비스를 운영하기 위한 플랫폼입니다.

Appwrite 는 좋은 제품입니다. 데이터베이스, 인증, 스토리지, 함수, 실시간 구독이 한 묶음으로 있고, 오픈소스라 자사 인프라에 직접 올릴 수도 있습니다. 백엔드 부품을 한곳에서 받는다는 점에서 Supabase 나 Firebase 와 같은 계열입니다.

차이는 데이터 위의 층입니다. 개발자가 아닌 사람이 초안을 검수하고, 배너 문구를 고치고, 일본어 번역을 발행하고, 누가 무엇을 언제 바꿨는지 되짚는 자리 — Appwrite 콘솔은 그것을 위해 만들어지지 않았습니다. Weegloo 는 엔터프라이즈급 CMS 에서 출발했기 때문에 그 층이 제품 자체입니다.

각각이 그대로 내어 주는 것

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

1. 편집 계층이 있느냐 없느냐

Appwrite 로 서비스를 만들면, 출시 다음 날부터 누군가는 콘텐츠를 손봐야 합니다. 그리고 그 사람이 Appwrite 콘솔을 열어 문서를 직접 고치게 두지는 않습니다. 그래서 팀은 관리 화면을 하나 만들고, 거기에 로그인과 역할과 미리보기와 변경 이력이 차례로 필요해집니다.

Weegloo 에서는 이것이 프로젝트가 아닙니다. 발행 상태, 리비전, 필드 단위 다국어, 태그, 댓글, 콘텐츠를 가로지르는 검색이 플랫폼의 동작이고, 별도의 어드민 페이지를 만들 필요가 없습니다. 콘솔이 곧 운영 화면이며, 개발자용 UI 가 아니라 서비스를 운영하는 사람을 위한 UI 입니다.

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

Appwrite Functions 는 여러 런타임으로 임의의 코드를 실행합니다. Weegloo 는 그 자리에 Script 라는 DSL 을 두었습니다. 못 하는 것이 아니라 하지 않기로 한 선택이고, 그 대가로 셋을 얻었습니다.

• 콜드 스타트가 없습니다. 기동할 컨테이너 자체가 없습니다.
• 대용량 트래픽에서 가볍습니다. 임의의 사용자 코드를 실행하는 런타임을 띄우지 않습니다.
• 그래서 쌉니다. 요금이 낮은 것은 인심이 아니라 구조에서 나옵니다.

실행 경로도 한 벌입니다. 직접 호출, 콘텐츠 변경 이벤트, Cron 스케줄러 모두 같은 Script 를 씁니다 — 스케줄에 걸어 둔 작업을 지금 한 번만 돌려야 할 때도 그냥 호출하면 됩니다. 이메일 발송처럼 매번 함수로 만들던 것도 문장 하나입니다.

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

Appwrite 는 개발자 플랫폼입니다. 콘솔은 잘 만들어져 있지만 스키마와 권한과 함수를 다루는 자리이고, 마케터가 문구를 고치러 들어갈 곳이 아닙니다.

Weegloo 는 비개발자에게 더 좋은 선택이고, 이유가 있습니다.

• 콘솔이 곧 제품입니다. 콘텐츠·미디어·회원·권한을 거기서 관리합니다.
• 검증은 클릭 몇 번입니다. 값의 범위·고유값·형식은 필드의 설정이지 코드가 아닙니다.
• 서버 로직이 코드가 아니라 DSL 입니다. 그 문장마저 AI 에게 말하면 대신 써 줍니다.
• 고를 스택이 없습니다. 붙이고 잇는 일이 아예 생기지 않습니다.

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

Appwrite 에서 백엔드 부품을 다 받아도 화면은 여전히 직접 만들어야 합니다. Weegloo 에는 그 화면까지 받아 오는 길이 있습니다.

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

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

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

전부 다 쓸 필요는 없습니다

Weegloo 를 "풀스택 백엔드" 로만 이해하면 오해입니다. 필요한 부분만 써도 됩니다. 콘텐츠 관리만 Weegloo 로 하고 데이터와 인증은 Appwrite 를 계속 쓸 수 있고, 미디어와 CDN 전송만 얹을 수도 있습니다.

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

Appwrite 가 더 나은 경우

• 실시간 구독이 핵심일 때. Appwrite 의 Realtime 은 제품의 간판 기능이고, Weegloo 에는 대응물이 없습니다. 공동 편집이나 실시간 대시보드가 제품의 중심이라면 그쪽이 맞습니다.
• 오픈소스여야 하거나 직접 설치해 운영해야 할 때. Appwrite 는 자사 인프라에 올릴 수 있습니다. Weegloo 는 관리형 플랫폼이고, 인프라를 분리해야 하는 요건은 Enterprise 의 전용 클러스터로 다룹니다 — 다만 소스 코드를 손에 쥐어야 한다면 그것은 오픈소스 쪽입니다.
• 임의의 코드를 서버에서 돌려야 할 때. 특정 라이브러리를 실행하거나 직접 짠 알고리즘을 돌려야 한다면 Functions 가 맞습니다. Script 는 그 자리를 노린 물건이 아닙니다.

자주 묻는 질문

Weegloo 는 Appwrite 대안인가요?

콘텐츠가 있고 그것을 사람이 운영하는 제품에는 그렇습니다. 데이터·인증·스토리지·서버 로직이라는 같은 범위를 덮고, 거기에 CMS 급 운영 콘솔과 다국어, 리비전, 값 검증, 스케줄러가 더해집니다. 다만 실시간 구독은 Appwrite 가 하고 Weegloo 는 하지 않습니다. 그것이 핵심이라면 대안이 아닙니다.

실시간 기능이 정말 없나요?

없습니다. 실시간 구독과 오프라인 우선 동기화는 Weegloo 가 제공하지 않습니다. 콘텐츠 변경을 계기로 서버 쪽에서 무언가를 실행하는 일(웹훅·Script 트리거)은 되지만, 클라이언트가 변경을 구독해 즉시 받아 보는 것은 다른 기능이고 그쪽은 Appwrite · Firebase · Supabase 가 앞섭니다.

Appwrite Functions 가 없으면 서버 로직은 어떻게 하나요?

Script 로 합니다. 콘텐츠를 읽고 쓰고, 외부 API 를 호출하고, 메일을 보내고, 서명을 검증하고, 분기하고 반복하는 선언형 문장입니다. 코드 기반 함수를 못 만드는 것이 아니라 만들지 않는 것이고, 그 대가로 콜드 스타트가 없고 대용량 트래픽에서 가볍습니다.

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

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

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

콘솔에서 Metric 기반으로 사용량을 확인합니다. 그리고 임계치를 퍼센트로 걸어 두면 그 지점에 도달했을 때 이메일이 먼저 옵니다 — 한도를 넘고 나서 알게 되는 것이 아니라, 넘기 전에 대응할 시간을 받습니다.

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

쓸 수 있고, 이 비교에서 격차가 큰 대목입니다. Appwrite 콘솔은 개발자를 위한 화면이라 비개발자가 매일 들어갈 곳이 아니고, 그래서 팀은 결국 관리 앱을 따로 만듭니다. Weegloo 는 콘텐츠·미디어·회원· 권한을 콘솔에서 관리하고, 검증은 클릭으로 설정하며, 서버 로직은 코드가 아닌 Script 문장입니다.

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

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