돈 한푼 안 쓰고 백엔드 만들기: Cloudflare+Supabase 실전 구조
도입
사이드 프로젝트를 돌릴 때 가장 먼저 부딪히는 건 결국 인프라 비용입니다. 프론트엔드 호스팅, 백엔드 API, 데이터베이스를 각각 유료로 붙이면 트래픽이 거의 없는 초기 단계에도 매달 청구서가 날아옵니다. 정데비는 최근 개인 프로젝트를 Cloudflare Pages·Workers와 Supabase 조합으로 완전히 무료 티어 안에서 운영해봤고, 이번 글에서는 그 구조와 실제로 걸리는 한도를 정리합니다.
역할 분담
역할 분담부터 정리하면, Cloudflare Pages는 프론트엔드 정적 자산을 전 세계 CDN에 배포하는 역할을 하고, Cloudflare Workers는 엣지에서 실행되는 서버리스 함수로 가벼운 백엔드 로직을 처리합니다. Supabase는 PostgreSQL 데이터베이스, 인증, 파일 스토리지를 묶어서 제공하는 BaaS(Backend as a Service)입니다. 정적 자산과 엣지 로직은 Cloudflare에, 실제 데이터가 쌓이는 부분은 Supabase에 맡기는 구조입니다.
무료 티어 한도
각 서비스의 무료 티어 한도를 실제로 확인해보면 이렇습니다. Cloudflare Workers와 Pages Functions는 합쳐서 하루 10만 요청까지 무료이고, 정적 자산 서빙은 대역폭 제한이 없습니다. Supabase 무료 플랜은 데이터베이스 500MB, 파일 스토리지 1GB, 대역폭 5GB, 월간 활성 사용자(MAU) 5만 명까지 제공하며, API 요청 횟수 자체에는 제한이 없습니다. 다만 계정당 활성 프로젝트는 2개까지만 만들 수 있습니다.
여기서 실무에 가장 크게 영향을 주는 함정 하나는 Supabase의 비활성 정지 정책입니다. 무료 플랜 프로젝트는 7일 동안 데이터베이스에 요청이 없으면 자동으로 일시정지되고, 다시 쓰려면 대시보드에서 직접 복구 버튼을 눌러줘야 합니다. 트래픽이 뜸한 사이드 프로젝트라면 며칠 만에 "Database is paused" 메시지를 만나기 쉽습니다. 이를 막는 가장 간단한 방법은 GitHub Actions로 며칠 간격으로 Supabase API에 가벼운 요청을 보내는 스케줄 워크플로를 만들어두는 것입니다. 다만 이 방식은 어디까지나 개인·사이드 프로젝트용 우회책이고, 실사용자가 있는 서비스라면 Pro 플랜(월 25달러) 전환을 권장하는 게 맞습니다.
연동 방식
연동 방식도 짚어둘 부분이 있습니다. Cloudflare Workers에서 Supabase에 접근하는 방법은 크게 두 가지입니다. 하나는 supabase-js 클라이언트로 REST API(PostgREST)를 호출하는 방식이고, 다른 하나는 Cloudflare Hyperdrive를 통해 Postgres에 직접 연결하는 방식입니다. 전자는 설정이 간단하고, 후자는 커넥션 풀링을 Cloudflare 네트워크 차원에서 처리해주기 때문에 지연시간이 더 낮습니다. 가벼운 CRUD 위주라면 supabase-js로 충분하고, 쿼리가 복잡해지거나 응답속도가 중요해지면 Hyperdrive를 검토하는 편이 좋습니다.
보안 주의사항
보안 측면에서 주의할 점도 있습니다. Supabase의 서비스 롤(Service Role) 키는 Row Level Security(RLS) 정책을 우회하는 권한을 가지므로, Worker 코드에 직접 하드코딩하지 말고 반드시 환경변수(시크릿)로 관리해야 합니다. 또한 익명 키(anon key)를 쓰는 경우에도 RLS 정책을 제대로 설정해두지 않으면 누구나 테이블을 읽고 쓸 수 있는 상태가 될 수 있습니다.
마무리
정리하면, Cloudflare와 Supabase 조합은 정적 프론트엔드부터 데이터베이스까지 실질적으로 0원으로 운영할 수 있는 구조를 만들어줍니다. 다만 각 서비스의 무료 티어 한도 — 특히 Supabase의 7일 비활성 정지 — 를 미리 알고 설계하지 않으면 서비스가 예고 없이 멈추는 경험을 하게 됩니다. 트래픽이 실제로 늘어나는 시점을 기준으로 어느 서비스부터 유료 전환할지 미리 판단 기준을 세워두는 것도 필요합니다.
[핵심요약] Cloudflare+Supabase로 백엔드 무료 운영하기