하드 예산 제한(Hard Budget Caps)은 AI 에이전트를 위한 런타임 안전 장치이다

AI 에이전트는 충돌하거나, 예외를 발생시키거나, 명백히 잘못된 답변을 내보내지 않고도 실패할 수 있다. 그저 유효한 작업을 너무 오랫동안 계속 수행하는 것이다.

이는 대부분의 소프트웨어 팀이 익숙한 종류의 실패 모드와는 다르다. 재시도 루프(retry loop)는 비용이 발생하는 API를 계속 호출할 수 있다. 코딩 에이전트는 테스트 환경을 계속 실행할 수 있다. 백그라운드 워커는 이미지, 임베딩, 로그 또는 스토리지 객체를 계속 생성할 수 있다. 개별적인 모든 행동은 허용될 수 있지만, 전체 실행 과정이 경제적으로 안전하지 않게 될 수 있다.

이것이 하드 예산 제한(hard budget caps)이 단순한 청구 기능이라기보다는 런타임 안전 제어 장치처럼 보이게 만드는 이유이다.

Simon Willison은 지난 10월 3일에 이 문제를 직접 언급했다. 사용량 기반 서비스는 임계값을 넘긴 후 단순히 알림을 보내는 것이 아니라, 작업을 중단시키는 하드 제한이 필요하다. Google Cloud도 Spend Caps를 통해 유사한 방향으로 나아가고 있으며, 이는 설정된 예산을 초과하면 적격 서비스를 일시 중지할 수 있다. 중요한 변화는 아키텍처적인 측면이다: 비용이 단순히 나중에 재무 부서가 검토하는 것이 아니라 소프트웨어가 강제할 수 있는 무언가가 되고 있다는 점이다.

에이전트 시스템의 경우, 이러한 구분은 더욱 중요하다. 왜냐하면 에이전트는 스스로 새로운 작업을 생성할 수 있기 때문이다.

예산 알림(Budget Alert)은 제어 경계가 아니다

전통적인 클라우드 예산은 보통 관찰적이다. 이는 다음과 같은 질문에 답한다:

이 프로젝트는 얼마나 많은 비용을 지출했는가?
지출이 예상 추세를 초과하는가?

이러한 질문들은 유용하지만, 그 어떤 것도 실행 자체를 멈추게 하지는 못한다.

에이전트는 제어 경계(control boundary)가 필요하다. 만약 한 실행 과정이 측정 가능한 리소스의 최대 500단위를 소비하도록 허용된다면, 501번째 단위는 실패해야 한다. 정확한 단위는 API 크레딧, GPU 분, 데이터베이스 쓰기 작업, 브라우저 액션, 토큰 또는 정규화된 내부 비용 점수일 수 있다.

근본적인 구분은 간단하다:

soft budget: 
    observe -> alert -> keep running

...

두 번째 모델은 실행 경로 자체에 속해야 한다.

Google Cloud의 현재 Spend Caps 미리보기는 이 아이디어를 구체화합니다. 문서에 따르면, 설정된 제한(cap)이 적용될 때 적격 서비스 사용을 일시 중지할 수 있으며, 자원은 그대로 유지됩니다. Google은 또한 추정 비용이 관련되어 있어 강제 실행이 즉각적이지 않다고 경고하는데, 이는 중요한 상기 사항입니다. 제공업체 측의 제한은 유용하지만, 애플리케이션 자체는 여전히 더 엄격한 자체 한도를 유지해야 합니다.

에이전트는 작은 실수를 반복적인 행동으로 만듭니다

일반적인 애플리케이션은 비교적 안정적인 요청 형태를 가집니다. 사용자가 버튼을 클릭하고, 작업이 큐에 들어가며, 트래픽이 인식 가능한 패턴 내에서 증가하거나 감소합니다.

에이전트는 피드백 루프를 생성할 수 있습니다.

플래너(planner)가 특정 작업이 실패했다고 결정합니다. 재시도 정책(retry policy)은 또 다른 시도를 만듭니다. 새로운 시도는 브라우저 세션을 시작합니다. 이 브라우저 세션은 이미지 서비스(image service)를 호출합니다. 이미지 서비스의 출력이 유효성 검사에 실패합니다. 플래너는 수정된 프롬프트로 다시 시도하기로 결정합니다. 이 순서에서 아무것도 반드시 잘못된 것은 없습니다.

