프롬프트 캐싱 — 같은 5천만 토큰에 260달러와 36달러
한 프로젝트에서 API와 Claude Code로 각각 5천만 토큰을 썼는데 비용은 260달러와 36달러였다. 그 차이를 만든 것이 프롬프트 캐싱이다.
LLM 을 활용한 개발, 이른바 ‘바이브 코딩’ 이 퍼지면서 개발 생산성이 크게 올랐다. 동시에 API 사용량이 늘면서 비용 부담도 무시할 수 없는 현실이 됐다. 이 상황에서 프롬프트 캐싱(Prompt Caching) 은 개발 및 에이전트 운영 비용을 크게 줄일 수 있는 핵심 기술로 떠오르고 있다.
같은 토큰, 7배 차이 나는 비용
최근 진행한 프로젝트에서 Claude 3.7 Sonnet API 와 Claude Code 를 동시에 쓰며 흥미로운 경험을 했다. 총 API 사용량이 1억 토큰에 도달했을 때, 공교롭게도 프로젝트용 API 와 Claude Code 에서 각각 5천만 토큰씩 쓰였다.
단순히 생각하면 비용도 절반씩 들었을 것 같았다. 결과는 달랐다.
- 프로젝트용 API — $260
- Claude Code — $36
이유는 Claude 3.7 Sonnet 의 캐싱 정책이다. 캐싱된 토큰 비용이 일반 토큰 비용의 1/10 수준이었기 때문이다. Claude Code 를 쓰는 과정에서 상당 부분의 프롬프트와 결과가 캐싱되어 재사용됐고, 이것이 실제 처리된 토큰 수를 크게 줄여 비용 절감으로 이어졌다.
- Claude 3.7 Sonnet — 입력 $3 / 캐싱 $0.3 (90% 인하)
- 캐시 가능한 최소 프롬프트는 1,024 토큰이다
- Claude 는 캐시를 처음 저장(Write)할 때 25% 할증이 붙지만, 한 번이라도 재사용(Hit)되면 즉시 절감 효과가 생기며 재사용 빈도가 높을수록 이익이 기하급수적으로 커진다
- Anthropic 프롬프트 캐싱 문서
IDE 환경에 따라서도 갈린다 — Cursor Pro 사례
주변 동료들의 사례도 주목할 만하다. Cursor Pro 를 구독하며 프리미엄 모델 사용량(500회)을 넘겨 Claude 3.7 Sonnet 을 쓴 두 동료는 각각 4,500만 토큰과 5,500만 토큰을 썼고 API 비용으로 48달러와 36달러를 냈다.
토큰당 비용으로 환산해 보면 이렇다.
| 환경 | 사용량 | 비용 | 100만 토큰당 |
|---|---|---|---|
| Claude Code | 5,000만 | $36 | 약 $0.72 |
| Cursor Pro (동료 A) | 4,500만 | $36 | 약 $0.80 |
| Cursor Pro (동료 B) | 5,500만 | $48 | 약 $0.87 |
캐싱 효율은 작업 유형과 패턴에 따라 크게 달라질 수 있다. 다만 일반적인 개발 작업 흐름에서 이런 차이가 났다는 점은 주목할 만하다. Claude Code 가 Cursor 보다 일반적인 코드 생성·수정 작업에서 프롬프트 캐싱에 더 최적화되었을 가능성을 시사한다. 특정 도구가 사용자의 반복적인 코딩 패턴을 더 잘 예측하고 캐시를 효율적으로 쓰도록 설계되었을 수 있다는 추정이다.
업계 동향 — 캐싱은 거스를 수 없는 흐름
OpenAI. GPT-4o 부터 자동 캐싱을 도입했고(50% 할인), 최근 GPT-4.1 이후 모델에 대해서는 캐싱 비용을 대폭 인하했다(50% → 75%). Claude 의 효율적인 캐싱 정책에 대응하고 개발자의 비용 부담을 줄여 경쟁력을 확보하려는 전략으로 해석된다. 비슷한 시기에 오픈소스 기반 Codex CLI 를 내며 개발자 도구 생태계에서도 캐싱을 활용한 비용 효율성을 강조하는 모습이다.
| 모델 | 입력 | 캐싱 | 인하율 |
|---|---|---|---|
| GPT-4o | $2.5 | $1.25 | 50% |
| GPT-4.1 | $2 | $0.5 | 75% |
| o1 | $15 | $7.5 | 50% |
| o3 | $10 | $2.5 | 75% |
캐시 가능한 최소 프롬프트는 1,024 토큰이고, 추론 모델은 추론 토큰까지 고려해야 한다. (문서)
Google. Gemini 2.0 Flash 와 2.5 Pro 에 캐싱을 도입했고 2.5 Flash 도 출시 예정이다. 캐싱이 LLM 서비스의 표준 기능으로 자리 잡고 있음을 보여 준다.
| 모델 | 입력 | 캐싱 | 인하율 |
|---|---|---|---|
| Gemini 2.0 Flash-Lite | — | 캐싱 사용 불가 | — |
| Gemini 2.0 Flash | $0.10 | $0.025 | 75% |
| Gemini 2.5 Pro Preview | $1.25 | $0.31 | 75% |
캐시 가능한 최소 프롬프트는 4,096 토큰이다(최근 32K 에서 감소). (문서)
실전 캐싱 가이드
프롬프트 분리 패턴
- 고정 영역 분리 — 시스템 메시지, 툴(함수) 정의, 프롬프트 예제처럼 자주 바뀌지 않는 부분은 따로 떼어 캐시에 저장한다
- 가변 영역 활용 — 사용자 입력, 특정 함수 호출 파라미터처럼 매번 달라지는 부분만 요청 시 동적으로 붙인다
- API 명시적 호출 — Claude API 는
cache=true헤더를, Vertex AI 는contextCache필드를 명시적으로 설정해 캐싱을 켠다
세션 ID 기반 캐시 키 설계
긴 대화 세션에는 고유 식별자(UUID)와 프롬프트 버전 태그를 조합해 캐시 키를 만들면, 같은 세션 안의 반복 요청에서 캐시 재사용률이 오른다.
Claude Code 나 Codex CLI 같은 도구는 현재 작업 중인 Git 브랜치의 해시 값을 캐시 키의 일부로 써서, 코드베이스가 바뀌면 자동으로 캐시를 무효화하고 최신 상태를 반영한다.
에이전트 루프 단계별 최적화
에이전트가 목표 달성을 위해 반복하는 루프(Plan → Act → Reflect)마다 전략을 다르게 가져간다.
| 단계 | 캐싱 | 이유 |
|---|---|---|
| Plan (계획 수립) | 완전 캐시 | 시스템 목표, 제약 조건은 잘 바뀌지 않는다 |
| Act (도구 호출) | 부분 캐시 | 툴 명세(고정)는 캐시하고 호출 인자(가변)만 바꾼다 |
| Reflect (결과 피드백) | 미적용 또는 낮은 우선순위 | 매번 실행 결과가 달라 캐시 효과가 낮다 |
Prompt Hub 등의 분석에 따르면, 전체 요청 중 캐시 히트율을 60%까지만 달성해도 총 LLM 비용을 35~55% 절감할 수 있는 것으로 나타났다.
캐싱 운영 비용이 ’거의 0’인 이유
캐싱은 모델을 다시 추론하는 과정을 건너뛰는 로직이다. 그래서 값비싼 GPU 연산 자원을 거의 쓰지 않고, 상대적으로 저렴한 스토리지와 Key-Value I/O 비용만 든다. 많은 기술 블로그나 커뮤니티에서 “캐시 히트는 사실상 순이익” 이라고 표현하는 이유다.
LLM 공급사들이 공격적으로 캐시 할인율을 높이는 배경에는 이런 수익 구조와 더불어, 자사 플랫폼에 대한 개발자 락인 효과를 강화하려는 전략적 판단이 깔려 있다.
체크리스트
이제 프롬프트 캐싱은 선택이 아니라 필수 설계 원칙이다. 특히 수천만 토큰 이상을 쓰는 바이브 코딩이나 에이전트 프로젝트에서는 다음을 점검해야 한다.
- 캐시 히트율을 정기적으로 측정하고 있는가 — LLM 공급사의 콘솔이나 API 응답 메트릭에서
cached_tokens같은 항목을 확인한다 - 시스템 메시지 등 고정 프롬프트를 따로 관리하고 있는가 —
.prompt.toml같은 파일로 분리해 버전 관리와 재사용을 쉽게 만든다 - 쓰는 IDE/에이전트가 특정 조건에서 캐싱을 우회하지 않는가 — 예를 들어 Cursor Pro 에서 500회 무료 사용량을 넘긴 뒤 ‘느린 요청(Slow Request)’ 모드가 캐시를 무효화하는지 검증한다
프롬프트 캐싱은 더 이상 부가 기능이 아니라 AI 개발과 에이전트 운영의 경제성을 좌우하는 핵심이다. API 호출 비용은 AI 도입의 주요 장벽 중 하나이고, 캐싱은 그 장벽을 낮추는 가장 효과적인 방법 중 하나다. 이제는 성능만이 아니라 캐싱 정책과 효율까지 보고 기술 스택을 고르고 애플리케이션을 설계해야 한다.