Originally published on madgeek.ai. We build production AI systems and custom software for enterprises.

모델 라우팅 (Model routing)은 각 작업이 실제로 필요로 하는 요구 사항에 따라 서로 다른 AI 작업을 서로 다른 모델 계층 (model tiers)으로 전달하는 관행입니다. 분류 (classification) 작업은 가장 저렴한 모델로 보내집니다. 요약 (summarisation) 작업은 중간 계층 모델로 보내집니다. 워크플로 내에 복잡한 추론 (complex reasoning)이 존재한다면, 이는 가장 성능이 뛰어난 모델로 보내집니다. 각 작업은 품질 임계값 (quality threshold)을 충족하는 가장 저렴한 엔드포인트 (endpoint)에 도달합니다.

이 패턴은 대부분의 프로덕션 AI 시스템에서 API 비용을 80-95%까지 절감합니다. 이는 AI 비용 효율성을 위한 단일 항목 중 가장 영향력 있는 아키텍처 결정입니다. 그리고 대부분의 개발 팀은 이를 건너뜁니다.

왜 모델 라우팅은 표준 관행이 아닐까요?

왜냐하면 고객이 프로덕션 볼륨 (production volume)에 도달할 때까지는 체감할 수 없는 이득을 위해, 초기에 더 많은 엔지니어링 작업이 필요하기 때문입니다.

라우팅 없이 구축하는 개발 팀은 모델 하나를 선택하고, 한 세트의 프롬프트 (prompts)를 작성하여 배포합니다. 반면 라우팅을 적용하여 구축하는 팀은 모든 워크플로를 개별 작업으로 분해하고, 여러 모델 계층에 걸쳐 각 작업을 평가하며, 각 계층에 맞는 작업별 프롬프트를 엔지니어링하고, 라우팅 로직 자체를 구축하며, 경로별 품질과 비용을 추적하기 위한 모니터링 도구를 갖추어야 합니다. 이는 데모 단계에서 고객에게는 동일해 보이는 결과를 얻기 위해 3~5배 더 많은 엔지니어링 작업을 수행하는 것입니다.

비용 차이는 규모가 커질 때만 눈에 보입니다. 하루에 API 호출이 100건일 때는 아무도 눈치채지 못합니다. 10,000건일 때는 하루 300달러 대 16달러가 됩니다. 50,000건일 때는 그 차이가 생존의 문제가 됩니다. 즉, 하루 1,500달러 대 80달러가 됩니다.

고정 가격 계약으로 AI 시스템을 구축하는 벤더(Vendors)들은 이러한 추가 작업을 수행할 동기가 없습니다. 그들은 작동하는 제품을 인도하기 위해 비용을 지불받는 것이지, 운영 비용을 최적화하기 위해 받는 것이 아니기 때문입니다. API 비용은 벤더가 아닌 고객이 지불합니다.

모델 라우팅은 실제로 어떻게 작동하나요?

라우팅 계층 (routing layer)은 애플리케이션 로직과 AI 제공업체의 API 사이에 위치합니다. 작업(task)을 처리해야 할 때, 라우터는 해당 작업이 어떤 종류인지 평가하고 적절한 모델 티어 (model tier)로 전달합니다. 세 가지 일반적인 라우팅 전략이 있습니다:

**정적 라우팅 (Static routing)**은 빌드 타임 (build time)에 각 작업 유형에 고정된 모델 티어를 할당합니다. 추출 (Extraction) 작업은 항상 Haiku로 전송됩니다. 요약 (Summarisation)은 항상 Sonnet으로 전송됩니다. 이는 가장 단순한 접근 방식이며 90%의 유스케이스 (use cases)를 처리합니다. 매핑은 아키텍처 단계에서 각 작업을 모델 티어별로 테스트하고, 품질 임계값 (quality threshold)을 충족하는 가장 저렴한 모델을 선택함으로써 결정됩니다.

