프롬프트 캐싱 알아보기: 비용을 절감할 수 있는 때와 그렇지 않은 때

프롬프트 캐싱이 실제로 캐시하는 것

프롬프트 캐싱은 의미 기반 메모리가 아닙니다. 제공자가 “이건 이전에 보낸 내용과 비슷해 보이네요”라고 판단하는 것이 아닙니다. 다음에 더 가깝습니다.

“이 모델과 캐시 정책을 기준으로 볼 때, 이 요청의 시작 부분이 이전 토큰 시퀀스와 충분히 일치하므로 해당 접두부의 내부 연산을 재사용할 수 있습니다.”

이 구분은 중요합니다.

프롬프트 캐싱은 일반적으로 다음과 같은 동일한 긴 접두부를 반복해서 보낼 때 도움이 됩니다.

• 시스템 지시
• 도구 스키마
• 긴 문서 묶음
• 제품 카탈로그
• 코드베이스 컨텍스트
• 법률 또는 정책 매뉴얼
• 퓨샷 예시
• 여러 요청에서 재사용되는 정적 검색 결과

각 요청의 시작 부분이 다음과 같이 달라지면 대체로 큰 도움이 되지 않습니다.

• 맨 앞에 있는 동적 타임스탬프
• 공통 콘텐츠 앞에 있는 사용자별 데이터
• 무작위로 바뀌는 예시 순서
• 캐시 가능한 구간 안에 있는 요청별 UUID
• 순서나 형식이 바뀌는 검색 청크
• 고정된 지침 앞에 배치된 대화 기록

엔지니어링 측면에서 핵심은 변하지 않고 처리 비용이 큰 컨텍스트를 앞에, 자주 바뀌는 컨텍스트를 뒤에 배치하는 것입니다.

Anthropic과 OpenAI 비교: 비슷한 목표, 다른 제어 방식

Anthropic과 OpenAI 모두 프롬프트 캐싱을 지원하지만, 개발자가 사용하는 방식은 다릅니다.

Anthropic은 프롬프트 캐싱을 더 명시적으로 제공합니다. 콘텐츠 블록에 캐시 제어 설정을 지정한 다음, 다음과 같은 사용량 필드를 확인할 수 있습니다. cache_creation_input_tokens 및 cache_read_input_tokens. 이를 통해 캐시 항목을 생성하는지, 아니면 기존 항목에서 읽는지 더 쉽게 파악할 수 있습니다.

OpenAI의 프롬프트 캐싱은 지원되는 모델에서 더 자동으로 작동합니다. 프롬프트 접두부가 재사용되면 캐시된 입력 토큰에 다른 요금이 적용되고 사용량 메타데이터에 표시될 수 있습니다. 일반적으로 같은 방식으로 명시적인 캐시 경계점을 지정하지는 않습니다. 대신 재사용할 접두부가 바이트 및 토큰 수준에서 변하지 않도록 요청을 구성합니다.

실질적인 차이는 제어와 편의성에 있습니다.

구현 세부 사항은 모델과 제공자에 따라 다르며 계속 발전하고 있습니다. 하지만 아키텍처 원칙은 변하지 않습니다. 캐싱은 비슷한 프롬프트가 아니라 반복되는 접두부에 관한 것입니다.

요금 모델: 생성과 읽기

프롬프트 캐싱을 이해하는 유용한 방법은 입력 토큰을 세 가지 범주로 나누는 것입니다.

1. 일반 입력 토큰: 일반 입력 요금으로 청구됩니다.
2. 캐시 생성 토큰: 캐시 항목을 생성하는 데 사용되는 토큰으로, 할증 요금이나 별도의 쓰기 요금이 적용되는 경우가 많습니다.
3. 캐시 읽기 토큰: 기존 캐시 항목에서 읽는 토큰으로, 일반적으로 할인된 요금이 적용됩니다.

