대부분의 AI 에이전트는 실행의 모든 단계를 단일 모델에 의존합니다. 계획 수립, 도구 호출, 데이터 추출, 요약, 오류 복구 등이 모두 동일한 LLM을 통해 처리됩니다. 이러한 방식은 초기 프로토타입 단계에서는 간단하지만, 프로덕션 환경에서는 상당한 비효율성을 초래합니다.
심층적인 추론이 필요한 계획 단계와 기본적인 JSON 추출 단계에 동일한 모델을 사용할 필요는 없습니다. 코드 생성 작업은 분류 작업과는 다른 요구 사항을 가집니다. 날짜 문자열 형식을 지정하기 위해 Claude Fable 5나 Claude Opus 4.8과 같은 고성능 추론 모델을 사용하는 것은 비용 측면에서 자원을 낭비하는 일입니다.
다중 모델을 사용하여 AI 에이전트를 구축하면 워크플로우의 각 단계를 해당 작업에 가장 적합한 모델로 라우팅할 수 있습니다. 이 가이드에서는 이러한 다중 모델 아키텍처를 설계, 구현 및 관리하는 방법을 살펴봅니다.
에이전트 오케스트레이션 계층이 아닌 API 계층에서 작업 중이라면, 이 가이드와 함께 에이전트 우선 API 설계(Agent-First API Design) 및 팀들이 직접 모델 API에서 통합 AI API로 전환하는 이유(Why Teams Switch from Direct Model APIs to a Unified AI API)를 참조하십시오. 다중 모델 에이전트는 기본 API 인터페이스가 오케스트레이션 코드를 다시 작성하지 않고도 모델을 교체할 수 있을 만큼 안정적일 때 가장 안정적으로 작동합니다.
:::info
핵심 요약
- 작업 복잡도에 모델 매칭: 라우팅, 추출, 형식 지정에는 작고 빠른 모델을 사용하고, 계획 수립 및 복잡한 분석에는 더 큰 추론 모델을 예약하십시오.
- 스키마 표준화: 모델 제공업체를 전환할 때 발생하는 계약 불일치를 방지하기 위해 모든 핸드오프 단계에서 엄격한 출력 검증(예: Pydantic)을 구현하십시오.
- 폴백(Fallback) 설계: 속도 제한, 제공업체 중단 또는 지연 시간 급증 시 에이전트 워크플로우를 방해하지 않도록 자동 폴백 경로를 구축하십시오.
- 텔레메트리 중앙 집중화: 지연 시간, 입/출력 토큰 수, 단계별 비용을 추적하여 라우팅 로직을 지속적으로 최적화하십시오. :::
다중 모델 에이전트 아키텍처
다중 모델 에이전트 아키텍처는 복잡성, 비용 및 지연 시간 요구 사항에 따라 작업을 전문 모델에 분산합니다.
사용자 요청
│
▼
┌─────────────┐
│ 라우터 │ ← 작업 복잡도 분류
│ (빠른 모델)│
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│단순 │ │복잡 │
│모델 │ │모델 │
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ 집계기 │ ← 결과 결합
│ (빠른 모델)│
└─────────────┘
핵심 아키텍처는 다음 5가지 구성 요소로 이루어집니다:
- 라우터: 작업의 복잡도와 의도에 따라 분류하는 빠르고 저렴한 모델.
- 모델 풀: 작업 유형(추론, 추출, 코드 생성 등)에 맞춰진 모델 모음.
- 집계기: 병렬 단계의 결과를 최종 응답으로 결합하는 빠른 모델.
- 폴백 정책: 기본 모델이 실패하거나, 시간 초과가 발생하거나, 속도 제한에 걸릴 경우 사용할 모델을 결정하는 규칙.
- 텔레메트리 계층: 모델 선택, 지연 시간, 단계별 정확한 토큰 비용을 기록하는 로깅 시스템.
폴백 정책과 텔레메트리가 없으면 다중 모델 에이전트는 디버깅이 어려워지고 지연 시간과 비용 프로필을 예측할 수 없게 됩니다.
OpenAI SDK를 이용한 구현
통합 API 게이트웨이를 사용하면 단일 SDK와 API 키를 사용하여 다양한 제공업체의 모델에 액세스할 수 있습니다. 이는 모델 교체와 라우팅을 단순화합니다.
다음 예제는 기본적인 라우팅 구현을 보여줍니다. 모델 가용성과 가격은 TokenLab 모델 디렉토리에서 확인해야 합니다.
from openai import OpenAI
client = OpenAI(
api_key="sk-tokenlab-xxx",
base_url="https://api.tokenlab.sh/v1"
)
# 비용 및 기능 계층별 모델 풀
MODELS = {
"router": "deepseek-v4-flash", # 빠른 분류
"simple": "deepseek-v4-flash", # 추출, 형식 지정
"reasoning": "claude-sonnet-5", # 계획, 분석
"complex": "gpt-5.5", # 코드 생성, 복잡한 로직
"budget": "deepseek-v4-flash", # 대량 처리
}
def route_task(task: str) -> str:
"""저비용 모델을 사용하여 작업 복잡도를 분류합니다."""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """이 작업을 다음 카테고리 중 하나로 분류하세요:
- simple: 데이터 추출, 형식 지정, 번역
- reasoning: 분석, 계획, 비교
- complex: 코드 생성, 다단계 문제 해결
- budget: 대량 처리, 비중요 작업
카테고리 이름만 소문자로 응답하세요."""},
{"role": "user", "content": task}
],
max_tokens=10
)
category = response.choices[0].message.content.strip().lower()
return MODELS.get(category, MODELS["simple"])
def execute_task(task: str, context: str = "") -> str:
"""작업을 선택된 모델로 라우팅하고 실행합니다."""
model = route_task(task)
messages = []
if context:
messages.append({"role": "system", "content": context})
messages.append({"role": "user", "content": task})
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
실전 에이전트: 코드 리뷰 파이프라인
다중 모델을 활용한 AI 에이전트 구축의 실질적인 효과를 확인하기 위해 풀 리퀘스트(PR)를 검토하는 파이프라인을 고려해 보겠습니다. 이 워크플로우는 전체 코드 diff를 하나의 비싼 모델에 보내는 대신, 리뷰를 전문적인 단계로 나눕니다.
def review_pr(diff: str) -> dict:
"""다중 모델 PR 리뷰 파이프라인."""
# 1단계: 빠르고 저렴한 모델을 사용하여 변경 사항 분류
classification = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[{
"role": "user",
"content": f"이 코드 변경 사항을 분류하세요: {diff[:2000]}\n"
"카테고리: bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# 2단계: 강력한 추론 모델을 사용하여 보안 스캔 수행
security = client.chat.completions.create(
model="claude-sonnet-5",
messages=[{
"role": "system",
"content": "당신은 보안 검토자입니다. 다음을 확인하세요: "
"SQL 인젝션, XSS, 인증 우회, 코드 내 비밀값, "
"안전하지 않은 역직렬화. 줄 번호를 구체적으로 명시하세요."
}, {
"role": "user",
"content": f"이 diff의 보안 문제를 검토하세요:\n{diff}"
}]
).choices[0].message.content
# 3단계: 범용 모델을 사용하여 코드 품질 분석
quality = client.chat.completions.create(
model="gpt-5.5",
messages=[{
"role": "user",
"content": f"코드 품질 검토: 명명 규칙, 구조, "
f"오류 처리, 테스트 커버리지.\n{diff}"
}]
).choices[0].message.content
# 4단계: 빠르고 저렴한 모델을 사용하여 요약 생성
summary = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[{
"role": "user",
"content": f"이 PR 리뷰를 3개의 글머리 기호로 요약하세요:\n"
f"유형: {classification}\n"
f"보안: {security[:500]}\n"
f"품질: {quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
비용 및 효율성 최적화
아래 표는 이 파이프라인에 대한 모델 할당을 요약한 것입니다. 정확한 가격은 제공업체와 사용량에 따라 다르므로 TokenLab 모델 디렉토리에서 현재 요금을 확인하십시오.
| 단계 | 모델 | 입력 토큰 | 역할 / 전문 분야 |
|---|---|---|---|
| 1. 분류 | DeepSeek V4 Flash | ~2,100 | 빠른 분류, 저비용 라우팅 |
| 2. 보안 | Claude Sonnet 5 | ~2,500 | 심층 추론, 보안 분석 |
| 3. 품질 | GPT-5.5 | ~2,500 | 고급 코드 품질 및 구조적 검토 |
| 4. 요약 | DeepSeek V4 Flash | ~1,200 | 빠른 저비용 텍스트 집계 |
4단계 모두를 Claude Sonnet 5나 GPT-5.5와 같은 플래그십 추론 모델로 실행하면 비용이 크게 증가합니다. 더 간단한 작업을 DeepSeek V4 Flash와 같은 저비용 모델로 라우팅함으로써, 다중 모델 파이프라인은 핵심 보안 분석 단계에 필요한 심층 추론 능력을 유지하면서 전체 토큰 비용을 절감합니다.
가격뿐만 아니라 기능에 따른 라우팅
비용 절감이 일반적인 목표이긴 하지만, 라우팅 결정은 특정 모델의 기능도 고려해야 합니다. 강력한 라우팅 정책은 다음 4가지 핵심 차원에서 모델을 평가합니다:
- 추론 깊이: 복잡한 로직, 계획 수립, 다단계 추론.
- 컨텍스트 윈도우: 작업에 필요한 배경 정보나 코드의 양.
- 도구 사용 신뢰성: 함수 호출 및 구조화된 출력 생성의 정확도.
- 지연 시간 민감도: 사용자 대면 애플리케이션의 속도 요구 사항.
이러한 차원은 명확한 라우팅 규칙을 수립하는 데 도움이 됩니다:
- 분해 및 계획 작업은 추론 중심 모델로 라우팅합니다.
- 데이터 추출 및 형식 지정 작업은 빠르고 저렴한 모델로 라우팅합니다.
- 코드 생성 및 구문 분석 작업은 코딩 작업에 최적화된 모델로 라우팅합니다.
- 저장소 전체 분석 작업은 컨텍스트 윈도우가 큰 모델로 라우팅합니다.
라우터를 이러한 요구 사항에 맞추려면 코딩 모델 비교 및 가격 비교를 참조하여 워크플로우 단계와 현재 모델 벤치마크를 일치시키십시오.
LangChain 통합
LangChain과 같은 오케스트레이션 프레임워크 내에서도 다중 모델 라우팅을 구현할 수 있습니다. 다음 예제는 통합 API 기본 URL을 사용하여 서로 다른 모델을 구성하는 방법을 보여줍니다:
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
# 개별 구성으로 모델 초기화
fast_model = ChatOpenAI(
model="deepseek-v4-flash",
api_key="sk-tokenlab-xxx",
base_url="https://api.tokenlab.sh/v1"
)
reasoning_model = ChatOpenAI(
model="claude-sonnet-5",
api_key="sk-tokenlab-xxx",
base_url="https://api.tokenlab.sh/v1"
)
# 전문 체인 정의
classify_chain = ChatPromptTemplate.from_template(
"이 요청의 의도를 분류하세요: {input}"
) | fast_model
analyze_chain = ChatPromptTemplate.from_template(
"이 문제에 대한 상세 분석을 수행하세요: {input}"
) | reasoning_model
다중 모델 에이전트를 사용해야 할 때
다중 모델을 도입하면 아키텍처 복잡성이 증가합니다. 이 방식은 일반적으로 다음과 같은 경우에 가장 유용합니다:
- 다양한 작업 요구 사항: 에이전트가 단순 작업(분류, 형식 지정 등)과 복잡한 작업(전략적 계획, 코드 생성 등)을 혼합하여 처리하는 경우.
- 높은 사용량 및 비용: 월간 API 지출이 최적화를 통해 의미 있는 절감 효과를 얻을 수 있을 만큼 높은 경우.
- 전문 모델의 강점 활용: Gemini의 컨텍스트 윈도우, Claude의 코딩 능력, GPT의 도구 사용 속도 등 특정 제공업체의 강점을 워크플로우에 활용하려는 경우.
- 비대칭적 지연 시간 요구: 워크플로우의 일부는 즉시 결과를 반환해야 하고, 다른 배경 단계는 더 오래 걸려도 되는 경우.
단일 목적 에이전트나 단순한 채팅 인터페이스의 경우, 단일 모델을 유지하는 것이 더 쉬운 경우가 많습니다. 모든 요청이 동일한 수준의 능력을 필요로 한다면 라우팅의 운영 오버헤드는 정당화되지 않을 수 있습니다.
일반적인 실패 모드
다중 모델 아키텍처는 완화가 필요한 특정 실패 모드를 도입합니다:
1. 과도하게 설계된 라우터
라우터 프롬프트가 지나치게 복잡해지면 분류 단계 자체가 느리고 비싸질 수 있습니다. 라우팅 프롬프트를 간결하게 유지하고 분류 카테고리를 광범위하게 설정하십시오.
2. 출력 계약 불일치(Output Contract Drift)
서로 다른 모델은 JSON을 반환하도록 지시받더라도 출력을 다르게 형식화할 수 있습니다. 한 모델은 원시 JSON을 반환하고, 다른 모델은 마크다운 블록으로 감쌀 수 있습니다. 다운스트림 파서 오류를 방지하려면 모든 단계 핸드오프에서 Pydantic과 같은 검증 라이브러리를 사용하여 엄격한 스키마를 강제하십시오.
3. 조용한 품질 저하
기본 제공업체 중단 시 폴백 정책이 하위 계층 모델로 요청을 라우팅하면, 에이전트가 오류를 발생시키지 않고 품질이 낮은 답변을 반환할 수 있습니다. 명확한 속도 제한 전략과 알림 시스템을 구현하면 폴백이 활성화된 시점을 추적하는 데 도움이 됩니다.
4. 파편화된 텔레메트리
모델 사용량이 여러 직접 제공업체 API에 분산되면 비용 및 성능 지표를 집계하기가 어려워집니다. 단일 게이트웨이를 통해 요청을 중앙 집중화하면 로깅 및 비용 추적이 단순화됩니다.
최소 평가 루프
다중 모델 에이전트를 유지 관리하려면 성능을 추적하기 위한 기본적인 평가 루프를 구축하십시오. 각 실행에 대해 다음 지표를 데이터베이스 테이블에 기록할 수 있습니다:
- 작업 카테고리: 라우터가 할당한 분류.
- 선택된 모델: 각 단계에 대해 선택된 모델.
- 단계 지연 시간: 각 단계를 완료하는 데 걸린 시간.
- 토큰 사용량: 정확한 입력 및 출력 토큰 수.
- 폴백 상태: 폴백 모델이 트리거되었는지 여부.
- 사용자 피드백: 최종 출력이 성공적이었는지에 대한 이진 지표.
이 데이터를 분석하면 라우터가 올바른 모델을 선택하고 있는지, 어떤 단계가 비용의 대부분을 차지하는지, 폴백 모델이 허용 가능한 품질을 유지하고 있는지 확인하는 데 도움이 됩니다.
FAQ
서로 다른 모델 간의 다양한 프롬프트 형식을 어떻게 처리하나요?
모델마다 가장 잘 반응하는 프롬프트 구조가 다릅니다. 예를 들어, 어떤 모델은 시스템 프롬프트에서 더 잘 작동하고, 어떤 모델은 사용자 프롬프트에 포함된 지침을 선호합니다. 이를 처리하려면 풀의 모든 모델에 동일한 원시 문자열을 보내는 대신, 대상 모델에 따라 조정되는 템플릿으로 프롬프트를 추상화하십시오.
라우팅이 사용자 대면 애플리케이션에 너무 많은 지연 시간을 추가하지 않나요?
라우팅은 분류 단계에 약간의 지연 시간을 추가합니다. 라우터에 고도로 최적화된 저지연 모델을 사용하고, 최대 토큰 제한을 낮게 유지(10 토큰 미만)하거나, 사용자의 애플리케이션 상태나 진입점에서 분류를 추론할 수 있을 때 단계를 병렬화하여 이를 최소화할 수 있습니다.
모델 간 전환 시 JSON 파싱 오류를 어떻게 방지하나요?
파싱 오류를 방지하려면 모델 제공업체가 지원하는 구조화된 출력 기능(JSON 모드 또는 도구 호출 등)을 사용하십시오. 또한, Pydantic이나 유사한 라이브러리를 사용하여 모든 모델 출력을 검증 계층으로 감싸 파이프라인의 다음 단계로 전달하기 전에 페이로드를 파싱, 검증 및 복구하십시오.
하나의 API로 모든 모델에 액세스하세요: TokenLab 시작하기를 통해 단일 API 키로 300개 이상의 모델에 액세스할 수 있습니다. 여러 제공업체 계정을 관리하거나 API마다 라우팅 로직을 다시 작성할 필요 없이 다중 모델 에이전트를 구축하세요.
출처
2026-07-07 기준 가격
- TokenLab model directory2026-07-07 기준 확인
- Berkeley Function Calling Leaderboard2026-07-09 기준 확인
- SWE-bench2026-07-09 기준 확인
- RouteLLM paper2026-07-09 기준 확인
- Braintrust LLM router guide2026-07-09 기준 확인
