본문으로 건너뛰기
TEN Brief 하루 열 건, 확인된 것만 2026.09.05 EN

This article is also available in English →

테크 · 5분 · 검색 의도

프롬프트 캐싱이란 — 두 번째부터 입력이 40분의 1 값이 된다

Prompt caching stores the repeated opening section of a request to a language model so it does not have to be processed from scratch on every call. Because a transformer computes each token's internal representation from the tokens before it, an identical prefix produces identical intermediate values, and those values can be saved and reused. The pricing follows the mechanics: writing to the cache costs more than ordinary input, reading from it costs far less, and the cache expires after a set time. On Anthropic's Claude Fable 5.1, released September 1, 2026, ordinary input is 10 dollars per million tokens, a five-minute cache write is 12.50 dollars, a one-hour write is 20 dollars, and a read is 0.25 dollars, which is one-fortieth of the input price. The break-even therefore falls between the first and second reuse for a five-minute cache and around the second for a one-hour cache. The trap is that the cache matches only an exact prefix, so anything variable placed near the front destroys it on every call

프롬프트 캐싱은 언어 모델에 보내는 요청에서 매번 반복되는 앞부분을 저장해 두고 재사용하는 기능이다. 트랜스포머 모델은 각 토큰의 내부 표현을 그 앞의 토큰들로부터 계산하기 때문에, 앞부분이 완전히 같으면 중간 계산 결과도 같다. 그 결과를 저장했다가 다시 쓰는 것이 프롬프트 캐싱이다. 가격 구조는 이 원리를 그대로 따른다. 저장할 때(쓰기)는 일반 입력보다 비싸고, 꺼내 쓸 때(읽기)는 훨씬 싸며, 저장된 내용은 정해진 시간이 지나면 사라진다. 2026년 9월 1일 공개된 앤스로픽 클로드 페이블 5.1을 예로 들면 일반 입력이 100만 토큰 10달러, 5분 보관 쓰기가 12.50달러, 1시간 보관 쓰기가 20달러, 읽기가 0.25달러다. 읽기가 입력의 40분의 1이므로 손익분기는 5분 캐시의 경우 두 번째 재사용, 1시간 캐시의 경우 두세 번째 재사용에서 넘어간다. 함정은 캐시가 완전히 같은 앞부분에만 걸린다는 점이다

오후 햇살이 드는 도서관 서가와 절반쯤 뽑혀 나온 책 한 권

3줄 요약

  • 원리 — 앞부분이 같으면 중간 계산이 같다. 그 계산 결과를 저장해 재사용한다
  • 값 — 쓰기는 입력보다 비싸고 읽기는 40분의 1. 두 번째 재사용부터 이득이다
  • 함정 — 완전히 같은 앞부분에만 걸린다. 가변 정보를 앞에 두면 매번 깨진다

핵심 질문

