프롬프트 캐싱, 완전 쉽게 풀어서 설명하기

TMT

https://x.com/akshay_pachaar/status/2031021906254766128

클로드가 어떻게 캐시 히트율 92%를 뽑아내는지 보여주는 사례 분석

AI 에이전트가 한 번 움직일 때마다, 일종의 세금을 지불하게 됩니다.

에이전트는 매번 모든 내용을 처음부터 다시 읽습니다.

시스템 지침. 도구 정의. 세 턴 전에 이미 불러온 프로젝트 컨텍스트. 이 모든 것들을요. 매 턴마다 전부 다요.

이게 바로 컨텍스트 세금입니다. 그리고 장시간 동작하는 에이전틱 워크플로에서는, 이 세금이 AI 인프라 전체에서 가장 비용이 많이 드는 항목이 되는 경우가 많습니다.

수학적으로 보면 이렇습니다. 20,000토큰짜리 시스템 프롬프트가 50턴 동안 반복되면, 아무 새로운 가치도 만들어내지 못하면서 그대로 정가로 과금되는 중복 연산이 100만 토큰어치 발생합니다.

이에 대한 해결책이 프롬프트 캐싱입니다. 하지만 제대로 활용하려면, 내부에서 실제로 무슨 일이 일어나는지 이해해야 합니다.

무엇이 바뀌고, 무엇이 안 바뀌는지부터 보라

무언가를 최적화하기 전에, 우선 에이전트의 프롬프트(컨텍스트) 구조를 명확하게 생각해야 합니다.

에이전트가 보내는 모든 요청은 근본적으로 두 부분으로 나뉩니다.

정적 프리픽스(static prefix): 시스템 지침, 도구 정의, 프로젝트 컨텍스트, 행동 가이드라인 등이 포함됩니다. 세션의 모든 턴에서 내용이 완전히 동일합니다.

동적 테일(dynamic tail): 사용자 메시지, 도구 출력, 터미널 관측 결과 등이 포함됩니다. 매 요청마다 바뀌며, 대화가 진행될수록 계속 늘어납니다.

이 구분이 핵심입니다. 정적 프리픽스가, 아무 이유 없이 매번 다시 계산하고 있는 비싼 부분입니다. 동적 테일만이 실제로 새 계산이 필요한 유일한 부분입니다.

프롬프트 캐싱은 이 정적 프리픽스의 “수학적 상태”를 저장해 두었다가, 이후 요청에서 해당 부분의 재계산을 완전히 건너뛰게 만드는 방식으로 동작합니다. 처음 한 번만 그 프리픽스를 처리하는 비용을 내고, 이후 턴들에서는 메모리에서 읽어오기만 하는 것입니다.

왜 이것이 통하는가: 트랜스포머가 실제로 하는 일

캐싱이 왜 그렇게 효과적인지 제대로 이해하려면, 모델이 프롬프트를 읽을 때 내부에서 어떤 일이 일어나는지 알아야 합니다.

LLM 추론 요청은 항상 두 단계로 진행됩니다.

1단계: 프리필(Prefill)

이 단계에서는 모델이 전체 입력 프롬프트를 처리합니다. 이 과정은 컴퓨트 바운드(compute-bound)이며, 컨텍스트에 있는 모든 토큰에 대해 밀집 행렬 곱(dense matmul)을 수행합니다. 모델은 모든 내용을 읽고, 그것에 대한 표현을 쌓아 올립니다. 느리고, 비용이 많이 드는 단계입니다.

2단계: 디코드(Decode)

이 단계에서는 모델이 출력 토큰을 한 번에 하나씩 생성합니다. 이 과정은 컴퓨트보다는 메모리 바운드(memory-bound)에 가깝습니다. 모델은 대부분의 시간을 무거운 계산을 다시 하는 대신 이전에 계산한 상태를 읽는 데 쓰기 때문입니다.

프리필 단계에서, 트랜스포머는 각 토큰에 대해 Query, Key, Value라는 세 개의 벡터를 만듭니다. 어텐션 메커니즘은 이 벡터들을 사용해 각 토큰이 시퀀스의 다른 모든 토큰과 어떻게 연관되는지를 계산합니다.

여기서 중요한 통찰이 하나 있습니다. Key와 Value 벡터는 그 시점까지 나온 토큰들에만 의존한다는 점입니다. 한 번 어떤 프리픽스에 대해 계산이 끝난 Key/Value는, 다시 바뀔 일이 없습니다.

아래 그림은 방금 설명한 내용을 시각적으로 보여줍니다.

캐싱을 쓰지 않으면, 이 Key–Value 텐서들은 요청이 끝나는 순간 바로 버려집니다. 다음 요청은 처음부터 다시 시작해, 모든 20,000개 토큰에 대해 이 텐서들을 다시 계산합니다.

