Vercel, Cloudflare Pages, GitHub Pages 중 어디에 올릴까?

이 저장소에서 실제로 운영 중인 것은 Astro로 빌드한 정적 사이트입니다. astro.config.mjs의 site는 https://2dayapp.com이고, GitHub Actions 워크플로가 dist를 Pages에 배포하며 루트에 2dayapp.com CNAME을 넣습니다. 로그인·결제·서버 API를 운영하는 앱은 아닙니다.

이 조건에서는 GitHub Pages를 계속 쓰는 편이 자연스럽습니다. 정적 결과물만 필요하고, GitHub Actions에서 빌드한 dist를 Pages에 올리는 흐름이 이미 자리 잡았기 때문입니다. 다만 이 판단을 모든 블로그의 정답으로 확대하지는 않습니다. 가격과 한도는 바뀔 수 있으므로 실제 이전이나 신청 전에는 각 제공자의 공식 문서를 다시 확인해야 합니다.

2dayapp에서 실제로 걸리는 선택 기준

이 비교의 출발점은 기능 목록이 아니라 현재 발행 경로다. package.json의 pnpm verify는 포맷·lint·Astro/TypeScript 검사·테스트·빌드를 차례로 실행하고, pnpm build는 dist를 만든 뒤 빌드 결과의 내부 링크도 검사한다. 배포 워크플로는 verify가 성공한 뒤 dist를 GitHub Pages에 올리고, 그 다음 변경 URL을 IndexNow에 알린다.

따라서 지금 비교하는 것은 “어느 호스팅이 더 강한가”가 아니다. 이 정적 산출물과 검증 순서를 다른 플랫폼에서도 유지할 수 있는지, 그리고 로그인·함수·데이터 저장처럼 정적 파일 바깥의 요구가 실제로 생겼는지를 비교한다. 현재 저장소에는 플랫폼별 트래픽·청구액을 나란히 측정한 자료가 없으므로, 아래 숫자는 운영 결과가 아니라 공식 제한을 읽기 위한 기준이다.

플랫폼이 갈리는 지점

개인 기술 블로그나 작은 문서 사이트라면 GitHub Pages로 시작해도 충분합니다. 서버가 없고, 콘텐츠가 정적 HTML로 끝나며, 월 100GB 수준의 소프트 대역폭 한도 안에 있다면 가장 단순합니다.

정적 사이트지만 트래픽이 커질 수 있고, Cloudflare DNS/WAF/Workers/R2/D1 같은 주변 기능까지 쓸 계획이라면 Cloudflare Pages가 더 오래 버팁니다. 특히 정적 asset 요청이 무료이자 unlimited라는 점은 광고형 콘텐츠 사이트에 큰 장점입니다.

Next.js 앱, preview 중심 협업, 서버리스 함수, ISR, 관측성, 팀 기능이 중요해지면 Vercel이 편합니다. 대신 편의 기능이 늘수록 비용 구조가 세밀해집니다. “그냥 무료 배포”로 쓰기보다 앱 플랫폼으로 보는 편이 맞습니다.

이 선택에서 실제로 비교한 수치

위 표에서 특히 조심해야 할 부분은 한도의 성격입니다. GitHub Pages의 월 100GB와 시간당 10 builds는 soft limit이고, 사이트 1GB와 배포 10분 timeout은 실제로 막히는 제약에 가깝습니다. Vercel Hobby의 32 builds/hour와 100 deployments/day는 서로 다른 제한이므로 하나의 배포 빈도로 합쳐 읽으면 안 됩니다. 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가 있습니다.

2dayapp에 적용하면: 블로그는 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를 후보로 둡니다. 정적 페이지는 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는 3,600초 기준 32 builds/hour, 하루 100 deployments/day입니다. 빌드 횟수와 배포 횟수는 같은 지표가 아니므로 표에서 분리했습니다. 함수 실행 시간은 프로젝트 설정과 Fluid compute 적용 여부에 따라 달라질 수 있으므로, 단순 블로그 비교에서는 “함수를 얼마나 오래 실행할 수 있나”보다 “함수와 이미지 최적화, analytics, 로그가 비용 항목으로 분리된다”는 점을 먼저 봐야 합니다.

