Prompt Caching 세밀 전략: 캐시 적중률 90%+ 달성과 무효화 함정 피하기

캐시 적중률이 낮은 3가지 구조적 원인

1. 동적 콘텐츠가 캐시 구간 앞에 위치

cache_control 경계는 그 지점까지의 prefix를 캐싱한다. 시스템 프롬프트 앞에 datetime.now()나 user_id를 넣으면 매 요청마다 prefix가 달라져 적중 불가. 올바른 순서: [정적 시스템 프롬프트 → cache_control] → [동적 컨텍스트] → [사용자 입력]

2. 캐시 블록이 너무 작음

최소 캐시 가능 토큰은 claude-3 계열 기준 1024 토큰. 800토큰짜리 시스템 프롬프트에 cache_control을 달아도 캐시가 생성되지 않는다. 실측: 문서 RAG에서 청크를 개별 캐싱하려다 전부 무시된 사례가 흔하다.

3. TTL 미스매치

prompt cache TTL은 5분. 사용자 세션이 5분을 초과하면 캐시가 만료돼 다음 메시지에서 캐시 미스가 발생한다. 고객 지원 챗봇에서 대화 재개 패턴이 길면 적중률이 세션 길이에 반비례한다.

구조 설계와 측정 코드

import anthropic

client = anthropic.Anthropic()

# 올바른 캐시 구조: 정적 → cache_control → 동적
def build_messages(system_doc: str, user_query: str, session_history: list):
    system = [
        {
            "type": "text",
            "text": system_doc,          # 1024+ 토큰의 정적 문서
            "cache_control": {"type": "ephemeral"},  # 경계 표시
        }
    ]
    messages = session_history + [
        {"role": "user", "content": user_query}  # 동적 부분은 캐시 경계 밖
    ]
    return system, messages

def call_with_cache_metrics(system_doc: str, user_query: str, history: list):
    system, messages = build_messages(system_doc, user_query, history)
    resp = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=1024,
        system=system,
        messages=messages,
    )
    usage = resp.usage
    # 캐시 적중률 계산
    total_input = usage.input_tokens + getattr(usage, 'cache_read_input_tokens', 0)
    hit_rate = getattr(usage, 'cache_read_input_tokens', 0) / total_input if total_input else 0
    print(f"캐시 읽기: {getattr(usage, 'cache_read_input_tokens', 0)} | "
          f"캐시 생성: {getattr(usage, 'cache_creation_input_tokens', 0)} | "
          f"적중률: {hit_rate:.1%}")
    return resp

비용 수치: 캐시 읽기는 일반 입력 토큰의 10% 비용, 캐시 생성은 125%. 시스템 프롬프트 4000토큰을 10회 재사용하면 캐시 없이 40,000 토큰 vs 캐시 있을 때 4000×1.25 + 4000×10×0.1 = 9,000 토큰 등가 — 77.5% 절감.

운영 체크리스트

• [ ] cache_read_input_tokens / cache_creation_input_tokens 를 매 요청마다 로깅
• [ ] 목표 적중률 설정: 단일 세션 챗봇 85%+, 배치 문서 분석 95%+
• [ ] 시스템 프롬프트 최소 1024 토큰 확보 (부족하면 패딩 문서 추가)
• [ ] 동적 값(타임스탬프, 유저 ID, 세션 토큰)은 반드시 캐시 경계 뒤에 위치
• [ ] 세션 5분 초과 가능성이 있는 워크플로우는 TTL 만료를 고려해 비용 재계산
• [ ] A/B로 캐시 on/off 비용 비교를 2주 단위로 검증
• [ ] 모델 업그레이드 시 캐시 무효화 발생 — 전환 당일 비용 스파이크 예산 반영