Anthropic, 프롬프트 캐시 TTL을 1시간에서 5분으로 조용히 축소 — API 비용에 미치는 영향은?

무슨 일이 있었나요?

Claude API를 사용하는 개발자들에게 꽤 중요한 변경사항이 하나 발견됐어요. Anthropic이 지난 3월 6일에 프롬프트 캐시(Prompt Cache)의 TTL(Time To Live)을 기존 1시간에서 5분으로 대폭 줄였다는 건데요, 문제는 이 변경에 대한 공식적인 사전 공지가 없었다는 거예요. GitHub 이슈를 통해 사용자들이 직접 발견하고 제보한 상황이에요.

프롬프트 캐시가 뭔지부터 설명할게요. LLM API를 호출할 때 매번 긴 시스템 프롬프트나 컨텍스트를 함께 보내잖아요. 프롬프트 캐시는 이렇게 반복적으로 보내는 내용을 서버 측에서 캐싱해두는 기능이에요. 쉽게 말하면, 같은 말을 매번 처음부터 다시 읽는 대신 "아, 이건 아까 읽은 거랑 같네"하고 넘어가는 거죠. 이렇게 하면 처리해야 할 토큰 수가 줄어들어서 비용이 절감되고 응답 속도도 빨라져요.

1시간에서 5분으로, 왜 이게 큰 차이인가

TTL이 1시간이었을 때는, 한 번 캐싱된 프롬프트가 이후 1시간 동안의 모든 API 호출에서 재사용됐어요. 사용자가 채팅을 하면서 잠깐 다른 일을 하다가 돌아와도, 캐시가 살아있으니 비용 효율적이었죠.

그런데 TTL이 5분으로 줄어들면 상황이 많이 달라져요. 5분 안에 다음 요청이 오지 않으면 캐시가 만료되고, 다시 전체 프롬프트를 처음부터 처리해야 하거든요. 이건 특히 다음과 같은 사용 패턴에서 비용 차이가 크게 나요.

코딩 어시스턴트처럼 긴 시스템 프롬프트와 대량의 코드 컨텍스트를 사용하는 경우를 생각해보세요. 개발자가 코드를 작성하다가, 생각을 좀 하고, 다시 질문을 던지는 패턴에서 그 간격이 5분을 넘기는 건 아주 흔한 일이에요. 이전에는 캐시 덕분에 비용이 크게 절감됐지만, 이제는 매번 풀 프롬프트 비용이 청구될 수 있는 거예요.

실제로 Claude Code 같은 도구를 사용하는 개발자들 사이에서 "갑자기 API 비용이 눈에 띄게 올라갔다"는 보고가 나오기 시작한 것도 이 변경과 관련이 있어 보여요.

기술적으로 좀 더 들여다보면

캐시 TTL을 줄이는 건 Anthropic 입장에서도 이유가 있을 거예요. 캐시를 오래 유지하려면 그만큼 서버의 메모리(GPU 메모리 포함)를 점유해야 하거든요. 사용자가 늘어나면 캐시 유지 비용도 비례해서 올라가니까, 인프라 효율성 차원에서 내린 결정일 가능성이 높아요.

하지만 문제는 커뮤니케이션 방식이에요. API의 가격이나 동작 방식이 바뀌면, 그걸 기반으로 비용을 설계한 고객들에게 사전 공지를 하는 게 당연한 건데, 이번에는 그 과정이 생략된 거예요. 이건 API 제공자와 소비자 사이의 신뢰 문제와 직결되는 부분이에요.

OpenAI의 경우에도 모델 deprecation이나 가격 변경을 사전에 공지하는 정책을 갖고 있고, Google의 Gemini API도 마찬가지예요. API 경제에서 예측 가능한 변경 관리는 기본 중의 기본이거든요.

업계 맥락에서 보면

이 이슈는 LLM API 시장의 더 큰 흐름과도 맞닿아 있어요. 프롬프트 캐싱은 비용 절감의 핵심 전략 중 하나인데, 각 제공자마다 구현 방식이 달라요. OpenAI도 자체적인 프롬프트 캐싱을 제공하고 있고, Google의 Gemini는 Context Caching이라는 이름으로 비슷한 기능을 제공해요. 이런 캐싱 기능의 조건과 한계를 정확히 이해하는 게 API 비용 관리의 핵심이에요.

특히 LLM 기반 서비스를 SaaS로 제공하는 입장에서는, 이런 "조용한 변경"이 수익 모델을 흔들 수 있어요. API 비용을 기반으로 가격을 책정했는데, 하루아침에 비용 구조가 바뀌면 마진이 한순간에 증발할 수 있으니까요.

한국 개발자에게 주는 시사점

국내에서도 Claude API를 활용한 서비스나 도구를 개발하는 팀이 빠르게 늘고 있는데요, 이번 사례에서 얻을 수 있는 실무적 교훈이 몇 가지 있어요.

첫째, API 비용 모니터링을 반드시 해야 해요. 대시보드에서 일별, 주별 비용 추이를 확인하는 습관을 들이세요. 이번처럼 공지 없는 변경이 생겼을 때 빨리 감지할 수 있거든요.

둘째, 단일 API 제공자에 대한 의존도를 줄이는 아키텍처를 고려해보세요. LiteLLM 같은 프록시 도구를 사용하면, 백엔드를 OpenAI에서 Anthropic으로, 혹은 그 반대로 비교적 쉽게 전환할 수 있어요. 프롬프트 캐시 조건까지 고려한 비용 최적화 전략이 점점 더 중요해지고 있어요.

정리하면

API 제공자의 "조용한 변경"은 언제든 일어날 수 있고, 그 영향은 생각보다 클 수 있어요. 여러분은 사용 중인 LLM API의 비용 구조를 얼마나 자주 확인하고 계신가요? 프롬프트 캐시에 의존하는 비용 설계를 하고 있다면, 캐시 조건이 바뀌었을 때의 플랜 B는 있으신가요?