에이전트 하나가 사용자와 6턴을 주고받았다고 해보죠. 시스템 프롬프트, 도구 정의, 스키마는 매 턴마다 똑같습니다. 바뀌는 건 사용자의 마지막 메시지나 에이전트가 방금 받은 도구 실행 결과뿐입니다. 그런데도 이 똑같은 앞부분을, 여섯 번 다 풀 가격으로 결제하고 있었다면 어떨까요.

여러 AI 모델을 하나의 API로 중개하는 서비스 OpenRouter가 이 문제를 다룬 글을 냈습니다. 프롬프트 캐싱이 정확히 얼마를 아껴주는지, 왜 캐시를 켰는데도 가끔 효과가 없는지를 짚은 내용이죠. 에이전트를 API로 직접 붙여 쓰는 사람이라면 청구서에서 놓치기 쉬운 지점을 담고 있습니다.

출처: OpenRouter Prompt Caching: What Cached Tokens Cost – OpenRouter

캐시를 읽는 건 싸지만, 캐시를 쓰는 건 오히려 비싸다

에이전트가 매 턴 반복해서 보내는 부분은 대개 프롬프트에서 가장 비싼 부분입니다. 긴 시스템 프롬프트, 도구 정의, JSON 스키마, 가드레일, 참고 문서 같은 것들이죠. 캐싱이 없으면 매 턴마다 이 전체를 다시 풀 가격으로 계산합니다. 프롬프트 캐싱은 이 반복되는 앞부분을 공급자 서버에 저장해두고, 다음 턴부터는 훨씬 싼 값에 다시 읽어오는 방식입니다.

여기서 눈여겨볼 지점이 하나 있습니다. 캐시를 “읽는” 값과 “쓰는” 값이 다르다는 것. 앤트로픽의 클로드 소네트 4.6 기준으로 캐시 읽기는 100만 토큰당 0.3달러, 일반 입력값 3달러의 딱 10분의 1이죠. 문제는 쓰기 쪽입니다. 5분짜리 캐시를 처음 만들 때는 입력값의 1.25배, 1시간짜리로 만들면 2배를 냅니다. 즉 한 번 캐시를 써놓고 그걸 다시 읽어보지도 못하고 끝난다면, 캐싱을 아예 안 쓴 것보다 오히려 더 비싸게 낸 셈인 겁니다.

그래서 캐싱이 이득이 되려면 조건이 하나 붙습니다. 같은 내용을 몇 번은 다시 읽어야 쓰기 비용을 회수한다는 것. 한 번 묻고 끝나는 질문이라면 캐싱은 별 도움이 안 되죠. 반면 여러 턴을 이어가는 에이전트라면 이야기가 다릅니다. 같은 지시문과 도구, 정책을 세션 내내 반복해서 들고 다니는 구조이니, 몇 턴만 지나면 처음 낸 캐시 비용은 금방 회수되는 겁니다.

캐시를 만들어놨는데도 다음 요청이 다른 곳으로 간다면

캐시가 도움이 되려면 조건이 하나 더 있습니다. 다음 요청이 캐시를 저장해둔 바로 그 서버로 다시 가야 한다는 것.

OpenRouter처럼 70곳이 넘는 공급자에 요청을 나눠 보내는 구조에서는 이 조건이 자주 깨집니다. 첫 턴에서 캐시를 A라는 공급자 서버에 써놨는데, 두 번째 턴이 B라는 다른 서버로 가버리면 그 서버엔 읽어올 캐시가 없죠. 요청 자체는 정상적으로 처리되지만, 결제는 풀 가격으로 나갑니다.

원인은 대화를 식별하는 방식에 있습니다. 시스템에서는 보통 대화의 첫 메시지들을 기준으로 삼아 같은 대화인지 판단하는데, 에이전트는 이 첫 메시지를 자꾸 바꾸죠. 상태를 요약해서 새로 쓰거나, 도구 실행 결과 순서를 바꾸거나, 새 메타데이터를 끼워 넣는 식입니다. 첫 메시지가 달라지면 시스템은 이걸 다른 대화로 인식하고, 결국 다른 서버로 보내버리는 것.

이 문제를 풀려고 나온 접근이 세션을 고정하는 방식입니다. 후속 요청을 캐시가 남아있는 서버로 계속 붙잡아두고, 대화 자체에 고유한 식별자를 달아서 첫 요청부터 이 고정이 걸리게 만드는 것. 다만 이런 장치가 있어도 첫 메시지가 계속 바뀌는 구조라면 완전히 막지는 못합니다.

청구서에서 확인해야 할 숫자

API 응답의 사용량 정보를 보면 캐시에서 실제로 읽어온 토큰 수가 따로 찍힙니다. 이 숫자가 0에 가깝다면 캐싱이 이름만 켜져 있을 뿐 실제로는 작동하지 않고 있다는 뜻이죠. 원인은 대개 넷 중 하나입니다. 프롬프트 자체가 캐싱하기엔 너무 짧거나, 캐시가 이미 만료됐거나, 앞부분이 매번 바뀌고 있거나, 아니면 요청이 다른 공급자로 넘어간 경우.

프롬프트 캐싱은 켜두기만 하면 자동으로 돈이 굳는 기능이 아닙니다. 같은 내용이 몇 번이나 재사용되는지, 그리고 그 재사용이 실제로 같은 서버에서 일어나는지에 따라 득이 될 수도, 오히려 손해가 될 수도 있는 구조죠. 에이전트를 API로 직접 굴리고 있다면, 캐시 적중률을 청구서에서 한 번쯤 확인해볼 이유가 여기에 있습니다.