1줄 정의

동일 프리픽스 (system·tools·context) 를 재전송 않고 서버에 남겨 재사용해 입력비 1/10·지연 단축을 노리는 최적화.

전체 시스템에서 맡는 역할

프롬프트 캐싱은 LLM 을 쓸 때 “입력 비용과 레이턴시의 지배 요인” 을 깎는 층 이다.

LLM 한 번 호출할 때마다 매번 똑같은 걸 실어 보내는 부분이 있다.

• system prompt (에이전트 성격·룰·툴 설명)
• tool definitions (MCP, function calling 규격)
• 큰 문맥 (문서, 코드베이스, 과거 대화 이력)

이 프리픽스는 요청마다 달라지지 않는데, 일반 API 에서는 매번 풀로 token 과금되고 매번 풀로 처리된다. 대화나 에이전트 턴이 길어질수록 같은 긴 프리픽스를 계속 실어 보내는 꼴이 된다.

프롬프트 캐싱은 여기를 분리한다. 지정한 프리픽스를 서버 쪽 임시 캐시 (ephemeral cache) 에 올려 두고, 다음 요청에서 “앞과 같은 프리픽스입니다” 라고 참조하면 캐시 히트 부분은

• 입력 비용이 최대 1/10 수준까지 내려가고 (Anthropic docs 기준)
• 처리 시간도 그만큼 줄어든다

Anthropic 의 API 에서는 Messages API 의 블록 단위로 cache_control: { type: "ephemeral" } 를 명시적으로 붙인다. system, tools, 개별 content block 까지 각각 붙일 수 있어서 “어디부터 재사용할지” 를 엔지니어가 나눈다. TTL 은 기본 5 분이고, 같은 프리픽스가 그 안에 다시 쓰이면 히트, 안 쓰면 사라진다.

반면 OpenAI 는 동급 메커니즘을 자동 prompt caching 으로 투명하게 제공 한다. 개발자 쪽에서 cache_control 을 붙일 필요가 없고, 같은 프리픽스가 연달아 쓰이면 알아서 캐시가 걸린다. 선언형 Anthropic 과 암묵형 OpenAI, 이 차이가 같은 “프롬프트 캐싱” 이라도 운용 설계를 많이 다르게 만든다.

Claude Code 같은 agent harness 에서는 이 캐시가 먹느냐 마느냐로 턴당 비용이 한 자릿수 달라진다. 즉 이 용어는 “세세한 API 최적화” 가 아니라 에이전트 운용의 경제성을 결정하는 기둥 에 있다.

흔한 오해

• 오해 1: 프롬프트 캐싱 = 출력을 재사용하는 구조, 라고 여겨지기 쉽다.

– 실제로는 “입력 프리픽스의 처리 결과를 재사용” 하는 구조다. 출력은 매번 새로 생성된다. 같은 질문을 두 번 보내면 모델도 두 번 생각한다. 싸지는 건 입력 쪽 전처리다.

• 오해 2: 캐싱이 있으면 context window 를 사실상 무한으로 쓸 수 있다, 고 기대하기 쉽다.

– 실제로는 캐시되어 있어도 그 프리픽스는 모델 컨텍스트에 제대로 올라가야 한다. 1M 토큰을 캐시해 둬도 1M 이 넘는 입력은 안 들어간다. 캐싱은 용량을 늘리는 기능이 아니라 같은 용량을 싸게 쓰게 해주는 기능이다.

• 오해 3: Anthropic 의 prompt caching 은 붙이면 항상 이득, 이라고 단순화되기 쉽다.

– 실제로는 cache write 자체가 25% 비싼 토큰 레이트 로 과금된다. 1 회성 짧은 호출에 cache_control 을 붙이면 히트 없이 비싸기만 한다. 5 분 TTL 안에 같은 프리픽스를 여러 번 때리는 시나리오가 있어야 비로소 이득이 난다.

이 용어가 중요한 이유

독자의 실무 판단에 이게 꽂히는 이유는, “AI 앱의 월 운영비가 현실적인가” 를 결정하는 층이기 때문이다.

에이전트나 사내 AI 툴을 굴릴 때 자주 막히는 질문은 이런 것이다.

• system prompt 와 tool 정의에 매번 2,000 토큰을 쓰고 있다. 반년 돌리면 얼마인가
• RAG 로 항상 20,000 토큰 가이드를 얹고 있는데, 이게 유저당 원가를 결정한다
• Claude Code / Codex 에서 세션이 길어질수록 느려지는 이유는 무엇인가

여기에 대해 “프롬프트 캐싱을 걸면 몇 할 회수되는가” 를 말할 수 있느냐로, 제품의 마진율과 에이전트 운영 지속성이 달라진다. 1M context 이야기가 모델 선택의 입구라면, prompt caching 은 그 선택한 모델을 사업으로 굴리는 쪽의 입구다.

이 용어가 나오는 기사

• (발행 후 추가)

다음에 읽을 용어 3개

• token — 과금 단위. 캐싱 효과를 금액으로 말하려면 먼저 여기.
• context window — “용량” 축. 캐싱은 “비용” 축에서 같은 용량을 싸게 쓰는 쪽.
• API — cache_control 이 실제로 붙는 구현 레이어.