같은 긴 프롬프트를 매번 다시 읽어야 할까? 12시간 프롬프트 캐싱의 원리와 설계

1. 프롬프트 캐시는 답을 저장하는 기능이 아니다

학교 규정, 출력 형식, 도구 정의와 긴 참고 자료를 매 요청마다 AI 모델에 보내는 서비스를 생각해 봅시다. 사용자 질문은 매번 달라도 앞부분 수천 토큰은 같을 수 있습니다. 모델은 입력을 처리하면서 앞 토큰을 뒤에서 참고할 수 있도록 중간 계산 상태를 만듭니다. 같은 앞부분을 다시 계산하지 않고 이 상태를 재사용하는 것이 프롬프트 캐싱의 핵심입니다.

OpenAI 공식 문서는 이 중간 상태를 key-value states, 즉 KV 상태라고 설명합니다. 캐시는 모델의 답변이나 사용자가 보낸 문자열을 그대로 꺼내 반환하는 일반 웹 캐시와 다릅니다. 이전 요청의 동일한 앞부분에서 계산한 KV 상태를 재사용하고, 새로 붙은 질문은 다시 처리해 새 답변을 생성합니다. 질문이 같아도 생성 결과가 항상 같아진다는 뜻은 아닙니다.

2026년 10월 20일 OpenAI API 변경 기록에는 Responses API에서 12시간 프롬프트 캐싱을 선택할 수 있게 됐다고 나옵니다. 몇 시간 간격으로 요청되는 공통 지침·도구·문맥을 더 오래 재사용할 수 있는 선택지이며, 12시간 캐시 쓰기는 일반 입력 토큰 가격의 2.5배라고 명시돼 있습니다. 오래 보존한다는 이유만으로 항상 경제적인 것은 아니므로 재사용 횟수와 시간 간격을 함께 봐야 합니다.

근거 자료 · OpenAI API Changelog · October 20, 2026 · OpenAI API Docs · Prompt caching

2. 캐시가 재사용되는 기준은 전체 요청이 아니라 동일한 앞부분이다

프롬프트 캐시는 접두사, 즉 입력의 시작부터 이어지는 동일한 구간을 기준으로 작동합니다. 공통 지침을 앞에 놓고 사용자마다 바뀌는 질문을 뒤에 두면 긴 공통 구간이 같게 유지됩니다. 반대로 날짜, 사용자 이름, 난수처럼 매 요청 달라지는 값을 맨 앞에 넣으면 그 지점 이후가 달라져 재사용할 수 있는 구간이 짧아집니다.

공식 문서에 따르면 렌더링된 전체 문맥에는 제공자 지침, 개발자 메시지, 도구 정의, 대화 기록과 텍스트·이미지·문서·지원되는 오디오가 포함될 수 있습니다. 모델, 도구의 이름·설명·스키마·순서, 병렬 도구 호출 설정, 구조화 출력 스키마, 추론 노력이나 상세도 설정 등이 바뀌면 캐시 가능한 접두사에도 영향을 줄 수 있습니다. 세션을 계속 사용한다는 사실만으로 적중이 보장되지는 않습니다.

GPT-5.6 이후 모델은 캐시 가능한 접두사가 최소 1,024토큰이어야 한다고 문서에 설명돼 있습니다. 짧은 질문 몇 줄만 반복하는 서비스라면 캐싱 최적화보다 요청 구조를 단순화하는 편이 낫습니다. 긴 시스템 지침, 많은 도구 스키마, 반복 참고 자료가 있을 때 먼저 토큰 사용량을 측정하고 최적화 대상을 정해야 합니다.

근거 자료 · OpenAI API Docs · Prompt caching

3. 캐시 쓰기와 읽기를 나누면 비용 구조가 보인다

캐시를 처음 만들 때는 쓰기 비용이 들고, 이후 동일한 접두사를 찾으면 읽기 가격이 적용됩니다. 공식 문서에서 GPT-5.6 이후 기본 30분 캐시 쓰기는 일반 입력 요율의 1.25배, 12시간 선택은 2.5배입니다. 이후 캐시 읽기는 대부분 해당 모델 일반 입력 요율의 0.1배이며 GPT-6.1 Sol은 0.05배라고 설명합니다. 실제 금액은 모델과 처리 방식에 따라 다르므로 현재 가격표를 확인해야 합니다.

손익은 ‘긴 캐시가 싸다’가 아니라 쓰기 뒤 유효 시간 안에 얼마나 많이 읽느냐로 결정됩니다. 일반 입력 비용을 1이라고 놓고 읽기 비율을 0.1로 단순화하면 12시간 캐시에 한 번 쓰고 한 번만 읽을 때 접두사 비용은 2.6입니다. 두 번을 일반 처리한 2보다 큽니다. 한 번 쓰고 여섯 번 읽으면 3.1이고, 일곱 번을 일반 처리한 7보다 작습니다. 이 계산은 원리를 설명하는 예시이며 실제 청구액이 아닙니다.

