구글 클라우드 지출 상한 정식 출시, 예약 처리량 요청은 계속 처리

Published · AI Daily — AI-assisted deep research, methodology & disclosure

Google Cloud는 2026년 10월 30일 Google Cloud Budgets의 지출 상한이 정식 출시되었다고 발표했다. 이번 버전은 대상 서비스에 적용되는 API, 실시간 추정 비용 보고서, 월별 자동 초기화를 추가해 리소스를 삭제하지 않고 과도한 사용을 제한한다. 상한에 도달하면 종량제 요청과 약정 사용 할인으로 처리되는 요청은 중단될 수 있지만, Provisioned Throughput의 예약 용량 요청은 절대로 중단되지 않고 계속 트래픽을 처리한다.API 가이드에 따르면 모든 상한은 다음 예산 기간에 자동 초기화되고 수동 해제는 당기 내 조기 재개다.

Google Cloud는 2026년 10월 30일 Google Cloud Budgets의 지출 상한이 정식 출시되었다고 발표했다. 이번 버전은 대상 서비스에 적용되는 API, 실시간 추정 비용 보고서, 월별 자동 초기화를 추가해 리소스를 삭제하지 않고 과도한 사용을 제한한다. 상한에 도달하면 종량제 요청과 약정 사용 할인으로 처리되는 요청은 중단될 수 있지만, Provisioned Throughput의 예약 용량 요청은 절대로 중단되지 않고 계속 트래픽을 처리한다. 이 사이트의 11월 2일 발행호는 원 발표 날짜와 이 중요한 예외를 함께 명시한다.

새 API는 기존 Cloud Billing Budgets API에서 사용할 수 있다. 관리자는 프로젝트 내 적용 대상 서비스의 상한을 프로그램으로 생성, 변경, 해제, 삭제할 수 있다. 짧게 쓰는 개발 샌드박스나 실험용 에이전트 프로젝트를 만들 때부터 작은 한도를 설정하면 나중에 청구서를 확인할 때까지 무제한 사용이 이어지는 상황을 줄일 수 있다. 그렇다고 모든 Google Cloud 제품이 같은 방식으로 강제 차단된다는 뜻은 아니다. 이미 발생한 요금이 자동으로 사라지는 것도 아니다. 보호를 선언하기 전에 프로젝트, 서비스의 적용 자격, 결제 권한, 실제 상한 설정을 각각 확인해야 한다.

AI 서비스에는 실시간 추정 비용이 사용되어 이용 후 수분 안에 상한이 발동할 수 있다고 Google은 설명한다. Cost Reports에는 차단 판단에 쓰인 빠른 추정치가 나타나므로 느린 최종 순비용 정산을 기다리지 않고 원인을 조사할 수 있다. 그러나 추정치와 확정 청구액은 시각이나 금액이 다를 수 있다. 사고 기록에는 설정값, 발동 시각, 실시간 비용 화면, 거절된 요청의 응답, 이후 확정된 청구액을 남기는 것이 적절하다. ‘수분 안’이라는 표현은 지원되는 AI 서비스에 대한 설명이지 모든 비용이 정확히 상한 금액에서 멈춘다는 보장은 아니다.

API 가이드는 모든 상한이 다음 예산 기간 시작에 CONFIGURED로 자동 초기화되어 차단된 서비스를 다시 연다고 설명한다. 수동 해제는 당기 내 조기 재개다. AWAITING_NEXT_PERIOD로 바꾸면 금액을 올리고 inputState를 CONFIGURED로 재설정하지 않는 한 그 기간에는 다시 발동하지 않는다. 주 블로그는 manual override가 남는다고 말하지만 가이드에는 기간을 넘는 자동 복구를 끄거나 복구 전 내장 승인 절차를 요구하는 옵션이 없다. 외부 승인 통제는 추가 설계 제안이지 제품 내장 기능이 아니다. 기간이 바뀌기 전에 이상 작업을 조사해야 한다.

