90% 할인은 무엇의 90%인가
프롬프트 캐싱은 반복 입력을 다시 처리하는 비용을 줄인다. 전체 Agent 실행비를 90% 줄여 준다는 뜻은 아니다. 출력, 새 입력, 도구 실행, 재시도와 캐시 생성 비용은 따로 남는다. 답변을 저장해 그대로 돌려주는 응답 캐시와도 다르다.
GPT-6 Astra의 기본 입력은 백만 토큰당 $10, 캐시 읽기는 $1이다. 이 부분만 비교하면 90% 할인이다. Claude Fable 5.1은 $10에서 $0.25로 내려가므로 읽기 단가 차이는 97.5%다. 단, 둘 다 캐시를 만드는 비용이 있다. Astra 가격, Fable 5.1 가격.
Agent에서는 왜 더 중요해지는가
한 번 질문하고 끝나는 채팅과 달리 Agent는 검색, 파일 읽기, 코드 실행, 검수 결과를 다음 호출에 이어 붙인다. 매 호출마다 새 질문만 읽는 것이 아니다. 아직 컨텍스트에 남아 있는 지침, 도구 정의와 이전 결과가 반복 입력이 된다.
다음은 개념 예시다. 실제 요청 구조와 캐시 경계는 공급자마다 다르다.
호출 1 [공통 지침 + 도구] [요청]
호출 2 [공통 지침 + 도구] [요청 + 검색 결과]
호출 3 [공통 지침 + 도구] [요청 + 검색 결과 + 파일 내용]
호출 4 [공통 지침 + 도구] [요청 + 검색 결과 + 파일 내용 + 테스트]
반복되는 앞부분 새로 생긴 뒷부분
캐시가 없으면 같은 자료를 반복 처리한다. 캐시가 있어도 불필요한 검색 결과를 계속 쌓으면 새 입력과 읽기 비용이 커진다. 그래서 자료를 작게 고르는 설계와 캐시 재사용은 함께 해야 한다. 원문 전체 대신 도구가 필요한 필드와 출처를 반환하도록 만드는 것이 첫 번째 개선이다.
Implicit와 Explicit를 구분한다
Implicit는 서비스가 재사용 경계를 찾아주는 방식이다. Explicit는 개발자가 경계나 캐시 객체를 지정하는 방식이다. 자동이라고 적중을 보장하는 것도 아니고, 명시적이라고 이전 답변을 저장하는 것도 아니다.
OpenAI의 GPT-5.6 이후 모델은 두 방식을 지원한다. prompt_cache_options.mode로 선택하며, 명시적 모드는 지원 블록의 prompt_cache_breakpoint로 경계를 정한다. 기본 TTL은 30m, 최소 캐시 길이는 1,024토큰이다. 과거 모델의 prompt_cache_retention 예제를 그대로 옮기지 않는다. OpenAI 캐시 가이드.
Anthropic은 최상위 cache_control로 자동 경계 이동을 켜거나 블록마다 명시적으로 지정한다. 기본 5분과 선택 가능한 1시간 TTL이 있으며, 쓰기 단가는 각각 기본 입력의 1.25배와 2배다. tools → system → messages 순서와 최대 네 경계, 20블록 lookback 조건을 확인해야 한다. Anthropic 캐시 가이드.
Gemini는 지원 모델의 implicit 캐시와 generateContent API의 explicit 캐시 객체를 구분한다. Interactions API에는 explicit 객체가 지원되지 않는다. 명시적 객체는 이름으로 재사용하고 TTL·만료를 관리한다. 보관 시간 요금도 계산해야 한다. 모델별 최소 길이와 가격은 서로 다르다. Gemini 캐시, 캐시 객체 API, 가격표.
언제 캐시가 안 맞는가
여기서는 두 상황을 분리한다. 만료는 재사용할 캐시가 더 이상 유효하지 않은 상황이고, prefix 불일치는 캐시가 남아 있어도 이번 요청의 앞부분이 달라서 못 쓰는 상황이다.
- 앞쪽에 매번 다른 시각·UUID·검색 결과를 넣는다.
- 시스템 지침, 도구 설명·스키마·순서를 바꾼다.
- 과거 메시지를 수정하거나 대화 전체를 새로운 요약으로 교체한다.
- 모델이나 프롬프트에 영향을 주는 설정을 바꾼다.
- 명시적 캐시의 TTL이 끝났거나 객체가 삭제되었다.
- 길이 기준이나 경계 조건을 충족하지 못한다.
OpenAI는 reasoning effort, 출력 스키마와 compaction 등도 관련 설정으로 설명한다. Anthropic은 변경된 지점 이후의 누적 prefix를 다시 확인한다. 따라서 “사용자 질문만 바꿨는데 miss가 났다”면 서버가 실제로 렌더링한 요청부터 비교한다. OpenAI의 영향 설정, Anthropic의 prefix 구조.
개발자가 캐시용 문자열을 안정화한다고 사용자 간 데이터를 섞어서는 안 된다. 공통 규칙과 공개 지식만 공유 가능한 영역에 두고, 고객별 자료와 대화는 권한 경계 안에 둔다.
실무에서 추천하는 배치
아래는 VibeRick의 설계 권장안이다. 특정 SDK의 복사 가능한 요청 예제가 아니라 변경 주기에 따른 분리 기준이다.
- 거의 바뀌지 않는 서비스 지침과 도구 정의.
- 버전이 명확한 지식 자료.
- 해당 고객에게 허용된 업무 맥락.
- 대화 기록과 도구 결과.
- 이번 질문과 이번에만 필요한 입력.
지식 문서를 갱신하면 캐시 버전도 갱신한다. 새 문서를 배포했는데 예전 explicit 객체를 계속 참조하는 문제는 캐시 적중률만 보고는 찾을 수 없다. 자료 버전, 프롬프트 버전, 모델과 실제 응답의 출처를 함께 기록한다.
숫자로 계산해 보기
다음은 100,000토큰짜리 고정 prefix를 열 번 쓰고, 첫 요청에서 한 번 생성한 뒤 아홉 번 모두 적중한다고 가정한 Astra 기본 요율 계산이다. 새 입력·출력·도구·장문 할증은 제외한다.
비교 기준: 캐시 없이 읽기 0.1M × $10 × 10 = $10.00
캐시 쓰기 1회 0.1M × $12.50 = $1.25
캐시 읽기 9회 0.1M × $1 × 9 = $0.90
합계 $2.15
고정 prefix 처리비 감소 78.5%
읽기는 90% 저렴해도 첫 생성까지 포함하면 이 예시의 절감은 78.5%다. 첫 호출만 하고 다시 쓰지 않는다면 오히려 쓰기 비용이 더 든다. 이 차이가 명시적 경계와 재사용 빈도를 고민하는 이유다.
실험은 네 묶음으로 한다
Cold: 새 prefix로 첫 호출. Warm: 같은 prefix로 반복. Changed: 도구·자료·기억을 하나씩 변경. Expired: TTL 이후 다시 호출.
각 묶음에서 입력·출력 토큰, 캐시 읽기·쓰기, 첫 응답 시간과 전체 완료 시간을 남긴다. 같은 질문만 반복하는 테스트는 실제 Agent가 도구 결과를 축적하는 상황을 대신하지 못한다.
task_id / model / prompt_version / corpus_version
input / cached_input / cache_write / output
tool_calls / retries / first_token_ms / completion_ms
검수 통과 여부 / 사람이 고친 내용
공급자의 usage 필드 이름은 그대로 보존하고 분석 단계에서 공통 항목으로 매핑한다. Anthropic의 캐시 생성·읽기, OpenAI의 입력 세부 항목, Gemini의 API별 usage를 같은 필드라고 가정하지 않는다.
결론: 적중률보다 완료된 일
캐싱을 잘한 Agent는 단순히 오래 대화하는 Agent가 아니다. 필요한 맥락을 유지하면서 올바른 도구를 쓰고, 검수 가능한 결과를 끝내는 Agent다. 캐시를 끈 비교군과 품질·지연·총비용을 함께 보자.
다음으로 좋은 Agent의 세 축과 Astra·Fable의 실행 예산을 함께 읽으면 모델 선택과 운영 설계를 연결할 수 있다.