에이전트 캐싱은 계수를 바꾸고 지수는 못 바꾼다

짧은 에이전트의 비용은 무엇을 캐싱하는지가 정한다. 같은 모델, 같은 토큰인데 캐싱 구성만 바꿔서 20턴 세션이 $4.05에서 $0.97이 된다.

긴 에이전트에서는 서문만 녹음해 두는 것이 무력해진다. 프리픽스에만 브레이크포인트를 거는 흔한 구성은 에이전트가 길어질수록 절감률이 떨어지고, 히스토리까지 캐싱하면 반대로 오른다.

그런데 히스토리까지 캐싱해도 절감률 상한은 90%다. 배속으로 넘겨도 요금이 0은 아니기 때문이다. 그리고 비용은 여전히 턴 수의 제곱으로 자란다. 200턴 세션은 완벽하게 캐싱해도 $36이다. 캐싱은 계수를 바꾸고 지수는 못 바꾼다. 긴 에이전트의 지배 레버는 히스토리를 캐싱하는 것이 아니라 줄이는 것이다.

전제 세 개

Claude Opus 5 기준이다.

항목	값	근거
안정 프리픽스 S	10,000 토큰	browser toolset 6,610 + bash 325 (문서) + 시스템 프롬프트 3,065 (가정)
턴당 증가분 δ	3,000 토큰	출력 400 + 툴 결과 2,600 (둘 다 가정)
턴 수 N	20	가정

안정 프리픽스의 6,935는 문서에 있는 값이다. browser_toolset_20260801 기본 멤버가 6,610 토큰, bash 툴이 325 토큰이고, 이 토큰은 대화당 한 번이 아니라 매 요청마다 다시 전송된다. 나머지 3,065와 δ, N은 가정이다.

가정이 하나 더 있다. 아래의 모든 절감률은 캐시 적중률 100%를 전제한다. 프리픽스가 한 번도 깨지지 않고 TTL 안에 항상 살아 있는 경우다. 실서비스에서 프리픽스가 얼마나 자주 깨지는지에 대한 공개 통계를 찾지 못했고, 뒤에서 다루듯 깨지는 경로는 여러 개다. 이 글의 절감률은 도달 가능한 상한이다.

캐시 단가는 이미 공개돼 있다

두 제공자 모두 공식 요금 문서에 캐시 단가를 명시한다. 협상 사항이 아니다.

모델	입력	5분 캐시 쓰기 (1.25×)	1시간 캐시 쓰기 (2×)	캐시 읽기 (0.1×)	출력
Claude Opus 5	$5	$6.25	$10	$0.50	$25
Claude Sonnet 5	$2	$2.50	$4	$0.20	$10
Claude Haiku 4.5	$1	$1.25	$2	$0.10	$5

단위는 $/1M 토큰이다. (Anthropic 요금 문서, 2026-08-23 조회)

읽기가 정가의 10%라는 비율은 한 제공자의 정책이 아니다. Claude 세 모델과 OpenAI의 gpt-5.6-sol($4.00 → $0.40), gpt-5.4-mini($0.75 → $0.075)가 모두 정확히 10%다. 구형 소형 모델인 gpt-4o-mini만 50%($0.15 → $0.075)인데, 읽기 단가가 gpt-5.4-mini와 같으면서 입력 단가가 5분의 1이기 때문이다. (OpenAI 요금 문서, 2026-08-23 조회)

캐시 손익분기는 문서가 직접 답한다. 5분 캐시는 한 번 읽으면 쓰기 비용을 회수하고, 1시간 캐시는 두 번 읽으면 회수한다. 단 TTL 안에서 재사용하는 경우다. 재사용 간격이 5분을 넘으면 읽기가 아니라 재작성이 되어 회수가 아니라 손해다.

에이전트 입력의 74%는 히스토리다

API는 상태를 갖지 않으므로 매 턴 전체 히스토리를 다시 보낸다. 성우가 매 턴 1쪽부터 다시 읽는 것과 같다. 그래서 입력 토큰이 턴 수에 대해 제곱으로 늘어난다.

