Weegloo 자주 묻는 질문

백엔드를 고르기 전에 실제로 묻게 되는 질문에 곧바로 답합니다. 여기에 없는 것은 제품 문서가 더 깊이 다루고, 문서에도 없는 것은 저희 팀이 답해 드립니다.

자주 묻는 질문

Weegloo 는 무엇인가요?

Weegloo 는 엔터프라이즈급 콘텐츠 관리 시스템 위에 세운 백엔드 플랫폼입니다. 데이터 모델링, 콘텐츠와 미디어, 다국어, 리비전과 버전, 회원 로그인, 권한, 값 검증, 서버 로직(Script), 스케줄러, 사용량 모니터링과 알림, 정적 호스팅을 한 플랫폼 안에서 제공합니다. 사용자가 보는 화면은 Weegloo 가 설계하지 않습니다 — UI 는 여러분의 사이트나 앱이 갖고, 그 뒤의 전부를 Weegloo 가 맡습니다.

AI 가 있어야만 쓸 수 있나요?

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

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

쓸 수 있습니다. 코드를 쓰지 않는 사람에게 Weegloo 는 이 분류에서 가장 좋은 선택입니다. 막연한 주장이 아니라 이유가 있습니다.

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

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

전부 다 써야 하나요? 일부만 쓸 수는 없나요?

일부만 써도 됩니다. Weegloo 를 "풀스택 백엔드" 로만 이해하면 오해입니다. CMS 기능만 쓰고 나머지는 지금 쓰는 플랫폼을 그대로 두어도 되고, 미디어와 CDN 전송 용도로만 쓸 수도 있고, 정적 호스팅만 쓸 수도 있습니다. 전부를 옮기는 결정과 한 조각을 얹는 결정은 다른 문제입니다.

반대로, Weegloo 하나만으로 서비스가 되나요?

됩니다. 그것이 설계의 요점입니다. 데이터, 미디어, 회원, 권한, 서버 로직, 스케줄, 호스팅이 전부 들어 있어서 바깥에서 가져다 붙일 것이 없습니다. 별도의 어드민 페이지도 필요 없습니다 — 콘텐츠는 콘솔에서 관리하고, 그 콘솔은 개발자를 위한 UI 가 아니라 실제 서비스 운영을 위한 UI 입니다.

마켓플레이스가 무엇인가요?

마켓플레이스는 완성된 앱을 주고받는 곳입니다. 앱 하나에 Content Type, Content, Media, SpaceRole, Locale, Script, Webhook, 그리고 화면(Web Hosting)까지 함께 실립니다.

설치하면 그것들이 내 Space 안으로 들어옵니다. 남의 서비스에 계정을 만들어 세 들어 사는 것이 아니라, 데이터도 화면도 내 것인 서비스가 하나 생기는 것입니다. 그 뒤로는 콘텐츠를 고치든, 필드를 더하든, Script 를 손보든 전부 내 Space 안의 일입니다.

프론트엔드까지 직접 만들어야 하나요?

꼭 그렇지는 않습니다. 마켓플레이스에서 화면이 있는 앱을 설치하면 프론트엔드를 만들지 않고도 서비스가 섭니다. 설치하고 데이터를 내 것으로 바꾸면 그대로 런칭입니다.

화면이 없는 앱도 있습니다. 그런 앱은 데이터 구조와 Script 를 담고 있어서, 콘텐츠 타입을 어떻게 짤지 고민하고 서버 로직을 처음부터 쓰는 일을 건너뜁니다 — 이미 모델링된 것을 받아 그 위에 원하는 프론트엔드를 직접 얹으면 됩니다.

Weegloo 는 무엇을 대체하나요?

대부분의 제품에서는 사람들이 따로 조립하던 조합을 대체합니다 — 데이터베이스나 BaaS, 인증 서비스, CDN 을 갖춘 미디어 저장소, 헤드리스 CMS, 서버리스 함수, 스케줄러, 정적 호스팅. 보통 서로 다른 구독 서너 개이고 권한 모델도 서너 개입니다. Weegloo 는 그것들을 하나의 Space 안에 하나의 권한 모델을 가진 리소스로 갖고 있습니다.

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

