Claude Code의 Cache Write, AI 가성비의 열쇠

프롬프트 캐싱: Claude Code의 'Cache Write'부터 2026년 AI 가성비 엔지니어링까지

2026년 5월 12일 · 분석 리포트 · AI Engineering

💡 Claude Code 상태 화면의 'Cache Write' 한 줄은 단순한 통계가 아닙니다. 본 보고서는 이 항목의 기술적 실체에서 출발해, LLM 프롬프트 캐싱의 작동 원리, 사용자 제어 가능성, 활용 사례, 토큰 효율화 전략, 그리고 2026년 AI 엔지니어들이 추구하는 가성비·퍼포먼스 최적화 트렌드와 보안 리스크까지를 통합적으로 분석합니다.

1. 질문의 출발점: 'Cache Write'는 무엇인가

Claude Code의 /status 또는 사용량 화면에서는 모델별로 Input · Output · Cache Read · Cache Write 토큰이 분리되어 표기됩니다. 여기서 말하는 '캐시'는 일반적인 웹 캐시(브라우저·CDN)나 RAG의 벡터 캐시와는 다른, 모델 추론 내부의 KV 캐시(Key-Value Cache)를 서버에 영속적으로 보관하는 메커니즘을 지칭합니다.

LLM은 입력 토큰들 사이의 의미적 연관성을 Attention 연산으로 계산하는데, 이 중간 계산 결과(Key/Value 행렬)를 매 요청마다 다시 계산하지 않고 디스크·메모리에 'Write'해 두었다가, 동일한 접두사(prefix)가 다시 들어오면 'Read'로 복원합니다. Claude Code의 'Cache Write' 카운트는 바로 이 서버 측 KV 캐시를 새로 만들 때 발생한 토큰 수이며, 'Cache Read'는 이미 만들어진 캐시를 재사용한 토큰 수입니다.

🧠 즉, Cache Write는 '비용'이 아니라 미래 호출에 90% 할인을 적용하기 위한 선투자입니다. 한 번 Write에 25% 할증을 내고, 반복 호출에서 회수하는 구조죠.

2. 캐시에 담기는 정보와 사용자 제어 가능성

2.1 어떤 정보가 캐시에 담기는가

캐시는 본질적으로 모델이 본 토큰들의 내부 표현(activations)을 저장하지, 사용자가 임의로 키-값 쌍을 박아 넣는 데이터베이스가 아닙니다. 따라서 캐시에 담기는 실질적 내용물은 프롬프트 앞쪽에 배치된 다음과 같은 요소들입니다.

▶ 시스템 프롬프트 — 페르소나·정책·역할 정의

▶ 도구(tool) 정의 — JSON 스키마, 함수 시그니처 (보통 수천 토큰)

▶ RAG로 주입한 대형 문서·코드베이스

▶ 이전 대화 누적 컨텍스트 — 멀티턴의 정적 부분

한 마디로 요청 간에 변하지 않는 정적 접두사(Static Prefix)가 캐시의 대상입니다.

2.2 사용자가 직접 'Write'할 수 있는가

결론은 "DB에 PUT/SET 하듯 임의 데이터를 캐시에 쓸 수는 없다"입니다. 다만 '캐시 중단점(cache breakpoint)을 어디에 둘지'를 통해 간접적으로 Write를 유도할 수 있습니다. 공급자별 제어 방식은 다음과 같습니다.

공급자	제어 방식	사용자 개입
Anthropic	명시적 — cache_control: ephemeral	캐싱 경계선을 직접 그음
OpenAI	완전 자동 (1,024 토큰 이상)	프롬프트 구조로 간접 제어
Google Gemini	Implicit + cachedContents API	명시적 캐시 객체·TTL 지정

따라서 Claude Code의 'Cache Write'가 늘어났다면, 그것은 사용자가 직접 명령한 것이 아니라 Claude Code 내부 에이전트 루프가 시스템 프롬프트·도구 정의·읽어들인 파일 컨텍스트를 자동으로 캐시 후보로 마킹한 결과로 이해해야 합니다.

