'Eco Mode' AI 코딩 에이전트 가격 책정 대 토큰 소모. 테스트 실행을 위해 프론티어 모델을 사용하는 것이 낭비인가? (+벤치마크)

최근 자율 코딩 에이전트의 원본 단계 로그를 확인했는데, 단위 경제학(unit economics) 측면에서 볼 때 매우 터무니없다는 생각이 들었습니다. 그래서 한 에이전트가 다중 모듈 레포지토리(multi-module repo)에서 평범한 버그 수정 작업을 수행하는 것을 지켜보았습니다. 에이전트는 이 문제를 해결했지만, 이 작업만으로 거의 $5에 가까운 토큰을 소모했습니다. 실제로 툴 호출 추적(tool-call trace)을 분석해 보니, 토큰은 다음과 같은 곳에 사용되었습니다: 단계 1–12 (거의 $1.10): 프로젝트 검색, 의존성 추적, 결함 로직 위치 파악, 수정 방법 결정. 단계 13–42 (거의 $3.80): 두 파일 편집, 빌드 실행, 누락된 import 포착, 타입 에러 수정, 테스트 재실행, 어설션(assertion) 조정, 테스트 재실행. 토큰 비용의 70% 이상이 프론티어 모델(frontier model)이 컴파일러 출력(compiler output)을 감시하고 테스트를 재실행하는 데 사용되었습니다. 라이너(linter)나 빠른 모델이 잠자는 동안 할 수 있는 작업에 대해 최고 수준의 프론티어 요금(Opus 5.5, Grok 4.7 등)을 지불하고 있는 것입니다.

그리고 코딩 에이전트 전반에 걸친 가격 책정/크레딧 소모에 대한 많은 불만 뒤에 숨겨진 또 다른 (꽤 큰!) 문제가 있습니다. 저는 동료들이 할당량이 너무 빨리 소진된다고 느낀다는 것을 알게 되었습니다(모델 자체가 나쁘기 때문이라기보다는, 단일 모델 에이전트가 못 쓰는 망치로 못을 박으려는 것처럼 과도하게 사용하기 때문일 수 있습니다). 저는 종종 JetBrains 인프라와 Kotlin으로 작업하며, 어제 그들이 새로운 Junie Eco Mode에 대한 엔지니어링 분석 및 내부 벤치마크를 발표했다는 것을 알게 되었습니다(Junie CLI 26.10.20 및 JetBrains Air / IDE Betas에서 GA 출시). 이 단위 경제학 문제에 대한 접근 방식은 살펴볼 가치가 있는 것 같습니다. 여기서는 처음부터 끝까지 하나의 모델을 실행하는 것이 아니라, 아키텍트(Architect)와 빌더(Builder)를 분리하고 단방향 핸드오프(one-way handoff) 방식을 사용하는 것입니다.

Eco Mode는 어떻게 작동할까요? 제가 이해하기로는, 아키텍트(선택된 프론티어 모델): 작업을 제출하면 최고 등급 모델이 약 15단계의 기회를 얻습니다. 결정적으로, 이는 엄격하게 읽기 전용(read-only)입니다 (허용되는 유일한 쓰기는 버그에 대한 최소 재현 테스트를 작성하는 것입니다).

코드를 탐색하고 아키텍처를 이해하며, 엄격한 6가지 항목의 마크다운 사양(Goal, Scope, Where to change, Approach, Tests, 그리고 Risks/Corner cases)을 출력합니다. 그런 다음 완전히 작업을 중단합니다. 빌더(Builder) (저비용 실행 모델—현재는 GPT-6 Luna): Junie는 전체 컨텍스트와 구조화된 계획을 저가 모델에 전달합니다. 빌더가 실무 작업(grunt work)을 수행하며, 코드 편집, 로컬 빌드 실행, 스택 트레이스 파싱, 그리고 테스트가 통과할 때까지 반복하는 역할을 합니다. 여기서의 설계 선택은 단 한 번의 인계(handoff)로 작업을 처리하는 것입니다. 이전의 다중 에이전트 설정에서는 도구들이 저가 모델이 막힐 때까지 작동하도록 하거나, 나중에 "더 똑똑한 친구"에게 조언을 요청하게 하는 경우가 많았습니다. 이 패턴의 문제는 컨텍스트 폭발(context explosion)입니다: 저가 모델이 혼란스러워질 때마다 시스템은 50k 토큰 이상의 실패한 bash 로그를 재직렬화하여 비싼 모델에 다시 보내게 되고, 이는 Junie의 사설 저장소 전반에 걸친 벤치마크에서 비용 절감 효과를 완전히 파괴합니다. 이 단일 인계 설정에 대한 모든 수치는 매우 놀랍습니다. 예를 들어, Broad 사의 사설 저장소(Benchmark B): 작업당 평균 비용이 $2.61에서 $1.11로 (-57.3%) 떨어졌지만, 해결률은 거의 변하지 않았습니다 (49.1%에서 48.5%, 0.6% 변화). 대규모 엔터프라이즈 저장소(Benchmark A): 평균 비용이 $2.51에서 $1.30으로 (-48.1%) 떨어졌으며, 해결률은 동일한 32.1%를 유지했습니다. Opus 5.5 최대 노력 시: 비용은 $4.91에서 $1.81로 (-63%) 급락했지만, 해결률은 실제로 1% 상승하여 (55%에서 56%) 증가했습니다. 이는 아마도 스마트 모델이 파일을 건드리기 전에 명시적인 계획을 작성하도록 강제하는 것이 환각에 빠진 토끼굴 속으로 파고드는 것을 방지하기 때문일 것입니다.

하지만 저는 이것을 전적으로 일방적이라고 보지도 않습니다. (반론으로) 만약 Architect가 초기 15단계 동안 계획에 오류를 범한다면, Builder는 잘못된 해결책을 충실히 구현할 것입니다... 왜냐하면 값비싼 모델(이 경우 JetBrains AI 가격 책정도 고려해야 합니다...)에 다시 관여할 수 있는 역방향 루프가 없기 때문입니다. 그렇다고 해도, 해결률(resolve rates)이 순수 frontier 모델을 실행했을 때와 1% 이내로 유지되었다는 점을 감안하면, 제 경험상 비용을 절반으로 줄이는 가치가 있는 위험처럼 보입니다. 또한 다른 사람들은 테스트가 많은 작업에서 토큰 소모(token burn)를 어떻게 처리하는지 궁금합니다. 계획과 실행 사이에 모델을 수동으로 전환하시나요, 아니면 단순히 API 비용을 감수하고 계신 건가요? submitted by /u/AbleBranch6 [link] [comments]