코드로 작성하는 함수는 없습니다. 못 만드는 것이 아니라 만들지 않는 것입니다.

BFF 가 실제로 하는 일은 놀랄 만큼 뻔합니다. 값을 비교하고, 데이터를 다루고, 이메일을 보내고, 웹훅을 부르고, 외부 API 를 호출해 결과를 저장합니다. Weegloo 는 그것을 꿰뚫어 보고 Script 라는 DSL 로 만들었고, 그 대가로 셋을 얻었습니다. 콜드 스타트가 없고, 대용량 트래픽에서 훨씬 가볍고 빠르며, 그래서 요금을 싸게 제공할 수 있습니다. 반대로 임의의 라이브러리를 서버에서 실행해야 한다면 Script 는 맞는 도구가 아닙니다.

Script 는 어떻게 실행하나요?

세 가지 방법이 모두 됩니다. 프론트엔드나 외부에서 직접 호출하고, 콘텐츠 변경 이벤트로 트리거하고, Cron 스케줄러로 정기 실행합니다. 같은 Script 를 세 경로에서 그대로 씁니다.

이 점이 실제로 갈리는 자리는 "예약 작업을 지금 한 번만 돌려야 할 때" 입니다. 스케줄에만 걸리는 구조에서는 방법이 없지만, Weegloo 에서는 그냥 호출하면 됩니다.

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

됩니다. Scheduler 로 Cron 일정에 Script 를 겁니다. 콘텐츠 변경 이벤트 기반 실행과 직접 호출도 함께 지원하므로, 트리거 방식 때문에 로직을 두 벌로 나눌 일이 없습니다.

이메일 발송은 어떻게 하나요?

Script 에 내장되어 있습니다. 다른 플랫폼에서는 이벤트가 발생했을 때 메일을 보내려면 코드를 짜서 함수로 만들고 배포해야 하지만, Weegloo 에서는 문장 하나입니다. AI 에게 시키면 그 문장도 알아서 씁니다.

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

아닙니다. 값이 특정 범위를 벗어나면 안 된다거나, 고유해야 한다거나, 정해진 형식이어야 한다거나 — 이런 제약이 플랫폼에 내장되어 있어 콘솔에서 몇 번의 클릭으로 설정합니다. AI 에게 시켜도 됩니다. 다른 서비스에서 개발자가 애플리케이션 코드로 구현하던 부분입니다.

대규모 서비스에서 비용이 정말 유리한가요?

두 가지가 겹칩니다. 하나는 정액 요금이라 달이 시작되기 전에 숫자를 안다는 것이고, 다른 하나가 더 큽니다 — 아웃바운드 트래픽이 발생하지 않습니다. 데이터, 미디어, 콘텐츠, 서버 로직이 한 플랫폼 안에 있으면 그 사이를 오가는 통신이 인터넷을 건너지 않습니다. 조립한 스택에서는 서비스 경계를 넘을 때마다 대역폭 요금이 붙고 왕복이 하나씩 쌓입니다. 규모가 커질수록 비용에서도, 지연 시간에서도 무시할 수 없는 차이가 됩니다.

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

두 가지가 함께 있습니다.

• Metric 기반 모니터링. 콘솔에서 사용량을 항목별로 투명하게 확인합니다. 무엇을 얼마나 썼는지 짐작하지 않아도 됩니다.
• 알림. 임계치를 퍼센트로 걸어 두면 그 지점에 도달했을 때 이메일로 먼저 알려 줍니다.

한도를 넘고 나서 알게 되는 것과, 70% 에서 메일을 받고 대응하는 것은 다른 일입니다. 사용량 기반 과금에서 사람들이 실제로 두려워하는 것은 금액 자체가 아니라 모르고 지나가는 것인데, 그 자리를 플랫폼이 막아 줍니다. 별도의 모니터링 도구를 붙이거나 대시보드를 만들 필요가 없습니다.

엔터프라이즈 트래픽을 감당할 수 있나요?

