저는 코딩 에이전트(Claude Code, OpenCode)와 LLM 제공자 사이에서 투명한 리버스 프록시(reverse proxy)로 작동하며, 지연 시간(latency)을 추가하지 않고 모든 요청을 기록하는 로컬 우선(local-first) 프로파일러를 구축했습니다. 이는 에이전트를 위한 perf와 같으며, 토큰이 정확히 어디로 소비되는지 보여줍니다.

라이브 데모 (샘플 데이터가 포함된 읽기 전용 대시보드).

자체 세션을 프로파일링한 후 드러난 사실들

1. API 비용 중 실제 프롬프트(prompt)는 약 60%에 불과했습니다. 나머지는 제가 인지하지 못했던 에이전트 오버헤드(overhead)였습니다. 즉, 하위 에이전트 탐색(search), 컨텍스트 압축(context compaction), 자리를 비웠을 때의 추적 요약(catch-up summaries), 그리고 세션 제목 생성 등이 포함되었습니다. 프로파일러는 모든 요청을 11가지 유형(main, search, compact, recap, title, subagent, webfetch, quota, tool_result, guide, unknown)으로 분류하고 "유형별 비용(Cost by kind)" 테이블을 보여줍니다. 에이전트에게 "철저히 탐색해줘"라고 말했을 때, search 하위 에이전트 하나만으로 토큰의 약 25-30%를 소비했습니다.

2. 5분간의 캐시 TTL(Time To Live) 페널티는 실재하며 비용이 많이 듭니다. Claude Code는 명시적인 TTL 없이 cache_control: {"type": "ephemeral"} 마커를 배치합니다. 따라서 캐시된 접두사(prefix)(시스템 프롬프트, 도구, 메시지 기록)는 약 5분간의 비활성 상태 이후 만료됩니다. 문서를 읽거나 커피를 마시러 자리를 비웠다가 돌아오면, 다음 요청에서 잠재적으로 200K 이상의 토큰에 대해 전체 캐시 쓰기(cache write) 비용을 지불하게 됩니다. Opus 모델의 경우, 캐시 쓰기는 복귀 후 첫 번째 요청에서 엄청난 배율의 비용을 발생시킵니다. 프로파일러는 콜드 재생성(cold regenerations)을 감지하여 심각도 배지(severity badges)로 표시하고, 각 유휴 시간(idle gap)이 정확히 얼마의 비용을 발생시켰는지 보여줍니다.

3. 긴 세션은 이를 가중시킵니다. 매 턴마다 캐시된 접두사가 커지므로, 콜드 리프레시(cold-refresh) 비용은 선형적으로 증가합니다. 3시간 동안 지속된 세션은 만료될 때마다 200K 이상의 토큰을 다시 쓸 수 있습니다. 프로파일러는 시간에 따른 컨텍스트 성장(context growth)을 추적하며, 도구 정의(tool definitions)만으로 매 호출 시 10-15K 토큰이 재전송되는 경우를 플래그(flag)로 표시합니다.

4. 저는 몇 달 동안 최적화를 시도했지만 대부분 실패했습니다.

저는 완전한 최적화 계층(stale tool results pruning(오래된 도구 결과 제거), system prompts collapsing(시스템 프롬프트 압축), unused tools removal(미사용 도구 제거))을 구축하고 이를 벤치마크(benchmark)했습니다. 초기 수치는 놀라워 보였지만, 그것은 잘못된 것이었습니다. 세션 간 캐시 워밍(cache warming)이 베이스라인(baseline)을 부풀렸고, 비용 모델(cost model)은 초기에 캐시 쓰기(cache-write) 토큰을 무시했습니다. 이 두 가지가 모두 수정되자 절감 효과는 사라졌습니다. 캐시된 접두사(prefix)를 편집하면 저렴한 읽기(read)가 비싼 쓰기(write)로 변하며, 클라이언트는 어차피 매 턴마다 깨끗한 전체 히스토리(history)를 다시 전송합니다. 저는 이 사후 분석(autopsy) 내용을 리포지토리(repo)의 docs/optimization/FINDINGS.md에 작성해 두었습니다.

사용 방법

npm install -g ai-agent-profiler
aap install              # 설정 시드(seeds config)
aap serve                # 터미널 1: :8080/ui에서 프록시(proxy) + 대시보드(dashboard) 실행
...

Anthropic, OpenAI, DeepSeek, AWS Bedrock (SigV4), 그리고 Ollama를 지원합니다. 텔레메트리(telemetry)는 전혀 없으며, 비밀값(secrets)은 삭제(redacted)됩니다. 모든 메트릭(metrics)은 원시 트레이스(raw traces)로부터 재구축 가능합니다.

Repo: https://github.com/rguiu/ai-agent-profiler

피드백을 받고 싶은 부분

• 제가 놓치고 있는 프로파일링(profiling)의 사각지대는 무엇인가요? 현재 여러분의 에이전트에 대해 답할 수 없는 것은 무엇인가요?
• 프록시 레벨(proxy-level) 최적화를 시도하여 다른 경제적 수치를 경험한 분이 계신가요? 제가 기술적인 트릭을 놓친 것인가요, 아니면 제공업체의 캐시가 에이전트의 요청 방식에 대해 진정으로 최적에 가까운 것인가요?
• API 비용의 약 40%가 사용자 외 오버헤드(non-user overhead)라는 사실을 알게 된다면, 서브 에이전트(subagents)나 도구 브리프(tool briefs)를 구성하는 방식이 달라질까요?
• 5분간의 캐시 TTL(Time To Live)에 불편함을 느끼는 분이 또 계신가요? 실제 환경에서 관찰되는 실질적인 TTL은 어느 정도인가요?
• 셸 훅(Shell hooks) vs 구조화된 출력(structured output) — 토큰 효율적인 구조화된 출력을 사용하는 AI 네이티브 도구가 올바른 해결책일까요, 아니면 출력 필터링(output filtering)만으로도 충분할까요?