🧠 Claude Code가 밝힌 비밀: AI 에이전트 비용, 프롬프트 캐싱이 전부다

 

"나 API 비용 너무 많이 나와요" — 이 말, 이제 안 해도 됩니다

AI 코딩 도구를 쓰다 보면 어느 순간 청구서를 보고 깜짝 놀라는 경험, 다들 한 번쯤 하셨을 거예요.

단순히 "많이 쓰면 비싸다"는 건 아는데, 왜 이렇게 토큰이 많이 빠져나가는지 이유를 몰라서 답답하셨던 분들이 많을 거라고 생각해요. 저도 처음엔 그랬거든요.

최근 앤트로픽(Anthropic)의 Claude Code 팀이 실제 제품을 만들면서 얻은 핵심 교훈을 공개했는데요, 결론은 딱 하나였어요.

"프롬프트 캐싱이 전부다(Prompt Caching is Everything)."

힙합 명곡 가사를 패러디한 이 한 문장에, 2026년 AI 에이전트 제품을 만드는 사람이라면 반드시 알아야 할 핵심이 담겨 있습니다. 오늘 이 내용을 제대로 파헤쳐 볼게요.

프롬프트 캐싱, 그게 정확히 뭔가요?

프롬프트 캐싱은 쉽게 말해서 "이미 계산한 건 다시 계산하지 말자"는 개념이에요.

AI 모델에게 메시지를 보낼 때마다, 시스템 프롬프트부터 대화 기록까지 모든 내용을 처음부터 다시 처리합니다. 문제는 Claude Code 같은 장시간 에이전트는 이 과정이 수십에서 수백 번씩 반복된다는 거예요. 매번 수천 개의 토큰을 새로 계산하면 비용과 시간이 폭발적으로 늘어납니다.

프롬프트 캐싱을 사용하면 이전에 처리한 내용을 서버에 저장해 두고, 다음 요청에서 그대로 재사용하는 거예요. 앤트로픽의 경우 캐시 읽기 비용은 기본 처리 비용의 10% 수준, 즉 비용을 최대 90%까지 줄일 수 있고, 응답 속도도 최대 85%까지 빨라집니다.

단순한 최적화 기법이 아니라, Claude Code라는 제품 자체를 가능하게 한 핵심 기술이라는 점이 이번 공개의 핵심이에요.

많은 분들이 모르는 캐시의 작동 원리

프롬프트 캐싱은 접두사(Prefix) 매칭 방식으로 작동해요. 요청의 시작 부분부터 특정 체크포인트까지의 내용을 통째로 캐싱해두는 방식이거든요.

핵심 법칙은 하나예요. 정적 콘텐츠는 앞에, 동적 콘텐츠는 뒤에.

Claude Code는 실제로 이런 순서로 콘텐츠를 배치합니다. 제일 앞에는 자주 안 바뀌는 시스템 프롬프트와 도구 정의가 오고, 그다음에 Claude.md 파일, 세션 컨텍스트, 마지막으로 실제 대화 메시지가 오는 구조예요.

이 순서가 무너지는 순간 캐시는 박살납니다. 예를 들어 시스템 프롬프트 안에 현재 시각을 분 단위로 넣거나, 도구 목록을 요청마다 랜덤 순서로 보내면 매번 캐시 미스가 발생해서 비용이 폭발하는 거죠.

도커의 레이어 캐싱과 정확히 같은 원리예요. 자주 변하는 레이어는 뒤에, 잘 안 바뀌는 건 앞에 배치하는 것처럼요.

사람들이 가장 많이 저지르는 캐시 파괴 실수 3가지

여기서부터가 실무적으로 가장 중요한 내용입니다.

첫 번째 실수는 시스템 프롬프트를 직접 업데이트하는 거예요. 날짜가 바뀌거나 사용자가 파일을 수정했을 때, 직관적으로는 시스템 프롬프트 안의 정보를 갱신하고 싶어지잖아요. 하지만 그렇게 하면 캐시 전체가 무효화됩니다.

Claude Code의 해결책은 다음 대화 턴에서 메시지로 전달하는 방식이에요. 예를 들어 다음 user 메시지에 system-reminder 형태로 "오늘은 수요일입니다"라고 넣어주면, 캐시를 건드리지 않고 정보를 업데이트할 수 있어요.

두 번째 실수는 도구 집합을 변경하는 거예요. 도구 추가나 삭제는 캐시 무효화의 가장 흔한 원인 중 하나입니다. Claude Code의 Plan Mode가 대표 사례인데요, 직관적인 구현이었다면 플랜 모드 진입 시 읽기 전용 도구만 남겼겠지만, 그렇게 하면 도구 목록이 바뀌면서 캐시가 파괴됩니다. 실제 설계는 EnterPlanMode와 ExitPlanMode를 도구로 구현해서 도구 목록은 그대로 두고 상태 전환만 메시지로 처리하는 방식이었어요.

세 번째 실수는 세션 중간에 모델을 바꾸는 거예요. 프롬프트 캐시는 모델별로 독립적입니다. Opus로 10만 토큰짜리 대화를 진행하다가 간단한 질문 하나를 위해 Haiku로 전환하면, Haiku 입장에서는 캐시가 전혀 없어서 처음부터 다시 구축해야 해요. 결과적으로 Opus로 그냥 답하는 것보다 비용이 더 높아지는 역설이 생깁니다.

