MCP 컨텍스트 블로트: 클로드 코드 사용자를 위한 실제 비용과 실용적 해결책

Reddit 사용자가 Claude Code에서 9개의 MCP 서버를 4개월간 운영하면서 겪은 숨겨진 비용과 성능 저하, 그리고 구체적인 해결책을 공유했습니다. 이 게시글은 프로덕션에서 MCP를 사용하는 모든 사람이 꼭 읽어야 할 내용입니다.

수치로 보는 문제

9개의 서버(파일시스템, GitHub, Stripe, Linear, Notion, Postgres, Sentry, AWS, 커스텀)에서 총 142개의 도구를 노출할 때, 콜드 스타트는 매 턴마다 시스템 프롬프트 + 도구 스키마에 38k 토큰을 소모합니다. 하루 200턴 기준, 입력 토큰은 760만 개입니다. Sonnet 가격(~$15/M 출력, ~$3/M 입력)으로 환산하면 실제 작업 전에 MCP 도구 정의만으로 하루 약 $23, 월 약 $700의 비용이 발생합니다. 캐싱은 동일한 접두사에만 도움이 되며, MCP 서버 하나만 변경되어도 캐시가 무효화됩니다.

발생하는 문제점

• 도구 선택 성능 저하: 142개의 도구가 컨텍스트에 포함되면서 Claude가 명백한 쿼리(예: 파일 읽기 요청에 linear_search_issues 사용)에서도 잘못된 도구를 선택하기 시작했습니다.
• 느린 열거: AWS와 같이 스키마가 무거운 서버는 도구 목록을 표시하는 데 4~6초가 소요됩니다.
• 무음 오류 전파: 설명이 부실한 도구 하나가 관련 쿼리 전체의 순위를 망칠 수 있습니다.

해결책: BM25를 활용한 게이트웨이 패턴

사용자는 Ratel이라는 오픈소스 인프로세스 Rust 라이브러리( BM25 랭킹 지원)를 사용한 게이트웨이 패턴으로 전환했습니다. 이제 Claude는 search_tools, invoke_tool, auth 세 가지 도구만 볼 수 있습니다. 나머지는 주문형으로 순위가 매겨집니다. 결과:

• 콜드 스타트 토큰이 38k에서 약 4k로 감소했습니다.
• 잘못된 도구 선택이 거의 사라졌습니다. 모델이 쿼리별 상위 5개 도구만 보기 때문입니다.
• 설정 시간은 10분이면 충분했습니다(단일 명령으로 Claude Code 임포트 가능).

저자는 대부분의 "MCP 옵티마이저" 스타트업이 사실상 BM25 검색에 불과하다고 지적합니다. 도구 설명은 짧고 구조화되어 있으며 키워드 매칭이 풍부하여, 벡터 DB나 LLM 개입이 필요하지 않습니다. 이름과 설명을 평탄화한 BM25만으로도 마이크로초 단위로 오프라인에서 90%의 효과를 결정론적으로 얻을 수 있습니다.

핵심 교훈: "제안"보다 "대체"가 낫다. 게이트웨이가 모델에 5개의 도구만 제공하면 수학적으로 효과가 있습니다. 142개 도구와 함께 5개를 제안하면, 모델은 여전히 142개를 로드하므로 절약되는 것이 없습니다.