용도별 최고의 LLM (2026): 채팅, RAG, 에이전트 비용 매트릭스

TL;DR — “최고의” LLM은 벤치마크 하나로 정할 수 없습니다. 챗봇, RAG/배치 API, AI 에이전트 중 무엇을 구축하느냐에 따라 답이 달라집니다. 용도마다 prompt 구조, hit rate 특성, TTL 적합성, 허용 가능한 latency가 다르므로 최적의 모델과 caching 전략 조합도 달라집니다. 이 가이드는 파트 3에서 측정한 수치를 기반으로 합니다. 동일한 gateway와 OpenAI SDK를 사용하며, 호출할 때마다 model 필드만 바꿉니다.

시리즈: 전체 5편 중 파트 4 · 이전 글: 파트 1 — Caching 원칙 · 파트 2 — Provider 비교 및 평가 · 파트 3 — 실행 가능한 코드 튜토리얼 · 다음 글: 파트 5 — LangChain 연동

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. Hit rate 높이기 → prompt 구조를 바꾸고, 트래픽 주기에 TTL을 맞춥니다.
3. Cache 할인 계수 낮추기 → caching 할인이 더 큰 provider를 선택합니다.
4. Cached prefill이 가장 빠른 provider 선택하기 → UX에는 latency가 중요합니다.

아래의 각 용도에서는 이 요소들을 서로 다르게 조정합니다.

용도 1: 챗봇, 고객 지원, 어시스턴트

트래픽 특성

• 각 요청은 긴 system prompt(페르소나 + 지식 + 규칙), 멀티턴 history, 새 사용자 메시지로 구성됩니다.
• 평균 context는 4K–20K tokens입니다.
• 사용자는 time-to-first-token에 매우 민감합니다. 2초를 넘기면 서비스가 고장 난 것처럼 느낍니다.
• 한 session 안에서는 요청 간격이 수초에서 수분 정도이므로 모든 provider의 cache TTL 안에 들어옵니다.

채팅은 별도 작업 없이도 Cache가 잘 맞는 이유

채팅은 caching 효율이 가장 좋은 workload입니다. 단일 session 안에서 요청은 다음과 같이 쌓입니다.

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 이내라면 모든 provider에서 수분 안에 다음 요청이 들어옵니다. 별도 작업 없이도 system prompt 부분의 hit rate가 90%를 넘습니다. Keep-alive도 필요하지 않습니다.

모델 추천(2026-05 측정)

* 안정적인 7,300-token system prompt를 사용해 동시 부하 없이 한 번씩 순차 측정했습니다. 전체 표는 파트 3 §6을 참고하세요.

최소한의 Production 코드

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
        ],
    )

이것으로 충분합니다. 위에 나열한 모든 모델은 marker 없이 자동으로 caching됩니다. 개발 중에는 resp.usage.prompt_tokens_details.cached_tokens를 확인해 cache hit 여부를 검증하세요.

챗봇에서 주의할 점

• ❌ 현재 timestamp를 system prompt에 넣지 마세요("Today is 2026-05-25 14:30:25"). 초 단위 값이 바뀔 때마다 모든 cache가 무효화됩니다.
• ❌ 매 turn마다 history를 다시 조립하지 마세요. Message array의 순서와 byte를 그대로 유지하고 뒤에만 추가해야 합니다.
• ✅ 사용자 페르소나 데이터는 system prompt가 아니라 첫 번째 user message에 넣으세요. 그러면 사용자별 차이로 shared prefix가 깨지지 않습니다.
• ✅ TTL을 넘겨 유휴 상태가 된 session에는 다음 사용자 메시지가 도착하기 전에 1-token keep-alive ping을 보내세요. 자세한 방법은 파트 3 §8.2에 있습니다.

용도 2: API Workload(RAG, 콘텐츠 생성, 배치 처리)

트래픽 특성

