LLM 프롬프트 캐싱 #4: 챗봇·RAG·에이전트를 위한 최적 모델

TL;DR —— “최적의” LLM을 고르는 것은 단일 벤치마크 문제가 아닙니다. 당신이 출시하려는 것이 챗봇인지, RAG/배치 API인지, AI 에이전트인지에 따라 달라집니다. 각 형태는 프롬프트 구조, 적중률 프로파일, TTL 적합성, 지연 허용도가 다르며, 이는 모델 + 캐싱 전략의 최적 조합도 달라지게 만듭니다. 본 가이드는 Part 3에서 측정한 수치를 기반으로 합니다——같은 게이트웨이, 같은 OpenAI SDK, 호출마다 model 필드만 바꿉니다.

시리즈: 전 4부 중 Part 4 · 이전까지: Part 1 — 캐싱 원리 · Part 2 — 프로바이더 비교 및 평가 · Part 3 — 실전 코드 튜토리얼

0. 보편적인 비용 공식

유스케이스로 들어가기 전에, 모든 선택이 최적화해야 할 방정식을 살펴봅시다.

per-call cost = (input_uncached × P_in)
              + (input_cached   × P_in × cache_discount)
              + (output × P_out)

per-call TTFT ≈ prefill_time × (1 - hit_rate)
              + decode_time

네 가지 레버:

1. 단가를 낮춘다(P_in / P_out) → 더 저렴한 모델을 고른다.
2. 적중률을 높인다 → 프롬프트를 재구성하고, TTL을 트래픽 리듬에 맞춘다.
3. 캐시 할인 계수를 낮춘다 → 캐싱이 더 강력한 프로바이더를 고른다.
4. 캐시된 프리필이 가장 빠른 프로바이더를 고른다 → UX에서 지연은 중요하다.

아래 각 유스케이스는 이 레버들을 서로 다른 방식으로 당깁니다.

유스케이스 1: 챗봇, 고객 지원, 어시스턴트

트래픽 프로파일

• 각 요청 = 긴 시스템 프롬프트(페르소나 + 지식 + 규칙) + 멀티턴 히스토리 + 새 사용자 메시지.
• 평균 컨텍스트: 4K~20K 토큰.
• 사용자는 첫 토큰까지의 시간에 극도로 민감하다(2초 초과면 망가진 느낌).
• 세션 내에서 요청은 수 초~수 분 간격으로 도착——어느 프로바이더의 캐시 TTL에도 충분히 들어간다.

왜 챗봇은 거의 저절로 캐싱되는가

챗봇은 가장 캐시 친화적인 워크로드입니다. 단일 세션 내에서:

Request 1: [system: 8K] + [history: 0]   + [user: Q1]
Request 2: [system: 8K] + [history: 200] + [user: Q2]
Request 3: [system: 8K] + [history: 400] + [user: Q3]
           ↑──────── prefix is monotonically growing ────────↑

메시지 간 간격이 TTL 이내(어느 프로바이더든 몇 분)로 유지되면, 시스템 프롬프트 부분은 별다른 노력 없이 90%+ 적중률을 달성합니다. 킵얼라이브가 필요 없습니다.

모델 추천(측정: 2026-05)

* 7,300 토큰의 안정적인 시스템 프롬프트에 대해 측정, 단일 순차 실행, 동시 부하 없음. 전체 표는 Part 3 §6 참조.

최소 프로덕션 코드

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

def chat(history: list, user_msg: str):
    return client.chat.completions.create(
        model="gpt-5.4-mini",
        max_tokens=512,
        messages=[
            {"role": "system", "content": STABLE_SYSTEM_PROMPT},   # front
            *history,                                              # middle
            {"role": "user", "content": user_msg},                 # back
        ],
    )

이게 전부입니다. 위에 나열된 모든 모델에서 캐싱은 자동입니다. 마커가 필요 없습니다. 개발 중에는 resp.usage.prompt_tokens_details.cached_tokens를 읽어 적중을 확인하세요.

챗봇의 함정

• ❌ 현재 타임스탬프를 시스템 프롬프트에 넣지 마세요("Today is 2026-05-25 14:30:25"). 초 단위 정밀도는 매번 캐시를 무효화합니다.
• ❌ 매 턴마다 히스토리를 다시 이어붙이지 마세요——메시지 배열 순서를 바이트 단위로 동일하게 유지하고, 추가(append-only)만 하세요.
• ✅ 사용자 페르소나 데이터는 첫 번째 사용자 메시지에 두고, 시스템 프롬프트에는 두지 마세요——그러면 사용자별 차이가 공유 프리픽스를 오염시키지 않습니다.
• ✅ TTL을 넘겨 식어버린 세션에는, 사용자의 다음 메시지가 도착하기 전에 1토큰 킵얼라이브 핑을 보내세요(Part 3 §8.2 참조).