3. 주요 모델 캐싱 정책 비교 (2026년 기준)

Cache Read 할인율은 세 공급자가 모두 최대 90% 수준으로 수렴했지만, 최소 캐싱 단위와 TTL, Write 할증 유무에서 결정적 차이가 발생합니다.

📊 공급자별 Cache Read 최대 할인율

Anthropic

90%

OpenAI

~90%

Google Gemini

90%

항목	Anthropic	OpenAI	Google
제어 방식	명시적 중단점	완전 자동	Implicit + Explicit
Write 할증	+25%	없음	저장 시간당 과금
최소 단위	1,024~2,048 토큰	1,024 토큰	32,768 토큰 (Explicit)
기본 TTL	5분 (1h 옵션)	5~10분	1시간~수일

출처: Anthropic Docs(prompt-caching), OpenAI Blog "API Prompt Caching", Google Vertex AI Context Caching 문서

4. 왜 '캐시 잘 쓰기'가 핵심 엔지니어링 역량인가

🔥 컨텍스트의 비대화

2026년의 실무 프롬프트는 더 이상 한 줄 질문이 아닙니다. 수만 라인 코드베이스, 수백 페이지 PDF, 수십 개 도구 정의가 동시에 컨텍스트로 들어갑니다. 캐싱 없이 매 요청마다 이를 재처리하면 latency가 10초 단위로 증가합니다.

💰 손익분기점(Break-even) 문제

Anthropic의 경우 Cache Write가 일반 입력 대비 약 25% 비싸므로, 최소 2회 이상 Hit가 발생해야 캐싱이 경제적으로 이득입니다. 즉 "캐시를 쓰는 것"이 능력이 아니라, 캐시가 재사용될 구조로 프롬프트를 설계하는 것이 능력입니다.

⚠️ Prefix-Only Matching의 가혹함

캐시는 프롬프트 시작 바이트부터 정확히 일치해야 합니다. 중간에 now() 타임스탬프나 사용자 이름이 끼어 있으면 그 뒤의 모든 캐시가 무효화됩니다.

5. 캐싱을 잘 쓰는 케이스 (Best Practices)

✓ 대규모 코드베이스 에이전트 — 프로젝트 트리·핵심 파일·빌드 시스템 설명을 시스템 프롬프트 뒤에 캐싱. Claude Code의 동작 패턴이 바로 이것입니다.

✓ 다중 도구(tool use) 에이전트 — 수십 개 함수 시그니처와 JSON 스키마를 캐싱해 매 turn마다 들어오는 고정 오버헤드 제거.

✓ 상세한 페르소나·few-shot 예시 (5K~50K 토큰) — 한 번 Write해 두면 이후 모든 호출이 90% 할인.

✓ 반복 평가(Eval) 파이프라인 — 동일 시스템 프롬프트 + 다른 입력 수백 건을 돌릴 때 자동 Hit.

6. 토큰 효율화의 실전 전략

캐싱은 토큰 효율화 전략 중 하나일 뿐이고, 실무에서는 다음 4가지 축을 병행합니다.

🧱 ① 프롬프트 계층화 (Layering)

[System] → [Tools/Docs] → [Persistent Context] → [User Input] 순서로 정적 → 동적 배치. 동적이 앞에 오는 순간 캐시는 깨집니다.

📦 ② 데이터 밀도 최적화

JSON 대신 Markdown·CSV·YAML로 동일 정보를 더 적은 토큰에 압축. 2026년 주력 모델들은 Markdown 구조 이해도가 매우 높습니다.

✂️ ③ 출력 토큰 통제

출력 토큰은 입력보다 3~5배 비쌉니다. max_tokens, "간결하게 답하라" 지시, 구조화 출력(JSON Schema) 제약으로 압축.

