MCP를 처음 접하면 보통 연결 수가 경쟁력처럼 보인다. 검색도 붙이고, 브라우저도 붙이고, 파일 시스템도 붙이고, 배포 도구도 붙이면 에이전트가 더 강해질 것처럼 느껴진다. 하지만 최근 Product Hunt에서 주목받은 Strata와 shutup-mcp, 그리고 Hacker News의 반복 논의가 보여 주는 방향은 다르다. 실제 병목은 연결 부족보다 툴 과다 노출과 컨텍스트 오버헤드다.
도구가 너무 많아지면 에이전트는 더 자유로워지는 대신 더 느려지고 더 흔들린다. 어떤 툴을 선택할지 판단 비용이 커지고, 툴 설명과 큰 JSON 응답이 컨텍스트를 잠식하며, 읽기 작업에도 쓰기 도구가 같이 노출돼 승인 기준이 흐려진다. 그래서 MCP 운영에서는 “얼마나 많이 붙였나”보다 “어떤 작업에 무엇만 보여 주나”가 중요하다.
메인 글인 에이전트 운영 허브는 어디에 둬야 할까: Notion Developer Platform, Codex, n8n 비교에서 허브 분리를 설명했다면, 이 글은 그중에서도 MCP 툴 스프롤 문제를 따로 정리한다.
왜 툴이 많을수록 오히려 어려워질까
에이전트는 사람처럼 “아는 도구가 많으니 상황에 맞게 잘 고른다”는 방식으로 움직이지 않는다. 실제로는 현재 목표, 툴 설명, 과거 문맥, 응답 형식에 크게 영향을 받는다. 도구 수가 늘면 판단 가능한 선택지가 많아지는 동시에, 현재 작업과 상관없는 설명도 함께 본다.
이 상태에서는 세 가지 문제가 생긴다.
- 간단한 읽기 작업도 불필요하게 무거워진다.
- 승인 기준이 불명확해진다.
- 실패 원인을 좁히기 어려워진다.
예를 들어 문서 요약만 시키고 싶은데 파일 쓰기, 외부 발송, 배포 툴까지 다 열려 있다면, 에이전트는 필요 없는 선택지를 매번 고려하게 된다. 이건 단순한 UX 문제가 아니라 운영 비용 문제다.
컨텍스트 오버헤드는 왜 중요한가
MCP 관련 논의에서 자주 나오는 포인트가 도구 설명과 구조화된 응답의 길이다. 도구 하나하나가 길게 설명되고, 응답도 대형 JSON으로 오면, 실제 작업을 위한 맥락 공간이 줄어든다. 한국 실무 환경에서 여러 SaaS와 내부 시스템을 함께 붙이기 시작하면 이 문제는 더 빨리 나타난다.
중요한 것은 모델 창 크기 자체보다 효율이다. 컨텍스트가 넉넉해도, 불필요한 툴 설명과 결과 구조가 계속 들어오면 작업 품질은 흔들린다. 그래서 MCP를 운영할 때는 툴 수를 줄이는 것만큼, 어떤 설명과 출력 형식이 반복적으로 따라오는지도 함께 봐야 한다.
툴 스프롤을 줄이는 가장 쉬운 기준
복잡한 정책 엔진이 없어도 아래 세 묶음으로 나누면 상당수가 해결된다.
- 읽기 도구
- 생성 도구
- 승인형 쓰기 도구
읽기 도구에는 검색, 조회, 로그 확인처럼 상태를 바꾸지 않는 것만 둔다. 생성 도구에는 초안 작성이나 제한적 편집처럼 사람이 다시 검토할 수 있는 작업을 둔다. 승인형 쓰기 도구에는 배포, 발행, 외부 메시지, 데이터 수정처럼 결과가 바로 남는 액션을 둔다.
핵심은 기술 분류가 아니라 작업 단계 분류다. 같은 서비스라도 읽기 기능과 쓰기 기능을 다르게 노출해야 한다.
필터링 프록시가 필요한 이유
Strata나 shutup-mcp 같은 신호가 흥미로운 이유는, 문제를 “더 많은 연결”이 아니라 “더 적절한 노출”로 정의하기 때문이다. 필터링 프록시는 MCP를 막는 장치라기보다, 현재 작업에 맞는 도구 집합만 통과시키는 장치다.
이 접근이 유용한 이유는 다음과 같다.
- 에이전트가 현재 단계와 무관한 도구를 보지 않는다.
- 승인 모델을 도구 노출 단계에서 먼저 단순화할 수 있다.
- 디버깅 시 어떤 툴 세트가 열려 있었는지 추적하기 쉽다.
결국 필터링은 생산성과 보안을 동시에 다루는 운영 기술이다. 보안만을 위한 최소권한과, 생산성만을 위한 컨텍스트 절약이 같은 구조 안에서 만난다.
허브 설계와 같이 봐야 하는 이유
툴 스프롤 문제는 MCP 자체의 문제가 아니라 허브 설계 문제이기도 하다. 워크스페이스 허브, 실행 허브, 결정적 자동화 허브를 나누지 않고 한곳에서 모든 툴을 쓰려 하면, 필연적으로 툴 목록이 비대해진다. 반대로 허브를 역할별로 나누면 MCP도 각 레이어에 맞는 것만 붙이기 쉬워진다.
예를 들면 아래처럼 볼 수 있다.
- 워크스페이스 허브에는 읽기와 승인 기록 중심 툴을 둔다.
- 실행 허브에는 리서치, 초안, 코드 이해용 툴을 둔다.
- 자동화 허브에는 승인 이후 외부 반영용 툴을 둔다.
이렇게만 해도 하나의 에이전트가 모든 툴을 다 볼 필요가 없어진다.
팀이 오늘 바로 적용할 체크리스트
- 현재 MCP 도구를 읽기, 생성, 쓰기로 나눠 본다.
- 기본 세션에 꼭 필요한 도구만 남기고 나머지는 조건부 노출로 바꾼다.
- 큰 JSON 응답을 반환하는 툴은 요약 계층이나 후처리 규칙을 둔다.
- 외부 반영 도구는 기본 노출 목록에서 뺀다.
- 에이전트 실패 로그에 당시 노출된 툴 목록을 남긴다.
에이전트를 잘 쓰는 팀은 대개 툴을 많이 보여 주는 팀이 아니라, 지금 필요한 툴만 정확히 보여 주는 팀이다. MCP가 확장될수록 이 원칙은 더 중요해진다. 연결은 점점 쉬워지겠지만, 운영을 쉽게 만드는 것은 여전히 선택과 절제다.