현재 가격 차이는 이렇습니다: 오픈 웨이트 모델 (open-weight models)은 입력 토큰 100만 개당 약 0.14달러 수준입니다. 반면 프런티어 플래그십 (Frontier flagships) 모델은 5.00달러입니다. 무려 35배의 격차입니다. 그리고 대부분의 파이프라인은 모든 요청을 비싼 모델로 보냅니다. 왜냐하면 모든 것을 최상의 모델로 라우팅하는 것이야말로, 아키텍처 결정을 내리지 않았을 때 얻게 되는 아키텍처이기 때문입니다.

해결책은 지루합니다. 그리고 지루한 것이 제가 가장 좋아하는 종류의 해결책입니다.

1단계: 모델이 아니라 워크로드를 분류하세요

"어떤 모델이 가장 좋은가?"라고 묻는 것을 멈추고, "어떤 작업이 저렴하고 안전한가?"라고 묻기 시작하십시오. 분류는 거의 항상 동일합니다:

• 대량 발생, 낮은 모호성 (High-volume, low-ambiguity) — 추출 (extraction), 분류 (classification), 포맷팅 (formatting), 요약 (summarization) → 저렴한 티어 (cheap tier)
• 다단계 추론 (Multi-step reasoning), 고객 대면 작업 (anything customer-facing) → 프런티어 티어 (frontier tier)

두 티어 모두 앞에 동일한 인터페이스를 두어, 호출자는 어떤 티어가 응답했는지 알 필요도 없고 신경 쓸 필요도 없게 만듭니다.

2단계: 라우터는 아마도 200줄 정도면 충분합니다

여기에 뼈대가 있습니다 — 작업 레지스트리 (task registry), 두 개의 티어, 하나의 디스패치 함수 (dispatch function):

from dataclasses import dataclass

PRICE_PER_MTOK = {"cheap": 0.14, "frontier": 5.00}  # $/1M input tokens
...

extract_invoice_fields   -> cheap
classify_ticket          -> cheap
format_to_json           -> cheap
...

summarize_call을 주목해 보세요. 이 작업은 저렴한 티어를 원했지만, 평가 점수 (eval score)가 임계값 (threshold) 아래로 떨어졌기 때문에 라우터가 자동으로 프런티어 티어로 다시 보냈습니다. 아무도 새벽 3시에 깨어날 필요가 없었습니다. 이것이 설계의 전부입니다. 작업별 골든 데이터셋 (golden dataset)과 임계값이 안전망 역할을 하며, 라우터는 단지 if 문일 뿐입니다.

그리고 이것이 이 포스트의 솔직한 부분입니다: 라우터는 사소합니다. 평가 하네스 (eval harness)가 진짜 핵심 작업입니다. 작업별로 골든 데이터셋을 구축하고, 모델이 변경될 때마다 점수를 매기며, 그 점수를 디스패치에 연결하는 것 — 바로 그곳에 엔지니어링 시간이 투입됩니다. 이 과정을 건너뛰는 팀들은 결국 '느낌 (vibes)'에 의존해 라우팅하게 되며, 느낌은 항상 비싼 모델로 라우팅됩니다. 왜냐하면 플래그십 모델을 선택해서 잘리는 사람은 아무도 없기 때문입니다.

3단계: 경영진을 설득하는 산술법

monthly_mtok = 100  # 100M input tokens/month

def bill(cheap_share: float) -> float:
...

0%의 트래픽이 저렴한 티어(cheap tier)에 있을 때 -> 100M 토큰당 월 $500
30%의 트래픽이 저렴한 티어(cheap tier)에 있을 때 -> 100M 토큰당 월 $354
50%의 트래픽이 저렴한 티어(cheap tier)에 있을 때 -> 100M 토큰당 월 $257
...

트래픽의 절반만 라우팅(routing)해도 비용이 거의 절반으로 줄어듭니다. 저렴한 티어(cheap tier)가 훨씬 저렴하기 때문에 그 기여도가 거의 미미할 정도입니다. 이 수치들을 실제 토큰 볼륨(token volume)에 맞춰 확장해 보세요. 비율은 그대로 유지됩니다.

이것은 이론적인 이야기가 아닙니다. 한 대형 거래소는 1,200개의 에이전트(agent) 전체에 정확히 이 방식을 재구축하여 AI 지출을 거의 절반으로 줄였습니다. 더 나은 프롬프트(prompt)를 만든 것도, 새로운 모델(model)을 도입한 것도 아닙니다. 라우터(router)와 워크로드 맵(workload map)이었습니다.

해결책은 평소와 같습니다. 이것은 AI의 탈을 쓴 데이터 문제입니다. 워크로드 맵(workload map)은 사용 로그(usage logs)에서 나옵니다. 황금 데이터셋(golden datasets)은 레이블이 지정된 데이터 파이프라인(data pipelines)입니다. 평가 점수(eval scores)는 테이블(table)에 존재합니다. AI 트래픽을 하나의 데이터셋(dataset)으로 취급하는 팀은 35배의 격차를 자신들에게 유리하게 활용합니다.

오늘날 여러분의 트래픽은 어디로 향하고 있습니까? 모든 것에 하나의 모델을 사용하고 있습니까, 아니면 티어(tiers)를 나누고 있습니까?

저는 Vinicius Fagundes입니다. 상파울루의 수석 데이터 엔지니어(principal data engineer), 독립 컨설턴트이자 MBA 강사입니다. 저는 데이터 파이프라인(data pipelines)과 그 위에서 작동하는 경제학에 대해 글을 쓰며, 매 분기 vf-insights.com을 통해 몇몇 플랫폼 프로젝트를 수행합니다.