Vercel 배포 한 번에만 Turbo를 적용하는 방법과 비용

2026년 9월 17일, Vercel은 Turbo를 프로젝트 전체에 적용해야 하는 선택지에서 Vercel 배포 한 번에만 비용을 더 내는 선택지로 바꿨습니다. 급한 빌드 한 번에는 더 투자하고, 다음 배포부터는 프로젝트에서 평소 쓰던 머신으로 돌아갈 수 있습니다.

프로젝트 설정을 바꿀 필요가 없어졌습니다

빌드 머신은 의존성을 설치하고 앱을 컴파일해 배포를 준비하는 동안 Vercel이 코드를 실행할 수 있도록 제공하는 임시 컴퓨터입니다. Turbo는 고정형 옵션 중 가장 큰 사양으로, 30 vCPU, 메모리 60 GB, 디스크 64 GB를 제공합니다.

이 변경 전에는 고정형 빌드 머신을 선택하려면 팀 또는 프로젝트 설정을 바꿔야 했습니다. 촉박한 마감에 대처하기에는 번거로운 방식이었습니다. 일상적인 프리뷰 빌드까지 계속 Turbo 비용을 내거나, 급할 때 설정을 바꾼 뒤 다시 원래대로 돌려놓는 일을 기억해야 했습니다.

새 오버라이드는 Vercel 배포 한 번에만 Turbo를 적용합니다. 프로젝트 설정 자체는 수정하지 않습니다. 프로젝트가 평소 Basic, Standard 또는 Elastic을 사용한다면, 별도의 오버라이드를 다시 추가하지 않는 한 다음 배포에서는 원래 선택한 머신을 사용합니다.

이 점이 핵심입니다. 모든 커밋이 아니라 빌드의 긴급도에 따라 추가 비용을 쓸 수 있습니다.

Turbo, Enhanced, Elastic은 Pro와 Enterprise에서 사용할 수 있습니다. Hobby 프로젝트는 항상 Basic을 사용하므로, Hobby의 속도를 높이는 스위치는 아닙니다. 이미 모든 배포를 Turbo로 실행하는 프로젝트에도 실질적인 이점이 없습니다.

Vercel 배포 한 번에 Turbo를 적용하는 세 가지 방법

어떤 방식으로 배포를 시작하느냐에 따라 방법이 달라집니다. 어느 경로를 택해도 동일한 일회성 배포 오버라이드가 적용됩니다.

1. 1

   GitHub 커밋 마커 사용

   Vercel의 GitHub 연동으로 시작하는 배포라면 커밋 메시지 본문에 대소문자를 구분하는 정확한 마커를 넣습니다.

   git commit -m "Test this change with Turbo" \
     -m "#VERCEL_BUILD_MACHINE=TURBO"

   이 마커는 해당 커밋에서 시작된 배포에만 적용됩니다. 현재 Vercel의 GitLab 또는 Bitbucket 연동에서는 동작하지 않습니다.

2. 2

   Vercel CLI 사용

   연결된 프로젝트에서 다음 명령을 실행합니다.

   vc deploy --turbo

   이 방법은 Vercel CLI 59.20.0 이상이 필요합니다. 플래그가 인식되지 않는다면 가장 먼저 구버전 CLI를 사용 중인지 확인해야 합니다.

3. 3

   배포 API 필드 설정

   내부 릴리스 서비스가 POST /v13/deployments를 통해 배포를 생성한다면, 요청의 buildMachine을 turbo로 설정합니다. 이 필드는 선택 사항이며 해당 배포에만 적용됩니다. 프로젝트 설정을 다시 쓰지 않습니다.

프로젝트의 빌드 머신을 변경할 권한이 필요합니다. 눈에 잘 띄지 않는 실패 방식도 알아둬야 합니다. Turbo를 사용할 수 없거나 계정에 권한이 없으면 Vercel은 배포를 실패시키는 대신 프로젝트에서 평소 선택한 머신을 사용합니다.

한 번은 작지만 반복하면 커지는 비용

Vercel의 현재 빌드 사용량 요금은 CPU 분당 $0.0035입니다. 이를 청구되는 빌드 시간의 분당 시작 가격으로 환산하면 Basic은 $0.007, Standard는 요금이 부과될 때 $0.014, Enhanced는 $0.028, Turbo는 $0.105입니다.

청구 시간은 각 빌드를 분 단위로 올림한 뒤 머신의 CPU 수를 곱해 계산합니다. Turbo 빌드가 3분 40초 걸렸다면 4분으로 청구되므로 비용은 $0.42입니다.

프로젝트 차원에서 Basic과 Elastic 중 무엇을 선택할지는 Basic 머신으로 Vercel 빌드 비용 줄이기를 참고하면 됩니다. 여기서 새로 내려야 할 결정은 더 좁습니다. 한 번의 마감에 Turbo 추가 비용을 지불할 가치가 있는지 판단하는 일입니다.

벤치마크가 아닌 워크로드 예시

한 팀이 일주일에 일반 배포 20회와 긴급 배포 1회를 내보낸다고 가정해 보겠습니다. 팀이 직접 측정한 결과, 같은 워크로드가 Basic에서는 7분 20초, Turbo에서는 3분 40초 걸렸습니다. 이 시간은 계산을 위해 가정한 값입니다. Turbo가 모든 빌드 시간을 절반으로 줄여주는 것은 아닙니다.

긴급 배포 한 번의 오버라이드는 해당 배포를 Basic에서 실행할 때보다 $0.364를 더 씁니다. 이 예시에서는 중요한 릴리스의 빌드 시간을 실제 측정값 기준으로 3분 40초 줄이는 데 드는 추가 비용입니다.

