AI 에이전트 프롬프트 캐싱 — 응답 속도를 높이는 공짜 최적화

AI 에이전트를 운영하다 보면 같은 시스템 프롬프트를 수백, 수천 번 반복해서 처리한다. 도구 정의 10개가 달린 에이전트라면 매 요청마다 LLM이 같은 텍스트를 다시 파싱하고 처리한다. 이걸 한 번만 처리하고 재사용할 수 있다면? 그게 프롬프트 캐싱이다.

프롬프트 캐싱이란

LLM API 요청에서 변하지 않는 부분을 캐시해서 재처리를 줄이는 최적화다. 시스템 프롬프트, 도구 정의, 긴 문서처럼 매 요청마다 반복되는 정적 컨텐츠가 대상이다.

비유하면 매일 같은 요리를 만드는 요리사가 있다고 해보자. 매번 레시피를 처음부터 읽는 대신, 이미 읽고 이해한 레시피를 머릿속에 유지하는 것이다. 재료만 새로 들어오면 나머지 단계는 훨씬 빠르게 진행된다.

3단계 동작 과정

1. 첫 요청 (Cache Miss)
   시스템 프롬프트 → LLM 처리 → 캐시 저장
   응답 시간: 일반 속도
 
2. 후속 요청 (Cache Hit)  
   시스템 프롬프트 → 캐시에서 로드
   응답 시간: 더 빠름, 처리 비용 없음
 
3. 5분 미활동
   캐시 자동 삭제 → 다음 요청은 Cache Miss

캐시는 5분 TTL이다. 5분 내에 같은 프롬프트로 요청이 들어오면 캐시 히트가 발생한다. 에이전트처럼 짧은 간격으로 연속 요청이 들어오는 패턴에 특히 효과적이다.

[💡 잠깐! 이 용어는?] TTL(Time-To-Live): 캐시가 유효한 시간. TTL이 지나면 캐시가 만료되어 다음 요청에서 다시 생성해야 한다. 5분 TTL이면 5분 이내 동일 요청은 캐시에서 처리된다.

모델별 최소 토큰 임계값

캐시가 활성화되려면 캐싱할 내용이 일정 토큰 이상이어야 한다. 너무 짧은 프롬프트는 캐싱 효율이 없어서 임계값을 설정한다.

Claude Sonnet 4.5 기준으로 1,024 토큰은 대략 800단어 정도다. 도구 정의 5~10개 + 시스템 프롬프트면 충분히 넘는다.

어디에 쓰면 좋은가

캐싱이 가장 효과적인 패턴이다.

멀티 스텝 에이전트 — 같은 도구 정의를 가지고 여러 번 LLM을 호출하는 에이전트. 1번 캐시되면 이후 모든 스텝에서 이득이다.

도구 정의 10개 = 약 3,000 토큰 (매 요청 반복)
 
Step 1: 도구 정의 처리 (Cache Miss)
Step 2: 도구 정의 캐시 히트 ← 절약
Step 3: 도구 정의 캐시 히트 ← 절약
Step 4: 도구 정의 캐시 히트 ← 절약

대용량 문서 처리 — 같은 문서를 여러 각도로 분석할 때. 처음 한 번만 문서를 처리하고 이후 질문은 빠르게 응답한다.

코드 생성 도구 — 코드베이스 컨텍스트나 코딩 규칙이 고정된 경우. 규칙을 매번 재처리할 필요가 없다.

실제 설정

프롬프트 캐싱은 기본적으로 자동 활성화되는 경우가 많다. Heroku의 Managed AI 서비스는 2025년 12월 18일부터 자동 적용했다.

특정 이유로 캐싱을 끄고 싶다면 요청 헤더를 사용한다.

import anthropic
 
client = anthropic.Anthropic()
 
# 기본 사용 — 캐싱 자동 활성화 (임계값 충족 시)
response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "당신은 코드 리뷰 전문 AI다. 다음 규칙을 따른다:\n" +
                    "1. 변수명은 의미를 명확히 표현해야 한다\n" +
                    "2. 함수는 단일 책임 원칙을 지켜야 한다\n" +
                    "3. 에러 처리는 구체적인 메시지로 해야 한다\n" +
                    "... (1024 토큰 이상의 규칙들)",
            "cache_control": {"type": "ephemeral"}  # 캐싱 마킹
        }
    ],
    messages=[
        {"role": "user", "content": "이 코드를 리뷰해줘: def f(x): return x*2"}
    ]
)
 
# 캐싱 비활성화 — 민감한 워크플로우에서
import httpx
response_no_cache = httpx.post(
    "https://api.heroku.com/ai/...",
    headers={"X-Heroku-Prompt-Caching": "false"},
    json={...}
)

Anthropic SDK를 직접 쓴다면 cache_control을 메시지에 명시한다. 플랫폼(Heroku, AWS Bedrock 등)이 자동 관리하는 경우라면 별도 설정 없이 임계값만 충족하면 된다.

캐싱이 적용되지 않는 경우

몇 가지 주의할 점이 있다.

사용자 메시지와 대화 이력은 캐시하지 않는다. 보안 정책상 개인화된 정보를 캐시하면 안 되기 때문이다. 캐싱은 정적인 시스템 프롬프트와 도구 정의에만 적용된다.

Amazon Nova 모델은 도구 캐싱이 미지원이다. 시스템 프롬프트는 캐싱되지만 Tool 정의는 캐싱되지 않는다.

프롬프트가 임계값 미만이면 캐시되지 않는다. 짧은 시스템 프롬프트는 캐싱 의미가 없어서 임계값을 둔다.

캐싱 효율 높이는 설계 원칙

정적 내용을 앞으로 — 시스템 프롬프트에서 변하지 않는 내용을 앞에, 동적 내용을 뒤에 배치한다. 캐시 키가 프롬프트 앞부분을 기준으로 매칭되기 때문이다.

❌ 나쁜 순서
[동적: 오늘 날짜, 사용자 이름]
[정적: 역할 정의, 도구 설명, 규칙]
 
✅ 좋은 순서
[정적: 역할 정의, 도구 설명, 규칙]  ← 여기까지 캐싱
[동적: 오늘 날짜, 사용자 이름]

도구 정의 분리 — 자주 쓰는 도구와 가끔 쓰는 도구를 분리해서 관리하면 캐싱 효율이 올라간다.

마무리

프롬프트 캐싱은 코드를 거의 바꾸지 않고 얻는 성능 개선이다. 특히 에이전트처럼 같은 프롬프트로 반복 요청이 들어오는 패턴에 효과가 크다.

• 시스템 프롬프트 + 도구 정의가 1,024 토큰 이상이다 → 캐싱 효과 기대
• 5분 내 반복 요청이 많다 → TTL 구간에 캐시 히트 발생
• 민감한 워크플로우다 → 헤더로 명시적 비활성화 가능

추가 비용 없이 얻을 수 있는 최적화라면 안 쓸 이유가 없다.

참고:

• Heroku AI 블로그: https://www.heroku.com/blog/faster-agents-automatic-prompt-caching/
• Anthropic 공식 문서: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching