$87K에서 $24K로: AI 에이전트 모델 티어 라우팅(Model Tier Routing)이 품질 저하 없이 비용을 절감하는 방법

2026년 4월, 35명의 엔지니어를 보유한 성장 단계의 SaaS 기업이 87,000달러의 API 청구서를 받았습니다. 이들의 엔지니어링 팀은 4개월 동안 Claude Code, Cursor, 그리고 커스텀 버그 분류(bug-triage) 에이전트를 운영해 왔습니다. 아무도 모델 라우팅(model routing) 정책을 설정하지 않았습니다. 파일 읽기, 일상적인 코드 수정, 도구 라우팅 결정(tool routing decisions), 검증 단계(validation passes) 등 모든 에이전트 루프의 모든 단계가 기본적으로 Opus 4.7으로 설정되어 있었습니다. 이 청구서는 개발자들의 부주의로 인해 발생한 것이 아니었습니다. 어떤 모델이 어떤 작업을 처리할지에 대해 아무도 명시적으로 내리지 않은 아키텍처 결정 때문에 발생한 것이었습니다. 5월에 모델 티어 라우팅(model tier routing), 프롬프트 캐싱(prompt caching), 컨텍스트 프루닝(context pruning)을 구현한 후, 동일한 팀의 청구서는 24,000달러로 줄어들었습니다. 연간 절감액은 756,000달러였습니다. 스프린트 속도(sprint velocity)로 측정된 엔지니어링 생산성은 변함이 없었습니다. 이것은 모델 라우팅 문제를 하나의 사례 연구로 응축한 것입니다. 비싼 모델이 저렴한 모델도 충분히 잘 처리할 수 있는 작업을 수행하고 있었던 것입니다. 아무도 다르게 지시하지 않았기 때문입니다.

왜 잘못된 모델이 생각보다 더 많은 비용을 발생시키는가
핵심 문제는 프런티어 AI(frontier AI) 모델이 비싸다는 것이 아니라, 대부분의 에이전트 프레임워크(agentic frameworks)가 모든 작업에 대해 단일 모델을 기본값으로 사용한다는 점입니다. 그 모델은 대개 미드 티어(mid-tier) 또는 프런티어(frontier) 옵션인데, 이는 그것이 가장 좋은 데모 결과를 만들어냈기 때문입니다. 프로덕션 환경에서 이 모델은 아키텍처 추론(architectural reasoning)이나 다중 파일 디버깅(multi-file debugging)과 동일한 토큰당 가격으로 파일 읽기, 변수 추출, 도구 라우팅 결정, 보일러플레이트(boilerplate) 코드 수정을 처리합니다. 수학적 계산은 빠르게 복리로 불어납니다.

에이전트 AI를 운영하는 30개 엔지니어링 팀을 대상으로 한 LeanOps 감사(2026년 3월~5월) 결과, 평균 에이전트 API 청구서의 62%가 재전송된 컨텍스트(re-sent context)로 인해 발생한다는 사실이 밝혀졌습니다. 이는 실제 추론 출력(reasoning output)이 아니라, 매 단계마다 재전송되는 동일한 시스템 프롬프트(system prompts), 도구 정의(tool definitions), 대화 기록(conversation history) 때문입니다. 모든 LLM API 호출은 상태가 없습니다(stateless). 제공업체는 이전 턴을 기억하지 못합니다. 따라서 에이전트는 모든 도구 호출(tool call), 모든 검증(validation), 모든 재확인(re-check) 시에 누적된 전체 기록을 전송합니다. 파일 읽기가 포함된 루프의 20번째 단계에 이르면, 단일 호출의 입력값이 50,000 토큰을 초과할 수 있습니다.

Claude Sonnet 4.6의 입력 속도를 기준으로 할 때, 루프 후반부의 단 한 단계만으로도 0.15달러의 비용이 발생합니다. 이를 50단계, 개발자당 하루 50개의 작업, 그리고 22일 근무 기준 20명의 개발자로 곱하면, 예산 경고가 울리기도 전에 월 110,000달러에 육박하게 됩니다. LeanOps 감사 결과, 표면적으로 동일한 도구를 사용하는 팀들 사이에서도 개발자 비용의 10백분위수와 90백분위수 사이에 20배의 차이가 있음이 발견되었습니다. 그 차이는 거의 전적으로 개발자가 기본적으로 어떤 모델을 사용하는지, 그리고 프롬프트 캐싱 (Prompt Caching)이 활성화되어 있는지 여부에 달려 있었습니다. 두 명의 엔지니어가 동일한 도구를 사용함에도 불구하고 청구 금액은 판이하게 달랐습니다.

모델 티어 라우팅 패턴 (Model Tier Routing Pattern)
모델 티어 라우팅 (Model tier routing)은 각 단계의 인지적 요구 사항 (Cognitive demand)에 따라 서로 다른 에이전트 단계에 서로 다른 모델 티어를 할당합니다. 그 원칙은 각 단계 유형에 대해 수용 가능한 출력을 생성하는 가장 저렴한 모델을 사용하고, 최첨단 추론 (Frontier reasoning)이 진정으로 필요한 단계에만 고가의 모델을 예약하는 것입니다. 2026년 모델 제품군을 위한 실질적인 3단계 구조는 다음과 같습니다:

티어 1 — 일상적인 단계 (Routine steps): 파일 읽기, 변수 추출, 구조화된 데이터 파싱 (Structured data parsing), 작은 메뉴에서의 도구 선택, 상용구 코드 (Boilerplate code) 편집. 이러한 작업들은 정의가 명확하고 정답/오답이 존재하며, 최첨단 추론으로부터 이득을 얻지 못합니다. 모델: Haiku 4.5, GPT-5 Nano, Gemini 2.5 Flash-Lite. 비용: 최첨단 모델 호출 비용의 약 1/20.

티어 2 — 표준 추론 (Standard reasoning): 코드 리뷰, 테스트 작성, API 통합, 단일 파일 리팩토링 (Refactoring), 요약. 에이전트의 실제 작업 대부분이 여기에 해당합니다. 모델: Claude Sonnet 4.6, GPT-5, Gemini 2.5 Pro. 비용: 최첨단 모델 호출 비용의 약 1/5.

티어 3 — 고난도 추론 (Hard reasoning): 아키텍처 결정, 미묘한 의존성 체인을 포함한 다중 파일 리팩토링, 보안 분석, 복잡한 버그에 대한 근본 원인 진단 (Root-cause diagnosis). 이곳이 바로 최첨단 모델이 그 비용을 정당화하는 영역입니다. 모델: Opus 4.7, GPT-5.5.

이 범주에 속하는 나머지 단계 유형들 — 복잡한 아키텍처 결정, 명확하지 않은 의존성 체인을 가진 다중 파일 리팩토링 (multi-file refactors) — 은 진정으로 최첨단 (frontier-level) 추론으로부터 이득을 얻으며, Anthropic과 OpenAI의 벤치마크 데이터 모두 이러한 작업 클래스에서 최첨단 모델과 중간 단계 (mid-tier) 모델 사이에 유의미한 성능 격차가 있음을 보여줍니다. LeanOps 감사에 따르면, 단계의 80%를 Haiku 4.5로 라우팅하고 어려운 20%만을 Opus 4.7로 에스컬레이션 (escalate) 하는 워크플로 (workflow) 는 모든 단계를 Opus로 처리하는 워크플로와 비교했을 때 표준 워크로드에서 유사한 최종 결과를 내면서도 60~80%의 비용 절감을 달성합니다. 엔지니어링 팀 전체에 일관되게 적용된 이 단일 라우팅 결정이 LeanOps 사례 연구에서 발생한 $87K에서 $24K로의 비용 감소의 대부분을 차지합니다.

