요약

  • Vercel은 10월 23일 기존 팀별 사용량 예산을 CLI에서 조회·설정·삭제하는 기능을 발표했다. 선택한 일괄 중단 동작은 팀의 모든 프로젝트 운영 배포에 적용된다.
  • 중단 뒤 예산을 늘려도 프로젝트가 자동 재개되지 않는다. 사이트를 하나씩 복구하는 동안 저장 자원 등의 청구는 남는다.

사이트를 다시 켜는 쪽은 계산기를 닫았다고 퇴근할 수 없다. Vercel의 지출 관리에는 팀 전체의 운영 배포를 멈추는 기능이 있다. 그러나 다시 서비스를 내보내려면 프로젝트마다 재개해야 한다. 지출 통제는 묶음이고, 서비스 복귀는 낱개다. 이 비대칭이 이번 CLI 업데이트에서 가장 비싼 문장이다.

10월 23일 발표는 vercel budgets로 청구 주기의 사용액과 예산을 확인하고, 같은 예산을 변경하거나 없앨 수 있게 됐다고 알린다. 대시보드의 On-Demand Budget과 CLI의 예산은 하나다. 스크립트나 에이전트도 필요한 권한으로 여기에 접근한다. 회계 숫자를 읽던 도구가 서비스를 멈추는 설정에도 손을 뻗을 수 있게 된 셈이다.

일괄 중단 자체는 새 발명이 아니다. Vercel은 2024년 3월에도 해당 기능을 소개했다. 이번 변화는 기존 통제를 명령줄 작업에 넣은 것이다. 중요한 변화다. 사람이 청구 설정 화면을 열어 판단하던 일을 반복 작업에 결합하기 쉬워졌기 때문이다. 편리함의 가치는 분명하고, 그 명령이 닿는 범위도 분명해야 한다.

한 프로젝트가 아니라 한 팀을 잡는다

예산 금액을 적는 것만으로 사용량이 멈추지는 않는다. 운영 배포 중단 옵션을 켜거나 CLI에서 --pause를 선택하면 예산 도달 시 팀의 모든 프로젝트 운영 배포가 중단된다. CLI 문서의 scope는 예산의 팀 단위 적용 범위를 뜻한다. 명령의 --scope로 다른 팀을 선택하는 것과 프로젝트 하나에 지출 한도를 두는 것은 다른 일이다.

고객별 사이트 여러 개를 같은 팀에 둔 사업자라면 이 차이는 매출 구조에 닿는다. 한 프로젝트의 사용량이 늘어 팀 예산을 채우면, 그 중단 옵션 아래에서는 다른 프로젝트도 함께 멈춘다. 비용을 발생시킨 곳과 이용 불가를 겪는 곳이 일치할 필요가 없다. 여기서 공동 청구는 공동 중단 가능성까지 품는다.

Vercel은 팀별 예산 기능을 Pro와 Enterprise Flexible Commitment에 추가 기능료 없이 제공하며, Owner 또는 Billing 역할이 관리할 수 있게 한다. 무료로 제공되는 통제에도 운영상 가격은 붙는다. 그 가격을 청구하는 쪽은 서비스를 기다리는 고객일 수 있다.

숫자가 벽이 되기까지 몇 분이 있다

현행 지출 관리 안내는 사용량 확인이 몇 분마다 이뤄진다고 설명한다. 알림, 웹훅, 중단 동작은 예산을 넘은 뒤 수 분 늦게 발생할 수 있다. 그동안 서비스와 사용량은 계속될 수 있다. 화면의 100%는 초 단위 전기 차단기의 눈금이 아니다.

청구 주기 중간에 예산을 낮추는 경우도 까다롭다. 이미 발생한 사용액이 포함되므로 현재 사용액 아래로 금액을 내리면 설정된 동작이 다음 확인 때 작동한다. 장래 지출을 줄이려 고친 숫자가 이미 쌓인 사용액과 만나 당장의 운영 배포를 멈출 수 있는 구조다. 예산 수정은 단순히 다음 달의 희망 지출을 쓰는 행위가 아니다.

