LLM 프롬프트 캐싱 (Prompt Caching): 2026년 완전 가이드

만약 여러분이 대규모 언어 모델 (LLM)을 기반으로 챗봇, RAG 앱, 또는 AI 에이전트를 출시한다면, 프롬프트 캐싱 (Prompt Caching)은 품질 저하 없이 입력 비용의 50~~90%를 절감하고 첫 번째 토큰 생성 시간 (Time-to-first-token)을 3~~10배 단축해 주는 단 하나의 최적화 방법입니다. 이것은 단순히 덧붙이는 기술이 아닙니다. Transformer 어텐션 (Attention)이 정의되는 방식에서 직접적으로 도출되는 결과입니다. 이를 한 번 이해하고 나면, 나머지 스택 (TTL, 제공업체별 차이, 프롬프트 구조)이 깔끔하게 정리될 것입니다.

이 페이지는 이론부터 프로덕션 의사결정 매트릭스까지 안내하는 4부작 시리즈의 인덱스입니다. 이미 알고 있는 지식에 따라 시작 지점을 선택하세요.

시작 지점

원하는 내용	시작 지점
캐싱이 왜 존재하는지, 그리고 KV 캐시 (KV Cache)가 실제로 무엇인지 이해하고 싶다면	Part 1 — KV 캐시 및 TTL 작동 방식
...

각 파트는 독립적이지만, 순서대로 읽으면 중복 없이 전체적인 그림을 그릴 수 있도록 작성되었습니다.

Part 1 — LLM 프롬프트 캐싱의 작동 방식

LLM 프롬프트 캐싱 #1: KV 캐시 및 TTL 작동 방식 →

아키텍처 중심의 기사입니다. 셀프 어텐션 (Self-attention)을 하나의 방정식으로 살펴보고, 안정적인 접두사 (Prefix)의 K 및 V 벡터가 수학적으로 왜 재사용 가능한지 설명하며, 메모리 대 연산 (Memory-vs-compute) 트레이드오프가 모든 개발자가 설계 시 고려해야 하는 TTL 동작을 어떻게 만들어내는지 보여줍니다.

핵심 요점:

프롬프트 캐싱 (Prompt Caching)은 상위에 추가된 최적화 계층이 아니라, 인과적 마스크 어텐션 (Causal-masked attention)의 직접적인 결과입니다. 위치 i에서의 K/V는 토큰 1…i의 결정론적 함수이므로, 동일한 접두사 (Prefix)는 비트 단위로 동일한 K/V를 생성합니다.
캐싱이 절약하는 것은 프리필 (Prefill, 연산 제한적 (Compute-bound), O(N²)) 단계이며, 디코딩 (Decode, 메모리 대역폭 제한적 (Memory-bandwidth-bound), 토큰당 O(N)) 단계는 모든 추론 엔진이 이미 최적화하고 있는 부분입니다.
TTL (Time-To-Live)이 존재하는 이유는 KV 캐시 (KV cache)가 매우 거대하기 때문입니다 (70B 모델의 32K 컨텍스트 기준 약 10 GB). 5분은 GPU 메모리 압박의 임계점이며, 몇 시간에서 며칠 단위의 TTL은 디스크 기반 캐시 (Disk-backed caches, DeepSeek의 MLA 아키텍처)를 통해서만 가능합니다.
캐싱은 비용 (캐시 히트 시 입력 비용 50–90% 절감)과 지연 시간 (5~~10K 토큰 범위의 프롬프트에서 TTFT가 3~~10배 감소하며, 100K 이상의 경우 훨씬 더 큰 감소) 측면 모두에서 이점을 제공합니다.

파트 2 — 제공업체별 LLM 프롬프트 캐싱 비교

LLM 프롬프트 캐싱 #2: Claude, GPT, Gemini, DeepSeek 비교 →

