OpenAI Prompt Caching 운영법: 긴 컨텍스트 API 비용을 줄이는 설계 기준

OpenAI Prompt Caching은 긴 프롬프트를 반복해서 보내는 API 제품에서 비용과 지연 시간을 동시에 줄일 수 있는 기능이다. 공식 문서에 따르면 지원 모델에서는 프롬프트 캐싱이 기본으로 활성화되며, 동일한 rendered prefix가 재사용될 때 cached input rate가 적용된다. 할인 폭은 모델과 요금제에 따라 다르지만 문서상 최대 90%까지 언급된다. 핵심은 “캐시가 있다”가 아니라 “캐시에 잘 맞는 요청 구조를 설계하느냐”다.

개발 현장에서 LLM 비용이 커지는 이유는 사용자가 긴 답을 받아서만이 아니다. 에이전트 시스템은 매 요청마다 시스템 지침, 도구 정의, 정책 문서, 프로젝트 컨텍스트, 이전 대화, 검색 결과를 같이 보낸다. 이 중 상당수는 요청마다 거의 변하지 않는다. Prompt Caching은 바로 이 고정 prefix를 재사용해 모델이 같은 토큰을 다시 처리하지 않게 만든다.

캐시가 동작하는 기본 조건

OpenAI 문서의 중요한 표현은 “entire rendered prefix must match”다. 개발자가 JSON에서 비슷한 내용을 보냈다고 캐시가 항상 맞는 것이 아니다. 모델이 실제로 받는 렌더링된 컨텍스트의 앞부분이 동일해야 한다. 시스템 메시지, developer 메시지, 도구 정의, 대화 기록, 문서, 이미지 같은 요소가 모두 prefix에 포함될 수 있다.

따라서 캐시 적중률을 높이려면 변하지 않는 내용을 앞에 고정하고, 매번 바뀌는 내용을 뒤로 밀어야 한다. 예를 들어 고객 지원 챗봇이라면 회사 정책, 답변 규칙, 금지 표현, 환불 정책 요약은 앞에 둔다. 사용자의 현재 질문, 최근 주문 정보, 검색된 문서 조각은 뒤에 둔다. 도구 정의 순서도 흔들리지 않게 고정한다.

자주 놓치는 문제는 타임스탬프와 요청 ID다. 시스템 메시지 앞부분에 “현재 시각: 2026-09-08 23:00” 같은 값을 매번 넣으면 prefix가 깨질 수 있다. 꼭 필요한 동적 값은 고정 정책 뒤, 사용자별 컨텍스트 근처에 배치한다. 실험 로그를 위해 넣는 request id, trace id, 랜덤 nonce도 프롬프트 본문이 아니라 메타데이터나 별도 로그로 빼는 편이 낫다.

어떤 서비스에서 효과가 큰가

Prompt Caching은 모든 API 요청에 같은 효과를 주지 않는다. 짧은 단발 질문에는 이득이 작다. 반대로 긴 고정 컨텍스트를 반복하는 서비스에서 효과가 크다. 대표적인 예는 코드베이스 분석 에이전트, 사내 문서 Q&A, 계약서 검토, 고객 지원 매뉴얼 기반 답변, 장문 리서치 에이전트다.

코딩 에이전트를 예로 들어보자. 매 요청마다 아키텍처 설명, 코딩 규칙, 테스트 명령, 파일 트리, 주요 타입 정의를 넣는다면 입력 토큰이 빠르게 커진다. 그런데 이 정보는 작업 중 여러 번 반복된다. 고정 prefix를 안정적으로 구성하면 캐시된 입력 토큰 비율이 올라가고, 에이전트가 여러 번 계획·수정·검증을 반복해도 비용 증가가 완만해진다.

사내 문서 Q&A도 비슷하다. 회사 정책 전체를 매번 검색해 넣는 대신, 자주 쓰는 핵심 정책과 답변 규칙은 고정 prefix로 두고, 현재 질문에 필요한 문서 조각만 뒤에 붙이면 된다. 이때 검색 결과의 순서가 매번 달라지면 캐시가 깨질 수 있으므로 점수와 문서 ID 기준으로 정렬을 고정하는 것이 좋다.

요청 구조를 어떻게 바꿔야 하나

