Skip to content

Split View: 프롬프트 캐싱 실전 가이드: 에이전트 앱의 비용과 지연 시간을 함께 줄이는 방법

|

프롬프트 캐싱 실전 가이드: 에이전트 앱의 비용과 지연 시간을 함께 줄이는 방법

들어가며

에이전트 애플리케이션은 생각보다 같은 프롬프트를 반복해서 많이 사용한다. 시스템 지침, 도구 설명, 정책 문서, few-shot 예시, 팀 공용 워크플로우 문구는 요청마다 크게 달라지지 않는다. 반면 사용자의 실제 질문이나 작업 데이터만 조금씩 바뀌는 경우가 많다.

이때 프롬프트 캐싱은 단순한 미세 최적화가 아니라 제품 구조를 바꾸는 수단이 된다. 동일한 접두 프롬프트를 다시 계산하지 않도록 하면 지연 시간과 비용을 함께 낮출 수 있기 때문이다. 특히 멀티 스텝 에이전트, 긴 시스템 프롬프트를 쓰는 코파일럿, 공용 도구 설명이 긴 워크플로우에서 효과가 크다.

이 글에서는 OpenAI와 Anthropic의 공식 문서를 기준으로, 에이전트 앱에서 프롬프트 캐싱을 어떻게 이해하고 적용해야 하는지 실무 관점에서 정리한다.

왜 에이전트 앱에서 캐싱이 중요한가

일반적인 챗봇보다 에이전트 앱이 캐싱의 수혜를 더 크게 보는 이유는 세 가지다.

  1. 시스템 프롬프트가 길다.
  2. 도구 설명과 정책 문서가 반복된다.
  3. 같은 에이전트가 여러 사용자 요청을 비슷한 구조로 처리한다.

예를 들어 내부 운영 에이전트가 다음과 같은 구조를 매번 보낸다고 가정해 보자.

  • 역할과 행동 규칙
  • 보안 및 승인 정책
  • 사용 가능한 도구 목록과 설명
  • 응답 형식 예시
  • 실제 사용자 요청

이 구조에서 앞부분은 거의 고정이고 마지막 사용자 요청만 달라진다. 캐싱이 잘 맞으면 매 요청마다 비싼 접두부를 다시 계산하지 않아도 되므로, 평균 응답 시간이 줄고 트래픽이 늘어도 단가를 더 잘 통제할 수 있다.

OpenAI와 Anthropic은 무엇이 다른가

둘 다 반복 프롬프트에서 비용과 처리 시간을 줄이는 방향은 같지만, 설계 포인트는 다르다.

OpenAI의 핵심 포인트

OpenAI 공식 문서에 따르면 프롬프트 캐싱은 최근 모델 전반에서 자동으로 활성화되며, gpt-4o 이후 계열에서 사용할 수 있다. 또한 캐시 히트는 정확히 일치하는 접두부에서만 가능하다. 그래서 정적인 지침과 예시는 프롬프트 앞쪽에 두고, 사용자별 변수는 뒤쪽으로 보내는 구조가 중요하다.

또한 OpenAI 문서에서는 다음 두 가지 실무 포인트를 강조한다.

  • 프롬프트 길이가 1024 토큰 이상일 때 자동 캐싱이 활성화된다.
  • prompt_cache_key를 사용하면 라우팅과 캐시 적중률 개선에 도움이 될 수 있다.

즉 OpenAI에서는 "접두부를 얼마나 안정적으로 고정하느냐"가 가장 큰 설계 변수다.

Anthropic의 핵심 포인트

Anthropic 공식 문서에 따르면 프롬프트 캐싱은 반복 작업에서 처리 시간과 비용을 줄이는 데 유용하다. Anthropic은 자동 캐싱뿐 아니라 명시적 캐시 브레이크포인트 개념을 제공한다. 기본 캐시 수명은 5분이며, 추가 비용을 내고 1시간 캐시도 사용할 수 있다.

또 하나 중요한 차이는 캐시 범위 표현 방식이다. Anthropic 문서에서는 캐싱 대상이 tools, system, messages 순서로 이어지는 접두부이며, 캐시 브레이크포인트까지 포함된다고 설명한다.

정리하면 다음과 같다.

