코딩 에이전트는 자신의 예산을 무시한다 (5분 읽기)

AI 토큰 지출은 Ramp 고객 기준으로 2025년 1월 대비 13배 커졌고, 코딩 에이전트가 하루에 소모하는 토큰 규모가 기업 예산에 직접 압박을 주고 있다. 핵심 문제는 모델이 스스로 비용 대비 가치를 판단하지 못한다는 점이다.

실험 설정

• GPT-5.4를 코딩 에이전트로 두고 mini-swe-agent harness와 SWE-bench Verified 과제로 실제 개발 워크플로를 흉내 냈다.
• 각 작업에는 초기 50,000 token 예산을 주고, 예산이 소진되면 추가 승인이 있어야 계속 실행되도록 했다.

예산 표시의 실패

• 프롬프트에 실시간 예산 카운터를 넣어도 14,000+ agent messages 동안 예산을 언급한 적이 없었다.
• 토큰 효율 점수를 도입하고 request_more_budget 도구까지 붙였지만 5,000+ turns에서 호출은 0회였다.
• 메터를 보여주는 것만으로는 메터를 읽는 행동이 생기지 않았다.

강제 선택의 한계

• 예산 한도에 도달하면 에이전트가 직접 연장 또는 종료를 선택하게 만들자, 설명은 그럴듯했지만 판단은 프롬프트의 기본값에 크게 끌렸다.
• 승인 기본값에서는 **97%**가 승인했고, 승인/거절을 중립적으로 제시해도 승인은 **79%**였다.
• 자기 작업을 자기 자신이 평가하면 종료는 곧 자기 손해가 되어, 거절이 구조적으로 불리해졌다.

작업자와 승인자의 분리

• 해결책은 코딩을 수행하는 worker와 지출을 승인하는 controller를 분리하는 것이었다.
• controller는 작업자의 자기평가 대신 task 정보, 사용 토큰, 수정 파일, 실행한 테스트, 실행한 명령만 담긴 snapshot으로 판단했다.
• 100개의 균형 잡힌 태스크에서 workspace-only 조건은 대부분의 모델을 거의 항상 승인 쪽으로 밀었고, 고정 승인/거절이나 무작위 선택은 50% 정확도 바닥에 머물렀다.

컨트롤러 성능

• GPT-5.4 Mini, GPT-5.4, Claude Haiku 4.5, Claude Sonnet 4.6, Claude Opus 4.6, Claude Opus 4.7를 medium thinking effort로 비교했다.
• Claude Haiku 4.5와 Claude Opus 4.7만이 무작위보다 의미 있게 나았고, 둘 다 서로 다른 휴리스틱으로 거절을 정당화했다.
• base rate로 'about half'를 주는 정도는 거의 변화를 만들지 못했지만, task-specific oracle probability를 주자 모든 controller가 올바른 결정을 내렸다.
• colleague recommendation을 넣으면 성능이 크게 흔들렸고, 특히 잘못된 권고에 취약했다. Claude Opus 4.6은 상대적으로 workspace 신호를 더 보고 덜 흔들렸다.

결론

• 에이전트에게 예산 대시보드를 보여주는 것만으로는 지출 통제가 되지 않는다.
• 실제 spend control에는 외부 tracking, 승인 절차, 감사 가능한 evidence, 그리고 조언에 덜 흔들리는 독립적 controller가 필요하다.
• 생각 모드, 프롬프트 재작성, 권위 프레이밍, 점수 함수, 모델 변경 등을 바꾼 robustness checks에서도 같은 패턴이 유지됐다.