OpenAI 프롬프트 캐싱 최적화, 고정 prefix·브레이크포인트·비용 측정법

AI를 활용하여 생성한 이미지입니다.

같은 긴 시스템 지시문과 도구 정의를 매 요청마다 다시 처리하는 서비스라면, 모델을 바꾸기 전에 요청의 앞부분부터 살펴보는 편이 좋습니다. OpenAI의 프롬프트 캐싱은 반복되는 prefix를 재사용해 입력 처리 비용과 지연을 줄이는 기능입니다. 캐시 대상은 개발자 지시문만이 아니라 도구 정의와 대화 이력까지 포함한 렌더링된 문맥이므로, 메시지의 내용뿐 아니라 순서와 구조도 운영 대상이 됩니다.[1]

프롬프트 캐싱은 무엇을 재사용하나요?

캐시 가능한 prefix는 요청마다 앞에서부터 같아야 합니다. 모델 이름, 개발자 지시, 도구의 이름·설명·스키마·순서, 구조화 출력 형식 중 하나라도 자주 바뀌면 동일한 prefix로 보기 어려워집니다. 반대로 사용자의 질문, 현재 문서, 검색 결과처럼 매번 달라지는 값은 고정 영역 뒤로 보내는 것이 유리합니다. 캐시 적중은 답변을 저장해 두는 기능이 아니라 입력 처리의 일부를 재사용하는 기능이라는 점도 구분해야 합니다.[1]

OpenAI 문서에는 모델별 최소 캐시 길이가 안내되어 있습니다. 원문 기준으로 GPT-5.6 이상은 1,024토큰, 그보다 오래된 모델은 2,048토큰이 기준입니다.[1] 짧은 프롬프트를 억지로 늘리기보다, 실제 반복 prefix가 기준을 넘는지 사용량 데이터로 확인하세요.

고정 prefix를 설계하는 순서

1. 공통 규칙을 묶습니다. 서비스 전체에서 바뀌지 않는 역할, 금지사항, 답변 형식을 하나의 개발자 지시문에 둡니다.
2. 도구 정의를 안정화합니다. 도구 이름과 설명, 속성 순서, 필수 필드가 호출마다 달라지지 않도록 버전을 관리합니다.
3. 가변 문맥을 분리합니다. 고객별 자료, 최신 검색 결과, 현재 질문은 고정 prefix 뒤에 추가합니다.
4. 변경 이유를 기록합니다. 정책을 수정하거나 도구 스키마를 바꾼 날에는 새로운 prefix가 시작됐다고 보고 적중률을 따로 비교합니다.

테넌트별 개인정보나 비공개 자료를 공통 prefix에 넣어 적중률을 높이려 해서는 안 됩니다. 사용자별 문맥과 캐시 경계를 분리하고, 오래된 정책·불필요한 예시를 길게 붙여 캐시 길이만 늘리는 것도 피하세요. 비용 절감보다 데이터 격리와 최신성이 우선입니다.

암묵적 캐시와 명시적 브레이크포인트

반복 prefix는 기본 동작만으로 캐시될 수 있습니다. 고정된 지시문과 가변 대화의 경계를 코드에 분명히 남겨야 한다면 문서가 설명하는 명시적 방식도 검토할 수 있습니다. prompt_cache_options.mode를 explicit로 두고 지원되는 입력 블록에 prompt_cache_breakpoint를 지정하는 방식입니다.[1]

고정된 개발자 지시 + 도구 정의 + 공통 예시
[캐시 브레이크포인트]
사용자 질문 + 현재 문서 + 도구 결과

문서에는 ttl: "30m" 같은 캐시 수명 옵션도 제시됩니다.[1] 30분 동안 반드시 적중하거나 다음 날까지 보관된다고 해석하지 말고, 실제 사용량에 기록된 캐시 읽기와 쓰기를 기준으로 판단하세요.

비용과 품질을 함께 측정하는 법

캐시 최적화는 응답이 빨라 보이는지만으로 평가하면 안 됩니다. 같은 모델과 같은 도구 정의를 사용해 대표 요청 20~30건의 입력 토큰, 캐시 읽기 토큰, 캐시 쓰기 토큰, 일반 입력 토큰, 응답 지연, 총비용을 기록합니다. 고정 prefix와 가변 suffix를 나눈 뒤 같은 요청군을 다시 실행하면 첫 요청의 쓰기 비용과 후속 요청의 읽기 비중을 비교할 수 있습니다.[1]

적중률이 올라가도 답변 품질이나 도구 실행이 나빠질 수 있습니다. 구조화 출력은 결과 형식을 일정하게 만드는 일이고, 함수 호출은 애플리케이션의 도구를 연결하는 일입니다. 모델이 최종 구조화 데이터를 내보내는 경우와 도구를 호출하는 경우를 구분하고, 함수 호출 결과를 다음 요청에 넣을 때는 해당 call_id를 정확히 연결하세요.[2][3]