항목OpenAIAnthropic
기본 접근자동 캐싱자동 캐싱 + 명시적 브레이크포인트
핵심 설계 포인트정확한 접두부 일치캐시 브레이크포인트 설계
최소 길이 관련 정보1024 토큰 이상에서 자동 캐싱공식 문서상 반복 접두부 재사용 중심 설명
캐시 수명 관련 정보공식 문서에서 자동 유지 정책 설명기본 5분, 추가 비용으로 1시간
프롬프트 구성 관점정적 앞, 동적 뒤브레이크포인트 이전에 반복 자산 배치

프롬프트를 어떻게 구조화해야 하나

실무에서는 "프롬프트를 잘 쓴다"보다 "캐시 가능한 접두부를 잘 만든다"가 더 중요해진다. 아래 패턴은 특히 에이전트 앱에 잘 맞는다.

패턴 1: 고정 자산을 맨 앞에 둔다

다음 요소는 가능한 한 앞쪽으로 이동한다.

  • 시스템 지침
  • 정책 문구
  • 도구 설명
  • 공용 예시
  • 고정된 출력 규칙

반대로 아래 요소는 뒤쪽으로 보낸다.

  • 사용자 질문
  • 세션별 상태
  • 요청별 파라미터
  • 변하는 문서 일부
[고정 시스템 지침]
[고정 정책]
[고정 도구 설명]
[고정 few-shot 예시]
[요청마다 바뀌는 사용자 입력]

패턴 2: 접두부를 팀 단위로 표준화한다

캐싱은 "거의 비슷함"이 아니라 "정확히 같은 접두부"가 중요하다. 따라서 팀마다 조금씩 다른 지침 문구를 쓰면 캐시 적중률이 금방 깨진다.

좋은 방식은 다음과 같다.

  • 에이전트별 시스템 프롬프트 템플릿을 하나로 관리한다.
  • 도구 설명 순서를 고정한다.
  • few-shot 예시 개수를 자주 바꾸지 않는다.
  • 운영 중인 실험군이 많다면 캐시 키 전략을 같이 설계한다.

패턴 3: 변화가 잦은 문맥은 뒤로 민다

RAG 문서, 사용자 프로필, 티켓 본문처럼 자주 달라지는 데이터가 앞쪽에 섞이면 캐시 가능한 접두부가 짧아진다. 이 경우 고정 운영 규칙과 도구 설명을 먼저 두고, 검색 결과나 사용자별 컨텍스트는 뒤로 보내는 편이 낫다.

패턴 4: Anthropic에서는 브레이크포인트를 자산 경계로 본다

Anthropic에서는 긴 지식 문서, 공용 정책, 도구 정의처럼 여러 요청에서 재사용할 자산 경계를 기준으로 캐시 브레이크포인트를 잡는 사고가 유용하다. "무엇을 반복 재사용할 것인가"가 먼저고, 그 다음이 브레이크포인트 위치다.

간단한 적용 예시

OpenAI 스타일 예시

아래 예시는 고정 접두부를 앞에 두고, 마지막에 사용자 입력만 붙이는 구조를 보여준다.

{
  "model": "gpt-4o",
  "prompt_cache_key": "support-agent-v1",
  "messages": [
    {
      "role": "system",
      "content": "You are the support operations agent. Follow the policy, use the available tools carefully, and produce a concise action summary."
    },
    {
      "role": "system",
      "content": "Policy: verify account scope, avoid irreversible actions without approval, and log the final decision."
    },
    {
      "role": "system",
      "content": "Tool guide: ticket_lookup, refund_policy_check, escalation_create."
    },
    {
      "role": "user",
      "content": "Customer asks whether order 48291 can be refunded after partial shipment."
    }
  ]
}

핵심은 앞의 세 블록이 오래 유지되는 고정 접두부라는 점이다. 이 구조를 여러 요청에서 유지할수록 캐시 적중 가능성이 높아진다.

Anthropic 스타일 예시

Anthropic에서는 캐시 브레이크포인트까지의 접두부를 재사용 자산으로 생각하면 이해가 쉽다.

{
  "model": "claude-sonnet",
  "system": [
    {
      "type": "text",
      "text": "You are the finance operations agent. Apply policy strictly and explain risk before action."
    },
    {
      "type": "text",
      "text": "Shared policy and workflow documentation goes here.",
      "cache_control": {
        "type": "ephemeral"
      }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "Review this reimbursement request and tell me whether it should be approved."
    }
  ]
}

