Chiko IT
클라우드 & SaaS

Vercel vs Netlify 비교 2026 — 무료 플랜·빌드 속도·엣지 함수 실전 분석

Chiko
11min read

목차

배포 비용이 절반으로 줄어든 단순한 이유

그래서, 지난 분기에 사이드 프로젝트 두 개와 회사 마케팅 페이지를 모두 Vercel 한 곳으로 묶어 돌렸더니, vercel vs netlify 비교를 진지하게 다시 해야 했다. 청구서가 예상보다 컸기 때문이다. 정적 페이지처럼 보이는 사이트인데도 미들웨어가 모든 경로에서 돌면서 함수 호출이 누적됐고, 일부는 Pro 플랜으로 강제 승급되어 결제 단계로 넘어갔다.

Before — 모든 프로젝트가 Vercel Pro 한 계정에 묶여 있었다. 월 청구액이 50달러 수준으로 올라갔다. 빌드는 빠르지만 트래픽이 늘면 함수 호출과 Fast Data Transfer가 동시에 누적된다.

After — SSR이 핵심인 1개 프로젝트만 Vercel에 남기고, 정적/Jamstack 성격의 나머지는 Netlify로 옮겼다. 같은 트래픽 기준 총비용이 절반 이하로 떨어졌다. 빌드 시간은 길어졌지만 캐싱 전략을 손봐서 운영상 체감은 크지 않았다.

이 글은 그 과정에서 정리한 두 플랫폼의 실제 차이를 다룬다. 가격표 단순 비교가 아니라, 어떤 워크로드에서 어디가 유리한지가 핵심이다. 모든 수치는 2026년 5월 기준 공식 페이지와 공개 자료를 토대로 했으며, 정책은 자주 바뀌니 결정 시점에 다시 확인할 것을 전제로 한다.

기존 접근의 한계 — "Next.js면 Vercel"의 절반의 진실

Next.js를 만든 회사가 Vercel을 운영하니 호환성과 빌드 최적화 면에서 강점이 명확하다. ISR(Incremental Static Regeneration), App Router의 스트리밍, Server Actions 같은 기능은 Vercel에서 가장 매끄럽게 동작한다. Next.js 신규 기능의 Day-1 지원은 다른 플랫폼이 따라가기 어렵다.

즉, 다만 운영 단계로 들어가면 두 가지가 걸린다.

첫째, 함수 호출 단위 과금이 누적된다. Edge Function이든 Serverless Function이든 호출 수와 실행 시간이 카운트된다. middleware.ts의 matcher 설정을 좁히지 않으면 정적 자산 요청에서도 미들웨어가 돌고, Hobby 플랜의 함수 호출 한도(2026년 5월 공식 페이지 기준 100만 회/월)를 예상보다 빨리 소진한다.

둘째, 대역폭 측정 방식이다. Vercel은 "Fast Data Transfer"라는 이름으로 데이터 전송량을 정산한다. 이미지가 많은 프로젝트라면 100GB 한도가 빨리 닳는다. CDN 캐시 히트율이 낮으면 같은 트래픽이라도 더 빨리 소진된다.

이 두 가지가 겹치면 "무료로 시작해 천천히 올라가겠다"는 계획이 어긋난다. 특히 마케팅 페이지처럼 트래픽 변동이 큰 워크로드에서 그렇다.

두 플랫폼의 가격 구조, 어디서 진짜로 새는가

특히, 가격은 자주 바뀌므로 결정 전에는 항상 Vercel Pricing과 Netlify Pricing 공식 페이지를 다시 확인해야 한다. 아래는 2026년 5월 기준 공개된 정보를 단순화한 비교다.

항목 Vercel Hobby (무료) Netlify Starter (무료)
대역폭 100 GB (Fast Data Transfer) 100 GB
빌드 시간 6,000 분/월 300 분/월
함수 호출 Edge 100만 회, Serverless 100 GB-Hours 12.5만 회
동시 빌드 1 1
상업적 사용 약관상 금지 허용
폼/Identity 없음 100 submissions/mo, Identity 1k MAU

즉, 상업적 사용 가능 여부는 라이선스적으로 큰 차이를 만든다. Vercel Hobby는 상업 프로젝트 금지가 약관에 명문화되어 있어, 작은 비즈니스 사이트도 원칙적으로는 Pro 플랜으로 올라가야 한다. Netlify Starter는 상업적 사용을 허용한다. 이 한 줄이 작은 팀의 초기 비용 구조에 의외로 큰 영향을 준다.

트래픽이 늘었을 때 비용 곡선

