5가지 인기 토큰 절약 방법을 10가지 실제 작업으로 테스트해 본 결과, 두 번의 실행 모두에서 토큰을 줄인 방법은 없었습니다.

둘째, 품질이다. 각 모드를 같은 작업에서 기준 모델과 1:1로 붙여서 총 20번의 대결을 붙였다. 아래 표는 20번 중 승리, 패배, 무승부를 카운트한 것이다. 테스트, 동일성, 코드 리뷰 항목에서 '승리'는 해당 모드의 패치가 더 나았다는 뜻이다. 풋프린트 항목에서 '승리'는 위험도가 더 낮았다는 뜻이다.

셋째, 8가지 품질 평가 지표다. 각 셀은 0~4점 척도에서 해당 모드의 평균 점수에서 기준 모델의 평균 점수를 뺀 값이다. 두 번의 실행을 평균 냈고, 마이너스 값은 평가자가 해당 모드의 패치를 더 낮게 평가했다는 뜻이다.

에이전트에게 적게 쓰라고(Ponytail) 하거나 말을 적게 하라고(Caveman) 시킨 두 모드는 견고함과 범위 통제 측면에서 가장 큰 타격을 입었다. 반면, diff 최소화에서 승리한 두 모드(RTK, Mandarin)는 토큰을 줄인 게 아니라 오히려 더 많이 써서 결과를 얻어낸 꼴이었다.

분석

Caveman 사례를 보면 왜 반복 실행이 중요한지 알 수 있다. 평균값은 거의 비슷해 보이지만, 실제 두 번의 실행 결과는 +7%와 -11%였다. 이 방식은 일관되게 "덜 하는" 메커니즘이 아니었다. Caveman은 대화나 탐색 같은 특정 구간은 압축했지만, 다른 구간은 오히려 늘려버렸다. 늘어나는 구간은 작업마다 달랐다. 어떤 건 패치가 커졌고, 어떤 건 검증 루프가 길어졌고, 어떤 건 독립적인 테스트 아티팩트가 생겨났다.

Ponytail은 두 번 다 출력 토큰을 줄인 유일한 모드였는데, 각각 -3%, -11%를 기록했어. 근데 전체 토큰은 여전히 +16%, -1%로 움직였지. 패치 크기도 대체로 더 작았고. 이건 전부 주입된 행동 방식 때문이야. Ponytail은 모델한테 "최고의 코드는 아예 안 짜는 코드"라고 세뇌하고, 코드를 쓰기 전에 YAGNI 사다리를 7단계나 타게 만들거든. 게다가 복잡한 작업은 실행 가능한 작은 체크 하나로 제한해 버리지. 추론 모델 입장에선 이게 역설적인 상황인 거야. 뭘 생략할지 고민하느라 입력 토큰이랑 사고 토큰은 더 쓰는데, 정작 나오는 패치는 짧아지는 거지.

RTK는 개별 명령어의 출력값은 줄였지만, 에이전트가 명령어를 더 많이 날려버렸어. RTK는 작업당 평균 60번의 도구 호출을 했는데, 베이스라인은 49번이었고 시간도 거의 두 배나 더 걸렸지. 래퍼(wrapper)가 자기 할 일은 제대로 했어. 명령어 하나당 나오는 원시 출력값은 줄였으니까. 근데 에이전트가 그 뒤로 명령어를 더 많이 때리고, 검증도 더 많이 하고, 같은 파일을 더 잘게 쪼개서 다시 읽어버린 거야. rg, git, 테스트 명령어 하나에서 아낀 토큰이, 모델이 나중에 명령어를 몇 번이나 더 실행할지까지는 보장해주지 않는다는 거지.

Context Mode는 토큰이랑 비용을 둘 다 늘렸어. 전체 토큰이 +94%, +46% 늘었고, 20개 페어 작업 중 19개에서 토큰 손실이 발생했지. 싸고 구조화된 검색 기능을 주니까 에이전트가 문맥을 더 많이 긁어모으고 더 자주 들여다보게 된 거야. 저장소 전체를 검색하고 가져오는 게 싸고 체계적으로 변하니까, 에이전트가 문맥을 더 많이 수집하고, 더 자주 확인하고, 그걸 통합하는 데 시간을 더 쏟게 된 거지. 문맥 작업 하나당 한계 비용을 낮췄더니 오히려 전체 수요량이 늘어난 꼴이야.

