Jamstack 보관 - 일상의 소소함

이 글은 「Cloudflare 완전 정복: 입문부터 2026 AI 에이전트까지」 시리즈 4회입니다. 지난 3회까지 Cloudflare의 본질(1회), DNS·CDN 셋업(2회), 무료 SSL/TLS와 보안 헤더(3회)를 다뤘습니다. 오늘은 이 기반 위에 내 웹사이트를 실제로 올리는 단계—Cloudflare Pages를 이용한 Jamstack 정적 사이트 배포를 다룹니다.

“서버 없이 웹사이트를 운영한다”는 말이 2026년에는 더 이상 과장이 아닙니다. GitHub에 코드를 푸시하면 전 세계 330개 이상 엣지 노드에 자동 배포되고, HTTPS·CDN·프리뷰 환경까지 원클릭으로 끝나는 시대. 그 중심에 Cloudflare Pages가 있습니다. 무료 플랜만으로도 월 500회 빌드, 무제한 대역폭, 무제한 사이트 수를 제공하기 때문에, 개인 블로그부터 소규모 비즈니스 랜딩 페이지까지 비용 걱정 없이 운영할 수 있습니다.

Jamstack이란 무엇인가 — 정적 사이트가 다시 주목받는 이유

Cloudflare Pages를 제대로 활용하려면 먼저 Jamstack 개념을 이해해야 합니다. Jamstack은 JavaScript, API, Markup의 앞글자를 딴 웹 아키텍처로, 핵심 원칙은 단순합니다.

사전 빌드(Pre-rendering): HTML을 서버가 매번 생성하는 대신, 빌드 시점에 미리 만들어 둡니다.
CDN 우선 배포: 완성된 정적 파일을 전 세계 엣지에 배포해 사용자와 가장 가까운 곳에서 서빙합니다.
동적 기능은 API로: 댓글, 결제, 인증 같은 동적 기능은 서드파티 API 또는 서버리스 함수로 분리합니다.

전통적인 워드프레스 같은 서버 사이드 렌더링(SSR) 방식은 요청마다 PHP가 데이터베이스를 조회하고 HTML을 조립합니다. 트래픽이 몰리면 서버 부하가 급증하고, 보안 패치를 놓치면 해킹 위험에 노출됩니다. 반면 Jamstack의 정적 사이트는 이미 완성된 HTML 파일을 CDN이 직접 서빙하므로 서버 부하가 사실상 제로이고, 공격 표면도 극히 작습니다.

2026년 현재 Jamstack 생태계는 놀라울 만큼 성숙했습니다. 대표적인 정적 사이트 생성기(SSG)만 해도 이렇게 다양합니다.

Hugo: Go 기반, 빌드 속도 최강. 수천 페이지도 수 초 만에 빌드.
Astro: 아일랜드 아키텍처로 부분 하이드레이션 지원. 블로그·문서 사이트에 최적.
Next.js (정적 내보내기): React 생태계와 완벽 호환. output: 'export' 설정으로 정적 빌드.
Nuxt (정적 생성): Vue 기반 풀스택 프레임워크의 정적 모드.
11ty(Eleventy): 설정 최소, 템플릿 엔진 자유 선택. 가볍고 빠름.
Gatsby: GraphQL 데이터 레이어가 특징. 콘텐츠 중심 사이트에 강점.

이 중 어떤 도구를 쓰든 최종 결과물은 HTML·CSS·JS 파일 묶음이고, 이걸 Cloudflare Pages에 올리기만 하면 됩니다.

Cloudflare Pages란 — 무료 정적 사이트 배포의 새 기준

Cloudflare Pages는 2020년 말 베타로 시작해 2021년 정식 출시된 정적 사이트 호스팅 플랫폼입니다. Netlify, Vercel과 같은 카테고리에 속하지만, Cloudflare의 글로벌 네트워크 위에서 동작한다는 결정적 차이가 있습니다.

Pages의 핵심 특징

