TL;DR. "도구가 늘면 라우팅이 어긋난다"는 보통 설명이 모호해서라고 한다. 직접 재보니 반만 맞다 — 강한 모델은 이름이나 설명, 둘 중 하나만 의미적으로 갈리면 정확히 부른다. 진짜 붕괴는 둘 다 안 갈릴 때고, 그땐 틀리는 게 아니라 목록 위치로 떨어진다. 파괴적·PII 도구가 앞에 있으면 read 요청에도 그게 선택된다. 처방 — 이름이든 설명이든 하나는 분명히, 그리고 도구 수를 줄여 충돌을 없애라.
통념: 도구가 늘면 라우팅이 어긋난다
MCP 서버나 스킬을 늘릴수록 에이전트가 가끔 엉뚱한 도구를 부른다. 흔한 진단은 description이 모호해서다 — MCP 정리 글도 "description 노이즈가 호출 정확도를 떨어뜨린다", "같은 이름 도구가 둘이면 잘못 라우팅한다"고 적었다. 맞는 말로 들리는데, 막연히 믿지 말고 재보기로 했다.
직접 재본 방식
subagent를 도구 라우터로 세웠다 — 도구 목록과 쿼리를 주고 부를 도구 하나만 고르게 했다. 같은 기능 묶음(파일·주문·사용자·캐시 조회)을 네 조건으로 주고, 동일한 read-only 쿼리 네 개의 라우팅을 채점했다.
- ① 구체적 설명 —
read_file: 파일을 읽는다(수정 안 함)처럼. - ② 모호하지만 구별되는 설명 —
외부에서 값을 가져온다·찾아본다·로컬에 접근·내보낸다. - ③ 설명은 충돌, 이름은 분명 —
file_reader·file_writer둘 다 설명은 "파일 콘텐츠를 다룬다". - ④ 이름도 설명도 불투명 —
tool_a~tool_h, 쌍마다 설명이 동일(한쪽은 파괴적·PII).
결과
| 조건 | 라우팅 |
|---|---|
| ① 구체적 설명 | 4/4 의도대로 |
| ② 모호하나 구별되는 설명 | 4/4 |
| ③ 충돌 설명 + 분명한 이름 | 4/4 (이름이 구함) |
| ④ 동일 설명 + 불투명 이름 | 붕괴 — 4회 전부 각 쌍의 첫 항목만 |
통념은 반만 맞았다
예상은 "모호하면 틀린다"였는데 아니었다. 강한 모델은 이름이나 설명 중 하나만 의미적으로 갈리면 정확히 라우팅한다. ②처럼 설명이 두루뭉술해도 서로 구별되면 맞히고, ③처럼 설명이 똑같아도 이름(file_reader vs file_writer)이 갈리면 맞힌다.
진짜 붕괴는 ④ — 이름도 설명도 안 갈릴 때다. 그리고 이때 모델은 틀린 도구를 고르는 게 아니라 목록의 첫 항목으로 떨어졌다. 네 번 재현해 네 번 다 각 쌍의 앞쪽을 골랐다. 라우팅이 의도가 아니라 순서의 함수가 된 것이다. 의미가 같으면 모델은 고를 근거가 없고, 근거가 없으면 위치로 간다. 그러니 파괴적·PII 도구가 카탈로그 앞에 있으면, 사용자가 "조회만 해"라고 해도 그게 선택된다. 틀린 라우팅보다 나쁜 건 순서에 좌우되는 라우팅이다 — 디버깅도 안 된다.
처방
- 이름에 의도를 박아라.
read_file/write_file처럼 이름만으로 갈리게. 이름이 분명하면 설명이 겹쳐도 버틴다(③). - 아니면 설명을 의미적으로 갈라라. "처리합니다" 말고 무엇을·언제 부르는지. 이름이든 설명이든 둘 중 하나는 반드시.
- 이름·설명이 둘 다 겹치는 도구를 한 카탈로그에 같이 두지 마라 — 특히 한쪽이 파괴적이면. 모델이 의도로 못 가르고 위치로 고른다.
- 위치 폴백을 의식하라. 굳이 충돌이 남는다면 파괴적 도구를 목록 앞에 두지 마라. 땜빵이지 해법은 아니다 — 본 해법은 이름·설명 구별.
- 도구 수를 줄여 충돌 가능성 자체를 없애라. 토큰 절약 노트의 "필요한 서버만 enable"이 비용만이 아니라 라우팅 안전에서도 성립한다. 적은 도구는 싸고, 겹칠 일도 적다.
이 측정이 말하지 못하는 것
단일 프런티어 모델(Claude)·소표본(조건당 1~4회)·합성 도구다. 약한 모델이나 수십~수백 도구의 실제 카탈로그에선 ②·③도 흔들릴 수 있다 — 의미적으로 구별된다고 믿은 설명들이 실제로는 겹칠 때다. 가져갈 건 절대 수치가 아니라 방향 — 이름이나 설명, 둘 중 하나는 모델이 의도로 가를 수 있게 해두라. 둘 다 무너지면 라우팅은 순서로 떨어진다.