구분	계산	토큰	비중
안정 프리픽스 반복	20 × 10,000	200,000	26%
누적 히스토리	3,000 × 190	570,000	74%
총 입력	200,000 + 570,000	770,000	100%
총 출력	20 × 400	8,000	—

입력의 74%가 히스토리다.

프리픽스만 21%, 히스토리까지 76%

구성	캐시 읽기	캐시 쓰기	미캐싱 입력	합계	배수
캐싱 없음	—	—	$3.85	$4.05	1.00×
안정 프리픽스만	$0.10	$0.06	$2.85	$3.21	1.26×
롤링 브레이크포인트	$0.35	$0.42	$0.00	$0.97	4.17×

세 구성 모두 출력 비용 $0.20이 같으므로 표에서 뺐다. 합계에는 포함돼 있다.

세션 합계보다 요청 한 건을 보면 구조가 선명하다. 20번째 요청은 어느 구성에서든 입력이 67,000 토큰인데, 그 67,000이 어떤 단가 구간으로 쪼개지는지가 다르다.

20번째 요청 한 건	캐시 읽기	캐시 쓰기	정가 입력	요청 비용
캐싱 없음	—	—	67,000	$0.3350
안정 프리픽스만	10,000	—	57,000	$0.2900
롤링	64,000	3,000	—	$0.0508

출력 $0.01은 세 구성이 같으므로 뺐다. 프리픽스만 캐싱한 20번째 요청은 캐싱 없음보다 13%만 싸다. 히스토리 57,000 토큰이 정가로 남기 때문이다.

여기서 두 프리픽스를 구분해야 한다. 안정 프리픽스는 매 요청 똑같이 앞에 붙는 부분 (시스템 프롬프트 + 툴 정의)으로 10,000 토큰이다. 누적 프리픽스는 그 시점까지 캐시 대상이 되는 전체 구간(안정 프리픽스 + 그때까지의 히스토리)으로, 20번째 턴이면 67,000 토큰이다.

롤링 브레이크포인트(이하 롤링)는 매 턴 히스토리 끝으로 브레이크포인트를 옮긴다. 그러면 직전까지의 누적 프리픽스를 0.1배로 읽고 새로 늘어난 3,000 토큰만 1.25배로 쓴다. 미캐싱 입력이 0이 된다.

브레이크포인트 개수는 걸림돌이 아니다. 롤링에 필요한 것은 히스토리 꼬리에 1개이고 안정 프리픽스에 하나 더 두어도 2개다. 문서 기준 상한이 요청당 4개이므로 여유가 있고, 직접 옮기기 어렵다면 자동 캐싱 옵션이 대화가 자라는 동안 브레이크포인트를 관리한다. 롤링의 실제 위험은 개수가 아니라 TTL이고, 그것은 아래에서 따로 다룬다.

절감률은 반대로 갈라져 90%에서 멈춘다

턴 수	히스토리 비중	캐싱 없음	프리픽스만	롤링	프리픽스만 절감	롤링 절감
5	37.5%	$0.45	$0.28	$0.22	37%	52%
10	57.4%	$1.28	$0.88	$0.43	31%	66%
20	74.0%	$4.05	$3.21	$0.97	21%	76%
50	88.0%	$21.38	$19.18	$3.49	10%	84%
100	93.7%	$80.25	$75.81	$10.69	6%	87%
200	96.8%	$310.50	$301.56	$36.34	3%	88%
500	98.7%	$1,901	$1,879	$203.29	1%	89%
1,000	99.3%	$7,552	$7,508	$781.54	1%	90%

두 절감률이 반대 방향으로 갈라진다. 짧은 대화에서 프리픽스 캐싱을 붙여 효과를 확인하고 그대로 둔 팀은, 에이전트가 길어질수록 효과가 사라지는 것을 모른 채 운영하게 된다. 1,000턴에서 프리픽스 캐싱은 1%다.

그래서 실무적으로 중요한 것은 절감률이 아니라 절대액이다. 200턴 세션은 완벽하게 캐싱해도 $36이고, 그런 세션을 하루 100개 돌리면 30일에 $109,000이다. 캐싱을 잘하는 것으로는 이 문제를 풀 수 없다.

