APPENDIX · TOOLS

API 비용 최적화

캐싱 · 배치 · 모델 라우팅

API 비용 최적화 — 캐싱·배치·모델 라우팅

연관 문서: 파라미터 착시: KV 캐시의 진실, 리즈닝 모델의 딜레마, 경량 모델의 빠른 발전, Claude Code 3대 설정 축, Codex 사용 가이드, RAG 아키텍처, 에이전트 프레임워크 지형도, LLM 평가, LLM 구동 스펙: 메모리 용량과 대역폭, 트랜스포머 추론의 두 단계

LLM을 실서비스에 태우면 가장 먼저 마주치는 문제는 비용이 예측보다 빠르게 늘어난다는 사실이에요. PoC에서 토큰 단가 × 예상 호출량으로 계산했던 숫자는, 실제 운영에서 보통 3~10배로 튑니다. 원인은 단순한 호출 횟수 폭증이 아니라 사용자 눈에 안 보이는 토큰들이에요 — system prompt, tool spec, thinking 블록, 재시도 루프, 컨텍스트 구간 변곡점.

이 문서는 API 비용을 구성하는 실제 축을 분해하고, 2026년 4월 기준 세 주요 공급자(Anthropic·OpenAI·Google)의 캐싱·배치·라우팅 메커니즘을 실무 판단 기준으로 정리해요.

1. 비용이 드는 곳을 먼저 본다

API 비용 공식 자체는 간단합니다:

비용 = (input 토큰 × input 단가) + (output 토큰 × output 단가)

하지만 실제 청구서는 이 공식만으로 예측되지 않아요. 다섯 가지 요소가 숨어서 비용을 부풉니다:

요소설명대응 축
정적 프롬프트 반복system prompt · 시스템 프롬프트 파일(Claude Code: CLAUDE.md, Codex: AGENTS.md) · tool spec이 매 요청마다 입력 토큰으로 카운트프롬프트 캐싱
컨텍스트 구간 변곡점GPT-5.4는 272K 초과 시 input 2배, Gemini 3.1 Pro는 200K 초과 시 input·output 동반 상승컨텍스트 관리
Thinking 토큰추론 모델의 <thinking>은 output 단가로 과금 + KV 캐시 점유effort/task_budget 조절
에이전트 루프tool call 결과가 다음 input으로 다시 들어감 → 같은 컨텍스트가 N번 input으로 과금모델 라우팅 · 캐싱
토크나이저 차이Claude Opus 4.7은 새 토크나이저로 같은 텍스트가 4.6 대비 최대 1.35x 토큰실측 기반 예산

실무 감각으로 정리하면 이래요. "호출 수를 줄이는" 최적화는 한계가 있고, "같은 호출에 들어가는 토큰 성분을 다르게 과금받는" 최적화가 훨씬 큽니다. 프롬프트 캐싱(반복 입력 90% 할인), 배치 API(전체 50% 할인), 모델 라우팅(단가가 낮은 모델로 대체)이 그 세 축이에요.

2. 프롬프트 캐싱 — 반복되는 입력의 90% 할인

왜 싸지는가

대화형 워크로드에서 앞부분 토큰들(system prompt, 시스템 프롬프트 파일, tool spec, RAG 컨텍스트) 은 요청마다 동일해요. 서버가 이 prefix의 KV 벡터를 저장해두고 다음 요청에 재사용하면, prefill 단계의 attention 연산 자체를 건너뜁니다 — 이것이 Prefix Caching의 핵심이에요. → KV 캐시의 진실 — Prefix Caching

서버 입장에서 재계산 없이 메모리에서 꺼내쓰는 셈이라, cache read 토큰을 base input 단가의 0.1x (90% 할인) 로 책정하는 게 업계 관행이에요.

공급자별 비교