관측성 도구 (Observability Tools) 가 놓치는 것
높은 에이전트 비용에 대한 기본 대응은 관측성 플랫폼을 설치하는 것입니다. LangSmith, Langfuse, Helicone, 그리고 Arize는 모두 비용 대시보드, 트레이스 (trace) 별 지출 내역, 에이전트당 지출 가시성을 제공합니다. 이것들은 유용합니다. 하지만 불충분하기도 합니다. 가시성 도구는 돈을 이미 사용한 후에 비용이 높다는 사실을 알려줄 뿐입니다. 파일 읽기 단계를 Opus 4.7로 보낸 라우팅 결정을 방지하지는 못합니다. Hacker News의 AgentBudget 개발자가 설명한 사례 (2026년 5월) — 10분 만에 $187의 비용을 발생시킨 GPT-4o 재시도 루프 (retry loop) — 는 관측성의 실패가 아니었습니다. 개발자는 LangSmith에서 그 일이 일어나는 것을 실시간으로 지켜볼 수 있었을 것입니다. 실패의 원인은 런타임 강제 적용 (runtime enforcement) 의 부재였습니다. 즉, "만약 이 단계 유형이 재시도이고 호출당 비용이 임계값을 초과하면, 중단하고 에스컬레이션하라"라고 말하는 규칙이 없었던 것입니다. 이것이 모니터링 (monitoring) 과 거버넌스 (governance) 의 차이입니다. 모니터링은 데이터를 표면화하고, 거버넌스는 규칙을 강제합니다. 또한 복합적인 아이러니가 존재합니다. LangSmith의 트레이스당 가격 책정은 자체적인 오버헤드 (overhead) 를 추가하며 — 기본 트레이스 1,000개당 $2.50, 확장 트레이스 1,000개당 $5.00 — 이는 대규모 배포 시 더욱 가중됩니다.

팀들은 모든 것을 잘못된 모델로 계속 라우팅(Routing)하면서 관측성 (Observability) 비용을 지불하고 있으며, 조치를 취할 수 없는 대시보드에서 청구액이 늘어나는 것을 지켜보고만 있습니다.

Waxell Runtime이 모델 라우팅을 강제하는 방법

Waxell Runtime은 에이전트 코드 상단의 거버넌스 계층 (Governance layer)에서 모델 라우팅 및 비용 규칙을 적용하며, 재빌드 (Rebuild)를 요구하지 않습니다. 각 에이전트의 내부 라우팅 로직을 수정하거나 개별 프레임워크 라이브러리를 패치하는 대신, Runtime은 토큰 예산 (Token budgets)과 모델 티어 정책 (Model tier policies)을 설정 (Configuration)으로서 강제합니다. 즉, 특정 단계 유형 (Step types)은 특정 모델 티어로 제한되고, 세션당 하드 스톱 (Hard stops)은 통제 불능의 루프 (Runaway loops)를 방지하며, 예산 임계값 (Budget thresholds)은 실행을 계속하는 대신 라우팅 변경이나 에스컬레이션 (Escalation)을 트리거합니다.

단 2줄의 코드로 200개 이상의 라이브러리를 자동으로 계측 (Instrument)하는 Waxell Observe는 Runtime의 강제 결정에 필요한 실시간 비용 텔레메트리 (Telemetry)를 제공합니다. 세션이 예산 상한선에 도달하면, Runtime은 단순히 경고만 하는 것이 아니라 정책에 따라 구성된 하위 티어로 라우팅하거나 중단합니다. 기본적으로 제공되는 26가지 정책 카테고리에는 비용 관련 제어 기능이 포함되어 있습니다: 호출당 토큰 제한 (Per-call token caps), 세션당 예산 하드 스톱 (Per-session budget hard stops), 단계 수 상한을 통한 루프 탐지 (Loop detection with step-count ceilings), 그리고 모델 티어 강제 규칙 (Model tier enforcement rules) 등입니다. 이러한 규칙들은 각 에이전트의 코드 변경 없이 에이전트 플릿 (Agent fleet) 전체에 적용됩니다.

LeanOps 사례 연구의 엔지니어링 팀은 이와 유사한 제어 기능을 수동으로 구현하는 데 3주를 소비했지만, Waxell이 계측된 시스템은 초기 거버넌스 설정을 통해 이를 적용합니다. 여기서 거버넌스 플레인 (Governance plane)의 구분이 구조적으로 중요합니다. 커스텀 코드를 통해 자체적으로 비용 제한을 강제하는 에이전트는 해당 코드의 신뢰도만큼만 신뢰할 수 있습니다. 반면 에이전트 상단에 위치하여 에이전트의 동작과 상관없이 제한을 강제하는 거버넌스 계층은, 에이전트 코드가 변경되거나 플릿에 새로운 에이전트가 추가되더라도 신뢰할 수 있습니다.

멀티 에이전트 예산 문제 (Multi-Agent Budget Problem)

에이전트가 하위 에이전트 (Sub-agents)를 생성할 때 모델 라우팅은 훨씬 더 복잡해집니다.

