Cloudflare Pages는 무료인가요?

무료 플랜으로 월 500회 빌드, 무제한 요청, 무제한 대역폭을 제공합니다. 대부분의 개인·중소 프로젝트는 무료로 충분합니다.

Vercel과 어떻게 다른가요?

Cloudflare Pages는 글로벌 CDN이 더 넓고(300+ 도시), 무료 대역폭이 무제한이며, Workers/D1/R2 등 Edge 생태계와 통합이 강합니다. Vercel은 Next.js 최적화와 개발자 경험이 더 매끄럽습니다.

SSR(서버 사이드 렌더링)도 가능한가요?

가능합니다. Astro, Next.js, SvelteKit, Remix 등 주요 프레임워크의 SSR을 Cloudflare Pages Functions(Edge)에서 실행할 수 있습니다.

GitHub Actions로 빌드하면 뭐가 좋나요?

Cloudflare 빌드 횟수(무료 500회)를 아끼고, 빌드 환경(Node 버전, 캐시, 시크릿)을 세밀하게 제어할 수 있습니다. 대량 페이지 사이트에 유리합니다.

포트폴리오·블로그를 배포하면 취업에 도움이 되나요?

이력서에 URL을 적을 수 있고, 면접에서 “배포·도메인·빌드”를 말할 근거가 됩니다. [개발 취업 실전 팁](/blog/developer-job-hunting-practical-tips/)의 포트폴리오·GitHub 절과 함께 보세요.

Cloudflare Pages 완벽 가이드 | 무료 배포·Edge 렌더링·Wrangler CLI

2026년 4월 1일 · 25분 읽기 · 수정 2026년 4월 17일 중급 가이드

이 글의 핵심

Cloudflare Pages로 정적 사이트·SSR 앱을 무료로 배포하고, Edge Functions로 서버 로직을 실행하는 방법을 다룹니다. GitHub 연동, Wrangler CLI, 환경 변수, 커스텀 도메인, 빌드 최적화까지 실전 예제로 설명합니다.

들어가며

Cloudflare Pages는 정적 사이트(Static Site)와 서버 사이드 렌더링(SSR) 앱을 글로벌 Edge 네트워크에 배포할 수 있는 플랫폼입니다. Vercel·Netlify와 비슷하지만, 무료 대역폭 무제한, 300개 이상 도시의 CDN, Workers·D1·R2와의 통합이 강점입니다.

이 글에서는 GitHub 저장소 연동, Wrangler CLI 배포, 환경 변수, 커스텀 도메인, Functions(Edge 서버 로직), 빌드 최적화, 그리고 Vercel과의 비교를 실전 예제로 다룹니다.

Node.js 앱 배포 전반은 Node.js 배포 가이드 (PM2, Docker, AWS, Nginx)에서, CI/CD 파이프라인은 Node.js + GitHub Actions CI/CD에서 확인할 수 있습니다.

실전 경험에서 배운 교훈

이 기술을 실무 프로젝트에 처음 도입했을 때, 공식 문서만으로는 알 수 없었던 많은 함정들이 있었습니다. 특히 프로덕션 환경에서 발생하는 엣지 케이스들은 로컬 개발 환경에서는 재현조차 되지 않았죠.

가장 어려웠던 점은 성능 최적화였습니다. 처음엔 “동작만 하면 되겠지”라고 생각했지만, 실제 사용자 트래픽이 몰리면서 병목 지점들이 하나씩 드러났습니다. 특히 데이터베이스 쿼리 최적화, 캐싱 전략, 에러 핸들링 구조 등은 여러 번의 장애를 겪으면서 개선해 나갔습니다.

이 글에서는 그런 시행착오를 통해 얻은 실전 노하우와, “이렇게 하면 안 된다”는 교훈들을 함께 정리했습니다. 특히 트러블슈팅 섹션은 실제 장애 대응 경험을 바탕으로 작성했으니, 비슷한 문제를 마주했을 때 참고하시면 도움이 될 것입니다.