공급자방식read 할인write 비용최소 토큰만료
Anthropic Claude수동 (cache_control 블록 표시)90% (0.1x)1.25x (5분) / 2x (1시간)4,096 (Opus 4.7 · Haiku 4.5) · 1,024 (Sonnet 4.6) · 2,048 (Haiku 3.5)5분 / 1시간
OpenAI GPT-5.x자동 (prefix 매칭)90% (0.1x)불변 (1x)1,024 (128 단위 확장)5-10분 비활성, 최대 1시간
Gemini 2.5+ Implicit자동할인 보장 없음 (best-effort)불변Flash 1,024 · Pro 4,096미공개
Gemini 2.5+ Explicit수동 (CachedContent)90% (0.1x) + 저장비불변Flash 1,024 · Pro 4,096사용자 지정 TTL
Gemini 3 Pro Explicit수동75% (0.25x) + 저장비불변Flash 1,024 · Pro 4,096사용자 지정 TTL

Gemini Explicit은 저장 비용이 따로 붙어요 — Pro는 $4.50/MTok/시간, Flash는 $1.00/MTok/시간. 짧은 시간 안에 재사용이 확실해야 손익분기점을 넘깁니다.

손익분기 계산

Anthropic 5분 캐시의 손익분기:

cache write 비용 = 1 × 1.25 × input_price = 1.25 unit
cache read 비용  = 1 × 0.10 × input_price = 0.10 unit
재계산 비용     = 1 × 1.00 × input_price = 1.00 unit

1회 캐시 히트로 절약 = 1.00 - 0.10 = 0.90 unit
초과 투자분         = 1.25 - 1.00 = 0.25 unit
→ 손익분기: 0.25 / 0.90 ≈ 0.28 회

즉 같은 prefix로 한 번만 다시 호출해도 이득이에요. 1시간 캐시(2x write)는 2.2회가 손익분기 — 챗봇처럼 같은 system prompt로 하루 종일 다중 유저를 받는다면 무조건 1시간 캐시가 유리합니다.

언제 효과가 큰가

  • 긴 system prompt + 많은 짧은 유저 질의 (고객 지원 챗봇)
  • RAG 파이프라인에서 고정된 규약·포맷 지침 · Contextual Retrieval의 문서별 LLM 호출 → RAG 아키텍처 §3.4
  • 에이전트의 tool spec + 시스템 프롬프트 파일 (주요 코딩 에이전트가 내부적으로 자동 활용)
  • 멀티턴 대화에서 앞 N턴을 매번 다시 전달하는 경우

공급자별 설계 판단

Anthropic: 가장 유연하되 수동 관리가 필요합니다. cache_control: {"type": "ephemeral"} 블록을 최대 4개까지 표시할 수 있어서 "system prompt + 문서 1 + 문서 2 + 대화 기록"처럼 경계를 직접 설계할 수 있어요. 배치 API와 스택되어 이론상 최대 95% 할인 가능합니다.

OpenAI: 자동이라 "아무것도 안 해도 된다"는 장점과 "어떻게 캐싱되고 있는지 통제하기 어렵다"는 단점을 동시에 가져요. 응답 usage 필드의 cached_tokens로 적용 여부만 확인합니다.

Gemini: Implicit(자동)은 '될 수도 있고 안 될 수도 있는' 구조라 비용 예측이 어려워요. 대용량·고빈도 시나리오에서는 Explicit로 명시적으로 설정하는 편이 예측 가능성이 높습니다. 최소 토큰은 Implicit·Explicit 동일 (Flash 1,024 / Pro 4,096) — 2025년 이전에 알려졌던 32,768 토큰 기준은 Gemini 1.5 시대 구식 값이에요.

주의: Anthropic 2026-02-05 이후

2026-02-05부터 Anthropic 캐시는 organization 단위가 아니라 workspace 단위로 격리됩니다. 조직 내 여러 workspace에서 같은 prefix를 쓰더라도 캐시는 공유되지 않으므로, 팀 분리가 잦은 엔터프라이즈는 workspace 설계 단계에서 이를 감안해야 해요.

3. 배치 API — 지연 허용 작업의 50% 할인

구조

  • 요청을 JSONL 파일로 업로드 → 서버가 큐에 적재 → 24시간 이내에 결과 파일 반환
  • input·output 모두 50% 할인
  • 품질은 실시간 호출과 동일 (동일 모델·동일 가중치)

