무료 정적 배포 플랫폼은 겉으로 보면 비슷합니다. Git에 push하면 빌드되고, 커스텀 도메인을 붙일 수 있고, CDN에서 파일을 서빙합니다. 하지만 트래픽이 늘거나, 서버리스 함수가 필요해지거나, 팀원이 붙거나, 빌드가 무거워지는 순간 성격이 갈립니다.
이 글은 “어디가 제일 좋다”를 고르는 글이 아닙니다. 어느 시점까지 어떤 플랫폼을 쓰고, 언제 옮겨야 하는지를 판단하기 위한 비교입니다. 수치는 공식 문서와 가격 페이지를 기준으로 확인했습니다.
현재 조건이 “정적 HTML로 끝나는 기술 블로그”라면 GitHub Pages가 맞습니다. 서버를 운영할 이유가 없고, 트래픽 비용을 걱정할 단계도 아니기 때문입니다. 반대로 월 수십만 PV가 안정적으로 나오거나, Cloudflare의 WAF/cache/Workers까지 함께 쓰게 되면 Cloudflare Pages로 옮기는 편이 더 자연스럽습니다.
결론부터
개인 기술 블로그나 작은 문서 사이트라면 GitHub Pages로 시작해도 충분합니다. 서버가 없고, 콘텐츠가 정적 HTML로 끝나며, 월 100GB 수준의 소프트 대역폭 한도 안에 있다면 가장 단순합니다.
정적 사이트지만 트래픽이 커질 수 있고, Cloudflare DNS/WAF/Workers/R2/D1 같은 주변 기능까지 쓸 계획이라면 Cloudflare Pages가 더 오래 버팁니다. 특히 정적 asset 요청이 무료이자 unlimited라는 점은 광고형 콘텐츠 사이트에 큰 장점입니다.
Next.js 앱, preview 중심 협업, 서버리스 함수, ISR, 관측성, 팀 기능이 중요해지면 Vercel이 편합니다. 대신 편의 기능이 늘수록 비용 구조가 세밀해집니다. “그냥 무료 배포”로 쓰기보다 앱 플랫폼으로 보는 편이 맞습니다.
| 상황 | 추천 |
|---|---|
| 개인 기술 블로그, 문서, 포트폴리오 | GitHub Pages |
| 정적 콘텐츠 + 트래픽 증가 + Cloudflare 생태계 | Cloudflare Pages |
| Next.js 앱, preview 협업, 서버리스/ISR | Vercel |
| 광고형 블로그를 거의 0원으로 오래 운영 | GitHub Pages로 시작, 트래픽이 커지면 Cloudflare Pages |
| 로그인, 결제, 대시보드가 붙는 제품 앱 | Vercel 또는 Cloudflare Workers/Pages 조합 |
숫자로 보는 기본 비교
| 항목 | GitHub Pages | Cloudflare Pages | Vercel |
|---|---|---|---|
| 기본 가격 | GitHub Free 공개 저장소에서 사용 가능 | Free 플랜 가능 | Hobby $0/mo, Pro $20/mo |
| 정적 트래픽 | 월 100GB soft bandwidth limit | 정적 asset 요청 무료/무제한 | Hobby Fast Data Transfer 100GB, Pro 1TB |
| 사이트 크기 | published site 1GB | Free 20,000 files, paid 100,000 files | CLI static upload Hobby 100MB, Pro 1GB |
| 빌드 제한 | Pages 배포 10분 timeout | Free 500 builds/month, 20분 timeout | build time 45분 |
| 빌드 빈도 | Pages 기본 빌드 10/hour soft limit | Free 1 concurrent, Pro 5 concurrent | Hobby 100 deployments/day, 100/hour |
| 서버리스 | 없음 | Pages Functions = Workers quota 사용 | Vercel Functions |
| 함수 무료 한도 | 해당 없음 | Workers Free 100,000 requests/day | Hobby 1M invocations/month |
| 커스텀 도메인 | 가능 | Free 기준 project당 100개 | Hobby project당 50개 |
| 리다이렉트/헤더 | 정적 파일/프레임워크 빌드 중심 | _redirects, _headers 지원 |
redirects, rewrites, headers, middleware |
| 가장 강한 지점 | 단순함과 GitHub 통합 | 정적 트래픽 비용과 엣지 생태계 | Next.js/DX/preview/앱 기능 |
| 약한 지점 | 동적 기능 없음, 상업 서비스 제한 | Workers 모델 이해 필요 | 사용량이 늘면 비용 모델을 봐야 함 |
위 표에서 특히 조심해야 할 부분은 한도의 성격입니다. GitHub Pages의 월 100GB와 시간당 10 builds는 soft limit이고, 사이트 1GB와 배포 10분 timeout은 실제로 막히는 제약에 가깝습니다. Vercel의 100GB/1TB는 포함 사용량이고, 초과하면 요금 항목을 봐야 합니다. Cloudflare Pages의 정적 asset 요청은 Functions를 호출하지 않는 요청일 때 무료/무제한입니다.
그래서 표만 보면 Cloudflare Pages가 압도적으로 좋아 보일 수 있습니다. 하지만 실제 선택은 숫자 하나로 끝나지 않습니다. 운영자가 무엇을 덜 신경 쓰고 싶은지가 더 중요합니다.
GitHub Pages: 블로그와 문서에 가장 단순하다
GitHub Pages는 HTML, CSS, JavaScript 파일을 저장소에서 가져와 정적 사이트로 호스팅하는 서비스입니다. 개인 블로그, 프로젝트 문서, 포트폴리오처럼 “빌드 결과물이 파일이면 끝나는” 사이트와 잘 맞습니다.
장점은 단순함입니다. 저장소, 이슈, Actions, Pages가 모두 GitHub 안에 있습니다. Astro나 Jekyll로 HTML을 만들고 Pages에 올리면 별도 런타임 서버가 없습니다.
하지만 GitHub Pages는 무료 웹호스팅 서비스나 SaaS 운영 플랫폼이 아닙니다. GitHub 문서는 Pages가 온라인 비즈니스, 전자상거래, 상업 거래를 주 목적으로 하는 사이트에 쓰이는 것을 의도하지 않는다고 설명합니다. 또한 published site는 1GB 이하, 대역폭은 월 100GB soft limit, Pages 배포는 10분을 넘으면 timeout, 기본 Pages 빌드는 시간당 10회 soft limit가 있습니다.
| GitHub Pages가 좋은 경우 | 피해야 하는 경우 |
|---|---|
| 글, 문서, 포트폴리오 | 로그인/결제/대시보드 |
| 정적 HTML로 충분한 사이트 | 서버리스 API가 필요한 앱 |
| GitHub Actions로 빌드 자동화 | 월 100GB를 꾸준히 넘는 트래픽 |
| 운영 비용을 거의 0원으로 유지 | 상업 거래가 핵심인 서비스 |
활용법: 블로그는 GitHub Pages로 시작하고, 이미지는 너무 크게 넣지 않으며, sitemap/RSS/canonical을 빌드에 포함합니다. 트래픽이 월 100GB 근처로 가거나, GitHub Support에서 CDN 사용/호스팅 이전을 권할 정도가 되면 Cloudflare Pages로 옮기는 편이 자연스럽습니다.
Cloudflare Pages: 정적 트래픽이 커질수록 유리하다
Cloudflare Pages의 가장 큰 장점은 정적 asset 요청 비용입니다. Cloudflare 문서는 Pages의 정적 asset 요청이 free와 paid plan 모두에서 무료이자 unlimited라고 설명합니다. 광고형 블로그, 문서 사이트, 이미지가 많지 않은 콘텐츠 사이트라면 이 차이가 큽니다.
빌드 한도도 명확합니다. Free는 500 builds/month, 1 concurrent build, build timeout 20분입니다. Pro는 5,000 builds/month와 5 concurrent builds, Business는 20,000 builds/month와 20 concurrent builds를 제공합니다. 파일 수는 Free 20,000개, paid 100,000개이고, 단일 asset 파일 크기는 25MiB입니다.
동적 기능은 Pages Functions를 통해 Workers로 넘어갑니다. 여기서부터는 정적 호스팅이 아니라 Cloudflare Workers 요금과 한도를 이해해야 합니다. Workers Free는 100,000 requests/day, Workers Paid는 최소 $5/month이고 10 million requests/month가 포함됩니다. Cloudflare는 Workers Paid에 대해 추가 data transfer 또는 bandwidth charge가 없다고 설명합니다.
| Cloudflare Pages가 좋은 경우 | 주의할 점 |
|---|---|
| 정적 트래픽이 커질 수 있는 블로그 | 빌드 500/month 한도 |
| Cloudflare DNS, WAF, R2, D1, Workers를 같이 쓸 계획 | Functions는 Workers quota와 과금 모델을 따른다 |
| redirect/header를 정적 파일로 관리하고 싶음 | 단일 asset 25MiB 제한 |
| preview deployment가 많이 필요함 | Workers/D1/KV까지 쓰면 구조 설계가 필요 |
활용법: 블로그가 커지고 트래픽 비용이 걱정되면 Cloudflare Pages로 옮기는 게 좋습니다. 정적 페이지는 Pages가 맡고, 폼 처리나 간단한 API는 Pages Functions로 시작합니다. 데이터가 필요해지면 D1, 파일은 R2, 캐시는 KV를 검토합니다.
Vercel: 블로그 호스팅보다 앱 플랫폼에 가깝다
Vercel은 정적 사이트도 잘 배포하지만, 진짜 강점은 Next.js와 앱 개발 경험입니다. preview deployment, branch 기반 협업, 함수, ISR, analytics, middleware, rewrite, rollback 같은 기능이 자연스럽게 이어집니다.
가격은 Hobby $0/month, Pro $20/month입니다. Hobby에도 100GB Fast Data Transfer, 1M function invocations/month, 4 CPU-hours, 360 GB-hours provisioned memory가 포함됩니다. Pro는 1TB Fast Data Transfer가 포함되고, 초과분은 Fast Data Transfer 기준으로 GB당 과금이 붙습니다. Vercel 가격 페이지는 Pro의 included usage credit과 pay-as-you-go 모델도 함께 설명합니다.
한도도 앱 플랫폼답게 세분화되어 있습니다. build time per deployment는 45분이고, Hobby는 deployments/day 100, deployments/hour 100입니다. 함수 실행 시간은 프로젝트 설정과 Fluid compute 적용 여부에 따라 달라질 수 있으므로, 단순 블로그 비교에서는 “함수를 얼마나 오래 실행할 수 있나”보다 “함수와 이미지 최적화, analytics, 로그가 비용 항목으로 분리된다”는 점을 먼저 봐야 합니다.
| Vercel이 좋은 경우 | 주의할 점 |
|---|---|
| Next.js 앱과 블로그가 같은 제품 안에 있음 | 사용량 기반 과금 항목이 많다 |
| preview deployment가 협업의 중심 | 단순 정적 블로그에는 과할 수 있음 |
| ISR, middleware, serverless functions가 필요 | Hobby는 Git organization repo 연결 제한이 있음 |
| 팀, 관측성, rollback, 보안 기능이 중요 | 트래픽/함수/이미지 최적화 비용을 봐야 함 |
활용법: “블로그”만이면 Vercel은 과할 수 있습니다. 하지만 블로그가 제품 앱의 일부이고, 로그인 후 대시보드, 실험 페이지, 서버리스 API, Next.js 렌더링 전략이 필요하다면 Vercel은 개발 속도가 빠릅니다.
비용 시나리오로 보면 더 선명하다
1. 월 1만 방문 기술 블로그
대부분 GitHub Pages로 충분합니다. 글은 정적 HTML이고, 이미지 최적화만 신경 쓰면 월 100GB soft limit 근처에도 가기 어렵습니다. 비용은 도메인 비용을 제외하면 거의 0원에 가깝습니다.
예를 들어 페이지 1회 로드에 HTML, CSS, JavaScript, 이미지까지 합쳐 평균 1MB가 전송된다고 가정하면 1만 PV는 약 10GB입니다. 같은 글이라도 이미지가 많아 평균 3MB가 되면 3만 PV만으로 약 90GB에 가까워집니다. GitHub Pages에서 중요한 기준은 방문자 수 자체가 아니라 PV × 페이지당 전송량입니다.
2. 월 50만 PV 광고형 블로그
트래픽과 정적 asset 요청이 중요해집니다. 이 구간부터는 Cloudflare Pages가 매력적입니다. 정적 asset 요청이 무료/무제한이고, Cloudflare DNS/WAF/cache 생태계를 같이 쓸 수 있습니다.
월 50만 PV에 페이지당 평균 1MB만 잡아도 약 500GB 전송량입니다. GitHub Pages의 soft bandwidth limit를 안정적으로 넘는 구간이고, Vercel Hobby의 100GB 포함량도 초과합니다. 이때는 “무료 배포가 되느냐”보다 정적 요청을 Functions로 태우지 않고, 이미지와 큰 파일을 어떻게 분리할지가 더 중요합니다.
3. 블로그 + 회원 기능 + 대시보드
이제 단순 호스팅 비교가 아닙니다. Vercel과 Cloudflare Workers/Pages 중 앱 구조에 맞춰 골라야 합니다. Next.js 중심이면 Vercel이 빠르고, edge-first API와 Cloudflare 스토리지를 함께 쓸 계획이면 Cloudflare가 강합니다.
4. SaaS로 확장
GitHub Pages는 이 단계의 플랫폼이 아닙니다. Cloudflare Pages도 정적 shell + Workers 앱 구조를 설계해야 합니다. Vercel은 앱 배포와 팀 협업은 좋지만, 비용 항목이 세분화되어 있으므로 트래픽, 함수, 이미지, 로그, analytics를 따로 추적해야 합니다.
기능 지원 비교
| 기능 | GitHub Pages | Cloudflare Pages | Vercel |
|---|---|---|---|
| Static hosting | 좋음 | 좋음 | 좋음 |
| Custom domain | 지원 | 지원 | 지원 |
| HTTPS | 지원 | 지원 | 지원 |
| Preview deployments | 제한적 | 강함 | 강함 |
| Serverless functions | 미지원 | Pages Functions/Workers | Vercel Functions |
| Edge runtime | 미지원 | Workers | Edge/Functions 계열 |
| Redirects | 빌드/정적 방식 | _redirects |
vercel.json, framework config |
| Headers | 제한적 | _headers |
vercel.json, framework config |
| Built-in analytics | 없음 | Web Analytics 별도 사용 가능 | Web Analytics/Speed Insights |
| Rollback | Git/Actions 기반 | 지원 | 지원 |
| 대형 정적 트래픽 | soft limit 고려 | 강함 | 포함량/과금 고려 |
| Next.js 최적 DX | 보통 | 가능하지만 별도 고려 | 매우 강함 |
언제까지 쓰고, 언제 옮길까
GitHub Pages를 계속 써도 되는 기준
- 블로그/문서/포트폴리오다.
- 로그인과 서버 API가 없다.
- 빌드가 10분 안에 끝난다.
- published site가 1GB보다 작다.
- 월 트래픽이 100GB soft limit를 안정적으로 넘지 않는다.
- GitHub Actions로 빌드와 배포가 충분하다.
Cloudflare Pages로 옮길 기준
- 정적 트래픽이 커지고 있다.
- 대역폭 비용보다 콘텐츠 확장이 중요하다.
- redirect/header/cache 전략을 더 세밀하게 가져가고 싶다.
- Cloudflare DNS, WAF, R2, D1, Workers를 같이 쓸 계획이 있다.
- Pages Functions로 간단한 API를 붙이고 싶다.
Vercel로 옮길 기준
- Next.js 앱이 핵심이다.
- preview URL 기반 협업이 중요하다.
- ISR, middleware, serverless functions, image optimization을 적극적으로 쓴다.
- 제품 앱과 블로그가 같은 배포 생명주기를 가져야 한다.
- Pro 비용과 사용량 기반 과금을 감당할 수 있다.
마이그레이션은 어떻게 하면 좋을까
처음부터 플랫폼 종속 기능을 많이 쓰면 나중에 옮기기 어렵습니다. 그래서 정적 블로그는 다음 원칙을 지키는 편이 좋습니다.
- 콘텐츠는 Markdown 또는 CMS 데이터로 분리한다.
- URL 구조를 플랫폼 이름과 무관하게 설계한다.
- canonical, sitemap, RSS를 프레임워크 레벨에서 만든다.
- 이미지와 큰 파일은 나중에 별도 스토리지로 뺄 수 있게 둔다.
- redirect 규칙은 문서화한다.
- 환경 변수와 secret은 플랫폼별 이름에 의존하지 않게 정리한다.
GitHub Pages에서 Cloudflare Pages로 옮길 때는 보통 repository 연결, build command, output directory, custom domain, DNS 전환 순서로 진행합니다. Astro 기준이라면 build command는 pnpm build, output directory는 dist입니다.
Cloudflare Pages로 옮길 가능성을 열어두려면 redirect 규칙도 코드 옆에 남겨두는 편이 좋습니다. 다만 언어별 URL을 운영한다면 와일드카드 redirect를 함부로 걸면 안 됩니다. 예를 들어 /ko/posts/foo를 /posts/foo로 보내면 정적 파일이 없어서 404가 날 수 있습니다. 루트 언어 선택 페이지만 정리하려면 다음처럼 범위를 좁히는 편이 안전합니다.
# public/_redirects
/ko / 301반대로 /ko/posts/*까지 루트로 옮기려면 먼저 새 URL을 실제로 만들고, slug 단위 redirect 표를 따로 관리해야 합니다. “대충 패턴으로 한 번에 넘기기”는 블로그 마이그레이션에서 검색 유입을 잃는 가장 쉬운 방법입니다.
GitHub Pages에서 Vercel로 옮길 때도 핵심은 비슷합니다. 다만 Next.js로 갈 계획이 아니라면 Vercel의 장점 일부를 못 씁니다. Astro 정적 블로그만 올린다면 Vercel은 “빠른 preview와 편한 dashboard”가 장점이고, Cloudflare Pages는 “정적 트래픽 비용 구조”가 장점입니다.
현재 조건에서의 선택
현재 조건이 기술 블로그라면 GitHub Pages가 가장 가벼운 출발점입니다. 아직 앱이 아니고, 글은 정적 HTML로 충분하며, 서버를 운영할 이유가 없기 때문입니다.
하지만 이 선택이 영구적이라는 뜻은 아닙니다. 트래픽이 커지고 광고형 콘텐츠가 늘면 Cloudflare Pages가 다음 후보입니다. 작은 제품이 실제 앱으로 커지고 로그인/대시보드/서버 API가 붙으면 Vercel 또는 Cloudflare Workers 기반 앱 구조를 다시 비교해야 합니다.
좋은 선택은 “가장 강한 플랫폼”을 고르는 것이 아닙니다. 지금의 복잡도에 맞는 플랫폼을 쓰다가, 복잡도가 바뀌는 순간 옮길 수 있게 경계를 남기는 것입니다.
자주 묻는 질문
개인 블로그도 처음부터 Cloudflare Pages로 가는 게 낫지 않나?
Cloudflare Pages도 좋은 선택입니다. 특히 Cloudflare DNS를 이미 쓰고 있고, 나중에 Workers/R2/D1까지 붙일 계획이 있다면 처음부터 Cloudflare Pages로 시작해도 됩니다. 다만 GitHub에 글을 쓰고 Actions로 빌드하는 흐름이 이미 편하다면 GitHub Pages가 더 단순합니다.
Vercel 무료 플랜으로 블로그를 운영하면 안 되나?
가능합니다. 다만 정적 블로그만 운영한다면 Vercel의 강점인 Next.js 통합, preview workflow, serverless functions를 충분히 쓰지 못할 수 있습니다. 블로그가 제품 앱과 같은 생명주기를 갖거나 Next.js 앱으로 커질 가능성이 크다면 Vercel이 더 설득력 있습니다.
광고형 블로그는 어느 시점에 옮겨야 하나?
방문자 수보다 전송량을 봐야 합니다. 이미지가 많은 글이 많아져서 월 100GB 근처로 가거나, GitHub Pages의 soft limit를 안정적으로 넘는 흐름이 보이면 Cloudflare Pages를 검토하는 편이 좋습니다. 이때는 sitemap, canonical, URL 구조를 유지한 채 DNS와 배포 플랫폼만 바꾸는 계획이 중요합니다.
참고 자료
- Vercel Pricing
- Vercel Limits
- Cloudflare Pages Limits
- Cloudflare Pages Functions Pricing
- Cloudflare Workers Pricing
- GitHub Pages 소개
- GitHub Pages Limits
이어서 읽기
GitHub Pages로 시작할 때 확인해야 할 SEO 기준은 GitHub Pages 블로그 SEO: 검색 노출에 불리할까?에서 다룹니다. 프레임워크 선택 관점은 Astro vs Next.js: 기술 블로그에 Next.js를 쓰지 않은 이유를 보면 이어집니다.