MCP 서버를 붙이기 쉬워질수록 팀은 자주 같은 실수를 한다. 연결 가능한 도구를 가능한 한 많이 열어 두면 에이전트가 더 똑똑해질 것이라고 기대하는 것이다. 하지만 실무에서는 반대 상황이 더 자주 생긴다. 선택지가 많아질수록 에이전트의 탐색 길이가 늘고, 잘못된 도구를 집는 빈도도 높아진다. 결국 비용은 오르고 산출물은 불안정해진다.
이 문제를 여기서는 도구 과밀이라고 부를 수 있다. 문제의 핵심은 MCP 자체가 아니라 노출 정책 부재다. 연결과 노출을 같은 일로 취급하면 운영은 금방 무거워진다.
왜 도구 과밀이 생기는가
에이전트 운영 초기에 팀은 대체로 연결 가능한 표면을 한 번에 넓힌다. 문서, 데이터베이스, 자동화 툴, 파일 시스템, 메신저, 분석 도구를 모두 붙이면 범용성이 커질 것처럼 보인다. 하지만 실제 요청은 그렇게 넓은 표면을 매번 필요로 하지 않는다.
예를 들어 블로그 초안 생성 작업은 키워드 기록, 과거 초안, 발행 규칙 정도면 충분할 수 있다. 그런데 여기에 배포 도구, 메신저 발신, 코드 저장소 수정 도구까지 동시에 노출하면 에이전트는 쓸모없는 선택지를 매번 고려하게 된다. 이것이 응답 지연과 토큰 증가로 이어진다.
연결은 넓게, 노출은 좁게
운영 원칙은 단순하다. 시스템 수준 연결은 넓게 유지하되, 실제 작업마다 보이는 도구는 좁게 제한한다. 이 원칙을 적용하면 두 가지 이점이 생긴다. 첫째, 에이전트의 선택 비용이 줄어든다. 둘째, 잘못된 쓰기 액션이 나갈 가능성도 함께 줄어든다.
실무에서는 보통 아래와 같이 나누면 충분하다.
- 읽기 전용 도구 세트: 문서 조회, 과거 기록 검색, 참고 자료 수집
- 생성 도구 세트: 초안 작성, 워크플로우 조립, 파일 초안 생성
- 고위험 도구 세트: 발행, 배포, 외부 발신, 권한 변경
읽기 전용과 생성 도구는 비교적 넓게 열어도 되지만, 고위험 도구는 승인 단계 직전까지 숨겨 두는 편이 낫다.
어떤 기준으로 필터링할까
도구 필터링은 감각이 아니라 질문으로 설계하는 편이 좋다.
첫째, 지금 요청이 정말 이 도구를 필요로 하는가. 둘째, 이 도구는 읽기인가 쓰기인가. 셋째, 이 도구의 결과가 최종 액션인가 중간 신호인가. 넷째, 잘못 호출됐을 때 복구 비용이 큰가.
이 네 가지 질문만 적용해도 많은 도구가 기본 세트에서 빠진다. 중요한 것은 도구를 영구적으로 제거하는 것이 아니라 작업 문맥에 따라 다시 보이게 하는 것이다. 즉 필터링은 축소가 아니라 동적 노출 제어에 가깝다.
토큰 비용과 품질을 같이 줄이는 법
도구 과밀을 줄이면 토큰 사용량만 줄어드는 것이 아니다. 품질도 함께 안정된다. 선택지가 적을수록 에이전트는 필요한 행위를 더 빠르게 찾고, 중간에 엉뚱한 호출을 시도할 가능성도 낮아진다. 특히 장시간 실행형 자동화에서는 한 번의 잘못된 호출이 뒤 단계를 모두 꼬이게 만들 수 있다.
그래서 운영자는 토큰 예산을 줄이는 것보다 불필요한 탐색 경로를 줄이는 관점으로 접근하는 편이 좋다. 같은 요청에서 반복적으로 설명이 길어지고 실패가 많다면, 모델을 바꾸기 전에 도구 세트를 먼저 줄여 보는 것이 맞다.
작은 팀용 적용 순서
- 반복 요청 3개를 골라 각 요청에 꼭 필요한 도구만 적는다.
- 읽기 전용과 쓰기 도구를 분리한다.
- 배포나 발신처럼 복구 비용이 큰 도구는 숨겨 둔다.
- 실패 로그에서 잘못 선택된 도구가 있었는지 확인한다.
- 월 1회 정도 도구 세트를 다시 정리한다.
MCP 시대의 경쟁력은 더 많은 도구를 붙이는 데 있지 않다. 필요한 순간에 필요한 도구만 보이게 만드는 데 있다. 이 원칙이 있어야 에이전트는 더 빠르고 싸고 예측 가능하게 움직인다.
메인 구조는 AI 에이전트 운영 설계 가이드: 도구 연결보다 먼저 정할 5가지에서 이어서 볼 수 있다. 그 글은 도구 노출 문제를 실행 위치, 승인 지점, 비용 관리와 함께 상위 운영 설계 관점에서 설명한다.