공급자별 비교

공급자엔드포인트할인율실제 처리 시간비고
Anthropic Message Batches/v1/messages/batches50%24시간 보장캐싱과 스택 가능
OpenAI Batch API/v1/batches50%1-6시간 실제, 24시간 보장전 모델 지원
Google Gemini BatchBatch Mode50%24시간 목표Flex pricing과 동등

실 단가 예 (2026-04)

모델실시간배치
Claude Opus 4.7$5.00 / $25.00$2.50 / $12.50
Claude Sonnet 4.6$3.00 / $15.00$1.50 / $7.50
Claude Haiku 4.5$1.00 / $5.00$0.50 / $2.50
GPT-5.4$2.50 / $15.00$1.25 / $7.50
GPT-5.5$5.00 / $30.00$2.50 / $15.00 (= GPT-5.4 실시간과 동일)

캐싱과 스택

Anthropic은 캐싱(read 90% 할인) + 배치(50% 할인)를 동시에 적용할 수 있습니다. 입력 기준 실제 비용:

base × 배치 0.5 × cached read 0.1 = base × 0.05

즉 입력 토큰 기준 최대 95% 할인이에요. output 토큰은 캐싱 대상이 아니므로 배치 50%만 남습니다.

적합 워크로드

  • 문서 처리 파이프라인 (사내 보고서 일괄 요약·분류)
  • 데이터 엔리치먼트 (CSV 수만 건 라벨링·번역)
  • 야간 분석 잡 (어제자 로그에서 이슈 뽑기)
  • 대량 임베딩 생성
  • 오프라인 평가·벤치마크 실행

부적합

  • 사용자가 대기하는 실시간 응답
  • 대화형 에이전트 (주요 코딩 에이전트·챗봇)
  • 실시간 의사결정·알림

실무 팁

  • 큐 제출 → 폴링이 아니라 큐 제출 → 완료 웹훅으로 설계하면 운영이 깨끗해져요 (OpenAI는 웹훅, Anthropic은 폴링 중심).
  • 대형 배치는 쪼개서 병렬 제출하는 편이 실패 복구에 유리합니다. JSONL 1개 파일이 10만 건이면, 파싱 에러 하나로 전체가 밀릴 수 있어요.
  • 배치 결과에는 요청 ID를 custom_id로 꼭 넣으세요 — 비동기라서 순서가 보장되지 않습니다.

4. 모델 라우팅 — 작은 모델에 먼저 보내라

원칙

워크로드 전체를 플래그십 모델로 처리할 필요는 없어요. 2026년의 작은 모델은 대부분의 정형 작업에서 충분한 성능을 냅니다. → 경량 모델의 빠른 발전

"Haiku로 초안 → Opus로 검수" 같은 파이프라인은 README §5에서 본 오케스트레이터 패턴의 비용 적용판이에요. 품질이 필요한 순간에만 큰 모델에 지출하고, 나머지는 값싼 모델로 흘립니다. → README §5 하네스가 체급을 이긴다

단가 차이 감각 (2026-04)

모델InputOutput플래그십 대비
Claude Opus 4.7$5.00$25.00기준
Claude Sonnet 4.6$3.00$15.000.6x
Claude Haiku 4.5$1.00$5.000.2x
GPT-5.4$2.50$15.00기준
GPT-5.4 mini$0.75$4.500.3x
GPT-5.4 nano$0.20$1.250.08x
Gemini 3.1 Pro$2.00$12.00기준
Gemini 3.1 Flash-Lite〜$0.10〜$0.400.04x 내외

같은 벤더 내에서도 nano/lite 라인은 플래그십의 4-8% 수준이에요. 단순 Q&A·요약·분류·의도 판별을 nano 급에 태우면 청구서 규모 자체가 달라집니다.

라우팅 설계 패턴

1) 난이도 라우팅 — 빠른 필터