⏰ ④ TTL 인식 설계

Anthropic 기본 TTL이 5분이므로, 5분을 넘기는 사용자 사이클에는 요청 배칭이나 1시간 TTL 옵션으로 전환.

7. 2026년 AI 엔지니어의 가성비·퍼포먼스 트렌드

현재 최상위 엔지니어들은 단일 모델·단일 프롬프트가 아니라 'Compound AI System'을 설계합니다.

전략	핵심 아이디어
🛣️ 모델 라우팅	단순·캐시 친화적 작업 → Haiku/4o-mini, 복잡 추론 → Sonnet/Opus/o1
🧠 시맨틱 캐싱	Redis·pgvector로 의미적 유사 질의는 LLM 호출 없이 답변 반환
📦 Batch API	비실시간 작업은 약 50% 저렴한 야간 배치로 처리
🏗️ Hybrid Prompt	정적/동적 경계 분리 + Cache Hit Rate를 KPI로 추적

🧠 핵심 명제: "얼마나 큰 모델을 쓰는가"가 아니라 "얼마나 영리하게 캐싱하고, 난이도에 따라 모델을 동적으로 배분하는가"가 경쟁력입니다.

8. 캐싱은 만능이 아니다 — 한계와 보안 리스크

8.1 기술적 한계

🔴 민감한 무효화 — 공백 하나, 날짜 하나만 앞쪽에 끼어도 전체 캐시가 깨집니다.

🔴 5분 TTL의 역효과 — Write 25% 할증을 내고도 5분 안에 Hit이 안 나면, 캐싱을 안 쓰는 편보다 비싸지는 역설이 발생.

🔴 All-or-Nothing 구간 — OpenAI 128 토큰 granularity 때문에 1,023 토큰처럼 임계점 직하 길이는 캐시 히트율 0%.

8.2 보안·프라이버시 리스크

2025~2026년 캐시는 새로운 공격 표면(attack surface)으로 부상했습니다. 학계와 산업 보고서가 짚는 핵심 위협은 다음 4가지입니다.

⚠️ PROMPTPEEK류 타이밍 사이드 채널 — 캐시 Hit/Miss에 따른 응답 지연 차이를 이용해 서버 캐시에 어떤 민감 토큰이 존재하는지 역추론 (NDSS 2025).

⚠️ 다중 테넌트 KV-Cache 유출 — 멀티 유저 환경에서 KV 캐시가 물리적으로 분리되지 않을 경우, 타 사용자 프롬프트 일부가 토큰 단위로 누설될 가능성.

⚠️ 시맨틱 캐시 포이즈닝 — 의미 기반 캐싱에 공격자가 오염된 응답을 주입하면, 유사 질문을 하는 정상 사용자에게 오염 답변이 반환.

⚠️ 쿼터 소진 공격(Quota Drain) — 미세 변형된 대량 요청으로 타겟의 Cache Write 할증 비용을 의도적으로 폭증.

8.3 표준 대응 가이드

리스크	권장 대응
Invalidation	정적 → 동적 순서 고정, 타임스탬프는 마지막 블록으로
5분 TTL	요청 배칭, 필요 시 1시간 TTL 옵션 활용
Side-Channel	응답 jitter 추가, 민감 토큰은 캐싱 대상에서 제외
Cross-Tenant	민감 정보 처리 시 Dedicated/Private Cache 옵션 요구

9. 결론: 'Cache Write' 한 줄이 의미하는 것

Claude Code 상태 화면에서 본 'Cache Write' 카운트는 단순한 통계가 아니라, 현재 세션이 어느 정도의 정적 컨텍스트를 KV 캐시에 적재했고, 앞으로 동일 접두사로 들어올 요청들에 90% 할인 혜택을 받을 준비를 마쳤는지를 보여주는 경제 지표입니다. 사용자가 직접 임의 데이터를 캐시에 PUT 할 수는 없지만, 프롬프트 구조와 도구 정의의 순서·안정성을 통해 캐시 효율을 좌우할 수 있습니다.