문제는 곱셈입니다.

하나의 잘못된 결정이 스무 개의 유효한 유료 행동이 될 수 있습니다. 두 번째 복구 규칙은 그 스무 개를 백 개로 만들 수 있습니다. 만약 비용 통제가 이메일 하나에 불과하다면, 아무도 지켜보지 않는 동안 시스템은 계속 작동할 수 있습니다.

이것이 에이전트 예산(agent budget)을 메모리 제한이나 요청 마감 시간처럼 취급해야 하는 이유입니다. 이것은 회계상의 선호 사항이 아닙니다. 지속적인 실행의 조건입니다.

도구 호출 전에 예산 확인을 배치하세요

예산 게이트를 배치하기 가장 안전한 곳은 부수 효과(side-effecting)가 있거나 비용이 측정되는 행동 직전입니다.

간단한 구현으로 정책을 개별 도구 외부에 유지할 수 있습니다:

from dataclasses import dataclass

@dataclass
...

이 예시는 의도적으로 작습니다. 중요한 속성은 순서입니다: 먼저 예약하고, 나중에 실행하는 것입니다.

만약 예산 확인이 도구 호출 이후에 발생한다면, 그것은 단순한 원격 측정(telemetry)일 뿐입니다. 재시도 경로가 래퍼(wrapper)를 우회할 수 있다면, 그것은 하드 캡(hard cap)이 아닙니다. 만약 자식 에이전트가 부모의 예산을 공유하는 대신 새로운 카운터(counter)를 받는다면, 스폰(spawning)은 한계를 벗어나는 방법이 됩니다.

따라서 예산 객체는 인증(authentication), 권한 부여(authorization), 취소(cancellation)와 동일한 아키텍처 수준에 위치해야 합니다.

여러 개의 예산 차원 사용하기

돈만이 제한이 필요한 유일한 자원은 아닙니다.

유용한 에이전트 런타임은 여러 독립적인 차원을 강제할 수 있습니다:

run_budget:
  max_tool_calls: 80
  max_browser_writes: 12
...

이러한 제한들은 서로 다른 문제를 해결합니다.

벽시계 시간 제한(wall-clock limit)은 자원을 많이 소모하지 않으면서 지연되는 작업을 포착합니다. 도구 호출 제한(tool-call limit)은 빠른 루프를 포착합니다. 브라우저 쓰기 제한(browser-write limit)은 외부 계정을 반복적인 부작용으로부터 보호합니다. 재시도 제한(retry limit)은 하나의 실패하는 단계가 전체 실행을 소모하는 것을 방지합니다. 자식 에이전트 제한(child-agent limit)은 재귀적 위임(recursive delegation)이 하나의 작업을 통제되지 않는 트리로 변질되는 것을 막습니다.

이러한 차원들은 독립적이어야 합니다. 왜냐하면 한 실행이 한 차원에서는 안전할 수 있지만 다른 차원에서는 위험할 수 있기 때문입니다.

예를 들어, 저렴한 API라도 여전히 수천 개의 원치 않는 외부 객체를 생성할 수 있습니다. 브라우저 자동화 작업은 인프라 비용으로는 거의 들지 않으면서 반복적으로 데이터를 게시하거나, '좋아요'를 누르거나, 수정할 수 있습니다. 재정적 비용만으로는 실제 실패를 놓칠 것입니다.

사후 회계보다 예약(Reservations)이 더 낫다

많은 측정되는 작업들은 완료될 때까지 최종 비용을 밝히지 않습니다. 이것은 경쟁 상황을 만듭니다: 여러 동시 워커(concurrent workers)들이 모두 남은 예산을 보고 같은 시간에 값비싼 작업을 시작할 수 있습니다.

예약이 이를 해결합니다.

작업을 시작하기 전에 최대치 또는 보수적인 추정치를 예약합니다. 작업이 완료된 후에는 실제 사용량과 예약을 조정(reconcile)합니다.

class Ledger:
    def __init__(self, limit):
        self.limit = limit
...

프로덕션 구현은 원자적 저장소(atomic storage)가 필요하지만, 중요한 것은 모델입니다. 동시성 때문에 예산이 무료로 생성되어서는 안 됩니다.

