저는 TokenSave(https://github.com/aovestdipaperino/tokensave)와 표준 OpenCode(https://github.com/anomalyco/opencode) 도구 간의 소규모 실무 비교를 수행하여, TokenSave가 대규모 Java 코드베이스에서 실제로 속도를 개선하고 컨텍스트 (context) 사용량을 줄이는지 확인했습니다.

테스트 환경

• MacBook Pro M1
• 16 GB RAM
• Lima Ubuntu
• OpenCode 1.18.9
• GPT-5.5
• 멀티 프로젝트 Java 코드베이스 (Multi-project Java codebase)
• 300k 라인의 코드 (300k lines of code)

동일한 작업을 두 번 실행했습니다:

1. 표준 OpenCode 도구만 사용
2. TokenSave만 사용

작업 자체는 하나의 컨트롤러 (controller)와 그와 관련된 의존성 (dependencies) 및 테스트를 포함하는 집중적인 코드베이스 탐색 요청이었습니다.

결과

TokenSave는 실행 시간을 13초 단축했으며, 이는 약 14.8%의 개선입니다.

동시에, 컨텍스트 (context) 사용량은 7,609 토큰 (tokens), 즉 약 18.1% 증가했습니다.

관찰 사항

표준 OpenCode 실행은 약간 더 완전한 답변을 생성했습니다. 가시적인 컨텍스트 토큰을 더 적게 사용하면서도 더 많은 주변 세부 정보를 찾아냈습니다.

TokenSave 실행은 다소 빨랐지만, 더 많은 도구 호출 (tool calls)을 필요로 했으며 약간 더 좁은 범위의 결과를 생성했습니다.

이는 TokenSave가 제공하는 인덱싱 (indexing) 및 코드 탐색 (code navigation) 기능이 조회 시간 (lookup time)을 줄일 수 있지만, 추가적인 도구 상호작용과 메타데이터 (metadata)가 예상되는 토큰 절감 효과를 상쇄할 수 있음을 시사합니다.

결론

OpenCode의 내장 도구는 약 300,000 라인의 코드를 가진 멀티 프로젝트 Java 코드베이스에서도 이미 충분히 최적화되어 있는 것으로 보입니다.

이번 테스트에서 TokenSave는 작업을 약간 더 빠르게 만들었지만, 더 많은 컨텍스트를 사용했고 약간 덜 완전한 답변을 생성했습니다.

따라서 전반적인 실무적 이점은 제한적이었습니다.

이것은 단일 테스트일 뿐이며 종합적인 벤치마크 (benchmark)가 아닙니다. 결과는 더 광범위한 아키텍처 분석 (architectural analysis), 반복적인 쿼리 (queries), 또는 훨씬 더 큰 저장소 (repositories)에 따라 달라질 수 있습니다.