[OpenAI][비용] Prompt Caching이 자동으로 붙는 조건과 cached_tokens로 절감 여부 확인하는 법

IT 리서치 노트

[OpenAI][비용] Prompt Caching이 자동으로 붙는 조건과 cached_tokens로 절감 여부 확인하는 법

Prompt Caching은 버튼을 켜는 기능이 아니라, 공통 prefix가 긴 요청에서 자동으로 붙는 비용 절감 장치다. 문제는 붙는 조건과 확인 위치를 모르면 절감이 됐는지 판단하기 어렵다는 점이다. 2026년 6월 24일 기준 OpenAI 공식 문서를 다시 보면, 핵심은 1024 token 기준, exact prefix 일치, prompt_cache_key 일관성, 그리고 응답 usage 안의 cached_tokens 확인 순서다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 자동 조건과 확인 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

먼저 결론부터 말하면, Prompt Caching은 eligible한 긴 프롬프트에서 자동으로 붙는다. 최근 OpenAI 공식 문서는 Prompt Caching이 별도 코드 변경 없이 동작한다고 설명하고, 같은 긴 prefix를 반복할수록 지연과 input token 비용을 줄일 수 있다고 적고 있다. 다만 그냥 요청을 많이 보낸다고 hit가 늘어나는 것은 아니다. 정확히 같은 prefix가 앞부분에 유지되어야 하고, 응답 usage 안의 cached_tokens를 직접 봐야 절감 여부를 판단할 수 있다.

이 기능은 특히 시스템 지시, 예시, schema, tool 설명처럼 매 요청마다 반복되는 긴 앞부분이 있을 때 의미가 크다. 예를 들어 Structured Outputs와 긴 schema를 같이 쓰는 응답 파이프라인이라면 JSON mode와 Structured Outputs 차이를 실무 기준으로 정리한 글과 연결해서 보는 편이 좋다. Responses API background 작업이나 webhook 저장 흐름처럼 같은 prefix가 반복될 가능성이 높다면 Responses API background mode와 webhook을 같이 쓸 때 놓치기 쉬운 점도 이어서 참고할 만하다.

2. 어디서 실제로 막히는가

실무에서 자주 생기는 오해는 세 가지다. 첫째, Prompt Caching을 직접 활성화하는 플래그가 있어야 한다고 생각한다. 둘째, prefix가 조금 바뀌어도 비슷한 프롬프트면 hit가 날 것이라고 본다. 셋째, 비용 절감 확인을 총 prompt_tokens만 보고 판단한다. 실제로는 자동 동작이 맞지만, exact prefix 조건을 어기면 cached_tokens가 0으로 남고, 총 prompt_tokens만 보면 얼마가 cached input 단가로 계산됐는지 알 수 없다.

특히 1024 token 기준을 모르면 로그 해석이 꼬이기 쉽다. 공통 시스템 프롬프트가 길어 보이더라도 실제 토큰 길이가 1024 미만이면 cached_tokens는 계속 0일 수 있다. 반대로 1024를 넘겼더라도 앞부분에 사용자별 동적 값이 섞이면 prefix hash가 달라져 hit가 줄어든다. 같은 문서를 붙였는데도 날짜나 세션 id를 앞에 넣는 바람에 매번 miss가 나는 경우가 대표적이다.

가격 계산도 자주 틀린다. OpenAI pricing docs는 input과 cached input 단가를 따로 적고 있다. 즉 비용 절감을 보려면 prompt_tokens - cached_tokens와 cached_tokens를 나눠 각각 단가에 곱해야 한다. cached_tokens를 읽지 않으면 Prompt Caching이 실제로 얼마나 먹혔는지 감으로만 보게 된다.

• 오해: 캐시 hit를 켜는 별도 기능이 있다고 생각한다.
• 실패: 공통 prefix 앞부분에 동적 텍스트를 넣어 exact match를 깨뜨린다.
• 막힘: 1024 token 미만 요청인데 cached_tokens가 0인 것을 버그로 본다.
• 누락: cached input 단가를 안 보고 총 prompt_tokens만 본다.

증상	먼저 볼 곳	실무 판단
cached_tokens가 계속 0이다.	1024 token 기준, prefix 앞부분 동적 값, prompt_cache_key	길이와 exact prefix를 먼저 본다.
비용 절감이 체감되지 않는다.	pricing docs의 Cached input 열	uncached input과 cached input을 나눠 계산한다.
같은 서비스인데 hit rate가 들쭉날쭉하다.	prefix 해시 라우팅, prompt_cache_key 일관성, 요청률	공통 prefix와 key 조합을 더 안정적으로 묶는다.