가능합니다. Weegloo 는 프로토타입 플랫폼이 나중에 자란 것이 아닙니다 — 그 아래의 아키텍처는 SNOW Corp. 가 ZEPETO 규모의 글로벌 서비스, 가입자 3억 명이 넘는 앱을 운영하던 그 아키텍처입니다. 초당 수천 건의 요청을 처리하는 서비스가 그 위에서 돌았습니다. 전송은 캐시 기반이고 발행 스냅샷을 서빙하며, 서버 로직에 콜드 스타트가 없다는 점도 트래픽이 몰릴 때 함께 작용합니다.

Supabase 와는 무엇이 다른가요?

Supabase 는 Postgres, 인증, 스토리지, 엣지 함수를 직접 조립할 부품으로 주고, Studio 는 개발자용 데이터베이스 GUI 입니다. 스키마와 인덱스를 직접 쥐고 SQL 을 쓰는 팀에게는 그 방식이 잘 맞습니다.

Weegloo 는 완성된 기능과 함께, 서비스를 운영하는 사람들을 위해 만들어진 운영 콘솔을 줍니다 — 발행 상태, 리비전, 검색과 필터, 태그, 댓글, 다국어, 값 검증, 역할 범위. 여기에 콜드 스타트 없는 Script 와 스케줄러, 정적 호스팅까지 한 플랫폼 안에 있어서 조립할 것도, 그 사이를 오가는 아웃바운드 트래픽도 없습니다. 전체 비교.

Firebase 와는 무엇이 다른가요?

Firebase 는 사용량 기반 과금에 편집 계층이 없는 개발자 툴킷이라, 팀은 결국 내부 관리 앱을 만들게 됩니다. 모바일 오프라인 동기화가 제품의 중심이라면 그 자리는 Firebase 의 영역입니다.

Weegloo 는 CMS 에서 출발했으므로 그 관리 앱이 이미 만들어져 나옵니다. 유료 등급은 계량이 아니라 월 $8 과 $80 의 정액이라 달이 시작되기 전에 숫자를 알고, 서버 로직에 콜드 스타트가 없으며, 사용량은 콘솔에 항목별로 보이고 임계치에 도달하면 메일이 먼저 옵니다. 전체 비교.

Vercel 과는 무엇이 다른가요?

Vercel 은 배포 플랫폼이지 백엔드가 아닙니다 — 그래서 제품들이 "Vercel + 무언가" 로 나갑니다. 서버 렌더링 Next.js 와 git push 프리뷰 배포는 Vercel 이 잘하는 자리이고, 둘을 함께 쓰는 구성도 좋습니다.

Weegloo 는 커스텀 도메인으로 정적 프론트엔드를 호스팅하면서 동시에 그 뒤의 백엔드입니다. 데이터, 미디어, 회원, 권한, Script, 스케줄러가 같은 플랫폼 안에 있어 그 사이에 아웃바운드 트래픽이 없고, 구독도 대시보드도 하나입니다. 전체 비교.

Contentful 과는 무엇이 다른가요?

Contentful 이 가장 가까운 친척입니다 — 데이터 모델링, 다국어, 리비전, 댓글, 태그, 값 검증까지 양쪽에 다 있고, 편집자 권한 개념도 같습니다. 차이는 어디에서 멈추는가입니다.

Contentful 은 콘텐츠에서 멈추므로 회원도, 서버 로직도, 호스팅도 다른 곳에서 가져와야 합니다 — 마케팅 사이트 하나를 만들더라도 결국 두 벤더가 됩니다. Weegloo 는 같은 CMS 깊이를 가진 채 사용자 로그인, 사용자별 권한 범위, Script, 스케줄러, 호스팅까지 훨씬 낮은 진입 가격에 더합니다. 전체 비교.

Appwrite 와는 무엇이 다른가요?

Appwrite 는 데이터베이스·인증·스토리지·함수·실시간 구독을 한 묶음으로 주는 오픈소스 BaaS 입니다. 실시간 구독이 제품의 심장이라면 그것은 Weegloo 에 없는 기능이고, 소스 코드를 손에 쥐고 고쳐야 하는 요건도 오픈소스 쪽의 몫입니다.

