프롬프트 캐싱 원리: AI 코딩 에이전트의 토큰 비용을 줄이는 설계와 캐시를 깨뜨리는 흔한 실수

핵심 메시지

• 프롬프트 캐싱은 LLM의 답변을 저장하는 것이 아니라, 매번 다시 보내는 입력 프롬프트를 저장해 재처리 비용을 깎아주는 장치다.
• 에이전트는 턴이 늘 때마다 이전 대화 전체를 다시 전송하므로, 캐싱이 없으면 세션이 길어질수록 비용이 가파르게 치솟는다.
• 이미 본 토큰은 처음 가격의 10분의 1 수준으로 계산되지만, 자동으로 켜지는 제공자와 직접 켜야 하는 제공자가 갈린다.
• 시스템 프롬프트에 현재 시각이나 작업 디렉터리 같은 값을 넣으면 그 뒤의 캐시가 통째로 무효화된다.
• 캐시 적중률을 눈으로 확인할 수 있는 에이전트 하네스를 쓰는 것이 실질적인 비용 관리의 출발점이다.

쉽게 이해하기

코딩 에이전트와 한참 대화를 나눠 문맥이 5만 토큰까지 쌓인 상태에서 질문을 1천 토큰 더 던지면, 우리는 5만 1천 토큰 전체에 대해 제값을 내게 될까. 영상은 이 질문으로 시작해, 에이전트 하네스가 제대로 만들어졌다면 그렇지 않다고 답한다. 반대로 잘못 만들어졌다면 매 턴 전체 문맥에 대해 정가를 지불하게 되고, 그 비용은 대화가 길어질수록 감당하기 어려워진다.

가장 먼저 바로잡는 것은 캐싱에 대한 오해다. 데이터베이스 캐시를 떠올리면 같은 질문에 저장해둔 답을 돌려주는 그림이 그려지지만, 프롬프트 캐싱은 출력이 아니라 입력을 저장한다. 에이전트는 구조상 대화가 이어질 때마다 지금까지의 전체 기록에 새 내용을 덧붙여 다시 보내고, 모델은 그 전체를 매번 다시 처리한다. 일부 API가 모델이 앞선 대화를 기억하는 것처럼 보이게 감싸줄 뿐, 내부에서 벌어지는 일은 같다.

그래서 요금 체계도 두 갈래로 나뉜다. 모델이 처음 보는 토큰에는 정가가 붙고, 두 번째 이후 똑같이 다시 읽는 토큰에는 훨씬 낮은 가격이 붙는다. 영상에서는 그 폭을 대략 정가의 10퍼센트 수준으로 설명한다. 세션 길이에 따른 비용 곡선을 보면 캐싱이 없을 때는 가파르게 휘어 오르지만, 캐싱이 걸리면 비교적 완만한 직선에 가깝게 유지된다.

실무에서 발목을 잡는 것은 만료 시간과 무효화다. 캐시는 몇 분에서 한 시간 사이에 만료되는데 그 기준이 제공자마다 다르고, 발표자는 점심과 저녁을 먹으러 자리를 비운 사이 캐시가 만료돼 그 지점마다 다시 정가를 낸 자기 세션 기록을 그대로 보여준다. 더 흔한 실수는 시스템 프롬프트에 타임스탬프나 현재 작업 디렉터리처럼 매번 바뀌는 값을 넣는 것으로, 앞부분이 조금이라도 달라지면 그 뒤가 전부 새 입력으로 취급된다.

결론은 단순하다. 시스템 프롬프트와 대화 이력을 도중에 바꾸지 말고 뒤에 덧붙이기만 할 것, 쓰고 있는 제공자의 캐시 만료 시간을 확인할 것, 그리고 캐시 적중률을 표시해주는 하네스를 쓸 것. 발표자는 실제로 1천만 토큰이 넘게 오간 세션의 비용이 몇 센트에 그친 사례를 들어, 같은 작업도 설계에 따라 요금이 전혀 달라진다는 점을 강조한다.

주요 인사이트

• 비용이 커지는 원인은 문맥의 크기 자체가 아니라 같은 문맥을 몇 번 되풀이해 보내는지에 있다. 5만 토큰짜리 세션은 실제로는 5만 토큰이 아니라 매 턴의 누적 합만큼 청구된다.
• 캐싱이 자동으로 켜지는지 여부가 제공자마다 다르다는 점은 특히 주의할 대목이다. 자동으로 처리해주는 곳도 있지만, 직접 요청에 캐싱을 지정해야 하는 곳에서는 아무것도 하지 않으면 할인 자체가 적용되지 않는다.
• 동적인 시스템 프롬프트는 겉보기에 편리한 기능이지만 캐시 관점에서는 비용을 몇 배로 키우는 설계다. 캐시는 프롬프트의 앞부분이 그대로일 때만 이어지므로, 변하는 값은 뒤쪽으로 미뤄야 한다.
• 대화를 요약해 압축하는 컴팩션 역시 캐시를 초기화한다. 이는 고장이 아니라 컴팩션의 정상 동작이지만, 압축 직후 한동안 비용이 다시 올라간다는 사실은 알고 있어야 한다.
• 캐시 적중률은 추측이 아니라 계측의 영역이다. 요청별·세션별 적중률을 보여주는 도구를 쓰면 어느 시점에 캐시가 깨졌는지 사후에 짚어낼 수 있다.

자주 묻는 질문

관련 AI 소식