무엇을 세는지도 요금제에 따라 다르다. Pro는 월 크레딧을 넘은 계량 사용량을, Enterprise Flexible Commitment는 선불 잔액을 소진하는 계량 사용량을 센다. 좌석, Marketplace 같은 연동 서비스, 별도 부가 상품은 이 금액에 들어가지 않는다. 예산과 최종 청구서를 같은 숫자로 취급하면 재무 담당자는 시작부터 다른 경기를 채점한다.

서비스가 멎어도 남는 청구

일괄 중단 때 방문자가 보는 것은 503 DEPLOYMENT_PAUSED 오류다. 운영 웹사이트, API와 함수가 요청을 받지 못한다. 저장된 자원은 지워지지 않는다. 유지한 배포 결과물과 함수 묶음, Vercel Blob, 컨테이너 레지스트리 이미지에는 관련 저장 요금이 계속 붙는다.

또한 운영 배포 중단은 AI Gateway API 키 사용이나 팀에 청구되는 v0 사용을 멈추지 않는다. 해당 사용이 이어지면 지출에도 계속 잡힌다. 스위치 하나로 팀 청구서 전체가 얼어붙는다는 계산은 성립하지 않는다. 고객이 보는 사이트는 멈추고도 사업자가 보유하거나 다른 경로로 쓰는 자원에는 비용이 남을 수 있다.

따라서 절감액은 중단 전후 요금 차이만으로 평가할 수 없다. 중단으로 피한 사용료, 남은 비용, 고객에게 약속한 서비스가 함께 계산 대상이다. 실제 손익을 구하려면 서비스별 트래픽과 계약상 약속, 당시 예산 설정, 중단·재개 시각이 필요하다. 그 자료 없이 만들 수 있는 확실한 결론은 하나다. 예산 한도는 손실 한도가 아니다.

한 번의 허용과 여러 번의 복귀

예산을 높였다고 재개까지 허용한 것으로 처리되지는 않는다. Vercel은 각 프로젝트를 대시보드나 REST API에서 개별 재개하도록 안내한다. 프로젝트 관리 문서는 재개에 새 배포가 필요 없으며 서비스가 몇 분 안에 돌아온다고 설명한다. 재개 버튼을 눌렀다는 사실과 고객의 요청이 다시 성공한다는 사실 사이에도 확인할 일이 남는다.

권한 목록도 구별해 읽어야 한다. 팀 예산을 관리하는 역할은 Owner 또는 Billing이다. 프로젝트 대시보드의 수동 재개에는 Owner, Member 또는 해당 프로젝트의 Project Administrator가 나온다. 조직은 실제 권한 배치를 확인해야 한다. 예산을 조정할 수 있는 사람의 연락처가 있다고 해서 모든 프로젝트의 복구 경로를 확보한 것은 아니다.

CLI의 알림 이력은 유용하지만 범위를 과장하면 값비싼 오해가 된다. 문서가 말하는 actions configured는 해당 임계점에 설정해 둔 동작이다. 그 동작이 실제 실행됐다는 증거가 아니다. 청구팀은 예산을 고쳤고, 운영팀은 재개를 눌렀으며, 고객은 여전히 실패 응답을 볼 수 있다. 세 팀의 보고가 각각 맞으면서 서비스는 아직 안 돌아올 수 있다는 뜻이다.

서로 다른 고객의 프로젝트를 한 팀 예산으로 묶을지는 결국 사업자가 내리는 선택이다. 함께 멈춰도 되는 서비스끼리 묶으면 통제는 이해하기 쉽다. 중단을 서로 감당할 수 없는 서비스를 묶으면, 한 줄로 쓴 비용 규칙이 여러 고객과의 약속을 동시에 건드린다. 분리를 택하더라도 팀 관리와 권한, 청구 운영이라는 일이 생긴다. 명령이 짧다고 결정의 무게까지 줄지는 않는다.

Vercel의 새 CLI는 예산을 다루는 손을 줄여준다. 고객이 사는 것은 그 손놀림이 아니라 돌아가는 서비스다. 좋은 예산은 비용을 멈추는 시점뿐 아니라, 누가 무엇을 어떤 순서로 다시 켤지까지 정해 놓은 예산이다.