프롬프트 캐싱으로 LLM API 비용 줄이기: Anthropic·OpenAI 캐시 조건과 프롬프트 배치 순서

긴 시스템 프롬프트, 도구 정의, 참고 문서를 매 요청마다 보내는 LLM 기능을 운영하고 있다면 입력 토큰 비용의 상당 부분은 "지난번과 똑같은 앞부분"에서 나온다. 프롬프트 캐싱은 이 앞부분의 처리 결과를 잠시 보관했다가 다음 요청에서 재사용하는 기능이다. 이 글을 읽고 나면 Anthropic과 OpenAI에서 캐시가 걸리는 조건을 구분하고, 프롬프트를 캐시가 잘 맞는 순서로 재배치하고, 응답의 사용량 필드로 실제 적중 여부를 측정할 수 있다.

두 제공자의 캐시 동작 비교

공통 원리는 같다. 요청의 앞에서부터 바이트 단위로 동일한 접두부(prefix)만 재사용된다. 중간 한 글자만 달라도 그 지점 뒤는 새로 처리된다. 차이는 켜는 방식과 수명, 가격 구조에 있다.

수치는 Claude 프롬프트 캐싱 문서와 OpenAI 프롬프트 캐싱 가이드를 2026-10-13에 대조한 값이다. 모델이 추가될 때마다 최소 길이와 배수가 바뀌므로 적용 전 해당 모델 행을 다시 확인한다.

캐시가 맞는 프롬프트 배치 순서

Claude 문서는 캐시 접두부의 순서를 tools → system → messages로 정의하고, 앞 단계가 바뀌면 그 뒤 단계 캐시가 모두 무효가 된다고 설명한다. OpenAI 가이드도 고정된 지시를 앞에, 변하는 내용을 뒤에 두라고 권한다. 실무에서는 다음 순서로 재배치한다.

1. 도구 정의 — 요청마다 도구 목록을 바꾸지 않는다. 사용자 권한에 따라 도구를 빼야 한다면 정의는 그대로 두고 호출 단계에서 막는 방식을 검토한다.
2. 고정 시스템 지시 — 역할, 출력 형식, 금지 규칙.
3. 긴 참고 자료 — 제품 매뉴얼, 코드베이스 요약, few-shot 예시. 같은 문서를 여러 질문에 쓰는 경우 효과가 가장 크다.
4. 대화 이력 — 이전 턴은 그대로 두고 뒤에 추가만 한다.
5. 이번 요청의 가변 부분 — 사용자 질문, 현재 시각, 요청 ID, 검색 결과.

가장 흔한 실수는 시스템 프롬프트 맨 앞에 "오늘 날짜: 2026-10-13 14:03:22" 같은 값을 넣는 것이다. 이 한 줄 때문에 뒤에 오는 수천 토큰이 매번 새로 처리된다. 날짜가 필요하면 날짜 단위로만 넣거나 사용자 메시지 쪽으로 옮긴다.

Claude에서 캐시 지정하기

가장 간단한 방법은 요청 최상위에 cache_control을 하나 두는 자동 캐싱이다. 문서에 따르면 시스템이 마지막 캐시 가능 블록에 중단점을 두고, 대화가 길어지면 앞으로 옮긴다. 세밀하게 제어하려면 블록마다 중단점을 지정하며, 요청당 최대 4개까지 둘 수 있다.

import anthropic

client = anthropic.Anthropic()
MANUAL = open('manual.md', encoding='utf-8').read()  # 매 요청 동일한 긴 문서

def ask(question: str):
    return client.messages.create(
        model='claude-sonnet-5-5',
        max_tokens=1024,
        system=[
            {'type': 'text', 'text': '너는 사내 제품 매뉴얼에 근거해 답하는 지원 담당자다.'},
            {'type': 'text', 'text': MANUAL,
             'cache_control': {'type': 'ephemeral', 'ttl': '1h'},
            },
        ],
        messages=[{'role': 'user', 'content': question}],
    )

for q in ['환불 기한은?', '계정 이전 방법은?']:
    u = ask(q).usage
    print(q, 'write', u.cache_creation_input_tokens,
          'read', u.cache_read_input_tokens, 'uncached', u.input_tokens)

