프롬프트 캐싱, 붙이고 나서야 비용보다 지연시간이 먼저 보였다

토큰값 아끼는 기능이라고만 보면 반밖에 못 본다

프롬프트 캐싱 얘기 나오면 보통 비용 절감부터 떠올리게 된다. 나도 그랬다. 근데 실제로 문서를 읽고 구조를 짜보면, 먼저 와닿는 건 속도 쪽이다. 시스템 프롬프트가 길고, 공통 컨텍스트가 크고, 대화가 누적되는 서비스일수록 매번 같은 덩어리를 다시 계산하는 게 꽤 아깝다. 캐시가 한 번 제대로 붙으면 체감이 바로 온다.

Anthropic 문서도 이 점을 꽤 분명하게 설명한다. 반복되는 프롬프트 접두부를 특정 지점에서 재사용하게 만들면 처리 시간과 비용을 둘 다 줄일 수 있다는 얘기다. 말은 단순한데, 실제 운영에서는 고객사 정책 문서나 길어진 시스템 지침, 제품 매뉴얼 같은 게 계속 앞에 붙기 때문에 생각보다 효과가 크다.

자동 캐싱이 편한데, 무조건 정답은 아니다

캐싱 방식도 두 가지다. 자동으로 마지막 캐시 가능한 블록을 따라가게 두는 방식, 그리고 블록마다 직접 기준점을 찍는 방식. 처음에는 자동이 편하다. 멀티턴 대화에서 히스토리가 자라날수록 시스템이 알아서 캐시 지점을 앞으로 밀어주니까 구현 부담이 적다. 프로토타입 단계라면 거의 이걸로 시작해도 된다.

다만 조금만 복잡해지면 얘기가 달라진다. 어떤 블록은 반드시 캐시하고 싶고, 어떤 블록은 매번 새로 평가되어야 할 때가 있다. 예를 들어 보안 지침은 고정인데 사용자의 최근 입력은 민감하고 짧게 변한다면, 둘을 한 덩어리로 묶는 순간 효율이 애매해진다. 해봤더니 캐시는 기능이 아니라 설계 문제더라. 프롬프트를 어떻게 쪼개느냐가 더 중요했다.

가격표를 보면 더 현실적으로 보인다

Anthropic 가격표를 보면 기본 입력, 캐시 쓰기, 캐시 히트, 출력 토큰이 따로 나뉘어 있다. 이걸 보면 감이 온다. 무조건 캐시가 공짜가 아니라, 잘 맞는 구간에 써야 이득이다. 특히 긴 프롬프트를 반복적으로 쓰는 워크로드에서는 히트 비용이 확실히 낮아지니까 누적 효과가 나온다. 반대로 매 요청마다 프롬프트 구조가 크게 바뀌면, 기대만큼 절약이 안 될 수도 있다.

그래서 나는 캐싱을 “비용 최적화 옵션”이라기보다 “반복 문맥을 다루는 아키텍처”로 보는 쪽이 맞다고 본다. 제품 문서, 팀 규칙, 거대한 few-shot 예시를 매번 앞에 붙이는 서비스라면 고민할 가치가 충분하다. 반면 짧은 단발성 질의가 대부분이라면 손이 더 가는 만큼 이득이 작을 수도 있다.

이럴 때는 진짜 체감된다

긴 시스템 프롬프트를 자주 쓰는 챗봇, 같은 문서 세트를 붙이는 사내 도우미, 혹은 역할이 고정된 업무 에이전트는 효과를 보기 좋다. 특히 지연시간이 민감한 화면에서는 첫 응답이 조금이라도 빨라지는 게 꽤 크게 느껴진다. 사용자는 토큰 가격보다 답이 빨리 오는 걸 먼저 기억하니까.

솔직히 단점도 있다. 캐시가 붙었다고 해서 프롬프트 설계가 자동으로 좋아지는 건 아니다. 오히려 지저분한 구조를 그대로 고정시켜버릴 위험도 있다. 그래도 문맥이 반복되는 제품이라면 한 번쯤 붙여볼 만하다. 나도 비용 계산보다 응답 감각이 먼저 달라져서 좀 놀랐다.

---

📎 참고 자료

• Anthropic Prompt Caching
• Anthropic Pricing