무제한 대역폭: 무료 플랜에서도 대역폭 제한이 없습니다. Netlify의 월 100GB, Vercel의 월 100GB 제한과 비교하면 압도적입니다.
무제한 사이트 수: 프로젝트를 몇 개든 만들 수 있습니다.
월 500회 빌드(무료): 하루 평균 16회 이상 배포해도 넉넉합니다.
자동 프리뷰 배포: Pull Request마다 고유 URL이 생겨 팀 리뷰가 편합니다.
글로벌 엣지 배포: 330개 이상 도시의 데이터센터에 자동 배포. 한국 서울에도 PoP가 있어 국내 사용자 응답 속도가 빠릅니다.
무료 SSL: 커스텀 도메인을 연결하면 Let’s Encrypt 인증서가 자동 발급됩니다. 3회에서 다룬 Cloudflare의 SSL 인프라와 동일합니다.
Functions(서버리스): Pages 프로젝트에 /functions 디렉토리를 추가하면 Cloudflare Workers 기반 서버리스 함수를 함께 배포할 수 있습니다. 9회에서 Workers를 상세히 다룹니다.

Pages vs Netlify vs Vercel — 2026년 비교

정적 사이트 배포 플랫폼 3강 비교입니다. 무료 플랜 기준으로 핵심 차이를 정리했습니다.

항목	Cloudflare Pages	Netlify	Vercel
월 대역폭	무제한	100 GB	100 GB
월 빌드 횟수	500회	300분(시간 기준)	6,000분(시간 기준)
동시 빌드	1개	1개	1개
프리뷰 배포	무제한	무제한	무제한
사이트 수	무제한	무제한	무제한
엣지 노드 수	330+	~20	~20
서버리스 함수	Workers (무료 10만 req/일)	Functions (125K req/월)	Serverless (100GB-hrs)
SSR 지원	Workers 통합	자체 런타임	자체 런타임 (Next.js 최적화)
커머셜 제한	없음	없음	비상업 프로젝트만(Hobby)

Cloudflare Pages의 가장 큰 강점은 무제한 대역폭과 글로벌 엣지 노드 수입니다. 블로그 글 하나가 갑자기 바이럴 되어 트래픽이 폭증해도 추가 비용이 발생하지 않고, 전 세계 어디서든 빠른 응답 속도를 보장합니다.

반면 Vercel은 Next.js와의 긴밀한 통합이 장점이고, Netlify는 오래된 생태계와 풍부한 플러그인이 강점입니다. 순수 정적 사이트를 비용 걱정 없이 운영하고 싶다면 Cloudflare Pages가 2026년 현재 가장 합리적인 선택입니다.

실습 ① — GitHub 연동으로 5분 배포

가장 일반적이고 권장되는 배포 방식입니다. GitHub 저장소에 코드를 푸시하면 자동으로 빌드·배포가 이루어집니다.

사전 준비

Cloudflare 계정 (무료 플랜 OK — 2회에서 생성한 계정 그대로 사용)
GitHub 계정과 정적 사이트 저장소

아직 정적 사이트가 없다면, 실습용으로 Astro 프로젝트를 빠르게 만들어 보겠습니다. Mac Studio 또는 Synology NAS DS+925에 SSH 접속한 뒤 아래 명령어를 실행합니다.

실습용 Astro 프로젝트 생성 (Mac Studio / Synology NAS)

# Node.js 18+ 필요. Mac Studio에서 Homebrew로 설치된 경우:
node --version   # v20.x 이상 확인

# Astro 프로젝트 생성 (대화형 설정)
npm create astro@latest my-first-pages -- --template blog

# 프로젝트 디렉토리 진입
cd my-first-pages

# 로컬에서 개발 서버 확인 (선택)
npm run dev
# → http://localhost:4321 에서 블로그 템플릿 확인

# Git 초기화 및 GitHub 푸시
git init
git add -A
git commit -m "feat: initial Astro blog"

# GitHub에 저장소 생성 후 (https://github.com/new)
git remote add origin https://github.com/YOUR_USERNAME/my-first-pages.git
git branch -M main
git push -u origin main

Synology NAS DS+925에서 실행하는 경우, SSH로 접속한 뒤 동일한 명령어를 사용합니다. NAS에 Node.js가 설치되어 있지 않다면 Docker 컨테이너 안에서 실행할 수도 있습니다.

# Synology NAS — Docker로 Node.js 사용하는 경우
docker run --rm -it -v $(pwd):/app -w /app node:20-slim bash

# 컨테이너 안에서 위의 npm create astro 명령 동일하게 실행

