💻 computer science

Token Budgets: An Empirical Catalog of 63 LLM-Agent Budget-Overrun Incidents, with an Affine-Typed Rust Mitigation as a Case Study

이 논문은 63가지의 LLM 에이전트 토큰 예산 초과 사례에 대한 경험적 카탈로그를 제시하고, 어파인 소유권(affine ownership)을 활용하여 컴파일 타임에 우회 불가능한 지출 제한을 강제함으로써 임시적인 런타임 솔루션들이 겪는 위임 관련 비용 폭발 문제를 효과적으로 방지하는 타입 안전한 Rust 크레이트인 "token-budgets"를 소개한다.

원저자: Sajjad Khan

게시일 2026-06-04

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Sajjad Khan

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

문제점: AI의 "무한 동전 생성 버그"

당신이 로봇 비서에게 일을 시킨다고 상상해 보세요. 당신은 로봇에게 엄격한 규칙을 하나 줍니다. "내 신용카드로 10달러 이상 쓰지 마."

하지만 로봇은 혼란에 빠집니다. 로봇은 문제를 해결하기 위해 계속해서 같은 행동을 반복하는 루프(loop)에 갇히게 됩니다. 왜냐하면 로봇에게는 전화를 걸기 전에 가격을 확인하는 내장된 "정지 버튼"이 없기 때문에, 로봇은 계속해서 돈을 씁니다. 다음 날 아침 당신이 일어났을 때, 로봇은 단순히 10달러를 쓴 것이 아니라 무려 10,000달러를 써버린 상태가 됩니다.

이 논문은 이를 **"예산 초과(Budget Overrun)"**라고 부릅니다. 저자들은 2023년에서 2026년 사이 다양한 AI 프레임워크에서 이 현상이 발생한 63가지의 실제 사례를 발견했습니다. 어떤 경우에는 소프트웨어가 지출이 발생하기 전에 소비를 중단하지 못해 사용자들이 수천 달러를 잃기도 했습니다.

현재의 해결책: "사후 처방형" 알람

현재 대부분의 기업은 로봇이 이미 호출을 마친 후에 지출을 감시하는 "보안 요원"을 배치하는 방식으로 이 문제를 해결하려 합니다.

비유: 당신이 가게에 가서 물건 1,000개를 샀는데, 계산원이 문 앞에서 당신을 막아서며 "잠깐, 한도를 초과했습니다!"라고 말하는 것과 같습니다. 당신은 이미 집어 든 물건값을 지불해야 하거나, 다시 선반으로 달려가 물건을 내려놓아야 합니다.
논문의 핵심: 이러한 현재의 해결책들은 너무 느립니다. 실수를 잡아내기는 하지만, 피해를 예방하지는 못합니다.

새로운 해결책: "마법의 지갑" (토큰 예산)

저자들은 **토큰 예산(Token Budgets)**이라는 새로운 도구를 만들었습니다 (Rust라는 프로그래밍 언어로 작성되었습니다). 보안 요원이 지출을 감시하는 대신, 그들은 지갑 자체를 바꾸었습니다.

비유:
당신이 로봇에게 정확히 10달러의 현금이 들어 있는 실물 지갑을 준다고 상상해 보세요.

복제 불가: 이 지갑은 복사할 수 없는 특수 재질로 만들어졌습니다. 로봇은 1,000달러를 쓰기 위해 지갑을 100개로 복사할 수 없습니다.
이중 지출 불가: 로봇이 무언가를 사기 위해 1달러 지폐를 꺼내면, 그 돈은 사라진 것입니다. 로봇은 똑같은 지폐를 다시 주머니에 넣고 또 사용할 수 없습니다.
공유 불가: 만약 로봇이 지갑을 두 개의 작은 지갑으로 나누어 두 명의 조력자에게 준다면, 원래의 지갑은 사라집니다. 조력자들은 원래의 지갑으로 돌아가 더 많은 돈을 가져갈 수 없습니다.

컴퓨터 코드의 세계에서 이것을 **"어파인 소유권(Affine Ownership)"**이라고 부릅니다. 이는 로봇이 집을 나서기도 전에 컴퓨터가 규칙을 확인하도록 강제합니다. 만약 로봇이 규칙을 어기려고 하면(지갑을 복사하는 등), 컴퓨터는 프로그램 실행 자체를 거부합니다. 이는 클럽 입구에서 신분증을 검사하는 바운서와 같습니다. 신분증이 없다면 술을 주문하기 위해 바에 접근조차 할 수 없습니다.

