RSS

Vercel vs Cloudflare Pages vs Netlify vs 자체 서버: 배포 플랫폼 선택 가이드

웹 인프라글: , Duolabs13분 읽기blogdeploymentmodel-openai-gpt-5.5nextjstechnical-noteweb-infrastructure

웹사이트 구축 플랫폼 선택 가이드 1/3
정보 확인 기준: 2026년 7월 29일

웹사이트를 만들 때 자주 듣는 이름으로 Vercel, Cloudflare Pages, Netlify가 있습니다. 여기에 AWS나 직접 관리하는 서버까지 더하면 선택지가 너무 많아 보입니다. 하지만 먼저 구분할 것이 있습니다. 이들은 완성된 홈페이지를 만들어 주는 서비스가 아니라, 개발자가 작성한 코드를 빌드하고 실행하는 개발·배포 플랫폼입니다.

따라서 “어디가 가장 좋은가?”보다 다음 질문이 먼저입니다.

  • 정적 페이지가 중심인가, 로그인과 API가 필요한가?
  • Next.js의 서버 렌더링과 캐시 기능을 얼마나 사용하는가?
  • 데이터베이스는 어느 지역과 환경에 있는가?
  • 배포 편의성과 인프라 통제권 중 무엇이 더 중요한가?
  • 장애 대응, 백업과 보안 업데이트를 누가 맡는가?

1분 요약

선택지 가장 잘 맞는 경우 Next.js 적합성 운영 부담 주의할 점
Vercel Next.js 기반 SaaS, MVP, 관리자·고객 포털 매우 높음 낮음 Functions, 전송량, 이미지와 저장소 사용량을 함께 봐야 함
Cloudflare Pages·Workers 정적 사이트, 엣지 API, 전 세계 응답 속도가 중요한 서비스 조건부로 높음 낮음 Workers 런타임과 Node.js 호환 범위를 확인해야 함
Netlify 프레임워크 기반 사이트, 미리보기와 콘텐츠 배포 흐름 높음 낮음 어댑터 동작과 플랫폼별 Functions 구성을 확인해야 함
Docker 자체 서버 장시간 작업, 세밀한 네트워크·DB 통제, 여러 서비스를 함께 운영 매우 높음 높음 관제, 패치, 백업, 복구와 확장을 직접 책임져야 함

표만 보면 Vercel이 가장 편하고 자체 서버가 가장 어려워 보일 수 있습니다. 실제로는 애플리케이션의 성격에 따라 운영 부담의 의미가 달라집니다. 단순 홈페이지에 서버를 직접 운영하는 것은 과할 수 있지만, 여러 내부 시스템과 데이터베이스가 한 환경에 모여 있다면 자체 서버가 오히려 예측하기 쉬울 수 있습니다.

Vercel: Next.js를 가장 자연스럽게 배포하는 선택

Vercel은 Next.js를 만든 회사가 운영하는 배포 플랫폼입니다. Git 저장소를 연결하면 브랜치별 미리보기, 프로덕션 배포, 정적 생성, 서버 렌더링과 Functions 구성이 자동화됩니다. Next.js의 App Router, Server Components, Route Handler와 캐시 기능을 적극적으로 사용한다면 가장 먼저 검토할 만합니다.

장점

  • Next.js 기능을 별도 어댑터 설정 없이 적용하기 쉽습니다.
  • 커밋과 Pull Request 단위로 미리보기 주소를 만들기 좋습니다.
  • CDN, HTTPS, 배포 이력과 롤백을 한곳에서 관리할 수 있습니다.
  • API와 데이터베이스 연결이 필요한 웹 애플리케이션에도 사용할 수 있습니다.

확인할 점

  • 애플리케이션 비용은 월 요금 하나가 아니라 Functions 실행, 데이터 전송, 이미지 최적화, 로그와 저장소 사용량의 영향을 받습니다.
  • PostgreSQL 같은 외부 데이터베이스를 사용하면 Functions와 DB의 지역을 맞춰 왕복 지연을 줄여야 합니다.
  • 장시간 실행 작업, 지속 연결이나 로컬 디스크에 의존하는 처리는 별도 작업 시스템이 더 적합할 수 있습니다.
  • Vercel 전용 기능을 많이 사용할수록 다른 환경으로 옮길 때 대체 구성을 찾아야 합니다.

