Claude Code, 툴 정의에 컨텍스트 낭비? 래퍼(Wrapper)별 성능 비교 분석
Claude Code는 턴당 62,600자의 과도한 툴 정의를 전송하여 컨텍스트를 낭비하는 반면, pi는 2,200자로 효율적인 사용을 보임.
동일한 모델(Sonnet 4.6)을 사용하여 Express.js의 버그를 수정하는 과정에서 Aider, pi, Cline, Claude Code, OpenCode의 성능과 비용을 비교 분석함.
Cline은 툴 결과를 사용자 메시지로 인코딩하여 컨텍스트를 효율적으로 관리하며, OpenCode는 과도한 출력으로 인해 비용이 높게 발생함.
Aider는 툴을 사용하지 않아 테스트를 수행하지 못하는 단점이 있었지만, Cline은 가장 저렴하고 일관된 성능을 보였다.
Claude Code의 과도한 툴 정의 오버헤드(Overhead)
본 연구는 Claude Code가 턴당 62,600자에 달하는 방대한 툴 정의를 전송하여 컨텍스트를 낭비한다고 지적한다. 이는 다른 래퍼(wrapper)인 pi(2,200자)와 비교했을 때 현저한 차이를 보인다. 과도한 툴 정의(Tool Definitions)는 컨텍스트 창(Context Window)을 빠르게 채워 장기적인 대화(Long-running Session)에 불리하게 작용할 수 있다. Context Lens를 통해 래퍼별 컨텍스트 사용량을 시각적으로 분석하여 이러한 문제를 파악했다.
래퍼(Wrapper)별 컨텍스트 사용량 및 비용 비교
연구 결과에 따르면, Aider는 0%의 캐시 적중률(Cache Hits)과 8,700개의 출력 토큰(Output Tokens)을 생성하며, pi는 71%의 캐시 적중률과 1,412개의 출력 토큰을, Cline은 78%의 캐시 적중률과 1,135개의 출력 토큰을, Claude Code는 92%의 캐시 적중률과 2,737개의 출력 토큰을, OpenCode는 81%의 캐시 적중률과 5,421개의 출력 토큰을 생성했다. OpenCode는 과도한 출력으로 인해 다른 래퍼보다 높은 비용을 발생시켰다. 비용 최적화(Cost Optimization)를 위해서는 출력 토큰 수를 줄이는 것이 중요하다.
Cline의 효율적인 컨텍스트 관리
Cline은 툴 결과를 사용자 메시지로 인코딩하는 독특한 아키텍처를 사용하여 컨텍스트를 효율적으로 관리한다. 이는 96.4%의 높은 캐시 적중률(Cache Hit)을 달성하는 데 기여했다. Cline의 아키텍처(Architecture)는 턴마다 안정적인 사용자 메시지를 앞쪽에 배치하여 캐싱 효율을 높이는 방식으로 설계되었다. 이러한 접근 방식은 컨텍스트 관리(Context Management) 측면에서 매우 긍정적인 평가를 받았다.
Aider의 한계: 테스트 미실행
Aider는 툴을 사용하지 않아 테스트를 실행할 수 없다는 단점이 있다. 이는 Aider가 버그를 수정하는 데 실패하는 주요 원인 중 하나로 작용했다. Aider의 아키텍처(Architecture)는 쉘(Shell) 접근을 허용하지 않아 테스트 스위트(Test Suite)를 실행할 수 없게 한다. 이는 Aider 사용 시 사용자가 직접 검증해야 하는 추가적인 부담으로 이어진다. 테스트 자동화(Test Automation)의 중요성을 시사한다.
OpenCode의 과도한 출력 문제
OpenCode는 모델에게 모든 단계를 자세히 설명하도록 유도하는 시스템 프롬프트(System Prompt)로 인해 과도한 출력 토큰을 생성하여 비용을 증가시킨다. OpenCode의 시스템 프롬프트(System Prompt)는 모델이 각 단계를 자세히 설명하도록 유도하여, 결과적으로 더 많은 출력 토큰을 생성하게 한다. 이는 출력 토큰당 비용이 높은 모델에서 특히 치명적인 문제로 작용한다. 출력 토큰 최적화(Output Token Optimization)가 필요하다.