💡 이 글은 저의 AI Cost Calc 블로그에 게시된 글을 교차 게시한 것입니다. 원문은 링크된 도구들과 함께 동일한 내용을 담고 있습니다 — 어느 플랫폼에서든 피드백을 환영합니다. Prompt caching (프롬프트 캐싱)은 오늘날 AI API에서 가장 과소평가된 단일 비용 최적화 방법입니다. 일반적인 RAG (Retrieval-Augmented Generation, 검색 증강 생성) 워크로드에서 올바르게 사용하면 OpenAI 청구 금액을 40-75%까지 줄일 수 있습니다. 잘못 사용하거나 완전히 건너뛰면, 계속해서 정가(headline rate)를 지불하게 될 것입니다. 함정은 이것입니다: 캐싱 절감액은 전적으로 구조적(structural)입니다. 동일한 제품이라도 동일한 총 토큰(total tokens)을 사용하더라도, 프롬프트(prompts)를 어떻게 배치하느냐에 따라 70%를 절약할 수도 있고 0%를 절약할 수도 있습니다. 대부분의 팀은 캐싱이 기술적으로 "활성화(enabled)"되어 있음에도 불구하고 캐싱이 적용되지 않은 가격을 지불하고 있다는 사실을 깨닫지 못합니다. 이 가이드는 OpenAI prompt caching (프롬프트 캐싱)을 구현할 가치가 있는 정확한 시점, 실제로 얼마나 절약할 수 있는지, 그리고 캐시 적중률(cache hit rate)을 조용히 떨어뜨리는 네 가지 패턴을 분석합니다.

OpenAI prompt caching (프롬프트 캐싱)의 작동 방식 (60초 요약)
2024년 말부터 OpenAI는 주요 추론 모델(reasoning models)에서 자동 프롬프트 캐싱을 지원해 왔습니다.

작동 원리:

• 트리거 (Trigger): 지난 5-10분 이내에 보낸 모든 프롬프트 접두사(prompt prefix)는 캐싱 대상이 됩니다.
• 할인 (Discount): 캐싱된 입력은 현재 대부분의 모델에서 표준 요율의 50%로 청구되며, GPT-5.5에서는 최대 75%까지 할인됩니다 ($5/1M → $1.25/1M cached).
• 별도의 플래그 없음 (No flag to flip): 캐싱은 자동입니다. 사용자가 활성화할 필요도, 요청할 필요도 없습니다. 프롬프트가 캐싱 가능한 구조로 되어 있다면 그냥 발생합니다.

Anthropic의 명시적 캐싱 시스템(cache_control로 블록을 표시하는 방식)과 비교하면, OpenAI의 방식은 더 단순하지만 제어 가능성은 낮습니다. 무엇을 캐싱할지 직접 선택할 수 없으며, OpenAI의 시스템이 접두사 해시 매칭(prefix hash matching)을 기반으로 결정합니다. 이는 구조적 요구 사항을 깨닫기 전까지는 매우 좋게 들리지만, 캐싱 가능한 부분은 반드시 프롬프트의 시작 부분에 있어야 하며 요청 간에 바이트 단위로 일치(match byte-for-byte)해야 합니다.

절감 계산법: 실제 워크로드(Workload)

GPT-5 mini로 구축된 고객 지원 챗봇의 비용을 산정해 보겠습니다:

시스템 프롬프트 (System prompt): 2,000 토큰 (어시스턴트 역할 정의, 도구 사양, 가드레일)
대화 컨텍스트 (Conversation context): ~500 토큰 (최근 3-4회의 사용자/어시스턴트 턴)
사용자 메시지 (User message): 100 토큰
출력 (Output): 250 토큰
볼륨 (Volume): 하루 20,000개의 대화, 각 대화당 4개의 메시지 = 하루 80,000번의 호출

캐싱이 없는 경우 (Without caching)
입력 비용 = 80,000 × 2,600 / 1M × $0.20 = $41.60
출력 비용 = 80,000 × 250 / 1M × $0.80 = $16.00
합계 = 하루 $57.60 = 월 $1,728

캐싱을 사용하는 경우 (시스템 프롬프트에 대해 95% 캐시 히트율 가정)
시스템 프롬프트(2,000 토큰)는 80,000번의 호출 모두에서 동일합니다. 웜업(Warmup) 이후, 한 번에 약 5분 동안 캐싱됩니다. 호출 빈도가 높다고 가정할 때:
캐싱된 입력 = 80,000 × 2,000 × 0.95 / 1M × $0.05 = $7.60
캐싱되지 않은 입력 = 80,000 × 2,000 × 0.05 / 1M × $0.20 = $1.60
동적 부분 (Dynamic part) = 80,000 × 600 / 1M × $0.20 = $9.60
출력 = 80,000 × 250 / 1M × $0.80 = $16.00
합계 = 하루 $34.80 = 월 $1,044

