AI 코딩 에이전트에 어느 모델을 붙여야 가장 나은지 묻는 글이 계속 올라온다. 어려운 디버깅에는 강한 모델이 필요하지만, 파일 이름을 찾거나 이미 정해진 테스트를 다시 돌리는 일까지 같은 모델에 맡기면 비용과 대기 시간이 아깝다는 고민이다.

여기서 나오는 해법이 모델 라우터다. 모든 작업에 한 모델을 고정하지 않고, 요청마다 알맞은 모델을 골라 보내는 장치다. 다만 값싼 모델을 많이 쓰는 것만으로는 좋은 라우터가 되지 않는다. 무엇을 기준으로 나누고, 잘못 고른 순간을 어떻게 알아챌지가 더 중요하다.

작업의 난도와 위험을 살펴 기본 모델로 보내거나 강한 모델로 올린 뒤 결과를 검증하는 흐름.

모델 라우터는 요청 앞의 분기점이다

모델 라우터는 에이전트와 여러 AI 모델 사이에 놓인다. 요청이나 지금까지의 작업 기록을 살펴본 뒤, 미리 허용한 후보 중 하나를 골라 요청을 전달한다. 응답을 만든 주체는 라우터가 아니라 선택된 모델이다.

Microsoft의 모델 선택 안내는 라우팅 방식을 세 가지로 나눈다. 간단하거나 중요도가 낮은 요청은 비용 중심으로, 복잡하거나 위험한 요청은 품질 중심으로, 나머지는 두 기준을 절충해 보낸다. Amazon Bedrock의 prompt routing 문서도 후보 모델의 예상 응답 품질과 비용을 비교하고, 기준을 넘지 못하면 fallback 모델을 쓰는 구조를 설명한다.

이 방식은 provider fallback과 다르다. fallback은 첫 번째 공급자의 서버가 실패했을 때 같은 모델을 다른 공급자에서 호출하거나 다음 후보로 넘어가는 복구 장치다. 모델 라우팅은 요청의 성격을 보고 처음부터 어떤 모델이 답할지 정하는 선택 장치다. OpenRouter의 라우팅 설명도 모델 선택과 공급자 선택을 별개의 두 층으로 구분한다.

도구 이름만 보고 난도를 정하면 틀린다

경로가 적힌 파일 하나를 찾는 검색은 단순하다. 그러나 큰 저장소에서 읽지 말아야 할 영역까지 가려내려면 설계 판단이 필요하다. 테스트도 이미 아는 명령을 다시 실행하는 일과 불규칙한 실패 원인을 해석하는 일의 난도가 다르다. 검색, 수정, 테스트 같은 행동 이름만 보고 모델을 나누면 이 차이를 놓친다.

라우팅 기준은 행동보다 상황을 봐야 한다.

  • 요청과 완료 조건이 분명한가
  • 바뀔 파일과 영향 범위가 좁은가
  • 실패했을 때 되돌리기 쉬운가
  • 정답을 가려낼 테스트나 확인 방법이 있는가
  • 같은 실패가 반복되거나 작업 범위가 계속 커지는가
  • 인증, 결제, 데이터 이전, 공개 API처럼 실수 비용이 큰 영역인가

앞의 네 항목이 분명하면 빠르고 저렴한 모델부터 시작하기 쉽다. 뒤의 두 항목이 나타나면 더 강한 모델로 올리거나 사람에게 멈춤 신호를 보내는 편이 안전하다. “수정은 싼 모델, 설계는 비싼 모델” 같은 고정표보다 실제 위험과 진행 상태를 보는 규칙이 낫다.

세 단계로 첫 규칙을 만든다

처음부터 복잡한 분류기를 학습할 필요는 없다. 작업을 세 단계로만 나눠 라우팅 기준을 시험한다.

  1. 기본 경로: 대상 파일, 변경 내용, 검증 명령이 이미 정해진 작은 작업을 맡긴다.
  2. 강한 모델 경로: 낯선 코드의 원인 분석, 여러 영역에 걸친 설계, 모호한 요구처럼 판단이 많이 필요한 작업을 맡긴다.
  3. 중단 경로: 같은 실패가 반복되거나 위험한 변경인데 검증 방법이 없으면 모델만 바꾸지 말고 사람의 확인을 기다린다.