히스토리가 안정 프리픽스를 넘어서는 지점은 계산할 수 있다.

교차 턴 수 = 2S ÷ δ + 1

이 값을 넘는 첫 정수 턴부터 히스토리가 더 크다. S=10,000, δ=3,000이면 7.7이므로 8턴부터다. 프리픽스가 30,000이면 22턴, 증가분이 500으로 작으면 42턴이다.

증가분에 대한 민감도도 같은 방향이다.

턴당 증가분 δ	히스토리 비중	프리픽스만 절감	롤링 절감
500	32.2%	50%	73%
1,000	48.7%	39%	74%
3,000	74.0%	21%	76%
6,000	85.1%	12%	77%

툴 결과가 클수록 프리픽스 캐싱은 무력해지고 롤링은 4.5%p 안에서 움직인다. 웹 페이지나 코드베이스를 읽어 오는 에이전트가 정확히 이 구간이다. 문서 기준 평균 웹페이지 10kB가 약 2,500 토큰이므로 페이지 하나 읽는 턴의 증가분은 2,900이다. 이 표는 출력을 20턴 × 400 토큰으로 고정하고 δ만 바꾼 것이다.

그래서 진짜 레버는 히스토리를 줄이는 것이다

지수를 건드리려면 N이나 δ를 줄여야 한다. 오래된 툴 결과를 삭제하는 컨텍스트 편집, 대화를 요약해 치환하는 압축, 구간이 끝나면 요약만 들고 새로 시작하는 방식이 모두 N을 리셋한다.

100턴을 구간으로 쪼개 계산한다. 구간이 끝날 때마다 캐시된 컨텍스트를 읽어 요약 2,000 토큰을 만들고, 다음 구간은 그 요약이 얹힌 프리픽스 12,000 토큰으로 시작한다. 요약 생성 비용이 표에 포함돼 있다.

구성	100턴 비용	롤링 통짜 대비 절감률
롤링 통짜	$10.69	—
10턴 × 10구간	$5.13	52.0%
25턴 × 4구간	$5.57	47.9%
50턴 × 2구간	$7.17	32.9%

요약 비용을 다 물고도 롤링 대비 절반 가까이가 남는다. 요약 3회가 먹는 비중은 전체의 5%다. 구간을 짧게 쪼갤수록 유리한데, N이 작아지면 제곱 항이 줄어드는 효과가 요약 횟수가 늘어나는 비용보다 크기 때문이다.

계산에 없는 것은 품질이다. 요약은 정보를 잃고, 잃은 정보가 나중에 필요해지면 에이전트가 같은 작업을 다시 한다. 그 재작업 비용은 위 표에 없다. 비용 축으로만 보면 짧게 쪼개는 것이 유리하지만 품질 축은 반대 방향이다.

모델을 내리는 것이 두 번째 레버이고, 이 축은 캐싱 축과 곱해진다.

모델 (20턴)	캐싱 없음	프리픽스만	롤링	Opus 롤링 대비
Claude Opus 5	$4.05	$3.21	$0.97	1.00×
Claude Sonnet 5	$1.62	$1.28	$0.39	0.40×
Claude Haiku 4.5	$0.81	$0.64	$0.19	0.20×

캐싱 4.17배와 모델 5배가 곱해져 Opus 캐싱 없음과 Haiku 롤링의 차이는 20.9배가 된다. 모델 선택은 품질 판단이라 비용만으로 결정할 수 없지만, 두 축이 독립이 아니라 곱해진다는 사실은 검토 순서를 바꾼다.

모델을 내릴 때 걸리는 함정이 있다. 최소 캐시 프리픽스가 모델마다 다르고, 위 세 모델에서는 싼 쪽이 더 높다. 문서 기준으로 Opus 5는 512 토큰, Sonnet 5는 1,024 토큰, Haiku 4.5는 4,096 토큰이다. 짧은 프롬프트를 쓰는 워크로드를 Haiku로 내리면 캐싱이 아예 걸리지 않을 수 있고, 그러면 표의 $0.19는 나오지 않는다.

