🧩 15. 운영: Prompt Caching 실전

Prompt Caching은 “모델을 바꾸면 빨라진다”보다 더 먼저 봐야 하는 운영 레버입니다. 특히 반복 작업이 많은 팀에서는 프롬프트의 공통 앞부분(prefix)을 얼마나 안정적으로 재사용하느냐가 지연시간과 입력비용에 직접 영향을 줍니다.

OpenAI 공식 가이드 기준으로 캐싱은 자동으로 동작하지만(조건 충족 시), prefix 설계·key 전략·측정 루프를 함께 운영해야 실제 성능 이득이 커집니다.

안내: 이 문서는 생성형 AI를 활용해 초안을 작성했고, 공개된 공식 자료를 바탕으로 사람이 검토·보정했습니다.

이 글의 근거 자료

• Prompt Caching 공식 가이드
  • https://developers.openai.com/api/docs/guides/prompt-caching
• prompt_cache_key API 레퍼런스
  • https://platform.openai.com/docs/api-reference/responses/create#responses-create-prompt_cache_key
• Responses object (usage.prompt_tokens_details.cached_tokens)
  • https://platform.openai.com/docs/api-reference/responses/object
• API Pricing
  • https://openai.com/api/pricing/

핵심 요약

• 캐시 히트는 정확히 같은 prefix에서만 발생한다.
• 1024 토큰 이상 요청부터 캐싱 효과가 본격적으로 나타난다.
• 핵심 운영축은 prefix 고정, prompt_cache_key 분리, cached_tokens 기반 측정이다.
• 트래픽이 한 키/프리픽스 조합으로 몰리면(가이드의 약 15rpm 언급) 캐시 효율이 떨어질 수 있다.

flowchart LR
    A["요청 입력"] --> B["고정 Prefix 정렬"]
    B --> C["prompt_cache_key 적용"]
    C --> D["보존 정책 선택\n(in_memory / 24h)"]
    D --> E["캐시 히트 측정\n(cached_tokens)"]
    E --> F["템플릿/키 튜닝"]
    F --> B

시각화 (Excalidraw)

Agent/OpenAI 비즈니스 활용/images/openai-biz-15-cache-routing.png

• 원본 편집 파일: Agent/OpenAI 비즈니스 활용/images/openai-biz-15-cache-routing.excalidraw

🧠 칠판 치트시트

• 고정 규칙/예시/툴은 앞, 사용자 변동값은 뒤
• prompt_cache_key는 워크플로우 단위로 분리
• cached_tokens를 주간 지표로 안 보면 최적화가 아니라 감 운영
• 캐시 보존정책은 성능뿐 아니라 데이터 정책 맥락까지 같이 본다

공식 문서 기준으로 꼭 알아야 할 5가지

1) 캐시는 자동이지만, 성능은 자동이 아니다

공식 가이드처럼 Prompt Caching은 별도 추가 과금 없이 자동 동작합니다. 하지만 “자동”은 최적화까지 자동이라는 뜻이 아닙니다. prefix가 흔들리면 캐시 히트율은 바로 떨어집니다.

참고:

• https://developers.openai.com/api/docs/guides/prompt-caching

2) 캐시 히트는 정확한 prefix 일치가 전제

아래가 자주 놓치는 포인트입니다.

• 같은 의미라도 문장 순서가 다르면 다른 prefix로 인식될 수 있음
• tools/structured output schema/image detail이 달라지면 히트율 하락
• 사용자 식별자/날짜 같은 변동값을 앞에 두면 매번 미스가 늘어남

실무 규칙:

• 앞(고정): system rules, output format, tools, schema, 공통 예시
• 뒤(변동): user_id, 날짜, 요청 payload

3) prompt_cache_key는 라우팅 레버

공식 문서 기준으로 prompt_cache_key는 prefix hash와 함께 라우팅에 영향을 주는 변수입니다. 같은 워크플로우에서 일관된 키를 쓰면 캐시 효율을 높이기 좋습니다.

권장 네이밍:

• ops_followup_v1
• ops_weekly_report_v1
• ops_helpdesk_v1

참고:

• https://platform.openai.com/docs/api-reference/responses/create#responses-create-prompt_cache_key

4) 보존 정책은 운영 목적에 맞춰 선택

공식 가이드에서 기본은 in_memory, 필요하면 24h 확장 보존을 지정할 수 있습니다.

• 기본(in_memory): 짧은 주기의 반복 요청에 유리
• 24h: 하루 단위 반복 요청이 많을 때 유리