KV 캐싱은 이 문제를, 해당 텐서들을 저장함으로써 해결합니다. 인프라는 이 텐서들을 추론 서버 상에 유지하면서, 입력 텍스트의 크립토그래픽 해시를 키로 삼아 인덱싱합니다. 새로운 요청이 같은 프리픽스를 가지고 들어오면, 해시가 일치하고, 텐서가 즉시 복구되며, 모델은 그 구간의 계산을 통째로 건너뜁니다.

이 덕분에 한 토큰을 생성할 때 드는 계산 복잡도가, O(n²)에서 O(n)으로 떨어집니다. 20,000토큰짜리 프리픽스를 50턴 동안 반복하는 상황을 생각해 보면, 이 절감 효과가 얼마나 큰지 알 수 있습니다.

경제성

가격 구조를 이해해야만, 이 아키텍처적 선택이 왜 그렇게 중요한지 감이 잡히게 됩니다.

Anthropic이 각 모델 패밀리에서 캐싱 가격을 어떻게 책정하는지 살펴보겠습니다.

기억해야 할 숫자 세 개:

캐시 읽기(cache read)는 기본 입력 가격의 10%만 청구됩니다. 캐시에서 읽는 모든 토큰이 90% 할인되는 셈입니다.
캐시 쓰기(cache write)는 기본 입력 가격보다 25% 비쌉니다. KV 텐서를 저장하기 위한 작은 프리미엄입니다.
1시간 확장 캐싱(extended 1-hour caching)은 기본 가격의 2배가 듭니다.

이 구조에서 수지가 맞으려면, 캐시 히트율이 높게 유지되어야 합니다. 실제 환경에서 그게 어떤 모습인지 보여 주는 최고의 사례가 바로 다음입니다.

Claude Code: 30분 세션 워크스루

Claude Code는 하나의 목표를 중심으로 설계되었습니다. 바로 “캐시를 뜨겁게 유지하는 것(keep the cache hot)”입니다.

이게 구체적으로 무엇을 의미하는지 이해하기 위해, 전형적인 30분 코딩 세션을 따라가 보면서 정확히 어떤 부분에 과금이 되고, 어떤 부분은 과금되지 않는지 추적해 보겠습니다.

0분: 세션 시작

Claude Code는 시스템 프롬프트와 도구 정의들을 로드합니다. 그리고 프로젝트 루트에 있는 CLAUDE.md 파일을 읽어, 코드베이스와 컨벤션을 설명하는 내용을 가져옵니다. 이 페이로드는 자주 20,000토큰을 넘깁니다.

이 순간이 세션 전체에서 가장 비용이 큰 지점입니다. 모든 토큰이 처음 등장하는 토큰들이니까요. 하지만 이 비용은 단 한 번만 지불합니다.

1~5분: 첫 번째 명령들

당신은 “auth 모듈을 살펴보고 개선할 점을 제안해 줘” 같은 첫 지시를 입력합니다.

Claude Code는 Explore 서브에이전트를 띄웁니다. 이 에이전트는 코드베이스를 탐색하며 파일을 열고, grep 명령을 실행하고, 관련 코드에 대한 그림을 그려 나갑니다. 이 모든 결과가 동적 테일에 계속 추가됩니다.

20,000토큰짜리 정적 기반 부분은 이미 캐시에 올라가 있습니다. 이제 이 부분은 1M토큰당 $3.00이 아니라 $0.30에 읽힙니다. 새로 추가되는 도구 출력과 당신의 메시지에 대해서만 정가를 내면 됩니다.

6~15분: 딥 워크

Plan 서브에이전트는 Explore 서브에이전트가 찾은 내용을 전달받습니다. 이때 Claude Code는 동적 테일이 불필요하게 비대해지는 일을 막기 위해, 원시 결과 전체를 그대로 넘기지 않고 간결한 요약본만 전달합니다. 이렇게 해야 접미부 길이를 적절히 유지하면서 캐시 효율도 함께 지킬 수 있습니다.

플래너는 구조화된 구현 계획을 만듭니다. 당신은 이 계획을 검토하고 승인하며, Claude Code는 실제 코드 수정을 시작합니다. 이 루프의 매 턴마다 20,000토큰짜리 프리픽스는 캐시에서 읽히고, 캐시 히트가 일어날 때마다 TTL이 갱신되어 이후 턴들을 위해 캐시가 계속 따뜻한 상태를 유지합니다.

16~25분: 반복

당신은 수정을 요청하고, Claude Code는 접근 방식을 조정합니다. 더 많은 도구 호출, 더 많은 터미널 출력이 이어집니다. 동적 테일은 계속 성장하지만, 이 테일은 이 세션에서 새롭게 생성된 고유한 내용만을 담습니다.

이 시점까지 세션은 총 수백만 토큰을 처리했을 수 있습니다. 하지만 20,000토큰짜리 기반 부분은 매 턴마다 캐시에서 읽혀 왔습니다.

28분: /cost 실행

캐싱이 없다면, 이런 세션은 쉽게 200만 토큰을 넘깁니다. Sonnet 4.5 요금 기준으로 약 $6.00 수준입니다.

하지만 캐싱이 높은 효율로 돌아가고 있다면:

대부분의 토큰은 1M토큰당 $0.30에 캐시에서 읽힙니다.
새롭게 추가되는 동적 테일 토큰만이 새로 계산됩니다.

실제에는 단일 작업 기준으로 80% 이상 비용 절감을 기대할 수 있습니다. 그리고 이런 작업이 모든 사용자, 매일 반복된다고 생각해 보십시오.

정리하자면, 세션이 진행되는 동안 시스템 프롬프트 레이아웃은 다음과 같이 변합니다.

모든 것을 깨뜨리는 규칙

프롬프트 캐싱에서 가장 직관에 반하는 사실이 하나 있습니다.

1 + 2 = 3입니다. 하지만 2 + 1은 캐시 미스입니다.

인프라는 프롬프트를 해시합니다. 이 해시는 암호학적 식별자입니다. 두 요소의 순서가 바뀌었더라도, 똑같은 요소들의 집합이더라도, 그 순서가 달라지면 해시는 완전히 달라집니다. 캐시는 비어 있는 것과 마찬가지가 되고, 프리픽스 전체를 정가로 다시 계산해야 합니다.

여기서 따라 나오는 규칙 세 가지:

세션 도중에 도구를 추가하거나 제거하지 마세요. 캐시된 프리픽스에는 도구들도 포함되어 있습니다. 도구가 바뀌면 그 이후에 나오는 모든 프리픽스 캐시는 쓸모없어집니다.
세션 도중에 모델을 바꾸지 마세요. 캐시는 모델별로 분리됩니다. 대화 중간에 더 저렴한 모델로 바꾸면, 캐시를 처음부터 다시 쌓아야 합니다.
프리픽스를 바꿔 상태를 바꾸려고 하지 마세요. 대신 Claude Code는 다음 사용자 메시지에 “태그”를 달아 시스템에 상기시킵니다. 프리픽스 자체는 절대 건드리지 않습니다.

당신에게 의미하는 것

위에서 설명한 모든 것은, Claude Code가 캐싱을 다루는 방식입니다. 하지만 여러분이 직접 에이전트를 만들 때도 똑같은 규칙이 적용됩니다.

프롬프트를 구성할 때는 이렇게 설계하세요:

맨 위에는 시스템 지침과 규칙을 둡니다. 중간에 바꾸지 않습니다.
필요한 도구들은 처음에 모두 로드합니다. 세션 도중에는 추가하거나 빼지 않습니다.
그다음에는 검색해 온 컨텍스트와 문서를 둡니다. 세션이 진행되는 동안 정적으로 유지됩니다.
맨 아래에는 대화 히스토리와 도구 출력들을 둡니다.

오토 캐싱이 켜져 있으면, 대화가 진행되면서 이 “경계 지점(breakpoint)”이 자동으로 앞으로 이동합니다.

Claude Code는 자체 캐시를 스스로 관리합니다. Anthropic이 이제 API에 오토 캐싱을 추가했기 때문에, 여러분이 만드는 에이전트에서도 똑같이 구현할 수 있습니다.

오토 캐싱이 없던 시절에는, 토큰 경계가 어디까지인지 사람이 직접 기억해야 했습니다. 경계를 잘못 잡으면 캐시에 도달하지 못하게 되었습니다.

캐시-세이프 포크(cache-safe forking)를 사용해, 컨텍스트 제한에 맞춰 압축(compaction)을 수행하세요. 같은 시스템 프롬프트, 같은 도구, 같은 대화를 유지한 채 그 아래에 “압축 지시”를 새로운 메시지로 추가하는 방식입니다.

컴팩션 호출은 바로 직전 호출과 거의 똑같이 생깁니다. 캐시된 프리픽스가 그대로 재사용됩니다. 새로 과금되는 부분은 컴팩션 지시만입니다.

API가 제대로 동작하는지 확인하려면, 각 응답에서 다음 세 필드를 꾸준히 살펴보면 됩니다.

cache_creation_input_tokens: 메모리에 새로 저장된 토큰 수
cache_read_input_tokens: 메모리에서 읽어 온 토큰 수
input_tokens: 일반 방식으로 처리된 입력 토큰 수

캐시 효율 점수는 “읽힌 토큰 수 / 생성된 토큰 수” 비율입니다. 업타임을 모니터링하듯, 이 수치도 꾸준히 관찰해야 합니다.

핵심 정리

프롬프트 캐싱은 단순히 켜고 끄는 기능이 아닙니다. 그 위에 전체 아키텍처를 구축해야 하는 하나의 “규율(discipline)”입니다.

Claude Code는, 이 분야가 대규모로 잘 구현됐을 때 어떤 모습이 되는지를 보여 주는 가장 좋은 사례입니다.

92% 캐시 히트율. 81% 비용 절감.

에이전트를 만드는 사람에게 이것이 바로 청사진입니다. 세금은 피할 수 없습니다. 존재하기 때문입니다. 진짜 중요한 것은, 그 세금을 계속 내고 있을지, 아니면 없애 버릴지를 당신이 선택할 수 있다는 점입니다.