구매자 가이드입니다. 다섯 가지 제공업체가 매우 다른 다섯 가지 형태로 프롬프트 캐싱을 제공합니다 — 명시적 마커 (Claude), 완전 자동 (GPT-5, DeepSeek-v4), 하이브리드 암시적+명시적 (Gemini, Qwen), 또는 아키텍처적 디스크 지원 (DeepSeek의 MLA). 이 기사는 기능별 비교와 함께 귀하의 특정 워크로드에 맞춰 점수를 매길 수 있는 **5차원 평가 프레임워크 (5-dimension evaluation framework)**를 제공합니다.

핵심 요점:

기본 가격을 비교하지 마세요 — 히트율 (Hit rate)에 따라 가중치를 둔 실질 비용을 비교하세요 (§4.1의 공식 참조).
Claude는 단일 호출당 가장 높은 할인율 (~90%)을 제공하지만, 명시적인 cache_control 마커가 필요합니다.
DeepSeek-v4는 대규모 디스크 기반 캐시를 제공하는 유일한 제공업체입니다. 부분 접두사 일치 (Partial-prefix matches) 시 할인이 적용되는데, 이는 입도 (Granularity)가 1,024가 아닌 64 토큰이기 때문입니다.
Gemini의 명시적 캐시는 시간당 저장 비용이 발생합니다 — 손익분기점은 호출 빈도에 따라 달라집니다.
히트율을 통제 변수로 두었을 때, 제공업체를 실제로 구분 짓는 다섯 가지 차원은 API 사용 편의성 (API ergonomics), 히트율 예측 가능성, TTL 적합성, 미스(Miss) 시의 지연 시간, 그리고 마이그레이션 비용입니다.

Part 3 — 실습 Python 튜토리얼 (Working Python Tutorial)

LLM Prompt Caching #3: 실습 Python 튜토리얼 →

실습 중심의 기사입니다. 단일 게이트웨이를 대상으로 OpenAI SDK 하나와 Anthropic SDK 하나를 비교하였으며, 2026-05-25 기준으로 Claude 제품군 전체(haiku-4-5부터 opus-4-7까지), GPT-5.x, Gemini 2.5, DeepSeek-v4, 그리고 Qwen3에 대한 측정 수치를 제공합니다.

핵심 요약:

cache_control 마커를 사용한 Claude: haiku/sonnet/opus 4-x 전반에 걸쳐 일관되게 88–89%의 비용 절감을 측정했습니다. base_url="https://synthorai.io/"를 포함한 Anthropic SDK를 사용하세요.
GPT-5.4-mini 자동 캐싱 (auto-cache): TTFT (첫 토큰 생성 시간)가 5배 개선되었습니다 (7K 토큰 프롬프트 기준 3.6초 → 0.73초). 시스템 토큰에 대해 93%의 캐시 히트율 (cache hit rate)을 기록했습니다.
Gemini 2.5-flash 암시적 캐싱 (implicit): 스트리밍 사용량이 캡처될 때 캐시 히트 시 88%의 비용 절감을 보여주었습니다.
DeepSeek-v4-flash: 74% 할인 효과가 있으며, 디스크 기반 (disk-backed)으로 작동합니다 (캐시가 시간 단위의 유휴 상태에서도 유지됨).
TTL 인지 패턴 (TTL-aware patterns): 크론 (cron) 작업을 위한 keep-alive 하트비트, 접두사 안정성 규칙 (prefix stability rules), 호출당 로그 기록 방법 등을 다룹니다.

Part 4 — 사용 사례별 최적의 모델 (Best Model by Use Case)

LLM Prompt Caching #4: 채팅, RAG 및 에이전트를 위한 최적의 모델 →

의사결정을 위한 기사입니다. 서로 다른 워크로드 (workloads)에 따라 비용과 지연 시간 (latency) 레버가 다르게 작동합니다. 채팅은 본질적으로 캐시에 친화적이며, RAG는 접두사 안정성 (prefix-stability) 문제와 싸워야 하고, 에이전트 (agents)는 누적된 접두사 규율 (cumulative prefix discipline)에 의존합니다. 이 기사는 워크로드 형태에 따른 모델 추천과 비용 추정치를 제공합니다.