🎯 2026년 AI 엔지니어링 4단 설계

① 정적 컨텍스트를 최대한 길고 안정적으로 유지

② 동적인 부분을 맨 뒤로 격리

③ 작업 난이도에 맞춰 모델을 동적으로 라우팅

④ 캐시의 보안·TTL 리스크까지 인지한 설계

→ 토큰을 적게 쓰는 것이 아니라, 재사용 가능한 토큰을 많이 쌓는 쪽이 진짜 가성비입니다.

References

📚 Anthropic Prompt Caching Docs — docs.anthropic.com/en/docs/build-with-claude/prompt-caching

📚 OpenAI API Prompt Caching — openai.com/index/api-prompt-caching

📚 Google Vertex AI Context Caching — cloud.google.com/vertex-ai/generative-ai/docs/context-caching

📚 NDSS Symposium 2025 — "PROMPTPEEK: Side-Channel Attacks on LLM Prompt Caching"

📚 arXiv 2025 — "Privacy Risks in Multi-tenant KV-Cache Systems"

본 콘텐츠는 정보 제공 목적이며, 특정 기술 스택·서비스 채택 결정은 독자의 환경과 요구사항에 따라 신중히 판단해야 합니다.

© 2026 OguTech Notes. All rights reserved.

📄 Raw Data

# 프롬프트 캐싱: Claude Code의 'Cache Write'부터 2026년 AI 가성비 엔지니어링까지

> 본 보고서는 Claude Code의 사용량 통계에 표시되는 'Cache Write' 항목의 기술적 실체를 출발점으로, LLM 프롬프트 캐싱의 작동 원리, 사용자 제어 가능성, 활용 사례, 토큰 효율화 전략, 그리고 2026년 현재 AI 엔지니어들이 추구하는 가성비·퍼포먼스 최적화 트렌드와 그 이면의 보안 리스크까지를 통합적으로 분석합니다.

---

## 1. 질문의 출발점: Claude Code가 보여주는 'Cache Write'는 무엇인가

Claude Code의 `/status` 또는 사용량(usage) 화면에서는 모델별로 **Input / Output / Cache Read / Cache Write** 토큰이 분리되어 표기됩니다. 여기서 말하는 '캐시'는 일반적인 웹 캐시(브라우저·CDN)나 RAG의 벡터 캐시와는 다른, **모델 추론 내부의 KV 캐시(Key-Value Cache)를 서버에 영속적으로 보관하는 메커니즘**을 지칭합니다.

LLM은 입력 토큰들 사이의 의미적 연관성을 Attention 연산으로 계산하는데, 이 중간 계산 결과(Key/Value 행렬)를 매 요청마다 다시 계산하지 않고 디스크·메모리에 'Write'해 두었다가, 동일한 접두사(prefix)가 다시 들어오면 'Read'로 복원합니다. Claude Code의 'Cache Write' 카운트는 바로 이 **서버 측 KV 캐시를 새로 만들 때 발생한 토큰 수**이고, 'Cache Read'는 이미 만들어진 캐시를 재사용한 토큰 수입니다 (Anthropic Docs, prompt-caching).

---

## 2. 캐시에 담기는 정보와 사용자 제어 가능성

### 2.1 어떤 정보가 캐시에 담기는가
캐시는 본질적으로 **'모델이 본 토큰들의 내부 표현(activations)'**을 저장하지, 사용자가 임의로 키-값 쌍을 박아 넣는 데이터베이스가 아닙니다. 따라서 캐시에 담기는 실질적 내용물은 프롬프트의 앞쪽에 배치된:

- 시스템 프롬프트(System Instruction, 페르소나, 정책)
- 도구(tool) 정의 — JSON 스키마, 함수 시그니처
- RAG로 주입한 대형 문서·코드베이스
- 이전 대화 누적 컨텍스트(멀티턴의 정적 부분)

