AI 운영 경제학 (3/4) — 컨텍스트 캐싱 가이드: 1시간 vs 5분, 어디에 쓰나
캐시는 언제나 절감이 아니다. 적중률에 따라 절감이거나 손해다.
핵심 요약
- 캐시 적중 = 베이스 입력의 0.1×, 캐시 쓰기 = 1.25× (5분) 또는 2× (1시간)
- 손익분기: 5분 캐시는 2회 적중, 1시간 캐시는 2~3회 적중에서 본전
- 1차 자료: Anthropic prompt caching docs, OpenAI prompt caching docs
- 캐시 적용 영역: 시스템 프롬프트 / CLAUDE.md / 도구 카탈로그 / 자주 쓰는 정적 컨텍스트
- 의사결정: 1시간이 짧은 캐시(5분)보다 항상 좋은 게 아니다 — 적중률 높은 패턴에서만 우월
1. 캐시는 어떻게 작동하는가
LLM 캐시는 프롬프트의 prefix를 저장해, 다음 호출에서 같은 prefix가 등장하면 재계산을 건너뛴다.
핵심 규칙:
- 접두사 매칭만 가능. 캐시된 블록 앞이 1바이트라도 다르면 미스.
- 블록 경계를 명시적으로 표시 (cache_control for Anthropic). OpenAI는 자동.
- 블록은 보통 1024 토큰 이상에서 효율적이다. 작은 블록은 오버헤드가 커진다.
적중 시 비용: - Anthropic: 베이스 × 0.1 (~10%). - OpenAI: 베이스 × 0.5 (~50%, 모델 따라 다름).
Anthropic이 공격적으로 싸지만, 적중률 관리 부담이 OpenAI보다 크다.
2. TTL — 5분 vs 1시간
Anthropic은 두 가지 TTL을 제공한다.
| TTL | 캐시 쓰기 단가 | 캐시 적중 단가 | 권장 사용처 |
|---|---|---|---|
| 5분 (default) | 베이스 × 1.25 | 베이스 × 0.1 | 한 세션 내 반복, 인터랙티브 작업 |
| 1시간 | 베이스 × 2.0 | 베이스 × 0.1 | 긴 세션, 백그라운드, 배치 |
TTL 선택 룰: - 같은 컨텍스트가 5분 이내에 다시 호출되는가 → 5분 캐시. - 5~60분 사이에 다시 호출되는가 → 1시간 캐시 (단, 손익분기 충족 시). - 1시간 이상 간격이면 캐시는 만료된다 — 이 경우 캐시가 오히려 손해.
Claude Code 사용자 주의: Claude Code는 1시간 캐시를 default로 사용하는 것으로 알려져 있다. 즉 모든 캐시 쓰기가 2× 베이스로 청구된다. 비용 추정 시 반드시 2배수 가정.
3. 손익분기 계산
5분 캐시: - 첫 쓰기: 베이스 × 1.25 (정상보다 0.25× 더 든다). - 적중 1회: 베이스 × 0.1 → 0.9× 절감. - 손익분기: 0.25 = 0.9 × N → N ≈ 0.28회. 즉 1회 적중부터 본전. - 실용: 2회 이상 적중하면 적용한다.
1시간 캐시: - 첫 쓰기: 베이스 × 2.0 (정상보다 1.0× 더 든다). - 적중 1회: 베이스 × 0.1 → 0.9× 절감. - 손익분기: 1.0 = 0.9 × N → N ≈ 1.12회. 2회 적중부터 본전. - 실용: 4회 이상 적중하면 적용한다 (안전 마진).
시사점: 적중 횟수가 1회 미만이면 캐시는 손해. 측정 없이 "캐싱 = 절감"이라고 도입하면 청구서가 더 커질 수 있다.
4. 무엇을 캐시하는가
4.1 시스템 프롬프트
- 거의 모든 호출에 등장. 캐시 적용 대상 1순위.
- 적중률이 가장 높다.
4.2 CLAUDE.md / 룰 파일
- 프로젝트 단위로 고정. 같은 프로젝트 안의 모든 호출에서 같다.
- 1시간 캐시가 적합 (긴 세션 대비).
4.3 도구 카탈로그
- MCP 서버 정의, function calling 스키마.
- 도구가 자주 추가/제거되면 캐시가 깨진다 — 안정화 후 캐시 적용.
4.4 자주 쓰는 정적 컨텍스트
- 설계 문서, 데이터 사전, 코드 스타일 가이드.
- 변경되는 부분은 뒤로 빼고, 정적 부분만 앞에 캐시.
캐시 안 되는 것: - 사용자별 / 세션별로 다른 데이터. - 매 호출마다 바뀌는 timestamp / random ID. - 극단적으로 작은 컨텍스트 (1K 토큰 미만). 캐시 오버헤드가 절감을 상쇄.
5. Anthropic vs OpenAI
| 항목 | Anthropic | OpenAI |
|---|---|---|
| 적용 방식 | 명시적 (cache_control) |
자동 |
| 적중 시 단가 | 베이스 × 0.1 | 베이스 × 0.5 (모델별 차이) |
| 쓰기 배수 | 1.25× (5분), 2.0× (1시간) | 추가 비용 없음 |
| TTL | 5분 / 1시간 | 모델별 (보통 5~10분) |
| 블록 단위 | 명시적으로 cache_control 표시 | 자동 (1024+ 토큰 prefix) |
선택 가이드: - 적중률을 완전히 통제할 수 있다면 Anthropic이 더 큰 절감 폭. - 변동이 잦은 워크로드라면 OpenAI의 자동 캐싱이 더 안전.
6. 캐시 미스 디버깅
캐시가 작동하지 않으면 다음을 점검한다:
- 앞부분 변경: 블록 시작이 매번 다른가? (timestamp 같은 것이 앞에 있나)
- 블록 크기: 1024 토큰 미만이면 캐시 활성화 안 됨.
- TTL 만료: 호출 간격이 TTL을 넘었는가?
- 순서 변경: 캐시 블록의 순서가 바뀌면 미스. 도구 정의 순서가 자동으로 정렬되는지 확인.
- 모델 변경: 같은 모델 안에서만 캐시가 공유된다.
측정 항목: API 응답의 usage.cache_read_input_tokens와 usage.cache_creation_input_tokens를 비교. 적중률 = read / (read + creation).
7. 운영 패턴 — 캐시 친화적 프롬프트 설계
[시스템 프롬프트 — 정적, 5K 토큰] ← 캐시
[CLAUDE.md — 정적, 3K 토큰] ← 캐시
[도구 카탈로그 — 정적, 2K 토큰] ← 캐시
─────────────────────────── 캐시 경계 ───
[사용자 입력 — 매번 다름] ← 캐시 안 됨
핵심 원칙: - 변경되지 않는 것을 앞에 모은다. - 변경되는 부분은 모두 뒤에. - 캐시 경계는 블록 경계와 일치시킨다.
이렇게 짜면 사용자 입력만 새로 처리되고, 그 앞 10K 토큰은 0.1× 단가로 들어간다. 1만 토큰을 1천 토큰 가격으로 사는 셈.
8. 한눈에 정리
| 캐시 종류 | 손익분기 적중 | 적합 워크로드 |
|---|---|---|
| 5분 TTL | 1회 (실용 2회) | 인터랙티브, 짧은 세션 |
| 1시간 TTL | 2회 (실용 4회) | 긴 세션, 배치, 백그라운드 |
| 캐시할 것 | 캐시 안 할 것 |
|---|---|
| 시스템 프롬프트 / CLAUDE.md / 도구 카탈로그 | 사용자별 데이터, timestamp, 매번 바뀌는 random |
| 자주 참조되는 정적 문서 | 1K 미만 작은 컨텍스트 |
핵심 룰: 측정 없이 캐싱 도입 금지. cache_hit_rate < 30%면 즉시 재검토.
다음 편
다음 편(4/4)은 컨텍스트 관리 패턴 — auto-compact / Memory / RAG 비용 비교다. 캐싱이 같은 컨텍스트를 싸게 보내는 기법이라면, 다음 편은 컨텍스트 자체를 줄이는 기법이다.
참고 자료
- Anthropic, Prompt Caching — docs.claude.com/en/docs/build-with-claude/prompt-caching (2026-05-05 확인).
- Anthropic, 1-Hour Cache TTL — docs.claude.com/en/docs/build-with-claude/prompt-caching#cache-duration (2026-05-05 확인).
- OpenAI, Prompt Caching — platform.openai.com/docs/guides/prompt-caching (2026-05-05 확인).
- 시리즈 1편 (토큰 비용 구조), 2편 (라우팅).
이 글은 AI 운영 경제학 시리즈의 3/4 편입니다.
댓글
댓글 쓰기