유스케이스 2: API 워크로드(RAG, 콘텐츠 생성, 배치 처리)

트래픽 프로파일

• RAG Q&A: 입력 = 안정적인 시스템 + 가변 검색 문서 + 가변 쿼리.
• 콘텐츠 생성(마케팅 카피, 코드, 번역): 안정적인 템플릿, 변하는 데이터.
• 배치 처리(문서 분류, 데이터 클렌징): 대량의 동일 작업.
• 지연은 부차적; 호출당 비용이 지배적.

어려운 문제: 검색이 프리픽스를 재정렬한다

RAG의 핵심 캐싱 문제: 검색된 문서가 호출마다 바뀌어 프롬프트 중간에서 프리픽스를 깨뜨린다.

Request 1: [system: 3K] + [doc_A, doc_B, doc_C] + [user: Q1]
Request 2: [system: 3K] + [doc_B, doc_D, doc_A] + [user: Q2]
           ↑─ hits ─────↑  ↑──── miss ─────────↑

복잡도가 증가하는 세 가지 해결책:

해결책 A —— 검색 문서를 앞이 아니라 뒤로 밀어라.

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},          # ~3K, stable
    {"role": "system", "content": INSTRUCTION_TEMPLATE},   # ~500, stable
    {"role": "user",   "content": f"References:\n{retrieved_docs}\n\nQuestion: {q}"},
]

결과: system 부분 전체(안정적인 약 3.5K 토큰)가 캐싱됩니다. 각 호출에서 미스되는 것은 사용자 대면 부분뿐입니다. 대부분의 프로덕션 RAG에는 이것으로 충분합니다. gpt-5.4-mini로 이 패턴을 측정한 적중률: 시스템 토큰에서 80%+.

해결책 B —— 결정론적 검색 정렬. 검색 청크를 관련도 점수가 아니라 안정적인 키(doc_id 오름차순)로 정렬하세요. 고빈도 청크가 일관된 위치에 머물러 프리픽스가 더 자주 일치합니다. 랭커의 정확도가 약간 손실되지만, 보통은 무관합니다.

해결책 C —— 벤더 정식 SDK를 통한 네이티브 명시적 캐시 마커. Anthropic Claude를 (이 게이트웨이 경유가 아니라) 직접 사용한다면, 여러 cache_control 패턴으로 “절대 안 바뀜” + “거의 안 바뀜” + “작업마다 바뀜”을 별도의 브레이크포인트로 캐싱할 수 있습니다. SDK를 하나 더 끌고 갈 수 있을 때 복잡한 RAG에 탁월합니다.

API 워크로드의 TTL 고려사항

• 지속적 트래픽(24/7 RAG 엔드포인트): 5분 TTL이면 충분——윈도우 안에 항상 다음 요청이 있습니다.
• 버스트 / cron(매일 09:00 배치): 긴 TTL 프로바이더(deepseek-v4-flash가 테스트 세트 중 가장 오래 유지됨)를 쓰거나, 실행 윈도우 동안 TTL/2마다 1토큰 킵얼라이브를 보내세요. 패턴은 Part 3 §8.2.

작업별 모델 추천

† Claude의 여러 cache_control 마커는 계층형 RAG에서 타의 추종을 불허합니다——게이트웨이를 가리키는 anthropic SDK를 사용, Part 3 §2 참조.

RAG 비용 스케치(10만 쿼리/일)

3K 시스템 + 5K 검색 문서 + 200토큰 쿼리 + 300토큰 출력. 수치는 Part 3 §6에서 측정한 단일 호출 비용에서 스케일한 것——단일 테넌트, 동시 부하 없음.

자릿수 단위로만 받아들이세요. 실제 프로덕션에는 동시 호출과 버스트가 있고, 검색 문서 길이 분포가 계산을 지배합니다.

RAG / API의 함정

• ❌ 검색 청크를 동적 관련도 점수로 정렬하지 마세요——요청마다 고유한 프리픽스가 됩니다.
• ❌ 스트리밍 시 사용량 로그를 버리지 마세요——비용 귀속이 무너집니다. stream_options={"include_usage": True}를 전달하고 prompt_tokens_details.cached_tokens와 usage.cost를 저장하세요.
• ✅ 배치 작업에서는 캐싱 위에 벤더 Batch API(OpenAI Batch, Anthropic Message Batches)를 얹어 약 50%를 추가로 절감하세요——이것은 이 게이트웨이 밖에서, 프로바이더를 직접 호출하여 수행합니다.

