[Vercel vs Netlify vs Cloudflare Pages 비교] 심층 분석 — 아키텍처와 실전 활용

 

안녕하세요!

재아군의 관찰인생입니다.

 

오늘은 바이브코딩중이라면 한 번쯤 들어봤을 Vercel vs Netlify vs Cloudflare Pages 비교를 심층적으로 다뤄보겠습니다.

정적 사이트 호스팅을 넘어 풀스택 배포 플랫폼으로 진화한 이 세 서비스의 아키텍처, 성능, 가격 정책까지 실전 관점에서 분석합니다.

 

 

---

 

1. Vercel vs Netlify vs Cloudflare Pages 비교란 무엇인가?

 

핵심 정의

 

Vercel, Netlify, Cloudflare Pages는 모두 JAMstack 및 모던 웹 애플리케이션을 위한 엣지 배포 플랫폼입니다.

Git 저장소와 연동하여 코드를 푸시하면 자동으로 빌드하고 글로벌 CDN에 배포하는 워크플로를 제공합니다.

 

• Vercel: Next.js 창시 기업이 만든 플랫폼으로, React 기반 프레임워크에 최적화된 서버리스 배포 환경을 제공합니다.
• Netlify: JAMstack이라는 용어를 대중화시킨 선구자로, 정적 사이트 생성기(SSG)와 서버리스 함수를 결합한 통합 플랫폼입니다.
• Cloudflare Pages: 전 세계 330개 이상의 데이터센터를 보유한 Cloudflare의 인프라 위에 구축된 후발주자로, Workers 런타임과의 통합이 강점입니다.

 

등장 배경

 

전통적인 웹 호스팅은 단일 서버에 애플리케이션을 배포하는 방식이었습니다.

AWS EC2나 DigitalOcean에 Nginx를 설정하고, SSL 인증서를 발급받고, CI/CD 파이프라인을 직접 구축해야 했습니다.

이 과정에서 다음과 같은 문제가 반복적으로 발생했습니다.

 

기존 방식의 4가지 문제점:

 

1. 인프라 관리 부담: 서버 프로비저닝, OS 패치, 보안 업데이트 등 애플리케이션 코드와 무관한 운영 작업에 개발 시간의 30~40%가 소모되었습니다.
2. 글로벌 배포의 복잡성: 아시아, 유럽, 북미 사용자 모두에게 빠른 응답 속도를 제공하려면 다중 리전 배포와 로드밸런서 설정이 필요했고, 이는 소규모 팀에게 현실적으로 불가능한 수준의 비용과 복잡도를 요구했습니다.
3. 프리뷰 환경 부재: PR 단위로 미리보기 배포를 만들려면 별도의 스크립트와 인프라가 필요했으며, 코드 리뷰 시 "로컬에서 확인해봐" 라는 비효율적인 워크플로가 반복되었습니다.
4. 빌드-배포 파이프라인 단절: Jenkins나 GitHub Actions로 빌드한 결과물을 S3에 업로드하고, CloudFront 캐시를 무효화하는 등 여러 서비스를 조합해야 했으며, 장애 발생 시 원인 추적이 어려웠습니다.

 

이러한 문제를 해결하기 위해 등장한 것이 바로 통합 배포 플랫폼이며, Vercel, Netlify, Cloudflare Pages가 각자의 철학으로 이 시장을 이끌고 있습니다.

 

 

---

 

2. 핵심 특징 & 기능 분석

 

2-1. 빌드 시스템과 프레임워크 지원

 

Vercel은 Next.js의 모든 렌더링 모드(SSR, SSG, ISR, App Router의 Server Components)를 네이티브로 지원합니다. next build 결과물을 자체 인프라에 최적화하여 배포하므로 별도의 설정 없이도 최상의 성능을 얻을 수 있습니다.

Netlify는 2024년부터 Next.js Runtime v5를 도입하여 Next.js 지원을 대폭 강화했지만, ISR(Incremental Static Regeneration)의 동작 방식에서 Vercel과 미묘한 차이가 존재합니다.

Cloudflare Pages는 프레임워크에 구애받지 않는 접근을 취하며, Astro, SvelteKit, Nuxt, Remix 등을 동등하게 지원합니다.

 

2-2. 서버리스 함수와 엣지 컴퓨팅

 

Vercel의 Serverless Functions는 AWS Lambda 기반으로 동작하며, 최대 실행 시간은 Pro 플랜 기준 300초입니다.

Edge Functions는 V8 Isolates 위에서 실행되어 콜드 스타트가 거의 없습니다.

Netlify Functions는 AWS Lambda를 래핑한 형태이며, Edge Functions는 Deno Deploy 기반입니다.

