에이전트의 토큰 비용은 아마도 필요 이상으로 5배나 높을 것입니다. 이는 모델이 비싸기 때문이 아니라, 라우팅 (Routing) 규율이 부족하기 때문입니다. 대부분의 팀은 모든 호출을 하나의 프런티어 모델 (Frontier model)에 연결하고 상황을 종료합니다. 이 포스트는 실질적인 해결책을 제시합니다: 에이전트 호출의 쉬운 80%는 저렴한 모델로 보내고, 어려운 20%는 프런티어 모델을 유지하면서, 이 과정에서 품질을 단 1점도 잃지 않는 방법입니다.

아래의 모든 내용은 하나의 OpenAI 호환 API 뒤에서 8개의 제공업체에 걸쳐 22개의 모델을 노출하는 게이트웨이의 실제 수치를 사용합니다.

비용을 발생시키는 기본 설정
전형적인 에이전트 루프 (Agent loop)의 형태는 다음과 같습니다:
요청 분류 (Classify the request)
구조화된 필드 추출 (Extract structured fields)
도구 선택 (Pick a tool)
도구 호출 및 결과 파싱 (Call the tool, parse the result)
발생한 일 요약 (Summarize what happened)
다음 단계 결정 (Decide the next step)
답변 초안 작성 (Draft the reply)

이 중 한두 단계만이 실제로 프런티어 수준의 추론 (Reasoning)을 필요로 할 것입니다. 나머지는 분류, 추출, 포맷팅 (Formatting)이며, 이는 빠르고 저렴한 모델이 플래그십 (Flagship) 모델과 구별할 수 없을 정도로 수행하는 작업입니다. 그럼에도 불구하고 대부분의 설정은 가장 저항이 적은 경로라는 이유로 모든 것을 gpt-5.5 (또는 그들의 기본 모델)로 보냅니다.

그것이 바로 세금입니다. 당신은 필요하지 않은 단계에 대해 플래그십 가격을 지불하고 있습니다.

수학적 근거를 통한 80/20 분할
모델에 대한 충성도가 아닌, 작업 난이도에 따라 라우팅하세요:
쉬운 80% — 분류, 추출, 요약, 짧은 도구 포맷팅, 라우팅 결정 → 빠른 중국 모델 티어 (China-model tier)
중간 15% — 코딩, 계획, 다단계 추론 → 강력한 추론 티어 (Reasoning tier)
어려운 5% — 진정으로 까다로운 프런티어 케이스 → 플래그십, 예약됨

혼합 비용 추정치 (입력 토큰, 1M당):
80% × ¤160 (저렴한 티어 입력) = ¤128
15% × ¤560 (추론 티어) = ¤84
5% × ¤7000 (플래그십 입력) = ¤350

혼합 입력 비용 ≈ ¤562 / 1M
vs. 전체 플래그십 사용 시 = ¤7000 / 1M
절감액 ≈ 이 예시에서 70% 이상
더 보수적인 분할을 적용하더라도 70% 이상의 비용 절감이 하한선이며, 어려운 결정은 여전히 프런티어 (Frontier) 모델로 전달되기 때문에 품질은 변하지 않습니다.

함정: 왜 "그저 가장 저렴한 모델을 사용하는 것"이 역효과를 내는가
단순한 비용 절감 방식은 모든 작업에 하나의 저렴한 모델만을 선택합니다. 이는 두 가지 이유로 실패합니다:

1. 품질 절벽 (Quality cliffs). ¤160/1M 모델은 정보 추출 (Extraction)에는 뛰어나지만, 12개 파일에 걸친 리팩토링 (Refactor) 계획 수립에는 형편없습니다. 어려운 작업을 낮은 티어로 밀어내면 사용자가 이를 알아차립니다.
2. 캐시 무효화 (Cache invalidation, 보이지 않는 세금). 이는 거의 아무도 예산에 반영하지 않는 부분입니다. 긴 에이전트 대화는 매 턴마다 시스템 프롬프트 (System prompt)와 도구 정의 (Tool definitions)를 다시 전송합니다. 만약 대화 중간에 제공자 (Provider)를 변경하면, 프롬프트 캐시 친화성 (Prompt-cache affinity)이 초기화되어 매 턴마다 전체 접두사 (Prefix) 비용을 다시 지불해야 합니다. 저렴해야 할 대화가 갑자기 그렇지 않게 됩니다.

승리 전략은 "저렴한 모델을 사용하는 것"이 아니라, 캐시 친화성을 유지하면서 라우팅 규율 (Routing discipline)을 지키는 것입니다. 쉬운 80%의 작업은 안정적인 저렴한 모델에 고정하여 캐시를 따뜻하게 (Warm) 유지하고, 그럴 가치가 있는 호출에 대해서만 프런티어 모델로 에스컬레이션 (Escalate)하십시오.

실제 라우팅 레이어의 모습
통합 게이트웨이 (Unified gateway)를 사용하면 이는 대략 10줄 내외로 구현됩니다. 하나의 API를 사용하며, 모델별로 모델을 교체합니다. 제공자별 SDK를 번거롭게 다룰 필요가 없습니다:

def route(task):
if task.complexity == "easy": # 분류, 추출, 요약
return "TokenLat-deepseek-v4-Flash" # ¤160/1M 입력
if task.needs_reasoning: # 코드, 계획, 다단계 작업
return "TokenLat-deepseek-v4-Pro" # ¤560/1M 입력, ¤10/1M 캐시 읽기
return "chatgpt-5.5" # 프런티어, 오직 어려운 5%를 위해

