GPT-5.6 prompt caching 운영법: explicit breakpoint로 비용 줄이기

GPT-5.6 발표에서 눈에 띄는 기능 중 하나는 prompt caching의 변화다. OpenAI는 GPT-5.6 이후 모델에서 explicit cache breakpoints와 30분 minimum cache life를 지원한다고 설명했다. 캐시 write는 uncached input rate의 1.25배, cache read는 cached input 90% 할인 구조다.

이 기능은 “프롬프트가 길수록 싸진다”는 단순한 이야기가 아니다. 캐시에 잘 맞는 프롬프트 구조를 만들었을 때만 비용이 줄어든다. 반대로 매 요청마다 앞부분이 조금씩 달라지는 구조라면 캐시 적중률이 낮고, write 비용만 늘 수 있다.

prompt caching이 필요한 상황

가장 좋은 후보는 반복되는 긴 prefix가 있는 요청이다. 예를 들어 다음과 같은 기능이다.

• 회사 정책 문서 50페이지를 항상 붙이는 내부 Q&A
• 코드 스타일 가이드와 아키텍처 문서를 포함하는 coding assistant
• 고객 지원 매뉴얼, 환불 규정, 보안 정책을 매번 넣는 상담 봇
• 수십 개 도구 설명과 JSON schema를 포함하는 agent runtime
• 긴 few-shot 예시를 쓰는 분류·추출 파이프라인

반대로 요청마다 system prompt, 도구 목록, 참고 문서 순서가 바뀌는 구조는 캐시에 불리하다. 캐시는 “반복되는 앞부분”이 안정적일 때 효과가 난다. 따라서 비용 최적화는 API 옵션 하나를 켜는 문제가 아니라 프롬프트 조립 방식을 고정하는 문제다.

breakpoint를 어디에 둘 것인가

explicit cache breakpoint는 캐시 가능한 구간과 매 요청마다 바뀌는 구간을 분리하는 기준점으로 이해하면 된다. 일반적으로 캐시 후보는 앞쪽에 둔다.

권장 구조는 다음과 같다.

1. 고정 system instruction
2. 제품 정책과 답변 원칙
3. 도구 설명 또는 JSON schema
4. 긴 예시 모음
5. cache breakpoint
6. 사용자별 컨텍스트
7. 이번 요청 내용
8. 출력 형식 지시

여기서 14번은 자주 바뀌지 않으므로 캐시 후보가 된다. 68번은 요청마다 바뀌므로 캐시 뒤에 둔다. 만약 사용자별 권한 정보나 오늘 날짜를 앞쪽 system prompt에 섞어 넣으면 캐시 적중률이 깨진다.

프롬프트 빌더를 점검할 때는 “매 요청마다 달라지는 문자열이 breakpoint 앞에 들어가는가”를 먼저 봐야 한다. timestamp, request_id, user_id, locale, A/B test variant가 앞쪽에 들어가면 캐시 효율이 떨어진다.

비용 계산을 어떻게 볼 것인가

캐시 write가 1.25배라는 점 때문에 첫 요청은 오히려 비쌀 수 있다. 하지만 같은 prefix를 30분 안에 여러 번 재사용한다면 read 할인으로 이득이 생긴다.

예를 들어 100k input token 중 80k가 캐시 가능한 prefix라고 하자. 이 prefix가 한 번만 쓰이면 write 비용이 붙어 비효율적일 수 있다. 그러나 같은 prefix를 20번 재사용하면 대부분의 요청에서 80k 토큰이 90% 할인된다. 이때 비용 절감 폭은 매우 커진다.

실무에서는 다음 지표를 봐야 한다.

• cacheable_prefix_tokens: 캐시 후보 토큰 수
• cache_write_count: 캐시를 새로 쓴 횟수
• cache_read_count: 캐시를 읽은 횟수
• cache_hit_ratio: 전체 요청 중 캐시가 적용된 비율
• effective_input_cost: 할인 반영 후 요청당 입력 비용
• prefix_version: 캐시 대상 프롬프트 버전