이는 재고 시스템과 유사합니다. 두 구매자가 모두 마지막 상품을 구매할 수 있는 것은 아닙니다. 왜냐하면 둘 다 쓰기(write)가 완료되기 전에 동일한 재고 수량을 읽었기 때문입니다. 마찬가지로, 두 에이전트가 동시에 남은 할당량(allowance)을 확인했기 때문에 같은 잔여 할당량을 모두 소진해서는 안 됩니다.

Provider 캡과 Application 캡은 서로 다른 문제를 해결한다

Provider 측 제한(Provider-side limits)은 애플리케이션 외부의 것이므로 가치가 높습니다. 만약 애플리케이션에 버그가 있어도, 제공업체는 여전히 추가적인 청구 사용을 중단할 수 있습니다.

애플리케이션 측 제한(Application-side limits)은 의도를 이해하기 때문에 가치가 높습니다.

클라우드 제공업체는 요청(requests)을 봅니다. 반면, 귀하의 런타임은 작업(tasks), 사용자(users), 세션(sessions), 도구(tools), 재시도(retries), 그리고 부수 효과(side effects)를 봅니다.

이는 계층적 설계(layered design)가 필요함을 시사합니다:

Provider 캡은 최악의 경우 계정 노출을 제한합니다.
Project 캡은 하나의 애플리케이션을 제한합니다.
User 캡은 하나의 테넌트 또는 운영자를 제한합니다.
Run 캡은 하나의 에이전트 실행을 제한합니다.
Step 캡은 하나의 워크플로우 내의 재시도와 부수 효과를 제한합니다.

Google Cloud의 Spend Caps는 적격 서비스에 대한 첫 두 계층의 예입니다. 이 기능은 설정된 임계값(threshold)에 도달한 후 사용을 일시 중지할 수 있으며, Google은 또한 캡 아래의 경고 지점들을 문서화합니다. 하지만 에이전트 런타임은 요청이 재시도 폭주(retry storm)의 일부인지 아니면 합법적인 새 작업인지를 알기 때문에 더 일찍 작동할 수 있습니다.

두 제어 장치는 경쟁하기보다는 서로를 강화해야 합니다.

예산 소진은 정상적인 종료 상태여야 한다

많은 에이전트 시스템들은 중단된 모든 작업을 오류로 간주하고 또 다른 시도를 할 가치가 있다고 여깁니다. 이는 중단 자체가 예산 시스템이 제 역할을 수행하는 것일 때 위험합니다.

예산 소진(Budget exhaustion)은 일급 시민 종료 상태(first-class terminal state)가 되어야 합니다:

SUCCESS
FAILURE
BLOCKED
...

BUDGET_EXHAUSTED를 수신하는 스케줄러는 새로운 할당량으로 동일한 계획을 자동으로 재시도해서는 안 됩니다. 그렇게 하면 예산이 경계(boundary)가 아니라 지연(delay)이 되어버립니다.

최종 기록에는 무슨 일이 일어났는지 설명할 충분한 증거가 포함되어야 합니다:

설정된 제한(configured limit);
소비된 양(consumed amount);
마지막 성공 단계(last successful step);
거부된 액션(action that was denied);
재시도 횟수(retry counts);
하위 실행(child runs);
이미 완료된 외부 부작용(external side effects already completed).

이로써 복구 과정이 명확해집니다. 인간이나 상위 레벨의 정책은 더 많은 예산을 부여하거나, 범위를 축소하거나, 영구적으로 중단하는 것을 선택할 수 있습니다.

재시도에는 자체적인 경제성이 필요하다

재시도는 제한을 실수로 무력화시키는 가장 쉬운 방법 중 하나입니다.

예를 들어, 이미지 생성 단계가 품질 검증에 실패했다고 가정해 봅시다. 시스템은 합리적으로 두 번째 프롬프트를 시도할 수 있습니다. 하지만 각 재시도가 원래의 전체 실행 허용량을 받는다면, 비용 모델 자체가 비현실적입니다.

재시도는 동일한 상위 예산에서 지출되어야 하며, 일반적으로 시도가 누적됨에 따라 더 엄격해져야 합니다.

유용한 정책 중 하나는 다음과 같습니다:

