Claude 프롬프트 캐싱으로 API 비용 90% 줄이기

7월 21, 2026

Claude API로 챗봇이나 에이전트를 돌리다 보면 청구서에서 가장 큰 비중을 차지하는 항목이 입력 토큰이라는 사실을 알게 된다. 시스템 프롬프트, 도구 정의, 참고 문서를 매 요청마다 통째로 다시 보내기 때문이다. 프롬프트 캐싱(Prompt Caching)을 적용하면 이 반복 전송분의 입력 단가를 최대 90%까지 줄일 수 있다. 이 글에서는 캐싱의 동작 원리부터 cache_control을 붙이는 위치, 캐시 수명 관리, 공식 단가 기반 비용 계산까지 실제 적용해 본 순서 그대로 정리한다.

프롬프트 캐싱이란 — 입력 최대 90% 절감 원리

프롬프트 캐싱은 프롬프트의 앞부분(프리픽스)을 Anthropic 서버에 잠시 저장해 두고, 같은 프리픽스로 다시 요청이 오면 그 구간을 처음부터 다시 처리하지 않는 기능이다. 과금 구조는 단순하다. 캐시에 처음 쓸 때는 일반 입력 단가의 1.25배를 내고, 이후 캐시를 읽을 때는 0.1배만 낸다. 즉 두 번째 요청부터는 반복 구간의 입력 비용이 90% 할인되는 셈이다. 비용뿐 아니라 응답 지연(latency)도 눈에 띄게 줄어든다.

공식 문서 기준 단가 배율을 표로 정리하면 다음과 같다. 출력 토큰 가격에는 영향이 없다.

구분	단가 배율	설명
일반 입력	×1.0	캐싱 미사용 시 기본 단가
캐시 쓰기 (5분 TTL)	×1.25	첫 요청에서 캐시 생성 시
캐시 쓰기 (1시간 TTL)	×2.0	긴 수명 옵션 선택 시
캐시 읽기 (히트)	×0.1	90% 절감 구간
출력 토큰	변동 없음	캐싱과 무관

캐싱이 유리한 경우 / 무의미한 경우

캐싱이 이득이 되려면 세 가지 조건이 맞아야 한다. 같은 프리픽스가 반복되고, 재호출이 캐시 수명(기본 5분) 안에 일어나고, 프리픽스가 최소 캐시 길이를 넘어야 한다. 공식 문서 기준으로 모델별 최소 캐시 가능 길이가 정해져 있는데 Sonnet 계열은 1,024토큰 수준이다. 이보다 짧은 프롬프트는 cache_control을 붙여도 캐시되지 않는다.

반대로 매 요청마다 프롬프트 내용이 통째로 바뀌는 일회성 작업, 호출 간격이 긴 배치성 작업에서는 캐시 쓰기 비용(×1.25)만 추가로 내고 히트는 못 보는 역효과가 날 수 있다. 자기 워크로드의 호출 패턴부터 확인하는 것이 순서다.

실제 적용 — cache_control 붙이는 위치와 코드

캐시는 프리픽스 단위로 동작한다. 요청 본문에서 tools → system → messages 순서로 앞부분이 캐시 대상이 되며, cache_control은 "여기까지 캐시하라"는 경계 표시다. 시스템 프롬프트 끝에 붙이는 것이 가장 기본형이다.

import anthropic

client = anthropic.Anthropic()

SYSTEM_PROMPT = "여기에 수천 토큰 분량의 시스템 프롬프트와 참고 문서를 넣는다."

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "문서 내용을 세 줄로 요약해 줘"}],
)

print(response.usage)
# cache_creation_input_tokens / cache_read_input_tokens 값을 확인

정상 동작 확인은 응답의 usage 필드로 한다. 첫 호출에서는 cache_creation_input_tokens(캐시 쓰기)가 잡히고, 5분 내 두 번째 호출부터 cache_read_input_tokens(캐시 히트)가 잡히면 성공이다. 주의할 점은 프리픽스가 한 글자라도 바뀌면 캐시 미스라는 것이다. 시스템 프롬프트 안에 현재 시각 같은 가변 값을 넣으면 캐시가 매번 깨지므로, 바뀌는 값은 반드시 프리픽스 뒤쪽(사용자 메시지)으로 몰아야 한다.

캐시 수명(5분)과 재사용 전략

기본 캐시 수명(TTL)은 5분이다. 다만 캐시가 읽힐 때마다 수명이 5분씩 다시 연장되므로, 5분 안에 요청이 계속 들어오는 서비스라면 캐시는 사실상 계속 살아 있다. 반대로 호출 간격이 5분을 넘는 워크로드라면 1시간 TTL 옵션을 고려한다. "cache_control": {"type": "ephemeral", "ttl": "1h"}처럼 지정하며, 쓰기 단가가 2배가 되는 대신 히트가 몇 번만 나와도 본전을 뽑는다.

자주 호출되는 서비스: 기본 5분 TTL로 충분하다. 히트가 수명을 계속 연장해 준다.
간헐적 호출(5분~1시간 간격): 1시간 TTL 쓰기(×2.0)로 전환을 검토한다.
공통 프리픽스 설계: 여러 기능이 같은 시스템 프롬프트를 공유하도록 구조를 맞추면 히트율이 올라간다.

before/after — 공식 단가 기반 계산 예시

아래 표는 실측 결과가 아니라 공식 단가를 기반으로 한 계산 예시다. 입력 100만 토큰당 3달러인 모델을 기준으로(캐시 쓰기 3.75달러, 캐시 읽기 0.30달러), 2만 토큰짜리 프리픽스(시스템 프롬프트+문서)에 500토큰짜리 질문을 하루 100회, 항상 5분 내 간격으로 보낸다고 가정했다.

항목	캐싱 미적용	캐싱 적용
프리픽스 2만 토큰 × 100회	약 $6.00	쓰기 1회 $0.075 + 읽기 99회 $0.594 = 약 $0.67
질문 500토큰 × 100회	$0.15	$0.15
하루 입력 비용 합계	약 $6.15	약 $0.82 (약 87% 절감)

프리픽스 비중이 클수록, 호출 횟수가 많을수록 절감률은 90%에 가까워진다. 반대로 하루 두세 번 호출하는 수준이라면 체감 효과는 미미하다.

배치 API와 함께 쓸 때 절감폭

실시간 응답이 필요 없는 대량 작업이라면 배치 API(Message Batches)를 함께 쓸 수 있다. 배치는 입력·출력 모두 50% 할인되며, 공식 문서 기준 프롬프트 캐싱과 중복 적용이 가능하다. 다만 배치는 요청 처리 순서와 시점이 보장되지 않아 5분 TTL로는 히트율이 실시간 호출보다 낮게 나올 수 있다. 대량 배치에서 캐싱 효과를 노린다면 1시간 TTL 조합이 현실적이다.

정리하면, 프롬프트 캐싱은 코드 몇 줄 추가로 끝나는 작업치고 절감폭이 가장 큰 최적화다. 긴 시스템 프롬프트를 반복 전송하고 있다면 지금 바로 usage 필드를 열어 캐시 히트가 잡히는지부터 확인해 보길 권한다.

함께 보면 좋은 글: 클로드 모델별 토큰 비용과 구독 플랜 사용량 한도 총정리

※ 이 글의 단가 배율·캐시 수명·모델명은 2026년 기준이며 변경될 수 있습니다.

이 블로그 검색

에이븐스튜디오