OpenAI API 비용을 줄이는 프롬프트 캐싱 설정법의 핵심은 반복되는 긴 콘텐츠를 요청 앞부분에 고정하고, API 응답의 캐시 토큰을 실제로 측정하는 데 있다. 특히 2026년 GPT-5.6 이상 모델은 캐시 읽기 요금이 일반 입력의 10%이므로, 동일한 긴 프롬프트를 반복하는 서비스라면 비용 차이가 빠르게 커진다.
다만 기능이 기본 활성화됐다는 사실만으로 비용이 자동 절감되지는 않는다. 캐시는 요청의 접두사(prefix)가 동일한지를 기준으로 작동하므로 시스템 지침, 도구 정의, 참고자료와 메시지 순서가 조금만 달라져도 적중 가능한 구간이 짧아질 수 있다.
이 글은 탐색형 검색 의도에 맞춰 캐시가 작동하는 조건, 프롬프트 배치 방법, 적중률 확인 절차, 10회 호출 비용과 손익분기점을 순서대로 설명한다. 수치는 2026년 OpenAI 공식 프롬프트 캐싱 문서에 공개된 GPT-5.6 이상 기준을 적용했다.
📌 핵심 요약
- GPT-5.6 이상은 동일한 캐시 가능 접두사가 최소 1,024개 표시 입력 토큰이어야 한다.
- 일반 입력을 1배로 보면 캐시 쓰기는 1.25배, 캐시 읽기는 0.1배다.
- 고정 콘텐츠는 앞에, 매번 달라지는 사용자 입력은 뒤에 배치해야 적중 구간이 길어진다.
- 적중률은 전체
cached_tokens합계를 전체input_tokens합계로 나눠 확인한다.
OpenAI 프롬프트 캐싱의 작동 조건과 1,024토큰 기준
프롬프트 캐싱은 이전 요청에서 처리한 입력의 앞부분을 저장해, 다음 요청에서 동일한 접두사의 연산을 재사용하는 기능이다. 지원 모델에서는 기본으로 활성화되지만, 모든 입력 토큰이 자동으로 캐시되는 것은 아니다.
GPT-5.6 이상에서는 캐시 가능한 접두사가 최소 1,024개의 표시 입력 토큰이어야 한다. 예를 들어 시스템 지침과 참고문서를 합쳐 900토큰뿐이라면 뒤의 질문이 반복되더라도 최소 길이 조건을 충족하지 못한다. 반대로 고정 지침과 문서가 3,000토큰이고 그 앞부분이 동일하다면 해당 구간을 중심으로 재사용 가능성이 생긴다.
최소 1,024토큰
GPT-5.6 이상에서 캐시 가능한 동일 접두사의 최소 표시 입력 길이 · OpenAI 공식 문서
캐시 보존 시간도 모델 세대에 따라 다르다. GPT-5.6 이상 캐시는 마지막 쓰기 또는 마지막 재사용 시점부터 최소 30분 유지된다. 이전 모델은 in_memory 설정에서 보통 비활성 상태가 5~10분 지속되면 만료되고, 지원되는 24h 설정을 사용하면 최대 24시간 유지될 수 있다.
따라서 고객 상담처럼 요청이 계속 들어오는 워크로드는 짧은 보존 시간에서도 효과를 얻기 쉽다. 반면 하루에 한두 번만 실행되는 배치 작업이라면 모델과 보존 옵션을 확인하지 않고 예상 절감액을 계산해서는 안 된다.
프롬프트 캐싱 설정법: 고정 접두사와 변경 입력 배치하기
설정의 첫 단계는 요청 콘텐츠를 ‘재사용되는 부분’과 ‘매번 달라지는 부분’으로 분리하는 것이다. 접두사 캐시 구조에서는 순서가 성능을 좌우하므로 다음 순서가 가장 안정적이다.
- 시스템 지침을 가장 앞에 둔다. 역할, 출력 규칙, 금지 조건처럼 요청마다 유지되는 내용을 먼저 배치한다.
- 도구 정의를 고정된 순서로 넣는다. 함수 목록과 JSON 스키마의 속성 순서를 요청마다 바꾸지 않는다.
- 공통 참고자료를 이어 붙인다. 제품 설명서, 정책 문서, 예시 출력처럼 반복 사용되는 긴 자료가 여기에 해당한다.
- 사용자 질문과 세션 데이터를 마지막에 둔다. 시간, 사용자 ID, 검색어처럼 계속 달라지는 값은 고정 접두사 뒤로 보낸다.
캐시가 적중하기 쉬운 메시지 순서
1. 공통 시스템 지침
2. 고정된 도구 정의
3. 공통 제품·정책 문서
4. 대화별 사용자 질문
5. 요청마다 변하는 부가 데이터예를 들어 요청 시각을 시스템 메시지 첫 줄에 삽입하면 첫 부분부터 문자열이 달라진다. 캐시 대상 문서가 그대로여도 접두사 비교가 일찍 끊겨 적중 토큰이 줄어들 수 있다. 요청 시각은 고정 문서 뒤나 별도 사용자 콘텐츠에 배치하는 편이 낫다.
도구 정의의 의미가 같더라도 도구 배열의 순서를 매번 섞거나 JSON 속성을 동적으로 재정렬하면 같은 문제가 생긴다. 참고자료 역시 검색 결과의 점수순으로 매번 순서가 바뀐다면 공통 부분이 짧아지므로, 변하지 않는 정책 원문과 동적으로 검색한 문서를 분리해야 한다.
GPT-5.6의 명시적 캐시 쓰기 지점
GPT-5.6 이상에서는 prompt_cache_options.mode를 explicit로 지정하고 콘텐츠 블록에 prompt_cache_breakpoint를 넣어 캐시 쓰기 위치를 명시할 수 있다. 한 요청에서 설정 가능한 쓰기 지점은 최대 4개다.
이 기능은 공통 시스템 규칙, 대형 참고문서, 작업별 예시처럼 재사용 경계가 뚜렷할 때 유용하다. 다만 지점을 많이 만든다고 항상 이득인 것은 아니다. 쓰기 토큰에는 1.25배 요율이 적용되므로, 이후 재사용 가능성이 높은 경계만 선택해야 한다.
OpenAI 프롬프트 캐싱 지원 모델과 명시적 설정 절차 자세히 보기
GPT-5.6 캐시 토큰 요금 계산: 동일 프롬프트 10회 비용
GPT-5.6 이상에서 일반 입력 요율을 1로 두면 캐시 쓰기는 1.25, 캐시 읽기는 0.1이다. 실제 통화 비용은 모델별 100만 입력 토큰 가격을 적용해야 하지만, 먼저 배수로 계산하면 어떤 모델에서도 절감 구조를 빠르게 판단할 수 있다.
동일한 캐시 가능 접두사를 10번 처리한다고 가정해 보자. 캐시를 사용하지 않으면 일반 입력 10회분이 든다. 캐시를 사용하면 첫 호출에서 1회 쓰기 비용 1.25가 발생하고, 나머지 9회는 각각 0.1이므로 합계는 2.15회분이다.
| 호출 시나리오 | 계산식 | 일반 입력 대비 비용 |
|---|---|---|
| 캐시 없이 10회 | 10 × 1.0 | 10.0회분 |
| 1회 쓰기 후 1회 읽기 | 1.25 + 0.1 | 1.35회분 |
| 1회 쓰기 후 9회 읽기 | 1.25 + (9 × 0.1) | 2.15회분 |
10회 기준 절감 비율은 (10 - 2.15) ÷ 10 × 100 = 78.5%다. 이는 10개 요청의 캐시 대상 접두사가 모두 같고, 첫 쓰기 이후 9번 모두 완전히 재사용된다는 조건의 이론값이다. 사용자별 문맥이나 도구 정의가 달라 일부 토큰만 적중하면 실제 절감률은 낮아진다.
실제 입력비는 각 토큰 범주에 해당 요율을 적용해 합산한다. GPT-5.6 이상에서는 다음 구조로 계산할 수 있다.
입력비 =
(일반 입력 토큰
+ 캐시 적중 토큰 × 0.1
+ 캐시 쓰기 토큰 × 1.25)
× 모델의 100만 토큰당 일반 입력가격
÷ 1,000,000가령 특정 요청 묶음에 일반 입력 20만 토큰, 캐시 읽기 70만 토큰, 캐시 쓰기 10만 토큰이 포함됐다면 과금 환산 토큰은 20만 + 7만 + 12만5천 = 39만5천 토큰이다. 여기에 선택한 모델의 100만 토큰당 일반 입력가격을 곱하면 입력비를 구할 수 있다.
캐시 사용의 손익분기 재사용 횟수
동일 접두사를 총 N번 호출할 때 캐시 비용은 1.25 + 0.1 × (N - 1), 미사용 비용은 N이다. 두 값을 비교하면 이론적 손익분기점은 약 1.28회이므로, 정수 호출 횟수로는 두 번째 동일 호출부터 누적 비용이 유리해진다.
단 한 번만 쓰고 만료되는 접두사는 일반 입력보다 25% 비싼 쓰기 비용만 남는다. 결국 핵심 판단 기준은 프롬프트의 길이만이 아니라 보존 시간 안에 같은 접두사가 최소 한 번 이상 재사용되는지다.
GPT-5.6 캐시 토큰 요금 계산: 동일 프롬프트 10회 비용 바로가기
cached_tokens로 캐시 적중률 확인하는 방법
캐시 효과는 API 응답의 usage.input_tokens_details.cached_tokens에서 확인한다. 요청 한 건만 보는 것보다 일정 기간의 전체 입력 토큰과 캐시 적중 토큰을 각각 합산해야 서비스 수준의 적중률을 정확히 파악할 수 있다.
- 각 API 응답에서
usage.input_tokens와usage.input_tokens_details.cached_tokens를 기록한다. - 사용자, 워크스페이스, 모델, 날짜를 함께 저장해 집계 기준을 만든다.
- 선택한 기간의
cached_tokens를 모두 합산한다. - 같은 기간의
input_tokens를 합산한다. - 아래 공식으로 적중률을 계산하고 배포 전후 값을 비교한다.
캐시 적중률(%) =
Σ cached_tokens ÷ Σ input_tokens × 100예를 들어 하루 동안 입력 토큰이 총 5,000만 개이고 그중 cached_tokens가 3,500만 개라면 캐시 적중률은 70%다. 이 수치는 비용 절감률과 같지 않다. 캐시 쓰기 토큰의 1.25배 비용, 일반 입력 토큰, 요청별 부분 적중이 함께 반영되기 때문이다.
OpenAI 대시보드의 사용량·비용 정보와 자체 집계값도 함께 대조하는 편이 안전하다. 사용자별 적중률은 특정 고객의 동적 프롬프트 문제를 찾는 데 유용하고, 워크스페이스별 집계는 배포 버전이나 팀별 프롬프트 구조 차이를 비교하는 데 적합하다. 일자별 추이는 캐시 만료나 트래픽 패턴 변화가 비용에 미친 영향을 보여준다.
OpenAI API 사용량과 캐시 토큰 확인 절차 바로가기
캐시 적중률을 높이고 비용 낭비를 막는 운영 체크리스트
2026년의 프롬프트 최적화는 단순히 입력을 짧게 줄이는 작업과 다르다. 반복성이 높은 긴 지침과 참고자료는 안정적인 접두사로 유지하고, 개인화 데이터만 뒤쪽에서 바꾸는 편이 총비용과 응답 지연을 함께 관리하기 쉽다.
| 점검 항목 | 비용에 유리한 구성 | 캐시를 깨뜨리는 구성 |
|---|---|---|
| 메시지 순서 | 고정 지침과 문서를 앞에 배치 | 세션별 데이터를 첫 메시지에 삽입 |
| 도구 정의 | 도구와 속성 순서를 일관되게 유지 | 요청마다 배열·스키마 순서를 변경 |
| 참고자료 | 공통 문서와 동적 검색 결과를 분리 | 검색 점수에 따라 전체 문서를 재정렬 |
| 재사용 주기 | 보존 시간 안에 같은 접두사를 반복 호출 | 한 번 쓴 뒤 만료될 콘텐츠를 매번 기록 |
| 성과 측정 | 토큰 유형별 비용과 적중률을 함께 집계 | 총 입력 토큰이나 청구액만 단독 확인 |
전문가 관점에서 가장 흔한 오류는 전체 프롬프트가 동일해야만 캐시가 작동한다고 생각하거나, 반대로 일부 문구만 같아도 모두 적중한다고 판단하는 것이다. 실제 최적화 단위는 앞에서부터 이어지는 동일 접두사다. 뒤쪽 사용자 질문이 달라도 앞부분은 재사용할 수 있지만, 앞부분이 달라지면 이후의 같은 문서까지 영향을 받는다.
운영에서는 먼저 트래픽이 많은 요청 유형 하나를 선택해 고정 구간을 표준화하는 방식이 효과적이다. 변경 전후 7일처럼 동일한 요일 구성을 가진 기간을 비교하고, 적중률뿐 아니라 캐시 쓰기 토큰·읽기 토큰·일반 입력 토큰과 실제 비용을 함께 확인해야 착시를 줄일 수 있다.
마지막으로 프롬프트 버전을 자주 바꾸는 환경에서는 배포 시점마다 캐시가 새로 작성될 수 있다. 문구 수정의 품질 효과가 작다면 여러 차례 나눠 배포하기보다 검증된 변경을 묶어 반영하는 편이 쓰기 비용과 측정 혼선을 줄이는 데 도움이 된다.
OpenAI API 프롬프트 캐싱의 실질적인 출발점은 최소 1,024토큰보다 긴 공통 콘텐츠를 요청 앞부분에 고정하는 것이다. GPT-5.6 이상에서는 첫 쓰기가 일반 입력의 1.25배여도 이후 읽기가 0.1배이므로, 보존 시간 안에 두 번째 동일 호출이 발생하면 누적 비용이 유리해진다. 적용 후에는 cached_tokens ÷ input_tokens로 적중률을 집계하고, 토큰 유형별 요금까지 함께 계산해야 실제 절감 효과를 정확히 판단할 수 있다.