Cloudflare Pages·Workers: 정적 자산과 엣지 실행에 강한 선택

Cloudflare Pages는 Git 또는 직접 업로드로 정적 자산을 배포하고, Pages Functions를 통해 서버 기능을 추가할 수 있습니다. Pages Functions는 Cloudflare Workers 런타임에서 실행됩니다. 로그인 확인, 폼 처리, 간단한 API나 미들웨어처럼 요청 가까이에서 처리할 작업과 잘 맞습니다.

장점

  • 정적 자산을 전 세계 Cloudflare 네트워크에서 제공할 수 있습니다.
  • Pages Functions로 별도 서버 없이 동적 기능을 추가할 수 있습니다.
  • D1, R2, KV 같은 Cloudflare 서비스와 바인딩해 구성할 수 있습니다.
  • 정적 요청과 Functions 호출을 분리하면 비용 구조를 이해하기 쉽습니다.

확인할 점

  • Workers는 일반적인 상시 Node.js 서버와 실행 환경이 다릅니다.
  • 공식 문서상 Node.js API는 호환 플래그를 포함한 지원 범위 안에서 사용하므로, 네이티브 모듈과 파일 시스템 의존성을 확인해야 합니다.
  • Next.js 전체 기능을 쓸 때는 현재 지원 방식과 어댑터, 빌드 결과를 실제 프로젝트로 검증해야 합니다.
  • Functions 경로 설정이 넓으면 정적 요청까지 함수 호출로 처리될 수 있으므로 라우팅 범위를 점검해야 합니다.

Cloudflare는 “Vercel보다 무조건 저렴한 Next.js 호스팅”으로 단순화하기보다, 정적·엣지 중심 구조에 맞는지를 먼저 판단하는 편이 안전합니다.

Netlify: 프레임워크 배포와 콘텐츠 작업 흐름의 균형

Netlify 역시 Git 기반 배포, 미리보기, Functions와 Edge Functions를 제공하는 웹 플랫폼입니다. 현재 공식 문서는 OpenNext 어댑터를 통해 Next.js App Router, SSR, ISR, Server Actions와 이미지 최적화 등을 지원한다고 안내합니다.

장점

  • Next.js뿐 아니라 Astro, Nuxt, SvelteKit 등 여러 프레임워크를 한 방식으로 관리하기 좋습니다.
  • 브랜치·배포 미리보기와 콘텐츠 검수 흐름을 구성하기 쉽습니다.
  • Functions, Edge Functions, 리디렉션과 환경변수를 플랫폼 안에서 연결할 수 있습니다.
  • 정적 사이트에서 동적 기능을 단계적으로 추가하기 좋습니다.

확인할 점

  • Next.js 기능은 Netlify의 OpenNext 어댑터가 적절한 Functions와 캐시 구성으로 변환합니다.
  • 실험 단계의 Next.js 기능이나 플랫폼 고유 기능은 배포 전 호환성을 확인해야 합니다.
  • 함수 지역과 외부 DB 지역이 멀면 API 응답 시간이 늘어날 수 있습니다.
  • 비용 비교에서는 빌드, 함수, 엣지 실행, 전송량과 부가 기능을 같은 사용량 조건으로 맞춰야 합니다.

Docker 자체 서버: 통제권을 얻는 대신 운영 책임을 맡는 선택

Docker와 Docker Compose로 Next.js, PostgreSQL, 프록시와 작업 프로세스를 직접 운영하면 실행 환경과 네트워크를 세밀하게 통제할 수 있습니다. 특정 클라우드 사업자의 가상 서버, 기업 온프레미스 환경 또는 관리형 컨테이너 환경을 사용할 수 있습니다.

장점

  • 일반 Node.js 런타임, 시스템 패키지와 장시간 프로세스를 자유롭게 구성할 수 있습니다.
  • 애플리케이션과 DB의 네트워크 위치를 직접 설계할 수 있습니다.
  • 여러 서비스와 공통 프록시·스토리지·모니터링을 묶어 운영할 수 있습니다.
  • 특정 서버리스 플랫폼의 실행 시간과 런타임 제약을 덜 받습니다.