Cloudflare Workers는 V8 Isolates를 사용하는 자체 런타임으로 콜드 스타트가 0ms에 가깝고, 무료 플랜에서도 하루 10만 요청을 허용합니다.

특히 Workers는 Node.js API 호환성을 지속적으로 확대하고 있어, 2025년 기준 대부분의 npm 패키지가 정상 동작합니다.

 

2-3. 프리뷰 배포와 협업 기능

 

세 플랫폼 모두 PR 단위의 프리뷰 배포를 지원하지만 세부 구현이 다릅니다.

Vercel은 각 커밋마다 고유한 URL을 생성하고, 댓글 시스템을 통해 디자이너와 기획자가 직접 피드백을 남길 수 있습니다.

Netlify Deploy Preview는 Split Testing(A/B 테스트) 기능과 결합하여 프리뷰 환경에서 트래픽 분배를 테스트할 수 있습니다.

Cloudflare Pages는 브랜치별 자동 배포를 지원하며, ..pages.dev 형태의 예측 가능한 URL 패턴을 제공합니다.

 

2-4. 데이터 저장소와 풀스택 기능

 

Vercel은 KV(Redis 호환), Postgres(Neon 기반), Blob Storage를 자체 서비스로 제공하여 별도의 데이터베이스 설정 없이 풀스택 애플리케이션을 구축할 수 있습니다.

Netlify는 Blobs(객체 스토리지)를 제공하며, Supabase와의 공식 통합을 강화하고 있습니다.

Cloudflare는 KV, D1(SQLite 호환 DB), R2(S3 호환 스토리지), Durable Objects 등 가장 다양한 저장소 옵션을 보유하고 있으며, 대부분 넉넉한 무료 티어를 제공합니다.

 

2-5. 성능과 글로벌 네트워크

 

Cloudflare Pages가 네트워크 규모에서 압도적입니다.

전 세계 330개 이상의 PoP(Point of Presence)를 보유하고 있어, 최종 사용자와 가장 가까운 위치에서 콘텐츠를 제공합니다.

Vercel은 자체 Edge Network를 운영하며, 주요 리전에서 안정적인 성능을 보여줍니다.

Netlify는 AWS CloudFront를 기반으로 한 CDN을 사용하며, Enterprise 플랜에서 고성능 엣지 노드를 추가로 제공합니다.

TTFB(Time to First Byte) 기준으로 Cloudflare Pages가 평균 50~80ms, Vercel이 80~120ms, Netlify가 100~150ms 수준을 기록합니다.

 

 

---

 

3. 기술 아키텍처 & 동작 원리

 

핵심 구성 요소 비교

 

구성 요소	Vercel	Netlify	Cloudflare Pages
CDN 기반	자체 Edge Network	AWS CloudFront	Cloudflare 글로벌 네트워크
서버리스 런타임	AWS Lambda + V8 Isolates	AWS Lambda + Deno Deploy	V8 Isolates (Workers)
빌드 환경	Amazon Linux 2	Ubuntu 20.04/22.04	Ubuntu (격리 컨테이너)
캐시 전략	SWR (Stale-While-Revalidate)	Instant Cache Invalidation	Tiered Caching
DNS	자체 DNS	Netlify DNS	Cloudflare DNS (1.1.1.1)
SSL/TLS	Let's Encrypt 자동	Let's Encrypt 자동	Cloudflare Universal SSL

 

배포 흐름 아키텍처

 

세 플랫폼의 배포 파이프라인은 유사한 패턴을 따르지만, 내부 동작에서 차이가 있습니다.

 

# Vercel 배포 흐름 (vercel.json)
{
  "buildCommand": "next build",
  "outputDirectory": ".next",
  "framework": "nextjs",
  "regions": ["icn1", "hnd1"],  # 서울, 도쿄 리전 지정
  "functions": {
    "api/**/*.ts": {
      "memory": 1024,
      "maxDuration": 30
    }
  },
  "rewrites": [
    { "source": "/api/:path*", "destination": "/api/:path*" },
    { "source": "/(.*)", "destination": "/" }
  ],
  "headers": [
    {
      "source": "/assets/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
      ]
    }
  ]
}

 

# Netlify 배포 설정 (netlify.toml)
[build]
  command = "npm run build"
  publish = "dist"
  functions = "netlify/functions"

[build.environment]
  NODE_VERSION = "20"
  NPM_FLAGS = "--prefix=/dev/null"

[[redirects]]
  from = "/api/*"
  to = "/.netlify/functions/:splat"
  status = 200

[[headers]]
  for = "/assets/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"
    X-Content-Type-Options = "nosniff"

