MCP를 처음 도입하면 연결 가능한 도구를 최대한 많이 붙이고 싶어진다. 문서, 검색, 데이터베이스, 배포, 저장소, 분석 도구까지 모두 연결해 두면 에이전트가 더 똑똑해질 것처럼 보이기 때문이다. 하지만 실제 운영에서는 반대 상황이 더 자주 벌어진다. 도구가 많아질수록 에이전트는 더 자주 망설이고, 불필요한 경로로 새고, 사람은 왜 그런 선택이 나왔는지 설명하기 어려워진다.
최근 흐름에서 이 주제가 다시 강하게 올라온 이유도 분명하다. Vercel 사례는 내부 데이터 에이전트에서 실제로 도구를 줄여 성능과 일관성을 개선한 방향을 보여 줬고, n8n은 같은 시기 에이전트 액션 제한이 신뢰성을 높이는 핵심이라고 정리했다. 연결 능력이 경쟁력이던 단계에서, 이제는 노출 설계가 경쟁력인 단계로 넘어간 셈이다.
도구가 많으면 왜 품질이 흔들릴까
에이전트는 사람이 아니다. 눈앞에 많은 앱이 보여도 대략 중요한 것만 고르는 식으로 일하지 않는다. 도구가 늘어나면 어떤 도구가 지금 요청에 적합한지 판단하는 비용이 먼저 늘어난다. 이 선택 비용은 토큰 낭비 문제에 그치지 않고, 경로 흔들림과 승인 비용 증가로 이어진다.
예를 들어 같은 “초안 작성” 요청을 받아도 어떤 실행에서는 검색 도구를 먼저 쓰고, 다른 실행에서는 불필요한 저장소 도구를 훑을 수 있다. 도구가 많을수록 이런 편차가 커진다. 멀티 에이전트 환경에서는 더 심각하다. 각 에이전트가 서로 다른 역할을 맡아도 같은 거대한 도구 목록을 보면 병렬화 이점이 줄어든다.
즉 MCP 운영의 문제는 연결 실패보다 선택 과잉에서 더 자주 나온다.
최소 노출 원칙은 기능 삭제가 아니라 역할 분리다
도구 노출 최소화라고 하면 종종 “필요한 기능을 빼는 것 아닌가”라고 오해한다. 하지만 핵심은 기능을 줄이는 것이 아니라, 역할별로 보여 주는 타이밍을 나누는 것이다. 같은 도구라도 어느 단계에서 누구에게 보이느냐에 따라 품질 차이가 크게 난다.
허브형 워크스페이스에서는 보통 세 묶음으로 시작하면 관리가 쉽다.
- 읽기 도구: 검색, 문서 조회, 로그 확인
- 생성 도구: 초안 작성, 워크플로 생성, 제한된 수정
- 승인형 쓰기 도구: 배포, 발행, 권한 변경, 데이터 반영
이렇게 나누면 리서치 에이전트는 읽기 도구만 보고, 자동화 초안 에이전트는 생성 도구까지 보고, 발행 에이전트는 마지막 순간에만 승인형 쓰기 도구를 볼 수 있다. 연결은 중앙에서 유지하되, 노출은 작업 단계에 맞게 줄이는 구조다.
허브형 워크스페이스에서 더 중요한 이유
여러 에이전트를 같은 워크스페이스 허브에 모으는 순간, 중앙 집중이 곧 범용 권한으로 흐르기 쉽다. 문서 허브와 실행 허브가 합쳐지면 편해 보이기 때문에 모든 도구를 공통 세트로 열어 두기 쉽다. 그러나 이 방식은 곧바로 운영 리스크로 이어진다.
첫째, 역할 경계가 흐려진다. 문서 정리 에이전트가 굳이 배포 도구를 볼 이유가 없는데도 선택지에 들어오면, 경로 오판 가능성이 높아진다.
둘째, 승인 기준이 흐려진다. 도구가 너무 많으면 어떤 액션이 실제로 위험한지 사람도 한눈에 파악하기 어렵다.
셋째, 실패 분석이 어려워진다. 도구 선택이 넓을수록 왜 그 도구가 골라졌는지 복기하기 힘들다.
허브형 워크스페이스는 중앙화 구조이지만, 도구 노출 관점에서는 오히려 더 엄격한 분리가 필요하다.
최소 도구 세트를 정하는 실전 질문
도구를 줄인다는 말이 추상적으로 느껴진다면, 아래 질문으로 시작하면 된다.
- 이 단계에서 정말 필요한 읽기 입력은 무엇인가
- 이 단계에서 결과를 만들기 위해 꼭 필요한 수정 권한은 무엇인가
- 이 단계의 실패가 외부 사용자에게 영향을 주는가
- 같은 결과를 더 좁은 도구 세트로 낼 수 있는가
- 사람이 승인할 때 이해하기 쉬운 도구 구성이 맞는가
이 질문에 답하다 보면 “붙일 수 있는 도구”와 “지금 보여 줄 도구”가 자연스럽게 구분된다. 대부분의 경우 실제 운영에 필요한 도구는 생각보다 적다.
도구 노출 최소화가 만드는 운영 효과
도구를 줄이면 단순히 속도만 좋아지는 것이 아니다. 운영상으로는 더 큰 이점이 있다.
- 에이전트 경로가 더 일관돼 테스트가 쉬워진다.
- 승인 요청이 덜 복잡해져 사람이 판단하기 쉬워진다.
- 실패 원인을 도구 선택 문제와 도구 자체 문제로 나눠 보기 쉬워진다.
- 역할별 에이전트 설계가 쉬워져 멀티 에이전트 운영 품질이 올라간다.
결국 좋은 도구 노출 정책은 모델의 실력을 키우는 것이 아니라, 모델이 실력을 안정적으로 드러내게 만드는 운영 장치다.
처음 적용할 때의 추천 순서
- 현재 워크플로를 읽기, 생성, 승인형 쓰기 단계로 나눈다.
- 각 단계에서 필요한 도구를 3~5개 안으로 적어 본다.
- 공통 도구를 기본 노출하지 말고 단계 진입 시에만 연다.
- 에이전트가 잘못 고른 도구 사례를 기록해 다음 노출 정책에 반영한다.
- 도구 추가는 기본값이 아니라 예외 승인처럼 다룬다.
MCP 시대의 경쟁력은 더 많은 연결이 아니라 더 정확한 노출 설계에 있다. 특히 여러 에이전트를 한 허브에서 운영할수록, 도구를 적게 보여 주는 것이 오히려 더 많은 일을 안정적으로 하게 만든다.
허브 구조 전체 맥락은 에이전트 허브형 워크스페이스 설계법: 승인, 도구, 맥락을 한곳에서 운영하는 기준에서 먼저 보는 편이 좋다.