MCP 도구 많을 때는 어떻게 하나요? 지연 로딩 전략

Claude Code에는 수십 개의 MCP 도구가 연결될 수 있어요. 이걸 다 포함하면 비용이 높아지고, 그렇다고 제거하면 캐시가 깨지는 딜레마가 생깁니다.

해결책은 지연 로딩(defer_loading)이에요. 도구를 아예 제거하는 대신, 이름만 포함된 경량 스텁 형태로 보내두는 거예요. 모델이 실제로 그 도구가 필요할 때 ToolSearch 도구를 통해 전체 스키마를 로드합니다.

항상 같은 순서로 같은 스텁이 들어가기 때문에 캐시 접두사가 안정적으로 유지돼요. 이 원리 덕분에 도구 목록이 아무리 많아도 캐시를 유지하면서 운영할 수 있는 거죠.

컨텍스트 요약도 캐시를 고려해야 합니다

장시간 에이전트를 운영하다 보면 컨텍스트 윈도우가 꽉 차는 순간이 와요. 이때 대화를 요약해서 새 세션을 시작하는 컴팩션 작업을 하게 되는데, 이것도 함정이 있어요.

일반적으로 떠올리는 방식은 별도 API 호출로 요약을 생성하는 거예요. 하지만 이렇게 하면 부모 대화의 캐시 접두사와 전혀 일치하지 않아서, 요약 과정에서 모든 토큰을 처음부터 처리하는 비용이 발생합니다.

Claude Code의 해결책은 컴팩션 시에도 부모 대화와 동일한 시스템 프롬프트와 도구 정의를 사용하는 거예요. API 입장에서는 이 요청이 직전 요청과 거의 동일하게 보여서 캐시를 재사용할 수 있게 되는 원리예요. 앤트로픽은 이 패턴을 아예 API에 내장시켜서 개발자들이 편하게 쓸 수 있도록 했다고 해요.

캐시 적중률은 서버 업타임처럼 관리해야 합니다

이 부분이 가장 인상적이었어요. Claude Code 팀은 캐시 적중률을 서버 업타임처럼 중요한 지표로 취급한다고 합니다.

캐시 적중률이 몇 퍼센트 떨어지는 것도 인시던트로 취급한다고 해요. 이유는 간단합니다. 모든 입력 토큰이 캐시 미스 상태로 처리되면 비용이 10배 가까이 뛰거든요.

2026년 현재 AI 에이전트 비용 구조를 살펴보면, Anthropic Sonnet 기준으로 입력 토큰 100만 개당 3달러인데, 캐시 읽기는 10%인 0.30달러에 불과해요. 하루에 수천 건의 에이전트 작업을 처리하는 서비스라면 이 차이가 어마어마하게 커지죠.

캐시 미스율 1%는 단순한 숫자가 아닙니다. 수백만 건의 요청이 누적될 때는 엄청난 비용 차이로 이어지는 비즈니스 지표예요. 그래서 캐시 적중률을 제품의 핵심 KPI로 관리해야 하는 거죠.

AI 에이전트 시장, 이 원칙 모르면 청구서에 울게 됩니다

이 내용이 중요한 이유는 단순히 Claude Code에만 해당하는 이야기가 아니기 때문이에요. AI 에이전트를 운영하는 모든 서비스에 적용되는 보편적인 설계 원칙이거든요.

2026년 현재 AI 에이전트 시장이 본격적으로 열리면서, 이 비용 구조를 모르고 시작한 팀들은 예상치 못한 청구서에 놀라는 경우가 늘고 있어요. 반대로 이 원칙을 처음부터 설계에 녹인 팀은 경쟁사보다 훨씬 낮은 운영 비용으로 제품을 운영할 수 있습니다.

"프롬프트 엔지니어링"을 넘어 "컨텍스트 엔지니어링"으로의 전환, 그리고 그 중심에 캐싱이 있다는 메시지는 앞으로 AI 제품을 만드는 모든 사람에게 필수 교양이 될 거예요. 첫날부터 캐싱을 고려하지 않으면, 나중에 제품 전체를 다시 뜯어고쳐야 하는 상황이 올 수도 있습니다.

AI 에이전트를 직접 만들고 있다면, 지금 당장 캐시 적중률부터 확인해 보세요. 그 숫자가 여러분 제품의 생존 가능성을 결정할 수도 있으니까요.

마무리

AI 에이전트 비용은 "많이 쓰면 비싸다"는 단순한 구조가 아니에요. 프롬프트 캐싱을 제대로 설계하지 않으면, 같은 작업량에서도 10배까지 비용이 벌어질 수 있어요. 정적인 것은 앞에, 동적인 것은 뒤에. 도구와 모델은 세션 중에 바꾸지 마세요. 상태 전환은 메시지로 모델링하고, 캐시 적중률을 비즈니스 지표로 관리하는 것. 이 원칙들을 처음 설계할 때부터 녹여 넣으면 경쟁사보다 훨씬 낮은 비용으로 AI 에이전트 서비스를 운영할 수 있습니다.