Weegloo vs Firebase

한 줄로 답하면

Firebase 는 개발자를 위한 도구 모음이고, Weegloo 는 서비스를 운영하기 위한 플랫폼입니다.

Firebase 는 Firestore, Authentication, Cloud Functions, Cloud Storage, Hosting 을 줍니다. 성숙하고 문서도 잘 갖춰진 구성 요소들이고 아래에는 구글의 인프라가 있습니다. 다만 데이터 위의 층은 주지 않습니다 — 개발자가 아닌 사람이 초안을 검수하고, 오타를 고치고, 배너 이미지를 바꾸고, 일본어 번역을 발행하는 그 자리 말입니다.

Weegloo 는 엔터프라이즈급 CMS 위에 세운 백엔드 플랫폼입니다. 콘솔이 제품의 일부라 운영 계층이 첫날부터 존재하고, 서버 로직은 콜드 스타트가 없는 Script 로 처리합니다.

각각이 그대로 내어 주는 것

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

1. Firebase 에는 편집 계층이 없고, 결국 필요해진다

출시 이후까지 살아남은 Firebase 프로젝트는 거의 모두 내부 관리 앱을 하나 기르게 됩니다. 누군가는 FAQ 문구를 바꾸고, 지난 프로모션을 내리고, 사용자 제보를 승인하고, 다음 주 히어로 이미지를 올려야 합니다 — 그리고 그 사람들이 Firebase Console 을 열어 Firestore 문서를 손으로 고쳐서는 안 됩니다.

그래서 팀은 관리자 페이지를 만듭니다. 그다음 거기에 로그인이 필요해지고, 역할이 필요해지고, 미리보기가 필요해지고, 누가 무엇을 바꿨는지 남기는 기록이 필요해집니다. 그 프로젝트는 원래 받쳐 주려던 기능 개발보다 커지는 일이 잦습니다.

Weegloo 는 콘텐츠 관리 시스템에서 출발했기 때문에 이것이 프로젝트가 아닙니다. 발행 상태, 리비전과 버전, 필드 단위 다국어, 태그, 댓글, 콘텐츠를 가로지르는 검색, "이 사용자가 만든 것만" 까지 좁혀지는 역할이 플랫폼의 동작입니다. 별도의 어드민 페이지를 만들 필요가 없습니다 — 콘솔이 곧 운영 화면이고, 개발자용 UI 가 아니라 서비스를 운영하는 사람을 위한 UI 입니다.

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

Weegloo 에는 코드로 작성하는 서버리스 함수가 없습니다. 못 하는 것이 아니라 하지 않기로 한 것이고, Cloud Functions 를 써 본 사람이라면 이유를 곧바로 알아봅니다.

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

• 콜드 스타트가 없습니다. Cloud Functions 는 한동안 호출이 없으면 다음 첫 요청이 눈에 띄게 느려지고, 그것을 피하려고 최소 인스턴스를 켜 두면 그만큼 요금이 붙습니다. Script 에는 기동할 컨테이너 자체가 없습니다.
• 대용량 트래픽에서 가볍습니다. 임의의 사용자 코드를 실행하는 런타임을 띄우지 않으므로, 트래픽이 몰릴 때 처리 부담이 다른 성질을 갖습니다.
• 그래서 쌉니다. 요금이 낮은 것은 인심이 아니라 구조에서 나옵니다.

실행 경로도 한 벌로 정리됩니다. 직접 호출, 콘텐츠 변경 이벤트, Cron 스케줄러 셋 모두 같은 Script 를 씁니다. Firebase 에서는 HTTP 함수와 이벤트 트리거 함수와 Cloud Scheduler 를 각각 구성해야 하고, 스케줄에 걸어 둔 작업을 지금 한 번만 돌리는 일이 특히 번거롭습니다. Weegloo 에서는 그냥 호출하면 됩니다.

이메일 발송처럼 매번 함수로 만들던 것도 Script 안에 문장으로 들어 있습니다. 외부 이벤트가 왔을 때 메일을 보내려고 함수를 짜고 배포할 일이 없습니다.

3. 계량기가 아니라 정액 요금, 그리고 밖으로 나가지 않는 트래픽

Firebase 의 Blaze 플랜은 사용량 기반입니다. 트래픽이 튀거나 질의 하나가 폭주하면 그것이 곧 청구 사건이 되고, 트래픽이 오기 전에는 청구서의 모양을 예측하기 어렵습니다.