Anthropic은 다음과 같은 사용량 필드를 통해 이 구분을 직접 제공합니다.

{
  "usage": {
    "input_tokens": 812,
    "cache_creation_input_tokens": 42000,
    "cache_read_input_tokens": 0,
    "output_tokens": 684
  }
}

이후 요청에서 접두부가 캐시에 적중하면 다음과 비슷한 결과가 나오는 것이 바람직합니다.

{
  "usage": {
    "input_tokens": 936,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 42000,
    "output_tokens": 711
  }
}

첫 호출은 캐시를 생성합니다. 이후 호출은 캐시에서 읽습니다.

비용 효율은 제공자의 현재 요금, 캐시 TTL, 모델에 따라 달라집니다. 요금은 바뀌므로 저는 설계 문서에 숫자를 하드코딩하기보다 코드에서 변수를 사용해 모델링하는 것을 선호합니다.

다음은 특정 경로에 캐싱을 구현할 가치가 있는지 판단할 때 제가 사용하는 짧은 Python 함수입니다.

def cache_savings(
    cached_tokens: int,
    normal_input_per_mtok: float,
    cache_write_per_mtok: float,
    cache_read_per_mtok: float,
    requests: int,
) -> dict:
    mtok = cached_tokens / 1_000_000

    no_cache = requests * mtok * normal_input_per_mtok
    with_cache = (
        mtok * cache_write_per_mtok +
        (requests - 1) * mtok * cache_read_per_mtok
    )

    return {
        "no_cache": round(no_cache, 6),
        "with_cache": round(with_cache, 6),
        "savings": round(no_cache - with_cache, 6),
        "savings_pct": round((1 - with_cache / no_cache) * 100, 2),
    }


print(cache_savings(
    cached_tokens=42_000,
    normal_input_per_mtok=3.00,
    cache_write_per_mtok=3.75,
    cache_read_per_mtok=0.30,
    requests=100,
))

여기에는 예시용 요금만 사용했습니다. 중요한 것은 계산 구조입니다.

재사용 가능한 접두부가 42,000토큰이고 요청이 100건이라면 캐싱은 대체로 매우 효과적입니다. 같은 접두부라도 요청이 단 한 번뿐이라면, 쓰기 요금이 일반 입력 요금보다 높을 경우 캐싱으로 인해 비용이 더 늘어날 수 있습니다.

이것이 첫 번째 주요 함정입니다. 프롬프트 캐싱은 초기 비용을 여러 번의 사용에 나누어 상쇄하는 방식입니다. 캐시된 접두부를 재사용하지 않으면 이점을 얻을 수 없습니다.

손익분기점 공식

다음 식으로 손익분기점을 추정할 수 있습니다.

no_cache_cost = N * T * normal_price

cache_cost = T * write_price + (N - 1) * T * read_price

각 항목의 의미는 다음과 같습니다.

• N 는 동일한 접두부를 사용하는 요청 수입니다.
• T 는 캐시 가능한 토큰 수입니다.
• normal_price 는 일반 입력 토큰 요금입니다.
• write_price 는 캐시 생성 요금입니다.
• read_price 는 캐시 읽기 요금입니다.

다음 조건에서 캐싱으로 비용이 절감됩니다.

T * write_price + (N - 1) * T * read_price
  <
N * T * normal_price

이 T 는 순수한 비용 손익분기점 계산에서는 약분되어 사라집니다. 즉, 재사용 횟수와 상대적인 요금이 결정을 좌우합니다. 하지만 운영 측면에서는 여전히 토큰 수가 중요합니다. 500토큰에서 80%를 절감하는 것은 미미하지만, 80,000토큰에서 같은 비율을 절감하면 별도의 비용 항목으로 볼 만한 규모가 됩니다.

대략적인 계산에 유용한 형태는 다음과 같습니다.

break_even_requests =
  (write_price - read_price) / (normal_price - read_price)

