GitHub 안에서 공개 프로젝트 문서와 배포를 함께 관리하려면 GitHub Pages가 간편하고, 무료로 Private 저장소를 연결하거나 브랜치별 미리보기를 사용하려면 Cloudflare Pages가 유리하다. 두 서비스 모두 정적 사이트를 자동 배포할 수 있지만, 저장소 공개 범위와 배포 관리 방식에 따라 선택이 달라진다.
이 블로그는 GitHub Pages를 사용하다가 소스 저장소를 Private으로 전환하면서 Cloudflare Pages를 선택했다. 글과 이미지는 공개하되 원본 Markdown·설정·커밋 기록은 비공개로 관리하려는 목적이었다. 이 사례와 함께, GitHub Pages를 유지하는 편이 나은 조건도 비교한다.
1. 저장소와 웹 호스팅을 분리해서 보기#
두 서비스 모두 Hugo가 생성한 HTML·CSS·JavaScript·이미지를 제공할 수 있다. 차이는 소스를 보관하는 위치보다 어디서 빌드하고 배포하는지에 있다.
| 구성 | 소스 저장 | 빌드·배포 | 방문자가 접속하는 서비스 |
|---|---|---|---|
| GitHub Pages + Hugo | GitHub 저장소 | GitHub Actions의 사용자 정의 워크플로 | GitHub Pages |
| Cloudflare Pages + Hugo | GitHub 저장소 | Cloudflare Pages의 Git 연동 빌드 | Cloudflare Pages |
이 표의 GitHub Pages 구성은 이 블로그에서 사용하던 방식이다. GitHub Pages의 모든 배포가 같은 워크플로를 요구하는 것은 아니다.
Cloudflare Pages로 이전하더라도 소스는 GitHub에 그대로 둘 수 있다. 저장소를 다른 Git 서비스로 옮기거나 로컬 Git 사용법을 바꿀 필요는 없다. Cloudflare Git 연동
두 구성 모두 push를 계기로 자동 배포할 수 있다. Cloudflare Pages도 Git 연동과 운영 브랜치 자동 배포를 설정하면 GitHub push → Cloudflare 빌드 → 사이트 배포로 이어진다. 호스팅을 옮긴다고 매번 파일을 수동 업로드해야 하는 것은 아니다.
2. 무료 플랜에서 비교할 항목#
2026년 10월 21일 공식 문서 확인 기준이다. 정적 사이트 호스팅을 비교하며, 도메인 구매비·유료 플랜·외부 DB와 서버 API 비용은 포함하지 않는다.
| 항목 | GitHub Pages — GitHub Free | Cloudflare Pages — Free |
|---|---|---|
| Public 저장소 배포 | 지원 | 지원 |
| Private 저장소 배포 | 미지원, GitHub Pro 등 지원 플랜 필요 | Git 연동으로 지원 |
| GitHub push 기반 배포 | Actions 등으로 구성 | 연결한 브랜치의 push로 자동 빌드·배포 |
| 기본 도메인 | github.io | pages.dev |
| 커스텀 도메인·HTTPS | 지원 | 지원 |
| 빌드 제한 | 시간당 10회 소프트 제한. 사용자 정의 Actions 워크플로에는 이 제한 미적용 | 월 500회, 계정당 동시 빌드 1개 |
| 빌드·배포 시간 제한 | Pages 배포 10분 | 빌드 20분 |
| 정적 사이트 용량 제한 | 게시 사이트 최대 1GB | 사이트당 최대 20,000개 파일, 파일당 최대 25MiB |
| 트래픽·요청 | 월 100GB 대역폭 소프트 제한 | Functions를 호출하지 않는 정적 자산 요청은 무료·무제한 |
근거: GitHub Pages 이용 조건, GitHub Pages 제한, Cloudflare Pages 제한, Cloudflare 정적 자산과 Functions 요금 구분.
한도의 기준은 서로 다르다. GitHub의 사이트 전체 용량과 Cloudflare의 파일 수·개별 파일 크기를 같은 제한으로 비교하면 안 된다. 이미지가 많다면 파일 수를, 큰 다운로드 파일을 제공한다면 개별 파일 크기를 확인한다.
Cloudflare Pages의 정적 자산 요청과 Pages Functions 실행도 구분해야 한다. 서버 측 처리를 추가하면 Functions 요청은 Workers 플랜의 사용량·요금 체계를 따른다. 정적 HTML 블로그의 조건을 서버 API에 그대로 적용할 수는 없다.
3. GitHub Pages가 유리한 목적#
GitHub 안에서 소스와 배포를 함께 관리#
이미 GitHub에서 코드·이슈·PR을 관리한다면 Pages까지 같은 서비스에서 운영할 수 있다. 별도 Cloudflare 계정과 GitHub App 접근 권한을 관리할 필요가 줄어든다. 관리할 서비스 수를 최소화하려는 공개 프로젝트 문서나 개인 사이트에 적합하다.
저장소마다 프로젝트 사이트를 만들 수 있어, 코드와 사용 설명서를 같은 저장소에서 관리하기에도 편하다. 기본 주소는 <owner>.github.io/<repositoryname>/ 형태다. GitHub Pages 사이트 유형
기존 GitHub Actions 절차 활용#
이미 Actions에서 테스트와 문서 생성을 실행한다면, 같은 워크플로에 Pages 배포를 연결할 수 있다. 예를 들어 링크 검사 → Hugo 빌드 → 성공한 결과 배포를 작업 의존관계로 구성하고 YAML 파일로 버전 관리할 수 있다. Pages 사용자 정의 워크플로
Cloudflare에서도 빌드 스크립트나 외부 CI를 활용할 수 있다. 여기서 GitHub Pages의 이점은 기능의 독점이 아니라 이미 운영 중인 Actions 절차와 관리 화면을 그대로 활용한다는 점이다. 반대로 Hugo 빌드 명령 하나면 충분하고 워크플로를 직접 관리하고 싶지 않다면 Cloudflare의 Git 연동이 간편할 수 있다.
단순한 정적 문서를 바로 게시#
HTML 파일이나 기본 Jekyll 구성이라면 게시할 브랜치와 루트 또는 /docs 폴더를 지정하는 방식으로 시작할 수 있다. 다만 이 글의 Hugo 구성은 빌드가 필요하므로 사용자 정의 Actions 워크플로를 사용했다. GitHub Pages 게시 소스 설정
4. Cloudflare Pages가 유리한 목적#
무료로 Private 저장소 기반 사이트 운영#
GitHub Free 계정에서 저장소는 Private으로 유지하고 사이트는 공개하려면 Cloudflare Pages의 Git 연동을 사용할 수 있다. GitHub Pages는 Private 저장소에 대해 지원되는 유료 플랜이 필요하다. 원본 소스의 공개 여부가 핵심 요구사항인 경우에 실질적인 차이가 생긴다.
변경 내용을 브랜치별로 미리보기#
Cloudflare Pages는 Git 연동 시 운영 브랜치 외의 변경을 Preview URL로 배포할 수 있다. 본문·테마 수정을 운영 사이트에 반영하기 전에 브라우저에서 검토하려는 경우에 유용하다. Preview 배포 대상 브랜치는 설정으로 제한할 수 있다. Cloudflare Git 연동과 Preview
GitHub Pages에서도 별도 저장소·경로와 Actions 등을 조합해 검토 환경을 만들 수 있지만, Cloudflare Pages처럼 Git 연동에 포함된 브랜치별 Preview 기능과는 구분해야 한다.
정적 자산 요청이 무료·무제한이라는 점도 트래픽이 많은 사이트의 검토 요소다. 다만 파일 크기·개수와 빌드 한도는 따로 적용되며, 이 조건이 속도나 가용성의 우위를 보장하는 것은 아니다.
5. 이 블로그가 이전한 이유: Private 저장소#
이 블로그 저장소를 Private으로 전환한 뒤 GitHub Pages 설정에는 다음 안내가 표시됐다.
GitHub Pro·Team 등 지원 플랜을 사용하면 Private 저장소에서도 GitHub Pages를 운영할 수 있다. 따라서 Private 저장소가 필요하다는 이유만으로 반드시 이전해야 하는 것은 아니다. GitHub 유료 플랜을 사용할지, 외부 호스팅을 연결할지를 선택하는 문제다.
이번에는 GitHub 저장소는 유지하고 Cloudflare Pages에 배포하는 방식을 선택했다. 이전 후 저장소를 Private으로 바꾸고, 그 상태에서도 Cloudflare의 저장소 복제·빌드·배포가 성공하는지 확인했다.
단, 저장소 비공개와 콘텐츠 비공개는 다르다. Private 전환은 원본 저장소에 대한 일반 접근을 제한한다. 웹에 공개된 글·이미지·HTML은 방문자가 계속 열람할 수 있고, 기존에 생성된 공개 fork나 clone도 회수되지 않는다. GitHub 저장소 공개 범위 변경
6. 목적별 선택 기준#
| 요구사항 | 먼저 검토할 선택 |
|---|---|
| 공개 프로젝트의 코드·문서·배포를 GitHub에서 함께 관리 | GitHub Pages |
| 테스트·문서 생성용 Actions 워크플로를 이미 운영 | GitHub Pages를 기존 절차에 연결 |
| GitHub 유료 플랜을 사용 중이고 현재 배포에 문제가 없음 | Private 저장소 지원 여부를 확인한 뒤 GitHub Pages 유지 |
| GitHub Free에서 소스는 Private, 웹사이트는 Public으로 운영 | Cloudflare Pages |
| 브랜치별 Preview URL로 수정 내용을 검토 | Cloudflare Pages의 Git 연동 |
| 공개 저장소의 소규모 정적 블로그, 특별한 배포 요구 없음 | 둘 다 가능. 익숙한 관리 방식과 한도를 기준으로 선택 |
| 호스트 디렉터리·커널·상주 프로세스까지 직접 관리 | 두 서비스가 아니라 VM·서버 호스팅 등 검토 |
서비스 이전만으로 검색 순위나 응답 속도가 개선된다고 가정하지 않는다. 이 비교에서는 동일 조건의 성능 측정을 하지 않았다. 현재 구성이 요구사항을 만족하면 이전 작업을 추가할 필요도 없다.
또한 정적 사이트를 제공할 수 있다는 사실이 모든 상업적 용도의 허용을 뜻하지는 않는다. GitHub Pages는 온라인 사업·전자상거래·상업용 SaaS 등의 사용에 별도 제한을 둔다. 수익화 목적이라면 실제 서비스 형태와 각 제공자의 이용약관을 함께 확인한다. GitHub Pages 제품 약관
마무리#
GitHub에서 공개 프로젝트와 배포를 함께 관리하는 목적이라면 GitHub Pages를, 무료 Private 저장소 연동이나 브랜치별 Preview가 필요하다면 Cloudflare Pages를 먼저 검토한다. 이미 GitHub 유료 플랜과 Actions를 사용 중이라면 Private 저장소 때문에 호스팅을 바꿀 필요도 없다.
이 블로그는 무료 Private 저장소 연동이 필요해 Cloudflare Pages로 이전했다. 다른 사이트에도 같은 선택을 적용하기보다 저장소 공개 범위, 기존 배포 절차, 검토용 미리보기의 필요성을 기준으로 결정하면 된다.
실제 설정은 Cloudflare Pages에 Hugo 블로그 배포하기, 운영 도메인 전환과 저장소 비공개 설정은 GitHub Pages에서 Cloudflare Pages로 이전하기에서 이어서 정리했다.