Cloudflare Pages 프로젝트 생성 — 대시보드 방식

GitHub에 코드가 올라갔으면 Cloudflare 대시보드에서 Pages 프로젝트를 연결합니다.

Cloudflare 대시보드 접속: dash.cloudflare.com → 좌측 메뉴에서 Workers & Pages 클릭
Create 버튼 클릭 → Pages 탭 선택 → Connect to Git
GitHub 계정 연결: “Connect GitHub” 클릭 → GitHub OAuth 인증 → 저장소 접근 권한 부여
저장소 선택: 방금 만든 my-first-pages 저장소 선택
빌드 설정:
- Production branch: main
- Framework preset: Astro 선택 (자동 감지되는 경우가 많음)
- Build command: npm run build
- Build output directory: dist
Save and Deploy 클릭

첫 빌드가 시작됩니다. Astro 블로그 템플릿 기준으로 보통 30초~1분이면 완료됩니다. 빌드가 끝나면 https://my-first-pages-abc.pages.dev 형태의 URL이 자동 생성됩니다. 이 URL로 바로 접속하면 전 세계 엣지에 배포된 내 사이트를 볼 수 있습니다.

이후부터는 main 브랜치에 코드를 푸시할 때마다 자동으로 새 빌드가 트리거되고, 배포가 완료되면 사이트가 업데이트됩니다. 별도의 CI/CD 파이프라인을 구성할 필요가 전혀 없습니다.

프레임워크별 빌드 설정 레퍼런스

Cloudflare Pages 대시보드에서 프레임워크를 선택하면 빌드 명령어와 출력 디렉토리가 자동 설정됩니다. 하지만 수동으로 입력해야 하는 경우를 위해 주요 프레임워크별 설정을 정리합니다.

프레임워크	Build command	Output directory	비고
Astro	`npm run build`	`dist`	가장 매끄러운 통합
Hugo	`hugo`	`public`	환경변수 `HUGO_VERSION` 지정 권장
Next.js (Static Export)	`npx next build`	`out`	`next.config.js`에 `output: 'export'` 필수
Nuxt (Static)	`npx nuxt generate`	`.output/public`	Nuxt 3 기준
Gatsby	`npx gatsby build`	`public`
11ty (Eleventy)	`npx @11ty/eleventy`	`_site`
Vite (vanilla)	`npx vite build`	`dist`	React/Vue SPA 포함
Jekyll	`jekyll build`	`_site`	Ruby 환경 빌드 시간 주의
순수 HTML	(없음)	`/` 또는 해당 폴더	빌드 불필요, 바로 배포

Hugo를 사용하는 경우, Cloudflare Pages의 빌드 환경에 설치된 Hugo 버전이 오래되었을 수 있습니다. 환경 변수로 원하는 버전을 지정하세요.

# Cloudflare Pages 환경 변수 설정 (대시보드 > Settings > Environment variables)
HUGO_VERSION = 0.147.1
NODE_VERSION = 20

실습 ② — Wrangler CLI로 직접 배포

GitHub 연동 없이 로컬에서 바로 배포하는 방법도 있습니다. CI/CD를 직접 구성하고 싶거나, GitHub Actions 등 외부 파이프라인에서 배포할 때 유용합니다.

Wrangler 설치 및 로그인

# Wrangler CLI 전역 설치
npm install -g wrangler

# Cloudflare 계정 인증 (브라우저가 열림)
wrangler login

# 인증 확인
wrangler whoami

프로젝트 빌드 후 직접 배포

# Astro 프로젝트 기준 — 먼저 로컬 빌드
cd my-first-pages
npm run build

# Cloudflare Pages에 배포 (첫 실행 시 프로젝트 자동 생성)
wrangler pages deploy dist --project-name my-first-pages

# 실행 결과 예시:
# ✨ Deployment complete!
# https://abc123def.my-first-pages.pages.dev

wrangler pages deploy 명령 하나로 빌드된 dist 폴더의 모든 파일이 Cloudflare 엣지에 업로드됩니다. 프로젝트가 아직 없으면 자동 생성할지 물어봅니다.

프로덕션 vs 프리뷰 배포

# 프로덕션 배포 (기본 — main 브랜치에 해당)
wrangler pages deploy dist --project-name my-first-pages --branch main