캐시 쓰기 요금이 일반 입력 요금보다 조금만 비싸고 읽기 요금은 훨씬 저렴하다면, 손익분기점은 매우 낮을 수 있습니다. 캐시 쓰기 요금이 비싸거나 접두부가 거의 반복되지 않는다면 캐싱의 효과를 안정적으로 얻기 어렵습니다.

변하지 않는 접두부를 위한 프롬프트 구성 방법

가장 효과적인 프롬프트 캐싱 최적화는 API 플래그가 아니라 프롬프트 배치입니다.

좋지 않은 배치:

Request ID: req_8f19a
Current time: 2026-02-14T09:12:33Z
User: customer_4812
Locale: en-US

SYSTEM INSTRUCTIONS:
...

POLICY MANUAL:
[42,000 tokens of stable text]

USER QUESTION:
Can I get a refund after 45 days?

이렇게 하면 프롬프트가 시작부터 달라지므로 접두부 캐싱이 작동하지 않습니다.

더 나은 배치:

SYSTEM INSTRUCTIONS:
...

POLICY MANUAL:
[42,000 tokens of stable text]

DYNAMIC REQUEST METADATA:
Request ID: req_8f19a
Current time: 2026-02-14T09:12:33Z
User: customer_4812
Locale: en-US

USER QUESTION:
Can I get a refund after 45 days?

변하지 않는 블록이 먼저 옵니다. 동적 블록은 그 뒤에 옵니다.

Anthropic 방식의 명시적 캐싱은 개념적으로 다음과 같은 형태일 수 있습니다.

{
  "model": "claude-sonnet-4-6",
  "max_tokens": 800,
  "system": [
    {
      "type": "text",
      "text": "You are a support policy assistant..."
    },
    {
      "type": "text",
      "text": "Refund policy manual v2026-02-01:\n\n...",
      "cache_control": {
        "type": "ephemeral"
      }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "Can I get a refund after 45 days?"
    }
  ]
}

정확한 요청 스키마는 API 버전과 SDK에 따라 달라지므로, 그대로 복사해 붙여 넣는 코드가 아니라 구조를 보여 주는 예시로 보세요. 중요한 점은 크고 변하지 않는 블록을 명시적으로 캐시 가능하게 지정하고, 호출 간에 변경하지 않는 것입니다.

OpenAI 방식의 자동 캐싱에서도 블록을 수동으로 지정하지 않더라도 프롬프트 구조는 똑같이 중요합니다.

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "system",
      "content": "You are a support policy assistant...\n\nRefund policy manual v2026-02-01:\n\n..."
    },
    {
      "role": "user",
      "content": "Can I get a refund after 45 days?"
    }
  ]
}

시스템 메시지가 요청마다 바뀐다면 일관된 캐시 읽기를 기대해서는 안 됩니다.

실용적인 아키텍처 패턴

프로덕션 시스템에서는 캐시된 프롬프트 접두부를 애플리케이션 코드에 명시적으로 표현하는 방식을 선호합니다.

간단한 패턴 하나는 다음과 같습니다.

prompt_prefix/
  support_policy_v17.txt
  tool_schema_v4.json
  examples_v9.md

runtime_request/
  user_question
  user_profile
  retrieved_recent_orders

그런 다음 요청을 다음과 같이 구성합니다.

from pathlib import Path

POLICY_PREFIX = Path("prompt_prefix/support_policy_v17.txt").read_text()
TOOL_SCHEMA = Path("prompt_prefix/tool_schema_v4.json").read_text()
EXAMPLES = Path("prompt_prefix/examples_v9.md").read_text()

def build_prompt(user_question: str, user_profile: dict) -> str:
    stable_prefix = f"""
You are a support policy assistant.

TOOLS:
{TOOL_SCHEMA}

POLICY:
{POLICY_PREFIX}

EXAMPLES:
{EXAMPLES}
""".strip()

    dynamic_suffix = f"""
USER PROFILE:
{user_profile}

USER QUESTION:
{user_question}
""".strip()

    return stable_prefix + "\n\n--- DYNAMIC REQUEST ---\n\n" + dynamic_suffix

