Weegloo vs Vercel

한 줄로 답하면

Vercel 은 프론트엔드를 배포합니다. Weegloo 는 사이트를 호스팅하면서 동시에 그 뒤의 백엔드입니다.

이 둘은 사실 같은 층위의 비교가 아니고, 그런 척하는 것은 정직하지 않습니다. Vercel 은 배포 플랫폼입니다 — 빌드 파이프라인, 엣지 네트워크, 프리뷰 배포, 그리고 세상에서 가장 좋은 Next.js 경험. 여러분의 데이터베이스나 CMS 나 인증 제공자가 되려는 제품이 아닙니다.

그래서 오히려 이 비교가 생깁니다. "Vercel" 만으로 서비스를 내보내는 곳은 거의 없습니다. 실제로 내보내는 것은 Vercel + 무언가 입니다 — Vercel + Supabase, Vercel + Firebase + CDN, Vercel + 헤드리스 CMS + 인증 제공자. 하나 붙을 때마다 구독이 하나, 대시보드가 하나, 키 묶음이 하나, 그리고 잘못될 수 있는 이음매가 하나씩 늘어납니다.

Weegloo 는 그 조립 전체를 하나의 플랫폼으로 대체합니다. 커스텀 도메인을 지원하는 정적 호스팅에 더해 구조화된 콘텐츠, 미디어, 회원 로그인, 권한, 데이터 검증, 서버 로직, 스케줄러가 같은 Space 안에 있습니다.

각각이 그대로 내어 주는 것

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

1. 구독 하나와 구독 셋을 비교하는 일이다

현실의 Vercel 기반 제품은 호스팅 비용을 내고, 데이터베이스나 BaaS 비용을 내고, 코드를 쓰지 않는 사람이 페이지를 고쳐야 하는 순간 CMS 비용을 냅니다. 업체 셋, 청구서 셋, 권한 모델 셋, 교체해야 할 자격 증명 묶음 셋.

Weegloo 의 유료 등급은 월 $8(Basic)과 월 $80(Pro)이고, 그 구독 하나가 호스팅과 데이터, 미디어, 회원, 권한, 서버 로직을 덮습니다. Free 등급에도 이미 커스텀 도메인 호스팅, 콘텐츠 20,000건, 월 API 호출 500,000회, 최종 사용자 계정 100,000개가 들어 있습니다.

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

이 항목은 규모가 커질수록 다른 무엇보다 크게 벌어집니다.

Vercel 위의 앱이 Supabase 에서 데이터를 읽고 다른 CDN 에서 이미지를 받아 오면, 그 통신은 전부 서비스 경계를 넘습니다. 아웃바운드 트래픽은 대역폭 요금으로 청구서에 그대로 올라가고, 왕복이 하나씩 쌓여 지연 시간이 됩니다. 트래픽이 늘수록 두 가지가 함께 늘어납니다.

Weegloo 는 데이터, 미디어, 콘텐츠, 서버 로직을 자체적으로 제공하므로 그 사이에서 인터넷을 건너는 호출이 없습니다. 대규모 서비스에서는 무시할 수 없는 비용 차이이고, 동시에 속도의 차이입니다.

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

Vercel 의 서버리스·엣지 함수는 임의의 코드를 실행합니다. Weegloo 는 그 자리에 Script 라는 DSL 을 두었습니다. 못 하는 것이 아니라 하지 않기로 한 선택입니다.

BFF 가 실제로 하는 일은 놀랄 만큼 뻔합니다. 값을 비교하고, 데이터를 다루고, 이메일을 보내고, 웹훅을 부르고, 외부 API 를 호출해 결과를 저장합니다. 그것을 DSL 로 만든 대가로 콜드 스타트가 없고, 대용량 트래픽에서 가볍고, 그래서 요금이 쌉니다.

실행 경로도 셋입니다. 직접 호출, 콘텐츠 변경 이벤트, Cron 스케줄러 모두 같은 Script 를 씁니다 — 스케줄에 걸어 둔 작업을 지금 한 번만 돌려야 할 때도 그냥 호출하면 됩니다.

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

Vercel 은 올릴 앱이 이미 있다는 것을 전제합니다. 배포는 훌륭하게 해 주지만, 그 앱은 누군가 만들어야 하고 데이터베이스와 CMS 를 붙이는 것도 개발자의 일입니다. 코드를 쓰지 않는 사람이 Vercel 에서 시작할 수 있는 일은 사실상 없습니다.

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

