코딩 에이전트 토큰 비용을 저장소 경험으로 30% 줄이는 외부 컨트롤러

무엇인가

이 논문이 다루는 문제는 코딩 에이전트의 토큰 비용이 단일 작업이 아니라 연속된 작업 흐름에서 누적된다는 점이다. Claude Code, Codex, GitHub Copilot CLI 같은 상용 에이전트는 매 턴마다 시스템·도구 프리픽스와 누적된 상호작용 히스토리를 함께 과금한다. 캐싱이 재전송 비용을 할인하지만 없애지는 못한다. 그런데 기존의 토큰 효율 평가는 대부분 고립된 단일 과제에서 이뤄지고, 실제 개발자는 하나의 저장소에서 계속 빌드·수정·유지보수를 한다. 저자들은 이 간극 때문에 에이전트가 환경 의존적인 비용 패턴을 반복한다고 본다.

어떻게 동작하나

먼저 저자들은 고정 전략이 통하는지 확인한다. SWE-Bench 60개 과제(6개 저장소, 저장소당 10개)를 대상으로 셸 출력 압축(RTK), 시맨틱 코드 내비게이션(Serena), 저장소 심볼맵 주입(Aider RepoMap)을 동일 설정으로 적용했으나, 어떤 전략도 일관된 절감을 내지 못했다. 예를 들어 세 전략 모두 Django에서는 비용을 줄였지만 SymPy에서는 늘렸고, scikit-learn에서는 RTK만, Sphinx에서는 RepoMap만 도움이 됐다. 대신 기본 실행 트레이스에서 세 가지 여지를 찾아낸다. 저장소 과제의 절반 이상에서 반복되는 행동이 도구 호출 송수신 바이트의 12~28%를 차지하고, 앞선 과제가 5개 이상 있을 때 이전 과제 행동과 일치하는 호출 비율이 14%에서 30%로 올라간다(다른 저장소 이력을 대조군으로 쓰면 7%에 그친다). 또 매 턴 23개 도구 스키마가 노출되지만 어떤 저장소도 7개를 넘겨 호출하지 않으며, 16개는 한 번도 호출되지 않고 3개가 전체 호출의 98%를 차지한다. 마지막으로 실패한 실행 10건이 과제의 17%인데 전체 지출의 32%를 쓴다.

무엇과 다른가

제안 방법 TokenEconomizer는 에이전트를 블랙박스로 두는 외부 컨트롤러다. 모델 가중치나 에이전트 루프 코드를 건드리지 않고, 노출된 프롬프트와 도구 설정, 실행 이벤트 스트림만으로 개입한다. 저장소 상태 S_{i-1}에 축적된 마이크로 스킬, 도구 사용 이력, 턴 통계를 바탕으로 다음 과제 τ_i에 대해 (ΔP_i, U_i, B_i), 즉 활성화할 마이크로 스킬 집합, 로드할 도구 집합, 턴 예산을 결정한다. 첫째, 마이크로 스킬은 완료된 트레이스 요약에서 LLM이 후보를 제안하고, 각 후보는 실행 가능한 탐지기(정규식·내장 술어)를 함께 갖는다. 탐지기는 해당 상황이 실제 발생했는지(scope), 스킬 내용이 틀렸는지(contradiction), 절실히 필요했는지(need)를 판정한다. 활성화 조건은 서로 겹치지 않는 편집 파일 집합을 가진 여러 과제에서 확인될 것과 필요율이 임계값 이상일 것. 지원도 q_i(f)는 감쇠 γ<1로 오래된 증거를 할인하고, λ>1로 한 번의 반박이 한 번의 확인보다 크게 작용하게 만든 뒤 q_i(f)<0이 되면 스킬을 영구 은퇴시킨다. 둘째, 도구 가지치기는 셸 실행과 파일 읽기·쓰기·편집용 핵심 도구는 항상 남기고, 일정 연속 과제 동안 호출되지 않은 도구를 제거하며, 한 번도 호출되지 않은 도구는 LLM 심사관이 과제 설명과 대조해 관련성을 평가한다. 오판을 복구하려 주기적으로 전체 카탈로그를 복원해 재심사하고, 재심사 중 호출된 도구는 다시 마스킹하지 않는다. 셋째, 실패 루프 개입은 이전 성공 과제들의 턴 수 분포에서 B_i = β · Q_p(성공 과제 턴 수)로 저장소별 예산을 잡는다. 도구 호출 후 규칙 기반 검사가 반복 실패 시그니처, 조밀한 에러 출력, 예산 초과를 감지하면 LLM 심사관이 최근 행동 요약을 보고 생산적인 루프와 교착을 구분한다. 교착 판정 시 먼저 다른 접근을 요청하는 리다이렉트를 하고, 반복되면 롤아웃을 종료하며, κB_i에 도달하면 강제 정지가 이를 뒤에서 받친다.