프롬프트 캐싱이 뭐야
**매번 똑같이 들어가는 앞부분을 저장해 두고 다시 쓰는 기능이다.** 언어 모델은 원래 호출할 때마다 입력 전체를 처음부터 처리한다. 시스템 지시가 2000토큰, 참조 문서가 5만 토큰이라면 질문 한 줄을 바꿔 물을 때마다 그 5만 2000토큰을 통째로 다시 읽는다. 열 번 물으면 52만 토큰 값을 낸다. 캐싱은 그 반복을 없앤다. **처음 한 번 처리한 결과를 저장해 두고, 다음 호출부터는 저장된 것을 꺼내 쓴다.** 가격은 세 단계로 나뉜다 — **일반 입력**(캐시 안 씀), **캐시 쓰기**(저장, 일반 입력보다 비쌈), **캐시 읽기**(꺼내 쓰기, 훨씬 쌈). 앤스로픽 클로드 페이블 5.1 기준으로 100만 토큰당 일반 입력 **10달러**, 5분 보관 쓰기 **12.50달러**, 1시간 보관 쓰기 **20달러**, 읽기 **0.25달러**다. **읽기가 입력의 40분의 1**이다(「앤스로픽 페이블 5.1」).
몇 번 써야 이득이야
**5분 캐시는 두 번째 호출부터, 1시간 캐시는 두세 번째부터 이득이다.** 100만 토큰짜리 앞부분을 N번 쓰는 경우로 계산해 보면 이렇다. 캐시를 안 쓰면 **N × 10달러**다. 5분 캐시를 쓰면 **12.50 + (N−1) × 0.25달러**다. N=1이면 12.50 대 10으로 캐시가 손해, **N=2면 12.75 대 20으로 캐시가 유리**하다. N=10이면 14.75 대 100 — **6분의 1 이하**다. 1시간 캐시는 **20 + (N−1) × 0.25달러**다. N=2면 20.25 대 20으로 거의 같고, **N=3이면 20.50 대 30으로 유리**해진다. 즉 **한 번만 쓸 거면 캐시를 켜지 않는 것이 싸다.** 여기서 실제 판단 기준이 나온다 — 보관 시간을 5분으로 할지 1시간으로 할지는 **재사용 횟수가 아니라 재사용 간격**이 정한다. 열 번을 3분 안에 쓸 거면 5분짜리로 충분하고, 열 번을 하루에 걸쳐 띄엄띄엄 쓸 거면 1시간짜리도 모자란다.
캐시가 왜 자꾸 안 걸려
**앞부분이 조금이라도 달라졌기 때문일 가능성이 가장 크다.** 캐시는 **접두사(prefix) 단위**로 걸린다. 앞에서부터 완전히 같은 구간까지만 재사용되고, 한 글자라도 달라지는 지점부터는 전부 다시 계산된다. 원리가 그렇다 — 트랜스포머에서 각 토큰의 내부 표현은 **그 앞의 토큰들에만 의존**하므로, 앞이 같으면 중간 결과가 같고 앞이 달라지면 그 뒤가 모두 무효가 된다. 그래서 가장 흔한 실수가 이것이다. **자주 바뀌는 것을 앞에 두는 것.** 시스템 프롬프트 첫 줄에 현재 시각이나 사용자 이름, 요청 ID를 넣으면 **매 호출마다 캐시가 통째로 깨진다.** 해법은 순서를 뒤집는 것이다 — **고정된 부분(지시·문서·코드베이스)을 앞에, 매번 바뀌는 부분(질문·시각·사용자 정보)을 뒤에** 둔다. 그 밖에 자주 걸리는 이유가 셋 더 있다. **최소 토큰 수 미달**(모델마다 캐시가 걸리는 최소 길이가 있다), **보관 시간 경과**(5분·1시간이 지나면 사라진다), 그리고 **대화가 길어지며 앞부분 자체가 계속 자라는 경우**다. 마지막 항목은 에이전트형 작업에서 특히 문제가 된다.

프롬프트 캐싱은 매번 똑같이 들어가는 앞부분을 저장해 두고 재사용하는 기능이다.

이 기능이 왜 필요한지는 언어 모델이 원래 어떻게 동작하는지를 보면 바로 보인다.

1. 모델은 매번 처음부터 다시 읽는다

언어 모델은 호출할 때마다 입력 전체를 처음부터 처리한다. 이전 대화를 "기억"하는 것처럼 보이는 서비스도 실제로는 이전 대화를 통째로 다시 보내는 방식이다.

그래서 이런 상황이 생긴다. 시스템 지시가 2000토큰, 참조 문서가 5만 토큰이라고 하자. 질문 한 줄만 바꿔 열 번 물으면 —

5만 2000토큰 × 10회 = 52만 토큰

같은 5만 2000토큰을 열 번 값 내고 읽는 것이다. 바뀐 것은 마지막 한 줄뿐인데.

프롬프트 캐싱은 이 반복을 없앤다. 처음 한 번 처리한 결과를 저장해 두고, 다음 호출부터는 저장된 것을 꺼내 쓴다.

2. 왜 '앞부분'만 되나

캐시가 앞부분에만 걸리는 것은 편의상의 제약이 아니라 모델 구조에서 나오는 성질이다.

트랜스포머에서 각 토큰의 내부 표현은 그 앞의 토큰들에만 의존한다. 100번째 토큰을 계산할 때는 1~99번 토큰을 보지만, 101번 토큰은 보지 않는다. 그래서 —

  • 앞부분이 완전히 같으면 그 구간의 중간 계산 결과도 완전히 같다 → 저장해 두고 재사용할 수 있다
  • 앞부분이 한 글자라도 달라지면 그 지점 이후의 모든 계산이 달라진다 → 전부 다시 계산해야 한다

