LLM 프롬프트 캐싱(Prompt Caching & KV Cache 재사용) 원리 해부: Prefix Caching부터 1024토큰 경계·5분 TTL과 정적/동적 컨텍스트 분리 전략까지

Transformer 어텐션 연산의 Prefill 지연을 제거하고 GPU VRAM 상에서 Key-Value(KV) 텐서를 재사용하는 LLM Prompt Caching 및 Prefix Caching 아키텍처를 상징하는 추상 기하학 아트워크다. 동심 궤도 링과 계층형 3D 아이소메트릭 KV 캐시 블록 매트릭스, 양방향 접두사 트리(Radix Branch) 노드 클러스터와 발광 에너지 프리즘 코어를 조형적으로 형상화했다.

대규모 언어 모델(LLM)과 자율형 AI 에이전트(Agentic AI) 시스템이 고도화되면서 수천 줄의 코드베이스, 수십 페이지의 기술 문서, 방대한 OpenAPI/Tools JSON 스키마를 프롬프트에 주입하는 롱 컨텍스트(Long Context) 처리가 기본 아키텍처로 자리 잡았다. 그러나 매 요청마다 수천~수만 토큰에 달하는 동일한 시스템 프롬프트와 참조 문서를 LLM 추론 엔진에 전달하면 치명적인 두 가지 병목이 발생한다. 바로 첫 토큰이 출력될 때까지 걸리는 Time-to-First-Token(TTFT) 지연시간의 급증과, 반복되는 입력 토큰으로 인해 기하급수적으로 늘어나는 막대한 API 인프라 과금이다.

결론부터 말하면 프롬프트 캐싱(Prompt Caching / Prefix Caching)은 Transformer의 어텐션 Prefill 연산 단계에서 계산된 Key-Value(KV) 텐서를 GPU VRAM에 보관하고 후속 요청에서 동일한 공통 접두사(Prefix)가 들어왔을 때 재연산 없이 $O(1)$로 KV 캐시를 재사용하는 아키텍처이며, TTFT 지연시간을 최대 80~85% 단축하고 토큰 입력 비용을 50~90% 절감한다. Anthropic(Claude), OpenAI, Google Gemini와 같은 주요 상용 플랫폼은 물론, vLLM과 SGLang의 RadixAttention 같은 오픈소스 자체 호스팅 인프라에서도 필수적인 핵심 기술로 채택되었다.

그러나 프롬프트 캐싱은 만병통치약이 아니다. 암호화 해시 트리와 순차적 토큰 블록 체인으로 동작하기 때문에 **프롬프트 첫머리에 1바이트의 공백이나 동적 타임스탬프(datetime.now())만 들어가도 뒤따르는 수만 토큰의 캐시가 전량 무효화(Cache BUST)**된다. 또한 대다수 제공업체가 1,024토큰 이상의 최소 임계치를 요구하고, 캐시 생성 시 1.25x~2.0x의 쓰기 프리미엄을 부과하므로 엄격한 '정적/동적 컨텍스트 분리'와 손익분기점(Break-even Point) 분석이 동반되어야 한다.

이 글에서는 Transformer 어텐션 연산에서 KV Cache가 생성·재사용되는 수학적 원리와 상용 플랫폼(Anthropic, OpenAI, Google Gemini) 및 오픈소스 추론 엔진(vLLM PagedAttention/RadixAttention)의 캐싱 메커니즘을 심층 비교한다. 또한 본문 도식화 다이어그램을 통해 Prefix 경계와 캐시 파괴(Cache BUST) 메커니즘을 살펴보고, 로컬 Python 시뮬레이션 스크립트로 검증한 5대 핵심 시나리오와 프로덕션 도입 체크리스트를 정리한다.

Prompt Caching의 접두사 분할 파이프라인(정적 시스템 프롬프트 캐시 히트 vs 가변 사용자 쿼리 미스)과 안티 패턴(동적 타임스탬프 전진 배치로 인한 Cache BUST) 대비 모범 사례(엄격한 정적 컨텍스트 우선 배치)를 나타낸 시스템 아키텍처 다이어그램이다.

1. Transformer 내부 동작과 KV Cache 재사용 메커니즘

LLM이 프롬프트를 입력받아 응답을 생성하는 추론 과정은 크게 두 단계로 나뉜다.

1) Prefill 단계와 Decode 단계의 본질적 차이

• Prefill (프롬프트 처리) 단계: 입력된 $N$개의 프롬프트 토큰 전체를 Transformer 레이어에 한꺼번에 밀어 넣고 병렬로 어텐션(Attention)을 계산한다. 모든 토큰 간의 내적 연산이 수행되므로 연산 복잡도는 $O(N^2)$에 달하며, 긴 문서일수록 첫 토큰이 나오기까지 걸리는 시간(TTFT)이 기하급수적으로 늘어난다. 이 과정에서 각 레이어의 Key 텐서와 Value 텐서가 계산된다.