prefix_version이 중요하다. 정책 문서를 수정하거나 도구 schema를 바꾸면 캐시 prefix가 바뀐다. 이때 버전 없이 로그를 보면 왜 캐시 적중률이 떨어졌는지 알기 어렵다.

프롬프트 빌더 리팩터링 예시

기존 코드가 이런 식이면 캐시에 불리하다.

system = now + user_id + policy + tools + examples + request

now와 user_id가 앞에 붙어 매번 prefix가 달라진다. 캐시를 쓰려면 다음처럼 분리해야 한다.

cached_prefix = policy + tools + examples
request_suffix = now + user_id + user_context + request

또한 도구 목록을 매 요청마다 동적으로 정렬하면 안 된다. 같은 도구라도 순서가 바뀌면 prefix가 달라진다. 도구 schema는 이름순이나 priority순으로 고정하고, 실험 중인 도구는 별도 prefix_version으로 분리하는 것이 좋다.

긴 few-shot 예시도 마찬가지다. 예시를 랜덤 샘플링해서 앞쪽에 넣으면 캐시가 깨진다. 예시 세트를 고정하거나, feature flag별로 고정된 예시 묶음을 둬야 한다.

RAG와 prompt caching을 같이 쓸 때

RAG 시스템에서는 검색 결과가 매번 달라지기 때문에 캐시가 어렵다고 생각하기 쉽다. 그러나 검색 결과를 suffix로 보내고, 고정 정책과 답변 형식만 prefix로 두면 여전히 효과가 있다.

추천 구조는 다음과 같다.

• prefix: 역할, 금지사항, 답변 스타일, citation 규칙, 출력 schema
• suffix: 검색 결과, 사용자 질문, 사용자 권한, 현재 시간

검색 결과를 prefix에 섞지 않는다. 또한 citation 규칙처럼 자주 반복되는 지시문은 prefix에 둔다. 이렇게 하면 RAG 결과가 매번 달라도 고정 지시문은 캐시될 수 있다.

다만 RAG에서 더 큰 비용은 검색 결과 자체일 수 있다. 같은 사용자가 비슷한 질문을 반복한다면 retrieval result cache도 별도로 운영해야 한다. prompt cache와 retrieval cache는 다른 계층이다. 둘을 구분해서 봐야 병목을 찾을 수 있다.

장애 대응과 롤백

캐시 기능을 켰을 때 가장 무서운 문제는 “비용이 줄 거라 기대했는데 오히려 늘어나는 상황”이다. 원인은 대개 세 가지다.

첫째, prefix가 자주 바뀐다. 둘째, 재사용 횟수가 적다. 셋째, 캐시 대상이 너무 작다. 이 경우 write 비용만 의미 있게 발생하고 read 절감이 부족하다.

그래서 rollout은 기능별로 해야 한다. 전체 조직에 한 번에 켜지 말고, 반복 prefix가 확실한 기능부터 시작한다. 하루 단위로 cache hit ratio와 effective input cost를 비교하고, 기준 미달이면 자동으로 끄는 feature flag를 둔다.

권장 기준은 처음에는 보수적으로 잡는다. 예를 들어 cache hit ratio가 50% 미만이거나 요청당 입력 비용이 기존 대비 10% 이상 증가하면 롤백한다. 반대로 70% 이상 hit ratio가 안정적으로 나오면 캐시 대상을 더 넓힌다.

실행 체크리스트

• 반복되는 긴 prefix가 있는 기능을 먼저 찾는다.
• timestamp, user_id, request_id가 캐시 구간 앞에 들어가지 않도록 프롬프트 빌더를 분리한다.
• policy, tools, examples 순서를 고정한다.
• prefix_version을 로그에 남긴다.
• cache_write_count와 cache_read_count를 분리해서 본다.
• RAG 검색 결과는 suffix에 두고, citation 규칙은 prefix에 둔다.
• feature flag로 기능별 rollout과 rollback을 가능하게 한다.

출처: OpenAI GPT-5.6 발표의 prompt caching 가격·동작 설명 기준.