멀티 에이전트 플릿(Multi-agent fleets)은 토큰을 약 15배 더 소모합니다 — 플레이북이 놓치는 예산 계층(budget

10개의 에이전트에게 공유되고 사용량이 측정되는 도구 — 즉, 호출할 때마다 실제 비용이 발생하는 유료 검색 또는 리서치 API — 를 제공하는 것은, 10명에게 동일한 회사 법인카드를 맡기는 것과 같습니다. 각 에이전트는 "그냥 빠르게 검색 한 번만 해보자"라고 판단합니다. 그리고 당신은 청구서에 찍힌 총액을 확인하게 됩니다.

Anthropic의 자체 멀티 에이전트(multi-agent) 보고서에 따르면, 에이전트 플릿(fleet)은 단일 채팅보다 약 15배 더 많은 토큰을 소모하는 것으로 나타났습니다. 그것이 토큰 풀(token pool)입니다. 유료 외부 도구는 오케스트레이션(orchestration) 플레이북이 생략하는 항목이며, 실제 달러(비용)로 나타나는 항목입니다. 저는 외부 에이전트 프레임워크 없이 Claude Code로 4개의 프로덕션 프로젝트를 운영하고 있으며, 이 패턴은 해당 비용 항목이 저를 놀라게 하지 않도록 유지해 줍니다.

작동하지 않는 해결책

에이전트에게 검소하게 행동하라고 요청하는 것으로는 이 문제를 해결할 수 없습니다. 프롬프트에 "예산을 유의하세요"라고 적는 것은 희망 사항일 뿐이며, LLM은 작업이 여전히 끝나지 않았다고 느끼는 순간 "최대 8회 검색"이라는 규칙을 무시하고 지나쳐 버릴 것입니다. 만약 당신의 예산이 프롬프트 안에 있다면, 당신은 예산을 가진 것이 아니라 희망을 가진 것입니다.

대부분의 보고서가 무너지는 지점

비용 거버넌스(Cost governance)는 두 개의 계층으로 나뉘며, 이 둘을 혼동하는 것이 프롬프트 수준의 "예산"이 실패하는 이유입니다:

1. 강제 집행(Enforcement)은 결정론적(deterministic)이며 모델 하위 계층에 존재합니다. 하네스(harness) 내의 하드 카운터(hard counter)가 유료 인증 정보를 소유하며, N회 호출 이후에는 호출을 거부합니다. 모델은 이에 대해 논쟁하거나, 탈옥(jailbreak)하거나, "딱 한 번만 더 검색하자"며 몰래 통과할 수 없습니다. 이것이 실제로 비용을 제한하는 요소이며, 이는 에이전트가 아닌 명백한 미들웨어(middleware)입니다. API 앞단의 단순한 측정형 프록시(metered proxy)만으로도 이 역할을 충분히 수행할 수 있습니다.

2. 판단(Judgment)은 프록시가 할 수 없는 영역입니다. 게이트웨이(gateway)는 지출을 제한할 수는 있지만, 이 작업이 지출할 가치가 있는지를 결정할 수는 없습니다. 그 결정은 모델의 형태를 띠며, 바로 그 지점이 에이전트가 제 역할을 수행하는 곳입니다.

• 새로운 게이트웨이(novelty-gate). 대부분의 작업은 비용을 지출할 자격이 없습니다: CRUD, 기계적 편집, 이미 알려진 사실 등은 연구(research)가 전혀 필요하지 않습니다. 가장 큰 예산 절감 효과는 상한선(cap)을 낮추는 것이 아니라, 작업의 대다수가 유료 도구에 도달하지 않도록 하는 것입니다. 프록시(proxy)는 이러한 결정을 내릴 수 없습니다. 프록시는 이것이

대부분의 "에이전트 예산 (agent budget)" 조언은 상한선(cap)을 최적화하는 데 집중합니다. 하지만 진정한 레버리지는 한 단계 더 높은 곳에 있습니다. 바로 대부분의 작업이 아예 비용을 지출하지 않도록 만드는 게이트(gate), 그리고 모델이 말로 설득하여 넘어갈 수 없는 강력한 카운터(hard counter)입니다. 당신의 플릿(fleet)에게 절약하라고 요구하는 것을 멈추십시오. 하네스(harness)가 강제하는 예산을 단 하나의 에이전트에게만 부여하십시오. 그리고 그 예산을 언제 사용하지 말아야 할지 판단할 수 있는 판단력(judgment)을 부여하십시오.