Vercel 요금 줄이기: Basic 빌드 머신이 유리한 조건

저렴한 빌드 분당 요금만으로 결론을 내릴 수는 없습니다. 2026년 9월 3일, Vercel은 Pro와 Enterprise 팀에 2 vCPU, 메모리 8 GB, 빌드 분당 $0.007인 새로운 Basic 옵션을 선보였습니다. 하지만 실제 실행 시간과 분 단위 올림, 실패, 큐 대기까지 반영했을 때 완료된 빌드당 비용이 Elastic보다 낮아야 Vercel 요금이 실제로 줄어듭니다.

Vercel 요금 정책에서 달라진 점

빌드 머신은 Vercel이 의존성을 설치하고, 앱을 컴파일하고, 배포를 준비할 때 사용하는 임시 컴퓨터입니다. 이제 유료 프로젝트에도 더 작은 고정 사양을 선택할 수 있습니다. Basic 빌드 머신은 Hobby뿐 아니라 Pro와 Enterprise에서도 사용할 수 있습니다.

Basic 사양은 2 vCPU, 메모리 8 GB, 디스크 32 GB입니다. Elastic은 프로젝트 워크로드에 맞춰 430 vCPU와 860 GB의 메모리를 할당할 수 있습니다. 새로운 유료 프로젝트의 기본값은 여전히 Elastic입니다.

Basic은 새로운 유료 기본값이 아니라 선택지입니다. 새로운 유료 프로젝트는 계속 Elastic으로 시작하며, 소유자가 팀 또는 프로젝트 설정에서 Basic을 선택할 수 있습니다. Hobby 프로젝트에 포함된 2-vCPU 머신은 그대로이며 이름만 Basic으로 바뀌었습니다.

이 글에서는 빌드 머신 선택만 따로 살펴봅니다. 플랜 이용료, 사용량 크레딧, 좌석, 트래픽, 함수, 스토리지, 부가 기능까지 포함한 내용은 Vercel 전체 요금 분석에서 확인할 수 있습니다.

핵심 지표는 완료된 빌드당 비용

Basic과 Elastic은 vCPU-분당 $0.0035로 같은 요율에서 출발합니다. 두 옵션의 청구액이 달라지는 이유는 Basic이 항상 2 vCPU를 사용하는 반면, Elastic은 4~30 vCPU를 할당하기 때문입니다.

Vercel은 각 빌드 시간을 분 단위로 올림합니다. 따라서 실무에서는 다음 두 공식을 사용하면 됩니다.

• Basic: 올림된 빌드 시간(분) × $0.007.
• Elastic: 올림된 빌드 시간(분) × 할당된 vCPU 수 × $0.0035.

가장 작은 4-vCPU Elastic 할당의 시작 비용은 청구되는 빌드 분당 $0.014입니다. Basic의 청구 분당 비용은 그 절반입니다. 따라서 Basic의 청구 시간이 정확히 두 배라면 비용이 같고, 두 배보다 짧다면 가격 면에서 Basic이 유리합니다.

Elastic이 4 vCPU보다 많이 할당되면 이 기준도 달라집니다. Vercel은 월간 총시간이 아니라 개별 빌드 시간을 올림하므로, 분 경계를 넘을 때마다 계산도 바뀝니다. 청구액을 판단하려면 요금표상의 추정치가 아니라 실제 실행 시간과 할당된 머신을 확인해야 합니다.

이 예시 안에서 $7 절감은 분명하지만, 반드시 가치 있는 절감은 아닙니다. 모든 프리뷰가 개발자나 리뷰어, 코딩 에이전트의 작업을 멈춰 세운다면 느려진 피드백 루프의 비용이 청구액 절감분보다 커질 수 있습니다. 빌드가 백그라운드에서 실행되고 큐가 밀리지 않는다면 Basic의 단위 비용이 더 낫습니다.

분자에는 실패한 빌드도 포함해야 합니다. 실제로 봐야 할 운영 지표는 총 빌드 비용을 성공한 배포 수로 나눈 값입니다. 분당 비용은 저렴해도 재시도를 유발하는 머신이라면, 실제로 필요한 결과를 기준으로는 손해일 수 있습니다.

큐 대기도 워크플로 비용입니다

Vercel이 공개한 청구 공식에는 빌드 시간과 CPU 수가 사용됩니다. 큐 대기는 별도 항목으로 더해지지 않지만, 팀은 그 지연을 그대로 체감합니다.