만료가 세션당 0.65회를 넘으면 1시간이 싸다

기본 캐시 수명은 5분이다. 20번째 턴 시점의 누적 프리픽스는 67,000 토큰이고, 그 시점에 캐시가 만료되면 다음 요청은 읽기가 아니라 재작성이다.

구분	토큰	단가	비용
캐시 읽기 (0.1×)	67,000	$0.50	$0.0335
재작성 (1.25×)	67,000	$6.25	$0.4188
만료 1회 추가 비용	—	—	$0.3852
세션 전체 $0.97 대비	—	—	40%

문서의 “두 번 읽으면 회수”는 쓰기가 한 번뿐인 프리픽스 캐싱 기준이고 롤링에는 그대로 적용되지 않는다. 롤링은 매 턴 쓰기가 발생하므로 1시간 TTL의 프리미엄도 매 턴 붙는다. 20턴 세션의 총 쓰기 67,000 토큰에 붙는 프리미엄은 $0.2512다. 임계는 그 프리미엄을 만료 1회 비용으로 나눈 값이다.

만료 시점	누적 프리픽스	만료 1회 비용	임계 기대 횟수
20턴 (최대)	67,000	$0.3852	0.65회
10턴 (중간)	40,000	$0.2300	1.09회
5턴 (초반)	25,000	$0.1437	1.75회

세션당 만료가 평균 한 번 정도면 1시간이 유리하고, 그 아래면 만료 시점에 따라 갈린다. 사람 승인이 여러 번 끼는 워크플로나 야간에 드문드문 도는 루프는 이 조건을 넘는다. 완전 자동으로 초 단위에 연달아 도는 루프는 5분이 싸다.

캐시는 에러 없이 깨진다

캐싱은 프리픽스 정확 일치다. 캐시 프리픽스는 tools → system → messages 순서로 구성되므로 앞쪽이 바뀌면 뒤쪽 전부가 무효화된다. 깨지는 경로는 이렇다.

• 시스템 프롬프트에 현재 시각이나 요청 ID, 세션 ID를 넣는다
• JSON 직렬화 키 순서가 비결정적이다
• 툴 목록이 요청마다 달라진다. tools가 맨 앞이므로 전체가 날아간다
• 사용자별 프로필을 시스템 프롬프트에 주입한다. 사용자마다 별도 캐시가 된다

확인 방법은 응답의 사용량 필드 세 개다. cache_read_input_tokens는 캐시에서 읽은 토큰, cache_creation_input_tokens는 캐시에 쓴 토큰, input_tokens는 마지막 브레이크포인트 뒤의 토큰으로 정가로 과금된다. 세 값의 합이 총 입력 토큰이다.

진단에 쓸 지표는 미캐싱 입력 비율, 즉 input_tokens ÷ 총 입력 토큰이다.

턴 수	캐싱 없음	프리픽스만	롤링
10	100%	57.4%	0%
20	100%	74.0%	0%
50	100%	88.0%	0%
100	100%	93.7%	0%

롤링이 제대로 걸리면 이 값이 0에 가깝고, 20~90%대면 프리픽스만 걸린 상태다.

읽기 대 쓰기 비율은 다른 것을 진단한다. 이 비율이 높으면 캐싱이 잘 되는 것으로 읽기 쉽지만, 프리픽스만 캐싱한 100턴 세션은 99:1이고 롤링은 50.6:1이다. 프리픽스만이 오히려 높다 — 쓰기가 첫 턴 한 번뿐이기 때문이다. 이 비율로 두 구성을 구분할 수 없다. 이 비율이 진단하는 것은 무효화이고, 1:1 아래로 내려가면 캐시가 매 턴 깨져 재작성만 반복되는 상태다.

측정한 값을 비용으로 환산하는 식은 이렇다. 세 항은 총 입력 토큰에 대한 비율이므로 합이 1이다.