• RAG Q&A: 입력 = 고정 system + 매번 달라지는 검색 문서 + 매번 달라지는 query입니다.
• 콘텐츠 생성(마케팅 문구, 코드, 번역): template은 고정되고 데이터만 바뀝니다.
• 배치 처리(문서 분류, 데이터 정제): 같은 작업을 대량으로 수행합니다.
• Latency보다 호출당 비용이 더 중요합니다.

가장 어려운 문제: 검색 결과가 Prefix 순서를 바꾼다

RAG caching의 핵심 문제는 호출마다 검색 문서가 달라져 prompt 중간부터 prefix가 깨진다는 점입니다.

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}"},
]

결과적으로 고정된 약 3.5K tokens의 system 영역 전체가 cache됩니다. 매번 miss가 발생하는 부분은 사용자에게 전달되는 영역뿐입니다. 대부분의 production RAG에는 이 정도면 충분합니다. gpt-5.4-mini로 이 패턴을 측정했을 때 system tokens의 hit rate는 80% 이상이었습니다.

해결책 B — 검색 결과 순서를 결정적으로 만듭니다. 검색된 chunk를 relevance score가 아니라 안정적인 key 기준으로 정렬합니다. 예를 들어 doc_id 오름차순을 사용합니다. 자주 검색되는 chunk가 같은 위치에 머물러 prefix가 일치할 가능성이 커집니다. Ranker 정확도가 조금 낮아질 수 있지만, 대개 영향은 없습니다.

해결책 C — Vendor SDK를 직접 사용해 native explicit-cache marker를 적용합니다. Anthropic Claude를 직접 사용한다면 이 gateway가 아닌 multi-cache_control 패턴으로 “전혀 바뀌지 않는 부분”, “가끔 바뀌는 부분”, “작업마다 바뀌는 부분”을 별도 breakpoint로 cache할 수 있습니다. SDK 하나를 추가로 운용할 수 있다면 복잡한 RAG에 매우 효과적입니다.

API Workload의 TTL 고려 사항

• 연속 트래픽(24/7 RAG endpoint): 5분 TTL이면 충분합니다. 항상 TTL 안에 다음 요청이 들어옵니다.
• Burst 또는 cron(매일 09:00 batch): TTL이 긴 provider를 사용하세요. 테스트한 모델 중에는 deepseek-v4-flash가 가장 오래 유지됐습니다. 또는 작업 시간 동안 TTL/2 간격으로 1-token keep-alive를 실행하세요. 구현 패턴은 파트 3 §8.2에 있습니다.

작업별 모델 추천

† Claude의 multi-cache_control marker는 계층형 RAG에 가장 효과적입니다. Gateway를 가리키도록 anthropic SDK를 설정해 사용하세요. 자세한 방법은 파트 3 §2에 있습니다.

RAG 비용 추정(일 100K queries)

System 3K + 검색 문서 5K + query 200 tokens + output 300 tokens를 가정합니다. 수치는 파트 3 §6의 단일 호출 측정 비용을 기준으로 환산했습니다. 단일 tenant에서 동시 부하 없이 측정한 값입니다. 실제 workload의 비용은 LLM 비용 계산기로 추정하고, 현재 단가는 실시간 모델 가격 비교에서 확인하세요.

정확한 금액이 아니라 대략적인 규모로 보세요. 실제 production에는 동시 호출과 burst가 발생하며, 검색 문서 길이의 분포가 비용에 가장 큰 영향을 줍니다.

RAG / API에서 주의할 점

• ❌ 검색된 chunk를 동적인 relevance score로 정렬하지 마세요. 요청마다 prefix가 달라집니다.
• ❌ Streaming 시 usage log를 버리지 마세요. 비용을 호출별로 추적할 수 없게 됩니다. stream_options={"include_usage": True}를 전달하고 prompt_tokens_details.cached_tokens와 usage.cost를 저장하세요.
• ✅ 배치 작업에서는 caching에 vendor Batch API(OpenAI Batch, Anthropic Message Batches)를 함께 적용하면 비용을 약 50% 더 줄일 수 있습니다. 이 gateway 밖에서 provider를 직접 호출해야 합니다.

용도 3: AI 에이전트(멀티스텝 추론, Tool 사용, 긴 Chain)

