Claude Code에서 토큰 사용량을 178배 줄였습니다!!

자, 유출된 Claude Code 저장소를 가져왔는데 전체가 약 1,430만 토큰 정도였습니다. 지식 그래프에 쿼리를 날렸더니 해당 쿼리에 대해 약 8만 토큰을 돌려받았습니다!

14.3M / 80K ≈ 178배.

좋네요. 제가 공식적으로 AI를 해결했습니다. 이제 20달러짜리 Claude를 178배 더 오래 사용할 수 있습니다!!

잠깐만요, 농담입니다 하하!
이게 바로 지금 인터넷에서 모든 사람이 "토큰 효율성"을 설명하는 방식입니다. 가능한 전체 컨텍스트를 가져와서 선택적으로 검색된 컨텍스트로 나누고, 큰 배수를 붙여서 포스팅을 올리면 붐!! 여러분의 저장소는 수천 개의 스타를 받고 여러분은 D**bas*es 사이에서 유명해지겠죠!!

하지만 실제 시스템은 그렇게 작동하지 않습니다. Claude는 1,480만 토큰 저장소를 스스로 탐색하다가 시스템을 망가뜨릴 만큼 멍청하지 않습니다! Claude Code뿐만 아니라 어떤 AI 도구라도 마찬가지입니다!

실제 토큰 사용량은 한 번 검색한 양만이 아닙니다. 입력 토큰, 출력 토큰, 캐시 읽기, 캐시 쓰기, 도구 호출, 서브프로세스 등이 모두 포함됩니다. 이 모든 것이 계산에 들어갑니다. "177배" 스타일의 수학은 토큰이 실제로 어디에 쓰이는지 대부분 무시합니다.

그리고 솔직히 말해서, 검색(retrieval)은 어려운 문제도 아닙니다. 메모리가 진짜 문제죠. 이 프로젝트를 오랫동안 작업하면서 깨달은 점입니다!

10턴 후에 같은 파일이 다시 필요하면 어떻게 될까요? 자동 압축(auto-compact)에서 무엇이 살아남을까요? 세션이 커지면서 무엇이 조용히 누락될까요? 대부분의 도구는 검색 문제를 해결하고 메모리는 그냥 알아서 작동할 것이라고 가정합니다. 하지만 그렇지 않습니다.

저는 Graperoot라는 도구로 이 문제를 해결해 왔습니다.

단순히 컨텍스트를 가져오는 대신, 이를 관리하려고 시도합니다. 여기에는 두 가지 레이어가 있습니다:

• 코드베이스 그래프 (저장소 전체의 구조 + 관계)
• 라이브 인-세션 액션 그래프 (무엇이 검색되었고, 실제로 무엇이 사용되었으며, 우선순위에 따라 무엇을 유지해야 하는지 추적)

따라서 컨텍스트는 한 번 검색되고 잊혀지는 것이 아닙니다. 추적되고, 재사용되며, 세션이 커져도 누락되지 않도록 보호됩니다.

Medusa, Gitea, Kubernetes와 같은 실제 저장소에서 테스트한 수치입니다:

우리는 가짜 기준이 아닌 실제 워크플로우를 기준으로 벤치마크를 수행합니다.

결과

|Repo|Files|Token Reduction|Quality Improvement|
|:-|:-|:-|:-|
|Medusa (TypeScript)|1,571|57%|~75% better output|
|Sentry (Python)|7,762|53%|Turns: 16.8 to 10.3|
|Twenty (TypeScript)|~1,900|50%+|Consistent improvements|
|Enterprise repos|1M+|50 to 80%|Tested at scale|

저장소 크기에 관계없이 평균 감소율은 약 50%이며, 피크 시에는 80%까지 올라갑니다. 여기에는 입력, 출력 및 캐시된 토큰이 포함됩니다. 부풀려진 숫자가 아닙니다.

평균 약 50~60% 토큰 감소

집중된 작업에서 최대 약 85% 감소