resp = client.responses.create(  
model=route(task),  
input=task.prompt,  
)  

또는 라우터(router)를 완전히 건너뛰고 게이트웨이(gateway)가 호출마다 결정하도록 할 수 있습니다:

resp = client.responses.create(  
model="auto", # 게이트웨이가 요청별로 적절한 티어(tier)를 선택함  
input=task.prompt,  
)  

model: "auto"는 동일한 개념의 설정이 필요 없는(zero-config) 버전입니다. 즉, 사용자가 직접 라우팅 로직을 구현(hand-roll)할 필요 없이 게이트웨이가 라우팅 정책(routing policy)을 적용합니다.

22개 모델 게이트웨이의 실제 수치
통합 게이트웨이는 가격 정보를 사전에 명확히 보여주어야 합니다. 1M 토큰당 크레딧(¤) 기준의 일부 예시는 다음과 같습니다 (입력 / 캐시 읽기):

• deepseek-v4-Flash — 저렴함 / 빠른 티어 → ¤160 / ¤40
• qwen3.5-plus — 일반 티어 → ¤130 / ¤20
• deepseek-v4-Pro — 추론(reasoning) 티어 → ¤560 / ¤10 (가장 낮은 캐시 읽기 비용)
• glm-5.1 — 중국어 안정형 → ¤950 / ¤160
• kimi-k3 — 플래그십 (중국) → ¤3000 / ¤300
• gemini-3.1-pro — 프런티어(frontier) → ¤2800 / ¤300
• chatgpt-5.5 — 프런티어(frontier) → ¤7000 / ¤700

핵심적인 격차: 저렴한 티어의 입력 비용은 플래그십 입력 비용보다 약 44배 저렴합니다. 이것이 바로 80/20 법칙의 핵심 논거를 한 줄로 요약한 것입니다.

캐시 히트(Cache-hit) 가격 책정 — 에이전트의 허점
에이전트 시스템(agentic systems)의 경우, 입력 가격은 거의 고려 대상이 아닙니다. 중요한 것은 캐시 읽기(cache-read) 가격입니다. 왜냐하면 정적 접두사(static prefix, 시스템 프롬프트, 도구 스키마, 검색된 컨텍스트 등)가 매 턴마다 다시 전송되기 때문입니다.

• deepseek-v4-Pro의 캐시 읽기는 1M당 ¤10
• qwen3.5-plus는 1M당 ¤20

따라서 안정적인 모델을 고정하고 접두사를 캐시에 유지하는 장기 실행 에이전트 루프(agent loop)는 대부분의 턴을 입력 가격의 아주 일부인 캐시 읽기 요율로 처리할 수 있습니다. 모델을 전환할 때마다 캐시를 초기화하는 제공업체들은 이러한 비용 절감 효과를 조용히 지워버립니다. 캐시 친화성(Cache affinity)은 사후 고려 사항이 아니라 라우팅 결정의 핵심 요소입니다.

가시화하기
보이지 않는 것은 최적화할 수 없습니다. 적절한 게이트웨이를 통한 모든 요청은 다음과 같은 흔적을 남겨야 합니다:

REQUEST → AUTH → ROUTE(auto→text-pro) → RESPONSE → METER
region: SEA | status: 200 OK | latency: 842ms | tokens: 1,284 | cost: ¤0.0048

호출당 5단계가 한 줄로 표시됩니다.

청구 금액이 급증할 때, 월간 총액을 바라보며 추측하는 대신 어떤 모델, 어떤 경로, 그리고 어떤 요청이 원인인지 확인할 수 있습니다.

추측하지 말고 — 품질을 측정하세요
이 플레이북이 전제하는 한 가지는 다음과 같습니다: 저렴한 티어(cheap tier)가 충분히 괜찮은지 실제로 확인해야 한다는 것입니다. 실제 작업 샘플을 두 티어 모두로 라우팅(routing)하고, 성공 기준에 따라 출력값의 점수를 매긴 다음, 그제서야 분할(split)을 확정하십시오. 대부분의 팀은 품질 저하의 절벽(quality cliff)이 우려했던 것보다 훨씬 작다는 것을 발견하며, 품질 저하가 발생하는 경우에도 이미 프론티어(frontier) 모델을 위해 예약해 두었을 것입니다.

핵심 요약: 절감액은 더 저렴한 모델을 찾아다니는 데서 오는 것이 아닙니다. 쉬운 80%의 작업을 안정적인 저렴한 티어로 라우팅하고, 캐시 친화성(cache affinity)을 유지하며, 어려운 호출만 프론티어 모델로 에스컬레이션(escalating)하는 데서 옵니다. 그렇게 하면 품질을 유지하면서도 70% 이상의 비용 절감이 일상적인 일이 됩니다.

8개의 제공업체를 직접 연결하지 않고 이를 시도해보고 싶다면: TokenLat는 말레이시아 및 동남아시아를 위한 통합 AI 게이트웨이입니다. 22개 모델에 대해 하나의 OpenAI 호환 API를 제공하며, 자동 라우팅(auto routing) 및 요청당 비용 추적(per-request cost traces) 기능을 갖추고 있습니다. 위의 모델 목록은 tokenlat.com에서 실시간으로 확인할 수 있습니다.

현재 에이전트 작업당 비용은 얼마인가요? 한 자릿수인가요, 아니면 원하는 것보다 빠르게 증가하고 있나요? 80/20 분할 방식이 귀하의 워크로드(workload)에 어떻게 적용될지 궁금합니다.