이 예시에서 반복 재사용하려는 공용 정책 문서가 캐시 대상 경계에 놓인다. 이후 사용자 메시지만 바꿔도 같은 앞부분을 재활용하는 구조를 만들 수 있다.

ROI는 어떤 상황에서 잘 나오나

모든 서비스가 똑같이 이득을 보지는 않는다. 아래처럼 판단하면 현실적이다.

ROI가 큰 경우

  • 긴 시스템 프롬프트를 매번 보내는 에이전트
  • 도구 설명이 많은 워크플로우
  • 동일한 팀 프롬프트를 반복 호출하는 내부 코파일럿
  • 많은 사용자가 공통 접두부를 공유하는 B2B SaaS
  • 긴 문서나 정책을 계속 참조하는 업무 자동화

ROI가 작은 경우

  • 매 요청의 앞부분부터 내용이 크게 달라지는 앱
  • 매우 짧은 프롬프트 중심 서비스
  • 접두부가 매 배포마다 자주 바뀌는 실험 환경
  • 사용자별 개인화 문맥이 프롬프트 앞에 먼저 들어가는 구조

간단히 말해 "고정 자산이 길고, 반복 호출이 많고, 접두부를 안정적으로 유지할 수 있을수록" ROI가 좋아진다.

흔한 실수

1. 변수 데이터를 앞쪽에 섞는다

사용자 이름, 티켓 번호, 최근 이벤트 로그가 시스템 지침보다 먼저 오면 접두부 일치가 깨진다. 캐싱 관점에서는 가장 먼저 고정 자산을 정렬해야 한다.

2. 비슷하지만 정확히 같지 않은 프롬프트를 남발한다

문장 부호 하나, 예시 하나, 도구 순서 하나만 달라도 적중률이 떨어질 수 있다. 팀이 많아질수록 프롬프트 표준화가 중요하다.

3. 캐시 가능한 자산과 실험 자산을 구분하지 않는다

제품 실험을 자주 하면 시스템 프롬프트가 계속 바뀐다. 이때는 실험 구간과 안정 구간을 나눠서, 최소한 공통 정책과 도구 설명만이라도 고정시키는 편이 낫다.

4. Anthropic에서 브레이크포인트를 너무 뒤에 둔다

캐시 브레이크포인트 이전에 반복 자산이 잘 모이도록 설계해야 하는데, 변동성이 큰 사용자 데이터 뒤쪽에 브레이크포인트를 두면 재사용 가치가 작아진다.

5. OpenAI에서 prompt_cache_key 전략 없이 라우팅만 기대한다

OpenAI 문서에서 말하듯 prompt_cache_key는 라우팅과 캐시 적중률 개선에 도움이 될 수 있다. 팀, 에이전트, 버전 단위로 일관되게 키를 설계하면 운영이 쉬워진다.

마이그레이션 체크리스트

프롬프트 캐싱을 도입할 때는 아래 순서가 실무적으로 안전하다.

  1. 현재 프롬프트를 고정 자산과 가변 자산으로 분리한다.
  2. 시스템 지침, 도구 설명, 예시를 접두부로 재배치한다.
  3. 사용자별 데이터와 요청별 문맥을 뒤로 이동한다.
  4. 에이전트별 표준 템플릿을 만든다.
  5. OpenAI를 쓰는 경우 1024 토큰 이상 반복 접두부가 실제로 존재하는지 확인한다.
  6. OpenAI를 쓰는 경우 prompt_cache_key 기준을 팀이나 에이전트 버전 단위로 정한다.
  7. Anthropic을 쓰는 경우 어떤 자산 경계에 캐시 브레이크포인트를 둘지 정한다.
  8. 기본 5분 재사용만으로 충분한지, 1시간 캐시가 필요한지 판단한다.
  9. 배포 후에는 캐시 적중률, 평균 지연 시간, 요청당 비용 변화를 함께 본다.
  10. 프롬프트 실험은 캐시 안정 구간을 해치지 않도록 분리한다.

팀에 바로 공유할 결론

프롬프트 캐싱은 모델 비용을 깎는 옵션이 아니라 에이전트 프롬프트를 더 체계적으로 설계하게 만드는 운영 원칙에 가깝다. OpenAI에서는 정확한 접두부 일치와 접두부 배치가 핵심이고, Anthropic에서는 재사용 자산과 캐시 브레이크포인트 설계가 핵심이다.

