AI 제품을 만들 때 쉬운 요청과 어려운 요청이 섞입니다.
"문장을 JSON으로 변환해줘"
"이 repository의 장애 원인을 찾고 수정해줘"
둘 모두에게 가장 강한 모델을 쓰는 것은 단순하지만 비용 효율적이지 않을 수 있습니다.
그래서 model routing이 중요해집니다.
세 모델의 역할을 나눠볼 수 있습니다
GPT-6 계열은 Luna, Sol, Astra처럼 비용과 능력이 다른 층을 제공합니다.
개념적으로 다음처럼 나눌 수 있습니다.
Luna → 단순 분류, 추출, 짧은 변환
Sol → 복잡한 코딩, agent workflow
Astra → 가장 어려운 end-to-end 작업
이것은 절대적인 규칙이 아니라 routing을 설계하기 위한 출발점입니다.
가격 차이는 매우 큽니다
OpenAI의 2026년 9월 표준 API 가격 기준으로 short-context 입력/출력 단가는 모델별로 큰 차이가 있습니다.
따라서 모든 요청을 Astra로 보내는 것과 Luna에서 시작해 일부만 escalation하는 것은 전체 비용 구조가 완전히 다를 수 있습니다.
하지만 가장 싼 모델로만 보내는 것도 답은 아닙니다. 실패와 재시도가 늘면 오히려 비용이 증가합니다.
Static Routing부터 시작하세요
처음에는 복잡한 AI router가 필요 없습니다.
if task_type in {"extract", "classify", "rewrite"}:
model = "luna"
elif task_type in {"code", "analysis"}:
model = "sol"
else:
model = "astra"
업무 유형을 이미 알고 있다면 이 정도가 가장 설명하기 쉽고 운영도 편합니다.
더 좋은 방식: 실패 기반 Escalation
한 단계 더 나아가면 결과 검증이 routing을 결정하게 만들 수 있습니다.
Luna
↓ schema validation 실패
Sol
↓ tests / rubric 실패
Astra
이 방식의 장점은 "이 요청이 어려워 보인다"는 추측보다 실제 성공 조건을 사용한다는 것입니다.
CodeBridge Mini Lab: 100개의 요청으로 routing simulation
과거 요청 100개를 뽑아 다음을 기록합니다.
task,type,luna_ok,sol_ok,astra_ok,luna_cost,sol_cost,astra_cost
1,extract,1,1,1,0.001,0.01,0.05
2,code,0,1,1,0.003,0.08,0.31
그리고 세 전략을 비교합니다.
A. Always Astra
B. Always Sol
C. Luna → Sol → Astra escalation
비교 지표:
- 전체 성공률
- 총 API 비용
- 평균 latency
- escalation 비율
이 정도만 계산해도 routing이 실제로 이득인지 확인할 수 있습니다.
Router 모델 자체가 복잡해지면 비용이 생깁니다
요청을 분류하기 위해 또 다른 LLM을 호출하면 routing 비용과 실패 가능성이 추가됩니다.
그래서 초기에는 다음 순서가 좋습니다.
Rules
→ validation-based escalation
→ 필요하면 learned / LLM router
Routing은 모델뿐 아니라 effort에도 적용됩니다
같은 모델 안에서도 단계화할 수 있습니다.
Sol medium
→ Sol high
→ Sol max
→ Astra high
모델과 reasoning effort를 함께 보면 더 세밀한 cost-quality frontier를 만들 수 있습니다.
결론: 최고 모델 하나보다 좋은 escalation policy가 더 경제적일 수 있습니다
AI 시스템의 목표는 leaderboard 1위 모델을 쓰는 것이 아니라 요구 품질을 만족하는 비용 구조를 만드는 것입니다.
따라서 질문을 이렇게 바꿔보세요.
모든 요청에 어떤 모델을 쓸까?
보다
어떤 실패 신호가 나오면 다음 모델로 올릴까?
가 더 운영적인 질문입니다.