온디맨드 동시 실행을 끄면 Pro에서 동시에 배포할 수 있는 슬롯은 3개입니다. 활성 슬롯을 넘는 빌드는 대기합니다. 온디맨드 동시 실행을 사용하면 Vercel은 최대 500개의 동시 배포를 제공하며, 사용한 빌드 시간에 요금을 부과합니다.

Basic에서 빌드가 느려지면 슬롯을 더 오래 차지합니다. 작은 사이트를 하루에 몇 차례 배포하는 창업자에게는 문제가 되지 않을 수 있습니다. 반면 코딩 에이전트가 여러 프리뷰를 열거나, 에이전시가 다수의 고객 프로젝트를 배포하거나, 팀이 여러 브랜치에 동시에 푸시한다면 금세 영향을 받을 수 있습니다.

두 가지 시간을 모두 기록해야 합니다.

• 빌드 시간은 올림 후 머신 비용을 결정합니다.
• 큐 대기 시간과 빌드 시간의 합은 피드백을 받기까지 걸리는 시간을 결정합니다.

결국 판단 기준은 이것뿐입니다. 첫 번째 수치를 최적화하되, 두 번째 수치가 워크플로를 망치지 않도록 해야 합니다.

Basic은 누가 테스트해야 할까?

소형 앱 하나를 혼자 운영하는 창업자

혼자 SaaS를 운영한다면 가벼운 마케팅 사이트나 대시보드를 프로젝트 단위로 Basic에 옮긴 뒤, 같은 대표 빌드를 Elastic과 비교할 수 있습니다. Vercel 요금제의 나머지 항목은 건드리지 않으면서 반복되는 빌드 비용을 낮출 수 있다는 점이 장점입니다.

빌드가 계속 안정적으로 완료되고, 실행 시간이 느려지더라도 릴리스를 지연시키지 않을 때만 전환을 유지할 가치가 있습니다. 배포 빈도가 낮은 프로젝트라면 금액 차이가 너무 작아 직접 튜닝할 이유가 없을 수도 있습니다.

고객 프로젝트 규모가 제각각인 에이전시

에이전시는 모든 고객 계정에 하나의 머신 결정을 일괄 적용하면 안 됩니다. 작은 랜딩 페이지와 콘텐츠 프로젝트부터 프로젝트별로 Basic에 고정해 보십시오. 대형 스토어프런트, 모노레포, 의존성이 많은 앱은 자체 측정 결과가 달리 말해 주기 전까지 Elastic에 두는 편이 낫습니다.

프로젝트별 수익성을 더 명확하게 관리할 수 있다는 점이 이 방식의 장점입니다. 리소스를 적게 쓰는 고객 프로젝트가 에이전시에서 가장 무거운 앱과 같은 빌드 머신을 물려받을 필요가 없어집니다.

코딩 에이전트를 운용하는 엔지니어링 리드

에이전트 중심 개발에서는 계산식의 빌드 횟수가 달라집니다. 자동 커밋이 늘면 프리뷰 빌드도 늘 수 있으므로, 빌드당 작은 비용 차이가 더 자주 반복됩니다.

엔지니어링 리드는 한산할 때의 배포 한 번이 아니라 평소 수준의 집중 부하를 측정해야 합니다. Basic이 완료된 빌드당 비용은 낮추더라도 실행 시간이 길어져 사용 가능한 슬롯 3개를 모두 채우고 큐를 만든다면, 저렴한 머신은 비용을 청구서에서 처리 시간으로 옮긴 셈입니다.

Enterprise 플랫폼 소유자

Basic은 Enterprise에서도 사용할 수 있지만, 계약 조건 하나가 셀프서비스 변경을 막을 수 있습니다. 계약상 Enhanced 머신이 활성화된 Enterprise 고객은 해당 머신을 기본으로 사용하며, 머신 설정을 바꾸려면 계정 관리자에게 문의해야 합니다.

프로젝트 하나만 Basic으로 바꾸고 테스트하는 방법

먼저 프로젝트 단위로 변경하십시오. 다른 앱에 영향을 주지 않고 실험할 수 있으며, 같은 설정에서 손쉽게 되돌릴 수 있습니다.

1. 1

   Elastic 기준선 기록

   Vercel Observability에서 Build Diagnostics를 열고 대표 배포를 선택합니다. 빌드 시간, 할당된 머신, 청구 사용량, 큐 대기 시간, 배포 완료 여부를 기록합니다. Basic 테스트에서도 캐시 조건과 코드 리비전을 최대한 동일하게 맞춥니다.

