OpenAI 프롬프트 캐싱 24시간 운영법: LLM 비용을 낮추는 설계 체크리스트

OpenAI API changelog에는 2026년 5월 말부터 ZDR이 아닌 조직에서 prompt_cache_retention 기본값이 in_memory가 아니라 24시간으로 바뀌었다는 내용이 있습니다. 이 변화는 화려한 신기능처럼 보이지 않지만, LLM 비용 최적화에는 꽤 실용적입니다. 같은 긴 프롬프트를 반복해서 보내는 서비스라면 캐시 적중률만 올려도 체감 비용과 지연 시간을 줄일 수 있습니다.

다만 프롬프트 캐싱은 “켜두면 싸진다”가 아닙니다. 프롬프트 구조가 캐시에 맞게 설계되어 있어야 합니다. 이 글은 개발자가 바로 적용할 수 있는 캐싱 설계 방법을 정리합니다.

프롬프트 캐싱이 효과적인 경우

캐싱이 잘 먹히는 패턴은 공통 prefix가 길고, 사용자별 가변 입력이 뒤쪽에 붙는 구조입니다.

예를 들면 다음과 같습니다.

대형 시스템 프롬프트를 사용하는 고객지원 봇
긴 정책 문서나 제품 매뉴얼을 매번 컨텍스트로 넣는 RAG 보조 플로우
코드 리뷰 규칙, 보안 체크리스트, 스타일 가이드를 고정으로 넣는 개발 도구
동일한 예시 few-shot을 여러 요청에서 반복하는 분류기
에이전트가 동일한 도구 설명과 운영 규칙을 매번 포함하는 워크플로우

반대로 사용자 입력이 매번 앞쪽에 오고, 시스템 프롬프트가 짧거나, 프롬프트 전체가 요청마다 재조립되는 구조라면 캐시 효율이 낮습니다.

비용이 새는 프롬프트 구조

프롬프트 캐싱을 망치는 흔한 구조는 다음과 같습니다.

1. 매 요청마다 timestamp를 앞쪽에 넣는 경우

프롬프트 맨 앞에 “현재 시간: 2026-07-06 23:00” 같은 값을 넣으면, 뒤의 긴 규칙이 같아도 prefix가 달라져 캐시 적중률이 떨어질 수 있습니다. 시간 정보가 필요하면 고정 규칙 뒤, 사용자 입력 근처에 배치하는 편이 낫습니다.

2. 사용자별 메타데이터를 시스템 프롬프트 중간에 섞는 경우

“사용자 이름”, “요금제”, “최근 행동” 같은 가변 정보는 중요하지만 고정 정책 문서 중간에 넣으면 캐시 범위가 깨집니다. 고정 블록과 가변 블록을 명확히 분리해야 합니다.

3. 도구 설명을 매번 다른 순서로 직렬화하는 경우

JSON object 순서가 실행마다 바뀌거나, 도구 목록이 동적으로 정렬되면 프롬프트 문자열이 달라집니다. 도구 설명, 정책, 예시는 안정적인 순서로 직렬화해야 합니다.

실제 적용 예시

고객지원 자동응답 서비스를 생각해봅시다. 기존 프롬프트가 다음처럼 되어 있다고 가정합니다.

현재 시간
고객 이름과 요금제
상담 정책
환불 규정
말투 가이드
최근 대화
질문

이 구조에서는 앞부분부터 계속 달라집니다. 캐싱 친화적으로 바꾸면 아래처럼 됩니다.

상담 정책
환불 규정
말투 가이드
답변 금지 항목
출력 포맷
고객 이름과 요금제
최근 대화
현재 시간
질문

정책 문서가 20k 토큰이고 사용자별 컨텍스트가 1k 토큰이라면 차이가 큽니다. 동일한 정책 문서를 하루 동안 반복 호출하는 구조에서는 24시간 캐시 유지가 의미 있는 비용 절감으로 이어질 수 있습니다.

관측 지표를 먼저 만들어야 한다

캐싱은 감으로 운영하면 안 됩니다. 최소한 아래 지표를 로그에 남겨야 합니다.

요청별 총 입력 토큰
캐시 가능한 고정 prefix 길이
캐시 hit/miss 여부 또는 캐시 관련 usage 정보
모델별 평균 비용
p95 지연 시간
프롬프트 템플릿 버전

특히 프롬프트 템플릿 버전은 중요합니다. 프롬프트 문구를 자주 바꾸면 캐시가 초기화됩니다. 마케팅 문구 수정하듯 시스템 프롬프트를 매일 바꾸는 팀은 캐시 혜택을 제대로 못 받습니다.

배포 전략

프롬프트 캐싱 최적화는 한 번에 전체 서비스에 적용하지 말고, 호출량이 많은 경로부터 적용하는 게 좋습니다.

최근 7일 API 비용 상위 10개 endpoint를 뽑습니다.
각 endpoint의 고정 프롬프트 길이와 가변 입력 위치를 확인합니다.
템플릿을 고정 블록과 가변 블록으로 나눕니다.
10% 트래픽에만 새 템플릿을 적용합니다.
비용, 지연 시간, 품질 지표를 기존 템플릿과 비교합니다.

품질 비교도 필요합니다. 프롬프트 순서를 바꾸면 모델의 응답 스타일이 달라질 수 있습니다. 특히 출력 포맷을 앞쪽에 둘지 뒤쪽에 둘지는 태스크별로 다르게 테스트해야 합니다.

캐싱과 보안

ZDR 조직은 정책이 다를 수 있으므로 캐시 유지 설정을 그대로 적용할 수 없습니다. 개인정보, 고객 데이터, 민감 로그를 포함한 프롬프트는 캐시 정책과 데이터 보존 정책을 함께 봐야 합니다.

운영 원칙은 간단합니다.

고정 문서와 사용자 데이터를 분리합니다.
민감 정보는 필요 최소한만 넣습니다.
프롬프트 로그에는 원문 대신 해시와 길이 정보를 우선 저장합니다.
캐시 정책은 보안팀 또는 개인정보 책임자와 같이 확인합니다.

바로 적용할 체크리스트

API 비용 상위 endpoint 10개 추출
프롬프트를 고정 블록과 가변 블록으로 분리
timestamp, user metadata를 프롬프트 앞쪽에서 제거
도구 설명과 예시 순서를 안정적으로 직렬화
프롬프트 템플릿 버전 로그 추가
캐시 hit/miss, 입력 토큰, 지연 시간 지표 수집
10% 트래픽 A/B 테스트 후 전체 적용
ZDR·개인정보·로그 보존 정책과 충돌 없는지 확인

프롬프트 캐싱 24시간 기본값은 비용을 자동으로 줄여주는 마법이 아닙니다. 하지만 긴 고정 컨텍스트를 반복 사용하는 서비스라면, 프롬프트 레이아웃만 바꿔도 바로 효과를 볼 수 있는 최적화 포인트입니다.