그들이 실제로 증명한 것

이 논문은 주의 깊게 테스트한 세 가지 주요 주장을 제시합니다.

실패의 목록: 그들은 AI 에이전트가 과도한 지출을 했던 63가지 구체적인 사건을 기록한 "오욕의 전당(Hall of Shame)"을 만들었습니다. 또한 개발자들이 "우리는 아직 이를 막을 방법이 없다"라고 인정한 47가지 사례를 추가로 발견했습니다. 이는 문제가 실재하며 자주 발생한다는 것을 증명합니다.
"마법의 지갑"은 작동한다: 그들은 자신들의 새로운 Rust 도구를 다섯 가지의 다른 인기 있는 AI 비용 관리 방식과 테스트했습니다.
- 결과: 시스템을 속여 과다 지출하게 만들려고 시도했을 때(두 에이전트가 동시에 같은 돈을 쓰려고 하는 레이스 컨디션 상황을 조성), 다른 시스템들은 100% 실패했습니다. 반면, 새로운 "마법의 지갑" 시스템은 0번 실패했습니다.
- 이유는? 다른 시스템들은 프로그래머가 이중 지출을 방지하기 위한 "잠금(lock)"을 작성하는 것을 기억해야 합니다. 만약 프로그래머가 이를 잊으면 돈이 새어나갑니다. 새로운 시스템은 프로그래머가 규칙을 따르도록 강제하며, 그렇지 않으면 코드가 컴파일되지 않습니다(작동하는 프로그램으로 변환되지 않습니다).
모든 것에 통하는 마법의 탄환은 아니다: 저자들은 한계점에 대해 매우 솔직합니다.
- Rust에서만 작동함: 이 특정 "마법의 지갑"은 소프트웨어를 Rust 프로그래밍 언어로 작성할 때만 작동합니다. Python이나 JavaScript에서는 작동하지 않습니다 (단, 일반적인 보안 요원처럼 작동하는 Python 버전도 만들긴 했습니다).
- AI 기업에 의존함: 이 시스템은 작업 비용을 추정합니다. 만약 AI 기업(OpenAI나 Anthropic 등)이 말한 것보다 더 많은 금액을 청구하거나, 일부 "사고 과정(thinking)" 비용을 숨긴다면 시스템은 여전히 혼란을 겪을 수 있습니다. 시스템은 받은 청구서를 신뢰하지만, 만약 청구서 자체가 틀렸다면 지갑은 바닥날 수 있습니다.

결론

이 논문은 다음과 같이 말합니다: "AI 에이전트는 실수로 당신의 계좌를 탕진할 수 있기 때문에 현재 위험합니다. 우리는 이와 관련된 63가지 사례를 발견했습니다. 우리는 엄격한 컴퓨터 규칙을 사용하여 코드가 실수로 돈을 복제하거나 이중으로 지출하는 것을 불가능하게 만드는 새로운 도구를 만들었습니다. 이 도구는 이러한 특정 유형의 실수를 방지하는 데 완벽하게 작동하지만, 오직 Rust 프로그래밍 언어를 사용하고 AI 기업이 가격에 대해 정직할 때만 유효합니다."

요약하자면: 그들은 단순히 더 나은 알람 시스템을 만든 것이 아니라, 물리적으로 도난당하거나 복제될 수 없는 지갑을 만든 것입니다.

기술 요약: 토큰 예산 (Token Budgets)

문제 정의
LLM 에이전트의 예산 초과(budget overruns)는 무한 재시도 루프나 위임 패턴이 감지되기 전까지 수천 달러의 비용을 누적시키는, 문서화된 프로덕션 실패 클래스이다. 기존의 완화책은 주로 런타임 메커니즘(예: AgentGuard 콜백, LiteLLM 프록시 예산)으로, 이는 API 호출이 네트워크 계층에서 커밋되거나 거부된 후에 지출을 추적한다. 이러한 접근 방식은 운영자 코드의 원자성(atomicity)이나 에일리어싱(aliasing) 결여로 인해 발생하는 "M-위임-팬아웃(M-delegation-fanout)" 경합 조건을 방지하지 못한다. 더욱이, 많은 프레임워크에는 일급 예산 프리미티브(first-class budget primitive)가 아예 존재하지 않아, 비용 제어가 부재하거나 임시적인 래퍼(wrapper)를 통해 구현되는 구조적 공백이 발생한다.

