에이전트는 한 번의 질문을 수십 번의 API 호출로 바꿉니다. 그 호출마다 같은 시스템 프롬프트를 다시 보내고, 요금은 매번 다시 붙습니다. 프롬프트 캐싱이 이 반복분을 줄여 주는데, 많이 넣을수록 이득이 커지지는 않았습니다. 논문이 모델 4종 × 전략 3가지, 총 12개 조건을 측정한 결과 가장 좁게 잡은 전략이 비용에서 4개 중 3개, 첫 토큰 시간에서 다시 4개 중 3개로 최고였습니다(두 축의 3개가 같은 모델은 아닙니다). 프롬프트 캐싱은 켜고 끄는 기능이 아니라, 무엇을 캐시에 넣고 뺄지 정하는 일입니다.
토큰은 모델이 글을 처리하고 요금을 매기는 기본 단위입니다. 그런데 토큰당 단가만 비교해서는 에이전트 비용을 설명할 수 없습니다. 에이전트 비용은 같은 내용을 몇 번 다시 보내느냐에 따라 달라지고, 이 반복 전송을 줄이는 기능이 프롬프트 캐싱입니다. 앞부분이 똑같은 요청이 이어지면 그 공통 부분을 다시 계산하지 않고 재사용합니다.
일반 챗봇은 질문 하나가 호출 하나입니다. 에이전트는 다릅니다. 도구를 부르고, 결과를 읽고, 다시 판단하고, 또 부릅니다. 이 반복 하나하나가 별도의 API 호출이고 각각 요금이 붙습니다.
비용은 호출 횟수 × 호출당 다시 보내는 토큰입니다. 호출 횟수만 세면 뒤쪽 항을 놓칩니다 — 호출할 때마다 그때까지의 맥락을 통째로 다시 보내기 때문입니다. 시스템 프롬프트와 도구 정의, 지금까지의 대화가 호출할 때마다 입력 토큰으로 다시 집계됩니다. 논문 저자들은 실험에서 길이 1만 토큰짜리 시스템 프롬프트를 쓰고, 도구 호출 횟수를 3회부터 50회까지 달리했습니다. 50회면 같은 1만 토큰을 50번 다시 보내는 셈입니다.
Lumer 등(arXiv:2601.06007)은 제공자 3곳(OpenAI·Anthropic·Google)에서 캐싱 전략 세 가지를 비교했습니다. 웹 검색 도구를 실제로 호출하며 요청과 응답을 여러 차례 주고받는 벤치마크(DeepResearch Bench)에서 에이전트 세션을 500회 이상 실행하고, API 비용과 첫 토큰까지 걸린 시간을 함께 측정했습니다.
비교한 세 전략은 이렇습니다.
| 전략 | 캐시에 넣는 것 | 성격 |
|---|---|---|
| 전체 맥락 | 시스템 프롬프트 + 대화 + 도구 결과 전부 | 가장 단순. 요청마다 달라지는 것까지 들어감 |
| 시스템 프롬프트만 | 지시문과 도구 정의 | 바뀌지 않는 부분만 |
| 도구 결과 제외 | 시스템 프롬프트 + 대화, 도구 실행 결과는 뺌 | 세션마다 달라지는 값만 제외 |
논문은 초록에서 비용 41~80% 절감, 첫 토큰까지 걸린 시간 13~31% 단축이라고 요약합니다. 다만 모델별 표를 열어 보면 범위가 더 넓고, 어느 전략이 좋았는지도 모델마다 갈립니다. 12개 조건을 그대로 옮깁니다.
| 모델 | 전략 | 비용 절감 | 첫 토큰 시간 변화 |
|---|---|---|---|
| GPT-5.2 | 전체 맥락 | 79.3% | −9.5% |
| 시스템 프롬프트만 | 81.4% | −10.5% | |
| 도구 결과 제외 | 79.6% | −13.0% | |
| Claude Sonnet 4.5 | 전체 맥락 | 77.8% | −21.8% |
| 시스템 프롬프트만 | 78.5% | −22.9% | |
| 도구 결과 제외 | 78.1% | −20.9% | |
| Gemini 2.5 Pro | 전체 맥락 | 38.3% | −6.0% |
| 시스템 프롬프트만 | 41.4% | −6.1% | |
| 도구 결과 제외 | 27.8% | +2.9% | |
| GPT-4o | 전체 맥락 | 47.8% | +8.8% |
| 시스템 프롬프트만 | 45.9% | −30.9% | |
| 도구 결과 제외 | 46.8% | −28.1% |
출처 · arXiv:2601.06007 원문 표 확인. 첫 토큰 시간은 음수가 단축, 양수가 지연 증가입니다. 굵게 표시한 것이 각 모델에서 그 항목의 최고값입니다.
비용은 12개 조건 전부에서 줄었습니다. 그러나 첫 토큰까지 걸린 시간은 두 조건에서 오히려 늘었습니다. GPT-4o에서 전체 맥락을 캐시했을 때 8.8%, Gemini 2.5 Pro에서 도구 결과를 제외했을 때 2.9%입니다. 논문은 “요청마다 바뀌는 내용을 캐시하면 추가 처리 부담 때문에 응답 시간 단축 효과가 상쇄될 수 있다”고 설명합니다.
논문이 제시한 세 가지 규칙은 모두 요청할 때마다 바뀌는 내용을 캐시 구간에서 빼라는 하나의 원칙으로 모입니다. 다만 세 번째는 위 표에서 보듯 모델을 탑니다.
시스템 프롬프트 안에서 자주 바뀌는 부분을 끝쪽으로 보냅니다. 캐시는 요청의 앞부분이 직전 요청과 일치하는 데까지만 재사용되므로, 바뀌는 내용이 앞에 있으면 그 뒤도 함께 재사용할 수 없게 됩니다.
적용: 4개 모델 공통.
도구 정의를 요청할 때마다 다시 만들면 기존 캐시를 쓸 수 없습니다. 논문은 “요청 사이에 도구 정의가 바뀌면 캐시가 무효가 될 수 있다”고 설명합니다. 정의는 고정하고, 호출할 때 넘기는 값만 바꾸세요.
적용: 4개 모델 공통.
검색 결과나 API 응답은 세션마다 다릅니다. 논문은 이 둘을 캐시에서 빼는 전략을 따로 두었지만 결과가 갈렸습니다. GPT-5.2에서는 첫 토큰 시간이 가장 좋았고(−13.0%), Gemini 2.5 Pro에서는 비용이 셋 중 최악(27.8%)이고 지연도 늘었습니다(+2.9%).
적용: 쓰는 모델에서 직접 측정한 뒤 결정.
같은 “프롬프트 캐싱”이라도 켜는 방법, 최소 길이, 유지 시간이 다릅니다. 아래는 각 제공자 공식 문서에서 직접 확인한 값입니다.
| 항목 | Anthropic | OpenAI | Google Gemini |
|---|---|---|---|
| 켜는 방식 | 수동 — cache_control 지정 |
기본 활성. GPT-5.6 이상은 prompt_cache_options로 제어 |
암묵적 캐싱이 기본 활성 |
| 최소 길이 | 모델별 512 · 1,024 · 2,048 · 4,096 토큰 | 1,024 토큰(GPT-5.6 이상) / 2,048 토큰(이전) | 2,048 토큰(2.5 Flash·Pro) / 4,096 토큰(3.x Flash·3.1 Pro Preview) |
| 캐시 읽기 단가 | 기본 입력 토큰 단가의 0.1배 | 0.1배(GPT-5.6 이상). 이전 모델은 모델별 | 비율 명시 없음 — 재사용 시 절감분을 자동 반영한다고만 설명 |
| 캐시 쓰기 추가 비용 | 1.25배(5분) / 2배(1시간) | 1.25배(GPT-5.6 이상) / 추가 요금 없음(이전 모델) | 문서에 별도 쓰기 요금 명시 없음 |
| 유지 시간 | 기본 5분, 옵션 1시간 | 마지막 사용 후 30분(GPT-5.6 이상) | 문서에 명시 없음 |
| 구간 지정 | 요청당 캐시 분기점 최대 4개 | prompt_cache_breakpoint로 선택 지정 |
암묵적 캐싱은 지정 불가 |
출처 · 각 제공자 공식 문서(2026-09-08 확인). “명시 없음”은 해당 공식 문서에서 값을 확인하지 못했다는 뜻이며, 그런 요금이나 조건이 없다는 뜻은 아닙니다.
프롬프트 캐싱은 즉시 응답해야 하는 요청에서 반복 계산을 줄입니다. 즉시 결과가 필요 없는 작업은 아예 다른 경로로 보내는 편이 낫습니다.
Anthropic의 Message Batches API는 모든 사용량을 표준 가격의 50%로 계산합니다. 대신 요청을 보내고 기다리지 않다가 나중에 결과를 받는 비동기 방식입니다. 대부분 1시간 안에 끝나지만 최대 24시간이 걸릴 수 있고, 24시간 안에 끝나지 않은 요청은 만료됩니다. 결과는 29일간 조회할 수 있습니다.
맞는 일: 대량 분류, 재색인, 정기 평가 실행처럼 사람이 기다리지 않는 작업.
쉬운 단계는 작은 모델로 보내는 방식입니다. 다만 앞 절에서 적었듯 세션 도중 모델을 바꾸면 캐시를 다시 쓸 수 없습니다. 한 세션에서 여러 모델을 섞기보다 작업 종류별로 세션을 나누는 편이 캐시를 지키는 데 유리합니다.
확인할 것: 모델 라우팅으로 아낀 금액과 캐시를 다시 못 써서 더 낸 금액을 같은 표에서 비교하세요. 따로 보면 모델 라우팅의 절감 효과가 실제보다 커 보입니다.
| # | 할 일 | 확인 방법 |
|---|---|---|
| 1 | 한 작업이 실제로 몇 번의 API 호출이 되는지 센다 | 요청 로그의 세션당 호출 수. 예상보다 크면 그것이 비용의 정체입니다 |
| 2 | 시스템 프롬프트에서 매번 바뀌는 조각을 찾는다 | 타임스탬프, 세션 ID, 사용자 이름, 현재 단계 번호가 앞쪽에 있는지 |
| 3 | 그 조각들을 시스템 프롬프트 끝으로 옮긴다 | 옮긴 뒤 응답의 캐시 적중 토큰 수가 늘었는지 |
| 4 | 도구 정의를 고정한다 | 요청 두 개의 도구 스키마를 그대로 비교해 한 글자도 다르지 않은지 |
| 5 | 도구 실행 결과를 뺀 경우와 넣은 경우를 재 본다 | 모델마다 결과가 갈렸습니다. 두 조건으로 같은 작업을 돌려 비용과 첫 토큰 시간을 비교 |
| 6 | 최소 길이를 넘는지 확인한다 | 시스템 프롬프트의 토큰 수가 모델이 요구하는 최소치(512~4,096개)보다 적으면 프롬프트 캐싱이 아예 적용되지 않습니다 |
| 7 | 재사용 횟수를 세고 유지 시간을 고른다 | 5분 캐시는 1회 재사용부터 이득(1.35 대 2). 1시간 유지는 2회부터 이득(2.2 대 3) |
| 8 | 사람이 기다리지 않는 작업을 배치로 뺀다 | 24시간 지연을 감당할 수 있는 작업 목록 |
| 자료 | 이 글에서 쓴 내용 | 링크 |
|---|---|---|
| Lumer 외, Don’t Break the Cache (arXiv:2601.06007) | 12개 조건의 비용·첫 토큰 값 전체, 초록의 요약 범위, 세 가지 규칙. 원문 표 확인 | arxiv.org/abs/2601.06007 |
| Anthropic — Prompt caching | 쓰기 1.25배·2배, 읽기 0.1배, 유지 5분·1시간, 최소 512~4,096 토큰, 분기점 4개 | platform.claude.com/docs/.../prompt-caching |
| Anthropic — Batch processing | 표준 가격의 50%, 최대 24시간, 결과 29일 보관 | platform.claude.com/docs/.../batch-processing |
| OpenAI — Prompt caching | 기본 활성, 최소 1,024·2,048 토큰, 읽기 0.1배, 쓰기 1.25배(GPT-5.6 이상), 마지막 사용 후 30분 | developers.openai.com/api/docs/guides/prompt-caching |
| Google — Context caching | 암묵적 캐싱 기본 활성, 최소 2,048·4,096 토큰. 절감 비율은 명시 없음 | ai.google.dev/gemini-api/docs/caching |
이 글의 수치는 위 다섯 자료에서 직접 확인했습니다. 2차 집계 블로그의 숫자는 원 출처를 찾지 못해 쓰지 않았습니다. 가격과 캐시 동작은 자주 바뀌므로 도입 전에 공식 문서를 다시 확인하세요.