본문으로 건너뛰기
블로그로 돌아가기
프롬프트 캐싱 완벽 가이드: Anthropic이 공개한 Claude Code의 비용 최적화 비밀

프롬프트 캐싱 완벽 가이드: Anthropic이 공개한 Claude Code의 비용 최적화 비밀

11분 읽기0

프롬프트 캐싱 완벽 가이드: Anthropic이 공개한 Claude Code의 비용 최적화 비밀

프롬프트 캐싱은 Claude API 입력 토큰 비용을 최대 90% 절감하는 기술입니다. Anthropic Claude Code 팀은 캐시 히트율 하락을 서버 장애와 동급의 프로덕션 인시던트로 취급합니다.

AI 에이전트를 운영하면서 API 비용 청구서에 놀란 적이 있다면, 이 글이 답을 줄 것입니다. Anthropic의 Claude Code 엔지니어 Thariq가 직접 공개한 프롬프트 캐싱 최적화 전략을 분석합니다. 단순한 기능 소개가 아니라, 실제 프로덕션 시스템에서 검증된 설계 원칙과 구체적인 비용 수치를 함께 다룹니다.

프롬프트 캐싱이란 무엇인가

프롬프트 캐싱은 웹 브라우저의 캐시와 같은 원리입니다. 한번 방문한 웹사이트의 이미지와 스타일을 브라우저가 저장해두면, 다음에 같은 페이지를 열 때 다시 다운로드하지 않아도 되는 것처럼, LLM API도 이전 요청에서 처리한 프롬프트를 재활용할 수 있습니다.

프리픽스 매칭 방식으로 작동합니다. API는 요청의 시작부터 cache_control 브레이크포인트까지의 내용을 암호화 해시로 비교합니다. 이전 요청과 앞부분이 동일하면 캐시 히트가 발생하고, 해당 구간의 연산을 재활용합니다.

핵심은 순서입니다. 도서관 책장에 책이 순서대로 꽂혀 있다고 생각해보세요. 중간에 한 권을 빼거나 추가하면 그 뒤의 모든 책 위치가 밀리는 것처럼, 프롬프트의 앞부분이 바뀌면 그 이후 전체 캐시가 무효화됩니다.

비용 구조

프롬프트 캐싱의 경제학은 세 가지 가격으로 구성됩니다:

항목승수설명
캐시 쓰기 (5분 TTL)1.25x첫 요청 시 캐시 생성 비용
캐시 쓰기 (1시간 TTL)2.0x장기 캐시 생성 비용
캐시 읽기0.1x기본 가격의 10% (90% 할인)

모델별로 환산하면 그 차이가 확연합니다:

모델기본 입력 가격캐시 읽기 가격절감액
Claude Opus 4.6$15/MTok$1.50/MTok$13.50 절약
Claude Sonnet 4.6$3/MTok$0.30/MTok$2.70 절약
Claude Haiku 4.5$1/MTok$0.10/MTok$0.90 절약

Claude Code가 프롬프트 캐싱 위에 세워진 이유

Anthropic의 Claude Code 엔지니어 Thariq는 이렇게 말합니다:

"엔지니어링에서 흔히 'Cache Rules Everything Around Me'라고 하는데, 에이전트에도 같은 법칙이 적용됩니다."

Claude Code 같은 장기 실행 에이전트는 프롬프트 캐싱 없이는 실현 자체가 불가능합니다. 매 턴마다 시스템 프롬프트, 도구 정의, 프로젝트 컨텍스트, 대화 히스토리를 전부 보내야 하는데, 캐싱이 없으면 이 비용이 기하급수적으로 증가하기 때문입니다.

캐시 미스 = 프로덕션 인시던트

Claude Code 팀은 캐시 히트율에 알림을 설정하고, 히트율이 떨어지면 SEV(Severity) 인시던트를 선언합니다. 서버 다운이나 데이터 손실과 같은 수준으로 취급하는 것입니다.

이는 단순한 비용 문제를 넘어서는 결정입니다. 캐시 미스율이 몇 퍼센트만 증가해도, 수백만 요청에 걸쳐 인프라 예산이 하루 만에 폭증할 수 있기 때문입니다. 높은 캐시 히트율은 비용 절감뿐 아니라, 구독 플랜에서 더 관대한 Rate Limit을 제공할 수 있게 해줍니다.

고비용 모델 + 캐싱의 역설

LangChain의 Lance Martin이 정리한 에이전트 설계 패턴에서 흥미로운 인사이트가 나옵니다:

"높은 용량($/토큰) 모델에 캐싱을 적용하면, 캐싱 없는 저비용 모델보다 실제로 더 저렴할 수 있습니다."

100K 토큰 대화 중에 간단한 질문을 처리하려고 Opus에서 Haiku로 전환하면, Haiku의 프롬프트 캐시를 처음부터 다시 구축해야 합니다. 이 캐시 재구축 비용이 Opus가 직접 답변하는 비용보다 클 수 있습니다.

Anthropic이 공개한 6가지 캐싱 최적화 전략