• Decode (토큰 생성) 단계: 한 번에 단 1개의 새 토큰을 자가회귀(Autoregressive) 방식으로 생성한다. 이전 토큰들의 Key와 Value 텐서가 GPU 메모리에 KV Cache 형태로 저장되어 있다면, 새로 들어온 1개 토큰에 대해서만 Query 텐서를 구하고 저장된 KV Cache와 어텐션을 수행하므로 연산 복잡도가 $O(N)$으로 떨어진다.

2) Prompt Caching(Prefix Caching)의 혁신: Prefill 연산의 생략

전통적인 LLM API 호출에서는 새로운 HTTP 요청이 들어올 때마다 서버가 이전 요청의 컨텍스트를 전혀 기억하지 못하므로, 매번 $N$개 토큰에 대한 Prefill 연산을 처음부터 다시 수행했다.
반면 프롬프트 캐싱은 이전 요청에서 계산해 둔 Prefill 단계의 KV Cache 텐서를 GPU VRAM이나 고속 호스트 메모리에 그대로 유지한다. 새로운 요청이 들어왔을 때 프롬프트의 앞부분(Prefix)이 기존에 캐싱된 토큰 시퀀스와 정확히 일치한다면:

1. 일치하는 접두사 구간의 Prefill 연산($O(N_{prefix}^2)$ FLOPs)을 통째로 생략한다.

2. 이미 계산되어 있는 KV Cache 포인터만 즉시 연결($O(1)$)한다.

3. 오직 새로 추가된 꼬리 부분(User Query 등)의 토큰들에 대해서만 가벼운 Prefill 연산을 수행한다.

이 결과로 대규모 프롬프트에서도 TTFT 지연시간이 수 초에서 수백 밀리초 수준으로 급감(80~85% 단축)하며, GPU 연산 자원을 소모하지 않으므로 제공업체는 파격적인 입력 토큰 할인(최대 90%)을 제공할 수 있게 된다.

2. 프롬프트 캐싱을 지배하는 3대 핵심 규칙: 접두사 일치·임계치·TTL

프롬프트 캐싱을 실무 시스템에 성공적으로 적용하려면 캐시 엔진의 내부 작동 규약을 정확히 이해해야 한다.

1) The Strict Prefix Rule (엄격한 접두사 불변 법칙)

프롬프트 캐싱은 Transformer의 Causal Masking(인과적 마스크) 특성에 종속된다. 특정 토큰 $i$의 어텐션 Key/Value 값은 $0$부터 $i-1$까지의 모든 선행 토큰들에 의해 결정된다.
따라서 프롬프트의 $0$번 토큰부터 시작하는 연속된 접두사(Prefix)가 토큰 ID 수준에서 100% 동일해야만 캐시를 재사용할 수 있다.

• 만약 프롬프트 중간이나 맨 앞에 단 1글자, 공백 하나, 또는 줄바꿈 문자(\n)가 추가되거나 변경되면, 그 변경 지점 이후의 모든 토큰에 대한 KV 텐서 해시가 완전히 달라져 **뒤따르는 수천~수만 토큰의 캐시가 전량 무효화(Cache BUST)**된다.

2) 최소 토큰 임계치(Minimum Token Threshold)

KV Cache를 GPU 메모리에 할당하고, 토큰 해시를 계산하며, 캐시 인덱스 트리를 탐색하고 관리하는 데는 일정한 시스템 오버헤드가 발생한다. 따라서 모든 상용 엔진은 캐시를 활성화하기 위한 최소 토큰 임계치를 두고 있다.

• Anthropic Claude: 1,024 토큰 (Claude 3.5 Sonnet / Opus) 또는 2,048 토큰 (Claude 3.5 Haiku)

• OpenAI: 1,024 토큰 (128토큰 단위 증가 블록)

• 1,024토큰 미만의 짧은 프롬프트는 캐시 지시자를 명시하더라도 캐시가 생성되지 않으며, 일반 입력 요금으로 처리된다.

3) 슬라이딩 윈도우 TTL(Time-to-Live)과 메모리 퇴출(Eviction)

GPU VRAM은 매우 비싸고 한정된 자원이다. 사용되지 않는 캐시 텐서를 무한정 유지할 수 없으므로, 모든 엔진은 만료 시간(TTL)과 퇴출 정책을 운영한다.

• 슬라이딩 윈도우(Sliding Window): 기본 TTL은 통상 **5분(300초)**이다. 중요한 점은 해당 캐시가 읽힐(Hit) 때마다 만료 타이머가 다시 5분으로 리셋된다는 것이다. 즉, 사용자가 5분 이내에 지속적으로 대화를 이어가거나 에이전트가 툴 루프를 돌면 캐시가 만료되지 않고 무한히 연장된다.