출력 토큰, 캐시되지 않은 뒤쪽 입력, 도구 호출 비용도 별도로 고려해야 합니다. 캐시 적중률이 높아져도 사용자가 불필요하게 긴 답을 받으면 전체 비용이 줄지 않을 수 있습니다. 서비스별로 cache write tokens, cached input tokens, uncached input tokens, output tokens를 나눠 집계해야 원인을 찾을 수 있습니다.

근거 자료 · OpenAI API Docs · Prompt caching · OpenAI API Docs · Pricing

4. 30분과 12시간은 요청 간격으로 선택한다

수업 시간 50분 동안 여러 학생이 같은 도구 정의와 과제 규칙을 사용하는 서비스는 짧은 시간에 요청이 몰립니다. 기본 30분 캐시도 반복 쓰기 없이 충분히 적중할 수 있습니다. 반면 오전에 보고서를 요청하고 오후에 수정 요청을 보내는 업무 보조 서비스는 요청 사이가 길어 12시간 선택이 유리할 가능성이 있습니다.

결정 전에 시간대별 요청 분포를 SQL로 확인합니다. 같은 템플릿 버전에서 다음 요청까지 걸린 시간, 접두사 토큰 수, 실제 캐시 읽기 토큰과 쓰기 토큰을 집계합니다. 평균만 보면 특정 수업이나 배치 작업의 집중 구간을 놓칠 수 있으므로 30분 이내, 30분~12시간, 12시간 초과 구간으로 나누는 편이 이해하기 쉽습니다.

12시간은 정확히 12시간 뒤까지 모든 항목이 반드시 남는다는 애플리케이션 저장 보장이 아닙니다. 공식 설명은 12시간 최소 lifetime 선택과 캐시 재사용 조건을 함께 다룹니다. 장애 복구나 대화 기록 보존을 프롬프트 캐시에 의존하지 말고, 필요한 업무 데이터는 권한과 보존 정책을 갖춘 데이터베이스에 따로 저장해야 합니다.

-- 실습용 분석 쿼리 예시
SELECT template_version,
       CASE
         WHEN gap_minutes <= 30 THEN '0-30m'
         WHEN gap_minutes <= 720 THEN '30m-12h'
         ELSE 'over-12h'
       END AS reuse_window,
       COUNT(*) AS requests,
       SUM(cache_read_tokens) AS cache_reads,
       SUM(cache_write_tokens) AS cache_writes
FROM prompt_usage
GROUP BY template_version, reuse_window;

5. Python 실험은 문장 품질이 아니라 데이터 흐름을 검증한다

학생 실습에서는 실제 유료 API를 반드시 호출할 필요가 없습니다. 긴 공통 지침과 10개의 질문을 텍스트로 만들고, 각 요청을 토큰 목록처럼 단순화해 앞 요청과 동일한 접두사 길이를 계산하는 Python 모의실험부터 시작할 수 있습니다. 고정 지침을 앞에 둔 버전과 날짜를 앞에 둔 버전을 비교하면 작은 순서 변경이 재사용 범위를 어떻게 바꾸는지 확인할 수 있습니다.

실제 API를 사용할 수 있다면 지원 모델과 현재 문서를 확인한 뒤 소량의 요청만 실행합니다. 응답 사용량에서 캐시 읽기·쓰기·일반 입력 토큰을 기록하고, 동일한 템플릿 버전에서도 도구 순서나 출력 스키마를 바꿨을 때 결과가 어떻게 달라지는지 관찰합니다. 응답 속도는 네트워크와 서버 부하의 영향을 받으므로 한 번의 측정으로 성능 향상을 단정하지 않습니다.

아래 코드는 API 호출 코드가 아니라 접두사 배치를 이해하기 위한 의사코드입니다. 목표는 캐시를 강제로 적중시키는 요령이 아니라, 변경이 잦은 데이터와 안정된 데이터를 구분해 요청 구조를 설명하는 것입니다.

• 고정 접두사와 가변 질문의 위치를 명시했는가
• 템플릿·도구·모델 버전을 사용량과 함께 기록했는가
• 캐시 적중과 답변 정확도를 서로 다른 지표로 평가했는가
• 실제 측정값과 계산 예시를 구분했는가

# 교육용 의사코드
stable_prefix = [policy_text, tool_schema, output_schema]
for question in questions:
    request = stable_prefix + [question]
    usage = send_and_collect_usage(request, retention='12h')
    save_usage(template_version, question_id, usage)

# 비교군: 날짜를 맨 앞에 넣어 공통 접두사가 짧아지는 경우
changed_request = [current_time] + stable_prefix + [question]

6. Java API와 클라우드 운영에서는 버전과 개인정보를 함께 관리한다