자동 라우터도 이 틀을 벗어나지 않는다. Microsoft Foundry의 model router는 비용·균형·품질 모드와 후보 모델 묶음을 따로 설정하게 한다. OpenRouter Auto Router 문서도 선택 가능한 모델을 제한하고, 응답에서 실제로 고른 모델을 확인하는 방법을 제공한다.

직접 운영한다면 요청마다 최소한 다음 기록을 남긴다.

선택한 경로: 강한 모델
이유: 인증 코드 변경, 영향 파일 6개, 실패 테스트 2회
실제 사용 모델: model-b
검증: 인증 회귀 테스트와 변경분 검토

이 기록이 있어야 비용이 줄었는지만 보지 않고, 잘못 낮춘 요청과 불필요하게 올린 요청을 함께 찾는다. OpenRouter의 router metadata 문서는 실제 라우팅 전략과 시도한 모델·공급자·상태를 응답 메타데이터로 확인하는 방식을 보여준다.

모델을 바꾸면 문맥 비용도 달라진다

한 대화 안에서 모델을 자주 바꾸면 눈에 보이지 않는 비용이 생긴다. 공급자마다 prompt cache가 다르고, 모델을 바꾸면 앞선 문맥을 다시 처리하기도 한다. OpenRouter의 prompt caching 문서는 자동 라우터에서도 같은 대화의 모델과 공급자를 고정하는 session stickiness를 설명한다.

후보 모델의 context window도 확인해야 한다. Microsoft의 모델 선택 안내는 라우터의 유효한 문맥 크기가 후보 중 가장 작은 모델에 제약된다고 경고한다. 긴 저장소 문맥을 싼 모델이 받지 못해 매번 요약한다면, 호출 단가는 낮아도 전체 비용과 정보 손실은 커진다.

그래서 한 세션의 모든 턴을 잘게 바꾸기보다 경계를 크게 잡는 방법도 좋다. 예를 들어 탐색과 작은 수정은 기본 모델로 묶고, 실패가 누적된 원인 분석 구간만 강한 모델로 넘긴다. 중요한 작업은 처음부터 한 모델로 고정해 예측 가능성을 택한다.

자동 선택을 믿기 전에 작은 평가판을 만든다

모델 라우터는 모델 선택을 없애지 않는다. 선택 시점을 사람이 미리 정하는 대신, 실행 중 규칙으로 옮길 뿐이다. RouteLLM 원 논문과 공식 저장소는 강한 모델과 약한 모델 사이의 기준값을 실제 요청 자료로 조정하고, 품질과 비용을 함께 평가하는 방법을 제안한다.

도입할 때는 지난 작업 20개 정도를 모아 작게 비교한다.

  • 고정한 강한 모델의 성공률과 비용
  • 라우터가 고른 모델, 선택 이유, 성공 여부
  • 처음 선택이 실패해 강한 모델로 올라간 비율
  • 모델 변경 때문에 다시 보낸 문맥과 늘어난 시간
  • 사람이 결과를 고쳐야 했던 위험한 오분류

성공률이 비슷하다는 평균만 보면 안 된다. 인증이나 데이터 변경 같은 중요한 작업을 한 번 잘못 낮춘 문제는, 단순 작업 열 번을 싸게 처리한 이득보다 크다. 위험한 작업에는 수동 고정 규칙을 두고 평균과 별도로 확인한다.

요청이 단순하면 라우터도 필요 없다

작업량이 적고 한 모델로 충분하다면 라우터는 운영 지점만 늘린다. 어떤 모델이 답했는지 추적하기 어렵거나, 실패를 판별할 테스트가 없거나, 후보마다 도구 호출 방식과 문맥 한계가 크게 달라도 먼저 고정 모델을 안정시키는 편이 낫다.

반대로 단순한 반복 작업과 어려운 판단이 섞여 있고, 요청별 결과를 검증하며, 비용과 지연 시간을 실제로 기록한다면 모델 라우터를 시험할 이유가 생긴다. 시작 기준을 한 문장으로 줄이면 이렇다.

검증 가능한 작은 일은 기본 모델로 시작하고, 모호함·영향 범위·실패가 커지면 강한 모델로 올리며, 위험한데 확인 방법이 없으면 멈춘다.

제품 이름과 가격은 계속 바뀐다. 이 글의 동작과 제한은 2026년 8월 10일 공식 문서와 원 자료를 기준으로 확인했다. 특정 라우터를 바로 붙이기보다, 현재 작업 기록에서 어떤 신호가 실제 실패를 예고하는지 먼저 찾는 편이 안전하다.

확인한 공식·원 자료