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

• 들어가며
• 왜 에이전트 앱에서 캐싱이 중요한가
• OpenAI와 Anthropic은 무엇이 다른가
  • OpenAI의 핵심 포인트
  • Anthropic의 핵심 포인트
• 프롬프트를 어떻게 구조화해야 하나
  • 패턴 1: 고정 자산을 맨 앞에 둔다
  • 패턴 2: 접두부를 팀 단위로 표준화한다
  • 패턴 3: 변화가 잦은 문맥은 뒤로 민다
  • 패턴 4: Anthropic에서는 브레이크포인트를 자산 경계로 본다
• 간단한 적용 예시
  • OpenAI 스타일 예시
  • Anthropic 스타일 예시
• ROI는 어떤 상황에서 잘 나오나
  • ROI가 큰 경우
  • ROI가 작은 경우
• 흔한 실수
  • 1. 변수 데이터를 앞쪽에 섞는다
  • 2. 비슷하지만 정확히 같지 않은 프롬프트를 남발한다
  • 3. 캐시 가능한 자산과 실험 자산을 구분하지 않는다
  • 4. Anthropic에서 브레이크포인트를 너무 뒤에 둔다
  • 5. OpenAI에서 prompt_cache_key 전략 없이 라우팅만 기대한다
• 마이그레이션 체크리스트
• 팀에 바로 공유할 결론
• References

들어가며

에이전트 애플리케이션은 생각보다 같은 프롬프트를 반복해서 많이 사용한다. 시스템 지침, 도구 설명, 정책 문서, 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 순서로 이어지는 접두부이며, 캐시 브레이크포인트까지 포함된다고 설명한다.

정리하면 다음과 같다.

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

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

패턴 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

• OpenAI Prompt Caching
• Anthropic Prompt Caching