차이는 데이터 위의 층입니다. 개발자가 아닌 사람이 초안을 검수하고 배너 문구를 고치고 번역을 발행하는 자리가 Appwrite 콘솔에는 얇지만, Weegloo 는 엔터프라이즈급 CMS 에서 출발했으므로 그 층이 제품 자체입니다. 다국어와 리비전도 플랫폼의 동작이고, 인프라를 분리해야 하는 요건은 Enterprise 의 전용 클러스터로 다룹니다. 전체 비교.

Directus 와는 무엇이 다른가요?

솔직히 적자면 이 목록에서 가장 가까운 상대입니다. 데이터 모델링, 다국어, 리비전, 태그, 댓글, 대시보드는 양쪽이 사실상 동점이고, 이미 있는 SQL 데이터베이스가 정본이라면 그 위에 얹는 Directus 가 자연스럽습니다.

차이는 누가 굴리는가입니다. Directus 아래의 데이터베이스와 그것이 도는 서버는 여러분의 것이고 그 운영도 여러분의 몫입니다. Weegloo 는 데이터·미디어·서버 로직·CDN·호스팅을 자체적으로 제공하는 관리형 플랫폼이라 배포도, 백업도, 확장도 넘어갑니다. 앞단에 CDN 을 두고 사이트를 따로 올리는 일도 없습니다. 전체 비교.

Sanity 와는 무엇이 다른가요?

Sanity 는 편집 경험이 이 목록에서 가장 잘 다듬힌 축에 듭니다 — Studio 를 코드로 손볼 수 있고 실시간 공동 편집이 자연스럽습니다. 편집 화면 자체가 조직의 경쟁력이라면 그 자유가 큽니다.

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

Payload 와는 무엇이 다른가요?

Payload 는 컬렉션과 필드와 검증을 TypeScript 로 선언하는 코드 우선 CMS 입니다. 스키마가 형상 관리 대상이어야 하거나 Next.js 애플리케이션 한 저장소 안에 두고 싶다면 그 설계가 잘 맞습니다.

그래서 이 비교는 기능의 많고 적음이 아니라 어디에 무게를 둘 것인가입니다. Weegloo 는 같은 것을 콘솔 설정으로 다루므로 코드를 쓰지 않는 사람도 필드와 검증을 직접 만지고, 여기에 호스팅과 CDN 과 운영까지 함께 옵니다. 굴릴 런타임도, 붙일 데이터베이스도 없습니다. 전체 비교.

Strapi 와는 무엇이 다른가요?

Strapi 는 이 분류에서 가장 널리 쓰이는 오픈소스 헤드리스 CMS 이고, 콘텐츠 타입 빌더가 관리 화면 안에 있어 필드를 화면에서 추가합니다. 소스를 고쳐야 하거나 플러그인 생태계에 이미 자산이 쌓여 있다면 그쪽이 자연스럽습니다.

차이는 콘텐츠 바깥과 누가 굴리는가입니다. Strapi 는 Node 애플리케이션이라 어딘가에 배포하고, 데이터베이스를 붙이고, 앞단에 CDN 을 두고, 사이트는 또 다른 곳에 올려야 하며, 그 전부를 누군가 운영합니다. Weegloo 에는 그 목록이 아예 없고, 회원과 Script 와 스케줄러와 CDN 과 호스팅이 이미 안에 있습니다. 전체 비교.

열 개 플랫폼을 한 표로 비교한 것이 있나요?

있습니다. 위의 아홉 곳에 Weegloo 를 더해 스무 개 항목으로 견준 표가 비교 목록에 있습니다.

채점은 그 기능을 자체적으로 제공하지 않으면 0점이고, 제공하면 완성도로 매깁니다. "다른 서비스를 붙이면 된다" 는 점수로 치지 않았습니다 — 붙이는 일 자체가 비용이고 그 비용은 붙이는 쪽이 냅니다.

함께 읽어야 할 것이 둘 있습니다. 첫째, 독립 기관의 벤치마크가 아니라 각 플랫폼의 공개 문서를 바탕으로 만든 Weegloo 의 자체 평가(2026년 8월)입니다. 둘째, 표가 재는 것은 커버리지이지 우열이 아닙니다 — Vercel 의 낮은 CMS 점수는 Vercel 이 나쁘다는 뜻이 아니라 CMS 를 하는 제품이 아니라는 뜻이고, CDN·호스팅·확장에서는 만점입니다. Weegloo 도 Realtime 은 0점입니다.