Weegloo 의 유료 등급은 정액입니다. Basic 월 $8, Pro 월 $80. 달이 시작되기 전에 숫자를 알고, 그 값이 데이터·미디어·회원·권한·서버 로직·호스팅을 함께 덮습니다.

정액만 있는 것도 아닙니다. 쓴 만큼 내는 방식이 맞는 규모라면 Enterprise 의 종량제 무제한 플랜이 있습니다. 과금 방식 때문에 플랫폼을 바꿀 일이 없다는 뜻입니다.

그리고 한도에 가까워지는 것을 미리 압니다. Weegloo 는 Metric 기반으로 사용량을 콘솔에 투명하게 보여 주고, 임계치를 퍼센트로 걸어 두면 그 지점에 도달했을 때 이메일로 먼저 알려 줍니다. 청구서를 받고 나서 알게 되는 것과, 70% 에서 메일을 받고 대응하는 것은 다른 일입니다. 사용량 기반 과금에서 사람들이 실제로 두려워하는 것은 금액 자체가 아니라 모르고 지나가는 것인데, 그 자리를 플랫폼이 막아 줍니다.

여기에 하나가 더 붙습니다. 데이터, 미디어, 콘텐츠, 서버 로직이 한 플랫폼 안에 있으면 그 사이를 오가는 통신이 인터넷을 건너지 않습니다. 규모가 커질수록 아웃바운드 트래픽 비용과 지연 시간 양쪽에서 갈립니다 — 조립한 스택은 서비스 경계를 넘을 때마다 왕복이 하나씩 쌓이고, 그 대역폭이 청구서에 그대로 올라갑니다.

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

Firebase Console 은 잘 만들어진 화면이지만 엔지니어를 위한 대시보드입니다. Firestore 문서를 들여다보고, Security Rules 를 쓰고, Cloud Functions 를 배포하는 자리입니다. 마케터가 배너 문구를 고치러 들어갈 곳이 아닙니다.

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

• 콘솔이 곧 제품입니다. 콘텐츠, 미디어, 회원, 권한을 거기서 관리합니다. Firebase 프로젝트가 결국 하나씩 기르게 되는 그 내부 관리 앱이, Weegloo 에서는 이미 만들어져 나옵니다.
• 검증은 클릭 몇 번입니다. 값의 범위·고유값·형식은 필드의 설정이지, Security Rules 나 애플리케이션 코드에 넣고 시험해야 할 로직이 아닙니다.
• 서버 로직이 코드가 아니라 DSL 입니다. 메일 발송, 외부 API 호출, 정기 작업이 전부 Script 문장이고, 그 문장은 AI 에게 한 문장으로 말하면 알아서 씁니다. 함수를 짜고 배포할 일이 없습니다.
• 고를 스택이 없습니다. Firestore 와 Functions 와 Storage 와 Hosting 을 각각 붙이고 그 사이를 Security Rules 로 맞추는 일이 아예 생기지 않습니다.

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

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

Firebase 의 Extensions 는 기능 조각을 얹어 줍니다. Weegloo 의 마켓플레이스는 층위가 달라서, 서비스 한 벌이 통째로 설치됩니다.

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

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

전부 다 쓸 필요는 없습니다

Weegloo 를 "풀스택 백엔드" 로만 이해하면 오해입니다. 필요한 부분만 써도 됩니다. 콘텐츠 관리만 Weegloo 로 하고 인증과 데이터는 Firebase 를 계속 쓸 수 있고, 미디어와 CDN 전송만 얹을 수도 있습니다. 전부를 옮기는 결정과 한 조각을 더하는 결정은 다른 문제입니다.

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

Firebase 가 더 나은 경우

• 실시간·오프라인 우선 모바일 앱. Firestore 의 실시간 리스너와 오프라인 캐시는 훌륭하고 Weegloo 에는 대응물이 없습니다. 공동 편집기나 실시간 멀티플레이 기능은 Firebase 의 자리입니다.
• 이미 Google Cloud 에 깊이 들어가 있을 때. 인증과 분석과 데이터 파이프라인이 이미 GCP 라면, 그 안에 머무는 데에는 실질적인 운영상의 이점이 있습니다.
• 임의의 코드를 서버에서 돌려야 할 때. 특정 라이브러리를 서버에서 실행하거나 직접 짠 알고리즘을 돌려야 한다면 Cloud Functions 가 맞습니다. Script 는 그 자리를 노린 물건이 아닙니다.

Firebase 에 없고 Weegloo 에 있는 것