유스케이스 3: AI 에이전트(다단계 추론, 도구 사용, 긴 체인)

트래픽 프로파일

• 하나의 에이전트 작업 = 도구 결과와 번갈아 끼어드는 다수의 LLM 호출.
• 매우 긴 컨텍스트(시스템 + 도구 + 누적 히스토리): 10단계까지 보통 30K~100K 토큰.
• 고도로 구조화된 프롬프트: 길고 안정적인 프리픽스, 작고 가변적인 꼬리.
• 지연과 비용 모두 중요——프리필이 1초 늘 때마다 눈에 보이는 대기가 더해지고, 15단계 에이전트는 그것을 15배로 만듭니다.

왜 에이전트는 캐싱에 의존하는가

각 단계는 이전 단계의 도구 호출과 결과에 추가됩니다. 캐싱이 없으면 매 단계가 수만 토큰의 프리필을 다시 지불합니다.

Step 1: [system: 5K] + [tools: 3K]
Step 2: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
Step 3: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
                                   + [call_2: 1K] + [result_2: 5K]
        ↑──── prefix grows monotonically — perfect for caching ────↑

핵심 규칙: 도구 호출과 결과는 단계 간에 추가 전용이며 바이트 단위로 동일해야 합니다. 어떤 재작성이나 재정렬도 그 지점부터 캐시를 죽입니다. 가장 흔한 에이전트 버그는 “다시 보내기 전에 도구 결과를 정리했다” → 캐시율이 0으로 떨어짐 → 비용과 지연이 몇 배로 증가하는 것입니다.

TTL 매칭 —— 그것이 중요해지는 유일한 유스케이스

전형적인 에이전트 작업은 10~60초 동안 실행됩니다. 단일 작업 내에서는 기본 5분 TTL이면 괜찮습니다. 하지만 사람의 승인을 기다리는 에이전트(“이 계획을 검토하고 응답하세요”)는 몇 분간 유휴 상태일 수 있습니다. 사람이 10분간 멈추고 캐시가 식어버리면, 후속 단계는 50K 토큰의 프리필을 다시 지불합니다. 그런 워크플로에는 다음 중 하나를 하세요:

• 더 긴 TTL의 프로바이더를 사용한다(deepseek-v4-flash가 테스트 세트 중 가장 오래 유지됨), 또는
• 대기하는 동안 TTL/2마다 킵얼라이브 핑을 보낸다(Part 3 §8.2 참조).

에이전트 모델 추천

에이전트는 추론 능력을 요구합니다——품질을 먼저 고른 뒤 비용을 최적화하세요.

† Claude의 4개 cache_control 마커 패턴은 에이전트 캐싱에서 여전히 가장 강력한 구성입니다(10+ 단계에 걸친 누적 프리픽스 할인). 게이트웨이를 가리키는 anthropic SDK를 사용하세요——정확한 페이로드 형태와 TTL 옵션은 Part 3 §2 참조.

실제 비용 추정: 15단계 에이전트 작업

5K 시스템 + 3K 도구 + 단계마다 약 3K 추가, 총 15단계를 가정. Part 3 §6의 호출당 비용을 에이전트 형태로 스케일:

다시 한번, 스케치 수치입니다. 지배적인 변수는 당신이 실제로 프리픽스를 단계 간 바이트 단위로 동일하게 유지하느냐입니다.

에이전트의 함정

• ❌ 매 단계 메시지 리스트를 다시 만들지 마세요——배열을 바이트 단위로 동일하게 유지하고, 추가만 하세요.
• ❌ 도구 결과를 잘라내거나 재포맷하지 마세요——어떤 바이트 변화도 하위 캐시를 무효화합니다.
• ❌ 동시 실행되는 에이전트 인스턴스 간에 캐시 키를 공유하지 마세요——단계 순서가 갈라져 서로를 오염시킵니다.
• ✅ 작업마다 cache_creation_tokens : cache_read_tokens를 모니터링하세요——10단계까지 건강한 비율은 1:50 이상입니다.

