Red Hat이 219개의 실제 세션을 분석한 결과에 따르면, Claude Code는 토큰 예산의 4분의 3을 단순히 코드베이스를 읽는 데 사용합니다. 이 결과는 AI 기반 코딩 에이전트가 코드 생성에 시간을 낭비한다는 일반적인 가정을 뒤집으며, 개발자가 단순히 모델의 속도가 아니라 컨텍스트 관리 문제에 집중해야 함을 시사합니다.
데이터가 말해주는 사실
Red Hat은 Anthropic의 Claude Code와 진행된 219개의 상호작용을 조사하여 턴당 토큰 사용량을 계산했습니다. 샘플 전체를 살펴보면, 중간값 기준으로 턴당 토큰의 75%는 주변 코드와 문서를 읽어들이는 데 할당된 반면, 새로운 코드를 생성하는 데는 25%만 사용되었습니다. 대부분의 AI 제공업체가 입력 및 출력 토큰을 동일한 비율로 청구하기 때문에, 트랜잭션의 "읽기" 부분이 비용의 대부분을 차지합니다.
읽기 비용이 중요한 이유
최적화 전략
많은 팀이 생성 속도를 높여 매 생성 시간을 단축하기 위해 더 빠르거나 더 큰 모델에 자원을 쏟아붓습니다. 하지만 작업의 4분의 3이 단순히 컨텍스트를 불러오는 것이라면, 더 빠른 모델은 전체 시간의 극히 일부만 절약할 뿐입니다. 진정한 핵심은 모델이 매 턴 처리해야 하는 컨텍스트의 양입니다.
비용 제어
AI 어시스턴트가 매 요청마다 동일한 저장소 상태를 다시 읽으면 입력 토큰이 급증합니다. 컨텍스트 창이 큰 프로젝트는 생성된 코드의 양이 적더라도 비용이 급격히 늘어날 수 있습니다.
엔지니어링 초점
도구 개발자들은 종날 프롬프트가 어떻게 구성되는지는 간과한 채 모델의 품질을 높이는 데만 매달립니다. 이번 분석은 모델에 전달되는 코드를 다듬고(trimming), 캐싱하고(caching), 요약하는(summarizing) "컨텍스트 엔지니어링"이 점진적인 모델 업그레이드보다 더 큰 ROI를 제공한다는 점을 시사합니다.
읽기 오버헤드를 줄이기 위한 실질적인 단계
- 불필요한 파일 제거 – 현재 작업에 필요하지 않은 파일을 프롬프트에서 제외합니다. 프롬프트가 작아지면 입력 토큰이 줄어듭니다.
- 반복되는 읽기 작업 캐싱 – 코드베이스의 안정적인 부분에 대한 모델의 해석을 저장하고, 동일한 텍스트를 다시 보내는 대신 이를 여러 턴에 걸쳐 재사용합니다.
- 도구 출력 압축 – 외부 도구가 대량의 데이터(예: 린트 보고서)를 반환할 경우, Claude에 다시 전달하기 전에 요약합니다.
- 증분 디프(incremental diffs) 사용 – 파일 전체 내용 대신 마지막 턴 이후의 변경 사항만 보냅니다.
이러한 전략은 AI가 매 상호작용마다 동일한 저장소 스냅샷을 다시 읽는 것을 방지하여 지연 시간과 비용을 모두 줄이는 것을 목표로 합니다.
반론: 속도 또한 중요하다
일부 개발자들은 생성되는 25%의 토큰에 대한 지연 시간을 줄여주기 때문에 빠른 모델이 여전히 중요하다고 주장합니다. 즉각적인 응답이 필요한 IDE 플러그인과 같이 지연 시간에 민감한 환경에서는 매 밀리초가 중요합니다. 읽기 중심의 프로필이 빠른 모델의 이점을 없애는 것은 아니며, 단지 그 상대적인 영향력을 줄일 뿐입니다.
향후 주목할 점
Red Hat의 연구는 제한된 세션을 기반으로 하므로, 더 넓은 샘플링을 통해 다른 언어나 프로젝트 규모에 따른 다른 토큰 분포가 나타날 수 있습니다. 향후 데이터가 75%의 읽기 수치를 확인해 준다면, 컨텍스트를 자동으로 다듬고 캐싱하는 도구나 빠른 컨텍스트 인제스션(ingestion)에 최적화된 모델 아키텍처로의 전환이 일어날 수 있습니다.
핵심 요약: AI 지원 코딩에서 가장 저렴한 성능 향상은 모델을 더 빠르게 만드는 것이 아니라, 모델에 더 적은 정보를 제공하는 것에서 옵니다. Red Hat의 수치는 명확한 근거를 제시합니다. 프롬프트를 다듬고, 캐싱하고, 요약하십시오. 그러면 시간과 비용 모두에서 실질적인 절감 효과를 볼 수 있을 것입니다.