멀티턴 에이전트 작업에서 프롬프트 캐싱을 어떻게 구성하느냐에 따라 비용과 지연이 크게 달라진다. “Don’t Break the Cache” 논문은 OpenAI, Anthropic, Google 세 프로바이더에서 500회 이상의 에이전트 세션을 실행해 세 가지 캐싱 전략을 비교·측정한 최초의 실증 연구다.

배경

LLM 에이전트는 도구 호출(tool call)을 수십 회 반복하며 컨텍스트 창이 계속 누적된다. 프로바이더들은 프롬프트 캐싱을 제공하지만, 실제 에이전트 작업에서 어떤 전략이 효과적인지에 대한 체계적 연구는 부족했다.

연구팀은 DeepResearch Bench(실제 웹 검색 도구 호출이 포함된 멀티턴 에이전트 벤치마크)에서 10,000토큰 시스템 프롬프트 환경으로 실험을 진행했다.

세 가지 캐싱 전략

핵심 결과

• 비용 절감: 전략에 따라 41~80%
• 첫 토큰 지연(TTFT) 개선: 13~31%
• 선형 효과: 프롬프트 크기(500~50,000토큰)와 도구 호출 횟수(3~50회)에서 모두 선형적 비용·지연 개선 확인

중요한 발견: 전체 컨텍스트 캐싱(naïve approach)이 역설적으로 지연을 증가시키는 경우가 있다. 동적 콘텐츠가 끼어들어 캐시 블록이 깨지기 때문이다.

실전 가이드라인

동적 콘텐츠를 시스템 프롬프트 끝에 배치하라

[정적 지침]        ← 캐시 히트
[도구 목록 정의]   ← 캐시 히트
[동적 컨텍스트]    ← 캐시 미스 (끝에 배치해 앞부분 캐시 보호)

동적 함수 호출 정의를 피하라

매 요청마다 함수 시그니처가 달라지면 캐시가 깨진다. 정적 도구 목록을 시스템 프롬프트에 고정하고, 동적으로 활성화/비활성화 하지 말 것.

동적 툴 결과는 캐시 대상에서 제외하라

웹 검색 결과, 코드 실행 출력처럼 매번 달라지는 도구 결과를 캐시 블록에 포함시키면 캐시 효율이 급락한다.

프로바이더별 차이

세 프로바이더가 캐싱 전략에 따라 다른 성능 프로파일을 보인다. 프로바이더 전환 시 캐시 구성을 재검증해야 한다.

논문 정보

• arXiv: 2601.06007
• 저자: Elias Lumer 외 6인
• 발행: 2026년 1월 (v2: 2026년 1월 31일)
• 페이지: 16페이지, 9개 그림

관련 문서

• inference-caching — 프롬프트 캐시·KV캐시·시맨틱 캐시 개념 정리
• rag — 정적 문서 반복 활용 시 캐싱과 연계 전략
• claude-agent-sdk — Claude Agent SDK에서 캐싱 적용