현재 개발자 커뮤니티에서의 MCP 관련 대화는 기업의 거버넌스(Governance)와 권한 모델(Permission models)에 크게 집중되어 있습니다. 이는 실제적인 우려 사항입니다. 하지만 주의를 덜 받는 더 즉각적인 제약 사항이 있습니다. 더 작은 로컬 모델(Local models)을 실행하는 사람들에게 MCP의 토큰 소비 패턴은 단순한 불편함이 아니라 구조적인 문제입니다.

문제의 양상은 다음과 같습니다.

컨텍스트 윈도우(Context windows)는 대등하지 않다

128k 컨텍스트를 가진 클라우드 호스팅 모델은 3~4개의 MCP 서버로부터 오는 장황한 도구 설명(Tool descriptions)을 흡수하고도 실제 대화를 나눌 여유가 있습니다. 하지만 8k 컨텍스트를 가진 로컬 실행 7B 모델은 불가능합니다. 단 하나의 MCP 서버가 30개의 도구 설명을 컨텍스트에 밀어 넣으면, 첫 번째 사용자 메시지가 전달되기도 전에 예산의 상당 부분을 소비하게 됩니다.

이는 가설이 아닙니다. 실제로 도구 설명은 장황할 수밖에 없는데, 모델이 각 도구를 언제 어떻게 호출할지 결정하기 위해 이를 사용하기 때문입니다. 간결한 설명은 토큰을 절약하지만 라우팅(Routing) 정확도를 떨어뜨립니다. 철저한 설명은 토큰을 소모하지만 더 잘 작동합니다. 이러한 트레이드오프(Tradeoff)는 실재하며 공짜 해결책은 없습니다.

이 문제를 해결하려는 팀들은 몇 가지 접근 방식을 선택했습니다. 설명을 최소한으로 줄이고 일부 오라우팅(Mis-routing)을 수용하거나, 감지된 작업 컨텍스트에 따라 관련 도구만 주입하는 동적 도구 로딩(Dynamic tool loading)을 구현하거나, 세션당 활성 서버 수를 엄격하게 제한하는 방식입니다. 이 중 어느 것도 깔끔한 해결책은 아닙니다.

권한 모델 문제는 로컬 배포 시 양상이 다르다

권한에 관한 논의의 상당 부분은 MCP의 '전부 아니면 전무(All-or-nothing)' 식의 신뢰 모델을 기업 보안 문제로 규정합니다. 하지만 로컬 배포의 경우, 우려는 더 즉각적이고 개인적입니다. 만약 여러분이 로컬 파일 시스템이나 로컬 데이터베이스를 대상으로 MCP 서버를 실행하고 있다면, "에이전트가 이 디렉토리를 읽을 수 있음"과 "에이전트가 서버가 노출하는 모든 것을 할 수 있음" 사이의 세밀한 범위(Granular scope)가 존재하지 않습니다.

일부 실무자들은 MCP 호출을 가로채서 서버에 도달하기 전에 범위 규칙(scope rules)을 적용하는 경량 게이트웨이 계층(gateway layers)을 구축했습니다. 이 방식은 작동하지만, 유지보수가 필요한 구성 요소를 추가하며 그 자체의 장애 모드(failure modes)를 유발합니다. 프로토콜이 스펙 수준에서 이 문제를 해결하지 못한다는 것은, 이를 중요하게 생각하는 모든 팀이 각기 다른 방식으로 문제를 해결해야 함을 의미합니다.

서버 품질은 소형 모델에 중요한 방식으로 차이가 납니다

현재 공개된 대부분의 MCP 서버는 REST API 래퍼(wrapper)입니다. 도구 인터페이스(tool surface)는 언어 모델(LLM)의 소비가 아닌, 인간 개발자를 위해 설계된 원래 API의 설계를 반영합니다. LLM을 위한 좋은 도구 설계는 다릅니다. 도구는 좁아야(narrow) 하며, 이름은 모호하지 않아야 하고, 설명은 가장 식별력이 높은 정보를 앞부분에 배치(front-load)해야 합니다.

지시 이행(instruction following) 능력이 강력한 대형 모델의 경우, 평범한 도구 설명도 복구가 가능합니다. 하지만 소형 로컬 모델의 경우, 다른 도구와 유사해 보이는 설명이 부족한 도구는 지속적인 오라우팅(mis-routing)을 발생시킵니다. 생태계의 품질 격차는 소형 모델에 더 가혹하게 작용합니다.

프로토콜이 실제로 잘하고 있는 점

MCP의 정당성은 글루 코드(glue-code) 논거에 있으며, 이는 타당합니다. 공통 표준이 있기 전에는 에이전트를 여러 이기종 데이터 소스에 연결하기 위해 각 소스마다 맞춤형 통합 로직을 작성해야 했습니다. 서로 다른 인증(auth) 패턴, 서로 다른 에러 처리, 서로 다른 도구 인터페이스 관례가 존재했습니다. MCP는 이를 단일 인터페이스 패턴으로 통합합니다. 현재의 거친 부분들이 있음에도 불구하고, 초기 설정을 지나고 나면 통합 오버헤드의 감소는 실질적이고 측정 가능합니다.

이것이 실무자들에게 남기는 과제

이 프로토콜은 진정으로 유용한 일을 하고 있습니다. 다만 구현 측면에는 클라우드 사용자보다 로컬 모델 사용자에게 더 큰 타격을 주는 구체적인 문제들이 있습니다. 생태계가 아직 초기 단계이기 때문에 서버 품질과 도구 설계 규범이 아직 안정화되지 않았습니다.

현재 로컬 모델 (local models)을 사용하여 무언가를 구축하려는 사람들에게 실질적인 질문은 다음과 같습니다: MCP 도구 설명 (MCP tool descriptions)이 컨텍스트 예산 (context budget)을 잠식하지 않도록 하기 위한 실제 전략은 무엇이며, 여기에 세 번째 또는 네 번째 서버를 추가했을 때도 그 전략이 유효할까요?