AI 에이전트는 도구가 5개일 때는 잘 동작해도 40개가 되면 잘못된 도구를 호출하거나, 다른 도구의 파라미터를 섞거나, 필요 없는 호출을 반복하기 쉽다. 해결책은 더 큰 모델이 아니라 모델이 매 턴 보는 도구 목록을 설계하는 것이다.
왜 도구 선택이 깨지는가
도구 정의는 이름, 설명, 파라미터 스키마를 포함해 모델 컨텍스트에 들어간다. 도구가 많아지면 실제 작업과 무관한 설명이 컨텍스트를 차지하고, 유사한 이름과 스키마가 attention을 분산시킨다. 그 결과 다음 실패가 늘어난다.
- 존재하지 않는 도구 이름을 생성
- 올바른 도구를 골라도 다른 도구의 인자를 섞음
- 단순 대화 턴에도 불필요한 tool selection pipeline을 실행
- multi-step 작업에서 현재 단계와 무관한 도구까지 노출
1. Gating: 도구가 필요한 턴인지 먼저 판정
“고마워”, “무슨 뜻이야?” 같은 턴은 도구가 필요 없다. cheap classifier나 규칙 기반 gate로 tool pipeline 자체를 건너뛰면 지연 시간과 비용을 줄일 수 있다.
좋은 gate는 보수적으로 동작해야 한다. 도구가 필요할 가능성이 있으면 통과시키고, 명확한 대화형 턴만 차단한다.
2. Retrieval: 전체 카탈로그 대신 top-k 도구만 노출
도구 설명을 임베딩해 벡터 인덱스에 넣고, 사용자 요청과 가까운 도구 top-k만 모델에 제공한다. RAG-MCP 논문은 retrieval 기반 tool selection이 전체 카탈로그 노출 대비 tool selection accuracy를 13.62%에서 43.13%로 높이고 prompt token을 절반 이상 줄였다고 보고했다.
이 방식은 특히 MCP 서버처럼 도구 수가 빠르게 늘어나는 환경에 적합하다.
3. Routing: 도메인별 후보군으로 먼저 좁히기
도구가 제품 도메인별로 뚜렷하게 나뉘면 retrieval 전에 router를 둘 수 있다. 예를 들어 calendar, Slack, GitHub, database, file system처럼 상위 도메인을 먼저 고르고, 그 안에서 세부 도구를 선택한다.
도메인 router는 사람이 관리하기 쉬운 정책 계층이기도 하다. 특정 사용자나 세션에서 GitHub 도구군 전체를 비활성화하는 식의 권한 제어를 함께 걸 수 있다.
4. Planning: 단계마다 필요한 도구만 보여주기
복합 작업은 한 번에 모든 도구를 고르게 하지 말고 계획을 먼저 세운다. 각 단계는 현재 필요한 도구 subset만 본다.
예를 들어 “이슈를 읽고 수정한 뒤 PR을 만들어라”는 다음처럼 나눌 수 있다.
- GitHub issue 조회 도구만 노출
- 파일 읽기/쓰기와 테스트 도구만 노출
- git diff와 PR 생성 도구만 노출
계획 기반 접근은 도구 선택을 “전체 작업의 단일 결정”이 아니라 “현재 단계의 좁은 결정”으로 바꾼다.
5. Fallback: 애매하면 멈추고 복구
확신이 낮은 도구 호출은 실행하지 않는 편이 낫다. fallback은 다음 정책을 포함해야 한다.
- top-k 후보 점수가 낮으면 사용자에게 clarification 요청
- 도구 호출 validation 실패 시 스키마 오류를 모델에게 구조화해 반환
- 위험한 쓰기 작업은 stage/confirm 패턴으로 분리
- 같은 실패가 반복되면 자동 재시도를 중단
6. Benchmark: 감으로 판단하지 말고 측정
tool selection 변경은 작은 예제에서는 좋아 보여도 실제 트래픽에서 악화될 수 있다. 최소한 (query, expected_tool) 쌍으로 된 내부 벤치마크를 만들고 다음을 비교해야 한다.
| 지표 | 의미 |
|---|---|
| selection accuracy | expected tool이 후보군 또는 최종 호출에 포함되는가 |
| token cost | 요청당 tool definition 토큰 |
| latency | retrieval/router/model 선택에 걸린 시간 |
| unsafe call rate | 쓰기·삭제·외부 전송 도구의 오호출 비율 |
MCP 생태계에서는 MCPToolBench++ 같은 대규모 벤치마크도 참고할 수 있다.
실무 기본값
| 도구 수 | 권장 설계 |
|---|---|
| 1~10개 | 전체 노출 가능. 설명과 스키마 품질을 우선 점검 |
| 10~30개 | gating + retrieval top-k 도입 |
| 30개 이상 | domain routing + retrieval + 단계별 planning |
| 쓰기/외부 전송 포함 | fallback, confirmation, idempotency 필수 |
참고 자료
- The Complete Guide to Tool Selection in AI Agents — MachineLearningMastery.com (2026-07-06)
- RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation — arXiv
- MCPToolBench++: A Large-Scale MCP Tool Use Benchmark — arXiv