3. 자동 조건과 확인 순서

가장 실용적인 확인 순서는 다섯 단계다. 먼저 프롬프트 길이가 1024 tokens 이상인지 본다. 다음으로 시스템 지시, 예시, schema 같은 정적인 내용을 앞에 두고 동적 사용자 입력을 뒤로 민다. 이어서 반복 트래픽이라면 prompt_cache_key를 일관되게 준다. 그다음 usage.prompt_tokens_details.cached_tokens를 로그에 남긴다. 마지막으로 현재 모델의 cached input 단가를 pricing docs에서 확인해 절감액을 계산한다.

1. 먼저 공통 prefix가 1024 tokens 이상인지 확인한다.
2. 정적 내용은 앞에, 사용자별 동적 내용은 뒤에 둔다.
3. 공통 prefix를 공유하는 반복 요청에는 prompt_cache_key를 일관되게 준다.
4. 응답 usage에서 cached_tokens를 수집한다.
5. input 단가와 cached input 단가를 분리해 실제 절감액을 계산한다.

이 순서는 기능 이름을 외우는 것보다 중요하다. Prompt Caching은 자동이므로, 잘 붙게 만드는 설계와 잘 읽는 로그가 핵심이다. 예를 들어 긴 schema 기반 응답을 만들 때는 schema 전문과 예시를 앞에 고정하고, 실제 ticket body나 사용자 질문은 뒤로 보내는 편이 hit rate를 높이기 쉽다.

절감 계산 예시

effective_input_cost
= uncached_input_tokens * input_rate
= cached_input_tokens * cached_input_rate

cache_hit_ratio = cached_tokens / prompt_tokens

총 prompt_tokens가 크다는 사실만으로는 절감 여부를 판단할 수 없다. cached_tokens가 얼마나 붙었는지와, 그 모델의 cached input 단가가 얼마인지 같이 봐야 한다. 2026-06-24 기준 gpt-5.5 standard short context는 input 1M tokens당 5달러, cached input 0.50달러이므로 두 수치 차이가 크다.

4. 공식 문서와 예시 화면으로 확인하기

첫 화면에서는 Prompt Caching이 자동 기능이라는 점부터 확인한다. OpenAI는 최근 모델에서 Prompt Caching이 별도 코드 변경 없이 동작하고, 긴 프롬프트 반복 호출에서 지연과 입력 비용을 줄일 수 있다고 설명한다.

Prompt Caching 가이드 첫 부분은 자동 동작, 최근 모델 지원, 긴 반복 프롬프트 최적화라는 기본 전제를 보여 준다.

여기서 핵심은 모델 응답 품질을 바꾸는 기능이 아니라는 점이다. 캐시 hit는 prefill 비용과 시간을 줄이는 장치이지, 출력 의미를 다르게 만드는 장치가 아니다.

다음으로 조건을 본다. 공식 문서는 1024 tokens 이상 프롬프트에서 캐싱이 가능하고, 1024 미만이어도 응답 usage 안에 cached_tokens 필드 자체는 항상 노출된다고 적고 있다.

Requirements 구간은 1024 token 기준과 usage.prompt_tokens_details.cached_tokens 확인 위치를 같이 보여 준다.

이 조건을 모르고 cached_tokens가 0인 로그만 보면 캐시가 고장 났다고 착각하기 쉽다. 먼저 프롬프트 길이와 공통 prefix 길이를 같이 확인해야 한다.

세 번째로 보는 화면은 최신 모델 가이드의 운영 팁이다. OpenAI는 공통 prefix가 반복되는 트래픽에서 stable content를 앞에 두고, prompt_cache_key를 일관되게 쓰며, cached_tokens를 추적하라고 직접 권장한다.

최신 모델 가이드는 stable prefix 배치, prompt_cache_key 일관성, cached_tokens 추적을 함께 권장한다.

실무에서는 이 조합이 중요하다. 시스템 프롬프트와 예시를 앞에 두고, 사용자별 동적 텍스트는 뒤로 미뤄야 hit가 늘어난다. 같은 prefix를 공유하는 트래픽이 많다면 prompt_cache_key 일관성도 같이 봐야 한다.

보존 정책도 확인해야 한다. 2026-06-24 기준 공식 문서는 in-memory와 extended retention을 나누고, gpt-5.5 계열은 24h만 지원한다고 적고 있다.