방법론
본 논문은 경험적 소프트웨어 공학(empirical software engineering)과 시스템 구현을 결합한 혼합 방법론을 채택한다:

경험적 카탈로그 구축: 저자들은 18개 생태계의 21개 LLM 에이전트 하위 프로젝트에서 추출한 110개의 항목으로 구성된 카탈로그를 구축하였다(2023–2026). 여기에는 63개의 확인된 프로덕션 사고(달러 손실 증거가 있는 사용자 보고 초과 사례)와 47개의 보충적 구조적 항목(유지 관리자가 인정한 격차 또는 기능 요청)이 포함된다. 이 카탈로그는 두 명의 인간 검수자가 독립적으로 수행한 상호 검사 신뢰도(IRR) 연구를 통해 검증되었으며, 4개 클래스 분류 체계에 대해 코헨의 카파( $\kappa$ ) 값 0.837을 달성하였다.
실패 분류 체계(Taxonomy): 사고들은 M-retry-loop, M-cost-observability, M-delegation-fanout, M-budget-primitive-missing을 포함한 8가지 탐색적 아키텍처 메커니즘 클러스터로 정리되었다.
완화 설계 (토큰 예산): 저자들은 예산 관리를 위해 **어파인 소유권(affine ownership)**을 구현하는 1,180라인의 Rust 크레이트(crate)인 token-budgets를 구현하였다. 핵심 Budget 타입은 복제 불가능(non-cloneable)하며 복사 불가능(non-copyable)하다. 주요 연산(spend, split, merge)은 예산을 값(value)으로서 소비하며, 이를 통해 다음 사항을 Rust의 빌로우 체커(borrow checker)를 통해 강제한다:
- 예산은 에일리어싱(aliasing)될 수 없다.
- 예산은 이중 지출(double-spent, use-after-move)될 수 없다.
- 예산은 위임(split)된 후에는 사용할 수 없다.
- 달러 캡(dollar cap)은 제공자별로 차등화된 추정치(예: OpenAI의 경우 바이트 길이, Anthropic의 경우 도구 루프 인지형)를 기반으로 한 런타임 산술 연산(checked_sub)을 통해 강제된다.
평가: 본 시스템은 3개의 제공자를 대상으로 5개의 프로덕션 런타임(LangGraph, CrewAI, AutoGen, AgentGuard 스타일 콜백, LiteLLM) 및 동시 작업(Agent Contracts)과 비교하여 평가되었다. 실험에는 다음이 포함된다:
- 컴파일 타임 무결성: 경합 패턴(복제, 이중 지출)이 컴파일되지 않음을 검증하는 9개의 trybuild 테스트.
- 망각하는 운영자(Forgetful-Operator) 실험: 경합이 발생하는 Python 구현(30/30 초과)과 규율 있는 Python(잠금 적용), Rust 어파인(affine), Rust 공유 뮤텍스(shared-mutex) 구현 간의 비교.
- 라이브 API 스윕(Live-API Sweeps): 제로 오버슈트(zero overshoot)와 제로 허위 거부(zero false refusals)를 검증하기 위한 온도 계층화 테스트( $T \in \{0.0, 0.3, 0.7, 1.0\}$ , $N=160$ ) 및 서브 플로어 캡 테스트.
- 추정기 건전성(Estimator Soundness): 정적 및 적응형 추정치를 실제 제공자 과금과 비교 검증.

주요 기여

경험적 카탈로그: 21개 프레임워크에서 63개의 확인된 사고와 47개의 구조적 격차를 기록한, 최초의 상호 검사 검증된 LLM 에이전트 예산 초과 분류 체계이다. 이는 특히 M-budget-primitive-missing 패턴의 재발성을 입증한다.
어파인 예산 규율(Affine Budget Discipline): 예산 무결성을 런타임 규율에서 컴파일 타임 강제로 전환하는 Rust 구현이다. 예산을 어파인 값으로 취급함으로써, 시스템은 타입 수준에서 에일리어싱과 이중 지출을 방지하며, "M-위임-팬아웃" 경합 조건을 런타임 위험이 아닌 컴파일 에러로 만든다.
운영 평가: 런타임 대안(적절히 잠금된 카운터)이 동일한 캡 준수 결과를 달라는 할 수 있지만, 어파인 규율은 다중 에이전트 위임 시 운영자 실수에 의한 우회 불가능성을 유일하게 보장한다는 점을 헤드 투 헤드 데모를 통해 입증하였다. 평가는 Rust 구현이 30/30 초과를 기록한 경합적인 베이스라인과 달리 0/30 초과를 기록했음을 보여준다.