이것을 접두사(prefix) 단위 캐싱이라고 부른다. 뒤가 아니라 앞이어야 하는 이유가 여기 있다.

3. 가격은 세 칸으로 나뉜다

원리가 그러하므로 가격도 세 단계다.

구분하는 일페이블 5.1 (100만 토큰당)
일반 입력캐시 안 씀. 매번 처리$10
캐시 쓰기 (5분)처리 결과를 5분간 저장$12.50
캐시 쓰기 (1시간)처리 결과를 1시간 저장$20
캐시 읽기저장된 것을 꺼내 씀$0.25

읽기가 일반 입력의 40분의 1이다. 2026년 9월 1일 앤스로픽이 페이블 5.1을 내면서 이 항목만 1.00달러에서 0.25달러로 75% 내렸다 — 입력 10달러·출력 50달러는 그대로 두고 이 한 줄만 움직였다(「앤스로픽 페이블 5.1」).

4. 몇 번 써야 이득인가

100만 토큰짜리 앞부분을 N번 쓰는 경우로 계산해 보자.

호출 횟수캐시 없음5분 캐시1시간 캐시
1회$10.00$12.50$20.00
2회$20.00$12.75$20.25
3회$30.00$13.00$20.50
5회$50.00$13.50$21.00
10회$100.00$14.75$22.25
50회$500.00$24.75$32.25

읽어야 할 줄이 세 개다.

첫째, 한 번만 쓸 거면 캐시를 켜지 않는 것이 싸다. 쓰기 프리미엄(5분 2.50달러, 1시간 10달러)을 회수할 기회가 없다.

둘째, 손익분기가 매우 낮다. 5분 캐시는 두 번째 호출에서, 1시간 캐시는 세 번째에서 넘어간다. 반복이 조금이라도 있으면 켜는 쪽이 맞다.

셋째, 보관 시간을 정하는 것은 횟수가 아니라 간격이다. 열 번을 3분 안에 쓸 거면 5분짜리로 충분하고, 열 번을 하루에 걸쳐 띄엄띄엄 쓸 거면 1시간짜리도 모자라 중간에 다시 써야 한다. 몇 번 쓰느냐가 아니라 얼마나 자주 쓰느냐를 봐야 한다.

5. 캐시가 안 걸리는 네 가지 이유

실무에서 "캐싱을 켰는데 청구서가 안 줄었다"는 상황은 대개 이 넷 중 하나다.

① 자주 바뀌는 것을 앞에 뒀다 — 가장 흔한 실수다.

시스템 프롬프트 첫 줄에 현재 시각, 사용자 이름, 요청 ID 같은 것을 넣으면 매 호출마다 앞부분이 달라져 캐시가 통째로 깨진다. 캐시 쓰기 값만 계속 내고 읽기는 한 번도 못 하는 최악의 조합이 된다.

해법은 순서를 뒤집는 것이다.

  • : 시스템 지시, 참조 문서, 코드베이스, 도구 정의 — 바뀌지 않는 것
  • : 사용자 질문, 현재 시각, 세션 정보 — 매번 바뀌는 것

② 최소 토큰 수에 못 미친다. 모델마다 캐시가 걸리는 최소 길이가 정해져 있다. 짧은 프롬프트는 캐싱해도 아무 일이 일어나지 않는다.

③ 보관 시간이 지났다. 5분 또는 1시간이 지나면 저장된 내용이 사라지고, 다음 호출은 다시 '쓰기' 값을 낸다. 갱신 규칙(읽을 때마다 시간이 연장되는지)은 제공사마다 다르므로 문서를 확인해야 한다.

④ 앞부분 자체가 계속 자란다. 대화형·에이전트형 작업에서는 매 단계마다 이전 응답이 앞부분에 쌓인다. 앞부분이 자라면 그 자란 부분은 새로 써야 하고, 캐시된 구간의 비율이 갈수록 낮아진다.