• 콘솔이 곧 제품입니다. 콘텐츠, 미디어, 회원, 권한을 거기서 관리합니다. 따로 발주해야 하는 어드민 애플리케이션이 없습니다.
• 검증은 클릭 몇 번입니다. 값의 범위·고유값·형식은 필드의 설정이지 코드가 아닙니다.
• 서버 로직이 코드가 아니라 DSL 입니다. 메일 발송, 외부 API 호출, 정기 작업이 전부 Script 문장이고, 그 문장은 AI 에게 한 문장으로 말하면 알아서 씁니다.
• 고를 스택이 없습니다. 어떤 데이터베이스와 인증 제공자와 CDN 을 쓸지 정하고 잇는 일이 아예 생기지 않습니다.
• 사이트도 여기서 올라갑니다. 커스텀 도메인까지 포함해서, 배포처를 따로 고르지 않아도 됩니다.

엔지니어가 아닌 사람이 프로토타입이 아니라 실제 서비스를 운영할 수 있다는 뜻입니다. 화면을 만들 개발자가 필요한 순간이 오더라도, 백엔드는 그대로 두고 프론트엔드만 맡기면 됩니다.

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

Vercel 의 템플릿은 저장소를 복제해 주고, 배포와 운영은 그 다음부터 여러분의 일입니다. Weegloo 의 마켓플레이스는 설치하는 순간 내 Space 안에서 이미 돌아갑니다.

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

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

전부 다 쓸 필요는 없습니다

Weegloo 를 "풀스택 백엔드" 로만 이해하면 오해입니다. 필요한 부분만 써도 됩니다. Vercel 에 배포한 채로 Weegloo 를 콘텐츠 관리에만 쓸 수도 있고, 미디어와 CDN 전송에만 쓸 수도 있습니다.

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

Vercel 이 더 나은 경우

• 서버 사이드 렌더링이 필요할 때. Next.js SSR, ISR, 스트리밍, 미들웨어, 엣지 함수 — Weegloo 는 정적 결과물만 호스팅합니다. 요청마다 렌더링이 필요한 제품이라면 Vercel 에 올리고 그 뒤의 백엔드로 Weegloo 를 쓰세요. 이 조합은 잘 맞습니다.
• git push 배포와 PR 마다의 프리뷰 URL 을 원할 때. Vercel 의 빌드·프리뷰 워크플로는 정말 좋고 Weegloo 는 그것을 재현하려 하지 않습니다.
• 임의의 코드를 서버에서 돌려야 할 때. 특정 라이브러리를 실행하거나 직접 짠 알고리즘을 돌려야 한다면 함수가 맞습니다. Script 는 그 자리를 노린 물건이 아닙니다.

여기 "백엔드가 필요 없을 때" 는 넣지 않았습니다. 그것은 Vercel 을 고를 이유가 되지 않습니다 — Weegloo 도 정적 사이트를 커스텀 도메인까지 호스팅하고, 백엔드가 필요 없으면 그 부분을 쓰지 않으면 그만입니다. 다음 절을 보세요.

분명히 적어 둘 것: Weegloo 와 Vercel 은 양자택일이 아닙니다. Vercel 에 배포하면서 데이터, 미디어, 회원, 권한을 Weegloo 로 쓰면, 마음에 드는 배포 경험은 그대로 두고 데이터베이스와 인증 서비스와 CMS 를 스택에서 덜어낼 수 있습니다.

Vercel 에 없고 Weegloo 에 있는 것

• 애초에 백엔드가 있다는 것 — 직접 연결하는 업체 셋이 아니라, 구조화된 콘텐츠와 처리·CDN 전송을 갖춘 미디어, 회원 로그인, 세밀한 권한, 데이터 검증.
• 출시 이후 서비스를 운영하는 사람들을 위한 운영 콘솔: 검색, 필터, 태그, 댓글, 검수, 리비전, 명시적 발행 단계. 별도의 어드민 페이지가 필요 없습니다.
• 폴백 체인까지 갖춘 필드 단위 다국어 콘텐츠.
• 콜드 스타트 없는 Script 와 Cron 스케줄러.
• 좌석당 요금 + 사용량이 아니라 좌석을 포함한 정액 요금, 그리고 아웃바운드 트래픽 없음.
• Metric 기반 사용량 모니터링과 임계치 알림 — 콘솔에서 사용량을 보고, 퍼센트로 걸어 둔 지점에 도달하면 이메일이 먼저 옵니다.
• 검증된 규모. Weegloo 아래의 아키텍처는 SNOW Corp. 가 ZEPETO 규모의 글로벌 서비스 — 가입자 3억 명 이상 — 를 운영하던 그 아키텍처입니다.

