Show GN: 에이전트의 토큰낭비를 잡는 CLI를 만들었습니다! (공개 트레이스 6,780개)

토큰 낭비가 안 보이는 이유는 실패가 아니라 중복이라서입니다 같은 파일 두 번 읽기, 같은 인자로 재시도, 같은 도구 재호출. 그래서 끝난 트레이스를 읽어서 어느 스텝이 이미 한 일을 또 했는지 짚어주는 CLI를 만들었습니다!

[써보기]
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md

가입 없이 로컬에서 돌아갑니다. torch를 안 받아서 설치는 몇 초면 끝납니다. Python 3.12 이상. Claude Code 세션 파일은 ~/.claude/projects/ 아래에 있습니다.

공개 Claude Code 세션(258턴)에 돌린 실제 출력입니다:

Result: WASTE DETECTED

• category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified

1. requery — Read on .../boot.ts

• turns: turn 50 → re-run at turn 58 (of 258 total)
• state: No modification of this file in between — re-read output is unchanged.
• re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
• estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)

[어떻게 판정하나]

Langfuse나 Phoenix처럼 트레이스를 저장하고 시각화하지 않습니다. 이미 끝난 트레이스를 읽어서 낭비만 짚습니다.

2단계입니다. 먼저 같은 도구를 같은 인자로 부른 것끼리 묶고, 그다음 출력의 sha256이 완전히 같은지 봅니다. 출력이 다르면 상태가 바뀐 거라 안 잡습니다.

LLM 판정이 없습니다. 같은 트레이스를 넣으면 언제나 같은 결과가 나옵니다.

찾은 낭비는 네 종류로 분류합니다. 에러 반복(같은 에러를 원인 안 고치고 재시도), 부작용 재실행(상태를 바꾸는 도구를 같은 인자로 다시 호출), 회색지대(읽기 전용 반복 — 부작용은 없지만 토큰은 씀), 판정불가. Bash나 PowerShell처럼 인자 내용에 따라 효과가 완전히 달라지는 도구는 이름만으로 판정하지 않고 판정불가로 둡니다.

[공개 데이터에서 뭘 찾았나]

Toolathlon 벤치마크(22개 프론티어 모델 × 3회 실행, 6,780 트레이스, tool span 176,270개)에 그대로 돌렸더니 중복 호출 8,042건이 나왔습니다.

이 숫자를 그대로 쓰면 부풀린 겁니다. 47%는 회색지대(작업 완료 선언 반복, 이미 있는 디렉토리 재생성 같은 것)라서, 빼고 나면 4,251건입니다. tool span 대비 2.41%.

눈에 띈 건 상태를 바꾸는 도구의 중복 실행 1,343건이었고, 그중 같은 인자로 반복된 이메일 발송이 459건이었습니다. 다만 이건 "같은 도구가 같은 인자로 두 번 호출됐다"는 탐지고, 실제로 메일이 두 번 나갔는지는 트레이스만으론 확인할 수 없습니다.

[의외였던 것]

Claude Code 자체는 생각보다 효율적이었습니다. 파일 재읽기, 무의미한 재시도 같은 후보 패턴을 여섯 번 측정했는데 다섯 번은 CC 실세션에 사실상 존재하지 않았습니다. 캐싱과 컨텍스트 유지로 이미 막고 있더군요.

낭비가 두꺼운 쪽은 MCP 서버를 여러 개 붙인 환경이었습니다. 도구가 20개인 CC(0.80%)와 523개인 Toolathlon(2.41%)이 3배 차이였습니다.

[한계]

측정된 절감 사례는 아직 없습니다. 탐지하고 추정할 수는 있지만, 누가 이걸 보고 뭔가 고쳐서 청구서가 실제로 줄어든 데이터는 0건입니다.
회색지대 47%는 걸러내지 않고 분류만 해서 보여줍니다. 읽기 전용 반복이 실제 낭비인지는 실행 맥락에 따라 다르고, 그건 제가 판단할 수 없는 부분이라서요.
Cursor와 Codex는 아직 지원하지 않습니다.
검증에 실패한 탐지기는 폐기합니다. 파일 재읽기 탐지기를 만들었다가 30건 표본에서 정밀도가 70% 임계를 크게 밑돌아(관대하게 봐도 3.3%, 엄격하면 0%) 죽였고, 사전등록 문서에 예측과 결과를 함께 남겨뒀습니다.

[마무리...]
이 분야에 대해서 계속 연구와 검증 할 예정입니다!
readme가 영문인점은 죄송합니다.. ㅜ
만약 사용하시고 이런 부분은 개선 되었으면 좋겠고 추가 되었으면 좋겠다 라는 부분의 피드백을 받고 싶습니다!
앞으로 clew에게 많은 관심 부탁드립니다 감사합니다...!!

[qlcla123]

[보기 불편하실까봐 READ ME 한국어 번역본을 적어드렸습니다!]
Clew
에이전트 트레이스에서 낭비된 작업을 찾는 결정론적 탐지기.

Clew는 완료된 AI 에이전트 실행 트레이스를 읽어서, 이미 수행된 작업을 반복한 스텝 — 같은 도구를 같은 인자로 재호출, 실패한 호출을 동일 인자로 재시도, 이미 컨텍스트에 있는 정보를 다시 조회 — 을 찾아냅니다. LLM 판정 없이 동작하므로, 같은 트레이스를 넣으면 언제나 같은 결과가 나옵니다.

pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md

