프롬프트 캐싱

프롬프트 캐싱(Prompt Caching)은 여러 요청에 공통으로 들어가는 프롬프트 앞부분을 서버가 잠시 보관했다가 다시 사용해, 반복 입력의 처리 시간과 비용을 줄이는 기능입니다. 같은 규칙과 자료를 계속 보내는 AI 서비스에서 특히 유용합니다.

무엇을 저장하고 다시 사용하는가

프롬프트 캐싱은 완성된 답변 대신 입력의 앞부분을 저장합니다. 도구 정의, 시스템 지침, 참고 문서, 이전 대화처럼 요청 앞쪽에 놓인 입력을 지정된 지점까지 하나의 접두부로 보고 재사용합니다. Anthropic의 프롬프트 캐싱 문서에 따르면 Claude API는 새 요청의 접두부가 최근 요청과 일치하는지 확인합니다. 일치하면 캐시된 접두부를 재사용하고, 다르면 입력을 처리한 뒤 응답 생성이 시작될 때 새 캐시를 만듭니다.

자동 캐싱을 사용하면 요청 최상단에 cache_control을 한 번 두고, 시스템이 마지막으로 캐시할 수 있는 블록을 기준점으로 삼게 할 수 있습니다. 명시적 기준점을 각 콘텐츠 블록에 붙이면 개발자가 범위를 더 세밀하게 정합니다. 어느 방식을 택해도 자주 바뀌지 않는 내용을 앞에 놓는 구성이 중요합니다. 날짜, 사용자 질문, 매번 달라지는 검색 결과가 접두부 안에서 바뀌면 그 지점 뒤는 같은 캐시로 읽기 어렵습니다.

기본 유효 시간은 5분이며, 필요하면 1시간을 선택할 수 있습니다. 유효 시간은 캐시를 쓰거나 읽는 요청이 시작된 때부터 셉니다. 응답 생성에 걸린 시간도 이 기간에 포함됩니다. 캐시에 없는 접두부는 캐시 쓰기 입력으로, 적중한 접두부는 캐시 읽기 입력으로 집계됩니다. 1시간 항목의 쓰기 단가는 5분 항목보다 높으며, 구체적인 요율은 모델과 플랫폼에 따라 달라지므로 운영 전에는 현재 가격 문서를 함께 확인해야 합니다.

응답 캐시와 컨텍스트 압축은 어떻게 다른가

응답 캐시는 같은 요청에 미리 만들어 둔 완성 답변을 그대로 돌려주는 방식입니다. 프롬프트 캐싱은 입력 접두부의 처리를 재사용할 뿐, 모델은 새로 들어온 질문과 뒤쪽 컨텍스트를 바탕으로 답변을 다시 생성합니다. 그래서 앞부분이 같더라도 사용자 질문이 달라지면 출력도 달라질 수 있습니다. 최신 재고처럼 매번 결과를 새로 계산해야 하지만 긴 운영 규칙은 그대로인 챗봇이라면 응답 캐시보다 프롬프트 캐싱이 잘 맞습니다.

컨텍스트 압축은 오래된 대화나 도구 결과를 요약하거나 덜어내 실제 입력 토큰 수를 줄입니다. 프롬프트 캐싱은 접두부를 계속 컨텍스트에 넣은 채 처리 비용의 종류를 바꿉니다. Anthropic의 컨텍스트 윈도우 설명도 캐시에서 읽은 토큰이 컨텍스트 윈도우를 계속 차지한다고 밝힙니다. 긴 대화가 한도에 가까워지는 문제는 캐싱만으로 해결되지 않으며, 필요한 경우 서버 측 압축이나 오래된 도구 결과 정리를 함께 설계해야 합니다.

과금 기록에서도 차이가 드러납니다. Claude API의 사용량에는 일반 입력, 캐시 생성 입력, 캐시 읽기 입력이 나뉘어 표시됩니다. 캐시 적중 뒤에도 해당 토큰은 입력에 남고, 첫 요청이나 접두부가 바뀐 요청에는 캐시 쓰기가 생길 수 있습니다. 그래서 전체 입력 토큰만 비교하기보다 cache_read_input_tokens와 cache_creation_input_tokens가 어떤 요청에서 늘었는지 살펴야 합니다.

실무에서는 어디에 적용하는가

고객 지원 서비스가 매번 같은 환불 규정과 답변 원칙을 보내고, 끝에 고객 문의만 붙인다고 가정해 보겠습니다. 규정과 원칙을 앞에 고정하고 그 끝을 캐시 기준점으로 잡으면 후속 문의가 같은 접두부를 재사용할 수 있습니다. 반대로 고객 이름이나 주문 내역을 규정 앞에 넣으면 사람마다 접두부가 달라져 적중률이 떨어집니다. 공통 자료, 사용자별 자료, 현재 질문 순서로 놓으면 재사용 범위를 알아보기 쉽습니다.

문서 질의 서비스도 좋은 사례입니다. 한 보고서를 두고 요약, 위험 요인 추출, 표 검토를 연달아 요청할 때 보고서와 공통 지침을 먼저 두고 질문만 바꿀 수 있습니다. 다만 보고서가 편집되면 변경 지점 뒤의 캐시는 다시 만들어질 수 있습니다. 캐시 여부와 상관없이 모델이 참고해야 할 문서는 요청에 포함되므로, 민감한 자료의 전송·보관 정책도 기존 보안 기준대로 검토해야 합니다.

도입 뒤에는 캐시 적중률만 보지 말고 실제 요청 간격과 접두부 안정성을 함께 봅니다. 사용자가 보통 몇 분 뒤 후속 질문을 하는지, 공통 지침이 얼마나 자주 배포되는지, 5분과 1시간 중 어느 수명이 요청 흐름에 맞는지 확인합니다. 접두부가 짧거나 호출이 드문 서비스에서는 캐시를 쓰는 비용과 복잡성이 절감분보다 클 수 있습니다. 프롬프트 캐싱은 반복되는 긴 앞부분이 분명하고 후속 요청이 이어지는 구간부터 적용하는 편이 안전합니다.