실제로 저는 접두부의 버전도 관리합니다. 정책 매뉴얼이 바뀌면 이를 의도적인 캐시 무효화 이벤트로 처리하고 싶기 때문입니다.

sha256sum prompt_prefix/support_policy_v17.txt

이 해시는 모델 이름, 캐시 생성 토큰 수, 캐시 읽기 토큰 수, 요청 경로와 함께 로그에 기록됩니다. 이런 관측 가능성이 없으면 캐시 버그를 다루기 어렵습니다. 응답은 여전히 정상적으로 작동하고 비용만 더 들기 때문입니다.

유용한 로그 항목은 다음과 같습니다.

{
  "route": "support.answer",
  "model": "claude-sonnet-4-6",
  "prefix_hash": "9d3a4a...",
  "input_tokens": 932,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 42000,
  "output_tokens": 688,
  "latency_ms": 1840
}

청구 내역만 보고 최적화하지 마세요. 경로별로 캐시 동작을 로그에 기록하세요.

지연 시간: 대체로 개선되지만 만능은 아님

프롬프트 캐싱은 모델 제공자가 캐시된 접두부의 연산을 재사용할 수 있으므로 지연 시간을 줄일 수 있습니다. 하지만 제 워크로드에서 직접 측정하지 않았다면, 지연 시간이 일정하게 줄어든다고 가정하고 SLA를 설계하지는 않을 것입니다.

프로덕션에서 실제로 일어나는 일은 더 복잡합니다.

• 짧은 프롬프트에서는 지연 시간이 유의미하게 달라지지 않을 수 있습니다.
• 캐시된 접두부가 길면 첫 토큰까지의 시간이 개선되는 경우가 많습니다.
• 많은 요청에서는 여전히 출력 길이가 전체 처리 시간에 가장 큰 영향을 미칩니다.
• 도구 호출, 네트워크 지연, 대기열 대기가 캐시의 이점을 가릴 수 있습니다.
• 쓰기가 읽기보다 느리면 캐시 미스로 인해 꼬리 지연 시간이 급증할 수 있습니다.

현실적인 벤치마크 설정은 간단합니다.

# warm cache
python run_eval.py --case support_refund --repeat 1

# measure cache reads
python run_eval.py --case support_refund --repeat 50 --jsonl out.jsonl

# inspect p50/p95 by cache_read_input_tokens > 0
python analyze_latency.py out.jsonl

캐시 적중 요청과 캐시 미스 요청을 따로 측정하세요. 둘을 섞으면 어느 쪽도 설명하지 못하는 수치가 나옵니다.

실제 시스템에서 자주 보는 함정

1. 고정 콘텐츠 앞에 배치된 동적 콘텐츠

가장 흔한 실패 사례입니다. 타임스탬프, 요청 ID, 기능 플래그 덤프, 사용자 로캘 또는 실험 배정 정보가 시스템 프롬프트 맨 위에 들어갑니다.

아래로 옮기세요.

2. “동등한” JSON은 캐시 관점에서 동등하지 않습니다

이 두 스니펫은 의미상 동일하지만 캐시 관점에서도 반드시 동일한 것은 아닙니다.

{"name":"refund_lookup","timeout":3,"strict":true}

{
  "strict": true,
  "timeout": 3,
  "name": "refund_lookup"
}

캐시된 접두부에 도구 스키마나 설정을 포함한다면 결정론적으로 직렬화하세요.

import json

def stable_json(data: dict) -> str:
    return json.dumps(data, sort_keys=True, separators=(",", ":"))

이렇게 하면 키 순서나 공백 변경으로 인한 의도치 않은 캐시 미스를 방지할 수 있습니다.

3. 검색이 캐시 가능성을 무너뜨릴 수 있습니다

