MCP를 처음 도입하면 누구나 비슷한 유혹을 느낀다. 연결 가능한 도구를 많이 붙이면 에이전트가 더 똑똑해질 것 같다는 생각이다. 하지만 최근 커뮤니티와 제품 흐름은 반대 메시지를 준다. 도구 스프롤이 커질수록 에이전트는 더 많은 선택지를 매번 검토해야 하고, 실제 작업과 무관한 컨텍스트까지 읽느라 품질과 속도가 함께 흔들린다.
이번 주 실행형 AI 자동화 논의에서 MCP 도구 스프롤이 중요한 이유도 여기에 있다. 워크플로를 실제로 운영하려면 에이전트가 할 수 있는 일을 늘리는 것보다, 지금 이 단계에서 무엇만 보이게 할지를 정하는 편이 더 중요하다. 연결 자체는 기술 문제지만, 노출은 운영 문제다.
도구가 많을수록 왜 느려지는가
문제는 단순히 토큰 비용만이 아니다. 도구 수가 늘어나면 에이전트는 어떤 도구가 적절한지 판단하는 데 더 많은 문맥을 써야 한다. 이 과정에서 두 가지 부작용이 생긴다. 첫째는 지연이다. 둘째는 품질 흔들림이다. 같은 요청을 받아도 어떤 실행에서는 검색 도구를 쓰고, 어떤 실행에서는 불필요한 문서 도구를 먼저 보는 식으로 경로가 흔들리기 쉽다.
실무에서는 이 현상이 특히 멀티 에이전트 환경에서 커진다. 리서치 에이전트, 초안 작성 에이전트, 발행 에이전트가 모두 같은 도구 목록을 보고 있다면 각자 불필요한 선택지를 매번 훑게 된다. 결과적으로 병렬화로 얻어야 할 속도 이점이 도구 탐색 비용에 먹힌다.
MCP는 연결 목록이 아니라 노출 정책이다
MCP를 잘 운영하는 팀은 보통 연결과 노출을 분리해서 생각한다. 연결은 “붙일 수 있는가”의 문제다. 노출은 “지금 이 작업에서 보여 줄 것인가”의 문제다. 대부분의 실패는 연결이 아니라 노출을 넓게 잡아서 생긴다.
예를 들어 리서치 단계에는 검색, 문서 조회, 노트 읽기 정도면 충분할 수 있다. 반면 실행 단계에는 워크플로 수정 도구나 제한된 저장소 접근이 필요할 수 있다. 발행 단계에서는 승인형 쓰기 도구만 잠깐 열면 된다. 모든 단계를 한 도구 세트로 처리하려는 순간 에이전트는 똑똑해지기보다 산만해진다.
최소 노출 전략은 어떻게 짤까
가장 실용적인 방식은 작업 단위로 도구를 나누는 것이다.
첫째는 읽기 전용 도구 묶음이다. 검색, 문서 조회, 로그 확인처럼 시스템 상태를 파악하는 데 필요한 도구만 넣는다. 이 묶음은 가장 넓게 써도 상대적으로 안전하다.
둘째는 생성 도구 묶음이다. 워크플로 초안 작성, 문서 초안 생성, 제한된 수정처럼 결과를 만들지만 외부 반영까지는 하지 않는 도구를 둔다. 이 단계에서는 실행 자유도를 주되, 결과가 외부에 바로 반영되지는 않게 경계를 만든다.
셋째는 승인형 쓰기 도구 묶음이다. 배포, 발행, 데이터 수정처럼 실패 비용이 큰 작업만 모은다. 이 묶음은 항상 늦게 열고, 사람이 봐야 하는 근거와 함께 제시하는 편이 좋다.
핵심은 도구를 줄이는 데 있지 않다. 같은 도구라도 어떤 순간에 누구에게 보일지 제어하는 데 있다.
컨텍스트 압축은 숨김이 아니라 선택의 문제다
도구 스프롤을 줄인다고 하면 종종 “필요한 기능을 빼는 것 아닌가”라는 우려가 나온다. 하지만 좋은 압축은 기능 삭제가 아니라 선택 비용 감소다. 에이전트가 지금 당장 쓸 가능성이 낮은 도구를 숨기면, 필요한 도구를 더 빨리 고를 수 있다.
이 원칙은 사람의 업무 도구 구성과도 비슷하다. 모든 앱을 한 화면에 펼쳐 놓는 것보다, 작업별로 필요한 앱만 여는 편이 더 빠르다. AI 에이전트도 다르지 않다. 항상 모든 도구를 쥐여 주는 것보다, 작업 단계에 따라 도구를 늘리고 줄이는 편이 품질이 더 안정적이다.
운영 지표는 무엇을 봐야 하나
도구 스프롤을 줄였을 때 효과를 확인하려면 단순한 호출 횟수보다 운영 지표를 봐야 한다.
- 한 작업에서 실제로 사용된 도구 종류 수
- 불필요한 도구 선택 후 되돌아간 횟수
- 승인 전 단계에서 발생한 재시도 수
- 병렬 실행 시 에이전트 간 경로 편차
- 사람이 개입해 도구 선택을 바로잡은 횟수
이 지표를 보면 도구가 많은 것이 강점인지, 아니면 산만함의 원인인지 더 명확해진다.
한국어 실무팀용 적용 순서
- 현재 워크플로를 읽기, 생성, 승인형 쓰기 단계로 나눈다.
- 각 단계에서 정말 필요한 도구만 3개 안팎으로 적어 본다.
- 공통 도구를 기본 노출하지 말고 단계 진입 시에만 연다.
- 에이전트가 잘못 고른 도구 사례를 기록해 다음 노출 정책에 반영한다.
- 도구 확장은 기본값이 아니라 예외 승인처럼 다룬다.
실행형 AI 자동화의 품질은 연결한 도구 수가 아니라, 도구를 얼마나 절제해서 보여 주는가에 더 크게 좌우된다. MCP 시대에는 연결 능력보다 노출 설계가 경쟁력이다. 필요한 순간에 필요한 도구만 열 수 있어야 에이전트는 더 빠르고 덜 산만하게 움직인다.
전체 실행 구조와 승인·훅 설계는 실행형 AI 자동화 워크플로 가이드: 프롬프트에서 실제 실행까지 연결하는 법에서 함께 볼 수 있다.