• LRU(Least Recently Used) 퇴출: 서버 클러스터 전반에 GPU 메모리 압박이 발생하면, 가장 오랫동안 접근되지 않은 캐시 블록 체인부터 순차적으로 해제된다.

3. 주요 플랫폼별 캐싱 아키텍처 및 비용 체계 비교

프롬프트 캐싱을 지원하는 주요 상용 API 및 오픈소스 엔진의 기술 사양과 과금 모델을 비교하면 다음과 같다.

4. 정적/동적 컨텍스트 분리 아키텍처: 안티 패턴과 모범 설계

프롬프트 캐싱의 경제성을 극대화하기 위해서는 프롬프트 조립 파이프라인의 구조적 설계가 무엇보다 중요하다.

1) 치명적인 안티 패턴: Prefix Pollution (접두사 오염)

가장 흔하게 저지르는 실수는 다음과 같이 요청마다 달라지는 가변 데이터를 시스템 프롬프트 상단에 배치하는 경우다.

이 경우 뒤따르는 3,000토큰의 내용이 토씨 하나 틀리지 않고 동일하더라도, **첫 번째 토큰이 매번 바뀌기 때문에 캐시 히트율은 정확히 0%**가 된다. 사용자는 캐시 혜택을 전혀 받지 못하고 매번 100%의 Prefill 연산 지연과 비용을 부담하게 된다.

2) 모범 아키텍처: Strict Static-First Separation (정적 컨텍스트 우선 배치)

프롬프트 캐싱을 최적화하려면 프롬프트를 변동성(Volatility)에 따라 철저히 계층화하여 배치해야 한다.

1. 최상단: 시스템 지침, 에이전트 역할 정의, 도구(Tools)의 JSON Schema 전체를 불변의 형태로 배치한다.

2. 중간: RAG 검색으로 주입된 대규모 참조 문서나 고정된 Few-shot 예제를 배치하고 캐시 브레이크포인트(cache_control: {"type": "ephemeral"})를 설정한다.

3. 최하단: 가변적인 현재 시각 타임스탬프, 사용자 세션 상태, 그리고 실시간 사용자 질문을 마지막에 배치한다.

3) 캐시 쓰기 프리미엄과 손익분기점(Break-even Point) 수학적 계산

Anthropic을 비롯한 대다수 서비스는 캐시를 처음 쓸 때 **기본 토큰 가격의 1.25배(또는 2배)**를 청구한다.

• 1회만 호출되는 프롬프트의 경우: $1.25 \times Cost_{base}$로 오히려 비용이 25% 증가한다.

• 2회 호출되는 경우: 첫 회 $1.25$, 두 번째 회 $0.10$으로 총 $1.35 \times Cost_{base}$가 소요되며, 캐시를 쓰지 않았을 때($2.0 \times Cost_{base}$) 대비 32.5% 절감된다.

• 5회 호출되는 경우: $1.25 + 4 \times 0.10 = 1.65$ vs $5.0$으로 67.0% 절감된다.

• 10회 호출되는 경우: $1.25 + 9 \times 0.10 = 2.15$ vs $10.0$으로 78.5% 절감된다.

• 따라서 동일한 정적 접두사가 최소 2회 이상 재사용되는 시나리오에서만 캐싱을 활성화해야 하며, 1회성 배치 호출에는 명시적으로 캐시 지시자를 제외하는 것이 현명하다.

5. 로컬 Python으로 검증하는 Prompt Caching 라이프사이클 시뮬레이션

실제 상용 프롬프트 캐싱 엔진의 내부 핵심 규칙을 로컬 Python 스크립트(test_prompt_caching.py)로 모델링하여 직접 동작을 검증했다.

직접 실행해 확인한 5가지 핵심 검증 시나리오

로컬 터미널 환경에서 위 스크립트를 직접 실행하여 5가지 시나리오가 모두 정상 통과(All 5 Prompt Caching & KV Cache verification checks passed successfully!)함을 확인했다.

1. 최소 토큰 임계치 가드 (Case 1): 500토큰의 짧은 프롬프트를 전송했을 때, 캐시 등록 요건(1,024토큰)을 충족하지 못하므로 캐시 노드가 생성되지 않고 cached_tokens == 0, new_cache_written == False로 처리되어 불필요한 캐시 쓰기 할증이 발생하지 않음을 확인했다.