**복잡도 기반 라우팅 (Complexity-based routing)**은 모델을 선택하기 전에 입력을 분석합니다. 단순한 입력 (짧고, 구조화되어 있으며, 표준 형식인 경우)은 저렴한 티어로 전송됩니다. 복잡한 입력 (길고, 비구조화되어 있으며, 엣지 케이스 (edge-case)가 많은 경우)은 더 유능한 티어로 전송됩니다. 이는 입력의 복잡도가 크게 변하는 작업, 즉 대부분의 입력은 쉽지만 가끔 정말 어려운 입력이 발생하는 작업에 효과적입니다.

**폴백 라우팅 (Fallback routing)**은 가장 저렴한 모델로 시작하여 단계적으로 격상합니다. 작업을 먼저 Haiku로 보냅니다. 만약 출력이 품질 검사 (신뢰도 점수 (confidence score), 형식 검증 (format validation), 일관성 검사 (consistency check))를 통과하지 못하면, 자동으로 Sonnet에서 재시도합니다. 그마저도 실패하면 Opus로 격상합니다. 대부분의 호출은 첫 번째 시도에서 해결됩니다. 시스템은 저렴한 모델이 특정 입력을 처리할 수 없다는 것이 입증될 때만 비싼 모델에 대한 비용을 지불합니다.

실제로는 이들을 조합하여 사용합니다. 잘 파악된 대다수의 작업에는 정적 라우팅을 사용하고, 엣지 케이스의 빈도를 예측할 수 없는 작업에는 폴백 라우팅을 사용합니다.

라우팅 아키텍처는 코드에서 어떤 모습인가요?

라우팅 계층은 별도의 서비스가 아닙니다. 애플리케이션의 AI 계층에 내장된 아키텍처 패턴입니다. 가장 단순한 형태는 다음과 같은 설정 맵 (configuration map)입니다:

시스템의 각 태스크(task)는 정의된 스킬(skill)을 가집니다. 스킬이란 고유한 프롬프트(prompt), 모델 할당(model assignment), 그리고 품질 임계값(quality threshold)을 가진 별개의 테스트 가능한 함수입니다. 오케스트레이터(orchestrator)는 스킬을 순차적으로 호출하며, 각 스킬은 적절한 모델로 라우팅(routing)됩니다. 태스크 정의에는 모델 티어(model tier), 프롬프트 템플릿(prompt template), 예상 출력 스키마(expected output schema), 그리고 품질 검증 함수(quality validation function)가 포함됩니다.

이것이 바로 우리가 말하는 에이전트 스킬 설계(agent skill design)입니다. 각 스킬은 독립적으로 테스트할 수 있고, 시스템의 나머지 부분에 영향을 주지 않고도 다른 모델 티어로 교체할 수 있으며, 비용과 품질을 격리하여 모니터링할 수 있는 자급자족적인(self-contained) 단위입니다.

무엇이 문제인가?

두 가지가 있습니다.

첫째, 각 모델 티어마다 서로 다른 **프롬프트 요구사항(prompt requirements)**이 있습니다. Opus에서 작동하는 프롬프트가 Haiku에서 반드시 작동하는 것은 아닙니다. Opus는 관대합니다. 모호한 지시사항에서도 의도를 추론합니다. 반면 Haiku는 문자 그대로 해석합니다. 즉, 프롬프트 내에 명시적인 구조, 출력 형식 정의, 그리고 예외 상황 처리(edge case handling)가 포함되어야 합니다. 저렴한 모델을 위한 효과적인 프롬프트를 작성하는 것은 성능이 뛰어난 모델을 위한 프롬프트를 작성하는 것과는 다른 기술입니다.

둘째, 태스크 수준에서의 품질 검증(quality validation)이 필요합니다. 태스크를 더 저렴한 모델로 라우팅할 때는 출력이 임계값을 충족하는지 확인할 방법이 필요합니다. 구조화된 태스크(추출, 분류)의 경우, 스키마 검증(schema validation), 필드 완전성 체크(field completeness checks), 신뢰도 점수 산출(confidence scoring) 등을 통해 비교적 간단히 해결할 수 있습니다. 생성형 태스크(요약, 콘텐츠 생성)의 경우, 품질 검증이 더 어렵고 때로는 첫 번째 모델의 출력을 평가하기 위해 두 번째 모델 호출이 필요할 수도 있습니다.

