멀티에이전트를 켜두면 비용이 무섭게 오른다. 역할 3개 × 각각 여러 번 모델 호출. 그런데 생각해보면 이상하다. "1+1은?" 같은 쉬운 질문에도 토론 5인조를 붙이면 낭비 아닌가? 반대로 어려운 질문에 혼자 붙이면 틀린다.
ACL 2025 논문 MasRouter는 이 문제를 정면으로 정의한다. 질문마다 팀을 어떻게 꾸릴지를 자동으로 정하는 라우터다. 단순히 "이 질문에 어떤 모델?"이 아니라 "협업 방식 + 역할 구성 + 각 역할의 모델"을 통째로 고른다.
원문: arXiv:2502.11133 (ACL 2025) · 코드: yanweiyue/masrouter
기존 라우터가 못 보던 것
예전 LLM 라우터는 단일 에이전트 세계의 질문만 풀었다. "이 쿼리는 GPT? Claude? 아니면 작은 모델?" 비용은 아꼈지만, 멀티에이전트에서 진짜 중요한 결정을 놓쳤다.
- 혼자 풀까, 토론이 필요할까? (협업 모드)
- 역할을 몇 개, 어떤 걸 둘까? (역할 배분)
- 각 역할에 어떤 모델을 붙일까? (모델 할당)
MasRouter는 이 셋을 하나로 묶어 MASR(Multi-Agent System Routing)라는 새 문제로 정의했다. 팀 구성 전체를 라우팅 대상으로 본 최초의 시도다.
비유: 콜센터 티켓 배정
전화가 오면 유형을 보고 배정한다. 단순 문의는 상담원 1명, 기술+결제 복합은 두 명 협업, 고난도는 시니어 투입. MasRouter도 질문이 들어오면 순서대로 고른다.
- 협업 모드 결정자: 변분 잠재변수 모델로, 이 질문에 맞는 협업 방식을 라우팅
- 역할 배분자: 구조적 확률 캐스케이드로 역할을 하나씩 생성
- 모델 라우터: 각 역할에 태스크 적합 모델 할당
실행 후 성과와 비용을 보고 이 컨트롤러들을 함께 학습한다. 목표식은 성능(Utility) − λ×비용(Cost). λ를 키우면 "충분히 맞으면서 더 싼 팀"을 선호하게 된다.
숫자: 성능 올리고 비용 내림
| 측정 | 결과 |
| MBPP pass@1 | AgentPrune 대비 +8.20%, AFlow 대비 +1.80% |
| HumanEval 오버헤드 | SOTA 대비 최대 -52.07% |
| 5개 벤치 평균 | SOTA 라우터 RouterDC 대비 +3.51% |
| 기존 MAS에 플러그인 | 오버헤드 -17.21 ~ -28.17% |
즉 성능은 올리면서 비용은 절반 가까이 줄인 구간이 있었다. 20개 베이스라인, 5개 벤치에서 검증했다.
워크드 예시: 에이전트를 몇 명 붙일까
"많을수록 좋다"는 흔한 오해다. 논문은 최대 에이전트 수 γ를 바꿔봤다.
- γ를 6까지 올릴 때는 성능이 붙는다.
- 6 → 10으로 더 올리면 성능 이득은 미미한데 쿼리당 비용은 약 1.5배.
그래서 논문은 γ=6을 균형점으로 택한다. 또 비용 가중치 λ를 5→25로 올리면 오버헤드가 17.78% 줄고 성능은 1.3%만 떨어졌다. 질문별 적정 팀 크기가 존재하고, 그걸 넘으면 돈만 태운다는 데이터다.
시리즈 4편을 한 줄로 잇기
| 논문 | 푸는 질문 |
| MoA | 여러 답을 어떻게 층층이 합칠까 |
| AOrchestra | 서브 실행자를 어떻게 즉석 만들까 |
| Think Big, Search Small | 메인/서브에 용량을 어디에 몰까 |
| MasRouter | 그 모든 결정을 사람 대신 라우터가 학습으로 |
앞 세 논문이 "좋은 구조는 무엇인가"를 다뤘다면, MasRouter는 "그 구조 선택을 자동화하자"로 넘어간다. opencodex에서 모델 토글·서브 우선순위를 손으로 맞추는 단계가 있다면, MasRouter는 그 다음 단계의 연구 버전이다. 규칙 기반 → 학습 기반 라우팅.
내일 당장 쓸 인사이트 (학습 없이도)
- 질문을 3단으로 분류하라: 단독 / 2역할 / 3역할 이상.
- 단독 질문에 멀티에이전트 금지. 이게 가장 큰 절감 포인트다.
- 역할마다 모델 표를 고정하라. 예: 계획=비쌈, 검색=중간, 포맷팅=쌈.
- 팀 크기 상한을 둬라. "많을수록 좋다"는 6명 근처에서 깨진다.
- 주간 로그로 "과한 팀" 비율을 재라. 30% 넘으면 라우팅 규칙을 조여라.
학습형 MasRouter를 당장 못 써도, 이 MASR 체크리스트만 적용해도 비용이 내려간다.
한계
- 모델 풀의 각 모델이 대체로 정상이라는 가정. 한 모델이 오염(공격/저품질)되면 팀 전체가 오도될 수 있다고 논문도 인정한다.
- 라우터를 학습시킬 데이터가 필요하다. 소규모 팀엔 규칙 라우팅이 더 현실적일 수 있다.
- 벤치가 코딩(MBPP/HumanEval) 위주라, 다른 도메인 일반화는 별도 검증이 필요하다.
참고: arXiv:2502.11133 · ACL 2025 · GitHub
댓글