Mandarin은 전체 토큰을 86%, 15% 늘렸어. 为什么？(왜냐고?) 번역된 프롬프트는 단순히 첫 메시지의 토큰 수만 바꾼 게 아니야. 모델이 작업을 분해하고 접근하는 방식 자체를 바꿔버렸거든. 작업이 필요하든 아니든 상관없이 위임하는 횟수가 늘었고, 그 방식도 더 획일화됐어. 비용은 중국어 글자 때문이 아니라, 그 결과로 나타난 전체 작업 궤적에서 발생한 거야.

Terra는 20개 작업 페어 중 19개에서 더 저렴했지만, 전체 토큰은 6%, 5% 더 썼어. 그러니까 이건 토큰 효율성이 아니라 가격 책정에서 이득을 본 거지. Terra는 턴당 출력 토큰은 더 많으면서 도구 호출 횟수는 평균적으로 더 적었어(49번 대비 42번). 추론에 쓴 노력은 궤적이 아니라 토큰 수에 나타난 셈이지. 품질 문제는 과하게 만들어서 생긴 게 아니라, 더 큰 요구사항의 구성 요소를 누락해서 발생했어.

공유된 메커니즘

이 방법들은 각기 다른 국소적인 지점들을 최적화해:

• Ponytail은 코드랑 설명을 덜 내뱉으려고 함.
• Caveman은 상호작용을 압축함.
• RTK는 개별 명령어 결과를 압축함.
• Context Mode는 검색된 문맥을 압축함.
• Mandarin은 프롬프트 표현 방식을 바꿈.
• Terra는 모델, 추론 수준, 가격 책정 방식을 바꿈.

근데 청구서는 국소적인 지점이 아니라 전체 작업 궤적에 대해 날아오지.

모델은 명령어 결과값을 작게 받아도, 명령어를 두 배로 실행해서 메꿀 수 있어. 뭘 생략할지 고민하느라 토큰을 더 쓰고 나서 더 짧은 패치를 내뱉을 수도 있지. 저장소 문맥을 가져오기 쉽게 만들면, 그만큼 훨씬 더 많이 가져와서 응답할 수도 있고.

여기서 일어난 일이 딱 이거야. 이 처리 방식들이 에이전트의 검색 정책, 위임, 검증 루프, 패치 경계를 다 바꿔버린 거지. 그 행동 변화가 토큰 절감 효과보다 훨씬 크고 일관적이었던 거야.

출력 압축이 곧 작업량 압축은 아니다.

다른 연구들도 국소적인 절감 효과와 전체 궤적 사이의 이런 괴리를 지적해. 실제 Claude Code 세션 500개를 다시 돌려본 결과에 따르면, 이 분야 도구들이 광고하는 60~90% 절감 효과는, 재전송된 문맥까지 다 계산하고 나면 전체 비용의 4% 미만으로 쪼그라들었어. JetBrains도 Caveman 프롬프팅과 RTK에 대한 통제 연구에서 똑같은 패턴을 발견했지.

결론

토큰을 아끼려고 만든 도구들은 사실상 행동 교정이나 다름없음. 광고하는 효과만 봐서는 실제 청구 금액이나 결과물의 퀄리티가 어떤지 알 수가 없거든.

전체 토큰 사용량을 줄이는 게 목적이라면, 지금 나온 증거들로 봐서는 이런 도구들을 굳이 폭넓게 쓸 이유가 없음. 비용 절감이 목적이라면 5.6 Terra xhigh가 확실한 승자긴 한데, 이건 모델 자체가 다르고 추론 수준이나 퀄리티도 차이가 있으니 감안해야 함.

결국 자기 작업에서 설정 변경이 토큰을 아껴주는지 확인하는 유일한 방법은, 설정을 바꿨을 때랑 안 바꿨을 때 각각 작업을 돌려보고 청구서를 직접 확인하는 것뿐임.

공개: 이 연구에 사용한 로컬 평가 도구인 Stet은 내가 직접 만들고 있음. 코딩 에이전트가 설정을 변경했을 때, 커밋하기 전에 과거 저장소 작업들을 대상으로 테스트해 볼 수 있게 해주는 도구임. Stet은 현재 사용 중인 LLM 구독을 활용해서 로컬에서 돌아감.

10개의 작업은 제 레포지토리에서 가져온 실제 병합된 변경 사항들로 다양한 코딩 작업을 포함하지만, 모두 제 레포에서 나온 것이라 일반화보다는 일관성을 테스트한 것에 가깝습니다.

결과에서 작업별로 큰 차이가 나는 것을 보면 이런 도구들은 워크로드 의존적인 것 같습니다: o...