753달러 상당의 코딩 에이전트 사용량을 감사한 결과, 94.5%의 컨텍스트 재사용을 발견했습니다.

저는 프롬프트 캐싱 (Prompt caching)이 코딩 에이전트 (Coding agents)를 위한 가장 큰 비용 최적화 요소 중 하나가 될 것이라고 예상했습니다.

결국, 모든 요청에는 거의 변하지 않는 시스템 프롬프트 (System prompts), 도구 정의 (Tool definitions), 그리고 지침 (Instructions)이 포함되기 때문입니다. 이것들을 캐싱하는 것은 마치 공짜 돈을 얻는 것처럼 느껴졌습니다.

저는 또한 두 번째 레버로 '사용되지 않은 검색된 컨텍스트 (Unused retrieved context)'를 예상했습니다. 에이전트는 끊임없이 파일을 읽고, 로그를 가져오고, 디렉토리를 조사하며, 코드베이스 (Codebases)를 탐색합니다. 분명히 그 컨텍스트의 상당 부분은 최종 출력에 실제로 영향을 미치지 않을 것입니다.

그래서 저는 작은 도구인 context-audit를 구축했고, 이를 **753.24달러의 입력 비용 (Input spend)**을 나타내는 27개의 실제 코딩 에이전트 세션에 걸쳐 실행했습니다.

두 가지 가정 모두 벤치마크를 통과하지 못했습니다.

제가 측정한 것

27개 세션에 걸쳐:

지표	값
컨텍스트 재사용 (Context Reuse)	94.5%
...

프롬프트 캐싱 (Prompt caching)은 잠재적 절감액의 단 **1.0%**만을 차지했습니다.

사용되지 않은 검색된 컨텍스트 (Unused retrieved context)는 단 **0.4%**를 차지했습니다.

반면, 모든 컨텍스트 토큰의 94.5%는 반복되는 콘텐츠였습니다.

지배적인 비용은 사용되지 않은 검색 (Unused retrieval)이 아니었습니다.

정적인 프롬프트 (Static prompts)도 아니었습니다.

그것은 바로 누적된 대화 기록 (Accumulated conversation history)이었습니다.

세션이 길어짐에 따라 동일한 정보가 계속해서 반복해서 나타났습니다.

세션이 커질수록 더 반복적이었습니다

컨텍스트 재사용 (Context reuse)은 세션 크기에 따라 급격히 증가했습니다:

최종 컨텍스트 크기	평균 재사용
< 5k tokens	66.3%
...
세션이 오래 지속될수록 더 반복적이 되었습니다.

이는 제가 예상했던 결과가 아니었습니다.

저의 최적화 본능은 잘못된 병목 현상 (Bottleneck)을 가리키고 있었습니다.

통찰: 코딩 에이전트는 두 가지 메모리 시스템을 가지고 있습니다

트랜스크립트 (Transcripts)를 파헤치면서, 저는 코딩 에이전트를 챗봇 (Chatbots)과는 다르게 생각하기 시작했습니다.

그들은 두 개의 뚜렷한 메모리 시스템 (Memory systems)을 가지고 작동하는 것으로 보입니다.

워크스페이스 메모리 (Workspace Memory)

예시:

파일 (Files)
로그 (Logs)
터미널 출력 (Terminal outputs)
빌드 결과물 (Build artifacts)
컴파일러 오류 (Compiler errors)
디렉토리 구조 (Directory structures)

이러한 정보는 종종 디스크 (disk)에 존재합니다.

에이전트 (agent)는 워크스페이스 (workspace)를 다시 읽음으로써 이를 빈번하게 재구성할 수 있습니다.

대화 메모리 (Conversational Memory)

예시:

사용자 선호도 (User preferences)
설계 결정 (Design decisions)
거부된 아이디어 (Rejected ideas)
제약 사항 (Constraints)
트레이드오프 (Trade-offs)
아키텍처 근거 (Architectural rationale)

이 정보는 오직 대화 (conversation) 내부에만 존재합니다.

한번 제거되면, 영구적으로 사라질 수 있습니다.

이러한 차이점은 제가 컨텍스트 관리 (context management)를 생각하는 방식을 바꾸어 놓았습니다.

모든 컨텍스트가 동일하게 폐기 가능한 것은 아닙니다.

가지치기 실패 모드 (A Pruning Failure Mode)

긴 코딩 세션을 상상해 보세요.

대화 초기에 사용자는 다음과 같이 결정합니다:

임베딩 (embeddings) 사용 안 함
LLM-as-a-judge 사용 안 함
HTML 대시보드 사용 안 함