# 프리뷰 배포 (feature 브랜치에 해당)
wrangler pages deploy dist --project-name my-first-pages --branch feature/new-design

# 프리뷰 배포는 고유 URL 생성:
# https://feature-new-design.my-first-pages.pages.dev

CLI 배포의 장점은 자동화의 자유도입니다. GitHub Actions, GitLab CI, Jenkins 등 어떤 CI 도구에서든 wrangler pages deploy 한 줄로 배포할 수 있습니다.

GitHub Actions 연동 예시

GitHub 연동 대신 GitHub Actions에서 Wrangler CLI로 배포하는 워크플로 예시입니다. 빌드 환경을 세밀하게 제어하고 싶을 때 유용합니다.

# .github/workflows/deploy.yml
name: Deploy to Cloudflare Pages
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci
      - run: npm run build

      - uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy dist --project-name my-first-pages

CLOUDFLARE_API_TOKEN은 Cloudflare 대시보드 → My Profile → API Tokens에서 “Cloudflare Pages: Edit” 권한으로 생성합니다. CLOUDFLARE_ACCOUNT_ID는 대시보드 우측 사이드바 “Account ID”에서 확인할 수 있습니다.

커스텀 도메인 연결 — 2회 DNS 설정의 실전 적용

*.pages.dev 도메인도 충분히 쓸 만하지만, 내 도메인을 연결하면 브랜드 정체성과 SEO 모두 개선됩니다. 2회에서 Cloudflare에 DNS를 셋업한 도메인이 있다면 연결이 특히 간단합니다.

대시보드에서 커스텀 도메인 추가

Workers & Pages → 프로젝트 선택 → Custom domains 탭
Set up a custom domain 클릭
도메인 입력: 예) blog.yourdomain.com
DNS가 이미 Cloudflare에 있으면 CNAME 레코드가 자동 추가됨
SSL 인증서도 자동 발급 (3회에서 다룬 Universal SSL과 동일 메커니즘)

# Cloudflare DNS에 자동 추가되는 레코드 형태
# Type: CNAME
# Name: blog
# Target: my-first-pages.pages.dev
# Proxy status: Proxied (주황색 구름)

외부 DNS를 사용하는 경우에는 수동으로 CNAME 레코드를 추가해야 합니다. 하지만 2회에서 이미 Cloudflare DNS로 마이그레이션했다면 클릭 한 번이면 끝입니다. 이것이 시리즈를 순서대로 따라온 보람입니다.

루트 도메인(yourdomain.com)도 연결할 수 있습니다. 일반적으로 루트 도메인에 CNAME을 쓸 수 없지만, Cloudflare DNS는 CNAME Flattening 기술로 루트 도메인에도 CNAME을 설정할 수 있게 해 줍니다. Pages 프로젝트에 루트 도메인을 추가하면 자동으로 처리됩니다.

www 리다이렉트 설정

www.yourdomain.com과 yourdomain.com 모두 접근 가능하게 하되, 하나로 통일하고 싶다면 Cloudflare의 Redirect Rules를 사용합니다.

# Cloudflare 대시보드 → 도메인 → Rules → Redirect Rules
# 규칙 추가:
# - When: Hostname equals "www.yourdomain.com"
# - Then: Dynamic redirect
#   URL: concat("https://yourdomain.com", http.request.uri.path)
#   Status code: 301

이렇게 하면 www 접속 시 깔끔하게 루트 도메인으로 301 리다이렉트됩니다. SEO 점수에도 긍정적입니다.

프리뷰 배포(Preview Deployments) 200% 활용하기

Cloudflare Pages의 가장 실용적인 기능 중 하나가 프리뷰 배포입니다. main 이외의 브랜치에 푸시하거나 Pull Request를 열면, 해당 변경사항만 반영된 별도의 URL이 자동 생성됩니다.

프리뷰 배포의 동작 방식

브랜치별 URL: feature-redesign.my-first-pages.pages.dev 형태로 브랜치 이름이 서브도메인에 반영됩니다.
커밋별 URL: 매 커밋마다 고유 해시 URL도 생성됩니다. 예: abc1234.my-first-pages.pages.dev
GitHub PR 코멘트: GitHub 연동 시 PR에 자동으로 프리뷰 URL이 코멘트로 달립니다.
무제한: 프리뷰 배포 수에 제한이 없습니다.

