Vercel CDN 비용 폭탄 없애기: Flat Rate CDN과 FinOps로 예측 가능한 인프라 비용 만들기 (2026)

Vercel을 쓰다 보면 한 번쯤 이런 경험을 하게 됩니다. 월말에 청구서를 열었는데, 예상보다 훨씬 큰 숫자가 적혀 있는 거죠. 심하면 DDoS 공격 한 방에 $23,000짜리 청구서를 받은 케이스도 실제로 있었고, HowdyGo 같은 팀은 이미지 최적화 항목 하나에서 매달 수백 달러가 새고 있다는 걸 한참 뒤에야 발견하기도 했습니다. 저도 처음엔 과금 구조를 제대로 파악하지 못해 이미지 최적화 초과분이 청구서에 조용히 붙어 있던 적이 있어요. Edge Requests, Fast Data Transfer, Origin Transfer, 이미지 최적화까지 과금 차원이 너무 많아서 어디서부터 잡아야 할지 막막했습니다.

2026년 5월, Vercel이 Pro 플랜 대상으로 Flat Rate CDN Limited Beta를 출시했습니다. 종량제를 월정액으로 바꾸는 이 모델은 단순한 가격 정책 변경이 아니라, CDN 비용 관리 방식 자체를 바꾸는 신호탄입니다. 여기에 FinOps 프레임워크를 결합하면 CDN 총소유비용(TCO)을 체계적으로 통제할 수 있는 구조가 만들어집니다.

이 글을 읽고 나면 다음 청구서를 열기 전에 이미 금액을 알 수 있게 됩니다. Vercel Pro 플랜으로 프로덕션 서비스를 운영 중이거나 준비 중인 분들, 그리고 Next.js App Router와 서버리스·CDN의 기본 개념을 갖고 계신 분들을 위한 글입니다.

목차

• 핵심 개념
  • Vercel 요금제, 왜 이렇게 복잡한가
  • Fast Data Transfer와 Fast Origin Transfer, 뭐가 다른가
  • Flat Rate CDN: 고정 요금 모델이 의미하는 것
  • FinOps를 Vercel에 적용한다는 것
• 실전 적용
  • 예시 1: Cache-Control 헤더로 Edge Requests 줄이기
  • 예시 2: ISR로 동적 페이지를 CDN 친화적으로 만들기
  • 예시 3: Spend Management로 안전망 설정하기
  • 예시 4: 이미지 최적화 비용 분리하기
• 장단점 분석
  • 장점
  • 단점 및 주의사항
  • 실무에서 가장 흔한 실수
• 마치며
• 참고 자료

핵심 개념

Vercel 요금제, 왜 이렇게 복잡한가

솔직히 Vercel 요금제는 처음 보면 당황스럽습니다. Pro 플랜이 "월 $20"처럼 보이지만, 실제로는 아래 항목들이 각각 독립적으로 과금됩니다.

이 항목들이 서로 연결되어 있다는 게 문제입니다. 그리고 여기서 많은 분들이 놓치는 부분이 하나 있습니다. Next.js 미들웨어는 매칭되는 모든 요청에 대해 Edge Request를 발생시킵니다. matcher를 정밀하게 설정하지 않으면, .js·.css·이미지 같은 정적 파일 요청까지 미들웨어를 통과하면서 Edge Requests 카운터가 생각보다 훨씬 빠르게 올라갑니다. 처음에 이 메커니즘을 몰랐을 때는 왜 Edge Requests가 그렇게 많이 나오는지 도저히 이해를 못 했었어요.

Fast Data Transfer와 Fast Origin Transfer, 뭐가 다른가

이 둘을 헷갈리는 분들이 많은데, 구간이 다릅니다.

• Fast Data Transfer: CDN → 최종 사용자 구간. 사용자가 데이터를 받아가는 비용입니다.
• Fast Origin Transfer: Origin 서버(또는 서버리스 함수) → CDN 구간. 캐시 미스가 발생해 원본에서 CDN으로 데이터를 가져올 때의 비용입니다.

캐시 히트율을 높이면 두 항목이 동시에 줄어드는 이유가 여기 있습니다. 특히 Fast Origin Transfer는 Origin 호출 자체를 줄이는 캐싱 전략에 더 직접적으로 반응합니다. 캐시 설정 하나가 서버리스 실행 비용까지 함께 잡아주는 구조입니다.

Flat Rate CDN: 고정 요금 모델이 의미하는 것

Flat Rate CDN이란 Edge Requests, Fast Data Transfer 등 CDN 관련 지표를 단일 고정 월정액으로 통합하는 과금 모델입니다. 트래픽 폭증이나 DDoS 공격에도 청구액이 변하지 않는 것이 핵심입니다.

