Weegloo vs Directus

한 줄로 답하면

Directus 는 내 데이터베이스를 감싸는 오픈소스이고, Weegloo 는 운영까지 포함한 관리형 플랫폼입니다.

솔직히 적자면, Directus 는 이 비교 목록에서 가장 강한 상대입니다. 데이터 모델링, 콘텐츠 관리, 다국어, 리비전, 태그, 댓글, 대시보드 — 이 목록은 양쪽이 사실상 동점입니다. Directus 를 써 본 사람이 Weegloo 를 열면 낯설지 않을 것이고, 그 반대도 마찬가지입니다.

차이는 어디에 서 있느냐입니다. Directus 는 이미 있는 SQL 데이터베이스 위에 얹는 계층이고, 그 데이터베이스와 그것이 도는 서버는 여러분의 것입니다. Weegloo 는 데이터·미디어·서버 로직· CDN·호스팅을 자체적으로 제공하는 관리형 플랫폼입니다. 어느 쪽이 나은지는 이미 데이터베이스를 갖고 있는지, 그리고 그것을 계속 직접 운영할 생각인지에 달려 있습니다.

각각이 그대로 내어 주는 것

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

1. 이미 데이터베이스가 있는가

이것이 첫 갈림길이고, 나머지는 대체로 여기서 따라옵니다.

이미 SQL 데이터베이스가 있고 그것이 정본이라면 Directus 가 강합니다. 스키마를 옮기지 않고 그 위에 관리 화면과 API 를 얹을 수 있습니다. 기존 시스템이 같은 데이터베이스를 계속 쓰는 상황이라면 이보다 자연스러운 선택이 드뭅니다.

새로 시작하거나 데이터베이스를 직접 운영하고 싶지 않다면 이야기가 달라집니다. Directus 를 쓴다는 것은 데이터베이스와 그 위의 인스턴스를 누군가 운영한다는 뜻이고, 백업·업그레이드·확장이 그 사람의 일입니다. Weegloo 에서는 그 일 자체가 없습니다.

2. 콘텐츠 바깥 — 호스팅, CDN, 그리고 콜드 스타트

데이터와 CMS 가 동점이므로 차이는 그 바깥에서 벌어집니다.

사이트는 어딘가에 올라가야 합니다. Directus 는 호스팅을 하지 않으므로 Vercel 이나 Netlify 를 붙이고, CDN 도 앞단에 따로 둡니다. 업체가 둘 셋이 되고, 그 사이를 오가는 아웃바운드 트래픽이 비용과 지연 시간으로 쌓입니다. Weegloo 는 Web Hosting 과 CDN 이 기능으로 들어 있어 그 왕복이 없습니다.

서버 로직에는 콜드 스타트가 없습니다. Weegloo 의 Script 는 기동할 컨테이너 자체가 없고, 직접 호출 · 콘텐츠 변경 이벤트 · Cron 스케줄러 셋 모두 같은 Script 를 씁니다. 이메일 발송은 문장 하나입니다.

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

Directus 의 마켓플레이스는 확장을 설치해 Directus 를 넓힙니다. Weegloo 의 마켓플레이스는 넓히는 쪽이 아니라 통째로 가져오는 쪽입니다 — 서비스 한 벌이 설치됩니다.

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

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

전부 다 쓸 필요는 없습니다

필요한 부분만 써도 됩니다. Directus 로 데이터를 계속 다루면서 Weegloo 는 미디어와 CDN 전송에만 쓸 수도 있고, 정적 호스팅만 쓸 수도 있습니다. 전부를 옮기는 결정과 한 조각을 얹는 결정은 다른 문제입니다.

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

Directus 가 더 나은 경우

• 이미 있는 SQL 데이터베이스가 정본일 때. 스키마를 옮기지 않고 그 위에 얹는다는 것은 Weegloo 가 줄 수 없는 것입니다. 다른 시스템이 같은 데이터베이스를 계속 읽고 쓴다면 특히 그렇습니다.
• SQL 을 직접 쥐어야 할 때. 집계와 윈도 함수, 직접 만든 인덱스와 실행 계획이 제품의 핵심이라면 데이터베이스를 직접 다루는 쪽이 맞습니다.
• 오픈소스여야 하거나 직접 설치해 운영해야 할 때. 소스 코드를 손에 쥐고 고쳐야 한다면 Directus 입니다. 인프라 분리나 폐쇄망만이 요건이라면 Weegloo 의 Enterprise 전용 클러스터로도 해결됩니다.
• 실시간 구독이 필요할 때. Directus 는 제공하고 Weegloo 에는 대응물이 없습니다.
• 확장을 직접 만들어야 할 때. 임의의 코드를 얹을 수 있다는 것은 Script 가 노린 자리가 아닙니다.

자주 묻는 질문

Weegloo 는 Directus 대안인가요?

새로 시작하는 제품이라면 그렇습니다. 데이터 모델링, CMS, 다국어, 리비전, 협업이라는 핵심을 같이 덮고, 거기에 호스팅·CDN·콜드 스타트 없는 서버 로직·사용량 알림이 더해집니다. 다만 이미 있는 SQL 데이터베이스를 감싸는 것이 목적이라면 대안이 아닙니다. 그것은 Directus 의 존재 이유입니다.

기존 데이터베이스를 그대로 쓸 수 있나요?

없습니다. Weegloo 는 데이터베이스를 노출하지 않고, 데이터는 Content Type 으로 모델링해 전송 API 로 읽습니다. 기존 데이터베이스가 다른 시스템의 정본이고 계속 그래야 한다면 Directus 가 맞는 선택입니다. 반대로 옮겨도 되는 데이터라면, 옮기는 일 자체는 한쪽 API 에서 읽어 다른 쪽에 쓰는 스크립트 하나이고 AI 에이전트에게 맡기기 좋은 작업입니다.

직접 운영해야 하나요?

아닙니다. Weegloo 는 관리형이라 백업·업그레이드·확장이 여러분의 일이 아닙니다. Directus 는 오픈소스라 직접 운영하거나 Directus Cloud 를 쓰게 됩니다 — 어느 쪽이 나은지는 인프라를 직접 쥐고 싶은지에 달려 있습니다.

호스팅과 CDN 도 포함되나요?

포함됩니다. Web Hosting 이 정적 프론트엔드를 커스텀 도메인까지 올려 주고 CDN 전송도 함께 있습니다. Directus 는 데이터 계층이므로 호스팅을 따로 두게 되고, 그 사이를 오가는 아웃바운드 트래픽이 비용과 지연 시간으로 쌓입니다.

실시간 기능이 있나요?

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

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

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

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

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

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

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