2. 2

   프로젝트에서 Basic 선택

   Vercel에서 프로젝트를 연 다음 Settings, Build and Deployment, Build Machine으로 이동합니다. Basic을 선택하고 저장합니다. Vercel 문서에는 팀 단위로도 같은 옵션을 선택할 수 있다고 나와 있지만, 첫 테스트는 프로젝트 설정이 더 안전합니다. 빌드 머신 설정에 접근하려면 소유자 역할이 필요합니다.

3. 3

   문서에 나온 CLI 방식 사용

   Vercel CLI 59.6.0 이상에서는 다음 명령으로 프로젝트 설정을 바꿀 수 있습니다.

   vc project update --build-machine basic

   흔한 실수는 구버전 CLI에서 명령을 실행한 뒤, 해당 플랜에서는 머신을 선택할 수 없다고 단정하는 것입니다. 명령 실패를 플랜 제한으로 보기 전에 버전을 확인하십시오.

4. 4

   같은 워크로드 실행

   비슷한 캐시 조건에서 동일한 대표 리비전을 빌드합니다. 빌드 시간, 머신, 청구 사용량, 큐 대기 시간, 완료 여부 등 같은 항목을 기록합니다. 에이전트 중심으로 개발한다면 큐가 실제로 생기는지 볼 수 있도록 평소 수준의 집중 부하도 포함합니다.

5. 5

   결과를 기준으로 선택

   월간 빌드 총비용을 계산해 성공한 배포 수로 나눕니다. 단위 비용이 낮아지고 전체 처리 시간이 팀의 목표를 충족한다면 Basic을 유지합니다. 속도, 메모리 또는 안정성 저하가 절감 효과를 상쇄할 만큼 커진다면 Build Machine 설정에서 프로젝트를 Elastic으로 되돌립니다.

Basic의 한계를 정확히 알아야 합니다

Basic은 Elastic을 더 효율적으로 만든 버전이 아니라 사양이 더 작은 머신입니다. 메모리 상한은 8 GB로 고정됩니다. Elastic은 워크로드가 필요로 할 때 최대 60 GB와 30 vCPU까지 확장할 수 있습니다.

분 단위 올림이 작은 절감액을 없앨 수도 있습니다. 분 경계를 몇 초만 넘어도 청구 시간이 한 분 더 생깁니다. 자신에게 유리하게 반올림한 스톱워치 계산이 아니라 Vercel에 표시된 청구 사용량을 비교해야 합니다.

Elastic은 프로젝트 변화에 맞춰 계속 적응합니다. Basic은 고정된 채로 남습니다. 지금은 작은 앱에 맞는 머신이라도 의존성, 라우트 또는 생성 에셋이 늘어난 뒤에는 잘못된 선택이 될 수 있습니다.

지금 실행할지, 기다릴지, 무시할지 판단하는 기준

• 이번 주 실행: 빌드가 안정적이고 리소스 사용량이 적은 Pro 또는 Enterprise 프로젝트를 운영하며, 반복되는 빌드당 비용 차이가 의미 있을 만큼 빌드 횟수가 많다면 테스트하십시오.
• 대기: 프로젝트가 CPU 병목 상태이거나, 메모리를 많이 쓰거나, 45분 한도에 가깝거나, 이미 프리뷰 큐에 민감하다면 기다리십시오. 먼저 신뢰할 수 있는 Elastic 기준선을 확보해야 합니다.
• 가격 변경 무시: Hobby를 사용한다면 이번 변경을 신경 쓸 필요가 없습니다. 포함된 2-vCPU 머신의 이름만 Basic으로 바뀌었을 뿐, 머신과 플랜의 적용 방식은 달라지지 않았습니다.
• 계약 우선 확인: Enterprise에 Enhanced 머신이 활성화되어 있다면 계정 관리자가 변경 권한을 갖고 있을 수 있습니다.

월요일에 바로 할 일

월요일에 대표적인 소형 프로젝트 하나를 고르십시오. 같은 빌드를 Elastic과 Basic에서 실행한 뒤 빌드 시간, 청구 사용량, 할당된 CPU, 큐 대기 시간, 완료 여부를 기록합니다. 완료된 빌드당 비용을 낮추면서 팀의 처리 시간 목표를 지키는 옵션을 선택하면 됩니다.

예산이나 워크플로를 바꾸는 플랫폼 소식을 알기 쉽게 받아보려면 뉴스레터를 구독하세요.