트래픽 특성

• 하나의 agent 작업은 tool 결과가 중간중간 삽입되는 여러 번의 LLM 호출로 구성됩니다.
• Context가 매우 깁니다. System + tools + 누적 history를 합치면 10단계쯤에는 일반적으로 30K–100K tokens가 됩니다.
• Prompt 구조가 매우 규칙적입니다. 긴 prefix는 고정되고 끝부분만 조금씩 바뀝니다.
• Latency와 비용이 모두 중요합니다. Prefill에 1초가 추가될 때마다 사용자의 대기 시간이 늘어나며, 15단계 agent에서는 그 지연이 15배로 누적됩니다.

에이전트에 Caching이 필수인 이유

각 단계는 이전 단계의 tool call과 결과 뒤에 추가됩니다. Caching이 없으면 단계마다 수만 tokens에 대한 prefill 비용을 다시 지불해야 합니다.

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 ────↑

반드시 지켜야 할 규칙: 단계가 진행돼도 tool call과 결과는 byte까지 동일하게 유지한 채 뒤에만 추가해야 합니다. 다시 작성하거나 순서를 바꾸면 그 지점부터 cache가 모두 무효화됩니다. Agent에서 가장 흔한 문제는 “tool 결과를 정리해서 다시 전송했다”는 것입니다. 이 경우 cache rate가 0으로 떨어지고 비용과 latency가 몇 배로 늘어납니다.

TTL이 특히 중요한 유일한 용도

일반적인 agent 작업은 10–60초 안에 끝나므로 단일 작업 안에서는 기본 5분 TTL이면 충분합니다. 하지만 사람의 승인 대기 단계가 있는 agent는 다릅니다. 예를 들어 “이 계획을 검토하고 응답하세요”라고 요청한 뒤 수분 동안 멈출 수 있습니다. 사용자가 10분간 응답하지 않아 cache가 만료되면 다음 단계에서 50K tokens의 prefill 비용을 다시 지불해야 합니다. 이런 workflow에서는 다음 중 하나를 적용하세요.

• TTL이 더 긴 provider를 사용합니다. 테스트한 모델 중에는 deepseek-v4-flash가 가장 오래 유지됐습니다.
• 대기 중 TTL/2 간격으로 keep-alive ping을 전송합니다. 자세한 방법은 파트 3 §8.2에 있습니다.

에이전트 모델 추천

에이전트에는 추론 능력이 필요합니다. 품질을 먼저 보고 선택한 뒤 비용을 최적화하세요.

† Claude의 4-cache_control-marker 패턴은 여전히 agent caching에 가장 효과적입니다. 10단계 이상에서도 누적 prefix 할인이 적용됩니다. Gateway를 가리키도록 anthropic SDK를 설정해 사용하세요. 정확한 payload 구조와 TTL 옵션은 파트 3 §2에 있습니다.

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

System 5K + tools 3K + 단계마다 약 3K가 추가되고 전체 15단계라고 가정합니다. 파트 3 §6의 호출당 비용을 agent 구조에 맞춰 환산했습니다.

이 수치도 대략적인 추정치입니다. 단계가 바뀌어도 prefix를 실제로 byte 단위까지 동일하게 유지하는지가 가장 큰 변수입니다.

에이전트에서 주의할 점

• ❌ 단계마다 messages list를 새로 만들지 마세요. Array를 byte 단위까지 동일하게 유지하고 뒤에만 추가하세요.
• ❌ Tool 결과를 줄이거나 형식을 바꾸지 마세요. Byte 하나만 바뀌어도 이후 cache가 무효화됩니다.
• ❌ 여러 agent instance가 동시에 실행될 때 cache key를 공유하지 마세요. 단계 순서가 달라져 서로의 cache를 오염시킵니다.
• ✅ 작업별로 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 요약

이 Gateway가 하는 일과 하지 않는 일

기능 범위는 다음과 같습니다.