확인할 점

  • 운영체제와 컨테이너 이미지의 보안 업데이트를 직접 관리해야 합니다.
  • 인증서, 방화벽, 비밀값, 로그, 용량과 장애 알림 구성이 필요합니다.
  • 데이터는 컨테이너 내부가 아니라 볼륨 또는 외부 DB에 두고 백업·복구 시험을 해야 합니다.
  • 서버 한 대의 월 비용만 계산하면 안 됩니다. 운영 시간, 장애 대응과 복구 가능성도 비용입니다.

Docker 공식 문서도 볼륨을 컨테이너와 수명이 분리된 영속 저장 방식으로 설명하며 백업·복원 절차를 별도로 다룹니다. 컨테이너가 다시 만들어진다고 해서 데이터 백업까지 자동으로 해결되는 것은 아닙니다.

비용은 같은 단위로 비교해야 한다

플랫폼의 무료 플랜과 서버 한 대의 월 요금만 비교하면 실제 비용을 놓치기 쉽습니다.

비용 항목 확인 내용
빌드 월 빌드 횟수, 빌드 시간, 동시 빌드와 캐시
정적 전송 CDN 요청과 데이터 전송량
서버 실행 호출 수, 실행 시간, CPU와 메모리
이미지 원본 저장, 변환 횟수와 전송량
데이터 DB, 파일, 캐시와 백업 보관
관측 로그 보존, 오류 추적, 성능 지표와 알림
운영 보안 패치, 장애 대응, 복구 시험과 담당자 시간
이전 플랫폼 전용 기능을 다른 환경으로 바꾸는 비용

Cloudflare Pages는 정적 자산 요청과 Functions 호출의 과금 기준이 다르고, Pages Functions는 Workers 사용량으로 계산됩니다. Vercel 역시 Functions, 이미지, 데이터 전송과 저장소 등 자원별 사용량을 구분합니다. 따라서 실제 트래픽 패턴을 넣어 비교해야 합니다.

상황별 선택

Next.js MVP를 빠르게 공개해야 한다면

Vercel이 가장 단순한 출발점입니다. 배포 설정에 쓰는 시간을 줄이고 제품 검증에 집중하기 좋습니다.

회사 소개·문서처럼 정적 콘텐츠가 중심이라면

Cloudflare Pages나 Netlify를 우선 검토할 수 있습니다. 폼이나 인증이 필요한 부분만 Functions로 분리하면 구조가 단순해집니다.

데이터 처리와 내부 시스템 연동이 많다면

Vercel 같은 관리형 플랫폼과 외부 작업 서버를 조합하거나, Docker 환경에 애플리케이션과 작업 프로세스를 구성하는 편이 맞을 수 있습니다.

여러 고객 시스템을 일관된 방식으로 운영한다면

배포 자동화, 표준 Docker 이미지, 관제와 백업 체계가 이미 갖춰졌는지가 중요합니다. 체계가 없다면 서버 수가 늘수록 운영 위험도 같이 커집니다.

선택 전 체크리스트

  • 정적, 서버 렌더링, API 요청 비율을 구분했는가?
  • 사용하는 Next.js 기능이 대상 플랫폼에서 지원되는가?
  • 네이티브 모듈, 파일 시스템과 장시간 작업이 있는가?
  • 애플리케이션과 DB 지역이 가까운가?
  • 트래픽 급증 시 비용과 제한을 확인했는가?
  • 로그·알림·백업·복구 담당자가 정해졌는가?
  • 다른 플랫폼으로 옮길 때 바꿔야 할 기능을 알고 있는가?

정리

Vercel, Cloudflare Pages와 Netlify는 서버 관리를 줄여 주지만 실행 환경과 과금 단위가 서로 다릅니다. 자체 서버는 자유도가 높지만 그만큼 운영 책임도 커집니다.

가장 현실적인 선택은 기술 이름이 아니라 애플리케이션의 실행 방식, 데이터 위치, 운영 역량과 이전 계획에서 시작합니다. Next.js라고 무조건 Vercel이어야 하는 것도, 비용을 줄이기 위해 무조건 자체 서버를 써야 하는 것도 아닙니다.

다음 편에서는 개발 플랫폼이 아니라 비개발자도 운영할 수 있는 홈페이지 제작 도구를 비교합니다.

시리즈 이어 읽기

공식 자료

함께 읽기