실전 활용 시나리오

시나리오 1 — 디자인 리뷰: 디자이너에게 프리뷰 URL을 공유하면 로컬 환경 없이도 실제 배포된 상태로 확인할 수 있습니다.

시나리오 2 — A/B 테스트 초안: 랜딩 페이지 두 가지 버전을 각각 다른 브랜치에 만들고, 두 프리뷰 URL을 비교합니다.

시나리오 3 — 클라이언트 승인: 프리랜서라면 작업물을 프리뷰 URL로 공유해 클라이언트 피드백을 받을 수 있습니다. 프로덕션에 영향 없이 수정 → 재배포 → 재확인이 자유롭습니다.

프리뷰 접근 제한 — Cloudflare Access 연동

프리뷰 URL은 기본적으로 공개입니다. 사내 프로젝트라면 외부 노출이 부담스러울 수 있습니다. 이때 Cloudflare Access(6회에서 상세히 다룹니다)를 연동하면 프리뷰 배포에 인증 벽을 세울 수 있습니다.

# Cloudflare 대시보드 → Zero Trust → Access → Applications
# 프리뷰 도메인 패턴: *.my-first-pages.pages.dev
# 정책: 특정 이메일 도메인만 허용
# → 인증되지 않은 접근 시 Cloudflare 로그인 화면 표시

빌드 설정 최적화 팁

환경 변수 관리

API 키, 분석 도구 ID 등 환경별로 다른 값은 Cloudflare Pages의 환경 변수 기능으로 관리합니다.

# 대시보드 → 프로젝트 → Settings → Environment variables

# Production 환경
SITE_URL = https://yourdomain.com
ANALYTICS_ID = G-XXXXXXXXXX

# Preview 환경 (별도 설정 가능)
SITE_URL = https://preview.yourdomain.com
ANALYTICS_ID = G-PREVIEW0000

프로덕션과 프리뷰 환경에 서로 다른 환경 변수를 설정할 수 있어, 프리뷰에서는 분석 추적을 끄거나 테스트용 API 엔드포인트를 사용하는 것이 가능합니다.

빌드 캐시 활용

Cloudflare Pages는 node_modules를 자동 캐시합니다. 하지만 빌드 시간을 더 줄이고 싶다면 몇 가지 팁이 있습니다.

패키지 매니저 락 파일 유지: package-lock.json(npm) 또는 pnpm-lock.yaml(pnpm)을 커밋하면 의존성 설치가 빨라집니다.
불필요한 devDependencies 정리: 빌드에 필요 없는 패키지는 제거합니다.
Hugo 사용 시 버전 고정: 앞서 언급한 HUGO_VERSION 환경 변수로 빌드 재현성을 확보합니다.

빌드 실패 시 디버깅

빌드가 실패하면 대시보드의 Deployments 탭에서 빌드 로그를 확인할 수 있습니다. 흔한 실패 원인과 해결법입니다.

증상	원인	해결
`npm ERR! ERESOLVE`	의존성 충돌	환경 변수 `NPM_FLAGS = --legacy-peer-deps` 추가
`Error: Cannot find module`	락 파일 누락	`package-lock.json` 커밋
`Hugo: command not found`	Hugo 미설치	`HUGO_VERSION` 환경 변수 설정
빌드는 성공인데 페이지 비어있음	Output directory 오류	빌드 설정의 출력 디렉토리 확인 (`dist`, `public` 등)
`Pages only supports files up to 25 MiB`	단일 파일 크기 초과	대용량 에셋은 R2(8회)에 분리

Pages의 숨은 고급 기능

_headers 파일 — 커스텀 HTTP 헤더

3회에서 배운 보안 헤더를 Pages에서도 적용할 수 있습니다. 프로젝트 루트(빌드 출력 디렉토리)에 _headers 파일을 추가하면 됩니다.

# 빌드 출력 디렉토리에 위치 (예: public/_headers)
/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'

/assets/*
  Cache-Control: public, max-age=31536000, immutable

경로 패턴별로 헤더를 다르게 설정할 수 있습니다. /assets/* 경로에는 1년 캐시를 적용해 정적 에셋의 재다운로드를 방지하는 것이 대표적인 최적화입니다.

_redirects 파일 — URL 리다이렉트·리라이트

# 빌드 출력 디렉토리에 위치 (예: public/_redirects)

# 301 영구 리다이렉트
/old-post    /new-post    301

# 302 임시 리다이렉트
/event       /event-2026  302

# Splat(와일드카드) 리다이렉트
/blog/*      /posts/:splat  301

# SPA 라우팅용 폴백 (클라이언트 사이드 라우팅)
/*           /index.html    200

SPA(Single Page Application)를 배포할 때 마지막 줄이 핵심입니다. React Router, Vue Router 등 클라이언트 사이드 라우팅을 사용하는 경우, 모든 경로를 index.html로 리라이트(200)해야 새로고침 시 404가 발생하지 않습니다.

Pages Functions — 서버리스 함수 간단 체험

Pages 프로젝트에 functions/ 디렉토리를 추가하면 서버리스 함수가 자동으로 배포됩니다. 정적 사이트와 API를 하나의 프로젝트에서 관리할 수 있는 강력한 기능입니다. (9회 Workers에서 깊이 다루지만, 맛보기로 확인해 봅니다.)

// functions/api/hello.js
export async function onRequestGet(context) {
  return new Response(JSON.stringify({
    message: "Hello from Cloudflare Pages Functions!",
    timestamp: new Date().toISOString()
  }), {
    headers: { "Content-Type": "application/json" }
  });
}

이 파일을 프로젝트에 추가하고 배포하면 https://yourdomain.com/api/hello 엔드포인트가 자동 생성됩니다. 파일 경로가 곧 URL 경로가 되는 파일 시스템 라우팅 방식입니다.

# 로컬 테스트 — Wrangler로 Pages Functions 포함 개발 서버 실행
wrangler pages dev dist --port 8788

# 테스트 요청
curl http://localhost:8788/api/hello
# → {"message":"Hello from Cloudflare Pages Functions!","timestamp":"2026-05-29T..."}

이 기능 덕분에 폼 제출 처리, 외부 API 프록시, 간단한 인증 로직 등을 별도 백엔드 서버 없이 Pages 프로젝트 안에서 해결할 수 있습니다.

실전 응용 — Synology NAS에서 Hugo 블로그 운영하기

Mac Studio나 Synology NAS DS+925를 홈랩으로 운영하면서 Hugo 블로그를 Cloudflare Pages로 배포하는 실전 워크플로를 정리합니다.

NAS에서 Hugo 블로그 작성·배포 자동화

# Synology NAS에 SSH 접속
ssh your-nas-user@nas-ip

# Hugo 프로젝트 클론 (이미 GitHub에 있는 경우)
cd /volume1/projects
git clone https://github.com/YOUR_USERNAME/my-hugo-blog.git
cd my-hugo-blog

# 새 글 작성
# Docker로 Hugo 실행 (NAS에 Hugo 바이너리 직접 설치하기 어려운 경우)
docker run --rm -v $(pwd):/src -w /src hugomods/hugo:latest new content posts/cloudflare-pages-guide.md

# 에디터로 글 작성 (VS Code Remote SSH 추천)
# → /volume1/projects/my-hugo-blog/content/posts/cloudflare-pages-guide.md

# 작성 완료 후 푸시 → Cloudflare Pages 자동 빌드·배포
git add -A
git commit -m "feat: add Cloudflare Pages guide post"
git push origin main

# 약 30초 후 https://yourdomain.com 에 새 글 반영!

이 워크플로의 아름다운 점은, NAS가 항상 켜져 있으므로 어디서든 SSH나 VS Code Remote로 접속해 글을 쓰고 git push 한 줄이면 전 세계에 배포된다는 것입니다. 서버 관리, 배포 파이프라인 걱정이 완전히 사라집니다.

Mac Studio에서의 로컬 개발 + 배포

# Mac Studio — Homebrew로 Hugo 설치
brew install hugo

# 새 사이트 생성
hugo new site my-blog
cd my-blog

# 테마 추가 (예: PaperMod — 인기 블로그 테마)
git init
git submodule add https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod

# hugo.toml 기본 설정
cat > hugo.toml << 'EOF'
baseURL = "https://blog.yourdomain.com/"
languageCode = "ko-kr"
title = "나의 기술 블로그"
theme = "PaperMod"

[params]
  env = "production"
  description = "Cloudflare Pages로 배포한 기술 블로그"
EOF

# 첫 글 작성
hugo new content posts/hello-world.md

# 로컬 프리뷰
hugo server -D
# → http://localhost:1313

# 빌드 + Wrangler로 직접 배포
hugo
wrangler pages deploy public --project-name my-blog

Cloudflare Pages 월 비용 명세표

이번 회차에서 다룬 Cloudflare Pages 관련 비용을 플랜별로 정리합니다.

항목	Free	Pro ($20/월)	Business ($200/월)
사이트(프로젝트) 수	무제한	무제한	무제한
월 빌드 횟수	500회	5,000회	20,000회
동시 빌드	1개	5개	20개
대역폭	무제한	무제한	무제한
커스텀 도메인	무제한	무제한	무제한
프리뷰 배포	무제한	무제한	무제한
SSL 인증서	자동·무료	자동·무료	자동·무료
Pages Functions	10만 req/일	1,000만 req/월	5,000만 req/월
빌드 시간 제한	빌드당 20분	빌드당 20분	빌드당 20분
최대 파일 크기	25 MiB/파일	25 MiB/파일	25 MiB/파일
최대 파일 수	20,000개/배포	20,000개/배포	20,000개/배포

결론: 개인 블로그나 소규모 프로젝트라면 Free 플랜으로 충분합니다. 월 500회 빌드는 매일 16번 이상 배포할 수 있는 양이고, 대역폭 무제한이므로 트래픽 폭증에도 추가 비용이 없습니다. Pro 이상은 팀 단위 협업이나 다수 프로젝트를 동시 빌드해야 할 때 고려하면 됩니다.

이전 회차와 연결 — DNS·SSL이 Pages를 완성한다

이번 4회의 내용은 1~3회에서 쌓은 기반 위에 올려져 있습니다.

2회(DNS)에서 Cloudflare에 등록한 도메인 → Pages 커스텀 도메인 연결 시 CNAME이 자동 추가됩니다.
3회(SSL)에서 설정한 Full(Strict) 모드 → Pages 도메인에도 동일하게 적용되어 엔드투엔드 HTTPS가 보장됩니다.
1회에서 소개한 Cloudflare의 330+ 글로벌 엣지 → Pages 배포가 바로 이 네트워크 위에서 동작합니다.

이렇게 DNS → SSL → 배포가 하나의 플랫폼 안에서 매끄럽게 연결되는 것이 Cloudflare 생태계의 진짜 힘입니다. 각각 다른 서비스를 조합하는 것과 비교하면 설정 복잡도와 장애 포인트가 크게 줄어듭니다.

마무리 — 정적 사이트 배포, 이제 서버가 필요 없다

Cloudflare Pages는 "정적 사이트 배포"라는 작업의 마찰을 거의 제로에 가깝게 만들었습니다. GitHub 푸시 한 번이면 전 세계 배포가 완료되고, 무제한 대역폭 덕분에 비용 걱정도 없습니다. _headers, _redirects 파일로 세밀한 제어가 가능하고, Pages Functions로 간단한 서버리스 로직까지 같은 프로젝트에서 처리할 수 있습니다.

1~4회까지의 여정을 돌아보면, Cloudflare 계정 하나로 DNS, CDN, SSL, 그리고 정적 사이트 호스팅까지 모두 무료로 확보한 셈입니다. 다음 5회부터는 Phase 2—홈랩·자가호스팅 영역으로 넘어갑니다.

다음 회차 예고: 5회에서는 Cloudflare Tunnel을 다룹니다. Synology NAS나 Mac Studio 같은 홈 서버를 포트 포워딩·공인 IP 없이 안전하게 외부에 공개하는 방법—인바운드 포트를 단 하나도 열지 않고 HTTPS 접속을 가능하게 하는 마법 같은 기술입니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.

📚 시리즈: Cloudflare 완전 정복: 입문부터 2026 AI 에이전트까지 (총 16화 중 4화)
◀ 이전 3화 (다음 차수는 아직 게시되지 않았습니다)