HN의 AgentBudget 토론(2026년 5월)에서 한 가지 실패 모드(Failure mode)가 드러났습니다: 에이전트 A가 자체 예산을 가진 에이전트 B를 생성하지만, B의 지출이 A의 한도(Ceiling)에 반영되지 않는 문제입니다. B는 자신의 예산을 모두 소진하고 멈추지만, A는 총비용이 이미 작업당 제한을 초과했다는 사실을 인지하지 못한 채 계속 실행됩니다. 단일 사용자 요청이 쿼리 분석 에이전트, 임베딩 (Embedding) 에이전트, 리랭킹 (Reranking) 에이전트, 그리고 응답 생성 에이전트를 트리거하고 각 에이전트의 과금이 독립적으로 이루어지는 파이프라인에서는, 합산된 비용이 개별 에이전트에게는 보이지 않습니다. 각 에이전트는 자신의 예산 범위 내에 있지만, 전체 합계는 그렇지 않습니다. Runtime의 예산 계층 구조 (Budget hierarchy)는 비용 전파 (Cost propagation)를 통해 이 문제를 해결합니다. 즉, 하위 에이전트의 비용이 상위 에이전트의 한도로 합산되므로, 작업 수준의 예산 캡 (Budget cap)이 트리거 에이전트뿐만 아니라 전체 실행 트리 (Execution tree)에 적용됩니다. 이는 사후 모니터링 집계가 아닌 구조적 거버넌스 (Structural governance)이며, 개발자가 런타임 전에 전체 호출 그래프 (Call graph)를 선언할 필요도 없습니다.

모든 팀이 도구 변경 전에 실행해야 하는 라우팅 감사 (Routing Audit)
도구를 변경하기 전에, 현재 지출이 실제로 어디에 사용되는지 파악하기 위해 다음의 2단계 비용 감사를 실행하십시오.

1단계 — 모든 API 호출에 단계 유형(파일 읽기, 코드 수정, 아키텍처 결정, 재시도 등)과 사용된 모델을 태깅(Tag)합니다. 단계 유형 및 모델 티어 (Model tier)별로 지출을 집계합니다. 최적화되지 않은 대부분의 시스템에서는 지출의 절반 이상이 Tier 2 또는 Tier 3 모델을 사용하는 일상적인 작업에 사용된다는 사실이 드러납니다.

2단계 — 단계 유형을 티어에 매핑합니다. 비용이 가장 많이 발생하는 상위 5개 단계 유형에 대해, 더 낮은 티어의 모델이 수용 가능한 출력을 생성하는지 확인합니다. Tier 3를 기준점 (Baseline)으로 삼아 Tier 1 및 Tier 2 모델을 사용하여 단계 유형별 벤치마크 테스트를 수행합니다.

LeanOps 감사 데이터에 따르면, 일상적인 파일 읽기, 보일러플레이트 (Boilerplate) 수정, 변수 추출 작업에서는 Haiku 4.5와 Sonnet 4.6 사이에 측정 가능한 품질 차이가 나타나지 않았습니다. 품질 격차는 아키텍처 추론 (Architectural reasoning) 및 복잡한 의존성을 가진 멀티 파일 디버깅 (Multi-file debugging) 작업에 집중되었습니다.

LeanOps의 30개 팀 연구에 따르면, 이번 감사를 완료하고 티어 라우팅 (Tier routing)을 구현한 팀들은 30일 이내에 에이전트 비용을 55~75% 절감했습니다.

자주 묻는 질문 (FAQ)

AI 에이전트를 위한 모델 티어 라우팅 (Model tier routing)이란 무엇인가요?
모델 티어 라우팅은 인지적 요구 사항 (Cognitive demand)에 따라 에이전트의 각 단계를 서로 다른 모델 티어로 전달하는 관행입니다. 파일 읽기나 변수 추출과 같은 일상적인 단계는 저렴하고 빠른 모델로 보내고, 복잡한 추론 (Reasoning) 단계는 프론티어 모델 (Frontier models)로 보냅니다. 목표는 대부분의 에이전트 프레임워크 (Agentic frameworks)가 기본적으로 수행하는 방식처럼 모든 단계를 동일한 — 대개 비싼 — 모델로 설정하는 대신, 각 단계의 실제 추론 요구 사항에 모델 비용을 맞추는 것입니다.

