Cloudflare Pages 무료 티어로 SaaS 시작하기 — 진짜 1년 비용 후기
1인 개발자가 Cloudflare Pages 무료 티어로 1년간 portal, myhyetaek 등 5개 서비스를 운영하며 지출한 실제 비용과 뼈아픈 실패담을 공개합니다.
AWS 청구서의 공포, 그리고 이주 결심
2025년 11월, 제 메일함에 날아온 AWS 프리티어 만료 알림과 함께 찍힌 '45달러' 청구서를 보고 저는 한동안 모니터 앞을 떠나지 못했습니다. 당시 제가 운영하던 서비스는 하루 방문자가 100명도 채 되지 않는 작은 토이 프로젝트들이었습니다. RDS 데이터베이스 인스턴스 하나 켜두고, EC2 제일 작은 사이즈를 돌렸을 뿐인데 커피 10잔 값이 순식간에 증발한 것이죠.
1인 개발자에게 월 고정비 5만 원은 심리적 장벽이 매우 높습니다. 서비스가 언제 돈을 벌어다 줄지 모르는 상황에서 인프라 비용만 나가는 것은 '밑 빠진 독에 물 붓기'처럼 느껴지기 때문입니다. 그래서 저는 과감하게 모든 서비스를 Cloudflare Pages 환경으로 이주하기로 결심했습니다. 지난 1년간 GRAXEL이라는 이름 아래 portal, myhyetaek, JobFit 등 무려 5개의 서비스를 런칭하고 운영해 온 진짜 비용 이야기를 오늘 솔직하게 풀어보려 합니다.
진짜 영수증 공개: 1년간 얼마를 냈을까?
결론부터 말씀드리자면, 제가 지난 1년간 5개의 서비스를 돌리며 Cloudflare에 지불한 총액은 단 1.25달러(약 1,700원)였습니다. 믿어지시나요? 서버리스 환경의 극강의 가성비가 빛을 발하는 순간이었습니다.
- Cloudflare Pages & Workers: 월 10만 회의 무료 요청 한도 내에서 완벽하게 방어했습니다. 청구 금액 0원.
- Cloudflare D1 (Serverless SQL): 하루 최대 1만 번의 쿼리가 발생했지만, 읽기 500만 건, 쓰기 10만 건이라는 넉넉한 무료 티어 덕분에 역시 0원이었습니다.
- Cloudflare R2 (Object Storage): 여기서 비용이 발생했습니다! 사용자들이 업로드한 프로필 이미지와 문서 썸네일이 쌓이면서 Class A 작업(데이터 쓰기/수정)에서 한도를 초과해 약 1.25달러가 과금되었습니다.
어디서 돈이 새는가: 나의 뼈아픈 실패담
물론 1년 내내 평화로웠던 것은 아닙니다. 가장 아찔했던 순간은 올해 3월, myhyetaek 서비스에서 무한 루프 버그가 발생했을 때였습니다. 프론트엔드 코드의 useEffect 의존성 배열을 실수로 잘못 설정하는 바람에, 수백 명의 유저 브라우저에서 1초마다 Workers KV(Key-Value 저장소)를 호출하는 대참사가 벌어졌습니다.
"다음 날 아침 대시보드를 열어보니 KV 읽기 요청이 하룻밤 사이에 800만 건을 돌파해 있었습니다. 무료 제공량인 10만 건을 아득히 초과한 수치였죠."
다행히 Cloudflare의 요금 상한선(Billable Limits) 알림을 미리 설정해 둔 덕분에, 10달러 선에서 서비스를 강제 정지시키고 코드를 핫픽스할 수 있었습니다. 만약 AWS였다면 영문도 모른 채 수백 달러의 폭탄을 맞았을 것입니다. (더 자세한 제 소개와 운영 철학은 GRAXEL 소개 페이지에서 확인하실 수 있습니다.)
내가 추천하는 절약 패턴 5가지
1년의 삽질 끝에 제가 터득한 'Cloudflare 영끌(영혼까지 끌어모으는) 무료 티어 생존법'을 공유합니다.
- Cache Rules를 극단적으로 활용하라: 정적 자산(이미지, CSS, JS)은 물론이고, 자주 변하지 않는 API 응답(예: 공지사항 목록)도 Cloudflare Cache에 태우세요. Workers 호출 자체를 막는 것이 최고의 절약입니다.
- R2는 이미지 서빙용으로만: 데이터베이스처럼 R2를 쓰지 마세요. R2는 S3 호환 스토리지를 제공하지만, 잦은 수정과 삭제(Class A 오퍼레이션)는 과금의 주범이 됩니다. 읽기(Class B)는 매우 저렴합니다.
- KV 대신 D1을 메인으로: 예전에는 서버리스 DB로 KV나 Durable Objects를 많이 썼지만, 이제는 정식 출시된 D1이 훨씬 강력하고 무료 한도도 넓습니다.
- Tail Log 최소화: 디버깅을 위해
console.log를 남발하지 마세요. Workers의 로그 보관 비용도 무시할 수 없습니다. 에러 추적은 꼭 필요한 곳에만 심어두는 습관을 들여야 합니다. - 이미지 최적화 꼼수: Cloudflare Images는 유료지만, 오픈소스 라이브러리를 사용해 빌드 타임에 이미지를 WebP로 변환한 뒤 Pages 자산으로 배포하면 트래픽 비용을 0원으로 만들 수 있습니다.
결론: 누구에게 추천하고, 누구는 피해야 할까?
만약 당신이 저처럼 혼자서 SaaS의 초기 MVP(Minimum Viable Product)를 검증하고 싶거나, 트래픽이 간헐적으로 발생하는 랜딩 페이지, 개인 블로그 등을 운영한다면 Cloudflare Pages는 축복과도 같습니다. Cloudflare 공식 블로그에서도 강조하듯 개발자 친화적인 생태계가 구축되어 있죠.
하지만, 무거운 비디오 인코딩이 필요하거나 실시간 웹소켓 서버가 24시간 열려있어야 하는 서비스라면 섣불리 Workers로 이주하지 마세요. 서버리스의 특성상 런타임 제한 시간(CPU Time)에 걸려 피를 볼 수 있습니다. 앞으로도 GRAXEL 블로그의 운영기 카테고리를 통해 1인 개발자의 생존 팁을 계속 연재하겠습니다. 작은 비용으로 큰 가치를 만들어내는 모든 1인 개발자들을 응원합니다!
공유하기
이어 읽으면 좋은 글
같은 주제와 태그를 기준으로 GRAXEL 운영 맥락을 더 깊게 볼 수 있는 글입니다.
1인 개발자 SaaS 모노레포 vs 멀티레포 — Graxel 운영 1년 후 다시 보는 결정
pnpm과 Turborepo로 구축한 모노레포 아키텍처가 1인 개발자에게 정말 정답이었을까요? 1년간의 뼈저린 운영 회고와 실패담.
SaaS Factory 모노레포 운영기 — pnpm + Turbo로 12개 서비스 묶기
pnpm workspaces와 Turborepo로 공용 패키지와 12개 서비스를 동시에 관리하며 얻은 실전 패턴을 공유합니다.
Next.js 15 App Router + next-intl v4로 ko/en/ja 3개 언어 운영기
graxel.ai 자체를 한국어/영어/일본어 3개 언어로 운영하면서 배운 로케일 라우팅, SEO, hreflang 실전 패턴을 정리합니다.