Cloudflare Pages로 개발자 블로그 운영비 0원 만들기: 실제로 해보니
- Cloudflare Pages 무료 플랜은 정적 블로그 기준 대역폭 제한이 사실상 없어, 트래픽이 급증해도 과금이 발생하지 않습니다.
- 비용이 0원이 되는 진짜 이유는 서버가 없어서가 아니라 CDN 엣지에서 캐시로 처리되기 때문입니다. 이 구조를 이해해야 한도 관리도 쉬워집니다.
- Vercel 대비 유리한 점은 “대역폭 무제한”이고, 불리한 점은 “빌드 횟수 한도(월 500회)와 빌드 로그 접근성”입니다. 배포 전략만 잘 짜면 충분합니다.
블로그를 시작할 때 가장 먼저 했던 고민이 “트래픽이 생기면 갑자기 요금 폭탄 맞는 거 아닌가?”였습니다. 이전에 Vercel로 프로젝트를 운영하다 특정 달에 예상치 못한 청구서를 받은 적이 있어서, 개인 블로그만큼은 비용 리스크가 없는 환경으로 가고 싶었습니다.
결국 선택한 게 Astro + Cloudflare Pages 조합이었고, 지금까지 수개월째 월 청구 금액 0원을 유지하고 있습니다. 이 글은 그 경험을 정리한 내용입니다. “무조건 무료다”는 마케팅 얘기가 아니라, 실제로 어떤 조건에서 무료가 유지되고 어디서 한도가 걸리는지를 중심으로 씁니다.
Cloudflare Pages가 비용 절감에 유리한 이유: 서버가 없는 게 아니라 엣지 캐시가 서버 역할을 한다
보통 호스팅 비용은 “요청을 처리하는 서버의 연산 + 전송하는 데이터 대역폭”으로 결정됩니다. 전통적인 VPS나 서버리스 함수 방식은 요청이 올 때마다 무언가를 실행하고, 그 실행 횟수와 대역폭이 쌓여 청구됩니다.
Cloudflare Pages는 이 구조가 다릅니다. 빌드 결과물(HTML, JS, CSS, 이미지)을 Cloudflare의 전 세계 300개 이상 엣지 노드에 배포하고, 방문자 요청은 가장 가까운 엣지에서 파일을 그냥 던져줍니다. 연산이 없습니다. 파일 서빙만 있습니다.
그래서 다음 세 가지가 동시에 가능합니다:
- 속도: 방문자 근처 엣지에서 파일을 직접 서빙하므로 TTFB(첫 바이트 수신 시간)가 짧습니다.
- 안정성: CDN 자체가 이미 다중화되어 있어 단일 장애점이 없습니다.
- 비용 0원: 정적 파일 서빙은 Cloudflare의 핵심 무료 기능 범위입니다.

빌드 횟수 한도 초과, 캐시 미스로 인한 응답 지연, Pages Functions 사용 시 Workers 무료 할당량 초과는 별도 체크가 필요합니다. 돈이 안 드는 것과 장애가 없는 것은 다른 문제입니다.
무료 플랜 한도 실제로 확인해보니: 어디서 막히고 어디서는 여유 있나
Cloudflare Pages 무료 플랜의 구체적인 한도는 아래 공식 요금 화면에서 확인할 수 있습니다.