에이전트 앱이 길고 반복적인 시스템 자산을 많이 쓴다면, 가장 먼저 해야 할 일은 모델 교체가 아니라 프롬프트를 "캐시 가능한 구조"로 다시 배치하는 것이다. 그것만으로도 비용, 지연 시간, 운영 일관성이 함께 좋아질 가능성이 높다.

References

Prompt Caching for Agent Apps: A Practical Guide to Lower Cost and Latency

Introduction

Agent applications reuse more prompt structure than most teams realize. System instructions, tool descriptions, policy text, shared examples, and workflow rules often stay the same across many requests. Usually only the final user task, document slice, or session state changes.

That makes prompt caching more than a small optimization. In agent products, it can be a structural advantage. If the repeated prefix of a prompt does not need to be processed from scratch every time, teams can reduce both latency and cost while keeping the same agent behavior.

This article explains how to think about prompt caching for real agent systems, using only official OpenAI and Anthropic documentation as factual grounding.

Why prompt caching matters for agent apps

Prompt caching becomes especially valuable when an application has all three of these traits:

  1. Long system instructions
  2. Repeated tool and policy definitions
  3. Many requests that share the same prompt prefix

That is a very common pattern in support agents, internal copilots, workflow assistants, and document-heavy operational agents.

A typical agent request might contain:

  • role and behavior rules
  • safety and approval policy
  • available tools and their descriptions
  • shared examples
  • the actual user request

Most of the expensive prompt tokens live in the repeated setup, not in the final user-specific line. If you can keep that repeated setup stable, caching becomes a direct lever for both product economics and response speed.

How OpenAI and Anthropic differ

Both vendors position prompt caching as a way to reduce time and cost for repetitive work, but they expose different design ideas.

OpenAI

OpenAI documentation says prompt caching is enabled for all recent models, gpt-4o and newer. The same documentation also says cache hits are only possible for exact prefix matches. In practice, that means static instructions and examples should go at the beginning of the prompt, while variable content should go at the end.

OpenAI also states:

  • caching is enabled automatically for prompts that are 1024 tokens or longer
  • prompt_cache_key can improve routing and cache hit rates

So for OpenAI, the main operational question is simple: can your team keep the shared prefix truly stable?

Anthropic

Anthropic documentation says prompt caching reduces processing time and costs for repetitive tasks. Anthropic supports both automatic caching and explicit cache breakpoints. The default cache lifetime is 5 minutes, and Anthropic also offers a 1-hour cache duration at additional cost.

Anthropic also documents the cache scope clearly: prompt caching covers tools, system, and messages up to the cache breakpoint.

So for Anthropic, teams usually think in terms of reusable prompt assets and where the cache breakpoint should sit.

Quick comparison

CategoryOpenAIAnthropic
Main modelautomatic cachingautomatic caching plus explicit breakpoints
Key design ideaexact prefix matchcache breakpoint design
Minimum automatic threshold1024 tokens or longerdocumented around repeated prefixes and breakpoints
Cache lifetime details in groundingautomatic behavior is documenteddefault 5 minutes, optional 1 hour
Best mental modelkeep the prefix stablechoose reusable assets before the breakpoint

Prompt structuring patterns that work

Prompt caching rewards structure, not just prompt quality. The goal is to make the reusable prefix long, stable, and shared across many requests.

Pattern 1: Put static assets first

Move these items to the front whenever possible:

  • system instructions
  • shared policy
  • tool descriptions
  • common examples
  • stable output rules

Move these items later in the prompt:

  • user request
  • per-session state
  • request-specific variables
  • changing document excerpts
[static system instructions]
[shared policy]
[tool descriptions]
[shared examples]
[variable user input]

Pattern 2: Standardize prompts across the team

Caching depends on identical prefixes, not nearly identical prefixes. If every squad rewrites the same support agent instructions in a slightly different way, cache efficiency drops quickly.

Good habits include:

  • one template per agent family
  • fixed tool ordering
  • stable example count
  • consistent versioning for shared prompts

Pattern 3: Push volatile context to the end