첫째, 프롬프트를 static, semi-static, dynamic 세 덩어리로 나눈다. static은 제품 정책, 시스템 역할, 보안 규칙, 도구 정의처럼 거의 바뀌지 않는 내용이다. semi-static은 사용자 조직 설정, 프로젝트 규칙, 장기 메모리처럼 가끔 바뀌는 내용이다. dynamic은 현재 질문, 검색 결과, 실행 로그, 최근 대화처럼 매번 바뀌는 내용이다.

둘째, static을 가장 앞에 둔다. 캐시는 prefix 기반이므로 앞부분이 흔들리면 뒤에 아무리 긴 내용이 같아도 이득이 줄어든다. 셋째, 도구 정의를 안정화한다. 사용하지 않는 도구를 매번 넣거나, 도구 배열 순서가 상황마다 바뀌면 캐시 효율이 떨어진다. 도구가 많다면 작업 유형별로 toolset을 나누되, 각 toolset 내부 순서는 고정한다.

넷째, 검색 결과를 덜 흔들리게 만든다. RAG 시스템은 같은 질문에도 검색 점수 미세 차이로 문서 순서가 바뀔 수 있다. 캐시 관점에서는 검색 결과 전체가 dynamic이지만, 반복 작업에서는 같은 프로젝트 문서가 계속 등장한다. 문서 ID, 섹션 순서, 업데이트 시간을 기준으로 정렬 규칙을 정하면 재현성과 디버깅이 좋아진다.

다섯째, 캐시 모니터링을 지표로 본다. OpenAI는 Prompt Caching Dashboard에서 cache read hit rate를 확인할 수 있다고 안내한다. 운영팀은 총 입력 토큰, cached input token 비율, p50·p95 latency, 요청당 비용을 함께 봐야 한다. 캐시 적중률만 높고 응답 품질이 떨어지면 잘못 최적화한 것이다.

비용 계산은 평균이 아니라 작업 흐름으로 해야 한다

LLM 비용 계산에서 흔한 실수는 “요청 1회 가격”만 보는 것이다. 에이전트 제품은 한 사용자 액션이 여러 모델 호출로 구성된다. 예를 들어 코드 수정 기능은 계획 1회, 파일 읽기 3회, 수정안 작성 1회, 테스트 실패 분석 2회, 재수정 1회, 최종 요약 1회처럼 이어질 수 있다. 각 호출에 2만 토큰의 고정 컨텍스트가 반복된다면 캐싱 여부가 월 비용을 크게 바꾼다.

간단한 계산식을 만들자. 작업 1건당 평균 호출 수, 호출당 고정 입력 토큰, 동적 입력 토큰, 출력 토큰, 캐시 적중률을 표로 둔다. 그다음 캐시 적용 전후 비용과 지연 시간을 비교한다. 이 방식이면 “프롬프트를 1,000토큰 줄이는 것”과 “고정 prefix를 안정화해 캐시 적중률을 20% 올리는 것” 중 무엇이 더 큰 이득인지 판단할 수 있다.

또한 배치 처리와 함께 볼 필요가 있다. 실시간성이 낮은 요약, 분류, 리포트 생성은 Batch API나 낮은 우선순위 티어를 검토하고, 반복 컨텍스트가 큰 실시간 요청은 Prompt Caching을 우선 적용한다. 비용 최적화는 한 기능이 아니라 라우팅 정책이다.

적용 체크리스트

• 시스템 지침, 정책, 도구 정의, 고정 문서를 static prefix로 분리한다.
• 현재 시간, request id, 사용자 질문, 검색 결과는 고정 prefix 뒤에 둔다.
• 도구 정의의 포함 여부와 순서를 작업 유형별로 고정한다.
• RAG 검색 결과는 정렬 규칙을 고정하고, 불필요하게 긴 문서는 넣지 않는다.
• Prompt Caching Dashboard에서 cache read hit rate를 확인한다.
• 비용 지표는 요청 1회가 아니라 사용자 작업 1건 단위로 계산한다.
• p50·p95 latency와 cached input token 비율을 같이 본다.
• 캐시 최적화 후에도 답변 정확도와 근거 품질을 회귀 테스트한다.

Prompt Caching은 마법 같은 할인 버튼이 아니다. 프롬프트 구조를 안정화했을 때 효과가 나는 인프라 기능이다. 긴 컨텍스트를 쓰는 AI 제품이라면 모델 교체보다 먼저 prefix 설계와 캐시 지표를 정리하는 것이 비용 절감의 빠른 출발점이다.