처럼 **요청 간에 변하지 않는 '정적 접두사(Static Prefix)'** 입니다 (Anthropic Docs).

### 2.2 사용자가 직접 'Write'할 수 있는가
결론적으로 **"DB에 PUT/SET 하듯 임의 데이터를 캐시에 쓰는 것은 불가능"**하지만, **'캐시 중단점(cache breakpoint)을 어디에 둘지'를 통해 간접적으로 Write를 유도**할 수 있습니다.

- **Anthropic (명시적 제어):** 메시지 배열 내 특정 블록에 `"cache_control": {"type": "ephemeral"}` 표식을 추가하면, 모델은 그 지점까지의 누적 프롬프트를 캐시에 'Write'합니다. 즉, 사용자는 "어디까지를 캐싱할지"의 경계선을 직접 그립니다.
- **OpenAI (완전 자동):** 1,024 토큰 이상의 프롬프트에 대해 시스템이 자동으로 캐싱을 시도하며, 사용자는 별도 표식을 넣지 않습니다 — 단, 프롬프트 구조를 어떻게 짜느냐가 사실상의 제어 수단입니다.
- **Google Gemini (하이브리드):** 자동 캐싱(Implicit) 외에, `cachedContents` API로 명시적 캐시 객체를 생성하고 TTL을 지정해 보관할 수 있습니다.

따라서 Claude Code의 'Cache Write'가 늘어났다면, 그것은 **사용자가 직접 명령한 것이 아니라 Claude Code 내부 에이전트 루프가 시스템 프롬프트·도구 정의·읽어들인 파일 컨텍스트를 자동으로 캐시 후보로 마킹**한 결과로 이해해야 합니다.

---

## 3. 주요 모델 캐싱 정책 비교 (2026년 기준)

| 항목 | **Anthropic (Claude 4.x / 3.7)** | **OpenAI (GPT-5/4o)** | **Google (Gemini 3.0)** |
| :--- | :--- | :--- | :--- |
| 제어 방식 | 명시적 중단점(`cache_control`) | 완전 자동 | Implicit + Explicit 혼합 |
| Cache Read 할인 | 약 **90%** 할인 | 50~90% 할인 | 최대 90% 할인 |
| Cache Write 비용 | **일반 입력 대비 ~1.25배 할증** | 별도 할증 없음 | Explicit 캐시는 저장 시간당 과금 |
| 최소 캐싱 단위 | 1,024 ~ 2,048 토큰 | 1,024 토큰 (128 토큰 granularity) | Explicit 기준 32,768 토큰 |
| 기본 TTL | **5분** (히트 시 갱신, 1시간 옵션 가능) | 5~10분 (비활성 시 삭제) | 1시간~수일 (설정 가능) |

출처: Anthropic Docs, OpenAI Blog "API Prompt Caching", Google Vertex AI 문서.

---

## 4. 왜 '캐시 잘 쓰기'가 핵심 엔지니어링 역량이 되었는가

### 4.1 컨텍스트의 비대화
2026년의 실무 프롬프트는 더 이상 한 줄 질문이 아닙니다. 수만 라인 코드베이스, 수백 페이지 PDF, 수십 개 도구 정의가 동시에 컨텍스트로 들어갑니다. 캐싱 없이 매 요청마다 이를 재처리하면 latency가 10초 단위로 증가합니다.

### 4.2 손익분기점(Break-even) 문제
Anthropic의 경우 Cache Write가 일반 입력 대비 약 25% 비싸므로, **최소 2회 이상 Hit가 발생해야 캐싱이 경제적으로 이득**입니다 (*Quantacost AI Report, 2026*). 즉 "캐시를 쓰는 것" 자체가 능력이 아니라, "**캐시가 재사용될 구조로 프롬프트를 설계하는 것**"이 능력입니다.