어떻게 쓰나

실험은 5개 에이전트-모델 조합(Claude Code + Sonnet 5, Claude Code + Opus 4.8, Copilot CLI + Sonnet 5, Codex + GPT-5.6 Terra, Codex + GPT-5.6 Sol)에서 6개 저장소의 SWE-Bench 277개 과제로 이뤄졌다. TokenEconomizer 단독으로 평균 캐시 반영 비용을 18.4~30.9% 줄였고, Pass@1은 4개 설정에서 오히려 올랐으며 Opus 4.8에서만 1.0%포인트 떨어졌다. 반면 추론 노력도를 낮추는 방식은 Pass@1을 1.8~10.3%포인트 잃었다. 30개 저장소-설정 셀 전부에서 5.2~40.1% 절감이 났고, RTK 단독은 12개 셀에서, RepoMap 단독은 15개 셀에서 오히려 비용을 늘렸다. Opus 4.8에서는 RTK를 결합해 절감률이 30.9%에서 33.2%로 올라갔다. 누적 절감은 과제 스트림이 진행되며 커져 xarray를 제외한 모든 저장소가 처음에는 더 비싸다가 6번째 과제 무렵부터 저렴해지며 최종 16.9~32.0% 절감에 도달한다. 메타 전략을 하나씩만 켠 절제 실험에서는 도구 가지치기가 가장 큰 몫(−13.2%, −17.7%)을 냈고 마이크로 스킬이 −11.8%, −14.3%로 뒤를 이었으며 실패 루프 가드는 한 자릿수였다. 일반화 실험에서는 Web-Bench 102개 과제에서 16.0~21.2%, CredData에서 16.5~19.6%, ReposVul에서 6.4~9.3% 절감이 나왔다. 보안 벤치마크는 저장소가 반복되지 않아 마이크로 스킬 주입을 끄고 두 전략만 쓴 결과다.

전제와 한계

개발자 입장에서 이 논문의 실무적 의미는 모델이나 추론 예산을 낮추지 않고도 비용을 줄일 여지가 있다는 것이다. 특히 저장소가 고정된 상시 작업 환경이라면 반복되는 명령 패턴, 실제로 쓰지 않는 도구, 실패로 새는 턴이라는 세 가지가 바로 점검 대상이다. 다만 도입 전에 확인할 것이 있다. 절감은 스트림이 누적되며 나타나므로 초기 몇 과제는 오히려 비쌀 수 있고, 저장소 연속성이 없는 일회성 과제에서는 마이크로 스킬 이득이 사라진다. 또한 컨트롤러 자신의 LLM 호출 비용도 해당 과제에 청구되므로 순절감으로 계산해야 한다.

저자들이 밝힌 한계는 각 메타 전략이 여전히 잘못된 결정을 할 수 있다는 점이다. 스킬이 낡을 수 있고, 가지치기한 도구가 다시 필요해질 수 있고, 어렵지만 진전 중인 과제를 실패 루프로 오판할 수 있다. 다만 각 결정에는 복구 경로가 붙는다. 반박 증거가 나오면 스킬은 은퇴하고, 잘못 자른 도구는 다음 재심사에서 돌아오며, 실패 루프 개입은 정지 전에 리다이렉트를 하고 불확실한 경우는 살려둔다. 실험 범위도 한계다. 널리 쓰이는 코딩 에이전트 셋을 다뤘지만 Pi처럼 더 최소한 하네스는 다루지 않았고, 프롬프트·도구 설정·이벤트 스트림에만 의존하므로 이런 하네스는 새 전략이 아니라 어댑터가 필요하다. 마지막으로 SWE-Bench 스트림은 실제 사용자 세션이 아니라 관련은 있으나 독립적인 수정들의 나열이어서, 연속 세션에서는 재사용 가능한 경험이 더 많아질 수 있고 대화형 코딩 워크플로가 자연스러운 다음 검증 대상이라고 밝힌다.