Prompt cache retention 화면은 in-memory와 24h 차이, 그리고 gpt-5.5의 24h 전용 제약을 보여 준다.

이 차이를 모르고 5.5에서 in_memory를 기대하면 설정이 어긋난다. 반대로 구형 모델에서는 조직의 ZDR 정책에 따라 기본 retention이 달라질 수 있으니, 비용뿐 아니라 데이터 정책도 같이 봐야 한다.

가격표에서는 Cached input 열을 직접 본다. Prompt Caching이 붙었는지 판단할 때 제일 빠른 방법은 usage.cached_tokens와 함께 현재 모델의 cached input 단가를 보는 것이다.

Pricing 페이지의 Cached input 열은 같은 모델에서도 일반 input과 cached input 단가가 다르다는 점을 보여 준다.

2026-06-24 기준 OpenAI API pricing docs에서는 gpt-5.5 standard short context가 input 1M tokens당 5달러, cached input 0.50달러로 나와 있다. 즉 cached_tokens를 읽지 않으면 절감 폭을 제대로 계산하기 어렵다.

로컬 예시는 Responses API 요청에서 어디를 고정해야 하는지 보여 주기 위한 것이다. 긴 시스템 지시와 예시를 앞에 두고, 사용자 입력과 request-specific context는 뒤에 붙이는 방식이 기본이다.

예시 요청 코드는 prompt_cache_key, prompt_cache_retention, 공통 prefix 분리 위치를 함께 보여 준다.

코드가 길다고 캐시가 잘 붙는 것은 아니다. 공통 prefix를 안정적으로 유지하는 구조가 더 중요하다. 같은 팀이 여러 경로에서 같은 prefix를 쓰면 prompt_cache_key도 통일해 두는 편이 낫다.

마지막 화면은 절감 여부를 어디서 확인하는지 보여 준다. cached_tokens가 0이면 캐시 miss, 값이 잡히면 hit가 있었던 것이다. 이 숫자를 input 단가와 cached input 단가에 나눠 계산해야 실제 절감이 보인다.

usage 예시 로그는 prompt_tokens와 cached_tokens를 같이 확인해 절감 여부를 계산하는 방식이다.

같은 prefix를 계속 쓰는데도 cached_tokens가 계속 0이면 길이, prefix 안정성, prompt_cache_key 일관성, retention 기대치를 순서대로 다시 봐야 한다.

5. 주의사항과 리스크

첫 번째 리스크는 캐시가 붙으면 rate limit 부담도 줄어든다고 생각하는 것이다. 공식 문서는 Prompt Caching이 TPM rate limit에는 영향을 주지 않는다고 적고 있다. 두 번째 리스크는 수동으로 cache clear를 기대하는 것이다. 현재는 manual cache clearing이 없고, 최근에 보지 않은 프롬프트는 자동으로 정리된다. 따라서 운영에서 필요한 것은 수동 삭제 버튼보다 prefix 안정성과 재현 가능한 로그다.

보존 정책도 주의해야 한다. in-memory retention은 대체로 5~10분 inactivity, 최대 1시간 수준이고, extended retention은 더 길게 유지될 수 있다. 문서상 gpt-5.5와 gpt-5.5-pro, future models는 24h만 지원한다. 조직의 Zero Data Retention 설정에 따라 기본 retention 동작이 달라질 수 있으니, 비용 최적화와 데이터 정책을 따로 보지 않는 편이 좋다.

• Prompt Caching이 붙어도 TPM rate limit 자체는 줄지 않는다.
• 현재 manual cache clearing은 없다.
• gpt-5.5 계열은 24h retention만 지원한다.
• 동적 값이 prefix 앞부분에 섞이면 hit가 급격히 떨어질 수 있다.

6. 결론

Prompt Caching은 켜는 기능보다 설계하는 기능에 가깝다. 공통 prefix를 1024 tokens 이상으로 안정적으로 유지하고, prompt_cache_key를 일관되게 주고, cached_tokens와 cached input 단가를 같이 봐야 실제 절감 여부를 판단할 수 있다.

• 1024 tokens 이상인지 먼저 본다.
• 정적 내용은 앞에, 동적 내용은 뒤에 둔다.
• cached_tokens를 로그로 남긴다.
• input과 cached input 단가를 나눠 계산한다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/prompt-caching
2. https://developers.openai.com/api/docs/guides/latest-model
3. https://developers.openai.com/api/docs/pricing