2. 대규모 접두사 캐시 생성 및 84.5% 비용 절감 (Case 2): 2,000토큰의 정적 시스템 지침과 100토큰의 사용자 질문을 조합한 2,100토큰 요청에서, 첫 회 호출 시 캐시가 등록되고 두 번째 다른 질문이 들어왔을 때 선행 2,000토큰이 정확히 캐시 히트(Hit Ratio 95.2%)되어 0.1x 할인가가 적용됨으로써 후속 턴에서 84.5%의 실질 비용 절감이 이루어짐을 검증했다.

3. 접두사 오염에 따른 Cache BUST 재현 (Case 3): 시스템 프롬프트 맨 앞에 동적 타임스탬프(timestamp_1001 vs timestamp_1002)를 전진 배치한 안티 패턴을 시뮬레이션한 결과, 뒤따르는 2,000토큰이 완전히 동일함에도 불구하고 인덱스 0번의 불일치로 인해 캐시 히트율이 0%로 곤두박질치며 100% 캐시 무효화가 발생함을 입증했다.

4. 300초(5분) 슬라이딩 윈도우 TTL 수명 연장 및 퇴출 (Case 4): 200초 경과 시점의 재요청으로 캐시 수명이 연장(Touch)되어 초기 생성 기준 450초(7.5분) 시점에도 캐시가 정상 유지됨을 확인했으며, 마지막 접근 후 301초간 유휴 상태가 지속되자 캐시가 정확히 만료 퇴출됨을 확인했다.

5. 손익분기점(Break-even) 비용 모델 수식 검증 (Case 5): 1.25x 쓰기 할증과 0.1x 읽기 할인이 적용된 상태에서 호출 횟수별 누적 비용을 분석하여, 1회 단발 호출 시에는 25% 손실이지만 2회 호출부터 즉시 순이익 구간에 진입하고 10회 연속 호출 시 전체 누적 비용이 78.5% 절감됨을 수학적으로 확인했다.

검증 범위 명시: 위 검증은 단일 머신 인메모리 상에서의 토큰 시퀀스 분기 트리, 접두사 해시 매칭, 슬라이딩 TTL 만료 및 비용 함수의 동작 무결성 시뮬레이션이다. 실제 수십 대의 GPU 클러스터로 분산된 원격 프로덕션 환경에서는 vLLM 인스턴스 간 분산 KV 전송, 테넌트별 VRAM 파편화, 네트워크 패킷 지연 및 GPU 메모리 스왑(Swap to CPU) 성능을 추가로 고려해야 한다.

6. 프로덕션 프롬프트 캐싱 도입 및 운영 실무 체크리스트

1. 정적/동적 프롬프트 템플릿 강제 린터(Linter) 도입:
• 프롬프트 생성 템플릿에서 {datetime.now()}, {uuid4()}, {session_id} 등의 변수가 상위 80% 영역에 배치되지 못하도록 CI 단계에서 정적 검사 규칙을 구축해야 한다.

2. 도구(Tools) JSON Schema의 정렬(Deterministic Key Sorting) 보장:
• Python의 딕셔너리나 JSON 직렬화 라이브러리가 도구 스키마를 덤프할 때 키 순서가 달라지면 문자열 해시가 깨져 캐시가 무효화된다. 반드시 json.dumps(obj, sort_keys=True) 옵션으로 직렬화의 결정론적 일관성을 유지해야 한다.

3. 단발성 1회 호출에 대한 캐시 명시적 비활성화:
• 재사용 가능성이 없는 비동기 배치 작업, 단일 요약 태스크 등에는 cache_control 마커를 지정하지 않아 1.25x의 불필요한 캐시 쓰기 비용을 방지해야 한다.

4. 멀티턴 대화에서의 캐시 브레이크포인트 이동 전략:
• 장기 대화 챗봇의 경우 매 턴마다 브레이크포인트를 맨 마지막 어시스턴트 메시지로 이동시키면 누적된 대화 전체를 캐싱할 수 있다. Anthropic의 경우 요청당 최대 4개의 브레이크포인트를 지원하므로 [시스템 지침] -> [참조 문서] -> [직전 턴]에 각각 배치하는 다계층 캐싱 전략이 효과적이다.

5. 자체 호스팅(vLLM/SGLang) 환경의 GPU KV 블록 풀 사이징:
• PagedAttention 기반 Prefix Caching을 구동할 때는 gpu_memory_utilization 파라미터(기본 0.9)와 block_size(16 또는 64)를 적절히 조절하여, 급격한 트래픽 유입 시에도 기존 KV 블록 체인이 조기 퇴출되지 않도록 버퍼를 확보해야 한다.

참고 자료

• Anthropic: Prompt Caching Developer Guide (공식 가이드)

• OpenAI: Prompt Caching Documentation

• Google Cloud: Gemini Context Caching API Overview

• vLLM: Automatic Prefix Caching Architecture & Documentation

• SGLang: Fast and Expressive LLM Serving with RadixAttention (GitHub)

확인 기준일: November 12, 2026