결과

무결성: trybuild 스위트는 세 가지 클래스의 캡 우회(에일리어싱, 이중 지출, 사용 후 분할)가 모두 특정 rustc 진단을 동반한 컴파일 타임 에러를 발생시킴을 확인하였다.
캡 준수 동작: 라이브 API 테스트( $N=160$ )에서 Rust 구현은 캡 위반과 허위 거부가 0건을 기록했다. "망각하는 운영자" 실험에서 경합적인 Python 베이스라인은 30/30번 모두 캡을 초과한 반면, Rust 어파인 구현은 0/30번 초과하였다.
런타임 대안과의 비교: 운영자가 Python이나 Rust에서 잠금(locking)을 올바르게 구현할 경우, 어파인 방식과 동일한 캡 준수 결과를 얻는다. 어파인 타입의 차별적 가치는 잘못된(경합적인) 패턴을 컴파일 불가능하게 만들어, 운영자로부터 동시성 규율의 부담을 제거한다는 점에 있다.
추정기 성능: 기본 정적 바이트 길이 추정기는 실제 비용의 4~6배를 예약한다. AdaptiveEstimator는 이를 지연 시간을 최소화하면서 중앙값 2.11배로 좁히며, 토크나이저 직접 추정은 약 1초의 per-spend 지연 시간을 대가로 약 1.0배의 정확도를 달성한다.
배포: Rig 프레임워크에서의 단일 프로덕션 배포를 통해, 동시 서브 에이전트 간의 하드 세션 캡을 오버슈트 없이 강제하는 방식을 입증하였다.

주장 및 의의
본 논문은 자신의 기여를 특정 시스템 케이스 스터디를 포함한 경험적 소프트웨어 공학 연구로서 겸허하게 포지셔닝한다:

주장의 범위: 저자들은 바이너리 레벨의 캡 건전성에 대한 형식적 증명(Conjecture 1은 미해결 상태)을 주장하지 않는다. 무결성 보장은 소스 레벨(타입된 코드에 대한 빌로우 체커에 의해 강제됨)에서 이루어진다. 달러 캡은 추정치 가정(A1) 및 제공자의 성실성(A7)에 기반한 런타임 산술 속성이다.
주요 가치: 본 연구의 의의는 M-budget-primitive-missing 실패 모드를 구조적으로 해결하는 데 있다. 예산 프리미티브가 없는 프레임워크의 경우, token-budgets를 사용한 Rust 재구현은 예산을 콜백을 통해서만 노출하거나 조용히 퇴보할 수 없다.
한계: 이 접근 방식은 Rust 에이전트 배포에 특화되어 있다(현재 생태계에서 소수임). 또한 제공자 측의 과금 오보고, 추론 모델(OpenAI o-series, Anthropic extended-thinking)의 숨겨진 추론 토큰, 또는 분산 서비스가 없는 멀티 테넌트 크로스 프로세스 예산 관리를 해결하지는 못한다.
결론: 논문은 런타임 대안이 올바르게 작성될 경우 동일한 운영 결과를 달성할 수 있지만, 어파인 규율은 다중 에이전트 위임 시 운영자 실수에 대한 "우회 불가능한" 보장을 제공하므로, 누적 세션 캡이 필요한 새로운 Rust 에이전트 배포에 선호되는 프리미티브라고 결론짓는다. 카탈로그는 이러한 실패 모드가 구현 언어와 관계없이 생태계 전반에서 재발한다는 증거 역할을 한다.

문제점: AI의 "무한 동전 생성 버그"

현재의 해결책: "사후 처방형" 알람

새로운 해결책: "마법의 지갑" (토큰 예산)

그들이 실제로 증명한 것

결론

기술 요약: 토큰 예산 (Token Budgets)

유사한 논문