월간 절감액: $684 (40% 감소).
이것을 엔터프라이즈 규모(10배)로 확장하면, 프롬프트를 올바르게 구조화하는 것만으로도 추가 비용 없이 월 $6,840의 절감 효과를 얻을 수 있습니다. 계산기의 캐싱 슬라이더를 사용하여 자신의 워크로드를 모델링할 수 있습니다. "입력의 캐싱된 부분(Cached portion of input)"을 0%에서 100% 사이로 드래그하여 선형적인 비용 변화를 확인해 보세요.

캐싱으로 가장 큰 절감 효과를 얻을 수 있는 때
캐싱이 구조적으로 작동할 것이 확실시되는 네 가지 고레버리지(High-leverage) 시나리오:

1. 안정적인 검색을 활용한 RAG (RAG with stable retrieval)
   패턴: N개의 문서를 검색하여 안정적인 시스템 프롬프트 앞에 붙인 다음, 사용자 쿼리를 추가합니다.
   작동 원리: 만약 Top-K 검색 결과가 유사한 쿼리에 대해 동일한 청크(Chunk)를 반환한다면(FAQ 스타일의 제품에서는 자주 발생함), 검색된 컨텍스트가 캐싱된 접두사(Prefix)가 됩니다. 3,000~5,000 토큰에 달하는 전체 검색 컨텍스트를 캐싱할 수 있습니다.
   주의사항: 벡터 검색(Vector search) 결과가 동일한 쿼리에 대해 결정론적(Deterministic)이어야 합니다. 만약 무작위 타이 브레이킹(Random tie-breaking)을 사용하는 ANN(Approximate Nearest Neighbor)을 사용한다면, 캐시율은 급격히 떨어집니다.

지속적인 컨텍스트를 가진 대화 스레드 (Conversation threads with persistent context)
패턴: 시스템 프롬프트(System Prompt) + 처음 N개의 메시지는 안정적이고, 새로운 메시지가 추가되는 방식의 채팅.
작동 원리: OpenAI는 접두사(Prefix) 단위로 캐싱을 수행합니다. 대화가 (이전 메시지를 수정하는 것이 아니라) 추가되는 방식으로 성장하는 한, 모든 새로운 턴은 이전 턴들의 캐싱 혜택을 받습니다.
주의 사항: 일부 채팅 프레임워크는 메시지 기록을 수정합니다 (예: 오래된 메시지 요약). 모든 수정은 캐시를 깨뜨립니다.

3. 고정된 도구 사양을 가진 에이전트 루프 (Agent loops with fixed tool specs)
   패턴: 여러 반복(Iteration)에 걸쳐 1020개의 도구(Tool) 사이에서 결정을 내리는 에이전트. 도구 사양(Tool spec)은 모든 호출에서 동일합니다.
   작동 원리: 도구 정의는 종종 1,5003,000 토큰에 달합니다. 세션 내의 모든 호출에서 이 정의는 절대 변하지 않습니다. 이것이 가장 레버리지가 높은 캐시입니다. 첫 번째 반복 이후의 모든 반복은 대부분 캐싱됩니다.
   주의 사항: 사용자별로 도구 설명을 동적으로 생성한다면, 캐싱은 깨집니다.

4. 공유된 지침을 사용한 배치 분류 (Batch classification with shared instructions)
   패턴: 서로 다른 입력값과 함께 동일한 분류 프롬프트로 10,000개의 레코드를 처리합니다.
   작동 원리: 분류 지침(종종 500~1,500 토큰)은 레코드 전반에 걸쳐 동일합니다.
   주의 사항: 이는 Batch API(추가 50% 할인)를 사용하기에 완벽한 사례이며, 캐싱과 결합하여 효과가 배가됩니다.

캐싱이 아무런 도움이 되지 않는 경우
기술적으로는 캐싱이 활성화되어 있지만 실질적으로는 무용지물인 네 가지 패턴:

1. 원샷 완료 (One-shot completions)
   애플리케이션이 사용자당 단 한 번의 API 호출만 수행하는 경우 (예: "이 기사 요약하기" 도구), 캐싱할 것이 없습니다. 5~10분의 유효 기간은 다음 사용자가 도착하기 전에 만료됩니다.
   해결책: 방법이 없습니다. 원샷 패턴은 캐싱의 혜틱을 받지 못합니다.