이 두 가지 모두 해결 가능한 문제입니다. 다만, 기본적인 API 통합만 수행하는 팀이 고려하는 문제들은 아닐 뿐입니다. 왜냐하면 프로덕션 볼륨(production volume)이 커져서 비용 문제가 가시화될 때까지는 이 문제들이 드러나지 않기 때문입니다.

기존 시스템에 라우팅을 사후 적용(retrofit)할 수 있는가?

시스템이 어떻게 구축되었느냐에 따라 다릅니다.

만약 작업(tasks)들이 이미 깔끔한 인터페이스를 가진 별개의 함수 호출(function calls)로 분리되어 있다면, 라우팅(routing)을 추가하는 것은 설정(configuration)의 문제입니다. 작업별로 모델 계층(model tier)을 정의하고, 각 계층에 맞는 작업별 프롬프트(task-specific prompts)를 작성하고, 검증(validation)을 추가한 뒤 배포하면 됩니다. 소요 기간: 2~4주.

만약 시스템이 모놀리식 프롬프트(monolithic prompts) -- 단 한 번의 API 호출로 한 번에 여러 작업을 수행하는 방식 -- 를 사용한다면, 라우팅을 위해서는 먼저 파이프라인을 분해(decomposing)해야 합니다. 모놀리식 호출을 개별 작업으로 나누고, 각 모델 계층에서 각 작업을 독립적으로 테스트하며, 라우팅 계층(routing layer)을 구축하고, 오케스트레이션(orchestration)을 재구축해야 합니다. 소요 기간: 6~10주.

두 경우 모두 제품 자체는 변하지 않습니다. 사용자는 동일한 인터페이스를 보고, 동일한 입력을 제공하며, 동일한 출력을 받습니다. 변하는 것은 내부의 엔지니어링 -- 그리고 월간 API 비용입니다.

실제 프로덕션 시스템에서는 어떤 모습일까요?

우리는 3개월 만에 에이전트(agents) 수를 50개에서 80개 이상으로 확장한 운영 AI 플랫폼을 구축했습니다. 이 시스템은 통화 녹음 내용을 분석하고, 에이전트의 성과를 점수화하며, 코칭 기회를 식별하고, 보고서를 생성합니다.

이 각각은 서로 다른 복잡도 요구사항을 가진 별개의 작업입니다. 전사(Transcription) 전처리는 경량 모델(lightweight model)을 통해 실행됩니다. 미리 정의된 루브릭(rubric)에 따른 점수 산정 -- 구조화된 출력(structured output)을 활용한 패턴 매칭(pattern matching) -- 은 사용 가능한 가장 저렴한 계층에서 실행됩니다. 대화의 역동성을 이해해야 하는 미묘한 코칭 기회 식별은 중간 계층 모델(mid-tier model)로 라우팅됩니다. 잘 작성된 문장이 필요한 관리자 수준의 성과 요약 생성은 성능이 뛰어난 모델(capable model)로 라우팅됩니다.

만약 모든 통화가 단 하나의 모델을 거쳤다면, 에이전트당 비용이 너무 높아져서 50명에서 80명 이상의 에이전트로 확장하는 것이 경제적으로 불가능했을 것입니다. 모델 라우팅(Model routing)은 확장이 가능한 시스템과 스스로의 성장 속도를 견디지 못하는 시스템 사이의 차이를 만들어냈습니다.

그것이 바로 제대로 설계된 AI 시스템의 모습입니다. 하나의 모델이 모든 것을 수행하는 것이 아닙니다. 여러 개의 모델이 각자 가장 잘하는 작업을 처리하며, 첫 번째 코드 라인을 작성하기 전부터 설계된 라우팅 계층 (routing layer)에 의해 조율되는 방식입니다.