단, 프로젝트의 데이터 정책(예: ZDR 운용 맥락)과 함께 판단해야 합니다.

5) 최종 판단은 cached_tokens로 닫는다

캐싱 운영은 체감이 아니라 수치로 닫아야 합니다.

• usage.prompt_tokens_details.cached_tokens
• p95 latency
• input cost

특히 1024토큰 미만 요청은 cached_tokens=0이 나올 수 있으니, 요청 크기 분포까지 함께 봐야 오판을 줄일 수 있습니다.

참고:

• https://platform.openai.com/docs/api-reference/responses/object
• https://openai.com/api/pricing/

바로 붙여 쓰는 코드

1) Responses API 기본 예시 (Python)

from openai import OpenAI
 
client = OpenAI()
 
response = client.responses.create(
    model="gpt-5.1",
    input=[
        {
            "role": "system",
            "content": "너는 운영 자동화 도우미다. 출력 형식은 JSON으로 고정한다."
        },
        {
            "role": "user",
            "content": "이번 주 follow-up 메일 초안을 3개 만들어줘."
        }
    ],
    prompt_cache_key="ops_followup_v1",
    prompt_cache_retention="in_memory"  # 또는 "24h"
)
 
usage = getattr(response, "usage", None)
prompt_details = getattr(usage, "prompt_tokens_details", None)
cached_tokens = getattr(prompt_details, "cached_tokens", 0)
print("cached_tokens:", cached_tokens)

2) Prefix 고정 템플릿 패턴

[System rules - 고정]
[Output schema - 고정]
[Tool definitions - 고정]
[Few-shot examples - 고정]
 
[Dynamic block - 변동]
- tenant_id:
- user_id:
- date:
- request_payload:

3) 주간 비용/지연 점검 코드 (개념 예시)

# logs: [{cached_tokens, prompt_tokens, latency_ms, req_count}, ...]
 
def summarize(logs):
    total_prompt = sum(x["prompt_tokens"] for x in logs)
    total_cached = sum(x["cached_tokens"] for x in logs)
    hit_ratio = (total_cached / total_prompt) if total_prompt else 0
 
    p95_latency = sorted(x["latency_ms"] for x in logs)[int(len(logs) * 0.95) - 1]
    return {
        "cached_ratio": round(hit_ratio, 4),
        "p95_latency_ms": p95_latency,
        "requests": sum(x["req_count"] for x in logs),
    }

미니 사례 3가지

사례 A) Follow-up 자동화 (성공)

초기에는 고객사명/담당자명을 프롬프트 상단에 넣어 캐시가 거의 안 먹었습니다. 공통 규칙/예시를 앞으로, 고객사 개별값을 뒤로 이동한 뒤 cached_tokens가 눈에 띄게 증가했습니다.

사례 B) 주간 보고서 (실패 → 복구)

prompt_cache_key를 단일 키로 몰아 쓰다가, 트래픽 몰림 구간에서 지연 편차가 커졌습니다. 워크플로우별 키를 분리하고 템플릿 버전을 나누자 지연 분산이 안정화됐습니다.

사례 C) 내부 QA 봇 (품질 개선)

FAQ 규칙과 출력 포맷이 매번 바뀌어 응답 톤이 흔들렸습니다. prefix를 고정하고 key를 일관되게 운용하자 응답 일관성과 비용 예측 가능성이 함께 올라갔습니다.

30분 도입 루틴

1. 10분: 현재 프롬프트를 고정/변동 블록으로 분리
2. 8분: 워크플로우별 prompt_cache_key 네이밍 규칙 확정
3. 7분: 로그에 cached_tokens, prompt_tokens, latency 필드 강제
4. 5분: 다음 주 실험 1건 예약(템플릿 정렬 또는 key 분리)

완료 기준:

• cached_tokens 비율 상승
• p95 latency 하락
• 월간 입력비용 예측 오차 축소

적용 체크리스트

• 시스템 규칙/예시/툴 스키마를 prefix 앞쪽에 고정했다
• 사용자별 변동값을 뒤쪽 블록으로 분리했다
• 워크플로우별 prompt_cache_key를 분리했다
• prompt_cache_retention 정책을 운영 목적에 맞게 선택했다
• cached_tokens, p95, input cost를 주간 리포트로 추적한다

다음 읽기

• 🧩 14. 운영: 하네스 엔지니어링 실전
• 🧩 16. 운영: Eval Skills 실전
• 🧩 11. 운영: 반복업무 자동화 실전
• 🧩 12. 운영: 11편 다음 자동화 꿀팁