개인 블로그 운영 관점에서 실제로 느껴지는 한도는 딱 하나, 빌드 횟수입니다.
콘텐츠를 매일 1개씩 발행하고 main 브랜치에 직접 push한다고 해도 한 달에 30회 남짓입니다. GitHub Actions 워크플로우를 잘못 짜서 PR 생성/병합마다 빌드가 두세 번 트리거되는 경우가 아니라면 500회는 충분한 여유입니다. 제가 한 달 중 가장 바쁘게 배포했을 때 90회 정도였습니다.
반면 대역폭은 신경 쓸 필요가 없습니다. 개인 블로그 글이 HN(Hacker News)에 올라가 수천 명이 한꺼번에 접근하더라도 추가 비용 청구가 없는 것이 Cloudflare Pages의 핵심 경쟁력입니다.
Astro 블로그 배포 최적화로 빌드 횟수 낭비 없애기
빌드 한도 500회가 여유 있어 보여도, 배포 파이프라인을 잘못 설계하면 의외로 금방 소모됩니다. 실제로 처음 세팅할 때 두 가지 실수를 했습니다.
실수 1 — 모든 브랜치 push에 빌드 트리거Cloudflare Pages 기본 설정은 연결된 GitHub 레포의 모든 브랜치 push에 빌드를 실행합니다. feature 브랜치에서 초안을 수정하고 push할 때마다 프리뷰 빌드가 돌았고, 하루에만 10 ~ 15회 빌드가 소모되는 날도 있었습니다.
해결책은 Pages 프로젝트 설정에서 “Branch control” → 프로덕션 브랜치와 프리뷰 브랜치를 명시적으로 지정하고, 초안 작업용 브랜치는 빌드 제외 목록에 넣는 것입니다.
실수 2 — 이미지 최적화 없이 원본 PNG 그대로 커밋Astro는 @astrojs/image 또는 <Image /> 컴포넌트로 빌드 시 이미지를 WebP 변환·리사이즈합니다. 이걸 활성화하지 않으면 3MB짜리 PNG가 그대로 배포됩니다.
// astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
output: 'static',
image: {
service: {
entrypoint: 'astro/assets/services/sharp',
},
},
compressHTML: true,
build: {
inlineStylesheets: 'auto',
},
});

트래픽이 급증해도 0원 유지하는 캐시 전략
정적 사이트의 캐시 전략은 크게 두 가지로 나뉩니다:
- 자주 바뀌는 콘텐츠 (홈, 태그 목록, 최신 글 목록) — 짧은 캐시 TTL
- 거의 안 바뀌는 콘텐츠 (개별 포스트, 이미지, JS/CSS 번들) — 긴 TTL 또는 영구 캐시
Cloudflare Pages 프로젝트에 _headers 파일을 추가하면 경로별 캐시 헤더를 직접 제어할 수 있습니다:
# public/_headers
/_astro/*
Cache-Control: public, max-age=31536000, immutable
/images/*
Cache-Control: public, max-age=31536000, immutable
/blog/*
Cache-Control: public, max-age=1800, s-maxage=3600, stale-while-revalidate=86400
/
Cache-Control: public, max-age=300, s-maxage=600
/tags/*
Cache-Control: public, max-age=300, s-maxage=600
이 설정 적용 후 Cloudflare 대시보드의 “Cache” 탭에서 캐시 히트율을 확인해보면, 트래픽이 많은 날 캐시 히트율이 90% 이상으로 올라가는 것을 볼 수 있습니다.
Cloudflare Pages vs Vercel — 개발자 블로그 기준 실제 비교
이 비교는 “어느 게 더 좋냐”가 아니라 “내 상황에 어느 게 맞냐”를 기준으로 씁니다.

- 대역폭 비용이 걱정될 만큼 트래픽이 크거나, 트래픽 예측이 불확실한 경우
- Cloudflare의 다른 서비스(DNS, WAF, Workers, R2)와 통합 운영하는 경우
- Astro, Hugo, Jekyll 등 순수 정적 출력 프레임워크를 사용하는 경우
- Next.js 기반이고 ISR, Server Actions, Edge Runtime 등을 사용하는 경우
- Preview 배포 URL을 팀과 공유하며 코드 리뷰하는 워크플로우가 중요한 경우
- 빌드 로그와 분석 대시보드 접근성이 중요한 경우
순수 정적 블로그 기준으로는 Cloudflare Pages가 더 단순하고 비용 리스크가 적습니다. Vercel 무료 플랜은 대역폭에 월 100GB 한도가 있고, 초과 시 추가 요금이 발생합니다. 개인 블로그가 HN 같은 곳에 올라가 트래픽이 터질 때 그 차이가 실감납니다.
- Next.js 사용 → Vercel
- Astro / 순수 정적 → Cloudflare Pages
- Cloudflare 다른 서비스 이미 쓰는 중 → Cloudflare Pages
- 팀 협업 / 프리뷰 공유 중요 → Vercel
![[2026년 4월 테크 트렌드] 개발자가 지금 당장 주목해야 할 오픈소스·프레임워크 Top 5](/_astro/hero.BJaBJMdI_h9sR6.webp)