flowchart TD Q["사용자 질의(User Query)"] --> N["난이도 판정(Nano 모델)"] N -->|easy| H["저가 모델(Haiku)"] N -->|hard| O["플래그십(Opus)"]
  • 1차 필터는 nano 단가로 처리 → 대부분의 쉬운 쿼리는 Haiku로 종결
  • 어려운 쿼리만 Opus로 라우팅

2) 작성-검수 루프 — 품질 보호

README §5의 Writer/Reviewer 패턴을 비용 관점으로 읽으면:

  • Writer = 저렴한 모델 (Haiku · GPT-5.4 mini)
  • Reviewer = 고성능 모델 (Opus · GPT-5.4)
  • Reviewer는 Writer가 내놓은 초안만 보므로 입력 토큰이 적음 → 단가는 비싸도 총 비용은 낮음

3) Fallback 라우팅 — 실패 시 상위로

  • 1차: nano/Haiku로 처리 시도
  • 2차: 응답 품질 체크 실패 시 Sonnet으로 재시도
  • 3차: 그래도 안 되면 Opus
  • 대부분의 쿼리는 1차에서 끝남 → 실비용은 nano 기준에 가까움

코딩 에이전트의 내부 라우팅

주요 코딩 에이전트(Claude Code, Codex 등)는 실제로 이 패턴을 에이전트 내부에 구현하고 있어요. 가벼운 서브에이전트(예: Haiku·소형 모델)에 파일 탐색·테스트 실행 같은 단순 반복 작업을 위임하고, 메인 세션(Sonnet/Opus 또는 GPT-5 계열)은 판단과 최종 편집만 담당합니다. → Claude Code 3대 설정 축과 Codex 사용 가이드

이종 모델 라우팅의 프레임워크 제약: Claude Agent SDK·OpenAI Agents SDK 같은 벤더 SDK는 자사 모델 1st-class이라 "초안 Haiku → 검수 GPT-5.4" 같은 서로 다른 공급자 간 라우팅에는 불리해요. 이종 모델 파이프라인이 핵심이면 LangGraph·CrewAI·Pydantic AI 같은 벤더 중립 프레임워크가 유리합니다. → 에이전트 프레임워크 지형도 §9

5. 컨텍스트 관리 — 비용도 선형이 아니다

구간 단가 변곡점

공급자변곡점초과 시
GPT-5.4272Kinput 2배 ($2.50 → $5.00)
Gemini 3.1 Pro200Kinput $2 → $4, output $12 → $18
Claude Opus 4.7없음 (고정)$5 / $25

긴 컨텍스트를 다룰 때 GPT·Gemini는 단가 자체가 변해요. "200K에서 201K로 1천 토큰 늘어났을 뿐인데 이전 토큰까지 다 2배 단가로 재과금"되는 구조라, 변곡점을 아슬아슬하게 넘기는 프롬프트는 경제적으로 최악이에요. 180K 또는 310K로 맞추는 편이 낫습니다.

Claude는 고정 단가라 예측이 쉽지만, 같은 작업을 Opus로 돌리면 절대 가격이 높아요. 장문 작업의 공급자 선택은 "구간 단가 vs 베이스 단가"의 트레이드오프입니다.

토크나이저 차이

Claude Opus 4.7은 새 토크나이저를 채택해 같은 한국어·일본어·코드가 4.6 대비 1x~1.35x 토큰으로 카운트됩니다. 단가가 그대로여도 실사용 비용은 최대 35% 상승할 수 있어요. 특히 CJK·특수 포맷·긴 JSON 페이로드를 많이 다룬다면 PoC 단계에서 실측이 필수입니다.

세션 길이와 KV 캐시

README §3-4에서 본 KV 캐시 증가는 단순히 메모리 압박이 아니라 요청당 비용 증가예요. 긴 세션은 이래요:

  • 매 요청마다 앞선 N턴이 input 토큰으로 다시 들어감
  • thinking 블록이 interleaved로 쌓이면 output 단가가 이 부분까지 과금
  • Compaction 직전에는 Prefill 연산이 가장 무거움 → 지연·비용 동시 상승