2026년 5월 19일 Pro 플랜 Limited Beta로 출시된 이 모델은 종량제의 가장 큰 단점인 예측 불가능성을 정면으로 해결합니다. 공식 changelog 기준으로 Edge Requests와 Fast Data Transfer가 고정 요금에 포함되는 것으로 알려져 있으며, Fast Origin Transfer 포함 여부를 포함한 세부 요금 티어는 아직 미공개 상태입니다. GA 출시 시 확정될 예정이니, 지금 단계에서는 공개된 범위 내에서 판단하는 것이 좋습니다.

월초에 CDN 비용이 확정된다는 것 자체가 엔지니어링 팀에게는 엄청난 변화입니다. 예산 수립이 단순해지고, 기능 개발과 비용 계획을 동시에 진행할 수 있게 됩니다.

FinOps를 Vercel에 적용한다는 것

**FinOps(Financial Operations)**는 클라우드 인프라 비용에 재무적 책임을 부여하는 운영 프레임워크로, "Inform → Optimize → Operate"의 순환 사이클로 작동합니다.

State of FinOps 2026 보고서에 따르면, SaaS 비용을 FinOps로 관리하는 조직의 비율이 크게 증가했습니다. Vercel 같은 PaaS 플랫폼도 이제 FinOps 관리 대상입니다. 비용 관리는 더 이상 재무팀만의 일이 아니고, Vercel을 쓰는 개발자라면 이미 비용 의사결정의 당사자입니다.

Vercel 컨텍스트에서 이 사이클을 적용하면 이렇게 됩니다.

Inform   → Vercel Analytics + Spend Management 알림으로 현재 사용량 파악
Optimize → 캐싱 전략, ISR, 이미지 최적화 분리로 낭비 제거
Operate  → Flat Rate CDN + 임계치 알림으로 예측 가능한 상태 유지

아래 코드 예시들이 이 사이클의 Optimize 단계에 해당합니다.

실전 적용

예시 1: Cache-Control 헤더로 Edge Requests 줄이기

CDN 비용 절감의 가장 직접적인 방법은 캐시 히트율을 높이는 것입니다. Vercel Edge에서 응답이 캐시되면 Origin까지 요청이 도달하지 않아 Fast Origin Transfer와 서버리스 실행 시간이 동시에 줄어듭니다. 현업에서 확인해보면, 캐시 설정 하나를 제대로 잡는 것만으로도 Edge Requests 수치가 눈에 띄게 달라집니다.

// Next.js App Router - API Route에서 Cache-Control 설정
import { NextRequest, NextResponse } from 'next/server';
 
export async function GET(request: NextRequest) {
  try {
    const data = await fetchProductList(); // 상품 목록 조회
 
    return NextResponse.json(data, {
      headers: {
        // CDN에서 5분 캐시, 백그라운드 갱신 허용
        'Cache-Control': 's-maxage=300, stale-while-revalidate=600',
      },
    });
  } catch (error) {
    return NextResponse.json({ error: 'Failed to fetch' }, { status: 500 });
  }
}

stale-while-revalidate는 캐시가 만료된 후에도 600초 동안 구버전 응답을 즉시 제공하면서 백그라운드에서 새 데이터를 가져옵니다. 사용자 입장에서는 응답 지연이 없고, Origin 입장에서는 동시 갱신 요청이 몰리지 않아 일석이조입니다.

캐시가 실제로 동작하는지는 배포 후 아래 명령어로 확인해볼 수 있습니다.

# X-Vercel-Cache 헤더로 캐시 상태 확인
curl -I https://your-app.vercel.app/api/products | grep -i 'x-vercel-cache'
 
# HIT   → CDN 캐시에서 응답 (비용 절감 중)
# MISS  → Origin에서 응답 (캐시 미적용 상태)
# STALE → 만료된 캐시 제공 중, 백그라운드 갱신 진행 중

기대 효과: 트래픽이 많은 API 엔드포인트에 이 설정을 적용하면 동일 콘텐츠에 대한 서버리스 함수 호출이 5분에 한 번으로 제한됩니다. 캐시 히트율이 높아질수록 Edge Requests와 Fast Origin Transfer가 함께 줄어드는 것을 Vercel Analytics에서 확인할 수 있습니다.

예시 2: ISR로 동적 페이지를 CDN 친화적으로 만들기

e-commerce의 상품 상세 페이지처럼 수분 단위 갱신으로 충분한 콘텐츠라면, 실시간 SSR 대신 ISR(Incremental Static Regeneration)을 활용하는 것이 효과적입니다. 서버리스 함수 호출 횟수를 극적으로 줄일 수 있거든요.