[context.deploy-preview]
  command = "npm run build:preview"

[context.branch-deploy]
  command = "npm run build:staging"

 

# Cloudflare Pages 설정 (wrangler.toml)
name = "my-project"
compatibility_date = "2025-01-01"
pages_build_output_dir = "dist"

[[d1_databases]]
binding = "DB"
database_name = "my-app-db"
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

[[kv_namespaces]]
binding = "CACHE"
id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

[[r2_buckets]]
binding = "STORAGE"
bucket_name = "my-app-storage"

 

설계 원칙 4가지

 

1. Git-기반 워크플로: 세 플랫폼 모두 git push를 트리거로 빌드-배포 파이프라인이 자동 실행됩니다. GitHub, GitLab, Bitbucket과의 통합이 기본 제공되며, 브랜치 전략에 따른 환경 분리를 지원합니다.
2. 엣지 우선 아키텍처: 정적 자산뿐 아니라 서버 사이드 로직까지 사용자에게 가장 가까운 엣지 노드에서 실행하여 지연 시간을 최소화합니다.
3. 제로 구성 원칙: 프레임워크를 자동으로 감지하고 최적의 빌드 명령어와 출력 디렉토리를 추론합니다. 대부분의 프로젝트에서 별도 설정 파일 없이 배포가 가능합니다.
4. 점진적 복잡성: 정적 사이트에서 시작하여 서버리스 함수, 데이터베이스, 인증까지 필요에 따라 기능을 추가할 수 있는 구조입니다.

 

---

 

4. 실무 활용 가이드

 

프로젝트 시작하기

 

각 플랫폼에서 프로젝트를 시작하는 CLI 명령어를 비교해보겠습니다.

 

# Vercel - 프로젝트 초기화 및 배포
npx create-next-app@latest my-app --typescript --tailwind --app
cd my-app
npm i -g vercel
vercel login
vercel              # 대화형 설정 후 즉시 배포
vercel --prod       # 프로덕션 배포
vercel env pull .env.local  # 환경변수 동기화

# Netlify - 프로젝트 초기화 및 배포
npx create-next-app@latest my-app --typescript --tailwind --app
cd my-app
npm i -g netlify-cli
ntl login
ntl init            # 사이트 생성 + Git 연동
ntl dev             # 로컬 개발 서버 (Functions 포함)
ntl deploy --prod   # 프로덕션 배포

# Cloudflare Pages - 프로젝트 초기화 및 배포
npm create cloudflare@latest my-app -- --framework=next
cd my-app
npx wrangler login
npx wrangler pages deploy dist  # 직접 배포
# 또는 Cloudflare 대시보드에서 GitHub 연동 설정

 

기존 환경에서 마이그레이션 4단계

 

단계	작업 내용	예상 소요 시간	주의사항
1단계: 환경 분석	현재 빌드 설정, 환경변수, 리다이렉트 규칙 목록화	1~2시간	.env 파일과 CI/CD 환경변수를 모두 확인할 것
2단계: 설정 파일 작성	vercel.json / netlify.toml / wrangler.toml 작성	2~4시간	리다이렉트 규칙의 우선순위와 정규식 문법 차이에 주의
3단계: 스테이징 배포	프리뷰 환경에서 전체 기능 검증	4~8시간	서버리스 함수의 콜드 스타트와 타임아웃 설정 확인
4단계: DNS 전환	도메인 DNS 레코드 변경 및 SSL 인증서 발급	1~2시간	TTL을 미리 낮추고, 롤백 계획 수립 후 진행

 

팀 활용 팁

 

• 모노레포 환경: Vercel은 Turborepo와의 네이티브 통합으로 모노레포에서 변경된 패키지만 빌드합니다. Netlify는 ignore 명령어로 빌드 스킵 조건을 설정할 수 있습니다. Cloudflare Pages는 빌드 설정에서 루트 디렉토리를 지정하는 방식으로 모노레포를 지원합니다.
• 환경변수 관리: 세 플랫폼 모두 Production, Preview, Development 환경별로 다른 환경변수를 설정할 수 있습니다. Vercel은 vercel env pull 명령어로 로컬에 환경변수를 동기화하는 기능이 편리합니다.
• 팀 권한 관리: Vercel은 Viewer, Developer, Admin 역할을 구분하며, Netlify는 세분화된 역할 기반 접근 제어(RBAC)를 Enterprise 플랜에서 제공합니다. Cloudflare는 조직 수준의 접근 제어를 통해 팀원별 권한을 관리합니다.

 

---

 

5. 경쟁 기술 비교 분석

 