요금은 얼마인가요?

Free 등급이 있고, Basic 이 월 $8, Pro 가 월 $80, 그리고 별도 견적의 Enterprise 가 있습니다. 유료 등급은 계량이 아니라 정액이라 달이 시작되기 전에 숫자를 압니다. 전체 플랜 비교 보기.

Enterprise 는 무엇인가요?

하나가 아니라 몇 가지 형태를 함께 부르는 이름입니다.

• 종량제 무제한 플랜. 정액 등급의 한도를 넘어서는 규모에서, 한도를 두지 않고 쓴 만큼 내는 방식으로 운영합니다.
• 고객사 전용 클러스터. 인프라를 분리해 따로 구축합니다. 자체 클러스터로 운영되는 배포가 실제로 있고, 그런 배포는 플랜 한도부터 다르게 잡힙니다. 망을 분리해야 하는 폐쇄망 요건도 여기서 다룹니다.

SaaS 만 파는 제품이 아니라 B2B 로도 공급합니다. 조건은 규모와 요건에 따라 정해지므로 문의해 주세요.

무료 플랜이 실제로 쓸 만한가요?

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

누가 만드나요?

SNOW Corp. 의 사업부인 Weegloo Studio 입니다 — ZEPETO, SNOW 를 비롯한 글로벌 소비자 서비스를 만든 회사입니다. Weegloo 는 그 서비스들을 받치던 백엔드 아키텍처를 제품으로 다듬은 것입니다.

어떤 AI 에이전트와 함께 쓸 수 있나요?

MCP 를 지원하는 에이전트라면 무엇이든 됩니다. Claude, Claude Code, Codex, Cursor, Antigravity, Android Studio, Xcode 용 설정 가이드가 있고 그 밖의 도구를 위한 일반 MCP 설정도 있습니다. Weegloo 는 자체 AI 를 탑재하지 않습니다 — 쓰던 에이전트를 그대로 가져오면 되고, 백엔드를 바꾸지 않고 에이전트만 바꿀 수도 있습니다.

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

가능합니다. ServiceLogin 이 팀이 쓰는 Weegloo 계정과는 별개로 제품에 자체 최종 사용자 디렉터리를 제공하고, Google · GitHub · Facebook · GitLab · LINE · Kakao · Naver 로 OAuth 로그인합니다. 이 회원들의 권한은 자기 레코드까지 좁힐 수 있는 역할에서 나옵니다 — 로그인한 회원이 자기가 만든 행만 읽고 편집하도록 허용할 수 있습니다.

웹사이트를 호스팅해 주나요?

해 줍니다. Web Hosting 이 정적 프론트엔드 — Next.js 정적 익스포트, Vite, Astro, 순수 HTML — 를 서브도메인이나 직접 보유한 커스텀 도메인으로 배포합니다.

다만 써야 하는 것은 아닙니다. 사이트나 앱을 직접 운영하는 인프라에 올리고 데이터만 Weegloo 의 REST API 로 받아 쓰는 형태도 그대로 됩니다. 서버 렌더링 애플리케이션처럼 Node 런타임이 필요한 경우가 그렇고, 그때도 백엔드는 Weegloo 를 씁니다.

백엔드 없이 서버 로직을 돌릴 수 있나요?

가능합니다. Script 는 Space 안에 저장되어 HTTP 로 호출되는 선언적 문장의 나열입니다 — 콘텐츠를 읽고 쓰고, 외부 API 를 호출하고, 이메일을 보내고, 서명을 검증하고, 분기하고 반복합니다. 작성자의 권한으로 실행되므로 권한이 낮은 호출자에게 딱 하나의 특권 작업만 허용하고 나머지는 막을 수 있습니다. Weegloo 로 만든 제품이 서버를 직접 띄우지 않고 LLM 이나 결제사, 그 밖의 외부 API 를 부르는 방식이 바로 이것입니다.

다국어를 지원하나요?