아래는 Next.js 15+ App Router 기준 예시입니다. Next.js 15부터 params가 Promise로 변경됐으니, Pages Router 방식(params: { id: string })과 혼동하지 않도록 주의가 필요합니다.

// app/products/[id]/page.tsx (Next.js 15+ App Router)
export const revalidate = 300; // 5분마다 정적 재생성
 
interface Props {
  params: Promise<{ id: string }>; // Next.js 15+: params는 Promise
}
 
export default async function ProductPage({ params }: Props) {
  const { id } = await params; // await로 언래핑
 
  // revalidate 주기에만 실행 (그 사이엔 CDN 캐시에서 응답)
  const product = await fetchProduct(id);
 
  return <ProductDetail product={product} />;
}
 
// 빌드 시 인기 상품 미리 정적 생성
export async function generateStaticParams() {
  const topProducts = await fetchTopProducts(100);
  return topProducts.map((p) => ({ id: p.id }));
}

인기 상품 100개를 미리 정적 생성해두면, 해당 페이지에 대한 서버리스 함수 호출이 5분에 한 번으로 제한됩니다. Pages Router의 getStaticProps + revalidate 방식과 동일한 원리이지만, App Router에서는 Route Segment Config(export const revalidate)로 제어하는 방식이 다릅니다.

기대 효과: 실시간 SSR 대비 서버리스 실행 비용이 수십 배 차이 날 수 있습니다. 상품 상세 페이지처럼 페이지 수는 많지만 트래픽이 상위 몇 개에 몰리는 패턴에서 특히 효과가 큽니다.

예시 3: Spend Management로 안전망 설정하기

Flat Rate CDN이 출시됐더라도 서버리스 실행 시간, 이미지 최적화 등은 여전히 종량제입니다. Vercel의 Spend Management를 설정해두면 임계치 도달 시 자동 알림과 프로젝트 일시 중지가 가능합니다.

Spend Management는 vercel.json이 아닌 Vercel 대시보드 UI 또는 Vercel API를 통해 설정합니다. 대시보드에서 Settings → Spend Management로 이동하면 아래 항목들을 설정할 수 있습니다.

• 알림 임계치: 월 예산 대비 50% · 75% · 100% 도달 시 이메일·SMS 알림
• 자동 일시 중지: 임계치 초과 시 프로젝트 자동 중지 (트래픽 폭증 방어)
• 웹훅 연동: Slack, PagerDuty 등 외부 서비스로 알림 전달

Vercel API로 직접 설정하는 방법도 있습니다.

# Vercel API로 Spend Management 한도 설정 예시
curl -X PATCH "https://api.vercel.com/v1/projects/{projectId}/spending-limits" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "spend": [
      { "limitAmount": 50, "period": "month" }
    ]
  }'

한 가지 알아두면 좋은 점은, 이 모니터링이 실시간이 아니라 임계치 도달 후 수분의 지연이 있을 수 있다는 것입니다. 완벽한 보호막은 아니지만, 있는 것과 없는 것의 차이는 큽니다.

기대 효과: 예상치 못한 트래픽 폭증이나 봇 공격 시 청구서 액수가 통제 범위를 벗어나기 전에 대응할 수 있습니다. Slack 웹훅까지 연결해두면 알림 이메일이 스팸함에 빠지는 상황도 방지됩니다.

예시 4: 이미지 최적화 비용 분리하기

이미지 최적화는 종량제 모델에서 비용이 예상보다 빠르게 쌓이는 항목입니다. HowdyGo의 경우 월 28,000건의 이미지 최적화 요청이 발생하고 있었는데, Pro 플랜에 포함된 5,000건 한도를 초과한 23,000건에 $5/1,000건이 적용되어 매달 $115가 추가 청구됐습니다. 이를 자체 솔루션으로 전환한 후 비용을 80% 이상 절감했습니다. 숫자 자체는 작아 보일 수 있지만, 비슷한 패턴이 여러 항목에 겹치면 청구서가 갑자기 커지는 이유가 됩니다.

외부 이미지 최적화 서비스(예: Gumlet)로 분리하는 방법은 다음과 같습니다.

// next.config.ts - 외부 이미지 최적화 서비스 사용 설정
import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  images: {
    // Vercel 내장 최적화 대신 외부 로더 사용
    loader: 'custom',
    loaderFile: './image-loader.ts',
    remotePatterns: [
      {
        protocol: 'https',
        hostname: '*.gumlet.io',
      },
    ],
  },
};
 
export default nextConfig;

// image-loader.ts
interface ImageLoaderProps {
  src: string;
  width: number;
  quality?: number;
}
 
export default function gumletLoader({ src, width, quality }: ImageLoaderProps): string {
  const q = quality ?? 75;
  return `https://your-org.gumlet.io/${src}?w=${width}&q=${q}&f=auto`;
}