주요 배포 플랫폼 비교표

 

항목	Vercel	Netlify	Cloudflare Pages	AWS Amplify	GitHub Pages
최적 프레임워크	Next.js	Gatsby, Hugo, 11ty	Astro, SvelteKit, Remix	Next.js, Nuxt	Jekyll, Hugo
서버리스 함수	✅ (Lambda + Edge)	✅ (Lambda + Deno)	✅ (Workers)	✅ (Lambda)	❌
무료 빌드 시간	6,000분/월	300분/월	500회/월	1,000분/월	10회/시간
무료 대역폭	100GB/월	100GB/월	무제한	15GB/월	100GB/월
프리뷰 배포	✅ 커밋 단위	✅ PR 단위	✅ 브랜치 단위	✅ PR 단위	❌
엣지 PoP 수	~100개	~40개 (CloudFront)	330개 이상	~40개 (CloudFront)	~100개 (Fastly)
Pro 가격	$20/유저/월	$19/유저/월	$5/월 (Workers Paid)	$12/월~	무료
자체 DB	KV, Postgres, Blob	Blobs	KV, D1, R2, DO	DynamoDB 연동	❌
분석/모니터링	Web Analytics, Speed Insights	Analytics (유료)	Web Analytics (무료)	CloudWatch	❌

 

선택 가이드

 

• Next.js 중심 프로젝트: Vercel이 압도적입니다. App Router, Server Actions, PPR(Partial Prerendering) 등 Next.js의 최신 기능을 가장 먼저, 가장 안정적으로 지원합니다.
• 정적 사이트 + 폼/인증: Netlify가 강합니다. Forms, Identity 등 내장 기능으로 백엔드 없이 빠르게 구축할 수 있습니다.
• 글로벌 성능 + 비용 효율: Cloudflare Pages가 최적입니다. 무제한 대역폭과 330개 이상의 PoP는 트래픽이 많은 서비스에서 큰 비용 절감 효과를 가져옵니다.
• AWS 생태계 통합: AWS Amplify가 적합합니다. Cognito, AppSync, DynamoDB 등 AWS 서비스와의 긴밀한 통합이 필요할 때 선택합니다.
• 오픈소스 문서 사이트: GitHub Pages로 충분합니다. 서버리스 함수가 필요 없는 정적 사이트라면 가장 간단한 선택입니다.

 

---

 

6. 도입 시 베스트 프랙티스

 

5가지 핵심 원칙

 

1. 락인(Lock-in) 최소화: 플랫폼 고유 기능(Vercel의 @vercel/og, Netlify의 netlify-identity)에 과도하게 의존하지 마세요. 핵심 비즈니스 로직은 플랫폼 독립적으로 작성하고, 플랫폼 종속 코드는 어댑터 패턴으로 분리하는 것이 좋습니다.
2. 캐시 전략 명시: 기본 캐시 설정에 의존하지 말고, Cache-Control 헤더를 명시적으로 설정하세요. 정적 자산은 immutable 캐시를, API 응답은 stale-while-revalidate 패턴을 적용합니다.
3. 빌드 시간 최적화: 의존성 캐시를 활용하고, 불필요한 빌드를 스킵하는 조건을 설정하세요. 모노레포 환경에서는 변경된 패키지만 빌드하도록 구성합니다.
4. 환경 분리 철저: Production, Staging, Preview 환경의 환경변수와 기능 플래그를 명확히 분리하세요. 프리뷰 배포에서 실수로 프로덕션 API를 호출하는 사고를 방지합니다.
5. 모니터링 연동: 배포 후 Core Web Vitals(LCP, FID, CLS)를 지속적으로 추적하세요. Vercel Speed Insights, Cloudflare Web Analytics 등 내장 도구를 활용하거나 Datadog, Sentry를 연동합니다.

 

흔한 실수와 해결 방법

 

실수	증상	해결 방법
환경변수 미설정	빌드 성공, 런타임 에러 발생	대시보드에서 Production/Preview 환경변수 모두 설정, NEXT_PUBLIC_ 접두사 확인
리다이렉트 무한 루프	페이지 로딩 실패, ERR_TOO_MANY_REDIRECTS	리다이렉트 규칙의 우선순위 확인, force 옵션 제거 후 조건부 리다이렉트로 변경
서버리스 함수 타임아웃	504 Gateway Timeout	함수 실행 시간 최적화, DB 커넥션 풀링 적용, 비동기 작업은 큐로 분리
빌드 캐시 오염	이전 빌드의 잘못된 설정이 계속 적용됨	대시보드에서 빌드 캐시 수동 삭제 후 재배포
이미지 최적화 미적용	이미지 로딩 느림, LCP 점수 하락	next/image 또는 Cloudflare Image Resizing 활용, WebP/AVIF 자동 변환 설정

 

