Prompt Caching 심층 운영: 캐시 히트율 90% 달성 전략과 함정

왜 캐시 히트율이 낮아지는가

prompt caching은 cache_control 블록을 prefix로 지정한 토큰을 5분간 서버 측에 보존한다. 가장 흔한 실패 모드는 캐시 대상 위치를 동적 콘텐츠 앞에 두지 않는 것이다. 시스템 프롬프트 뒤에 타임스탬프나 사용자 ID를 삽입하면 매 요청마다 캐시가 무효화된다. 실측 기준으로, 1000토큰 시스템 프롬프트를 정적 prefix로 고정했을 때 캐시 히트 시 입력 비용이 90% 절감된다(캐시 읽기는 기본 입력가의 10%).

두 번째 함정은 5분 TTL 내에 충분한 트래픽이 없는 경우다. 배치성 작업이나 저빈도 엔드포인트에서는 캐시 쓰기 비용(기본 입력가의 125%)만 발생하고 히트 없이 만료된다. 캐시 쓰기 오버헤드를 회수하려면 5분 내 동일 prefix 요청이 최소 3회 이상 있어야 손익분기를 넘긴다.

구조 설계 원칙과 코드 예제

정적 레이어(시스템 프롬프트, RAG 문서 청크, few-shot 예시)를 앞에 배치하고 동적 레이어(사용자 메시지, 세션 변수)를 뒤에 둔다. cache_control은 정적 레이어의 마지막 블록에만 붙인다.

import anthropic

client = anthropic.Anthropic()

STATIC_SYSTEM = """당신은 법률 문서 분석 전문가입니다.
[... 800토큰 분량의 가이드라인 ...]"""

def analyze_document(user_query: str, document_chunk: str) -> str:
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": STATIC_SYSTEM,
                "cache_control": {"type": "ephemeral"}  # 정적 prefix에만 적용
            }
        ],
        messages=[
            {"role": "user", "content": f"문서: {document_chunk}\n\n질문: {user_query}"}
        ]
    )
    usage = response.usage
    cache_hit = usage.cache_read_input_tokens > 0
    print(f"캐시 히트: {cache_hit}, 절감 토큰: {usage.cache_read_input_tokens}")
    return response.content[0].text

usage.cache_creation_input_tokens와 usage.cache_read_input_tokens를 반드시 로깅해야 실제 히트율을 측정할 수 있다.

운영 체크리스트

비용 트레이드오프: 캐시 쓰기는 +25% 오버헤드이므로 저빈도 엔드포인트에서는 비활성화를 검토한다. 고빈도(분당 10+ 요청) 엔드포인트에서만 기본 활성화를 권장한다.

모니터링 알림 기준:

• 히트율 < 60%: prefix 구조 점검
• 캐시 쓰기 비율 > 히트 비율 × 2: TTL 내 트래픽 부족, 캐싱 비활성화 고려
• 응답 레이턴시 급증 시 캐시 미스 폭증 여부 교차 확인

멀티 테넌트 환경 주의: 테넌트별로 시스템 프롬프트가 다르면 캐시가 공유되지 않는다. 공통 prefix를 최대화하고 테넌트별 차이는 user 메시지로 이동하는 리팩토링이 유효하다.

롤링 배포 시: 시스템 프롬프트를 변경하면 기존 캐시가 전부 무효화된다. 배포 직후 5분간 비용 스파이크를 예상하고 알림 임계값을 일시적으로 완화한다.