6. 단가가 내렸는데 청구서가 그대로인 경우

앤스로픽은 페이블 5.1의 캐시 읽기 인하로 청구액이 25~45% 줄어든다고 밝혔다. 외부 테스트에서는 작업 하나를 끝내는 데 드는 비용이 실제로 줄었는지 결과가 엇갈렸다고 보도됐다.

두 진술이 동시에 성립할 수 있다. 이유는 두 개다.

첫째, 재사용 비율이 워크로드마다 다르다. 코드베이스 하나를 올려두고 수십 번 질문하는 작업이면 읽기 인하가 청구서에 그대로 반영된다. 매번 다른 문서를 넣는 작업이면 쓰기 값이 지배하고 읽기 인하는 거의 닿지 않는다.

둘째, 단가가 내리면 쓰는 양이 는다. 에이전트형 작업에서 성능이 좋아진 모델은 더 많은 단계를 스스로 밟는다. 단가가 4분의 1이 돼도 총 토큰이 네 배가 되면 작업당 비용은 제자리다.

단가는 확실히 내렸고, 총액은 자기 워크로드가 정한다. 자기 청구서에서 캐시 읽기 토큰이 전체 입력의 몇 퍼센트인지를 먼저 보는 것이 순서다.

7. 남은 것과 확인되지 않은 것

  • 가격은 수시로 바뀐다. 이 문서의 숫자는 2026년 9월 5일 기준 페이블 5.1이며, 구조를 설명하기 위한 예시다. 실제 계산은 각 사 문서의 최신 표로 해야 한다.
  • 캐시 보관 시간의 갱신 규칙이 제공사마다 다르다. 읽을 때마다 시간이 연장되는 방식인지 아닌지에 따라 장시간 작업의 비용이 크게 달라진다.
  • 최소 토큰 조건은 공지 없이 바뀔 수 있다.
  • 손익분기 표는 앞부분 100만 토큰을 가정한 산술이다. 출력 토큰 값(페이블 5.1 기준 100만 토큰 50달러)은 캐싱과 무관하게 그대로 든다. 긴 답변을 많이 받는 작업이면 절약폭의 체감이 달라진다(「AI 토큰 가격이란」).
  • 캐싱은 여러 회사가 함께 제공한다. 다만 이름, 최소 길이, 보관 시간, 할인율이 서로 달라 회사 간 비교는 표시 가격만으로 성립하지 않는다.

출처

  1. Anthropic — Prompt caching documentation
  2. Anthropic — Pricing
  3. VentureBeat — Anthropic's Claude Fable 5.1 and Mythos 5.1 arrive with a 75% cost reduction for Fable cache reads
  4. LLM Stats — Claude Fable 5.1 API pricing, context window and benchmarks
  5. OpenAI — API pricing
  6. implicator.ai — Anthropic Fable 5.1 Keeps $10/$50 Price, Cuts Cache Reads 75%

검증

발행
최종 수정
교차 확인
서로 다른 출처 6건을 대조했다.
미검증
  • 손익분기 계산은 100만 토큰짜리 앞부분을 가정한 산술이다. 실제 청구액은 프롬프트 길이, 캐시 최소 토큰 조건, 출력 토큰 수에 따라 달라진다.
  • 캐시 보관 시간의 갱신 규칙(읽을 때마다 시간이 연장되는지 여부)은 모델·제공사마다 다르다. 각 사의 최신 문서로 확인해야 한다.
  • 캐시가 걸리는 최소 토큰 수는 모델마다 다르며 공지 없이 바뀔 수 있다.
  • '청구액 25~45% 감소'는 앤스로픽이 제시한 수치이고, 외부 테스트는 작업당 비용이 실제로 줄었는지에 이견을 보였다고 보도됐다.
  • 가격은 2026년 9월 5일 기준이며 수시로 바뀐다. 이 문서의 숫자는 구조를 설명하기 위한 예시다.
작성
발행 전 사람이 검수했다. 수집·교차확인·재작성 절차는 편집 원칙.

하루 열 건, 아침에 한 번

3줄 요약만 보내고 전문은 사이트에서 읽습니다. 하단에서 한 번의 클릭으로 언제든 해지할 수 있습니다.

관련