MCP 툴 23개를 붙이자 무너진 툴 선택 정확도, 라우팅으로 되돌린 기록

툴 8개일 땐 안 보이던 문제

내부 운영 자동화 에이전트를 하나 굴리고 있었다. 처음엔 Notion 읽기/쓰기, Slack 메시지, 캘린더 조회로 툴이 8개였고 선택은 거의 안 틀렸다. 그러다 MCP 서버를 계속 붙였다. Airtable, 내부 티켓 API, 파일 검색, 사내 위키까지. 어느새 노출 툴이 23개가 됐다.

증상은 조용히 왔다. Slack에 보낼 걸 Notion 코멘트로 남기거나, notion-search를 쓸 자리에 airtable_search를 골랐다. 파라미터도 헷갈렸다. channel_id 자리에 채널 이름 문자열을 넣는 식이었다. 크래시가 아니라 가끔 엉뚱한 데 남기는 형태라 한동안 모델 실수인가 했다.

실측: 8개 94% → 23개 71%

감으로 판단하기 싫어서 평가셋을 만들었다. 실제 요청 로그에서 100개를 뽑아 정답 툴과 정답 파라미터를 라벨링하고, 노출 툴 개수를 바꿔가며 선택 정확도를 쟀다.

• 8개 노출: 94% (94/100)
• 15개 노출: 84% (84/100)
• 23개 노출: 71% (71/100)

정확도만 문제가 아니었다. 툴 스키마가 매 호출에 다 주입되는데 23개면 대략 11K 토큰이었다. 실제 대화 맥락이 밀려나 멀티스텝 작업에서 앞 단계를 잊는 빈도도 같이 올랐다.

원인은 셋이었다. 첫째, search 계열이 셋(notion·airtable·wiki)인데 description이 다 "검색한다"로 시작했다. 구분 신호가 없었다. 둘째, MCP 기본 description이 장황했다. 한 툴에 5~6줄씩 예시까지 붙었다. 셋째, 파라미터 네이밍이 제각각이었다. 어떤 건 query, 어떤 건 q, 어떤 건 channel, 어떤 건 channel_id. 비슷한데 미묘하게 달라 교차 오염이 났다.

대응: description 다이어트 + 라우팅 + 상한

한 방에 고치지 않고 순서대로 했다. 먼저 description을 잘랐다. 한 줄 요약에 언제 쓰고 언제 안 쓰는지만 남겼다.

# before
notion-search: Search across all Notion pages and databases in
the workspace. Supports full-text... (6줄)

# after
notion-search: 노션 문서/DB 검색. 사내 문서·회의록 찾을 때.
채팅 메시지 검색은 slack_search.

이것만으로 71%가 82%가 됐다. search끼리 서로를 가리키게 하니 오선택이 줄었다.

다음이 라우팅이었다. 23개를 한 컨텍스트에 다 노출하지 않고, 상위 라우터가 먼저 카테고리(메시징/문서/일정/티켓)를 고르고 그 카테고리의 툴 3~5개만 실행 단계에 노출했다. 한 번에 보이는 툴을 늘 10개 이하로 유지한 게 핵심이었다. 여기서 90%로 회복했다.

트레이드오프는 분명하다. 라우팅은 LLM 호출이 한 번에서 두 번(라우터 + 실행)으로 는다. 지연이 요청당 0.6초쯤 붙고 토큰 비용도 올랐다. 라우팅이 실제로 산 건 82%에서 90%로, 8%p다. 티켓 오배정 한 건 수습이 그보다 비싸서 감수했다.

when-NOT: 툴 적으면 하지 마라

이 고민 전체가 툴이 많을 때만 성립한다. 노출 툴이 5~7개 이하면 라우팅은 순손해다. 정확도는 어차피 90% 후반이라 개선 여지가 없는데 호출만 두 번으로 늘어 지연·비용·디버깅 난도가 오른다. 실제로 8개짜리에 라우터를 얹어봤다가 정확도는 그대로고 지연만 붙어 걷어냈다.

경계선은 대략 10~12개였다. 그 밑이면 description만 정리해도 충분했고, 위로 넘어가는 순간부터 노출 자체를 줄이는 구조가 필요했다. 툴을 붙이기 전에 기존 툴과 description 첫 문장이 겹치는지만 봐도 절반은 예방된다.