AI Agent를 사용하다 보면 같은 프로젝트에서 비슷한 작업을 하는데도 응답 속도와 입력 비용이 달라지는 경우가 있다. 입력 길이나 모델의 차이도 있겠지만, 그중 하나가 프롬프트 캐시(Prompt Caching)다.
Agent는 도구를 호출하고 결과를 읽는 과정에서 같은 지침과 대화 이력을 반복해서 모델에 전달한다. 프롬프트 캐시는 이처럼 반복되는 입력의 계산을 재사용해 처리 시간과 비용을 줄이는 기능이다. 효과적으로 활용하려면 재사용 조건과 입력 구조, 캐시 쓰기·읽기 비용을 함께 이해해야 한다.
제공사별 API 정책은 **2026년 10월 01일 확인한 공식 문서 기준**이다.
최소 토큰 수, 보관 시간, 요금은 모델과 API에 따라 다르므로 실제 적용 시 해당 모델의 문서를 확인해야 한다. 본문의 수치 계산은 별도로 표시한 가상 예제다.
1. 프롬프트 캐시는 무엇을 저장할까?
일반적인 애플리케이션 캐시라면 요청 → 완성된 결과를 저장하는 모습을 먼저 떠올리기 쉽다. 예를 들어 Redis에 상품 조회 응답을 저장해두었다가 같은 요청이 오면 반환하는 방식이다.
프롬프트 캐시가 재사용하는 대상은 입력의 공통 앞부분을 모델이 처리하면서 만든 중간 상태다. 대표적으로 Transformer의 Attention 연산에 사용하는 Key·Value 상태, 즉 KV Cache가 여기에 해당한다. 따라서 캐시가 적중해도 새로운 질문에 대한 출력은 다시 생성한다. OpenAI 공식 문서
Prefill과 Decode
일반적인 자기회귀 LLM의 추론 과정을 나누면 다음과 같이 볼 수 있다.
| 단계 | 하는 일 | 프롬프트 캐시와의 관계 |
|---|---|---|
| Prefill | 입력 토큰들을 처리하고 이후 생성에 사용할 상태를 준비한다 | 일치하는 입력 구간의 계산을 재사용할 수 있다 |
| Decode | 앞선 문맥을 참조하며 출력 토큰을 순차적으로 생성한다 | 새로운 출력 토큰 생성은 계속 필요하다 |
vLLM도 Automatic Prefix Caching이 줄이는 대상은 Prefill이며, Decode 자체의 시간을 줄이는 기능은 아니라고 설명한다. 긴 자료를 읽고 짧게 답하는 요청과 긴 답변을 생성하는 요청에서 체감 효과가 다른 이유다. vLLM 공식 문서
여기서 구분할 점이 하나 더 있다. 한 번의 생성 과정에서 이전 토큰의 KV 상태를 쓰는 것과 서로 다른 요청 사이에서 같은 prefix의 KV 상태를 재사용하는 것은 범위가 다르다. 이 글에서 다루는 프롬프트 캐시는 후자에 초점을 맞춘다.
2. 같은 문장이 포함되어 있어도 캐시가 적중하지 않는 이유
Prefix는 입력의 앞부분을 의미한다. 다음은 실제 API의 내부 직렬화 순서가 아닌, 공통 구간을 설명하기 위한 예제다.
요청 A: [고정 지침][프로젝트 문서 v1][질문 A]
요청 B: [고정 지침][프로젝트 문서 v1][질문 B]
└──── 재사용 가능한 공통 prefix ────┘
요청 C: [매번 달라지는 시각][고정 지침][프로젝트 문서 v1][질문 C]
└─ 앞에서 달라지면 뒤의 동일한 문서도 공통 prefix가 되지 않는다
핵심은 뜻이 비슷한가가 아니라 모델에 전달된 앞부분이 일치하는가다. 문서가 같더라도 그 앞에 요청마다 달라지는 내용을 넣으면 재사용할 수 있는 구간이 짧아진다. 실제 적중에는 최소 길이, 캐시 경계, 보관 상태 등의 조건도 필요하다. OpenAI 공식 문서
이 원리는 일반적인 causal Attention 모델에서 뒤쪽 토큰의 상태가 앞선 문맥의 영향을 받는다는 점과 연결된다. 앞의 지침이 바뀌면 그 뒤에 나오는 같은 문장도 다른 문맥에서 처리된다. 따라서 문서 중간에 같은 문단이 있다는 이유만으로 해당 부분을 독립적으로 재사용할 수 있다고 가정하면 안 된다.
또한 중간 구간을 수정했다고 기존 캐시 전체가 삭제되는 것은 아니다. 변경 전까지의 prefix는 조건에 따라 여전히 재사용할 수 있다. 어떤 길이까지 적중하는지는 제공사의 캐시 경계 규칙에 달려 있다.
다른 캐시와 비교하기
| 구분 | 재사용하는 대상 | 재사용 판단 기준 | 적중 후 LLM 생성 |
|---|---|---|---|
| 프롬프트 캐시 | 입력 prefix의 계산 상태 | 동일한 prefix와 제공사 조건 | 필요 |
| 응답 캐시 | 완성된 답변 | 애플리케이션이 정한 요청 키 | 생략 가능 |
| 시맨틱 캐시 | 의미가 비슷한 질문에 저장해둔 답변 | 임베딩 유사도와 필터 조건 등 | 생략 가능 |
시맨틱 캐시는 질문의 표현이 달라도 기존 답변을 재사용할 수 있다. 그만큼 서로 비슷해 보이는 질문에 같은 답을 줘도 되는지 판단해야 한다. Redis도 이 방식을 의미가 유사한 질의에 대한 LLM 응답 재사용으로 설명한다. Redis 공식 문서
예를 들어 “내 주문의 배송 상태”는 문장이 같아도 사용자와 주문이 다르면 답이 다르다. 응답 캐시를 설계한다면 사용자 권한과 데이터 버전을 키나 필터에 반영해야 한다. 프롬프트 캐시를 사용한다고 이러한 애플리케이션 설계가 대신 해결되는 것은 아니다.
3. AI Agent에서는 왜 더 중요할까?
Agent는 질문에 한 번 답하고 끝나는 대신, 도구를 호출하고 그 결과를 읽으며 다음 행동을 결정한다. 이 과정에서 이전 문맥이 다음 요청에도 반복해서 들어갈 수 있다.
코드를 수정하는 Agent를 가정해보자. 다음 구조는 대화 이력을 누적하는 Agent의 논리적 예제다.
1차: [지침·도구·프로젝트 규칙][사용자 요청]
2차: [지침·도구·프로젝트 규칙][사용자 요청][파일 조회 호출·결과]
3차: [지침·도구·프로젝트 규칙][사용자 요청][파일 조회 호출·결과][수정 호출·결과]
4차: [지침·도구·프로젝트 규칙][사용자 요청][파일 조회 호출·결과][수정 호출·결과][테스트 결과]
이전 입력을 유지하고 뒤에 새 내용을 추가하는 구조라면, 앞서 처리한 내용이 다음 요청의 공통 prefix가 된다. Agent 루프가 길수록 반복 입력이 차지하는 비중도 커질 수 있다.
직접 Agent를 구현한다면 입력을 다음 세 가지 수명으로 나눠보는 것이 도움이 된다. 이는 앞의 원리를 적용한 설계 예시다.
| 수명 | 예시 | 관리 방법 |
|---|---|---|
| 애플리케이션 단위 | 역할, 출력 형식, 공통 도구 스키마 | 버전을 관리하고 요청마다 불필요하게 변경하지 않는다 |
| 작업 단위 | 프로젝트 규칙, 현재 작업에 필요한 기준 문서 | 작업 중 필요한 동안 안정적으로 유지한다 |
| 요청 단위 | 현재 시각, 최신 검색 결과, 새 질문 | 변경 주기에 맞춰 갱신한다 |
단, 이 표를 하나의 시스템 메시지에 모두 붙이라는 뜻으로 이해하면 안 된다. 지침과 외부 자료의 역할 구분은 유지하면서, 같은 역할 안에서 안정적인 내용을 먼저 배치할 수 있는지 검토해야 한다. 검색 문서나 도구 결과를 시스템 지침으로 승격하면 의도하지 않은 지시까지 신뢰하게 될 수 있다.
캐시를 깨뜨리는 입력 생성 로직
코드가 같아도 실제로 만들어진 요청은 달라질 수 있다. 다음은 점검해볼 만한 사례다.
- 공통 지침 문자열의 첫 줄에 현재 시각이나 임의의 요청 ID를 삽입한다.
- 도구 목록을 순서가 일정하지 않은 자료구조에서 꺼내 요청에 넣는다.
- 같은 문서에 요청마다 다른 공백, 메타데이터, 검색 순위를 붙인다.
- 새 결과를 추가할 때 과거 메시지까지 다시 작성한다.
운영 로그에 prompt_version, toolset_version, document_version을 함께 남겨두면, 적중률 하락이 어떤 입력 변경과 연결되는지 추적하기 쉬워진다. 민감한 원문을 모두 기록하기보다 버전과 안전하게 관리한 식별자를 활용하는 편이 좋겠다.
4. 제공사마다 설정 방법은 다르다
“프롬프트 캐시는 자동 적용된다”는 설명은 사용하는 API와 모델을 함께 확인해야 한다.
| 제공사 | 공식 문서에서 확인한 방식 | 적용 전 확인할 부분 |
|---|---|---|
| OpenAI | 지원 모델에서 기본 활성화. 모델 세대에 따라 명시적 경계 지정도 지원 | 모델별 최소 길이, 쓰기 요금, 보관 설정 |
| Anthropic | 요청 최상위 또는 개별 콘텐츠 블록에 cache_control 설정 |
최소 길이, 경계 위치, 5분·1시간 TTL |
| Google Gemini | Gemini 2.5 이상에서 암묵적 캐싱을 기본 지원 | 모델별 최소 길이와 사용하는 API의 명시적 캐시 지원 여부 |
근거: OpenAI Prompt caching, Anthropic Prompt caching, Gemini Context caching.
특히 Gemini의 현재 문서는 Interactions API와 Gemini 4 Argon 이후 모델에서 명시적 캐시 객체를 지원하지 않는다고 안내한다. 이전 모델의 generateContent 예제를 모든 모델에 그대로 적용할 수는 없다. Gemini 공식 문서
캐시 경계는 개별 문서의 저장 키가 아니다
Anthropic의 명시적 경계 지정은 다음과 같은 형태다. 아래는 전체 API 호출이 아닌, 요청 본문의 system 필드 예시다.
{
"system": [
{
"type": "text",
"text": "작업 전반에서 유지할 공통 지침과 충분한 길이의 예시...",
"cache_control": {
"type": "ephemeral"
}
}
]
}
이 표시까지의 전체 prefix가 캐시 대상이며, 표시한 블록만 떼어서 저장하는 방식이 아니다. Anthropic은 tools → system → messages 순서로 prefix를 구성한다고 설명한다. 예시처럼 짧은 문자열만 보내면 최소 길이에 미달할 수 있다. Anthropic 공식 문서
5. 캐시가 적중하면 비용은 얼마나 줄어들까?
전체 비용은 다음처럼 분리해서 보는 것이 이해하기 쉽다. 아래 식은 토큰별 과금 모델을 단순화한 계산식이다.
요청 비용 = 일반 입력 비용
+ 캐시 쓰기 비용
+ 캐시 읽기 비용
+ 출력 비용
+ 별도 도구·저장 등의 비용
캐시 쓰기에는 처음 계산하고 저장하는 비용이, 읽기에는 재사용하는 비용이 붙을 수 있다. 출력과 외부 도구 비용은 별도로 남는다. 캐시 쓰기 단가는 같은 토큰의 일반 입력 단가에 더하는 할증액인지, 이를 대체하는 단가인지도 구분해야 한다. 여기서는 일반·쓰기·읽기를 서로 겹치지 않는 입력 구간으로 계산한다.
반복되는 prefix만 비교한 가상 예제
특정 서비스의 현재 요금표가 아닌 다음 조건을 가정하겠다.
- 공통 prefix: 10,000토큰
- 일반 입력 단가: 100만 토큰당 1달러
- 캐시 쓰기 단가: 일반 입력의 1.25배
- 캐시 읽기 단가: 일반 입력의 0.1배
- 총 10회 요청 중 첫 번째는 쓰기, 이후 9회는 같은 구간 전체를 읽기
캐시 없음 = 10,000 × 10 / 1,000,000 × $1
= $0.1
캐시 사용 = 10,000 / 1,000,000 × $1.25
+ 10,000 × 9 / 1,000,000 × $0.1
= $0.0215
반복 prefix의 처리 비용은 78.5% 감소한다. 그러나 매번 붙는 새 입력과 출력은 제외한 값이다. 이를 서비스 전체 비용이 78.5% 줄어든다고 해석하면 안 된다.
몇 번 재사용해야 이득일까?
동일한 prefix를 총 N회 사용하고, 쓰기 배수를 w, 읽기 배수를 r이라고 하자. 첫 요청에서 한 번 쓰고 나머지가 모두 적중한다면, 일반 입력 1회 비용을 기준으로 다음 조건에서 절약된다.
캐시 없음: N
캐시 사용: w + (N - 1) × r
w + (N - 1) × r < N
N > (w - r) / (1 - r) (r < 1)
w = 1.25, r = 0.1이면 총 2회부터, w = 2, r = 0.1이면 총 3회부터 이득이다. 만료나 입력 변경으로 다시 쓰는 상황이 생기면 계산도 달라진다. 요청 간격과 재사용 횟수를 함께 봐야 하는 이유다.
반대로 한 번만 사용할 긴 자료에 쓰기 비용이 추가되는 정책이라면 손해가 날 수 있다. 캐시 적용 여부를 결정할 수 있는 API에서는 재사용할 부분과 일회성 부분을 나누는 것이 비용 설계의 출발점이다.
6. RAG와 대화 요약은 어떻게 함께 사용할까?
RAG는 넣을 정보를 고르고, 캐시는 반복 계산을 줄인다
RAG는 질문과 관련된 자료를 찾아 입력에 넣는 방식이다. 프롬프트 캐시와 함께 사용한다면 다음처럼 구성할 수 있다.
[고정 지침·공통 예시][작업 동안 유지되는 자료][이번 검색 결과][이번 질문]
└────────── 안정적인 구간 ──────────┘ └──── 변경되는 구간 ────┘
질문마다 검색 결과가 달라도 그 앞의 지침과 공통 자료는 재사용 후보가 된다. 다만 문서 전체를 앞에 넣어 캐시를 노릴지, 검색으로 필요한 부분만 넣을지는 별도 선택이다. 검색 비용, 입력량, 재사용 빈도와 답변 품질을 비교해야 한다.
캐시를 유지하려고 오래된 검색 결과를 계속 보내서는 안 된다. 예를 들어 환불 정책 문서가 개정됐다면 새 문서를 읽고 반영해야 한다. 이때 생기는 재계산은 올바른 최신 정보를 전달하기 위한 비용이다.
Compaction은 당장의 적중률을 낮춰도 유리할 수 있다
긴 Agent 세션에서는 과거 대화를 요약해 컨텍스트를 줄이는 Compaction을 사용하기도 한다. Anthropic은 중요한 결정과 미해결 사항을 보존하면서 불필요한 내용을 줄이는 방법으로 설명한다. Anthropic의 Context Engineering 글
기존 메시지를 요약으로 교체하면 prefix가 달라져 해당 지점 이후의 재사용이 줄 수 있다. 그래도 앞으로 반복해서 읽을 토큰 자체가 줄어든다면 장기 비용은 내려갈 수 있다.
가령 아래와 같은 상황을 가정해보자. 두 선택에서 공통으로 발생하는 새 입력과 출력은 제외한다.
기존 이력 유지:
80,000토큰을 읽기 단가로 20회 사용
80,000 × 0.1 × 20 = 160,000
10,000토큰으로 요약 후 유지:
새 prefix 1회 쓰기 + 19회 읽기
10,000 × 1.25 + 10,000 × 0.1 × 19 = 31,500
단위는 일반 입력 토큰 단가로 환산한 값이다. 실제 선택에는 요약을 만드는 비용과 요약 과정의 정보 손실도 포함해야 한다. 그럼에도 이 예제는 적중률이 높은 긴 입력을 계속 유지하는 것이 항상 저렴하지는 않다는 점을 보여준다.
7. 적용 결과는 어떻게 확인할까?
응답이 빨라졌다는 느낌만으로 적중을 판단하기는 어렵다. 서버 대기와 출력 길이도 달라질 수 있기 때문이다.
대표적인 사용량 필드는 다음과 같다. 서로 다른 API의 필드를 같은 방식으로 합산하지 않도록 주의한다.
| API | 확인할 필드 |
|---|---|
| OpenAI Responses | usage.input_tokens_details.cached_tokens, 지원 모델의 cache_write_tokens |
| Anthropic Messages | usage.cache_read_input_tokens, usage.cache_creation_input_tokens |
| Gemini Interactions | usage.total_cached_tokens |
필드 근거: OpenAI, Anthropic, Gemini. Gemini 등 다른 엔드포인트를 사용한다면 해당 응답 스키마를 확인해야 한다.
Anthropic의 input_tokens는 캐시 쓰기·읽기 토큰을 제외한 값이므로, 전체 입력량은 세 필드를 합쳐 구한다. OpenAI Responses의 input_tokens는 전체 입력량이며 세부 필드가 그 안의 캐시 사용량을 나타낸다. 이 차이를 무시하면 적중률을 잘못 계산할 수 있다.
요청 수보다 토큰 비중도 함께 보기
요청 적중률 = 캐시 읽기가 발생한 요청 수 / 전체 요청 수
토큰 적중률 = 전체 캐시 읽기 토큰 수 / 전체 입력 토큰 수
100개 요청 모두에서 1,000토큰이 적중해도 각 요청이 20,000토큰이라면 토큰 적중률은 5%다. 요청 적중률만 보면 효과를 과대평가할 수 있다.
직접 검증한다면 다음 순서로 비교해볼 수 있다.
- 같은 모델과 설정으로 충분히 긴 공통 prefix를 준비한다.
- 첫 요청의 쓰기·읽기 토큰과 시간을 기록한다.
- 앞부분을 유지하고 마지막 질문만 바꿔 다시 요청한다.
- 공통 prefix의 초반을 수정한 요청과, 보관 시간이 지난 요청도 비교한다.
- 여러 차례 반복해 토큰 사용량, 첫 토큰까지의 시간(TTFT), 총 비용과 답변 품질을 비교한다.
첫 요청을 cold 상태, 재사용 가능한 상태의 요청을 warm 상태로 나눠 관찰하면 이해하기 쉽다. 실제 서비스에서는 요청 간격과 동시 요청 수도 함께 기록해야 한다. 한 번의 적중 결과만으로 운영 환경의 절감률을 예측하기는 어렵다.
캐시에 들어간 입력도 모델이 참고하는 컨텍스트이며, 컨텍스트 한도를 피하는 수단은 아니다. 또한 API 비용의 절감률을 구독형 Agent 도구의 사용 한도에 그대로 대입해서는 안 된다. 제품별 과금과 사용량 정책은 별도로 확인해야 한다.
프롬프트 캐시를 고려한 컨텍스트 관리
Agent의 입력을 설계할 때는 정보의 필요성과 함께 변경 주기와 재사용 빈도를 고려해야 한다. 공통 지침과 자료는 안정적으로 관리하고, 새로운 정보는 필요한 시점에 갱신하며, 불필요해진 이력은 줄인다.
캐시 적중률은 이러한 설계의 효과를 확인하는 지표 중 하나다. 실제 Agent의 효율은 작업을 정확히 완료하는 데 든 전체 토큰과 비용, 응답 시간과 답변 품질을 함께 측정해 평가해야 한다.