1. Cloudflare Pages란?

핵심 특징

항목	설명
CDN	전 세계 300+ 도시, Cloudflare 네트워크
무료 플랜	월 500회 빌드, 무제한 요청·대역폭
지원 프레임워크	React, Vue, Astro, Next.js, SvelteKit, Remix 등
SSR/Edge	Cloudflare Workers 기반 Functions
빌드 환경	Node.js, Python, Ruby, Go 등

언제 사용하면 좋은가

정적 사이트: 블로그, 문서, 랜딩 페이지
JAMstack: Astro, Hugo, Jekyll, Eleventy
SSR 앱: Next.js App Router, SvelteKit, Remix
Edge API: Cloudflare Workers + D1(SQLite) + R2(S3 호환) 트래픽이 글로벌하거나, 대역폭 비용이 걱정되거나, Edge에서 서버 로직을 돌리고 싶다면 Cloudflare Pages가 강력한 선택지입니다.

2. GitHub 연동 배포

가장 간단한 방법은 Cloudflare 대시보드에서 GitHub 저장소를 연결하는 것입니다.

2-1. 기본 설정

Cloudflare 대시보드 → Pages → Create a project
Connect to Git → GitHub 계정 연동
저장소 선택 → 브랜치(main 또는 production)
빌드 설정:
- Framework preset: Astro, Next.js, React 등 자동 감지
- Build command: npm run build
- Build output directory: dist (Astro), out (Next.js), .next (Next.js SSR)
Save and Deploy

2-2. 자동 배포

main 브랜치에 푸시하면 자동으로 빌드·배포
PR마다 Preview 배포 생성 (URL: <branch>.<project>.pages.dev)
빌드 로그는 대시보드에서 실시간 확인 장점: 설정이 쉽고, PR 프리뷰가 자동.
단점: Cloudflare 빌드 환경(무료 500회/월)을 소모하고, 빌드 시간·캐시 제어가 제한적.

3. Wrangler CLI 배포

Wrangler는 Cloudflare의 공식 CLI로, 로컬 빌드 → 업로드만 하면 Cloudflare 빌드 횟수를 아낄 수 있습니다.

3-1. Wrangler 설치

npm install -g wrangler
# 또는 프로젝트 로컬
npm install --save-dev wrangler

3-2. 인증

wrangler login

브라우저에서 Cloudflare 계정 인증.

3-3. 배포

# 로컬에서 빌드
npm run build
# dist 폴더를 Cloudflare Pages에 업로드
wrangler pages deploy dist --project-name=my-project

첫 배포 시 프로젝트가 없으면 자동 생성됩니다.

3-4. GitHub Actions에서 Wrangler 사용

name: Deploy to Cloudflare Pages
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Build
        run: npm run build
        env:
          NODE_OPTIONS: '--max-old-space-size=4096'
      
      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy dist --project-name=my-project

필요한 시크릿:

CLOUDFLARE_API_TOKEN: 대시보드 → API Tokens → Edit Cloudflare Workers 권한
CLOUDFLARE_ACCOUNT_ID: 대시보드 URL에서 확인 (dash.cloudflare.com/<ACCOUNT_ID>/...) 장점: 빌드 환경 완전 제어, 캐시 전략 자유, Cloudflare 빌드 횟수 절약.

4. 환경 변수와 시크릿

4-1. Cloudflare 대시보드에서 설정

Pages 프로젝트 → Settings → Environment variables

Production: main 브랜치 배포 시 사용
Preview: PR·브랜치 배포 시 사용

DATABASE_URL=postgresql://...
API_KEY=abc123

빌드 시(npm run build)와 런타임(Functions) 모두 접근 가능합니다.

4-2. 코드에서 접근

빌드 타임 (Node.js):

// astro.config.mjs, next.config.js 등
const apiKey = process.env.API_KEY;