2. 변수가 포함된 매우 동적인 프롬프트 (Highly dynamic prompts with embedded variables)

# 이것은 캐싱을 망가뜨립니다
prompt = f"""
현재 시간은 {datetime.now()}입니다. 사용자 ID: {user_id}
당신은 {product_name}을 위한 유능한 어시스턴트입니다.
[2,000 토큰의 시스템 프롬프트...]
"""

모든 호출이 서로 다른 접두사(타임스탬프 + 사용자 ID)를 가지므로 캐시 일치(Cache match)가 발생하지 않습니다.

해결책: 동적 데이터를 캐시 가능한 접두사(prefix) 이후인 프롬프트의 끝(END)으로 이동합니다: prompt = f""" You are a helpful assistant for {product_name}. [2,000 tokens of system prompt...] Context: Current time {datetime.now()}, User {user_id} """ 이제 처음 약 2,000개의 토큰이 캐시됩니다. 끝에 있는 50개의 동적 토큰은 캐시되지 않지만, 괜찮습니다. 접두사(prefix)만 일치하면 되기 때문입니다.

3. 간헐적인 롱테일 트래픽 (Bursty long-tail traffic)
   사용 패턴이 "1분 동안 200번 호출 후, 30분간 침묵, 다시 200번 호출" 방식이라면, 버스트(burst) 사이에 캐시가 만료됩니다. 각 새로운 버스트의 첫 번째 호출은 캐시 미스(cache miss)가 됩니다.
   해결책: 가치가 높은 엔드포인트(endpoint)의 경우, 침묵 기간 동안 4분마다 작은 "keep-alive" 프롬프트를 전송하세요. 이를 통해 최소한의 비용으로 캐시를 따뜻하게(warm) 유지할 수 있습니다.

4. 순환하는 예시를 사용하는 퓨샷 프롬프트 (Few-shot prompts with rotating examples)

안티 패턴 (Anti-pattern)

examples = random.sample(all_examples, k=5)
prompt = f"{system}\n\nExamples:\n{examples}\n\nUser: {user_input}"

무작위 예시 선택은 매 호출마다 서로 다른 접두사(prefix)를 보장합니다.
해결책: 캐시 윈도우(cache window) 동안에는 예시 세트를 고정(pin)하세요. 더 낮은 빈도(예: 매일)로 순환시키십시오.

캐시 적중률(Cache hit rate) 측정 방법
OpenAI는 API 응답에 캐시 적중 정보를 반환합니다. 이를 반드시 로깅(logging)해야 합니다.
응답 JSON에서 usage.prompt_tokens_details.cached_tokens를 확인하세요:

{
  "usage": {
    "prompt_tokens": 2500,
    "prompt_tokens_details": {
      "cached_tokens": 2000
    },
    "completion_tokens": 250
  }
}

캐시 적중률(Cache hit rate) = cached_tokens / prompt_tokens = 2000 / 2500 = 80%입니다.
건강한 프로덕션 애플리케이션은 캐시 적용 가능 워크플로우(workflows)에 대해 70% 이상의 적중률을 목표로 해야 합니다. 만약 30% 미만이라면 구조적인 문제가 있는 것이며, 대부분 위에서 언급한 네 가지 안티 패턴 중 하나일 가능성이 높습니다.

구현 팁: cached_tokens를 분석 도구에 로깅하세요. 매주 추적하십시오. 캐시 적중률의 하락은 P1 장애(incident)로 취급해야 합니다. 이는 보통 최근 배포가 프롬프트 안정성을 깨뜨렸음을 의미합니다.

손익 분기점 분석: 언제 캐싱을 구현할 가치가 있는가?
OpenAI에서 캐싱 자체는 무료입니다 (캐시 쓰기에 표준 요금의 1.25배를 부과하는 Anthropic과는 다릅니다).

따라서 유일한 비용은 프롬프트 (Prompt)를 구조화하는 데 드는 엔지니어링 시간뿐입니다. 일반적인 팀의 경우:

리팩터링 시간 (Refactor time) = 4-16시간 (기존 코드에 따라 다름)
엔지니어 비용 (Engineer cost) = 시간당 $100-200 (모든 비용 포함)
총 비용 (Total cost) = 일회성 $400-3,200

일반적인 절감액 기준 손익분기점 (Break-even):