---

 

7. 향후 전망 & 발전 방향

 

발전 방향 4가지

 

1. AI 네이티브 배포 경험: Vercel은 v0(AI UI 생성기)와 AI SDK를 통해 AI 기반 개발-배포 워크플로를 구축하고 있습니다. Cloudflare는 Workers AI로 엣지에서 LLM 추론을 실행할 수 있는 인프라를 제공하며, AI Gateway로 API 호출을 관리합니다. 2025년 하반기에는 세 플랫폼 모두 AI 에이전트 호스팅을 핵심 기능으로 내세울 것으로 예상됩니다.
2. 엣지 컴퓨팅의 확대: 단순 CDN 캐시를 넘어, 데이터베이스 쿼리와 인증 로직까지 엣지에서 처리하는 방향으로 진화하고 있습니다. Cloudflare D1의 글로벌 읽기 복제, Vercel의 Edge Config 등이 이 흐름을 보여줍니다. 향후 엣지에서 완전한 풀스택 애플리케이션을 실행하는 것이 표준이 될 것입니다.
3. 통합 개발자 플랫폼화: 배포 플랫폼에서 시작하여 데이터베이스, 스토리지, 인증, 분석, 모니터링까지 원스톱으로 제공하는 "슈퍼 플랫폼"으로 진화하고 있습니다. Vercel의 Storage 제품군, Cloudflare의 Developer Platform이 이를 잘 보여줍니다. 별도의 백엔드 인프라 없이 프론트엔드 개발자가 풀스택 서비스를 구축하는 시대가 가속화될 것입니다.
4. 오픈소스와의 균형: Vercel이 Next.js를 오픈소스로 유지하면서도 플랫폼 종속적 기능을 늘리는 것에 대한 커뮤니티의 우려가 존재합니다. OpenNext 프로젝트처럼 Next.js를 다른 플랫폼에서도 완전히 지원하려는 움직임이 활발해지고 있으며, 이는 건강한 경쟁 생태계를 만드는 데 기여할 것입니다.

 

개발자에게 주는 시사점

 

• 프레임워크 종속성을 인식하세요: 특정 플랫폼에 최적화된 프레임워크를 선택하면 성능은 극대화되지만, 마이그레이션 비용도 함께 증가합니다.
• 무료 티어를 전략적으로 활용하세요: 개인 프로젝트나 사이드 프로젝트는 Cloudflare Pages의 넉넉한 무료 티어로 시작하고, 트래픽이 증가하면 요구사항에 맞는 유료 플랜으로 전환하는 것이 합리적입니다.
• 멀티 플랫폼 전략을 고려하세요: 정적 자산은 Cloudflare Pages, API는 Vercel Functions, 인증은 별도 서비스로 분리하는 하이브리드 아키텍처도 가능합니다.

 

---

 

마무리

 

지금까지 Vercel vs Netlify vs Cloudflare Pages 비교를 아키텍처, 성능, 가격, 실전 활용 관점에서 심층 분석해보았습니다.

핵심을 정리하면 다음과 같습니다.

 

• Vercel은 Next.js 생태계와의 완벽한 통합, DX(개발자 경험) 중심 설계로 React 기반 프로젝트의 최적 선택입니다.
• Netlify는 JAMstack의 원조답게 정적 사이트와 폼, 인증 등 내장 기능의 조합이 강력하며, 마케팅 사이트나 콘텐츠 중심 프로젝트에 적합합니다.
• Cloudflare Pages는 330개 이상의 글로벌 PoP, 무제한 대역폭, 파격적인 가격 정책으로 비용 효율과 성능을 모두 잡을 수 있는 플랫폼입니다.
• 세 플랫폼 모두 빠르게 진화하고 있으므로, 프로젝트의 기술 스택과 팀 규모, 예산에 맞는 선택이 가장 중요합니다.

 

Vercel vs Netlify vs Cloudflare Pages 비교를 통해 여러분의 다음 프로젝트에 가장 적합한 플랫폼을 선택하는 데 도움이 되었길 바랍니다.

 

혹시 이 중 실제로 사용해본 경험이 있으신가요?

각 플랫폼의 장단점이나 마이그레이션 경험을 댓글로 공유해주시면 큰 도움이 됩니다.

이 글이 유용했다면 공유도 부탁드립니다!

 

다음 글에서는 실제 프로젝트를 각 플랫폼에 배포하고 성능을 측정하는 벤치마크 테스트를 진행해보겠습니다.

감사합니다!