• 한 개발자가 문서를 들여다보기 위한 것이 아니라, 여러 사람이 동시에 서비스를 운영하도록 설계된 콘솔 — 별도의 어드민 페이지가 필요 없습니다.
• 직접 정하고 스스로 지켜야 하는 모델링 관행이 아니라, 폴백 체인까지 갖춘 필드 단위 다국어.
• 발행이 일급 상태 기계로 있는 것, 그리고 리비전과 버전 관리 — 무엇이 라이브이고 무엇이 편집 중인지, 무엇이 언제 바뀌었는지가 플랫폼에 남습니다.
• 콜드 스타트 없는 Script, 그리고 그것을 부르는 세 경로(직접 호출 · 콘텐츠 이벤트 · 스케줄러).
• 클릭으로 거는 데이터 검증 — 범위, 고유값, 형식.
• Metric 기반 사용량 모니터링과 임계치 알림 — 콘솔에서 사용량을 보고, 퍼센트로 걸어 둔 지점에 도달하면 이메일이 먼저 옵니다.
• 검증된 규모. Weegloo 아래의 아키텍처는 SNOW Corp. 가 ZEPETO 규모의 글로벌 서비스 — 가입자 3억 명 이상 — 를 운영하던 그 아키텍처입니다.

자주 묻는 질문

Weegloo 는 Firebase 대안인가요?

콘텐츠 중심의 서비스 운영 워크로드에는 그렇습니다 — 누군가 편집하는 데이터가 있고, 로그인하는 회원이 있고, 전송할 미디어가 있고, 올려야 할 프론트엔드가 있는 제품입니다. 다만 실시간 협업이나 오프라인 우선 모바일 동기화에는 대안이 아닙니다. 그것은 Firestore 가 하고 Weegloo 는 하지 않는 일입니다.

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

Script 로 합니다. 콘텐츠를 읽고 쓰고, 외부 API 를 호출하고, 메일을 보내고, 서명을 검증하고, 분기하고 반복하는 선언형 문장입니다. 코드 기반 함수를 못 만드는 것이 아니라 만들지 않는 것이고, 그 대가로 콜드 스타트가 없고 대용량 트래픽에서 가볍고 요금이 쌉니다. 반대로 임의의 라이브러리를 서버에서 돌려야 한다면 Script 는 맞는 도구가 아닙니다.

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

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

Firebase 보다 저렴한가요?

더 싸고, 더 예측 가능합니다. Weegloo 의 첫 유료 등급은 월 $8 이고 그 값이 데이터·미디어·회원· 권한·서버 로직·호스팅을 함께 덮습니다. Firebase 에서 같은 범위를 맞추려면 Blaze 플랜 위에 관리 화면을 직접 만들고, 서비스 사이를 오가는 아웃바운드 트래픽 비용까지 얹어야 합니다.

과금 방식이 정액뿐인 것도 아닙니다. 쓴 만큼 내는 방식이 맞는 워크로드라면 Enterprise 의 종량제 무제한 플랜이 있습니다. 즉 "정액이냐 종량이냐" 는 둘 중 하나를 포기하는 선택이 아니라, 규모에 따라 고르는 문제입니다.

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

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

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

Firestore 를 대체할 수 있나요?

구조화된 애플리케이션·콘텐츠 데이터라면 가능합니다 — Content Type 으로 모델링하고 전송 API 로 읽습니다. 실시간 리스너와 오프라인 우선 동기화는 대체할 수 없습니다. 그것은 Weegloo 가 제공하지 않는 Firestore 의 기능입니다.

Security Rules 같은 것을 작성해야 하나요?

아닙니다. 권한은 액션마다 필터를 거는 역할이고, 값의 제약(범위·고유값·형식)은 필드를 정의할 때 콘솔에서 함께 설정합니다. 작성하고 테스트하고 배포하는 규칙 언어가 아니라 플랫폼 설정이며, 배포 없이 바뀝니다.

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

쓸 수 있고, 이 비교에서 격차가 가장 큰 대목입니다. Firebase Console 은 엔지니어용 대시보드라 비개발자가 매일 들어갈 화면이 아니고, 그래서 팀은 결국 관리 앱을 따로 만듭니다. Weegloo 는 콘텐츠·미디어·회원·권한을 콘솔에서 관리하고, 검증은 클릭으로 설정하며, 서버 로직은 코드가 아니라 Script 문장입니다 — 그 문장은 AI 에게 평범한 한 문장으로 말하면 대신 써 줍니다.

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

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

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

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