### 4.3 Prefix-Only Matching의 가혹함
캐시는 프롬프트 **시작 바이트부터 정확히 일치**해야 합니다. 중간에 `now()` 타임스탬프나 사용자 이름이 끼어 있으면 그 뒤의 모든 캐시가 무효화됩니다. OpenAI는 128 토큰 단위로 granularity를 두어 1,023 토큰은 캐싱이 아예 안 되는 'All-or-Nothing' 영역이 존재합니다 (OpenAI Blog).

---

## 5. 캐싱을 잘 쓰는 케이스 (Best Practices)

1. **대규모 코드베이스 분석/에이전트**
   - 프로젝트 트리, 핵심 파일, 빌드 시스템 설명을 시스템 프롬프트 뒤에 캐싱 — Claude Code의 동작 방식이 정확히 이 패턴입니다.
2. **다중 도구(tool use) 에이전트**
   - 수십 개의 함수 시그니처와 JSON 스키마를 캐싱해 매 turn마다 들어오는 고정 오버헤드 제거.
3. **상세한 페르소나·정책·few-shot 예시 (5K~50K 토큰)**
   - 한 번 Write해 두면 이후 모든 호출이 90% 할인된 가격으로 같은 품질을 유지.
4. **반복 평가(Eval) 파이프라인**
   - 동일한 시스템 프롬프트 + 다른 입력 수백 건을 돌릴 때, 시스템 프롬프트 부분이 자동 Hit.

---

## 6. 토큰 효율화의 실전 전략

1. **프롬프트 계층화(Layering)**
   - `[System Instruction] → [Static Tools/Docs] → [Persistent Context] → [Dynamic User Input]` 순서로 **정적 → 동적**으로 배치. 동적인 것이 앞에 오는 순간 캐시는 깨집니다.
2. **데이터 밀도(Density) 최적화**
   - JSON 대신 Markdown·CSV·YAML로 동일 정보를 더 적은 토큰에 압축. 2026년 주력 모델들은 Markdown 구조 이해도가 매우 높습니다.
3. **출력 토큰 통제**
   - 출력 토큰은 입력보다 3~5배 비쌉니다. `max_tokens`, "간결하게 답하라", 구조화 출력(JSON Schema) 제약으로 출력을 압축.
4. **TTL 인식 설계**
   - Anthropic 기본 TTL이 5분이므로 (Anthropic Docs), 5분을 넘기는 사용자 사이클에는 **요청을 batching**하거나 **1시간 TTL 옵션**으로 전환.

---

## 7. 2026년 AI 엔지니어의 가성비·퍼포먼스 추구 트렌드

현재 최상위 엔지니어들은 단일 모델·단일 프롬프트가 아니라 **'Compound AI System'**을 설계합니다.

- **모델 라우팅(Model Routing):** 단순·캐시 친화적 작업은 Haiku/GPT-4o-mini로, 복잡한 추론·캐시 미스 케이스만 Sonnet/Opus/o1으로 라우팅.
- **시맨틱 캐싱(Semantic Caching):** API 레벨 캐시 외에 Redis·pgvector로 **의미적으로 유사한 과거 질의는 아예 LLM을 호출하지 않고 답변을 반환**.
- **Batch API:** 실시간성이 필요 없는 요약·분류·평가 작업은 일반 API 대비 약 50% 저렴한 배치 API로 야간 처리.
- **Hybrid Prompt Architecture:** 한 프롬프트 안에 캐시 가능한 정적 부분과 동적 부분의 경계를 명확히 분리하고, 캐시 hit rate를 KPI로 추적.

핵심 명제는 명확합니다 — **"얼마나 큰 모델을 쓰는가"가 아니라 "얼마나 영리하게 캐싱하고, 난이도에 따라 모델을 동적으로 배분하는가"**가 경쟁력입니다.

---

## 8. 다만, 캐싱은 만능이 아니다 — 한계와 리스크

