MCP를 처음 붙일 때는 연결 수가 곧 경쟁력처럼 느껴진다. 문서, 데이터베이스, 자동화 엔진, 코드 저장소를 한꺼번에 열어 두면 에이전트가 더 많은 일을 해낼 것처럼 보이기 때문이다. 하지만 실제 운영에서는 다른 현상이 먼저 나타난다. 에이전트가 쓸데없이 긴 탐색을 하고, 같은 작업에서도 도구 선택이 흔들리고, 결과물은 오히려 산만해진다.
최근 커뮤니티에서 컨텍스트 압축과 프록시형 MCP 이야기가 반복되는 이유도 여기에 있다. 이제 문제는 MCP를 붙일 수 있느냐가 아니다. 붙인 도구를 얼마나 적절하게 숨기고 요약하고 라우팅할 수 있느냐가 운영 품질을 가른다.
왜 도구가 많을수록 더 느려지는가
에이전트는 사람이 아니다. 많은 선택지를 보면 자동으로 현명해지는 것이 아니라, 어느 도구를 선택할지 판단 비용이 커진다. 작업과 직접 관련 없는 도구까지 한꺼번에 보이면 에이전트는 매번 불필요한 후보를 검토하게 되고, 그 과정에서 토큰과 시간이 함께 증가한다.
문제는 비용만이 아니다. 도구 수가 늘수록 잘못된 경로를 타는 확률도 오른다. 예를 들어 초안 작성 작업인데 배포나 외부 발신 도구가 함께 노출돼 있으면, 의도하지 않은 쓰기 시도가 섞일 가능성도 커진다. 그래서 컨텍스트 압축은 성능 최적화이면서 동시에 안전 설계다.
컨텍스트 압축은 요약이 아니라 노출 정책이다
많은 팀이 압축을 단순히 긴 설명을 짧게 줄이는 작업으로 이해한다. 하지만 MCP 운영에서 더 중요한 것은 무엇을 보여주지 않을지 결정하는 일이다. 즉 컨텍스트 압축은 문장 요약보다 노출 정책에 가깝다.
실무에서는 세 단계로 나누면 이해가 쉽다. 첫째는 전역 연결이다. 시스템 차원에서 사용할 수 있는 도구를 등록해 둔다. 둘째는 작업 라우팅이다. 현재 작업이 어느 종류인지 판별해 필요한 도구 묶음을 고른다. 셋째는 호출 직전 압축이다. 선택된 도구에 대해서만 필요한 입력과 제한 규칙을 짧게 전달한다.
이 세 단계를 분리하면 같은 MCP 생태계를 유지하면서도 작업별 컨텍스트는 훨씬 가볍게 만들 수 있다.
search/execute형 프록시가 뜨는 이유
최근 반복적으로 언급되는 프록시형 구조는 이 문제를 다루기 쉽기 때문이다. 에이전트에게 개별 도구를 전부 직접 노출하는 대신, 먼저 search 계층에서 관련 도구를 좁히고 execute 계층에서 실제 호출을 수행하게 만드는 방식이다. 이렇게 하면 에이전트는 매번 전체 도구 목록을 보지 않아도 된다.
이 구조의 장점은 두 가지다. 하나는 컨텍스트 절감이다. 관련 없는 도구 설명을 계속 보여줄 필요가 없다. 다른 하나는 통제 가능성이다. search 단계에서 작업 유형, 권한 수준, 승인 필요 여부를 같이 반영할 수 있기 때문이다. 결국 프록시형 구조는 더 똑똑한 도구 선택기를 만들기보다, 잘못된 선택지를 미리 줄이는 쪽에 가깝다.
작은 팀이 바로 적용할 라우팅 기준
복잡한 인프라가 없어도 기본 라우팅 규칙은 만들 수 있다.
- 리서치 작업에는 검색, 문서 조회, 기록 조회만 연다.
- 초안 생성 작업에는 작성 도구와 읽기 도구만 연다.
- 쓰기나 발행 작업에는 승인 직전까지 고위험 도구를 숨긴다.
- 코드 수정 작업은 별도 sandbox나 branch 단위로 보내고 다른 업무 도구와 분리한다.
- 실패 로그에서 자주 잘못 집는 도구가 있으면 기본 세트에서 제외한다.
이 정도만 해도 MCP 운영 품질은 크게 올라간다. 중요한 것은 완벽한 분류기가 아니라 기본적으로 너무 많이 보여주지 않는 습관이다.
컨텍스트 압축은 멀티 에이전트 운영의 전제다
여러 에이전트를 동시에 돌릴수록 도구 노출 문제는 더 커진다. 같은 작업함 안에서 각 에이전트가 서로 다른 도구 세트를 보게 되면 결과 비교가 어려워지고, 권한 경계도 흐려진다. 반대로 역할별로 압축된 도구 세트를 고정하면 병렬 실행 결과가 더 예측 가능해진다.
그래서 컨텍스트 압축은 부가 최적화가 아니라 멀티 에이전트 운영의 기본 전제에 가깝다. Goal이 선명해도 도구 노출이 과하면 결과는 흔들린다. 좋은 운영은 목표 정의와 도구 압축이 같이 있을 때 비로소 안정된다.
적용 체크리스트
- 시스템 연결과 작업 노출을 같은 문제로 다루지 않는다.
- 작업 유형별 최소 도구 세트를 먼저 정한다.
- 고위험 쓰기 도구는 기본 세트에서 빼고 승인 직전에만 연다.
- search와 execute를 분리할 수 있으면 프록시 계층을 둔다.
- 실패 로그를 보고 잘못 선택된 도구를 줄인다.
MCP 시대의 실전 경쟁력은 연결 수가 아니라 라우팅 품질에서 나온다. 도구를 많이 붙일수록 더 많이 숨기고 더 짧게 보여줘야 한다. 그래야 에이전트는 더 빠르고, 더 싸고, 더 예측 가능하게 움직인다.
상위 허브 글은 멀티 에이전트 작업함 운영 가이드: 승인·격리·피드백을 한 번에 설계하는 법에서 볼 수 있다. 그 글은 컨텍스트 압축을 목표 정의, 실행 격리, 리뷰 루프와 함께 하나의 운영 구조로 연결한다.