해법은 세션 쪼개기 — 이건 README §6 원칙 1과 동일한 결론이에요. 비용 관점에서 재진술하면 "컨텍스트는 누적되는 한 매 호출마다 이전 누적분을 다시 input으로 지불한다"는 거예요.

6. 추론 모델의 숨겨진 비용

<thinking> 토큰은 사용자 눈에 안 보이지만 output 단가로 과금됩니다. 2026년 공급자별 단가를 단순 곱셈으로 보면:

설정평균 thinking 토큰/reqthinking 비용/req
Gemini 3.1 Pro LOW~300~$0.004
Gemini 3.1 Pro MEDIUM~2,000~$0.024
Claude Opus 4.7 high5,00010,000$0.13$0.25
Gemini 3.1 Pro HIGH (Deep Think Mini)~8,000~$0.096
GPT-5.4 xhigh (긴 프롬프트)~20,000~$0.30
Claude Opus 4.7 max + interleaved50,000+ (루프 전체)$1+

같은 프롬프트가 thinking 없음 → HIGH로 바뀌면 요청당 3-10배, 에이전트 루프로 누적되면 세션당 수십 배예요. effort 하향과 task_budget은 품질 조절이 아니라 비용 통제 장치입니다.

실무 규칙: "정말로 단발 깊은 분석인가?"를 먼저 묻고, 반복·루틴 작업은 일반 모델 + 강한 하네스로 돌립니다. 자세한 파라미터·단가 비교는 → 리즈닝 모델의 딜레마 — Thinking Effort 조절 (공급자별 평행 비교)

7. 의사결정 체크리스트

새 워크로드를 설계할 때 비용 축을 빠르게 점검하는 순서예요:

  1. 지연 허용 여부 — 24시간 내 결과면 되는가? → 배치 API 50% 즉시 적용
  2. system prompt 반복 여부 — 같은 prefix가 1024 토큰 이상, 2회 이상 재사용되는가? → 프롬프트 캐싱 90% 적용
  3. 모델 크기 적합성 — 이 작업에 정말 플래그십이 필요한가? → nano/Haiku 1차 라우팅, 실패 시 승급
  4. thinking 필요성 — "단발 깊은 분석"인가, "반복 루틴"인가? → 후자면 thinking off + 강한 하네스
  5. 컨텍스트 길이 — 200K/272K 변곡점 근처인가? → 프롬프트를 180K 또는 310K로 맞춰 구간 넘김 회피
  6. 토크나이저 실측 — Claude 4.7 사용 시 4.6 대비 실토큰 측정 → PoC에서 실제 청구서로 검증
  7. 에이전트 루프 길이 — tool call이 N회 반복되면 앞 컨텍스트가 N번 과금 → 서브에이전트 위임으로 메인 컨텍스트 보호 (README §4)

비용 최적화의 메타 원칙

KV 캐시·컨텍스트 레이어·하네스 품질 — 이 문서의 모든 축은 결국 "같은 작업을 더 적은 토큰, 더 싼 단가로 받아내는 게임" 이에요. 세션 쪼개기·시스템 프롬프트 파일 얇게·서브에이전트 위임 같은 README의 통제 원칙들은 품질 관리인 동시에 비용 통제였습니다. → README §6-7 에이전트 통제술

비용이 튀는 시점은 보통 "플래그십 모델 + 긴 컨텍스트 + HIGH thinking + 미캐싱 반복 요청" 네 축이 동시에 켜진 순간이에요. 이 넷 중 셋만 꺼도 요청당 비용이 한 자릿수 퍼센트로 떨어집니다.

네비게이션

왔던 길 — 이 부록에 도달하는 전형적인 경로

갈 길 — 이어 읽으면 자연스러운 3개

  1. 파라미터 착시: KV 캐시의 진실 — Caching이 재활용하는 대상의 수식
  2. RAG 아키텍처 — 캐싱·라우팅을 RAG 파이프라인에 적용
  3. 에이전트 프레임워크 지형도 — 프레임워크별 비용 특성과 벤더 락인 트레이드오프

연관 문서