1. 정적 콘텐츠를 앞에, 동적 콘텐츠를 뒤에 배치

Claude Code의 프롬프트 구조는 다음 순서를 철저히 따릅니다:

  1. 정적 시스템 프롬프트 + 도구 정의 (전역 캐시)
  2. CLAUDE.md 프로젝트 설정 (프로젝트별 캐시)
  3. 세션 컨텍스트 (세션별 캐시)
  4. 대화 메시지 (동적, 매 턴 변경)

이 순서가 깨지면 캐시 효율이 급격히 떨어집니다. Thariq는 실제로 캐시를 깨뜨렸던 사례들을 공유했습니다:

  • 정적 시스템 프롬프트에 상세한 타임스탬프를 삽입
  • 도구 정의의 순서를 비결정적으로 셔플
  • 도구 파라미터를 동적으로 변경 (예: AgentTool이 호출할 수 있는 에이전트 목록 갱신)

arXiv 논문 "Don't Break the Cache"도 이를 학술적으로 뒷받침합니다. 전략적 캐시 블록 제어(동적 콘텐츠를 끝에 배치)가 naive 전체 캐싱보다 일관된 이점을 제공하며, API 비용을 41-80% 절감하고 TTFT(Time to First Token)를 13-31% 개선한다는 결과를 보여줍니다.

2. 정보 업데이트는 메시지로 처리

시스템 프롬프트에 "현재 시각: 수요일 오후 3시"라고 넣어두었는데, 목요일이 되면 어떻게 해야 할까요? 직관적으로는 시스템 프롬프트를 수정하고 싶지만, 그러면 캐시가 깨집니다.

Claude Code의 해법은 <system-reminder> 태그입니다. 다음 사용자 메시지나 도구 결과에 업데이트된 정보를 태그로 감싸서 추가합니다. 프리픽스는 건드리지 않고 메시지만 추가하는 방식으로 캐시를 보존합니다.

3. 세션 중간에 모델을 바꾸지 않기

프롬프트 캐시는 모델별로 분리됩니다. Opus와 Haiku는 서로 다른 캐시 공간을 사용합니다.

100K 토큰 대화를 진행하다가 간단한 질문을 위해 Haiku로 전환하면, Haiku에서 100K 토큰 전체의 캐시를 새로 구축해야 합니다. 이 비용은 Opus가 직접 답변하는 것보다 비쌀 수 있습니다.

해결책: Sub-agent 패턴. 모델 전환이 필요하면, Opus가 다른 모델에게 전달할 "핸드오프 메시지"를 준비합니다. Claude Code의 Explore 에이전트가 이 패턴으로 Haiku를 사용합니다. 메인 대화의 캐시는 건드리지 않고, 별도 컨텍스트에서 작업하는 것입니다.

4. 세션 중간에 도구를 추가하거나 제거하지 않기

도구 세트 변경은 프롬프트 캐싱을 깨뜨리는 가장 흔한 원인입니다. 직관적으로는 현재 필요한 도구만 제공하는 것이 효율적으로 보이지만, 도구 정의가 캐시 프리픽스에 포함되어 있어서 하나만 바꿔도 전체 대화의 캐시가 무효화됩니다.

Plan 모드의 영리한 설계: 사용자가 Plan 모드를 켜면, 읽기 전용 도구만 남기는 것이 직관적인 접근입니다. 하지만 Claude Code는 모든 도구를 그대로 유지하고, EnterPlanModeExitPlanMode를 도구로 추가했습니다. 모드 전환 자체가 도구 호출로 처리되기 때문에, 도구 세트가 변하지 않고 캐시도 보존됩니다.

보너스 효과도 있습니다. EnterPlanMode가 도구이기 때문에, 모델이 어려운 문제를 감지하면 스스로 Plan 모드에 진입할 수 있습니다. 캐시 무효화 없이 자율적으로 모드를 전환하는 것입니다.

5. Tool Search와 defer_loading 패턴

Claude Code는 MCP를 통해 수십 개의 도구를 지원합니다. 모든 도구의 전체 스키마를 매 요청에 포함하면 약 122,800 토큰이 필요합니다. 그렇다고 필요 없는 도구를 빼면 캐시가 깨집니다.

해결책: 경량 스텁 + 온디맨드 로딩

// 경량 스텁 (항상 프리픽스에 포함)
{ "name": "mcp__gmail__send", "defer_loading": true }
{ "name": "mcp__calendar__create", "defer_loading": true }
// ... 수십 개의 스텁이 동일 순서로 유지

// 모델이 도구 필요 시 → ToolSearch 호출 → 전체 스키마 로드

스텁은 매 요청마다 동일 순서로 유지됩니다. 모델이 도구가 필요하면 ToolSearch를 호출하여 전체 스키마를 로드합니다. 이 방식으로 191,300 토큰(약 85%)을 절약하면서도 캐시 프리픽스를 안정적으로 유지합니다.

6. Compaction: 캐시를 보존하며 컨텍스트 압축