공개 Claude Code 세션에 돌린 실제 출력 예시:

Result: WASTE DETECTED

• wasted spans: 1
• category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified

1. requery — Read on .../boot.ts

• turns: turn 50 → re-run at turn 58 (of 258 total)
• state: No modification of this file in between — re-read output is unchanged.
• re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
• estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)

이게 왜 중요한가

AI 코딩 에이전트 세션은 청구서로만 낭비가 드러납니다. 모든 도구 호출이 200을 반환하고, 아무것도 에러를 내지 않기 때문에 낭비가 눈에 보이지 않습니다. 하지만 트레이스 안에서는 에이전트가 같은 파일을 두 번 읽고, 실패한 호출을 동일 인자로 재시도하고, 같은 도구를 같은 페이로드로 다시 부릅니다.

코딩 에이전트 세션에서 읽기(read) 작업이 토큰의 65~90%를 차지하기 때문에, 이런 낭비는 눈에 띄지 않게 쌓입니다. 관측성 도구들은 트레이스를 보여주지만, 어느 스텝이 중복이었는지는 알려주지 않습니다.

무엇을 탐지하나

Clew는 세 가지 중복 패턴을 찾습니다:

repeat — 같은 도구/노드가 반복 호출됨
requery — 같은 도구가 같은 입력으로 재호출됨 (출력 동일)
pingpong — 두 에이전트가 실질적으로 같은 내용을 주고받음 (멀티에이전트)

각 발견은 네 가지로 분류됩니다:

error_repeat — 출력이 에러인데 같은 호출을 반복
side_effect — 상태를 변경하는 도구(전송/쓰기/생성 등)를 재실행
idempotent — 읽기 전용/선언적 도구를 반복 (부작용 없음, 토큰은 소모)
unclassified — 매핑에 없는 도구. 효과가 페이로드에 달려 있어 도구 이름만으로 추론하지 않음 (Bash/PowerShell 등)

[어떻게 동작하나]
2단계 캐스케이드입니다:

구조 게이트 — 같은 도구를 같은 (정규화된) 인자로 호출한 것끼리 묶음
동일성 게이트 — 출력의 sha256이 완전히 일치하는지 확인. 다르면 상태가 변한 것이므로 플래그하지 않음

값싼 구조 검사가 먼저 후보를 추리고, 비싼 의미 검사(임베딩+코사인)는 필요할 때만 실행됩니다. LLM 판정이 없으므로 결과가 결정론적입니다 — CI에 넣고 싶다면 이 점이 중요합니다.

[입력 형식]
Claude Code — 세션 JSONL을 직접 분석
LangGraph — 트레이스에서 체인 중복 탐지
LangChain·CrewAI·AutoGen·LlamaIndex 등 — OpenTelemetry/OpenInference 표준 형식으로 계측된 트레이스를 파싱 (형식 지원이며, 프레임워크별 실측 검증은 진행 중)
공개 벤치마크 트레이스 (Toolathlon, RedundancyBench)

Cursor와 Codex 세션은 아직 지원하지 않습니다 — 로컬 포맷을 검토 중입니다.

[검증 결과]

공개 벤치마크 (Toolathlon, 6,780 트레이스, tool span 176,270개):
중복 호출 8,042건 탐지. 그중 47%는 회색지대(멱등 연산, 완료 선언)이며, 이를 제외하면 4,251건(tool span 대비 2.41%). Claude Code 세션(0.80%) 대비 약 3배.

상태 변경 도구의 중복 실행 1,343건, 여기에 같은 인자로 반복된 이메일 발송 459건 포함. 단, 이는 같은 도구가 같은 인자로 중복 호출됐다는 탐지이며, 실제로 부작용이 발생했는지는 확인되지 않았습니다.

라벨링 벤치마크 (RedundancyBench):
precision 0.826 (파일 내 중복에 대한 하한 추정치). RB 라벨의 상당수는 파일 간(cross-file) 중복으로, 세션 단위 분석 설계의 범위 밖입니다. recall은 0.157로 낮습니다.

[정직 경계]
측정된 절감 사례는 아직 없습니다. 탐지하고 추정할 수는 있지만, 실사용자가 무언가를 고쳐서 청구서가 실제로 줄어든 before/after 데이터는 0건입니다.
벤치마크에서 플래그된 것의 47%는 회색지대(멱등 재실행)입니다. 걸러내지 않고 분류만 합니다 — 읽기 전용 재실행이 낭비였는지는 볼 수 없는 맥락에 달려 있기 때문입니다.
sha256 완전일치를 요구하므로 출력이 조금만 달라도 플래그하지 않습니다. recall이 낮은 이유이며, 정밀도 쪽에 서 있는 설계입니다.
Claude Code는 유난히 잘 최적화돼 있습니다. 실제 CC 세션에서 후보 낭비 패턴 여섯 개를 측정했는데 다섯 개는 거기 존재하지 않았습니다. 흥미로운 낭비는 CC 자체가 아니라 다중 도구 MCP 환경에서 나타났습니다.
비용 추정(amplification)은 측정이 아니라 추정이며, Claude Code 포맷에서만 가능합니다.
검증되지 않은 것은 폐기합니다

파일 재읽기 탐지기를 만들었다가, 30건 표본 사람 주석에서 정밀도가 사전등록 임계(70%)를 크게 밑돌아(관대하게 봐도 3.3%, 엄격하면 0%) 폐기했습니다. 예측과 결과는 사전등록 문서에 함께 남겨뒀습니다.