Vercel을 검토할 때: “블로그”만이면 플랫폼 표면적이 과할 수 있습니다. 하지만 블로그가 제품 앱의 일부이고 로그인 후 대시보드, 실험 페이지, 서버리스 API, Next.js 렌더링 전략이 필요하다면 Vercel의 개발 편의가 선택 이유가 됩니다.

숫자를 실제 조건에 대입하는 방법

이 글에는 2dayapp의 Analytics나 플랫폼별 실제 청구서가 없다. 따라서 “월 몇 명이면 무조건 이전” 같은 기준을 만들지 않는다. 실제 이전을 검토할 때는 다음 세 값을 자신의 운영 데이터로 바꿔 넣어야 한다.

1. 월 전송량과 페이지·이미지별 전송 크기
2. 빌드 시간과 한 달의 빌드·배포 횟수
3. 정적 파일만 필요한지, 함수·로그인·데이터 저장이 필요한지

첫 두 값이 GitHub Pages의 제한에 가까워지거나 세 번째 요구가 생기면 비교표의 결론이 달라진다. 그 전에는 “무료 플랜에서 가장 큰 숫자”보다 현재 운영 흐름을 유지하는 비용을 먼저 본다.

언제까지 쓰고, 언제 옮길까

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 비용과 사용량 기반 과금을 감당할 수 있다.

마이그레이션은 어떻게 하면 좋을까

처음부터 플랫폼 종속 기능을 많이 쓰면 나중에 옮기기 어렵습니다. 그래서 정적 블로그는 다음 원칙을 지키는 편이 좋습니다.

1. 콘텐츠는 Markdown 또는 CMS 데이터로 분리한다.
2. URL 구조를 플랫폼 이름과 무관하게 설계한다.
3. canonical, sitemap, RSS를 프레임워크 레벨에서 만든다.
4. 이미지와 큰 파일은 나중에 별도 스토리지로 뺄 수 있게 둔다.
5. redirect 규칙은 문서화한다.
6. 환경 변수와 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는 “정적 트래픽 비용 구조”가 장점입니다.

현재 조건에서의 선택

현재 2dayapp은 기술 블로그이고, 글은 정적 HTML로 충분하며, 배포도 GitHub Actions의 dist 산출물로 끝납니다. 이 저장소에서 확인한 조건만 놓고 보면 GitHub Pages가 가장 가벼운 선택입니다. 실제 트래픽이 낮다고 추정해서가 아니라, 현재 필요한 기능에 서버 런타임이 없기 때문입니다.

하지만 이 선택이 영구적이라는 뜻은 아닙니다. 전송량·빌드 한도·운영 기능이 실제 제약이 되면 Cloudflare Pages를 다시 비교하고, 로그인·대시보드·서버 API가 붙으면 Vercel 또는 Cloudflare Workers 기반 앱 구조를 다시 검토해야 합니다.

좋은 선택은 “가장 강한 플랫폼”을 고르는 것이 아닙니다. 지금의 복잡도에 맞는 플랫폼을 쓰다가, 복잡도가 바뀌는 순간 옮길 수 있게 경계를 남기는 것입니다.

다시 판단할 조건

여기서 “검토”는 바로 이전한다는 뜻이 아닙니다. 현재 URL, canonical, sitemap, RSS와 배포 결과를 먼저 보존할 수 있는지 확인한 뒤 플랫폼을 바꿉니다.

참고 자료: 가격·제한을 확인한 문서

• Vercel Pricing
• Vercel Limits
• Cloudflare Pages Limits
• Cloudflare Pages Functions Pricing
• Cloudflare Workers Pricing
• GitHub Pages 소개
• GitHub Pages Limits

이 비교는 현재 2dayapp의 정적 구조와 각 플랫폼이 공개한 제한을 놓고 만든 결정 기록입니다. 실제 트래픽·청구액·검색 성과를 측정한 보고서는 아니며, 조건이 바뀌면 같은 표를 다시 계산해야 합니다.