런타임 (Cloudflare Functions):

// functions/api/data.js
export async function onRequest(context) {
  const apiKey = context.env.API_KEY;
  return new Response(JSON.stringify({ key: apiKey }));
}

4-3. 로컬 개발

.dev.vars 파일 (.gitignore에 추가):

DATABASE_URL=postgresql://localhost/dev
API_KEY=dev-key-123

wrangler pages dev dist --local

5. 커스텀 도메인 설정

5-1. 도메인 추가

Pages 프로젝트 → Custom domains → Set up a custom domain

도메인 입력 (예: blog.example.com)
DNS 레코드 추가:
- CNAME: blog → <project>.pages.dev
- 또는 A/AAAA: Cloudflare가 제공하는 IP
SSL 자동 발급 (Let’s Encrypt, 무료)

5-2. Apex 도메인 (example.com)

Cloudflare에서 도메인을 관리 중이라면:

CNAME flattening 자동 적용
example.com → <project>.pages.dev CNAME 추가 다른 DNS 제공자라면 A 레코드로 Cloudflare IP를 추가해야 합니다.

6. Functions (Edge 서버 로직)

Cloudflare Pages Functions는 Cloudflare Workers 기반으로, Edge에서 서버 코드를 실행합니다.

6-1. 기본 구조

my-project/
├── functions/
│   ├── api/
│   │   ├── hello.js       # /api/hello
│   │   └── users/[id].js  # /api/users/:id
│   └── _middleware.js     # 모든 요청에 적용
├── public/
└── dist/

6-2. 예제: API 엔드포인트

// functions/api/hello.js
export async function onRequest(context) {
  const { request, env, params } = context;
  
  return new Response(
    JSON.stringify({ message: 'Hello from Edge!' }),
    { headers: { 'Content-Type': 'application/json' } }
  );
}

배포 후 https://my-project.pages.dev/api/hello로 접근.

6-3. 동적 라우트

// functions/api/users/[id].js
export async function onRequest(context) {
  const userId = context.params.id;
  
  // D1 (Cloudflare SQLite) 예시
  const db = context.env.DB;
  const user = await db.prepare('SELECT * FROM users WHERE id = ?')
    .bind(userId)
    .first();
  
  return new Response(JSON.stringify(user), {
    headers: { 'Content-Type': 'application/json' }
  });
}

6-4. Middleware

// functions/_middleware.js
export async function onRequest(context) {
  const start = Date.now();
  
  // 다음 핸들러 실행
  const response = await context.next();
  
  // 응답 헤더 추가
  response.headers.set('X-Response-Time', `${Date.now() - start}ms`);
  
  return response;
}

6-5. SSR 프레임워크

Astro SSR:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';
export default defineConfig({
  output: 'server', // 또는 'hybrid'
  adapter: cloudflare()
});

Next.js:

npm install @cloudflare/next-on-pages

// next.config.js
module.exports = {
  experimental: {
    runtime: 'experimental-edge'
  }
};

7. 빌드 최적화

7-1. GitHub Actions 빌드 캐시

- name: Cache dependencies
  uses: actions/cache@v4
  with:
    path: |
      node_modules
      .astro
      .next/cache
    key: ${{ runner.os }}-build-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-build-

7-2. 빌드 시간 단축

병렬 처리:

// scripts/build.mjs
import { execSync } from 'child_process';
const tasks = [
  'node scripts/generate-og-images.mjs',
  'node scripts/generate-sitemap.mjs',
  'node scripts/generate-rss.mjs'
];
await Promise.all(tasks.map(cmd => 
  execSync(cmd, { stdio: 'inherit' })
));
execSync('astro build', { stdio: 'inherit' });

증분 빌드:

Astro: .astro 폴더 캐시
Next.js: .next/cache 폴더 캐시

7-3. 대량 페이지 최적화

문제: 1,000개 이상 페이지 → 빌드 10분+ 해결:

OG 이미지 캐시: 변경된 글만 재생성
정적 페이지 우선: output: 'static' 또는 hybrid
병렬 렌더링: Astro 4.0+ 자동 병렬화

// astro.config.mjs
export default defineConfig({
  output: 'static',
  build: {
    concurrency: 8 // 병렬 렌더링
  }
});

8. Vercel·Netlify 비교

8-1. 기능 비교표

항목	Cloudflare Pages	Vercel	Netlify
무료 빌드	500회/월	6,000분/월	300분/월
무료 대역폭	무제한	100GB/월	100GB/월
CDN 위치	300+ 도시	100+ 도시	100+ 도시
Edge 함수	Workers (V8)	Edge Functions (V8)	Edge Functions (Deno)
DB 통합	D1 (SQLite), R2 (S3)	Vercel Postgres, Blob	Netlify Blobs
빌드 시간	중간	빠름 (Next.js 최적화)	중간
DX	보통	매우 좋음	좋음

8-2. 선택 기준

Cloudflare Pages를 선택하면 좋은 경우:

글로벌 트래픽이 많고 대역폭 비용이 걱정될 때
Workers·D1·R2 등 Cloudflare 생태계를 쓸 때
무료 플랜으로 무제한 대역폭이 필요할 때
Astro·Hugo 같은 정적 생성기로 블로그를 만들 때 (Astro 블로그 가이드 참고) Vercel을 선택하면 좋은 경우:
Next.js App Router를 쓰고, 개발자 경험을 최우선할 때
빌드 시간이 중요하고, 프리뷰 배포가 많을 때
Vercel Analytics·Speed Insights를 쓸 때 Netlify를 선택하면 좋은 경우:
Form 처리, Identity(인증), Split Testing이 필요할 때
Deno 기반 Edge Functions를 선호할 때

9. 실전 예제: Astro 블로그 배포

9-1. 프로젝트 구조

my-blog/
├── src/
│   ├── pages/
│   ├── content/
│   └── components/
├── public/
├── functions/
│   └── api/
│       └── views.js  # 조회수 API
├── astro.config.mjs
├── wrangler.toml
└── package.json

9-2. GitHub Actions 워크플로

name: Deploy to Cloudflare Pages
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Validate frontmatter
        run: npm run validate
      
      - name: Build
        run: npm run build
        env:
          NODE_OPTIONS: '--max-old-space-size=4096'
      
      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy dist --project-name=my-blog --commit-message="Deploy from GitHub Actions"

9-3. 조회수 API (Functions)

// functions/api/views.js
export async function onRequest(context) {
  const { request, env } = context;
  const url = new URL(request.url);
  const slug = url.searchParams.get('slug');
  
  if (!slug) {
    return new Response('Missing slug', { status: 400 });
  }
  
  // D1 (Cloudflare SQLite)
  const db = env.DB;
  
  if (request.method === 'POST') {
    // 조회수 증가
    await db.prepare('INSERT INTO views (slug, count) VALUES (?, 1) ON CONFLICT(slug) DO UPDATE SET count = count + 1')
      .bind(slug)
      .run();
  }
  
  // 조회수 조회
  const result = await db.prepare('SELECT count FROM views WHERE slug = ?')
    .bind(slug)
    .first();
  
  return new Response(
    JSON.stringify({ slug, views: result?.count || 0 }),
    { headers: { 'Content-Type': 'application/json' } }
  );
}

D1 바인딩 (wrangler.toml):

name = "my-blog"
pages_build_output_dir = "dist"
[[d1_databases]]
binding = "DB"
database_name = "my-blog-db"
database_id = "abc123..."

10. 고급 팁

10-1. 리다이렉트

_redirects 파일 (빌드 출력 폴더에 포함):