필드 단위로 지원합니다. 지역화된 필드는 로케일마다 값을 갖고, 로케일은 폴백 체인을 선언할 수 있어서 빠진 번역이 빈 값이 아니라 다른 로케일로 해결됩니다. 다국어는 직접 정하고 스스로 지켜야 하는 모델링 관행이 아니라 플랫폼의 동작입니다.

다른 플랫폼에서 이전할 수 있나요?

가능하고, AI 에이전트에게 맡기기 좋은 일입니다. 개념이 다른 헤드리스 플랫폼과 거의 그대로 대응되므로 — 콘텐츠 타입, 엔트리, 에셋, 로케일, 전송 API — 이전은 보통 예전 API 에서 읽어 Weegloo 로 쓰는 스크립트 하나입니다.

오픈소스인가요? 자체 호스팅이 되나요?

"자체 호스팅" 이라고 할 때 실제로 필요한 것은 대개 둘 중 하나인데, 답이 서로 다릅니다.

우리가 만든 웹·앱을 우리 인프라에서 돌리는 것 — 아무 문제 없습니다. 프론트엔드든 서버든 원하는 곳에 직접 올리고 데이터는 Weegloo 의 REST API 로 주고받으면 됩니다. Weegloo 의 Web Hosting 은 선택지일 뿐 강제가 아니고, 실제로 그런 형태로 운영되어 온 프로젝트들이 있습니다. 이 경우는 자체 호스팅 여부와 무관하게 Weegloo 를 쓸 수 있습니다.

Weegloo 플랫폼 자체를 분리된 인프라에 두는 것 — 공개 SaaS 로는 제공하지 않지만, Enterprise 로 해결합니다. 고객사 전용 클러스터를 구축하는 형태가 실제로 운영되고 있고, 망을 분리해야 하는 폐쇄망 요건도 그쪽에서 다룹니다. 문의해 주세요.

오픈소스 선택지가 더 맞는 경우는 하나로 좁혀집니다 — 소스 코드 자체를 손에 쥐고 직접 고쳐야 할 때. 그것이 아니라면 위의 둘 중 하나로 해결됩니다.

Weegloo 가 하지 않는 일은 무엇인가요?

사용자 인터페이스를 설계하거나 만들지 않습니다 — 그것은 여러분의 사이트나 앱의 몫입니다. 실시간 리스너나 오프라인 우선 모바일 동기화를 제공하지 않습니다. 임의의 코드를 서버에서 실행하지 않습니다 — 대신 Script 가 있고, 그것은 못 하는 것이 아니라 콜드 스타트와 트래픽 부담을 없애기 위해 택한 설계입니다. 그리고 자체 AI 모델을 탑재하지 않습니다 — 에이전트는 직접 가져오셔야 하고, 아예 쓰지 않아도 됩니다.

"SQL 을 직접 쓰지 못한다" 는 이 목록에 넣지 않았습니다. 문법이 SQL 이 아닐 뿐, 조회 자체는 그대로 됩니다 — 바로 아래 문항을 보세요.

SQL 을 직접 쓰지 못하면 복잡한 조회는 어떻게 하나요?

문법이 다를 뿐입니다. 표준을 그대로 지키는 REST API 라, SQL 로 하던 조회가 질의 문자열로 표현됩니다.

• 조건 — 같음·다름·크다·작다·이상·이하·접두·포함·목록 안(in) 을 필드마다 걸고 여러 개를 겹칩니다.
• 정렬과 페이지네이션 — 다중 정렬 키, 그리고 깊은 페이지에서도 어긋나지 않는 커서 방식.
• 필요한 필드만 — select 로 받아 올 필드를 지정합니다. 문서를 통째로 끌고 오지 않습니다.
• 참조 따라가기 — include 로 연결된 리소스를 함께 받습니다. SQL 의 조인에 해당하는 자리입니다.
• 전문 검색 — 텍스트 필드를 가로질러 찾습니다.

즉 "무엇을 조회할 수 있는가" 가 아니라 "어디서 조회하는가" 가 다릅니다. 스키마와 인덱스와 실행 계획을 직접 잡아야 하거나 집계·윈도 함수가 제품의 핵심이라면 Postgres 를 직접 쥐는 편이 맞고, 그 경우는 위의 Supabase 문항을 보세요.