요약: Claude Prompt Caching은 반복되는 시스템 프롬프트, 문서 컨텍스트, 도구 정의를 캐시해 비용과 처리 시간을 줄이는 기능이다. OpenAI와 달리 Anthropic은 cache_control을 사용해 자동 캐싱 또는 명시적 breakpoint를 설정할 수 있으므로 프롬프트 구조를 더 의식적으로 설계해야 한다.
Anthropic 문서에 따르면 Claude Prompt Caching은 반복 작업이나 일관된 요소를 가진 프롬프트에서 특정 prefix를 재사용해 처리 시간과 비용을 줄인다. 지원 모델은 active Claude models이며, 최신 문서 예시는 claude-opus-4-8을 사용한다. 캐시는 기본적으로 5분 수명을 가지며, 추가 비용으로 1시간 캐시 duration도 제공된다.
가장 단순한 사용법은 요청 top-level에 cache_control: { type: "ephemeral" }을 추가하는 자동 캐싱이다. 이 경우 시스템은 캐시 가능한 마지막 블록까지를 자동으로 캐시하고, 대화가 길어지면 breakpoint를 앞으로 이동시킨다. 더 세밀하게 제어하려면 content block에 직접 cache_control을 붙이는 explicit cache breakpoint 방식을 쓴다.
이 기능은 특히 긴 시스템 지침, 긴 reference document, 도구 목록, multi-turn conversation, few-shot examples가 반복되는 서비스에 유리하다. 단, 캐시가 유리하다고 모든 데이터를 오래 붙잡아두면 안 된다. 프롬프트 구조, 비용, 개인정보, Zero Data Retention 요구를 함께 봐야 한다.
Claude 캐싱은 큰 prefix가 반복될 때 효과가 난다. 예를 들어 법률 문서 분석 앱에서 매 요청마다 30페이지 약관, 분석 기준, 출력 스키마, 예시를 함께 보낸다면 입력 비용이 커진다. 이 문서와 지침이 여러 질문에서 반복된다면 캐시를 붙이는 것이 합리적이다.
코딩 에이전트도 좋은 후보이다. 저장소 규칙, 아키텍처 설명, 테스트 실행 정책, 코드 스타일, 위험 명령 금지 규칙은 세션 동안 반복된다. 사용자 요청과 현재 diff만 바뀐다. 이때 반복 prefix를 캐시하면 multi-turn 작업의 비용과 latency를 줄일 수 있다.
반대로 매 요청마다 완전히 다른 짧은 프롬프트라면 효과가 작다. 캐시 write 비용도 고려해야 한다. Anthropic 가격표는 5분 cache write가 base input token의 1.25배, 1시간 cache write가 2배, cache read가 0.1배라는 multiplier 구조를 설명한다. 즉 한 번 쓰고 다시 읽지 않는 prefix는 오히려 비효율적일 수 있다.
Claude Opus 4.8 기준으로 문서에 나온 가격은 base input $5/MTok, 5분 cache write $6.25/MTok, 1시간 cache write $10/MTok, cache hit/read $0.50/MTok, output $25/MTok이다. Claude Sonnet 4.6은 base input $3/MTok, 5분 write $3.75, 1시간 write $6, read $0.30, output $15 구조다.
이 말은 반복 사용 횟수가 중요하다는 뜻이다. 100k token짜리 문서를 한 번 캐시하고 한 번만 읽으면 write 비용 때문에 이득이 제한된다. 하지만 같은 문서를 세션에서 여러 번 읽으면 두 번째부터 read 단가가 크게 낮아진다. 특히 긴 context 기반 질의응답, repository-aware coding, 대형 정책 문서 분석처럼 한 prefix를 여러 번 참조하는 워크로드에서 유리하다.
간단한 판단 기준은 이렇다. 같은 prefix가 몇 분 안에 2회 이상 재사용되는가. prefix가 충분히 긴가. output 비용보다 input 비용이 병목인가. latency가 사용자 경험에 영향을 주는가. 네 질문에 '예'가 많으면 캐싱 후보로 볼 수 있다.
자동 캐싱은 시작하기 쉽다. multi-turn 대화에서 메시지 history가 자라나는 구조라면 top-level cache_control만으로도 충분할 수 있다. 팀이 처음 도입할 때는 자동 캐싱으로 usage를 측정하고, hit rate와 비용 절감이 보이는 endpoint부터 명시적 breakpoint로 개선하는 순서가 안전하다.
명시적 breakpoint는 prefix 경계가 분명할 때 좋다. 예를 들어 system에는 역할과 정책을 두고, 첫 번째 user content block에는 긴 문서, 두 번째 block에는 질문을 둔다면 긴 문서 끝에 cache_control을 붙일 수 있다. 그러면 질문이 바뀌어도 문서 부분을 재사용하기 쉽다.
주의할 점은 cache가 prefix를 기준으로 동작한다는 것이다. tool 정의, system, messages 순서가 바뀌면 캐시가 깨질 수 있다. 도구 목록은 안정된 순서로 두고, 불필요하게 매 요청 생성되는 timestamp나 request id를 앞부분에 넣지 않는다. 질문별로 바뀌는 데이터는 cache breakpoint 뒤에 둔다.
문서 QA 서비스를 예로 들자. 사용자가 PDF 하나를 업로드하고 여러 질문을 한다. 첫 요청에서 문서를 chunk로 정리하고, 문서 원문 또는 요약, 답변 규칙, 인용 형식을 prefix로 만든다. 이 prefix에 cache_control을 붙인다. 이후 사용자의 개별 질문은 prefix 뒤에 붙인다.
응답 usage에서 cache_creation_input_tokens와 cache_read_input_tokens 같은 지표를 수집한다. 첫 질문은 cache write가 발생해 비용이 높을 수 있지만, 두 번째 질문부터 read token이 늘어나야 한다. 그렇지 않다면 prefix가 매번 달라지고 있다는 뜻이다. 이때 문서 정렬, whitespace, serializer, metadata 순서를 점검한다.
세션이 길어질수록 전체 대화 history를 계속 붙이는 대신, 안정된 문서 prefix와 최근 대화 요약을 분리한다. 요약은 변하는 데이터이므로 캐시 구간 뒤에 놓거나 별도 breakpoint 전략을 둔다. 이렇게 해야 캐시가 깨지지 않으면서도 맥락을 유지할 수 있다.
Anthropic 문서는 prompt caching이 Zero Data Retention arrangement가 있는 조직에서도 응답 반환 후 데이터가 저장되지 않는 방식으로 사용할 수 있다고 설명한다. 다만 조직의 계약, 클라우드 경로, 5분/1시간 캐시 설정에 따라 정책 확인이 필요하다. 민감한 고객 데이터는 캐시에 올리기 전에 최소화하고, 꼭 필요한 범위만 넣는 것이 안전하다.
또한 캐시가 비용을 줄인다는 이유로 권한이 다른 사용자 간 prefix를 공유하면 안 된다. 같은 문서라도 사용자 권한이 다르면 cache key나 세션 경계를 분리해야 한다. 비용 최적화보다 데이터 격리가 우선이다.
Claude 캐싱을 도입했다면 endpoint별로 cache write token, cache read token, total input token, output token, latency를 기록한다. 배포 전후로 read 비율이 증가하는지 확인한다. 갑자기 read token이 줄면 프롬프트 빌더 변경이 prefix 안정성을 깨뜨렸을 가능성이 높다.
프롬프트 생성 함수에는 snapshot test를 넣는다. 같은 문서와 같은 도구 목록을 넣었을 때 cache breakpoint 이전 문자열이 완전히 같은지 확인한다. JSON 직렬화는 key 정렬을 적용하고, 배열 순서는 명시적으로 고정한다. 프롬프트 캐싱은 프롬프트 엔지니어링이면서 동시에 일반적인 캐시 시스템 운영이다.
cache_control 자동 캐싱으로 측정한다.출처: Anthropic Docs, Prompt caching; Anthropic Models overview and pricing.