기본 알림은 상한의 50%, 80%, 100%에서 결제 관리자와 프로젝트 소유자에게 전송된다. 자동으로 만든 프로젝트에도 실제 담당자가 그 역할에 지정되어 있고 메시지를 받는지 확인해야 한다. 필요한 경우 사용자 지정 역할에 상한 관리 권한을 넣을 수 있지만, 상한을 해제하는 권한은 좁히고 변경 기록을 보존해야 한다. 먼저 비프로덕션 샌드박스에 작은 상한을 설정하고 통제된 부하로 알림, 실시간 보고서, 요청 거절, 월별 초기화를 관찰한다. 정상 작업이 차단됐을 때의 복구 절차와 통제 밖 요금이 계속 발생할 때의 별도 대응 경로도 정해야 한다.

가장 중요한 경계는 Provisioned Throughput이다. 원 발표는 예약 용량을 쓰는 요청이 지출 상한으로 절대 멈추지 않으며 임계값 이후에도 정상 처리된다고 명시한다. 반대로 종량제 요청과 약정 사용 할인이 적용되는 요청은 차단된다. 두 결제 방식을 함께 쓰는 팀은 종량제 요청 하나가 거절됐다는 이유로 총비용이 멈췄다고 판단해서는 안 된다. 예약 용량과 고정 약정을 별도로 목록화하고 청구 보고서 및 계약 관리로 감시해야 한다. 지출 상한은 적용 대상 서비스 요청을 제한하는 장치이며 전체 클라우드 청구서의 절대적인 한도가 아니다.

검증 시 프로젝트, 적용 서비스, API 권한과 알림 수신자를 나열한다. 다음 예산 기간의 자동 초기화와 당기 내 수동 조기 해제, 문서상 조건에서 당기 재발동만 막는 AWAITING_NEXT_PERIOD를 구분한다. 폐기 가능한 환경에서 통제된 사용으로 상한을 발동시키고 시각, 추정 비용, 응답 코드와 후속 청구액을 보존하며 적용 대상 종량제와 실제 사용 중인 Provisioned Throughput 요청을 따로 시험한다. 기간을 넘는 승인 절차를 추가한다면 내장 스위치가 아닌 외부 통제로 별도 검증한다.

정식 출시는 상한의 자동 설정과 발동 원인 조사를 쉽게 만들고, 월별 초기화는 운영상의 재개 결정을 바꾼다. 실제 보호 범위는 서비스 자격과 결제 방식에 달려 있다. API 설정과 요청 결과로 적용 범위를 확인하고, Provisioned Throughput과 계속 발생하는 다른 약정 비용에는 별도의 재무 통제를 적용해야 한다.

Sources

FAQ

지출 상한이 모든 클라우드 요금을 멈춥니까?

아니다. 적용 대상 종량제 요청과 약정 사용 할인 요청은 중단되지만 Provisioned Throughput의 예약 용량 요청은 절대 중단되지 않는다. 예약과 다른 지속 약정은 따로 점검해야 하며, 요청 하나가 거절됐다고 전체 청구액의 절대 상한이 생겼다고 판단하면 안 된다.

상한을 어떻게 설정하고 검증합니까?

프로젝트와 적용 대상 서비스를 확인한 뒤 Cloud Billing Budgets API로 상한을 설정하고 권한 및 알림 수신자를 점검한다. 폐기 가능한 환경에서 통제된 사용을 만들고 발동 시각, 실시간 추정치, 응답 코드를 기록해 나중의 확정 청구액과 비교한다.

월별 자동 초기화는 무엇을 바꿉니까?

API 가이드는 모든 상한이 다음 예산 기간 시작에 CONFIGURED로 자동 초기화되어 차단된 서비스를 다시 연다고 설명한다. 수동 해제는 당기 내 조기 재개다. AWAITING_NEXT_PERIOD로 바꾸면 금액을 올리고 inputState를 CONFIGURED로 재설정하지 않는 한 그 기간에는 다시 발동하지 않는다. 주 블로그는 manual override가 남는다고 말하지만 가이드에는 기간을 넘는 자동 복구를 끄거나 복구 전 내장 승인 절차를 요구하는 옵션이 없다. 외부 승인 통제는 추가 설계 제안이지 제품 내장 기능이 아니다. 기간이 바뀌기 전에 이상 작업을 조사해야 한다.