함수 스키마에는 가능하면 strict: true를 적용하는 편이 좋다고 OpenAI가 안내합니다. 다만 지원하지 않는 JSON Schema 키워드가 있으면 오류가 날 수 있으므로 스키마를 단순하게 시작하고 애플리케이션에서 실제 검증을 수행하세요.[3] 캐시는 검증이나 사실 확인을 대신하지 않습니다.

Responses API로 옮길 때의 주의점

Chat Completions의 messages 배열을 그대로 복사하는 식으로 마이그레이션하지 마세요. Responses API에서는 input, instructions, text.format과 함수 호출 결과를 전달하는 구조를 다시 확인해야 합니다.[4] 모델·도구·스키마를 한 번에 바꾸면 캐시 적중률 변화와 API 형식 변화가 섞입니다. 먼저 API 형식만 바꾸고, 다음 단계에서 prefix를 조정하는 식으로 원인을 나누세요.

캐시를 포기하는 편이 나은 경우

• 요청마다 시스템 지시와 도구 목록이 크게 달라지는 경우
• 긴 prefix가 한 번만 쓰여 캐시 쓰기 비용을 회수하기 어려운 경우
• 사용자별 문맥을 공통 캐시에 넣지 않으면 구조가 성립하지 않는 경우
• 캐시 적중보다 최신 정책 반영과 데이터 격리가 더 중요한 경우

도입 전 체크리스트

• 고정·가변 영역을 요청 로그에서 분리해 표시합니다.
• 모델, 도구, 스키마의 변경을 버전으로 기록합니다.
• 캐시 읽기·쓰기 토큰과 지연·총비용을 같은 기간에 비교합니다.
• 도구 오류, 재시도, 구조화 출력 검증 실패도 함께 집계합니다.
• 개인정보와 테넌트 전용 자료가 공통 prefix에 섞이지 않았는지 확인합니다.

운영 로그를 어떻게 남길까요?

캐시를 실제 비용 절감으로 연결하려면 요청마다 같은 항목을 남겨야 합니다. 모델명과 프롬프트 버전만 기록하면 원인을 나누기 어렵습니다. 도구·스키마 버전, 전체 입력 토큰, 캐시 읽기 토큰, 캐시 쓰기 토큰, 일반 입력 토큰, 첫 토큰까지의 지연, 전체 응답 시간, 도구 재시도 횟수와 오류 유형을 함께 저장하세요. 사용자의 원문이나 개인정보를 그대로 로그에 남기지 말고 식별자를 분리해 집계하는 편이 안전합니다.[1]

비교군도 나누어야 합니다. 처음 호출되는 콜드 요청과 같은 prefix를 반복하는 웜 요청을 구분하고, 짧은 질문과 긴 문서 입력을 섞지 마세요. 캐시 읽기 비중이 높아졌는데 총비용이 줄지 않는다면 출력 토큰, 재시도, 도구 호출 비용이 늘었는지 확인해야 합니다. 반대로 적중률이 낮아도 요청 자체가 짧다면 캐시 설계를 복잡하게 만드는 것보다 단순한 프롬프트가 더 나을 수 있습니다.

변경 배포 때 생기는 엣지 케이스

• 개발자 지시문에 날짜나 무작위 추적 ID를 넣으면 모든 요청의 앞부분이 달라질 수 있습니다.
• 도구 목록을 사용자별로 동적으로 만들면 공통 prefix와 테넌트 문맥을 분리하기 어려워집니다.
• 정책 문서를 고정 prefix에 넣었다면 문서가 바뀌는 즉시 새 버전으로 표시하고 이전 캐시의 의미를 과신하지 마세요.
• 재시도 요청이 같은 도구 호출을 다시 실행할 수 있으므로 캐시 최적화와 멱등성 검사를 별도로 유지합니다.

배포 전에는 한 가지 변경만 넣은 샘플 요청으로 prefix가 어디에서 달라졌는지 확인하세요. 도구 순서를 바꾼 것인지, 스키마의 설명 문장을 바꾼 것인지, Responses API의 입력 구조를 바꾼 것인지 원인이 분리되어야 다음 최적화가 재현됩니다.

자주 묻는 질문

캐시가 적중하면 답변도 같아지나요?

아닙니다. 입력 처리 일부를 재사용할 뿐, 새로운 출력 생성과 품질 검사는 별도로 이뤄집니다.[1]

도구를 하나 추가해도 되나요?

도구 정의와 순서가 바뀌면 prefix가 달라질 수 있습니다. 추가 전후를 다른 버전으로 측정하세요.

긴 프롬프트일수록 항상 유리한가요?

아닙니다. 반복되는 유효 정보만 남겨야 하며, 한 번만 쓰이는 장황한 설명은 비용과 유지보수 부담을 키울 수 있습니다.

함께 읽을 글

캐시로 비용을 줄이는 설계와 도구 호출의 중복 실행을 막는 설계는 별개의 문제입니다. AI 에이전트 도구 호출의 멱등성·재시도 설계도 함께 확인해 보세요.

Sources

1. [1] Prompt caching | OpenAI API
2. [2] Structured model outputs | OpenAI API
3. [3] Function calling | OpenAI API
4. [4] Migrating to Responses API | OpenAI API