MCP는 붙일수록 좋은 게 아니었다
2026-04-26#ai#mcp#claude-code
MCP를 18개까지 붙였다가 7개로 줄였다. 제거를 결정하게 해준 측정들의 기록.
MCP(Model Context Protocol)는 AI에게 외부 도구를 꽂는 표준 프로토콜이다. DB 조회, 이슈 트래커, 로그 검색, 디자인 툴 — 서버 하나 연결하면 AI가 그 도구를 직접 호출할 수 있게 된다.
하네스를 만들면서 눈에 보이는 대로 붙였다. DB, 로그, 문서, 디자인, 메시징, 다이어그램… 어느새 18개였다. 능력이 늘어난 만큼 좋아진 줄 알았는데, 측정해보니 아니었다. 지금은 7개다. 이 글은 11개를 걷어내며 배운 기준의 기록이다.
연결만 해도 비용이 나간다#
MCP 서버를 연결하면 도구 정의와 사용 지침이 시스템 프롬프트에 주입된다. 문제는 이게 매 턴 실린다는 것이다. 그 도구를 쓰지 않는 턴에도, 대화가 100턴이면 100번 청구된다. 18개를 점검해보니 다수가 이렇게 상시 주입되고 있었고, 시스템 프롬프트에서만 매 턴 수천 토큰이 나가고 있었다.
여기서부터는 도구별로 "실제로 값을 하는가"를 측정했다.
압축률 12.8%가 알려준 것#
로그 조회 MCP가 첫 대상이었다. 툴 결과를 압축해주는 도구를 함께 쓰고 있었는데, 통계를 열어보니 **1,181개 요청 중 압축이 발동한 건 18건, 평균 압축률 12.8%**였다. 로그 압축기는 stdout 텍스트를 10~50배로 줄여주는데, MCP는 구조화된 JSON을 반환하니 그 경로를 아예 타지 못한 것이다.
MCP를 제거하고 CLI 헬퍼 스크립트로 바꿨다. 로그 조회의 시작-폴링- 결과 조회 보일러플레이트를 스크립트 하나로 감싸고, 규칙 파일에는 "로그는 MCP가 아니라 이 스크립트로"라고 못 박았다. 같은 기능, 압축은 제대로 타고, 상시 주입 비용은 0이 됐다.
같은 일, 도구는 4분의 1#
DB 조회는 MCP 두 인스턴스에 도구 8개짜리 구성이었다. 이걸 도구를
2개(execute_sql, search_objects)만 노출하는 서버 하나로
교체했다. 기능 차이는 없는데 도구 정의 토큰이 약 75%
줄었다. 도구 개수가 많은 서버일수록, 노출 도구를 최소로 좁힌
대안이 있는지 먼저 볼 일이다.
대체재가 이미 있었다#
한 번에 4개를 걷어낸 날도 있다. 클라우드 문서 조회 MCP는 일반 웹 요청으로 충분했고, 디자인 툴 MCP는 사람이 웹 UI를 보는 게 빨랐고, 메시징 MCP는 CLI 명령이 이미 있었고, 다이어그램 MCP는 쓰질 않았다. 넷을 지우니 시스템 프롬프트가 2,000~3,000토큰 가벼워졌다. MCP가 하는 일의 상당수는 이미 갖고 있는 도구(웹 요청, CLI)의 포장이었다.
토큰만의 문제가 아니다#
DB MCP에서는 운영(prod) 소스를 목록에서 제거했다. 읽기 전용인데도 그랬다 — LLM이 판단해서 자동 호출하는 도구인 이상 무거운 쿼리가 운영 DB에 나갈 수 있고, 자격증명을 평문으로 상시 보관해야 하는 부담도 있다. 도구를 준다는 건 사고 반경을 준다는 뜻이라서, 연결 여부는 능력이 아니라 필요한 최소 범위 기준으로 정했다.
남은 기준#
11개를 걷어내고 남은 7개는 대체재가 없는 것들이다 — DB 조회, 구조적 추론, 라이브러리 최신 문서, 이슈 트래커, 툴 결과 압축, 로컬 디버거. 그리고 이 경험을 지시문서에 두 줄로 승격했다.
- MCP 서버 추가 원칙: 매 턴 주입되는 instruction 크기 검토. 300토큰 이상이면
프로젝트 스코프로 격리. WebFetch/CLI로 대체 가능하면 추가 지양
MCP는 기본값이 아니라 예외여야 한다. "연결할 수 있다"와 "연결해야 한다" 사이에 측정이 있어야 하고, 측정이 없으면 능력을 늘린다는 착각 속에서 비용과 사고 반경만 늘게 된다.