Pro 플랜으로 올라가는 시점이 다르다. Vercel Pro는 멤버당 월 20달러대 기본요금에 사용량 과금이 붙는다. Netlify Pro도 비슷한 가격대지만 함수 호출과 빌드 분의 단가 구조가 다르다.

그런데, 체감상 차이는 "어디서 누적되는가"다. SSR 비중이 높은 앱은 Vercel 쪽에서 함수 호출과 실행 시간이 먼저 쌓이고, 빌드가 잦은 정적/CMS 사이트는 Netlify 빌드 분이 먼저 바닥난다. Headless CMS를 붙여놓고 콘텐츠 업데이트마다 재빌드가 도는 구조라면 Netlify 300분은 한 달을 못 버틸 수도 있다.

숨은 비용 — 이미지 최적화와 콜드 스타트

즉, 이미지 최적화는 양쪽 다 별도 과금 단위가 있다. Vercel의 Image Optimization은 원본 변환 횟수당 과금한다. Netlify는 Image CDN을 별도 단가로 계산한다. 둘 다 무료 한도가 있지만 SNS 공유 카드 자동 생성 같은 트래픽 패턴에서는 한도가 빨리 닳는다.

콜드 스타트 빈도는 함수의 워밍 빈도와 리전 분포에 따라 달라진다. 한국에서 호출하는 첫 요청은 두 플랫폼 모두 도쿄 리전 기준으로 추가 지연이 붙는 게 일반적이다.

빌드 시간 — 같은 코드, 왜 결과가 다른가

특히, 동일한 Next.js 14 프로젝트를 두 곳에 올렸을 때 가장 두드러진 차이는 빌드 캐싱 동작이다.

한편, Vercel은 Next.js의 .next/cache 디렉터리를 자체 캐시 레이어에 자동으로 보관한다. 의존성이나 페이지 변경이 없으면 재컴파일을 건너뛴다. 첫 빌드는 두 플랫폼이 비슷하지만, 두 번째 빌드부터 격차가 벌어진다.

Netlify는 빌드 캐시를 직접 설정해야 한다. netlify.toml에 Next.js 플러그인을 명시하지 않으면 매번 처음부터 돈다. 다음과 같이 잡아두는 게 기본이다.

# netlify.toml — 캐시 플러그인을 명시하지 않으면
# 매번 의존성을 새로 받는다
[build]
  command = "npm run build"
  publish = ".next"

[[plugins]]
  package = "@netlify/plugin-nextjs"

# 메모리 한도 — 4GB로 잡지 않으면 큰 프로젝트에서 OOM
[build.environment]
  NODE_OPTIONS = "--max-old-space-size=4096"
  NETLIFY_NEXT_PLUGIN_SKIP = "false"

즉, 이 설정 없이 빌드를 돌리면 의존성을 매번 새로 받는다. 캐시 플러그인을 명시하면 두 번째 빌드부터 빌드 시간이 절반 가까이 줄어든다는 게 일반적인 보고다. 공식 문서(Netlify Build Plugins)에 명시되어 있지만, 템플릿으로 시작하면 빠뜨리기 쉬운 부분이다.

모노레포에서의 차이

특히, Vercel은 모노레포에서 변경된 패키지만 골라 빌드하는 게 거의 자동이다. Turborepo 통합이 기본값이라 turbo.json만 있으면 별도 설정이 필요 없다. Netlify는 Build Plugins로 유사한 동작을 구성할 수 있지만 손이 더 간다. 이 부분은 팀이 모노레포를 쓰는지 단일 레포를 쓰는지에 따라 체감이 크게 갈린다.

엣지 함수와 한국 리전 — 실제 응답의 한계

엣지 함수는 두 곳 모두 V8 Isolate 기반이다. 전통적 Node.js 런타임이 아니라 가벼운 격리 환경에서 돌기 때문에 콜드 스타트가 거의 없다는 게 공통된 장점이다.

한편, 다만 한국 사용자 입장에서는 PoP(Point of Presence) 분포가 결정적이다. Vercel의 엣지 네트워크는 자체 인프라와 AWS 기반 게이트웨이가 섞여 있다. Netlify는 Deno Deploy 인프라를 부분적으로 활용한다(2024년 발표 기준). 한국에서 호출하면 두 곳 다 도쿄 또는 싱가포르 리전으로 라우팅되는 경우가 많다. 서울 PoP는 일부 기능에만 적용된다.

// 단순 핸들러 — 두 플랫폼에서 거의 동일하게 동작한다
export const config = { runtime: 'edge' };

export default async function handler(req) {
  const start = Date.now();
  // 가벼운 KV 조회 정도가 엣지에 어울린다
  const res = await fetch('https://api.example.com/health');
  const elapsed = Date.now() - start;

  return new Response(
    JSON.stringify({ ok: res.ok, elapsed }),
    { headers: { 'content-type': 'application/json' } }
  );
}

이 정도 단순 핸들러는 두 곳 모두 잘 돈다. 차이는 외부 API 호출이 길어질 때 드러난다. 2026년 5월 기준 공식 문서를 보면 Vercel Edge Function의 Hobby 플랜 최대 실행 시간은 25초 선이고, Netlify Edge Functions는 50초까지 허용한다. LLM 스트리밍처럼 응답이 긴 워크로드를 엣지로 보낼 계획이라면 이 한도가 결정적일 수 있다.

측정은 직접 할 것

예를 들어, 응답 시간을 추측하지 말고 직접 측정하는 게 낫다. WebPageTest에서 서울/도쿄/싱가포르 노드를 명시해 비교하거나, k6로 부하 테스트를 돌려보는 식이다. 같은 함수라도 시간대와 리전에 따라 결과가 달라지므로 한 번의 측정으로 결정하지 않는 게 안전해 보인다.

워크로드별 분리 운영 제안

게다가, 가설은 단순하다. 한 플랫폼으로 통일하지 말고 워크로드 성격에 따라 나눠 쓰는 게 비용과 성능 양쪽에서 유리하다.

게다가, 정적 마케팅 페이지, 블로그, 문서 사이트는 Netlify가 무난하다. 상업적 사용 제한이 없고, 빌드 캐시만 잡으면 비용 곡선이 완만하다. Netlify Forms나 Identity 같은 부가 기능도 무료 한도 안에서 쓸 수 있어 작은 사이트는 거의 무료로 운영 가능하다.

예를 들어, SSR이 중요한 앱, Next.js App Router의 스트리밍, ISR 기반 콘텐츠 사이트는 Vercel이 유리하다. Next.js 신기능 호환성과 빌드 캐싱이 가장 매끄럽다. 단, 미들웨어 matcher를 좁게 잡고 Edge Function 호출 누적을 관리해야 한다.

LLM 스트리밍처럼 장시간 요청은 Netlify Edge Functions가 더 여유롭다. 또는 Cloudflare Workers 같은 제3의 선택지를 함께 검토할 가치가 있다.

분리 운영의 실무 비용

게다가, 도메인 분리, 환경 변수 동기화, CI/CD 분기 같은 운영 비용이 발생한다. 두 플랫폼 모두 GitHub 연동은 매끄럽지만, 한 PR이 두 곳을 동시에 트리거하면 빌드 시간도 두 배가 된다. 모노레포 + Turborepo로 묶고 변경된 패키지만 각 플랫폼에 배포하는 구조가 깔끔하다. GitHub Actions에서 paths 필터로 트리거를 분리하는 방법도 있다.

한계점 — 가격은 자주 바뀌고, PoP도 계속 늘어난다

이 글의 모든 수치는 2026년 5월 공개 정보를 토대로 했다. Vercel과 Netlify 모두 가격 정책을 자주 갱신한다. Vercel은 2024년 한 차례 함수 호출 단가 구조를 크게 개편했고, Netlify도 비슷한 시기에 빌드 분 단위를 조정했다. 작성 시점 이후 변경 가능성이 크니, 결정 시점에는 Vercel Pricing / Netlify Pricing 공식 페이지를 반드시 재확인할 것.

게다가, 한국 PoP 분포 역시 시간이 갈수록 개선되는 추세라 6개월 단위로 재측정할 가치가 있다. 또 이 글은 두 플랫폼만 다뤘지만, 동일 워크로드에서 Cloudflare Pages + Workers를 함께 비교해보는 게 합리적이다.

그런데, 지금 당장 해볼 수 있는 액션은 세 가지다. 첫째, 현재 사용 중인 플랫폼 대시보드에서 최근 30일치 함수 호출 수와 대역폭 추이를 확인한다. 둘째, 정적 자산만 골라 다른 플랫폼에 미러 배포해 비용 시뮬레이션을 돌려본다. 셋째, middleware.ts의 matcher를 좁혀 불필요한 함수 호출 누적부터 차단한다.

반면, 다음엔 Cloudflare Pages + Workers를 같은 워크로드에 올려 세 플랫폼을 동일 기준으로 측정해볼 생각이다.

관련 글

More posts