모델 티어 라우팅을 통해 AI 에이전트 비용을 얼마나 줄일 수 있나요?
LeanOps가 30개 엔지니어링 팀을 대상으로 실시한 감사(2026년 3월5월)에 따르면, 에이전트 단계의 80%를 Haiku 급 모델로 라우팅하고 나머지 어려운 20%를 위해 프론티어 모델을 예약하면, 모든 단계를 Opus 워크플로로 처리할 때와 비교하여 출력 품질은 유사하면서도 6080%의 비용 절감 효과를 얻을 수 있습니다. 프롬프트 캐싱 (Prompt caching) 및 컨텍스트 프루닝 (Context pruning)과 결합하여, 감사 대상 팀들은 표준 워크로드에서 측정 가능한 품질 저하 없이 30일 이내에 55~75%의 비용 절감을 달성했습니다.

관측성 플랫폼 (Observability platform)만으로는 이 문제를 해결하기에 충분하지 않은 이유는 무엇인가요?
LangSmith나 Helicone과 같은 관측성 플랫폼은 비용이 어디에 사용되었는지 사후에 보여줍니다. 이들은 라우팅 결정을 강제하거나, 애초에 비싼 모델 호출이 발생하는 것을 방지하지 못합니다. 모니터링의 공백은 가시성 (Visibility)의 문제가 아니라 집행 (Enforcement)의 문제입니다. 모델 라우팅 정책은 실행 후 비용 대시보드에 나타나는 것이 아니라, API 호출이 나가기 전 실행 시점 (Execution time)에 적용되어야 합니다.

모델 티어 라우팅이 출력 품질에 영향을 미치나요?
일상적인 에이전트 단계 — 파일 읽기, 변수 추출, 구조화된 데이터 파싱 (Structured data parsing), 상용구 코드 편집 (Boilerplate code edits) — 에 있어서는 대부분의 워크로드에서 Haiku 4.5의 품질이 Sonnet 4.6과 대등합니다.

품질 차이는 모호하고 문맥 의존적인 입력값에 대해 다단계 추론 (multi-step reasoning)이 필요한 작업, 즉 아키텍처 결정, 명확하지 않은 의존성 체인을 가진 다중 파일 리팩토링 (multi-file refactors), 보안 분석 (security analysis) 등에 집중됩니다. 라우팅 (Routing) 결정은 직관이 아닌 단계 유형별 실증적 품질 벤치마크 (empirical quality benchmarks)를 기반으로 이루어져야 합니다. 멀티 에이전트 예산 상속 문제 (multi-agent budget inheritance problem)란 무엇일까요? 에이전트가 하위 에이전트 (sub-agents)를 생성할 때, 각 하위 에이전트의 비용이 상위 에이전트의 예산 상한선 (budget ceiling)에 포함되지 않을 수 있습니다. 예산 내에 머무는 것처럼 보이는 작업이라도 하위 에이전트의 지출이 상위로 전파되지 않기 때문에 예산을 초과할 수 있습니다. 자식 비용을 부모의 상한선으로 합산하는 런타임 예산 계층 구조 (Runtime budget hierarchy)는 이러한 유형의 보이지 않는 초과 지출을 방지합니다. 이는 사후에나 에이전트별 대시보드에 나타나는 문제입니다. Waxell은 코드 변경 없이 어떻게 모델 라우팅 (model routing)을 강제할까요? Waxell Runtime은 에이전트 코드 상위 단계인 계측 레이어 (instrumentation layer)를 통해 거버넌스 레이어 (governance layer)에서 라우팅 정책을 적용합니다. 에이전트는 내부적으로 라우팅 로직을 구현하지 않습니다. 런타임 정책은 어떤 단계 유형에 어떤 모델 티어 (model tiers)가 허용되는지, 그리고 세션당 어떤 비용 제한이 적용되는지를 정의합니다. 이러한 규칙은 에이전트별 재빌드 (rebuilds)가 아닌 거버넌스 설정 (governance configuration)을 통해 에이전트 플릿 (agent fleet) 전체에 적용됩니다. 재빌드는 필요하지 않습니다. 출처: Ravi Kanani, "Agentic AI Cost