Retrieved passages, user profile fields, and fresh event logs often change on every request. If those move into the front of the prompt, the reusable prefix becomes smaller. Keep shared operating rules first, then attach variable context later.

Pattern 4: Treat Anthropic breakpoints as reusable asset boundaries

With Anthropic, it helps to think in terms of prompt assets that should be reused together. Long policy text, shared workflow docs, or large tool instructions are natural places to design around a cache breakpoint.

Simple implementation examples

OpenAI-style example

{
  "model": "gpt-4o",
  "prompt_cache_key": "support-agent-v1",
  "messages": [
    {
      "role": "system",
      "content": "You are the support operations agent. Follow the policy, use the available tools carefully, and produce a concise action summary."
    },
    {
      "role": "system",
      "content": "Policy: verify account scope, avoid irreversible actions without approval, and log the final decision."
    },
    {
      "role": "system",
      "content": "Tool guide: ticket_lookup, refund_policy_check, escalation_create."
    },
    {
      "role": "user",
      "content": "Customer asks whether order 48291 can be refunded after partial shipment."
    }
  ]
}

The first three blocks are the reusable prefix. If that shared prefix stays exactly the same, repeated requests have a better chance of benefiting from caching.

Anthropic-style example

{
  "model": "claude-sonnet",
  "system": [
    {
      "type": "text",
      "text": "You are the finance operations agent. Apply policy strictly and explain risk before action."
    },
    {
      "type": "text",
      "text": "Shared policy and workflow documentation goes here.",
      "cache_control": {
        "type": "ephemeral"
      }
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "Review this reimbursement request and tell me whether it should be approved."
    }
  ]
}

Here the shared policy block is treated as a reusable boundary. Different user questions can vary while the repeated setup remains stable.

ROI scenarios

Prompt caching does not pay off equally everywhere. The best results tend to show up in these cases:

  • agents with long instructions
  • workflows with many tool descriptions
  • internal copilots that reuse the same operating prompt many times
  • B2B products where many requests share a common setup
  • document-heavy operations where the same background context is reused

The payoff is usually weaker when:

  • prompts change significantly from the very beginning
  • requests are consistently short
  • prompt experiments constantly rewrite the shared prefix
  • personalization data appears before the stable instructions

A simple rule works well: the longer and more stable the shared prefix is, and the more often it repeats, the stronger the business case becomes.

Common mistakes

1. Mixing variables into the front of the prompt

If ticket IDs, user names, or fresh logs appear before the shared instructions, the prefix becomes less reusable.

2. Treating similar prompts as good enough

Caching is sensitive to exact prefix reuse. Small wording edits, tool order changes, or example changes can reduce hit rates.

3. Failing to separate stable prompt assets from experimental ones

Teams often run experiments by changing the full system prompt. A better approach is to keep policy and tool definitions stable while isolating the part being tested.

4. Putting Anthropic cache breakpoints too late

If volatile user context appears before the reusable boundary, the cacheable portion loses a lot of value.

5. Ignoring prompt_cache_key strategy on OpenAI

OpenAI documents that prompt_cache_key can improve routing and cache hit rates. If a team uses it consistently by agent family or prompt version, operations tend to become easier to reason about.

Migration checklist

Use this checklist when moving an existing agent workflow toward prompt caching:

  1. Split the current prompt into stable assets and variable assets.
  2. Move shared instructions, tools, and examples into the prefix.
  3. Push user-specific and request-specific content toward the end.
  4. Standardize one prompt template per agent type.
  5. For OpenAI, verify that a repeated prefix of 1024 tokens or more actually exists.
  6. For OpenAI, define a consistent prompt_cache_key strategy by team, agent, or version.
  7. For Anthropic, decide where reusable assets should end and where the cache breakpoint should sit.
  8. Decide whether the default 5-minute reuse window is enough or whether the 1-hour option is justified.
  9. After rollout, monitor cache behavior together with latency and per-request cost.
  10. Keep prompt experiments separate from the stable cached prefix whenever possible.

Final takeaway

Prompt caching is not just a billing feature. For agent applications, it becomes a design discipline. OpenAI pushes teams toward exact shared prefixes and stable prompt ordering. Anthropic pushes teams to think carefully about reusable prompt assets and cache breakpoints.

If your agent product uses long instructions, repeated policies, and shared tool definitions, the first optimization step may not be a new model. It may be a better prompt layout.

References