retry_limits = {
    "network_timeout": 2,
    "rate_limit": 1,
...

중요한 부분은 정확한 숫자가 아닙니다. 재시도 권한이 실패 클래스에 기반하며, 모든 재시도는 여전히 원래의 실행 예산을 소모한다는 점입니다.

이는 행동 품질을 향상시키기도 합니다. 남은 시도가 하나라는 것을 아는 에이전트는 무기한으로 계속 시도할 수 있는 에이전트보다 행동하기 전에 증거를 수집할 가능성이 더 높습니다.

하드 캡(Hard Cap)은 상태를 파괴하지 않고 안전하게 실패해야 한다

지출 중단이 작업의 파괴를 의미해서는 안 됩니다.

Google Cloud는 자체 Spend Caps를 비파괴적(non-destructive)이라고 명시하며, 적격 사용량은 데이터와 리소스가 유지되는 동안 일시 중지될 수 있습니다. 에이전트 런타임도 같은 원칙을 따라야 합니다.

하드 캡에 도달했을 때:

새로운 측정 액션(metered actions)의 실행을 중단하고;
로그와 영수증은 보존하며;
이미 생성된 초안이나 아티팩트는 유지하고;
검증된 외부 부작용을 맹목적으로 롤백하지 않으며;
정확한 계속 지점(continuation point)을 기록하고;
재개하기 전에 명시적인 새로운 허용량(new allowance)을 요구해야 합니다.

이는 일회성 시스템이 아닌 재개 가능한(resumable) 시스템을 만듭니다.

또한, 자주 혼동되는 두 가지 관심사—새로운 위험 중단과 오래된 상태 정리—를 분리합니다. 전자는 즉시 발생해야 하며, 후자는 신중하고 증거 기반이어야 합니다.

예산 정책은 프롬프트가 아닌 런타임에 속해야 한다

프롬프트는 에이전트에게 절약하도록 지시할 수 있다. 하지만 그것은 강제가 아니다.

프롬프트는 결정에 영향을 미친다. 반면, 런타임 게이트(Runtime gates)는 행동을 제약한다.

가장 안전한 아키텍처는 모델이 제한 사항을 오해하거나, 컨텍스트 압축 후 그것을 잊거나, 다른 프로세스에 위임하거나, 비용 추정치가 잘못된 계획을 선택할 수 있다고 가정한다. 하드 예산(hard budget)은 여전히 유지되어야 한다.

이는 정책이 모델 루프 외부에서 존재해야 함을 의미한다:

model proposes action
        |
        v
...

모델은 비용을 추정하고 더 저렴한 계획을 선택함으로써 참여할 수 있지만, 그 행동이 허용되는지에 대한 최종 권한을 가져서는 안 된다.

비용이 정확성의 일부가 되어가고 있다

더 넓은 교훈은 자율 소프트웨어의 '정확성(correctness)' 자체가 변했다는 것이다.

어떤 작업이 단순히 요청된 출력에 도달하는 것만으로는 정확하지 않다. 그 과정에서 시간, 외부 쓰기(external writes), 재시도(retries), 권한, 그리고 지출(spend)과 같은 제한 사항을 존중해야 한다.

이것이 현재 실제 지출 상한선(real spend caps)으로의 추진이 중요한 이유이다. Simon Willison이 기본 하드 제한(default hard limits)에 대해 제시한 주장은 단순한 청구서 권고를 넘어선다. 이는 에이전트 시스템을 위한 런타임 설계 원칙을 가리킨다. 즉, 모든 자율 루프는 인프라가 중단시키기 전에 허용되는 최대 피해 금액(maximum amount of damage)을 가져야 한다는 것이다.

Google Cloud의 2026년 7월 지출 상한선 미리보기(Spend Caps preview)는 클라우드 플랫폼들이 이 제어 기능을 청구 계층(billing layer)에서 노출하기 시작했음을 보여준다. 에이전트 프레임워크들은 모든 제공업체가 같은 일을 할 때까지 기다려서는 안 된다.

신뢰할 수 있는 에이전트는 자신이 얼마를 지출할 수 있는지 알아야 하고, 행동하기 전에 그 용량을 예약해야 하며, 재시도와 자식 작업(child workers) 전반에 걸쳐 동일한 원장(ledger)을 공유하고, 할당량이 소진되면 깔끔하게 멈춰야 한다.

이것은 자율 시스템에 대한 비관론이 아니다. 이것은 무인 실행(unattended execution)을 실용적으로 만드는 메커니즘이다.

출처:

원래 Dispatch에 게시됨.