코딩 에이전트의 토큰을 아껴 준다는 오픈소스가 빠르게 늘고 있다. 셸 명령 출력을 압축하는 RTK는 “자주 쓰는 개발 명령에서 토큰 소비를 60~90% 줄인다”고 소개하며 스타 8만 5천 개를 받았다. 도구 출력과 로그를 압축하는 headroom은 7만 8천 개, 언어 서버 기반 코드 탐색 MCP인 Serena는 3만 1천 개다(10월 30일 GitHub API 조회). 에이전트를 하루 종일 쓰는 사람에게 사용 한도와 청구액은 이제 매일 보는 숫자이고, 이 스타 수는 그 부담이 그만큼 크다는 뜻이다.
문제는 각 도구가 내세우는 절감률이 대부분 “그 도구가 손댄 출력이 얼마나 작아졌나”라는 점이다. 출력이 90% 작아져도 청구액이 90% 줄지는 않는다. 그렇다면 청구액은 얼마나 줄까? 10월 15일 arXiv에 올라온 TokenEconomizer 논문(UC Berkeley, Microsoft Research, Microsoft Security)이 이 질문에 같은 조건의 측정으로 답했다. 연구팀은 RTK, Serena, Aider의 RepoMap을 Claude Code·Codex·Copilot CLI에 붙여 SWE-Bench 과제를 돌렸고, 플러그인 형태의 자체 도구 TokenEconomizer도 공개했다.
이 글에서는 세 가지를 확인한다. 코딩 에이전트의 청구서는 어떤 항목으로 쌓이는가, 도구마다 어느 항목을 줄이고 실제 청구액은 얼마나 바뀌었는가, 그리고 내 환경에서는 무엇부터 바꿔야 하는가. 자료로는 논문 본문과 부록, TokenEconomizer 저장소(HEAD 1deb887, 10월 29일)의 코드와 문서를 읽었고, 내 Claude Code 세션 로그 30일치를 집계했다. RTK나 headroom을 직접 설치해 측정하지는 않았으므로, 이 도구들의 효과는 논문 측정값과 각 저장소의 설명으로만 다룬다.
청구서는 어떻게 쌓이나
에이전트가 한 턴을 진행할 때마다 모델에는 요청 전체가 다시 들어간다. 맨 앞에 시스템 프롬프트와 도구 정의, CLAUDE.md 같은 프로젝트 지침이 있고, 그 뒤에 지금까지의 대화와 도구 출력이 전부 붙는다. 프롬프트 캐싱은 이렇게 반복되는 앞부분을 싸게 다시 읽게 해 줄 뿐, 다시 읽는 일 자체를 없애지는 않는다. 그래서 턴이 길어질수록 매 턴 다시 읽는 양이 커지고, 같은 세션 안에서도 뒤쪽 턴이 앞쪽 턴보다 비싸다. 캐시가 어떤 조건에서 맞고 깨지는지는 #48에서 다뤘다.
이 구조가 실제 청구서에서 어떻게 나타나는지 내 로그로 확인했다. 최근 30일 동안(10월 30일 기준) 이 블로그를 포함한 여러 프로젝트에서 쓴 Claude Code 세션 15개에서 나온 과금 응답 1,337개의 usage 필드를 모아 Anthropic 공식 단가로 환산했다. 모델은 Opus 5.5와 Fable 5.1이 섞여 있다.
| 토큰 종류 | 토큰 비중 | 비용 비중 |
|---|---|---|
| 캐시 읽기(앞서 저장한 컨텍스트를 다시 읽음) | 97.9% | 47.0% |
| 캐시 쓰기(새 컨텍스트를 처음 저장함) | 1.8% | 37.2% |
| 출력 | 0.3% | 15.8% |
| 캐시를 거치지 않은 입력 | 0.0% | 0.0% |
토큰 수로는 거의 전부가 다시 읽은 컨텍스트였다. 단가가 기본 입력의 0.05배(Opus 5.5)와 0.025배(Fable 5.1)로 싸기 때문에 비용으로는 절반 정도로 내려온다. 캐시 쓰기는 토큰으로 1.8%뿐인데 비용으로는 37%를 차지했다. 내 세션의 캐시 쓰기는 전부 1시간 TTL이었고, 이 경우 단가가 기본 입력의 2배이기 때문이다. 세션의 첫 요청에 들어간 컨텍스트는 4.2만~5.2만 토큰이었다. 사용자가 아직 아무것도 시키지 않은 상태에서 매 턴 다시 읽는 양이 이 정도라는 뜻이다.
이 표에서 나오는 결론은 단순하다. 턴 하나를 없애면 그 턴에 다시 읽을 컨텍스트 전체가 사라진다. 반면 도구 출력 하나를 줄이면 그 출력이 저장되는 비용과, 그 출력을 다시 읽는 이후 턴들의 비용 일부만 줄어든다. 출력 압축이 효과가 없다는 말은 아니다. 다만 압축률은 청구서의 한 항목에만 적용되고, 압축 때문에 에이전트가 정보를 다시 찾느라 턴이 늘면 그만큼 상쇄된다.
같은 조건에서 잰 고정 전략 세 가지
논문은 먼저 Claude Code와 Opus 4.8(높은 effort)로 6개 저장소에서 10개씩, 모두 60개 SWE-Bench 과제를 돌렸다. 기본 실행과 세 가지 도구를 붙인 실행을 같은 과제에서 비교했다. 연구팀은 이 셋을 모든 저장소에 같은 설정을 적용한다는 뜻에서 고정 전략(fixed strategy)이라고 부른다.
- RTK(v0.45.0)는 셸 도구의 실행 전 훅으로 등록돼 명령을 RTK 경유로 바꾸고, 테스트 로그·파일 목록·diff 같은 출력을 줄여서 에이전트에게 돌려준다.
- Serena는 정의 찾기, 참조 찾기 같은 심볼 단위 탐색 도구를 추가하고, 에이전트에게 기본 읽기·검색 대신 이 도구를 쓰라고 지시한다.
- RepoMap은 Aider의 저장소 지도다. 저장소의 심볼을 참조 관계로 순위를 매겨 상위 시그니처를 2,048토큰 안에 담고, 이것을 프로젝트 지침으로 넣는다.
| 저장소 | RTK | Serena | RepoMap |
|---|---|---|---|
| scikit-learn | −6.9% | +28.6% | +30.5% |
| SymPy | +7.3% | +30.8% | +9.8% |
| Django | −19.9% | −15.4% | −16.2% |
| Sphinx | +0.6% | +2.1% | −7.5% |
| Matplotlib | −4.9% | −4.8% | +5.0% |
| xarray | −16.8% | +4.7% | −20.2% |
기본 실행 대비 비용 변화(음수가 절감). 논문 부록 표 3.
세 도구 모두 Django에서는 비용을 15~20% 줄였지만 SymPy에서는 늘렸다. scikit-learn에서는 RTK만 비용을 줄였고, Sphinx에서는 RepoMap만 줄였다. 어느 도구도 모든 저장소에서 이득을 내지 못했다.
본 실험에서는 277개 과제, 5개 에이전트·모델 조합, 3개 seed로 범위를 넓혔다. RTK를 붙였을 때 청구액 변화는 Claude Code + Sonnet 5에서 −1.1%, Opus 4.8에서 −3.6%, Codex + GPT-5.6 Terra에서 −4.7%, GPT-5.6 Sol에서 +4.5%, Copilot CLI + Sonnet 5에서 −8.9%였다. RepoMap은 −6.1%에서 +6.5% 사이였다. 저장소×조합 30칸으로 나눠 보면 RTK는 12칸, RepoMap은 15칸에서 비용을 늘렸다. Serena는 본 실험에서 빠졌다. 사전 측정에서 전체 비용을 늘린 유일한 도구였고, TokenEconomizer의 도구 정리 기능이 Serena 서버를 제거해 비교가 꼬일 수 있기 때문이다.
결과가 이렇게 갈리는 이유는 각 도구가 청구서의 어느 항목을 건드리는지 보면 짐작할 수 있다. RepoMap은 2,048토큰짜리 지도를 프로젝트 지침에 넣으므로, 지도가 매 턴 다시 읽는 앞부분에 붙는다. 지도 덕분에 탐색 턴이 줄어드는 저장소에서는 이득이고, 그렇지 않은 저장소에서는 매 턴 비용만 늘어난다. Serena도 도구 정의가 앞부분에 추가되고, 심볼 탐색이 기존 읽기·검색보다 호출 수를 늘리면 비용이 커진다. RTK는 새로 들어오는 셸 출력만 줄인다. 논문은 RTK 결과가 갈리는 원인을 따로 분석하지 않았다. 압축된 출력에 필요한 정보가 빠져 에이전트가 명령을 다시 실행했을 가능성이 있지만, 이것은 확인되지 않은 가설이다.
반복되는 비용 세 가지
연구팀은 같은 60개 과제에서 도구를 붙이지 않은 기본 실행 기록을 분석해, 저장소 안에서 반복되는 비용 세 가지를 찾았다.
세션마다 같은 사실을 다시 알아낸다. 한 저장소 과제의 절반 이상에서 반복된 동작이 도구 호출 바이트의 12~28%를 차지했다. 앞선 과제에 나온 동작과 일치하는 호출의 비율은 두세 번째 과제에서 14%였고, 앞선 과제가 5개 이상 쌓이면 30%까지 올랐다. 다른 저장소의 기록과 비교하면 7%만 일치했다. 테스트를 어떤 명령으로 돌리는지, 빌드를 먼저 해야 하는지처럼 그 저장소에서만 통하는 사실을 매번 다시 찾는다는 뜻이다.
불러온 도구 대부분을 쓰지 않는다. 에이전트는 매 턴 도구 정의 23개를 받았지만, 어느 저장소도 7개 넘게 쓰지 않았다. 16개는 한 번도 호출되지 않았고, 3개가 전체 호출의 98%를 차지했다. 내 로그에서도 30일 동안 호출된 도구는 21종이었고 상위 3개(Bash, Playwright의 페이지 스크립트 실행, 페이지 이동)가 호출의 78%였다.
실패한 과제가 비용을 많이 쓴다. 실패한 10개 과제는 전체의 17%였지만 비용은 32%를 차지했다. 같은 실패를 반복하는 것만으로 실패를 판별할 수는 없었다. 성공한 50개 중 36개도 같은 오류를 한 번 이상 반복했고, 반복 이후에 쓴 비용의 절반 이상이 결국 성공한 과제에서 나왔다. 턴 수 상한을 일괄로 거는 방법도 맞지 않았다. Matplotlib에서 실패한 과제는 성공한 과제보다 훨씬 길었지만(45턴 대 20턴), Sphinx에서는 거의 차이가 없었다(36턴 대 31턴).
세 가지 모두 턴 수나 매 턴 다시 읽는 앞부분과 연결된다. 사실을 다시 알아내려면 턴이 들고, 안 쓰는 도구 정의는 매 턴 다시 읽히고, 실패 루프는 턴을 계속 쌓는다.
TokenEconomizer가 줄이는 방식
TokenEconomizer는 에이전트의 모델과 코드를 건드리지 않는 외부 제어기다. 같은 저장소에서 끝난 세션 기록을 읽고, 위의 세 가지 비용에 하나씩 대응한다.
| 기능 | 하는 일 | 성립 조건 |
|---|---|---|
| micro-skills | 반복된 실패와 최근 세션 검토에서 저장소 사실을 뽑아, 세션 시작 때 한 줄씩 넣는다 | 세 세션에서 확인돼야 넣고, 이후 세션과 모순되면 폐기한다 |
| tool pruning | 오래 쓰지 않은 도구를 에이전트 자체 설정의 deny 목록에 넣는다 | 프롬프트 10개 이상이 2개 이상의 세션에 걸쳐 있거나, 5개 세션 동안 쓰지 않았어야 한다 |
| loop guard | 실패가 반복되는 턴을 judge 모델이 보고, 막혔다고 판정하면 다른 방법을 시도하라는 안내를 넣는다 | 그 저장소에서 잘 끝난 턴이 5개 이상 쌓여야 동작하고, judge 신뢰도가 0.7 이상이어야 한다 |
세부 설계에도 청구서 구조가 반영돼 있다. 비용은 캐시 단가로 계산하고, judge나 사실 제안처럼 제어기 자신이 부른 모델 호출도 해당 과제의 비용에 넣는다. micro-skills는 사실을 폐기할 때 확인 한 번보다 모순 한 번에 더 큰 가중치를 준다. 논문은 그 이유를 “폐기했어야 할 사실은 이후 모든 턴의 앞부분에 다시 청구된다”고 설명한다. tool pruning은 해당 저장소의 세션이 60분 동안 쉰 뒤에야 deny 목록을 쓴다. 도구 정의가 바뀌면 이어서 하던 대화의 캐시가 깨져 전체 이력을 다시 저장해야 하므로, 캐시가 어차피 만료된 시점을 기다린다.
SWE-Bench 결과는 다음과 같다. effort를 medium으로 낮춘 경우와 함께 놓았다.
| 조합 | TokenEconomizer 비용 | Pass@1 변화 | medium effort 비용 | Pass@1 변화 |
|---|---|---|---|---|
| Claude Code + Sonnet 5 | −23.6% | +1.3 | −26.6% | −4.7 |
| Claude Code + Opus 4.8 | −30.9% | −1.0 | −16.8% | −1.8 |
| Codex + GPT-5.6 Terra | −24.7% | +0.9 | −25.7% | −4.2 |
| Codex + GPT-5.6 Sol | −26.1% | +1.6 | −28.9% | −3.4 |
| Copilot CLI + Sonnet 5 | −18.4% | +2.6 | −25.4% | −2.4 |
기준은 높은 effort의 기본 실행. Pass@1 변화는 퍼센트포인트. 논문 표 1.
effort를 medium으로 낮추면 비용은 17~29% 줄지만 모든 조합에서 성공률이 떨어졌다. TokenEconomizer는 다섯 조합 중 넷에서 성공률이 올랐고, 30칸 전부에서 비용이 줄었다(−5.2~−40.1%). 기능을 하나씩만 켠 실험에서는 Claude Code 두 조합 기준으로 tool pruning이 −13.2%와 −17.7%, micro-skills가 −11.8%와 −14.3%, loop guard가 −7.1%와 −5.4%였다. 논문은 tool pruning의 몫이 가장 큰 이유를 “모든 과제의 모든 턴에 작용하기 때문”이라고 설명한다. 매 턴 다시 읽는 앞부분을 줄이는 기능이 가장 큰 효과를 낸 셈이다.
이 효과는 경험이 쌓여야 나온다. 저장소마다 기록 없이 시작하기 때문에, Claude Code 두 조합의 평균으로 보면 xarray를 뺀 모든 저장소에서 처음 몇 과제는 기본 실행보다 비쌌다. 여섯 번째 과제쯤부터 누적 비용이 기본 실행보다 낮아졌다. 매 과제가 새 저장소인 보안 감사 벤치마크에서는 micro-skills를 끄고 돌렸고, 절감 폭이 6.4~19.6%로 줄었다.
출력 압축과 함께 쓴 결과도 있다. Claude Code + Opus 4.8에서는 RTK를 더하자 절감률이 30.9%에서 33.2%로 늘고 성공률도 기본 실행보다 높아졌다. 다른 조합에서는 RTK를 더하면 절감률이 최대 5.2%포인트 줄었다. RepoMap을 더한 경우에는 다섯 조합 중 넷에서 TokenEconomizer 단독보다 덜 아꼈다. 논문은 RepoMap이 “수정할 위치”라는 다른 종류의 정보를 줘서 성공률을 올릴 수 있지만, 지도가 매 턴 청구된다고 설명한다.
논문 설정과 배포판의 차이
TokenEconomizer 저장소는 논문 실험의 설정과 배포한 플러그인의 설정이 어떻게 다른지 docs/PLUGIN.md에 표로 정리해 두었다. 설치하기 전에 알아야 할 차이는 세 가지다.
첫째, micro-skills가 기본으로 꺼져 있다. 기능별 실험에서 두 번째로 효과가 컸던 기능이다. 문서는 그 이유로 두 가지를 든다. 사실을 제안하는 모델 호출이 사용자의 요금제로 나가고, 주입되는 내용이 저장소가 통제하는 명령 출력에서 나온다는 것이다. 저장소에 악의적인 출력이 있으면 그것이 매 세션 지침으로 들어갈 수 있으니, 켤지는 사용자가 정하라는 판단이다. 기본 설치에서는 tool pruning과 loop guard만 동작하므로, 논문의 18.4~30.9%를 그대로 기대하기는 어렵다.
둘째, loop guard가 턴을 멈추지 않는다. 논문 실험에서는 안내 후에도 막혀 있으면 실행을 강제로 끝냈다. 플러그인은 사용자에게 중단 방법을 한 줄로 알리기만 한다. Codex와 Copilot의 훅은 턴 중단 신호를 무시하고, 멈출지는 사람이 정해야 한다는 이유다. 사람이 보지 않는 헤드리스 실행에서는 막힌 턴이 에이전트 자체 한도까지 계속 돈다.
셋째, Claude Code에서는 줄일 도구가 논문보다 적을 수 있다. 내 환경의 Claude Code는 MCP 도구 대부분을 필요할 때 불러오는 deferred 방식으로 다룬다. TokenEconomizer의 로그 파서(trace/claude.py)에도 “deferred 도구는 정의 전체가 아니라 목록 한 줄만 차지하므로 청구액에 거의 영향이 없다”는 주석이 있다. 이 경우 tool pruning이 줄일 대상은 항상 정의 전체가 실리는 내장 도구로 좁아진다. 논문 실험의 “매 턴 23개”와 내 환경의 도구 구성이 같다고 가정하면 안 된다.
지원 버전 범위도 좁다. Claude Code는 2.1.300~2.1.310, Codex는 0.153.1~0.164.0에서만 검증됐다. 내가 쓰는 Claude Code 2.1.314는 이 범위 밖이다.
내 환경에서 먼저 바꿀 것
논문과 내 로그를 함께 보면 우선순위가 정해진다. 턴 수와 매 턴 다시 읽는 앞부분을 먼저 줄이고, 출력 압축은 자기 저장소에서 효과를 잰 뒤에 붙인다. effort를 낮추는 방법은 성공률을 잃으므로 마지막에 쓴다.
1. 청구서 구성부터 잰다. 자기 세션이 캐시 읽기·쓰기·출력에 각각 얼마를 쓰는지 알아야 어느 항목을 줄일지 정할 수 있다. Claude Code는 세션 기록을 ~/.claude/projects/ 아래 JSONL로 남기므로, 응답마다 붙은 usage를 모으면 된다. 같은 응답이 여러 줄로 나뉘어 기록되므로 메시지 id 기준으로 마지막 값만 쓴다.
import json, glob, os, collections
last = {}
for f in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
for line in open(f, errors="ignore"):
d = json.loads(line)
m = d.get("message") or {}
if d.get("type") == "assistant" and isinstance(m, dict) and m.get("usage"):
last[m["id"]] = m["usage"]
t = collections.Counter()
for u in last.values():
t["cache_read"] += u.get("cache_read_input_tokens", 0)
t["cache_write"] += u.get("cache_creation_input_tokens", 0)
t["output"] += u.get("output_tokens", 0)
print(t) # 모델별 단가를 곱해 비용 비중으로 바꾼다첫 요청의 컨텍스트 크기도 같이 보면 좋다. 매 턴 다시 읽는 고정 비용이 얼마인지 알 수 있다.
2. 세션마다 다시 알아내는 사실은 지침에 적는다. micro-skills를 켜지 않아도 같은 일을 손으로 할 수 있다. 에이전트가 세션마다 같은 명령을 시행착오로 찾고 있다면, 그 명령을 CLAUDE.md나 AGENTS.md에 한 줄로 적는다. 다만 지침도 매 턴 다시 읽는 앞부분에 들어가므로 길게 쓰면 RepoMap과 같은 문제가 생긴다. TokenEconomizer의 규칙을 그대로 빌리면 된다. 여러 세션에서 반복 확인된 사실만 적고, 틀린 것으로 드러나면 바로 지운다. 지침을 어떻게 쓰면 에이전트가 따르는지는 #66에서 실험했다.
3. 쓰지 않는 도구는 뺀다. 연결만 해 두고 쓰지 않는 MCP 서버를 끄고, 저장소별 설정에서 쓰지 않는 내장 도구를 deny 목록에 넣는다. 도구 설정을 바꾸면 이어서 하던 대화의 캐시가 깨지므로, TokenEconomizer처럼 작업을 쉬는 시점에 바꾼다.
4. 같은 실패가 반복되면 끊는다. 같은 오류가 세 번 나오면 그 턴을 멈추고 접근을 바꾸라고 지시하는 편이 이어서 시도하게 두는 것보다 싸다. 다만 논문 데이터처럼 반복만으로는 실패를 판별할 수 없으니, 그 저장소에서 성공한 작업이 보통 얼마나 걸리는지를 기준으로 삼는다. 사람이 보지 않는 헤드리스 실행에는 턴 수나 비용 상한을 따로 둔다.
5. 출력 압축은 측정한 뒤에 붙인다. 테스트 로그와 빌드 출력이 긴 저장소라면 RTK 같은 도구가 이득일 수 있다. 하지만 논문 결과처럼 저장소에 따라 비용이 오히려 늘 수 있으므로, 압축률이 아니라 같은 과제의 청구액과 성공 여부를 비교해서 판단한다.
캐시 단가가 바뀐 점도 고려해야 한다. 논문은 Opus 4.8과 Sonnet 5로 측정했는데, 이 모델들의 캐시 읽기 단가는 기본 입력의 0.1배다. Opus 5.5와 Sonnet 5.5는 0.05배로 내려갔다. 다시 읽는 비용이 싸지면 청구서에서 캐시 쓰기, 즉 새로 들어오는 컨텍스트의 비중이 커진다. 실제로 내 로그에서도 캐시 쓰기가 비용의 37%였다. 그렇다면 최신 모델에서는 도구 출력을 줄이는 쪽의 상대적인 효과가 논문 측정보다 커질 수 있다. 이것은 내 로그와 단가표에서 나온 가설이고, 최신 모델로 같은 비교를 다시 해야 확인할 수 있다.
효과를 재는 방법은 논문의 설계를 따르면 된다. 같은 저장소의 실제 과제 10개 이상을 순서대로, 도구를 켠 조건과 끈 조건에서 각각 돌린다. 비용은 캐시 단가를 반영해 계산하고, 도구 자신이 부른 모델 호출도 넣는다. 성공 여부를 함께 기록하고, 첫 몇 과제가 아니라 누적 비용으로 비교한다. 비용이 줄지 않거나 성공률이 떨어지면 도구를 뺀다.
TokenEconomizer 자체는 같은 저장소에서 테스트를 반복해서 돌리는 작업에 맞는다. 쓴다면 toolprune=propose로 시작해 무엇을 뺄지 제안만 받아 보고, status로 실제 비용을 확인한 뒤에 켜는 순서가 안전하다. 지원 버전 범위도 먼저 확인해야 한다.
정리
코딩 에이전트의 청구서는 매 턴 다시 읽는 컨텍스트가 대부분을 차지한다. 내 세션 30일치에서 토큰의 97.9%가 캐시 읽기였고, 세션은 시작부터 4만~5만 토큰을 매 턴 다시 읽었다. 그래서 출력 하나를 90% 줄이는 것보다 턴 하나를 없애거나 매 턴 실리는 앞부분을 줄이는 쪽이 청구액에 더 크게 작용한다.
같은 조건의 측정도 이 방향을 뒷받침한다. RTK·Serena·RepoMap은 저장소에 따라 비용을 줄이기도 늘리기도 했고, RTK는 30칸 중 12칸에서 비용을 늘렸다. 안 쓰는 도구 정의, 다시 알아내는 사실, 실패 루프를 줄인 TokenEconomizer는 30칸 전부에서 비용을 낮췄다. 기능 중에서는 매 턴 작용하는 tool pruning이 가장 많이 아꼈다.
다만 배포판은 논문 설정보다 보수적이다. micro-skills는 꺼져 있고, loop guard는 턴을 멈추지 않으며, Claude Code에서는 MCP 도구가 이미 deferred로 다뤄진다. 어느 도구를 쓰든 자기 저장소에서 청구액과 성공률을 함께 재 보는 것이 출발점이다.
참고 자료
- Aaron J. Li 외, TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents, arXiv 2610.22732, 2026-10-15
- microsoft/TokenEconomizer 저장소,
docs/PLUGIN.md - rtk-ai/rtk, headroomlabs-ai/headroom, oraios/serena, Aider-AI/aider
- Anthropic, Pricing (캐시 쓰기·읽기 배율)
- 이전 글: #18 Headroom 코드 분석, #48 캐시 히트율, #66 AGENTS.md 실험