입력 비용 배수 = 읽기비율 × 0.1 + 쓰기비율 × 1.25 + 미캐싱비율 × 1.0

캐시 가능한 최소 프리픽스도 같이 봐야 한다. 그보다 짧으면 브레이크포인트를 걸어도 조용히 통과한다. Opus 5는 512, Sonnet 5는 1,024, Haiku 4.5는 4,096 토큰이다.

배치 할인은 롤링과 곱해지지 않는다

문서는 캐시 배수가 배치 API 할인과 데이터 레지던시를 포함한 다른 가격 수정자와 스택된다고 명시한다.

항목	효과	조건
배치 API	입력·출력 50% 할인	비동기. 대화형 에이전트에 쓸 수 없고 롤링과도 양립하지 않는다
프롬프트 캐싱	읽기 0.1배	프리픽스 일치 + TTL 생존
미국 전용 추론 (inference_geo: "us")	모든 항목 1.1배 증가	데이터 레지던시 요건이 있을 때
전용 엔드포인트·볼륨 계약	미공개	영업 협의

배치와 롤링을 곱해서 $0.49라고 쓰고 싶어지지만 그 값은 나오지 않는다. 롤링은 턴 사이 캐시가 TTL 안에 살아 있어야 성립하는데 배치는 비동기이고 완료까지 길게 걸린다. 턴마다 캐시가 만료되어 읽기가 아니라 재작성이 된다. 배치가 맞는 것은 턴이 없는 대량 단발 처리다.

부가 과금도 계산에 넣어야 한다. 웹 검색은 1,000회당 $10이므로 세션당 5회면 $0.05다. 롤링 구성 토큰 비용의 5%이고, 검색을 많이 도는 리서치 에이전트라면 무시할 수 없다. 웹 페치는 부가 과금이 없고 가져온 내용의 토큰만 과금된다.

전용 엔드포인트와 볼륨 계약 단가는 두 제공자 모두 영업 문의로만 안내한다. 공개 자료로 도달할 수 있는 범위가 여기까지다. 다만 그것이 이 글의 결론을 흔들지는 않는다. 정률 할인은 세 구성에 동일하게 적용되므로 절감률은 그대로고, 바뀌는 것은 절대액이다.

그래서 어떻게 하는가

먼저 자기 구간을 찾는다.

세션이 교차 턴 수보다 짧다. 안정 프리픽스 캐싱으로 끝난다. 5턴이면 프리픽스만으로 37%이고 롤링을 붙여도 52%다. 구현 공수를 들일 구간이 아니다.

교차 턴 수 이상, 100턴 이하. 히스토리 캐싱 없이는 절감이 사라진다. 롤링을 붙인다. 프리픽스만 구성 대비 20턴에서 세션당 $2.24, 100턴에서 $65.12를 아낀다.

100턴 이상. 롤링만으로는 부족하다. 압축이나 구간 분할로 N을 리셋하는 것을 먼저 검토한다. 100턴을 구간으로 쪼개면 요약 비용을 물고도 롤링 대비 절반 가까이가 더 나온다. 비용만 보면 10턴씩 쪼개는 것이 최적이지만 요약 손실이 커지므로 25턴 부근이 타협점이다.

사람 개입이 5분을 넘을 수 있다. 위 어느 구간이든 1시간 TTL로 간다.

두 조직을 이 모델에 넣어 본다. 전제(S=10,000, δ=3,000, 턴당 출력 400)는 위와 같고 모델은 Opus 5다.

두 예시가 같은 것을 보여 준다. 100턴 아래에서는 롤링을 붙이는 것으로 끝나고, 그 위에서는 롤링을 붙인 다음이 진짜 문제다.

그다음 순서대로 실행한다.