기대 효과: 월 5,000건을 넘는 트래픽이 예상된다면, 이미지 최적화 전문 SaaS의 정액 비용과 Vercel 초과 과금($5/1,000건)을 비교해보시면 좋습니다. 실제 Analytics → Usage 탭의 수치를 기준으로 분기점을 직접 계산해볼 수 있습니다.

장단점 분석

장점

단점 및 주의사항

TCO(Total Cost of Ownership): 직접 비용(요금)뿐 아니라 엔지니어링 시간, 운영 복잡도, 장애 리스크까지 포함한 총소유비용. CDN 전략을 비교할 때는 요금만이 아닌 TCO 기준으로 평가하는 것이 좋습니다.

실무에서 가장 흔한 실수

이 세 가지는 실무에서 반복적으로 나타나는 패턴입니다. 저는 두 번째를 직접 겪었는데, 로컬 개발 편의를 위해 켜둔 설정이 프로덕션 배포까지 그대로 따라간 경우였어요.

1. 미들웨어를 모든 경로에 적용하는 것: matcher를 정밀하게 설정하지 않으면 정적 파일 요청(.js, .css, 이미지)까지 미들웨어를 통과하면서 Edge Requests가 불필요하게 급증할 수 있습니다. 미들웨어 설정 후 Vercel Analytics에서 Edge Requests 추이를 확인해두시면 좋습니다.

2. Cache-Control: no-store를 기본값으로 두는 것: 개발 편의를 위해 캐시를 꺼두고 프로덕션에서 그대로 배포하는 경우가 생각보다 많습니다. 배포 체크리스트에 캐시 헤더 점검을 항목으로 넣어두는 것을 권장합니다.

3. Spend Management를 설정만 하고 웹훅을 연결하지 않는 것: 알림 이메일은 스팸 폴더에 빠지거나 늦게 확인될 수 있습니다. Slack이나 PagerDuty 웹훅을 함께 연결해두면 임계치 초과 시 즉각 대응이 가능합니다.

마치며

Vercel CDN 비용 문제의 본질은 '얼마나 쓰느냐'가 아니라 '얼마나 예측 가능하냐'에 있으며, Flat Rate CDN + FinOps 사이클의 조합이 그 예측 가능성을 확보하는 현실적인 경로입니다.

이 세 가지를 한 번만 챙겨두면, 다음 달 청구서를 열기 전에 이미 금액을 알 수 있게 됩니다.

1. 현재 사용량을 파악하는 것이 시작점입니다. Vercel 대시보드의 Analytics → Usage 탭에서 지난 30일간 Edge Requests, Fast Data Transfer, 이미지 최적화 건수를 확인해보시면 좋습니다. 어느 항목이 포함 한도를 초과하고 있는지, 어떤 프로젝트나 경로가 주범인지 파악하면 이후 최적화 순서가 자연스럽게 정해집니다.

2. 가장 비용이 높은 항목 하나에 캐싱 전략을 적용해보시면 좋습니다. API Route에 Cache-Control: s-maxage=300, stale-while-revalidate=600을 추가하거나, 동적 페이지에 export const revalidate = 300을 설정하는 것처럼 작은 변화부터 시작할 수 있습니다. curl로 X-Vercel-Cache: HIT이 반환되는지 확인하면 효과가 바로 체감됩니다.

3. Flat Rate CDN 대기자 명단에 등록해두시면 좋습니다. vercel.com/changelog/flat-rate-cdn-in-limited-beta에서 등록할 수 있습니다. GA 출시 시 구체적인 요금 티어가 공개될 텐데, 현재 종량제 비용과 비교해 전환 여부를 결정할 수 있도록 지금부터 사용량 데이터를 미리 확보해두는 것이 유리합니다.

참고 자료

• Flat Rate CDN in Limited Beta | Vercel Changelog
• CDN Pricing and Usage | Vercel Docs
• Manage and Optimize Usage | Vercel Docs
• Spend Management | Vercel Docs
• Vercel CDN Cache | Vercel Docs
• Cache-Control Headers | Vercel Docs
• Cutting Vercel Costs by 80% without Compromising UX or DX | HowdyGo
• 35% Cost Reduction Case Study | Pagepro
• How to Optimize Vercel Cost in 2026 | Focus Reactive
• How to Reduce Vercel Data Transfer Costs | Gumlet
• Should I Use Cloudflare in Front of Vercel? | Vercel Knowledge Base
• ISR: A Flexible Way to Cache Dynamic Content | Vercel Blog
• State of FinOps 2026 Report | FinOps Foundation
• Vercel Pricing 2026: Why My $20/mo Plan Actually Cost $286 | DeployWise