도구가 많아질수록 문제는 “무엇을 만들 것인가”보다 “무엇을 먼저 붙일 것인가”로 바뀝니다. Tool Selection Strategy는 에이전트의 비용, 속도, 안정성을 결정하는 우선순위 설계입니다.
왜 중요한가 #
실무에서 모든 작업을 하나의 거대한 에이전트가 처리하게 두면 복잡도가 급격히 올라갑니다. 조회는 검색 도구가 더 낫고, 문서화는 파일 도구가 더 낫고, 브라우저 작업은 별도 자동화가 더 낫고, 표준화된 외부 연동은 MCP가 더 낫습니다.
이런 선택은 OpenAI Remote MCP, FastMCP, Anthropic Tool Use처럼 이미 정리된 도구 계층을 보면 더 명확해집니다.
설계 원칙 #
도구 선택은 성능이 아니라 역할 분리에 가깝습니다.
- 검색은 검색 전용 도구를 둡니다.
- 변경 작업은 승인 가능한 경로로 둡니다.
- 브라우저 자동화는 별도 실패 전략을 둡니다.
- 표준 연동은 MCP나 API 레이어를 우선합니다.
- LLM이 직접 판단하기 어려운 작업은 룰 기반으로 좁힙니다.
실패 패턴 #
도구 선택을 잘못하면 시스템은 겉보기에는 작동하지만 운영 비용이 커집니다.
- 검색과 생성이 한 도구에 섞이면 결과가 불안정해집니다.
- 브라우저 작업을 일반 tool call로만 처리하면 실패 복구가 어렵습니다.
- MCP와 직접 API를 중복으로 붙이면 경로가 늘어납니다.
- 무료/저비용 도구만 고집하면 품질이 떨어질 수 있습니다.
빠른 시작 #
초기 설계에서는 아래 질문만 답해도 방향이 잡힙니다.
- 이 작업은 읽기인가 쓰기인가.
- 실패해도 되는가, 아니면 즉시 막아야 하는가.
- 구조화된 입력이 필요한가.
- 외부 시스템과의 표준 연결이 필요한가.
- 사람 검토가 필요한가.
이 질문에 따라 Responses API, Tool Calling, MCP, Browser Use, File Search의 우선순위가 달라집니다.
결론 #
좋은 Tool Selection Strategy는 “모델이 똑똑한가”보다 “도구 경로를 얼마나 단순하게 유지하는가”에 가깝습니다. 도구를 늘리는 것보다 선택 기준을 줄이는 편이 운영에는 더 유리합니다.