월간 OpenAI 지출액	캐싱 절감액 (평균 40%)	손익분기점 도달 시간
$100	$40/월	10-80개월
$500	$200/월	2-16개월
$2,000	$800/월	4개월 미만
$10,000	$4,000/월	1개월 미만

경험 법칙 (Rule of thumb): 만약 OpenAI에 월 $500 이상을 지출하고 캐시 적용이 가능한 워크로드 (Workload)를 실행한다면, 캐싱은 빠르게 비용을 회수합니다. 그 미만인 경우에는 여전히 권장되는 방식이지만 긴급성은 낮습니다.

OpenAI의 캐싱과 Anthropic 및 Google의 비교

OpenAI는 더 단순하지만 제어 가능성은 낮습니다:

제공업체	캐시 트리거 (Cache trigger)	할인율	캐시 쓰기 비용	제어 수준
OpenAI GPT-5.5	자동 접두사 (Automatic prefix)	75% 할인	없음	낮음
OpenAI GPT-5 mini	자동 접두사 (Automatic prefix)	75% 할인	없음	낮음
Anthropic Claude Opus 4.7	명시적 cache_control	90% 할인	1.25배	높음
Anthropic Claude Haiku 4.5	명시적 cache_control	90% 할인	1.25배	높음
Google Gemini 3.0 Pro	컨텍스트 캐싱 (Context caching) API	75% 할인	없음	중간

트레이드오프 (Trade-offs):

• OpenAI는 가장 쉽습니다 — 프롬프트가 이미 잘 구조화되어 있다면 코드 변경 없이 작동합니다.
• Anthropic은 가장 큰 할인율을 제공하지만, 명시적인 캐시 마커 (Cache markers)가 필요하며 약간의 쓰기 할증료를 지불해야 합니다.
• Google의 컨텍스트 캐싱 (Context caching)은 중간 단계에 위치합니다 — 캐시 관리를 위한 API 호출이 필요하지만 정밀한 제어를 제공합니다.

대부분의 팀에게는 OpenAI의 자동 방식이 적절합니다. 대량의 에이전트 (Agent) 워크로드의 경우, Anthropic의 명시적 제어는 그 복잡성을 감수할 가치가 있습니다.

체크리스트: 30분 안에 캐싱 최적화하기
새로운 OpenAI 통합을 시작하는 경우:

• 시스템 프롬프트(system prompt)와 도구 사양(tool specs)을 맨 앞에 배치하세요 (캐시 가능 접두사). 아직 안 함
• 동적 데이터(타임스탬프, 사용자 ID, 최신 사용자 입력 등)는 맨 뒤에 배치하세요. 아직 안 함
• 몇 가지 예시(few-shot examples)는 고정하고 요청마다 무작위로 바꾸지 마세요. 아직 안 함
• 안정적인 검색(stable retrieval)을 사용하세요 (동일한 쿼리에 대해 일관된 순위). 아직 안 함
• 대화 중간에 메시지 기록을 수정하는 것을 피하세요. 아직 안 함
• 캐시 적중률(cached_tokens)을 기록하여 히트율을 추적하세요. 아직 안 함
• 갑작스러운 히트율 하락에 대한 경고를 설정하세요.
  기존 애플리케이션의 경우:
• 가장 트래픽이 많은 상위 3개 프롬프트를 감사(Audit)하세요. 아직 안 함
• 해당 프롬프트에서 모든 동적 콘텐츠를 맨 뒤로 옮기세요. 아직 안 함
• 캐시 적중률을 측정하고 전후를 비교하세요. 아직 안 함
• 히트율이 50% 미만이라면, 바이트 단위의 차이(어떤 부분이 문제를 일으키는지 놀랄 것입니다)를 찾아보세요.
  결론적으로 OpenAI 프롬프트 캐싱은 프로덕션 AI에서 가장 큰 무료 최적화입니다. 절감액은 실질적이며 (입력 비용의 40~75%), 구현 비용은 작습니다 (프롬프트 재구조화 몇 시간). 하지만 가장 흔하게 놓치는 최적화이기도 합니다. 저는 프롬프트에 타임스탬프 변수가 맨 위에 있어 모든 캐시 적중을 방해하는 바람에 불필요하게 5배 이상 지불하고 있는 수십 개의 팀들을 검토했습니다. 해결책은 마법 같은 것이 아니라 구조적인 것입니다. 프롬프트 순서를 올바르게 하고, 캐시 적중률을 기록하면 절감액이 나타납니다.
  특정 워크로드를 모델링하려면 계산기(calculator)를 사용하세요 —