/old-url  /new-url  301
/blog/*   /posts/:splat  302

또는 _headers:

/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff

10-2. 프리뷰 브랜치 제한

# .github/workflows/deploy-cloudflare.yml
on:
  push:
    branches: [main]
  # PR 프리뷰는 Cloudflare 자동 배포에 맡기기

10-3. 빌드 실패 알림

- name: Notify on failure
  if: failure()
  run: |
    curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
      -H 'Content-Type: application/json' \
      -d '{"text":"Cloudflare Pages 배포 실패!"}'

10-4. 롤백

대시보드:

Deployments → 이전 배포 선택 → Rollback to this deployment CLI:

wrangler pages deployment list --project-name=my-blog
wrangler pages deployment rollback <deployment-id>

11. 정리

핵심 요약

Cloudflare Pages 장점:

무료 대역폭 무제한
300+ 도시 글로벌 CDN
Workers·D1·R2 통합
SSR/Edge Functions 지원 배포 방법:

GitHub 연동: 가장 쉬움, 자동 프리뷰
Wrangler CLI: 빌드 제어, 횟수 절약 추천 구성:

로컬/CI: GitHub Actions에서 빌드 + Wrangler 업로드
프리뷰: Cloudflare 자동 배포
환경 변수: 대시보드에서 Production/Preview 분리
모니터링: Cloudflare Analytics + Sentry

체크리스트

배포 전:

빌드 명령어 확인 (npm run build)
출력 디렉터리 확인 (dist, out, .next)
환경 변수 설정 (API 키, DB URL)
.gitignore에 .env, .dev.vars 추가 배포 후:
커스텀 도메인 DNS 전파 확인 (최대 24시간)
SSL 인증서 발급 확인
Functions 동작 테스트
404 페이지 확인

다음 단계

Cloudflare Pages와 함께 쓰면 좋은 글:

Astro + Cloudflare Pages 스택 분석 — Vercel·Netlify·WordPress와 비교
Astro로 기술 블로그 만들기
Node.js 배포 가이드 (PM2, Docker, AWS)
Node.js + GitHub Actions CI/CD
기술 블로그 방문자 늘리기 — 배포 후 검색 유입 구조 잡기 참고 자료:
Cloudflare Pages 공식 문서
Wrangler CLI 문서
Cloudflare Workers 문서

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「Cloudflare Pages 완벽 가이드 | 무료 배포·Edge 렌더링·Wrangler CLI」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)

불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역	운영 관점 질문
관측성	요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성	입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능	캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량	피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「Cloudflare Pages 완벽 가이드 | 무료 배포·Edge 렌더링·Wrangler CLI」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.

handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스, 타임아웃, 외부 의존성, DNS	최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하	N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납	상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패	환경 변수, 권한, 플랫폼 차이, lockfile	CI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치	프로필·시크릿·기본값, 리전	스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치	비멱등 재시도, 부분 쓰기, 캐시 무효화 누락	멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.

자주 묻는 질문 (FAQ)

Q. 이 내용을 실무에서 언제 쓰나요?

A. Cloudflare Pages로 정적 사이트와 SSR 앱을 배포하는 방법을 정리합니다. GitHub 연동, Wrangler CLI, 환경 변수, 커스텀 도메인, Functions(Edge), 빌드 최적화, Verce… 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.

Q. 선행으로 읽으면 좋은 글은?

A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.

Q. 더 깊이 공부하려면?

A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

Vercel 완벽 가이드 | 배포·Edge Functions·Analytics·환경 변수·실전 활용
Astro + Cloudflare Pages 블로그 스택 분석 | Vercel·Netlify
[Complete Cloudflare Pages Complete Guide | Free Deployment](/en/blog/cloudflare-pages-deployment-guide/

이 글에서 다루는 키워드 (관련 검색어)

Cloudflare Pages, Cloudflare, 배포, Edge Computing, Wrangler, GitHub Actions, CI/CD, DevOps, JAMstack 등으로 검색하시면 이 글이 도움이 됩니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.