여러 모델을 섞는 목적은 모든 요청을 싼 모델에 보내는 것이 아니다. 반복 작업은 낮은 지연과 비용으로 처리하고, 실패 비용이 큰 판단은 더 높은 역량의 모델이나 사람에게 넘기는 데 있다. 여기서 작은 모델과 큰 모델은 물리적 크기보다 팀이 확인한 속도·비용·업무 성공률의 역할명에 가깝다.
좋은 라우팅은 “어려우면 강한 모델을 부른다”로 끝나지 않는다. 실행 소유자, 승격 조건, 전달 정보와 최종 검증을 정해야 한다. Claude Code 서브에이전트의 모델 우선순위는 CLAUDE_CODE_SUBAGENT_MODEL 환경 변수, 호출별 값, frontmatter, 주 대화 모델 순이다. 생략하면 주 모델을 상속하고, tools도 생략하면 허용된 전체 도구를 물려받는다. 작업자는 모델과 도구 allow-list를 명시한다. 세부 범위는 서브에이전트 공식 문서에서 확인한다.
1. 한 모델 기준선을 먼저 만든다
라우터부터 만들면 어느 단계가 품질과 비용을 바꿨는지 알기 어렵다. 먼저 대표 업무를 한 모델로 끝까지 실행해 성공률, 전체 소요 시간, 입력·출력 토큰, 도구 호출, 재시도, 사람 수정 시간을 기록한다. 문구 변경, 범위가 닫힌 버그, 다중 파일 변경, 권한 관련 작업처럼 난도를 섞는다.
평가 사례에는 입력뿐 아니라 수정 가능 경로, 금지된 변경, 회귀 테스트, 사람 확인 항목을 붙인다. 기준선과 라우팅 시범은 같은 평가 세트·커밋·도구 범위·채점 방식으로 반복하고, 가능한 항목은 자동 채점한다. 구체적이고 측정 가능한 기준과 실제 작업 분포를 반영하는 방법은 Anthropic 평가 설계 안내에서 확인할 수 있다.
2. 승격 규칙을 하드 조건과 소프트 조건으로 나눈다
보안·권한·결제·데이터 삭제, 운영 환경 쓰기처럼 놓치면 손실이 큰 작업은 처음부터 상위 모델과 사람 검토로 보낸다. 이런 하드 조건을 작은 모델의 자기 판단에만 맡기지 말고 코드나 작업 분류 규칙으로 먼저 검사한다.
소프트 조건은 실제 실패 기록에서 만든다. 예상 밖 파일이 필요해짐, 서로 다른 설계안이 남음, 같은 테스트가 반복 실패함, 근거를 찾지 못함처럼 진행 중 관찰할 수 있는 신호를 쓴다. 파일 수나 실패 횟수의 임계값은 임의로 정하지 않고 기준선 결과에서 조정한다. 승격하지 않아 생긴 재작업과 불필요한 승격을 함께 세야 규칙이 한쪽으로 치우치지 않는다.
3. 모델이 아니라 결정에 필요한 묶음을 넘긴다
상위 모델에 저장소 전체나 긴 대화를 그대로 보내면 탐색 비용이 다시 든다. 승격 패킷을 다음 형식으로 고정한다.
- 요청과 성공 기준
- 확인한 사실과 근거 파일
- 이미 시도한 행동과 실패 결과
- 남은 선택지와 결정할 질문
- 허용 도구·수정 경로·중단 조건
실행권도 명시한다. 조언만 받으면 상위 모델은 판단 기준을 반환하고 기존 실행자가 변경한다. 제어권을 넘기면 다음 모델이 받은 컨텍스트와 도구를 기록한다. 모델 ID는 Anthropic API의 전체 모델명, Bedrock의 inference profile ARN, Google Cloud Agent Platform의 version name, Foundry의 deployment name처럼 다르다. 별칭이 아니라 실제로 해석된 ID와 공급자를 저장한다. 기준은 모델 설정 공식 문서에서 확인한다.
4. 마지막 문턱은 모델 밖에 둔다
상위 모델의 답도 자동 정답이 아니다. 테스트, 정적 검사, 허용 경로 확인, 중요한 변경의 사람 리뷰를 마지막 관문으로 둔다. 실행자와 조언자가 같은 가정을 반복할 수 있으므로 “강한 모델이 봤다”를 검증 결과로 기록하지 않는다.
시범 운영에서는 기준선과 같은 품질·보안 관문을 통과한 경우에만 전체 완료 비용을 비교한다. 토큰 비용뿐 아니라 승격, 재시도, 사람 수정 시간, 놓친 승격을 합친다. Anthropic API 가격은 공식 가격 문서에서 확인하고, 다른 공급자는 해당 요금표를 쓴다.
라우팅 규칙은 한 번 정한 서열표가 아니다. 실제로 실패를 줄인 승격 조건은 남기고, 결과를 바꾸지 못한 호출은 줄인다. 작은 모델과 큰 모델의 협업은 모델 이름을 섞는 일이 아니라, 값비싼 판단이 필요한 순간을 증거로 찾아내는 운영 구조다.