요청 간격이 5분보다 길면 기본 수명으로는 매번 다시 쓰기 비용(1.25배)만 내고 읽기 이득을 못 볼 수 있다. 문서가 1시간 수명을 권하는 경우가 바로 이 상황이다. 반대로 같은 접두부가 몇 초 간격으로 계속 들어오는 챗봇이라면 기본 5분이 쓰기 비용이 더 싸다.

문서의 무효화 표에서 놓치기 쉬운 항목은 도구 정의 변경(전체 무효), 이미지 추가·삭제와 tool_choice 변경(messages 단계 무효), thinking 설정 변경(messages 단계 무효)이다. 또 중단점마다 이전 캐시를 찾을 때 뒤로 최대 20개 블록까지만 확인하므로, 대화가 매우 길어지면 중간에 중단점을 하나 더 두는 것이 적중률 유지에 유리하다.

OpenAI에서 적중률 높이기

OpenAI는 별도 지정 없이 접두부를 캐시한다. 가이드에 따르면 prompt_cache_key는 GPT-5.6 이전 모델에서 관련 요청을 같은 캐시로 보내는 데 쓰이고, GPT-5.6 이후에는 고객·사용자별 캐시 집계와 다른 사용자 간 캐시 탐지 방지에 쓰인다. 장시간 보관은 모델 세대에 따라 prompt_cache_retention 또는 prompt_cache_options.ttl로 지정한다. 도구 목록을 바꿔야 할 때는 스키마를 다시 정의하지 말고 allowed_tools로 사용 범위만 바꾸라고 권한다.

from openai import OpenAI
client = OpenAI()

res = client.responses.create(
    model='gpt-5.6',
    instructions=FIXED_INSTRUCTIONS + MANUAL,   # 고정 접두부
    input=question,                              # 가변 부분은 뒤에
    prompt_cache_key=f'tenant-{tenant_id}',
)
print(res.usage.input_tokens, res.usage.input_tokens_details.cached_tokens)

적중률을 수치로 남기는 방법

캐시는 "켰다"가 아니라 "맞았다"를 확인해야 한다. 응답마다 사용량 필드를 로그에 남기고 일 단위로 적중률을 계산한다. Claude 문서는 전체 입력 토큰을 cache_read_input_tokens + cache_creation_input_tokens + input_tokens로 정의한다.

// 로그 레코드 배열에서 Claude 캐시 적중률과 예상 비용 배수 계산
function cacheStats(rows) {
  let read = 0, write = 0, plain = 0;
  for (const u of rows) {
    read += u.cache_read_input_tokens || 0;
    write += u.cache_creation_input_tokens || 0;
    plain += u.input_tokens || 0;
  }
  const total = read + write + plain;
  // 5분 TTL 기준 배수: 읽기 0.1, 쓰기 1.25, 일반 1.0 (모델별로 확인)
  const weighted = read * 0.1 + write * 1.25 + plain;
  return { hitRate: read / total, costRatio: weighted / total };
}

costRatio가 1보다 크면 캐시 쓰기만 반복되고 읽기가 거의 없는 상태다. 이때는 가변 값이 접두부에 섞였는지, 요청 간격이 수명보다 긴지 먼저 확인한다. 호출 로그 스키마 설계는 LLMOps 모니터링 항목과 구현에, 사용자별 토큰 예산과 429 처리는 AI API 비용과 Rate Limit 설계에 정리했다.

적용 전에 점검할 세 가지

첫째, 캐시 대상 접두부가 해당 모델의 최소 길이를 넘는지 토큰 수를 센다. 최소 길이 미만이면 지정해도 아무 일도 일어나지 않는다. 둘째, 접두부 안에 사용자별 값(이름, 권한, 세션 ID)이 섞여 있지 않은지 본다. 사용자마다 달라지면 사실상 개인 캐시가 되어 적중률이 낮아진다. 셋째, 개발 도구에서 같은 원리를 쓰는 사례도 함께 확인한다. Claude Code의 설정 파일과 세션 관리가 토큰 사용량에 미치는 영향은 Claude Code 토큰 사용량 줄이는 설정에서 다뤘다.