AI 에이전트 비용을 줄이는 핵심, 프롬프트 캐싱 제대로 이해하기

AI 에이전트는 매 턴마다 비용을 낸다

AI 에이전트를 오래 실행해 본 사람이라면 한 가지 이상한 비용을 보게 된다. 새로 한 일이 많지 않은데도 입력 토큰 비용이 계속 커진다.

이유는 단순하다. 에이전트는 매 요청마다 시스템 지침, 도구 정의, 프로젝트 설명, 이전 대화 맥락을 다시 읽는다. 이미 알고 있는 내용을 반복해서 처리하는 셈이다. 원문에서는 이것을 **컨텍스트 세금(Context Tax)**이라고 표현한다.

예를 들어 20,000토큰짜리 시스템 프롬프트를 50턴 동안 반복해서 처리하면, 새 가치를 만들지 않는 입력 계산만 100만 토큰이 된다. 프롬프트 캐싱은 바로 이 낭비를 줄이기 위한 기술이다.

캐싱의 핵심은 “변하지 않는 부분”을 고정하는 것

에이전트의 입력은 크게 두 부분으로 나눌 수 있다.

첫째는 **정적 접두사(Static Prefix)**다. 시스템 지침, 도구 목록, 프로젝트 규칙, 코드베이스 설명처럼 세션 중 거의 변하지 않는 내용이다.

둘째는 **동적 꼬리(Dynamic Tail)**다. 사용자의 새 요청, 도구 실행 결과, 터미널 출력, 대화 기록처럼 매 턴 바뀌는 내용이다.

프롬프트 캐싱은 정적 접두사를 한 번 계산한 뒤, 다음 요청부터는 다시 계산하지 않고 캐시에서 읽어 오는 방식이다. 즉, 매번 같은 부분을 새로 처리하지 않도록 만드는 구조다.

KV 캐싱은 왜 효과적인가

LLM 추론은 크게 두 단계로 진행된다.

프리필(Prefill) 단계에서는 모델이 전체 입력 프롬프트를 읽고 내부 표현을 만든다. 긴 컨텍스트를 처리할수록 이 단계가 비싸고 느려진다.

디코드(Decode) 단계에서는 출력 토큰을 하나씩 생성한다. 이미 계산된 상태를 활용하면서 다음 토큰을 만들어 내는 과정이다.

트랜스포머는 입력 토큰마다 Query, Key, Value 벡터를 만든다. 여기서 Key와 Value는 앞선 토큰들에 의해 결정되므로, 같은 접두사라면 다시 계산할 필요가 없다. 이것을 저장해 두었다가 재사용하는 것이 KV 캐싱의 핵심이다.

캐시가 없으면 요청이 끝날 때마다 이 값들이 사라지고, 다음 요청에서 같은 20,000토큰을 다시 계산해야 한다. 캐시가 있으면 동일한 접두사를 해시로 확인한 뒤, 저장된 값을 바로 불러와 계산량을 크게 줄일 수 있다.

비용 구조도 캐싱 중심으로 달라진다

Anthropic의 캐시 가격 정책에서 중요한 숫자는 세 가지다.

핵심은 분명하다. 처음 캐시를 만들 때는 비용이 들지만, 이후 같은 접두사를 계속 읽으면 비용이 크게 줄어든다. 그래서 중요한 지표는 단순 토큰 수가 아니라 캐시 적중률이다.

Claude Code가 캐시를 잘 활용하는 방식

Claude Code의 세션을 예로 보면 구조가 더 잘 보인다.

세션이 시작되면 Claude Code는 시스템 프롬프트, 도구 정의, 프로젝트의 CLAUDE.md 같은 문서를 읽는다. 이 초기 입력은 20,000토큰을 넘기 쉽다. 가장 비싼 순간이지만, 제대로 캐시되면 이 비용은 한 번만 크게 발생한다.

이후 사용자가 “인증 모듈을 보고 개선점을 찾아줘” 같은 요청을 하면 에이전트는 파일을 읽고, 검색하고, 도구를 실행한다. 이때 새로 생긴 결과만 동적 꼬리에 붙는다. 정적 접두사는 캐시에서 읽힌다.

계획 단계에서도 마찬가지다. 탐색 결과 전체를 그대로 넘기기보다 요약해서 전달하면 동적 꼬리가 과도하게 커지지 않는다. 이렇게 하면 세션이 길어져도 캐시 효율을 유지할 수 있다.

캐시를 깨뜨리는 가장 쉬운 실수

프롬프트 캐싱에서 가장 조심해야 할 점은 순서다.

같은 내용이라도 순서가 바뀌면 해시가 달라진다. 해시가 달라지면 캐시가 맞지 않는다. 결국 전체 접두사를 다시 계산해야 한다.

그래서 에이전트를 만들 때는 세 가지를 지켜야 한다.

1. 세션 중 도구 목록을 함부로 바꾸지 않는다.
2. 중간에 모델을 바꾸지 않는다.
3. 상태를 바꾸기 위해 시스템 프롬프트를 수정하지 않는다.

상태 변경이 필요하다면 시스템 프롬프트를 고치는 대신, 새 사용자 메시지나 별도 메모 형태로 추가하는 편이 안전하다.

실무자를 위한 프롬프트 구조

자체 에이전트를 만든다면 입력 구조를 이렇게 잡는 것이 좋다.

1. 시스템 지침과 규칙
2. 사용할 도구 목록
3. 고정 문서와 프로젝트 컨텍스트
4. 대화 기록과 도구 실행 결과

위쪽은 가능한 한 고정하고, 아래쪽만 계속 바뀌게 만들어야 한다. 그래야 캐시가 오래 유지되고, 비용도 예측 가능해진다.

확인해야 할 세 가지 지표

프롬프트 캐싱이 실제로 잘 작동하는지는 다음 값을 보면 된다.

• cache_creation_input_tokens: 새로 캐시에 저장된 토큰 수
• cache_read_input_tokens: 캐시에서 읽은 토큰 수
• input_tokens: 일반 입력으로 처리된 토큰 수

좋은 에이전트 구조라면 시간이 갈수록 캐시 읽기 비중이 커져야 한다. 반대로 매번 캐시 생성만 반복된다면 프롬프트 구조가 흔들리고 있다는 뜻이다.

정리

프롬프트 캐싱은 단순히 켜는 기능이 아니다. 에이전트 구조를 어떻게 설계하느냐의 문제다.

시스템 프롬프트와 도구 정의를 안정적으로 유지하고, 새로 바뀌는 정보만 뒤에 붙이는 구조를 만들면 긴 세션에서도 비용을 크게 줄일 수 있다. Claude Code의 높은 캐시 적중률은 우연이 아니라, 이런 구조적 설계의 결과다.

AI 에이전트를 제품 수준으로 운영하려면 이제 “답을 잘 내는가”만 볼 것이 아니라, 같은 컨텍스트를 매번 다시 계산하고 있지는 않은가까지 봐야 한다.

원문: “Prompt caching, clearly explained” — Akshay (@akshay_pachaar)