### 8.1 기술적 한계
- **민감한 무효화:** 공백 하나, 날짜 하나만 앞쪽에 끼어도 전체 캐시가 깨집니다 (Anthropic Docs).
- **5분 TTL의 경제적 역효과:** Write에 25% 할증을 지불하고도 5분 안에 Hit이 안 나면 **캐싱을 쓰지 않는 편보다 비싸지는 역설**이 발생합니다 (*Quantacost AI Report, 2026*).
- **All-or-Nothing 구간:** OpenAI의 128 토큰 granularity 때문에 1,023 토큰처럼 임계점 바로 아래 길이는 캐시 히트율 0%가 됩니다.

### 8.2 보안·프라이버시 리스크
- **PROMPTPEEK 류 타이밍 사이드 채널:** 캐시 Hit/Miss에 따른 응답 지연 차이를 이용해 **서버 캐시에 어떤 민감 토큰이 이미 존재하는지 역추론**하는 공격이 NDSS 2025·관련 arXiv 연구에서 입증되었습니다 (NDSS Symposium 2025, "PROMPTPEEK").
- **다중 테넌트 KV-Cache 유출:** 멀티 유저 환경에서 KV 캐시가 물리적으로 분리되지 않을 경우, 타 사용자의 프롬프트 일부가 토큰 단위로 새어 나갈 가능성이 보고됨 (arXiv, "Privacy Risks in Multi-tenant KV-Cache Systems", 2025).
- **시맨틱 캐시 포이즈닝(Semantic Cache Poisoning):** 의미 기반 캐싱을 운영하는 시스템에 공격자가 오염된 응답을 주입하면, 유사 질문을 하는 정상 사용자에게 그 오염 답변이 반환됩니다 (*Lawzava Security Review, 2026*).
- **쿼터 소진 공격(Quota Drain):** 미세 변형된 대량 요청으로 타겟의 Cache Write 할증 비용을 의도적으로 폭증시키는 방식.

### 8.3 표준 대응 가이드

| 리스크 | 권장 대응 |
| :--- | :--- |
| Invalidation | 정적 → 동적 순서 고정, 타임스탬프는 마지막 블록으로 |
| 5분 TTL | 요청 배칭, 필요 시 1시간 TTL 옵션 활용 |
| Side-Channel | 응답 jitter 추가, 민감 토큰은 캐싱 대상에서 제외 |
| Cross-Tenant | 민감 정보 처리 시 Dedicated/Private Cache 옵션 요구 |

---

## 9. 결론: Claude Code의 'Cache Write' 한 줄이 의미하는 것

질문자께서 Claude Code 상태 화면에서 보신 'Cache Write' 카운트는 단순한 통계가 아니라, **현재 세션이 어느 정도의 정적 컨텍스트를 KV 캐시에 적재했고, 앞으로 동일 접두사로 들어올 요청들에 90% 할인 혜택을 받을 준비를 마쳤는지**를 보여주는 경제 지표입니다. 사용자가 직접 임의 데이터를 캐시에 PUT 할 수는 없지만, **프롬프트 구조와 도구 정의의 순서·안정성을 통해 캐시 효율을 좌우**할 수 있습니다.

2026년 AI 엔지니어링의 본질은 결국 **(1) 정적 컨텍스트를 최대한 길고 안정적으로 유지하고, (2) 동적인 부분을 맨 뒤로 격리하고, (3) 작업 난이도에 맞춰 모델을 동적으로 라우팅하고, (4) 캐시의 보안·TTL 리스크까지 인지하는** 4단 설계로 수렴하고 있습니다. 토큰을 적게 쓰는 것이 아니라 **재사용 가능한 토큰을 많이 쌓는 쪽**이 진짜 가성비입니다.
---

## References

- [Anthropic Prompt Caching Docs](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching)
- [OpenAI API Prompt Caching](https://openai.com/index/api-prompt-caching)
- [Google Vertex AI Context Caching](https://cloud.google.com/vertex-ai/generative-ai/docs/context-caching)