RAG 시스템은 흔히 다음과 같이 프롬프트를 구성합니다.

Retrieved documents:
[doc A]
[doc B]
[doc C]

Instructions:
...

검색 결과가 쿼리마다 다르면 접두부도 쿼리마다 달라집니다. 검색된 컨텍스트가 실제로 동적이라면 괜찮지만, 고정 지침을 그 뒤에 두지는 마세요.

더 나은 구성:

Instructions:
...

Long-lived product documentation:
[stable docs]

Query-specific retrieved documents:
[doc A]
[doc B]
[doc C]

요청량이 많은 시스템에서는 컨텍스트를 다음과 같이 나누는 것을 고려하세요.

• 전체에 공통으로 적용되는 고정 지침
• 테넌트별 고정 문서
• 사용자 및 쿼리별 검색 결과

각 계층의 캐시 동작은 서로 다릅니다.

4. 캐시 TTL이 중요합니다

일부 캐시 항목은 만료됩니다. 트래픽이 몰리는 형태라면 접두부가 십 분 동안 집중적으로 재사용된 뒤 더 이상 사용되지 않을 수 있습니다. 캐시 수명을 늘리면 도움이 될 수 있지만, 제공업체와 모델에 따라 가격이나 지원 여부가 달라질 수 있습니다.

이때 요청 분포가 중요해집니다. “하루에 10,000건의 요청을 받는다”는 정보보다 “오전 9시부터 오전 10시까지 정확히 이 접두부에 대해 분당 200건의 요청을 받는다”는 정보가 더 유용합니다.

5. 모델 변경은 기존 가정을 무효화합니다

한 모델에 대해 캐시된 접두부를 다른 모델에서도 재사용할 수 있다고 가정해서는 안 됩니다. Claude Opus 4.8, Sonnet 4.6, GPT-5.5, Gemini 3 또는 Llama, Qwen, DeepSeek, MiniMax, Kimi 같은 개방형 모델 사이에서 요청을 라우팅한다면 모델별로 캐시 동작을 추적하세요.

다중 모델 라우팅은 유용하지만 비용 회수 계산을 복잡하게 만듭니다. 트래픽을 다섯 갈래로 나누면 각 모델에서 반복되는 접두부가 줄어들 수 있습니다.

6. 프롬프트 개인화가 역효과를 낼 수 있습니다

팀에서는 흔히 시스템 프롬프트를 개인화합니다.

You are helping {{customer_name}}, who is on plan {{plan_name}}.

별문제 없어 보이지만, 캐시된 콘텐츠 앞에 개인화 내용이 있으면 고객마다 접두부가 달라집니다. 개인화 내용이 고정 블록에 대한 모델의 해석을 실제로 바꾸는 경우가 아니라면 뒤에 배치하세요.

프롬프트 캐싱이 비용을 절감하는 경우

캐싱은 보통 다음과 같은 경우에 매우 적합합니다.

• 캐시 가능한 접두부가 크며, 흔히 수천 또는 수만 토큰에 이릅니다.
• 완전히 동일한 접두부가 여러 번 재사용됩니다.
• 여러 요청에 걸쳐 접두부가 일정하게 유지됩니다.
• 캐시 수명 내에 트래픽이 유입됩니다.
• 캐시 생성 토큰과 캐시 읽기 토큰을 관찰할 수 있습니다.
• 라우트의 프롬프트 구성을 예측할 수 있습니다.

구체적인 예:

• 코딩 어시스턴트가 동일한 저장소 구조도와 스타일 가이드를 반복해서 포함합니다.
• 지원 봇이 모든 환불 질문에 동일한 정책 매뉴얼을 포함합니다.
• 에이전트가 모든 요청에 대규모의 정적 도구 스키마를 사용합니다.
• 내부 연구 어시스턴트가 팀을 위해 동일한 자료 모음 개요를 포함합니다.