Java 백엔드는 화면의 질문을 그대로 모델로 전달하기 전에 템플릿 버전과 사용 가능한 도구를 결정할 수 있습니다. 요청 로그에는 원문 전체보다 request_id, template_version, model, retention, 입력·캐시 읽기·캐시 쓰기·출력 토큰과 지연 시간을 구조화해 남깁니다. 질문 원문이 꼭 필요하지 않다면 저장하지 않거나 민감정보를 제거합니다.

템플릿을 수정할 때는 모든 서버가 동시에 새 버전을 사용하도록 배포 순서를 관리합니다. 일부 서버가 오래된 도구 순서를 보내면 캐시 적중률뿐 아니라 출력 동작도 달라질 수 있습니다. 클라우드 대시보드에는 캐시 적중률만 올리지 말고 요청 성공률, 첫 응답 시간, 토큰당 비용, 답변 평가 점수와 오류율을 함께 표시합니다.

KV 텐서를 저장한다는 기술 설명이 개인정보 검토를 생략해도 된다는 뜻은 아닙니다. 공식 문서가 설명하는 렌더링 문맥에는 대화 기록과 문서·이미지 등도 포함될 수 있습니다. 개인정보와 비밀키를 프롬프트에 넣지 않는 원칙, 제공자의 데이터 처리 조건, 조직의 보존 정책과 접근 권한을 별도로 확인해야 합니다. 캐시 보존 시간은 업무 데이터 보존 기간과 같은 개념이 아닙니다.

브라우저 질문
→ Java API 인증·입력 검증
→ 템플릿 버전과 도구 선택
→ 고정 접두사 + 가변 질문 구성
→ AI API 캐시 쓰기 또는 읽기
→ 답변과 사용량 분리 수집
→ SQL 비용·품질 지표 저장
→ 클라우드 대시보드와 경보

7. 캐시 적중률이 높아도 서비스가 좋아졌다고 단정할 수 없다

높은 캐시 적중률은 반복 계산이 줄었다는 운영 신호입니다. 답변이 정확하고 도움이 된다는 품질 증거는 아닙니다. 오래된 규정이 안정된 접두사에 남아 반복되면 적중률은 높아도 내용은 틀릴 수 있습니다. 템플릿 버전과 자료 유효일을 관리하고, 변경 시 새 평가 세트를 통과시킨 뒤 배포해야 합니다.

평가에서는 같은 20개 질문을 30분 보존, 12시간 보존, 캐시를 고려하지 않은 구조로 나눠 비교할 수 있습니다. 요청당 전체 비용, 첫 토큰까지 시간, 캐시 읽기 비율, 정답 기준 충족률과 오류를 기록합니다. 이는 제안하는 실습 설계이며 특정 모델의 실제 성능 수치가 아닙니다. 네트워크 변동을 줄이려면 여러 차례 반복하고 중앙값과 범위를 함께 봅니다.

마지막으로 캐시는 장애 대책이 아닙니다. 캐시를 찾지 못해도 요청은 일반 입력으로 처리될 수 있도록 비용 상한과 시간 제한을 두고, 사용량 급증에는 경보를 설정합니다. 12시간 캐싱을 도입할지는 기능 이름이 아니라 재사용 시간 분포, 쓰기와 읽기 가격, 품질과 개인정보 조건을 근거로 결정해야 합니다.

8. 2주 프로젝트로 캐시 선택을 데이터로 설명한다

첫 주에는 세 가지 요청 템플릿을 만듭니다. 안정된 지침을 앞에 둔 템플릿, 가변 날짜를 앞에 둔 템플릿, 도구 순서가 바뀌는 템플릿입니다. Python으로 동일 접두사 길이를 계산하고, 가상 사용량을 SQL에 저장해 요청 간격별 재사용 가능 횟수를 분석합니다. 가격은 코드에 고정하지 않고 별도 설정과 확인 날짜를 기록합니다.

둘째 주에는 Java API로 템플릿 버전을 선택하고 사용량 JSON을 저장하는 기능을 만듭니다. 클라우드 환경에서는 예산 경보와 대시보드를 구성한 것으로 가정한 설계도를 작성합니다. 실제 API 실험을 선택했다면 소량의 비민감 예제만 사용하고 실험 비용 상한을 정합니다.

발표에서는 30분 또는 12시간 가운데 하나를 무조건 추천하지 않습니다. 자신의 가상 서비스에서 요청이 언제 반복됐고, 어느 접두사가 안정됐으며, 몇 번 재사용해야 쓰기 비용을 회수하는지를 보여 줍니다. 정확도·속도·비용·개인정보 가운데 어떤 조건이 결정을 바꾸는지도 설명하면 캐싱을 단순한 설정이 아니라 시스템 설계 문제로 이해할 수 있습니다.