일반 빌드 20회를 Basic으로 유지하면 21회 모두를 Turbo로 실행할 때보다 주간 합계가 $7.28 낮아집니다. 이것이 새로운 예산 제어 방식의 핵심입니다. 실제 판단에는 자체 측정한 시간이 필요합니다. 캐시 상태, CPU 사용량, 메모리 압박, 시간 올림 방식에 따라 결과가 모두 달라질 수 있기 때문입니다.

이 방식이 유용한 워크플로

프로덕션 장애를 고치는 솔로 창업자

GitHub에 연결된 SaaS를 운영하는 창업자는 핫픽스 커밋 하나에 마커를 넣을 수 있습니다. 프로젝트를 영구적으로 빠르게 만드는 것이 목적은 아닙니다. 장애, 고객과의 약속, 출시 일정에 걸린 릴리스의 대기 시간만 줄이고 다음 푸시부터는 평소 비용으로 돌아가는 방식입니다.

마감이 하나인 에이전시 릴리스 담당자

에이전시는 검토를 기다리는 사람이 있는 고객 릴리스에만 vc deploy --turbo를 사용할 수 있습니다. 일반 프리뷰는 프로젝트의 기존 설정을 유지하므로, 고객의 수정 요청이 생길 때마다 빌드 비용이 눈에 띄지 않게 불어나는 일을 막을 수 있습니다.

승인 절차가 있는 플랫폼 엔지니어

플랫폼 팀은 배포 서비스에서 승인된 긴급 릴리스 경로에만 buildMachine: "turbo"를 추가할 수 있습니다. 추가 컴퓨팅 자원이 프로젝트의 상시 기본값이 아니라, 기록하고 검토하며 비용을 계산할 수 있는 명시적인 릴리스 결정이 됩니다.

과장 없이 봐야 할 한계

30 vCPU라고 해서 빌드가 Basic의 2 vCPU보다 15배 빠르게 실행되는 것은 아닙니다. 모든 코어를 충분히 활용하지 못하는 빌드도 있습니다. Vercel은 많은 프로젝트가 Turbo 머신을 완전히 활용하지 못한다고 설명합니다. Elastic이 일반 작업에 더 작은 머신을 선택할 수 있는 이유이기도 합니다.

Turbo는 머신을 바꾸지만 대기열 정책은 바꾸지 않습니다. 지연 시간의 대부분이 빌드 슬롯을 기다리는 데서 발생한다면, 더 큰 머신은 엉뚱한 문제를 해결하는 셈입니다. CPU에 더 많은 비용을 내기 전에 대기 시간과 실제 빌드 시간을 비교해야 합니다.

캐시 상태 역시 비교를 망칠 수 있습니다. 캐시가 준비된 기본 빌드와 콜드 캐시의 Turbo 빌드를 비교해서는 머신이 만든 차이를 알 수 없습니다. 비슷한 리비전과 캐시 조건을 사용하고, 실제 경과 시간뿐 아니라 청구 시간도 함께 비교해야 합니다.

통제된 시험 한 번 실행하기

1. 1

   일반 배포 기록

   Build Diagnostics를 열어 프로젝트의 일반적인 머신 선택, 빌드 시간, 대기 시간, 청구 시간, 결과를 기록합니다. 확인하려는 긴급 워크로드와 비슷한 배포를 고릅니다.

2. 2

   배포 한 번 오버라이드

   서로 비교할 수 있는 배포 하나에 GitHub 마커, CLI 플래그 또는 API 필드를 사용합니다. 팀이나 프로젝트의 빌드 머신 설정은 바꾸지 않습니다.

3. 3

   관측된 시간 절감에 가격 매기기

   분 단위로 올림된 Turbo 빌드 시간에 $0.105를 곱합니다. 이 비용을 일반 배포의 청구 사용량과 비교한 뒤, 추가 비용을 실제로 줄인 시간으로 나눕니다.

4. 4

   다음 배포 확인

   마커, 플래그, API 필드 없이 일반 배포를 한 번 더 실행합니다. 프로젝트가 평소 사용하던 머신으로 돌아갔는지 확인합니다. 이렇게 하면 프로젝트 설정을 실수로 바꾼 경우를 찾아낼 수 있고, 오버라이드가 일시적으로만 적용됐다는 점도 입증할 수 있습니다.

지금 해야 할 일

• 이번 주에 실행하는 편이 좋습니다. Pro 또는 Enterprise 프로젝트를 운영하고, 이따금 마감이 촉박한 릴리스가 있으며, 유지하고 싶은 일반 머신 설정이 있다면 적합합니다.
• 먼저 측정해야 합니다. 프로젝트가 Elastic을 사용한다면 이미 충분한 CPU와 메모리를 배정하고 있을 수 있습니다. 이때 Turbo를 강제하면 시간은 거의 줄지 않은 채 요금만 늘어날 수 있습니다.
• 대부분의 배포에 Turbo가 필요하다면 프로젝트 설정을 사용하는 편이 낫습니다. 모든 커밋에 예외를 반복 적용하는 방식은 플래그로 위장한 정책일 뿐입니다.
• Hobby를 사용하거나, 이미 Turbo가 기본값이거나, 지연의 주원인이 대기열이라면 무시해도 됩니다.

월요일에 할 일

월요일에 대표적인 배포 하나를 고릅니다. 일반 빌드를 기록하고 Turbo 오버라이드를 한 번 실행한 뒤, 실제로 줄어든 시간과 추가 비용을 계산합니다. 이어서 일반 배포를 보내 프로젝트가 기존 설정으로 돌아갔는지 확인합니다.

뉴스레터를 구독하면 예산이나 워크플로를 바꾸는 플랫폼 변화를 알기 쉽게 받아볼 수 있습니다.