이러한 워크로드에서는 컨텍스트 품질을 낮출 필요가 없으므로 프롬프트 캐싱이 가장 효과적인 비용 최적화 방법 중 하나가 될 수 있습니다. 긴 프롬프트는 유지하되 매번 입력 요금을 전액 지불하지 않게 되는 것입니다.

프롬프트 캐싱이 도움이 되지 않는 경우

다음과 같은 경우에는 캐싱의 효과가 미미하거나 오히려 손해가 됩니다.

• 프롬프트가 짧습니다.
• 접두부가 거의 재사용되지 않습니다.
• 컨텍스트 대부분이 쿼리별 검색 결과입니다.
• 동적 데이터가 고정 데이터 앞에 있습니다.
• 실험 중에 지침을 계속 수정합니다.
• 트래픽이 여러 모델, 테넌트 또는 프롬프트 변형에 소량씩 분산됩니다.
• 캐시 쓰기 비용이 더 높고 읽기가 너무 드물어 그 비용을 회수하지 못합니다.

평가 중에 흔히 빠지는 함정이 있습니다. 노트북에서는 각 사례를 한 번씩만 실행하므로 프롬프트 캐싱의 효과가 나빠 보입니다. 그러다가 프로덕션에서는 수천 명의 사용자가 동일한 고정 접두부를 공유하므로 매우 효과적으로 보입니다. 반대 상황도 발생합니다. 데모에서는 동일한 프롬프트를 100번 반복해 큰 비용 절감 효과를 보여 주지만, 프로덕션에서는 테넌트별 맞춤 설정 때문에 재사용이 불가능합니다.

실제 요청 분포로 테스트하세요.

간단한 캐시 준비 상태 체크리스트

프롬프트 캐싱을 활성화하거나 이에 의존하기 전에 다음을 확인합니다.

• 수천 토큰을 넘는 고정 접두부가 하나 이상 있나요?
• 그 접두부가 모든 동적 콘텐츠 앞에 있나요?
• 직렬화가 결정론적인가요?
• 접두부의 버전을 관리하고 해시를 생성하나요?
• 캐시 생성 토큰과 캐시 읽기 토큰을 로그에 기록할 수 있나요?
• 캐시 수명 내 예상 재사용 횟수를 알고 있나요?
• 캐시 적중과 캐시 미스의 지연 시간을 따로 측정했나요?

세 항목 이상에 대한 답이 “아니요”라면 캐싱이 작동할 수도 있지만, 추측에 의존하고 있는 것입니다.

실무 핵심 요점

프롬프트 캐싱은 마법 같은 압축 기술이 아닙니다. 고정된 토큰 접두부를 재사용하는 것이며, 생성 비용은 한 번 지불하고 더 낮은 읽기 비용은 여러 번 지불하는 데서 경제성이 생깁니다.

엔지니어링 실행 지침은 간단합니다.

• 지침, 도구, 문서, 예시처럼 크고 고정된 콘텐츠를 먼저 배치하세요.
• 타임스탬프, 사용자 메타데이터, 검색 결과, 요청 ID를 캐시 가능한 접두부 뒤로 옮기세요.
• 추적하세요 cache_creation 대비 cache_read 라우트 및 모델별 토큰 수.
• JSON 도구 스키마와 설정에는 결정론적 직렬화를 사용하세요.
• 실제 제공업체 가격과 트래픽 분포를 사용해 손익분기점을 모델링하세요.
• 다중 모델 라우팅, 테넌트별 맞춤 설정, 짧은 프롬프트에는 주의하세요.
• 평균값을 신뢰하기보다 적중과 미스의 지연 시간을 따로 측정하세요.

제가 본 최고의 프롬프트 캐시 최적화는 전혀 기발하지 않았습니다. 고정 토큰 42,000개를 동적 토큰 12개 위로 옮겼을 뿐입니다. 모델의 동작은 달라지지 않았지만 청구 금액은 달라졌습니다.