마스터 의사결정 매트릭스

                            ┌─ Chinese-heavy ─→ deepseek-v4-flash + auto cache
                  ┌─ High ─→│
                  │          └─ Global users ──→ gpt-5.4-nano / claude-haiku-4-5
   Chatbot ──────→│
                  │          ┌─ Quality-first ─→ gpt-5.4-mini / claude-sonnet-4-5
                  └─ Mid ──→│
                            └─ Balanced ──────→ gemini-2.5-flash / qwen3-max

                            ┌─ Chinese RAG ───→ deepseek-v4-flash / qwen3-max
                  ┌─ Live ─→│
                  │          └─ English RAG ───→ gpt-5.4-mini / claude-sonnet-4-5†
   API ──────────→│
                  │          ┌─ Translation ───→ gpt-5.4-nano (template caches)
                  └─ Batch →│
                            └─ Doc review ────→ qwen3.5-flash + Batch APIs

                            ┌─ Simple ────────→ deepseek-v4-flash / qwen3-max
                  ┌─ China ─→│
                  │          └─ Complex ───────→ qwen3-max (plan) + deepseek (execute)
   Agent ────────→│
                  │          ┌─ Simple ────────→ gpt-5.4-mini + auto
                  └─ Global →│
                            └─ Complex ───────→ claude-sonnet-4-5† / gpt-5.5-pro

  † Claude with multi-`cache_control` breakpoints via the `anthropic` SDK pointed at the gateway (see Part 3 §2)

유스케이스별 TTL 빠른 참조

이 게이트웨이가 하는 것과 하지 않는 것

기대치를 솔직히 설정하기 위해:

오른쪽 항목 중 어느 것이든 오늘 당장 필요하다면, 애플리케이션 레이어에서 또는 벤더 SDK를 직접 사용하여 구현하세요. 이 게이트웨이는 얇은 프록시에 가격 레이어를 더한 것입니다. 캐싱과 관련된 모든 것은 업스트림 모델 레이어에서 일어납니다.

최종 요점

전 4부 시리즈는 네 줄로 압축됩니다.

캐싱은 하나가 아니라 두 개의 승리. 비용과 지연 모두. 안정적인 콘텐츠를 먼저, 변동하는 콘텐츠를 나중에. 프리픽스 규율은 공짜, 어디서든 실천하라. 모델 + 캐시 동작을 유스케이스에 맞춰라. 챗봇 ≠ RAG ≠ 에이전트. 자신의 트래픽으로 측정하라. 단일 실행 벤치마크는 출발점이지 정답이 아니다.

여기서 가장 빠른 길: 위 매트릭스에서 자신에게 가장 가까운 유스케이스를 고르고, 구조적 변경(안정 우선 프리픽스, 결정론적 검색, 바이트 단위로 동일한 에이전트 상태)을 적용한 뒤, cached_tokens와 usage.cost를 일주일간 기록하고 나서 재평가하세요.

FAQ

중국어 챗봇에 가장 저렴한 LLM은? 저희 테스트 세트에서 deepseek-v4-flash와 qwen3.5-flash는 중국어 텍스트에서 영어 튜닝 모델보다 한 자릿수 더 저렴하면서도, 전형적인 챗봇 워크로드의 품질에서 gpt-5.4-mini에 필적합니다.

2026년 RAG에 가장 좋은 LLM은? 영어: gpt-5.4-mini를 해결책 A 프롬프트 레이아웃(시스템 토큰을 앞에, 참조를 맨 아래)으로 사용하면 안정 부분에서 80%+ 적중률을 얻습니다. 중국어: deepseek-v4-flash. 자주 쿼리되는 매우 긴 문서: gemini-2.5-pro(1M+ 토큰 컨텍스트를 네이티브로 처리).

에이전트에는 GPT를 써야 할까 Claude를 써야 할까? 둘 다 강력합니다. 선택은 캐시 규율에 얼마나 투자하고 싶은지에 달려 있습니다. Claude의 4개 cache_control 마커 패턴(게이트웨이를 향한 anthropic SDK 경유)은 누적 에이전트 프리픽스에 유독 강력합니다——프리픽스가 따뜻해지면 10+ 단계에 걸쳐 입력 비용을 약 90% 줄입니다. OpenAI 형태의 클라이언트에 머물면서 마커 없이 약 50%의 캐시 절감을 받아들이고 싶다면, gpt-5.4-mini 또는 gpt-5.5-pro가 마찰이 더 적은 선택입니다.

“단순한” LLM 사용에서 “최적화된” 사용으로 바꾸면 현실적으로 얼마나 절약할 수 있나? 이 시리즈의 측정 실행에서: 같은 모델로 50~88% 비용 절감과 30~60% TTFT 절감. 이득의 대부분은 다른 모델을 고르는 것이 아니라 적중률을 80% 이상으로 끌어올리는 데서 옵니다.

어디서 시작해야 하나? 매트릭스에서 자신에게 가장 가까운 유스케이스를 고르세요. 구조적 프롬프트 변경을 적용하세요. 일주일간의 프로덕션 트래픽에서 cached_tokens와 usage.cost를 측정하세요. 그런 다음에야 모델 전환을 고려하세요.

출처 및 검증: 측정 수치는 Part 3 §6에서, https://synthorai.io/v1, 2026-05-25 기준, openai SDK 2.38.0. 벤더 가격 페이지: OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian.

← 블로그로 돌아가기