오른쪽 항목이 지금 필요하다면 application layer에서 구현하거나 vendor SDK를 직접 사용하세요. 이 gateway는 얇은 proxy에 가격 처리 계층을 더한 구조입니다. Caching 관련 처리는 모두 upstream의 모델 계층에서 이루어집니다.

결론

이 시리즈 전체는 네 줄로 정리할 수 있습니다.

Caching의 효과는 하나가 아니라 둘입니다. 비용과 latency를 모두 줄입니다. 고정된 콘텐츠는 앞에, 자주 바뀌는 콘텐츠는 뒤에 둡니다. Prefix 규칙은 비용이 들지 않으므로 모든 곳에 적용하세요. 용도에 맞춰 모델과 cache 동작을 선택합니다. 채팅 ≠ RAG ≠ 에이전트입니다. 자체 트래픽으로 측정합니다. 단일 실행 benchmark는 출발점일 뿐, 정답이 아닙니다.

가장 빠른 방법은 위 매트릭스에서 실제 환경과 가장 가까운 용도를 고르는 것입니다. 고정 prefix 우선 배치, 결정적 검색 순서, byte 단위까지 동일한 agent state와 같은 구조 변경을 적용하세요. 일주일 동안 cached_tokens와 usage.cost를 기록한 뒤 다시 평가하면 됩니다.

FAQ

중국어 챗봇에 가장 저렴한 LLM은 무엇인가요? 테스트한 모델 중 deepseek-v4-flash와 qwen3.5-flash는 중국어 텍스트 처리 비용이 영어 중심 모델보다 한 자릿수 배 저렴했습니다. 일반적인 채팅 workload에서는 gpt-5.4-mini와 비슷한 품질을 냈습니다.

2026년 RAG에 가장 적합한 LLM은 무엇인가요? 영어에서는 해결책 A의 prompt 구조, 즉 system tokens를 앞에 두고 참고 자료를 아래에 배치한 gpt-5.4-mini가 고정 영역에서 80% 이상의 hit rate를 냅니다. 중국어에는 deepseek-v4-flash가 적합합니다. 매우 긴 문서를 자주 조회한다면 1M+ token context를 native로 처리하는 gemini-2.5-pro가 좋습니다.

에이전트에는 GPT와 Claude 중 무엇을 써야 하나요? 둘 다 성능이 좋으며, cache 최적화에 얼마나 투자할지에 따라 선택이 달라집니다. Gateway에 연결한 anthropic SDK에서 사용하는 Claude의 4-cache_control-marker 패턴은 누적되는 agent prefix에 특히 효과적입니다. Prefix가 warm 상태가 되면 10단계 이상에 걸쳐 input 비용을 약 90% 줄일 수 있습니다. OpenAI 형식의 client를 그대로 사용하면서 marker 없이 약 50%의 cache 절감 효과를 얻으려면 gpt-5.4-mini 또는 gpt-5.5-pro가 더 간단한 선택입니다.

LLM 사용 방식을 “단순 구현”에서 “최적화된 구현”으로 바꾸면 실제로 얼마나 절약할 수 있나요? 이 시리즈의 측정 결과에서는 같은 모델을 사용하면서 비용이 50–88% 감소했고 TTFT가 30–60% 감소했습니다. 대부분의 효과는 다른 모델로 교체해서가 아니라 hit rate를 80% 이상으로 높여서 얻었습니다.

어디서 시작해야 하나요? 매트릭스에서 실제 환경과 가장 가까운 용도를 고르세요. Prompt 구조를 변경하고 production 트래픽에서 일주일간 cached_tokens와 usage.cost를 측정하세요. 모델 교체는 그다음에 검토하면 됩니다.

Provider별 LLM API 가격은 어떻게 비교하나요? Synthorai의 모델 페이지에서 실시간으로 가격을 비교할 수 있습니다. Provider로 필터링하고 백만 tokens당 input 또는 output 가격순으로 정렬할 수 있으며, gateway의 실제 정가와 항상 동기화됩니다. 위 매트릭스에서 용도에 맞는 모델 유형을 고른 뒤, 모델 페이지에서 현재 비용을 확인하세요.

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

← 블로그로 돌아가기