자주 묻는 질문

Weegloo 는 Vercel 대안인가요?

진짜 백엔드가 필요한 정적 사이트에는 그렇습니다 — Weegloo 가 커스텀 도메인으로 사이트를 호스팅하고 그 뒤의 데이터·미디어·회원·권한까지 제공합니다. 서버 렌더링 Next.js 애플리케이션에는 대안이 아닙니다. Weegloo 의 호스팅은 정적 결과물을 서빙하기 때문입니다. 그 경우 자연스러운 구성은 프론트엔드는 Vercel, 백엔드는 Weegloo 입니다.

Vercel 과 함께 쓸 수 있나요?

가능하고 흔한 형태입니다. 프론트엔드는 Vercel 에 배포하고, 콘텐츠와 미디어는 Weegloo 의 전송 API 로, 회원 로그인은 ServiceLogin 으로, 권한은 역할로 처리합니다. Vercel 의 빌드·프리뷰 워크플로는 유지하면서 별도의 데이터베이스·인증 제공자·CMS 를 덜어냅니다.

Next.js 를 지원하나요?

정적 익스포트 형태로 지원합니다. output: 'export' 를 켠 next build 가 만든 정적 번들을 Weegloo Web Hosting 에 배포할 수 있습니다. 서버 렌더링 Next.js 는 Node 런타임이 필요하고 Weegloo Hosting 은 그것을 제공하지 않습니다 — 그런 앱은 Vercel 에 올리고 거기서 Weegloo 를 호출하세요.

서버리스 함수 없이 API 라우트를 대신할 수 있나요?

Script 로 대신합니다. 프론트엔드가 HTTP 로 호출하는 선언형 문장이고, 콘텐츠를 읽고 쓰고 외부 API 를 호출하고 메일을 보냅니다. 코드 기반 함수를 못 만드는 것이 아니라 만들지 않는 것이고, 그 대가로 콜드 스타트가 없고 대용량 트래픽에서 가볍습니다. 임의의 라이브러리를 서버에서 돌려야 한다면 그때는 함수가 맞습니다.

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

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

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

쓸 수 있습니다. Vercel 은 올릴 앱이 이미 있다는 것을 전제하지만, Weegloo 는 콘텐츠·미디어·회원· 권한을 콘솔에서 관리하고 검증은 클릭으로 설정하며 서버 로직은 코드가 아닌 Script 문장입니다 — 그 문장은 AI 에게 평범한 한 문장으로 말하면 대신 써 줍니다. 사이트 배포까지 커스텀 도메인과 함께 포함되므로, 엔지니어가 아닌 사람도 실제 서비스를 운영할 수 있습니다.

백엔드가 필요 없는 정적 사이트인데도 Weegloo 를 쓸 이유가 있나요?

있습니다. Weegloo 는 호스팅만 써도 됩니다 — 정적 사이트를 커스텀 도메인까지 올려 주고, 무료 등급에도 커스텀 도메인 1개와 웹 호스팅 배포 10개가 들어 있습니다. 백엔드가 필요 없다면 그 부분을 쓰지 않으면 그만이고, 그것 때문에 더 내는 것도 없습니다.

차이가 생기는 것은 나중입니다. 문의 폼을 받아야 하거나, 공지를 코드 수정 없이 고쳐야 하거나, 회원을 받아야 하는 날이 오면 — 정적 호스팅만 있는 곳에서는 그때부터 데이터베이스와 CMS 와 인증 제공자를 고르고 붙이는 일이 시작됩니다. Weegloo 에서는 이미 있는 기능을 켜는 일입니다. 플랫폼을 옮기지 않아도 됩니다.

Vercel 보다 저렴한가요?

정직하게 비교하면 이렇습니다. Weegloo 는 월 $8 또는 $80 로 호스팅 과 백엔드를 함께 덮고, Vercel 플랜은 호스팅을 좌석당 요금으로 덮으며 데이터베이스·인증·CMS 는 따로 청구됩니다. 여기에 서비스 사이를 오가는 아웃바운드 트래픽 비용이 Weegloo 에서는 발생하지 않는다는 차이가 더해집니다.

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

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

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

프리뷰 배포가 되나요?

되지 않습니다. Weegloo 는 빌드된 정적 번들을 서브도메인이나 커스텀 도메인을 가진 Web Hosting 리소스에 배포합니다. PR 마다의 프리뷰 URL 은 Vercel 의 강점이고 Weegloo 는 그것을 재현하지 않습니다.

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

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