대화가 200K 토큰 컨텍스트 윈도우를 초과하면 요약(Compaction)이 필요합니다. 단순 구현은 별도 API 호출로 요약을 생성하는 것인데, 이렇게 하면 메인 대화의 캐시 프리픽스와 일치하지 않아서 전액 과금됩니다.

캐시 친화적 Compaction 설계: Claude Code는 Compaction 시에도 원래 대화와 동일한 시스템 프롬프트, 사용자 컨텍스트, 도구 정의를 유지합니다. 부모 대화의 메시지를 앞에 넣고, Compaction 프롬프트를 마지막 사용자 메시지로 추가합니다.

API 관점에서 이 요청은 부모 대화의 마지막 요청과 거의 동일하게 보입니다. 같은 프리픽스, 같은 도구, 같은 히스토리이므로 캐시가 재활용됩니다. 새로 과금되는 토큰은 Compaction 프롬프트뿐입니다.

Auto-caching: 캐시 관리의 자동화

Anthropic은 수동 캐시 관리의 복잡성을 줄이기 위해 Auto-caching을 출시했습니다.

기존에는 개발자가 cache_control 브레이크포인트를 수동으로 지정해야 했습니다. 어디에 캐시 포인트를 넣을지, 대화가 길어지면 어떻게 이동시킬지 직접 관리해야 했습니다.

Auto-caching은 단일 cache_control 필드를 요청 본문 최상위에 추가하면 됩니다:

{
  "model": "claude-sonnet-4-6-20260320",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "messages": [...]
}

시스템이 마지막 캐싱 가능 블록에 자동으로 브레이크포인트를 적용하고, 대화 성장에 따라 캐시 포인트를 자동으로 전진시킵니다. 추가로 Cache-aware Rate Limits도 도입되어, 캐시 읽기 토큰이 ITPM(Input Tokens Per Minute) 제한에 포함되지 않습니다.

실무 적용 체크리스트

프롬프트 캐싱을 자신의 프로젝트에 적용할 때 참고할 핵심 원칙입니다:

  1. 프리픽스 매치: 프리픽스 어디든 변경이 생기면 그 이후 전체 캐시가 무효화됩니다.
  2. 메시지로 업데이트: 시스템 프롬프트 수정 대신 메시지에 <system-reminder>로 정보를 전달하세요.
  3. 모델/도구 고정: 세션 중간에 모델이나 도구를 바꾸지 마세요. 상태 전환은 도구로 모델링하세요.
  4. 캐시 히트율 모니터링: 업타임을 감시하듯 캐시 히트율도 감시하세요.
  5. 포크 연산의 프리픽스 공유: Compaction 같은 포크 연산은 부모의 프리픽스를 공유해야 합니다.
  6. Auto-caching 활용: 수동 브레이크포인트 관리 대신 Auto-caching으로 시작하세요.

FAQ

Q. 프롬프트 캐싱과 KV 캐시는 같은 건가요?

프롬프트 캐싱은 KV 캐시를 기반으로 합니다. 트랜스포머 모델의 Key-Value 캐시를 API 레벨에서 관리하는 것으로, 개발자가 직접 KV 캐시를 다룰 필요 없이 cache_control 파라미터만으로 활용할 수 있습니다.

Q. 캐시 TTL 5분과 1시간 중 어떤 것을 선택해야 하나요?

5분 TTL이 기본이며 캐시 쓰기 비용이 1.25x입니다. 1시간 TTL은 2.0x 비용이 들지만 장기 실행 에이전트 워크플로우에 적합합니다. 요청 간격이 5분 이내라면 기본 TTL로 충분하고, 사용자의 생각 시간이 길거나 비동기 워크플로우라면 1시간 TTL이 유리합니다.

Q. Compaction API는 프로덕션에서 사용해도 되나요?

현재 Beta 상태입니다 (compact-2026-01-12 헤더 필요). 기능적으로는 Claude Code에서 프로덕션 사용 중이지만, API 인터페이스가 변경될 수 있으므로 주의가 필요합니다.

Q. 프롬프트 캐싱은 출력 품질에 영향을 주나요?

영향 없습니다. 캐시된 토큰이든 새로 처리된 토큰이든, 모델의 출력 품질은 동일합니다. 캐싱은 순수하게 연산 재활용이며, 모델의 추론 과정에는 영향을 주지 않습니다.

마무리: 프리픽스 중심 설계의 시대

프롬프트 캐싱은 단순한 비용 절감 기술이 아닙니다. Anthropic이 Claude Code를 설계하면서 보여준 것처럼, 캐시 프리픽스를 보호하는 것이 아키텍처의 제1원칙이 될 수 있습니다. 모델 중심도, 기능 중심도 아닌 프리픽스 중심 설계가 에이전트 시대의 새로운 패러다임입니다.

AI 에이전트를 구축하고 있다면, 지금 당장 여러분의 프롬프트 순서를 점검해보세요. 정적 콘텐츠가 앞에 있는지, 도구 정의가 고정되어 있는지, 캐시 히트율을 모니터링하고 있는지. 이 세 가지만 확인해도 API 비용이 극적으로 줄어들 수 있습니다.


참고 자료