1. 응답 사용량 필드를 로깅하고 미캐싱 입력 비율을 위 표와 대조한다. 0에 가깝지 않으면 롤링이 안 걸린 것이고, 읽기 대 쓰기가 1:1 아래면 캐시가 매 턴 깨지는 것이다
2. 교차 턴 수를 계산한다. 2S ÷ δ + 1. 이 값보다 긴 세션이 있으면 프리픽스 캐싱만으로 부족하다
3. 회수 문턱을 계산한다. 롤링 구현에 엔지니어 3일을 $2,000으로 보면 20턴 세션은 약 894회, 100턴 세션은 약 31회에서 회수된다. 월 세션 수가 그보다 적으면 지금 할 일이 아니다. 이 문턱은 토큰 절감만 센 것이고, 캐시 히트가 첫 토큰 지연을 줄이는 편익은 넣지 않았다
4. 프리픽스에서 시각·ID·비결정적 정렬을 제거한다. 무효화 한 건이 그 구간 비용을 10배로 만들고, 이 작업은 계약 협상과 달리 며칠이면 끝난다
5. N과 δ를 줄일 수 있는지 본다. 캐싱을 다 한 뒤에도 비용이 제곱으로 자라면 이쪽이 유일한 레버다

이 글의 숫자는 전부 예시값 위에 있다. 결론은 가정에 덜 민감하다.

캐싱을 넣으면 1편의 절감 배수가 무너진다

1편은 API 값으로 서버리스 정가 $1.04를 썼고, 실단가를 확보하지 못해 자체 서빙에 유리하게 기울어진 계산이라고 명시했다. 캐시와 배치 단가가 생겼으니 그 모델로 돌아갈 수 있다.

캐시 적중률 h에서 실효 입력 단가는 $1.04 × (1 - 0.9h)다. 1편의 워크로드는 입출력이 1:1이므로 블렌드 단가는 실효 입력 단가와 출력 단가의 평균이다. 배치는 입력·출력 모두 50%를 곱한다.

구성	필요 가동률	포화 시 절감 배수	손익분기 (월 과금 토큰)
1편의 값 (정가)	25.5%	3.92배	56.0억
캐시 적중 50%	32.9%	3.04배	72.3억
캐시 적중 70%	37.2%	2.69배	81.8억
캐시 적중 90%	42.8%	2.33배	94.1억
배치 50%만	51.0%	1.96배	112.0억
캐시 70% + 배치 50%	74.4%	1.34배	163.5억

1편의 “가동률 100%에서 3.92배 저렴”이 캐시와 배치를 함께 넣으면 1.34배로 내려간다. 배치 단독 효과(1.96배)가 캐시 90% 효과(2.33배)보다 크다. 1편이 “다음 편 최우선 취재 대상”이라고 못 박은 비대칭이 여기서 닫힌다.

첫 행에 단서를 붙여야 한다. 1편의 56.0억과 25.5%는 운영 인건비 $0, 실효 처리량 100% 행이고, 1편은 그 값을 자기 계산의 하한선이라고 명시했다. 인건비 $4,000이면 1편의 기준선은 69% 올라간다. 이 표는 그 하한선 위에서 API 쪽 할인만 적용한 것이다.

세 가지 비대칭도 남는다. 첫째, 자체 서빙 쪽도 프리픽스 캐시를 쓰는 것이 일반적이다. 다만 API 쪽 캐싱은 과금 단가를 0.1배로 깎고 자체 서빙 쪽 캐시는 프리필 연산을 줄여 처리량을 올리므로, 두 경로가 같은 배수로 상쇄된다는 보장이 없다. 자체 서빙 쪽 적중률 자료를 확보하지 못했다.

둘째, 0.9와 0.5라는 계수는 Anthropic과 OpenAI의 배수에서 가져온 것이다. 1편이 쓴 $1.04는 Together AI의 Llama 3.3 70B 단가이고 Together의 캐시·배치 정책은 확인하지 못했다. 셋째, 이 식은 캐시 쓰기(1.25배)를 빼고 읽기만 계산해 API 실단가를 낮게 잡는다. 두 항목 모두 손익분기 상승폭을 과대평가하는 방향이다.

그래서 이 표는 정확한 값이 아니라 방향과 대략의 크기로 읽어야 한다. 방향은 분명하다. API 쪽 할인을 정가로 계산한 비교는 자체 서빙에 유리하게 기울어져 있고, 그 기울기는 1편이 예상한 것보다 크다.