팀은 대안을 논의하고 더 단순한 접근 방식에 동의합니다.

50번의 턴 (turns)이 지난 후, 이러한 결정들은 대화 기록 (conversation history) 외에는 어디에도 남아 있지 않을 수 있습니다.

워크스페이스 (workspace)에는 여전히 코드가 남아 있습니다.

하지만 거부된 모든 경로가 들어 있는 것은 아닙니다.

단순한 가지치기 (pruning) 전략은 오래된 대화 노이즈 (noise)처럼 보이는 것들을 제거합니다.

불행하게도, 이는 프로젝트의 근거 (reasoning)까지 함께 제거할 수 있습니다.

그 결과, 에이전트 (agent)가 사용자가 이전에 명시적으로 거부했던 아이디어를 갑자기 다시 추천하기 시작하는 상황이 발생합니다.

구체적으로, 주로 최신성 (recency)을 기준으로 압축하는 요약기 (summarizer)는 다음과 같은 것들은 보존할 수 있습니다:

최신 파일 트리 (file tree),
최근 명령 출력 (command outputs),
최근 컴파일러 로그 (compiler logs),

반면, 수십 번의 턴 이전에 내려진 중요한 설계 결정 (design decision)은 누락시킵니다.

비싸 보이는 컨텍스트는 살아남습니다.

실제로 중요했던 저렴해 보이는 컨텍스트는 사라집니다.

이것이 중요한 이유

만약 당신이 장기 실행되는 코딩 에이전트 (coding-agent) 세션을 수동으로 가지치기 (pruning), 요약 (summarizing), 또는 압축 (compressing)하고 있다면, 컨텍스트의 비용이 많이 드는 부분이 아니라 결정의 근거 (rationale)를 삭제하고 있는 것일지도 모릅니다.

워크스페이스 상태 (Workspace state)는 종종 재구성 가능합니다.

대화상의 결정 (Conversational decisions)은 재구성이 불가능한 경우가 많습니다.

이것이 가지치기 (pruning)가 틀렸다는 뜻은 아닙니다.

가지치기는 다음을 구분해야 한다는 의미입니다:

워크스페이스 (workspace)에서 복구 가능한 기술적 실행 이력 (Technical execution history).
대화 (conversation) 내에만 존재하는 정렬 이력 (Alignment history).

두 범주를 동일하게 취급하면 미묘한 퇴보 (regressions)가 발생할 수 있습니다.

이것이 증명하는 것은 아닙

이것은 보편적인 법칙이 아닙니다.

27개의 세션은 흥미로운 관찰을 하기에는 충분하지만, 모든 코딩 에이전트 (coding agent)가 이와 같이 동작한다고 주장하기에는 충분하지 않습니다.

이 벤치마크 (benchmark)는 디스크 기반 상태 (disk-backed state)를 가진 코딩 에이전트 워크플로 (workflows)를 다룹니다.

다음은 포함하지 않습니다:

RAG 시스템
일반 챗봇 (General chatbots)
연구 에이전트 (Research agents)
고객 지원 에이전트 (Customer support agents)
기타 비코딩 워크플로 (non-coding workflows)

결과물은 해당 범위 내에서 해석되어야 합니다.

하지만 이 결과는 제 예상을 뒤엎기에 충분했습니다.

저는 프롬프트 캐싱 (prompt caching)과 검색 (retrieval) 낭비가 지배적일 것이라고 예상하며 이 프로젝트를 시작했습니다.

이 데이터셋에서 그것들은 거의 영향을 미치지 못했습니다.

직접 시도해 보세요

# 단일 트랜스크립트 (transcript) 감사
context-audit run transcript.jsonl

...

도구는 다음을 보고합니다:

컨텍스트 재사용 비율 (Context reuse ratios)
추정 비용 (Estimated costs)
반복되는 블록 (Repeated blocks)
컨텍스트 성장 패턴 (Context growth patterns)
잠재적인 캐싱 절감액 (Potential caching savings)

저장소 (Repository)

GitHub: context-audit

이 벤치마크는 코딩 에이전트 메모리에 대한 제 생각을 바꾸어 놓았습니다.

저는 정적 프롬프트 (static prompts)와 검색에서의 낭비를 찾기 위해 이 프로젝트를 시작했습니다.

대신, 저는 시스템이 컨텍스트 예산 (context budget)의 대부분을 자신의 이력을 전달하는 데 소비하고 있다는 것을 발견했습니다.

만약 여러분이 Claude Code, Cursor, Aider 또는 이와 유사한 코딩 에이전트 워크플로를 길게 실행하고 있다면, 여러분도 동일한 패턴을 보고 있는지 알고 싶습니다.