핵심 요약:

Chatbots (챗봇): 자동 캐싱 (auto-cache) 기능이 있는 모델이라면 무엇이든 작동하며, 세션이 자연스럽게 캐시를 활용합니다. 비용과 품질에 따라 선택하세요. gpt-5.4-nano가 가장 저렴하며, gpt-5.4-mini가 캐싱된 첫 토큰 생성 시간 (TTFT)이 가장 빠르고, claude-haiku-4-5는 적절한 프리미엄을 지불하면서 가장 뛰어난 지시 이행 (instruction-following) 능력을 보여줍니다.
RAG (검색 증강 생성): 검색된 문서의 재정렬은 프롬프트 중간의 캐시 히트 (cache hit)를 저해합니다. 세 가지 해결책이 있습니다. 참조 문서를 끝으로 밀어넣기, 결정론적 청크 순서 (deterministic chunk ordering) 지정, 또는 Claude의 멀티 cache_control 중단점 (breakpoints) 활용입니다.
Agents (에이전트): 도구 호출 (tool calls)과 결과는 반드시 추가 전용 (append-only) 방식이어야 하며, 단계별로 바이트 단위까지 동일 (byte-identical)해야 합니다. 4개의 cache_control 마커를 사용하는 claude-sonnet-4-5가 가장 강력한 누적 접두사 (cumulative-prefix) 할인을 제공하며, gpt-5.4-mini는 코드 변경 없이도 50%의 비용 절감 효과를 얻을 수 있습니다.
TTL (Time-to-Live) 매칭: 채팅은 5분, 인간 참여 (human-in-the-loop) 단계가 있는 에이전트는 1시간, 간헐적인 배치 (batch) 작업은 디스크 기반 (disk-backed) 설정을 권장합니다.

이 가이드를 읽는 법

이 주제가 처음인 엔지니어: 순서대로 읽으세요. 파트 1의 아키텍처 (architecture)를 이해하면 파트 2~4의 내용이 즉시 이해됩니다.
벤더 선정을 진행 중인 PM 또는 아키텍트: 파트 2와 파트 4로 바로 이동하세요. 팀원이 "왜 TTL이 존재하는가"라고 묻는다면 파트 1을 참조하세요.
오늘 당장 특정 워크로드를 배포해야 하는 엔지니어: 파트 4를 먼저 보고 (매트릭스에서 해당 행 찾기), 정확한 코드를 위해 파트 3을 확인하세요.
기존 앱을 최적화하려는 모든 사람: 파트 3의 §6 교차 제공업체 벤치마크 (cross-provider benchmark)를 확인하세요. 자신의 프롬프트에 대해 이를 재현해 보세요. 이는 몇 주간의 마이그레이션이 아니라 단 하루면 끝나는 작업입니다.

이 시리즈의 수치 데이터

모든 측정 수치는 2026-05-25에 Synthorai 게이트웨이(OpenAI 호환용 https://synthorai.io/v1, Anthropic 네이티브용 https://synthorai.io/)를 대상으로 측정되었습니다. 단일 테넌트(single-tenant), 단일 순차 실행(single sequential run) 조건이며 동시 부하(concurrent load)는 없었습니다. 귀하의 수치는 지역, 시간대, 경쟁 테넌트의 부하에 따라 변동될 수 있습니다. 이 수치들을 인용하기 전에 시작점으로 삼아 귀하의 트래픽에 맞춰 재현해 보시기 바랍니다.

가격표와 TTL 동작은 2026년 5월 기준 제공업체의 공개 문서를 반영합니다. 제공업체들은 몇 달마다 이를 업데이트합니다. 아키텍처적 근거 (파트 1)는 안정적이지만, 비교 수치 (파트 2 및 3)는 변동될 수 있습니다.