MCP 서버의 98%가 잘못되었습니다: 프로토콜이 작동하지 않은 이유
3년 전 나는 스티브 잡스의 전기를 읽었다. iPhone에 관한 부분이 나를 사로 잡았습니다. 디자인이 아닙니다. 철학: “사람들은 보여주기 전까지는 자신이 원하는 것이 무엇인지 모릅니다.”
\ 전화에 관해서는 그의 말이 옳았습니다. 그러나 도중에 AI 산업은 이를 거꾸로 뒤집었습니다.
\ 지난주 Anthropic은 “MCP를 사용한 코드 실행”에 대한 엔지니어링 블로그 게시물을 게시했습니다. 이 게시물에서는 에이전트가 직접 도구를 호출하는 대신 코드를 작성하게 하여 98.7%의 토큰 감소를 축하했습니다.
\ AI 커뮤니티가 폭발했습니다. “정말 훌륭해요!” “이것은 문맥 문제를 해결합니다!”
\ 하지만 중요한 것은 이것이 혁신이 아니라는 것입니다. 피해관리입니다.
우리가 인정하고 싶지 않은 깨진 디자인
Model Context Protocol이 출시되었을 때 의미가 있었습니다. 직접적인 함수 정의는 논리적인 것처럼 보였습니다. 도구 정의를 컨텍스트에 로드하고 모델이 호출할 정의를 선택하도록 한 다음 결과를 관찰합니다.
\ 처음부터 깨졌다는 점만 빼면요. 구현 중이 아닙니다. 디자인 철학에서.
\ LLM은 더 많은 데이터가 더 나은 결정을 내리는 전통적인 소프트웨어 시스템이 아닙니다. 그것들은 패턴 일치 기계입니다. 컨텍스트의 모든 토큰은 노이즈를 추가합니다.
\ 이렇게 생각해보세요 => 사서가 귀하의 질문에 대답하려고 한다고 상상해 보세요. 그녀에게 관련 책이 담긴 책장을 주면 그녀는 당신의 답을 빨리 찾을 것입니다. 그녀에게 도서관 전체를 주고 30초 안에 대답하라고 하시겠습니까? 그녀는 혼란스러워 할 것입니다. 그녀는 평범함에 묻혀 있던 좋은 정보를 그리워하게 될 것입니다.
\ 이것이 바로 우리가 MCP를 통해 LLM에 수행한 작업입니다.
\ 컨텍스트 효율성은 좋은 최적화가 아닙니다. 게임 전체입니다.
\ 그리고 프로덕션 환경에서 실제 MCP 구현을 살펴보면 이를 명확하게 알 수 있습니다. 작동하는 서버는 예외적입니다. 매우 제한적이고 잘 선별된 도구 세트가 있습니다. 최대 3~5개의 도구일 수 있습니다.
\ 그 이상이라면 즉시 상황에 따른 악몽을 만들었습니다.
\ 대부분의 MCP 서버는 무엇입니까? 그것은 건축상의 실수입니다.
\ Anthropic은 도구를 직접 호출하는 대신 에이전트가 코드를 작성하도록 함으로써 토큰의 98.7%를 절약하기 때문에 자신있게 말할 수 있습니다.
\ 그리고 98%가 또 뭔지 아세요? 기본 아키텍처 원칙을 위반하는 실제 MCP 서버의 비율입니다.
\ 그것은 우연이 아닙니다.
MCP 서버의 98%가 잘못된 것
생태계는 쓸모없는 MCP 서버에 빠져들고 있습니다. 그것을 만드는 사람들이 무능하기 때문이 아닙니다. MCP가 사용자 지향 도구 통합 표준이라는 잘못된 가정에서 시작했기 때문입니다.
\ 그렇지 않아요. 처음부터 백엔드 인프라였어야 했습니다.
\ 쓸모가 없는 MCP 서버에 실제로 필요한 것은 다음과 같습니다.
→ OAuth 및 적절한 인증(장난감 API 키 아님)
→ 시행을 통한 권한 관리(세밀한 접근 제어)
→ 상태 관리(상태를 뒷받침하는 데이터베이스)
→ 관찰성(모니터링, 로깅, 추적)
\ 이 모든 기능을 갖춘 MCP 서버가 몇 개나 되는지 아십니까? 소수. 어쩌면 생태계의 2%일 수도 있습니다.
아무도 이야기하지 않는 신호 대 잡음비
LLM은 패턴 인식 시스템입니다. 더 많은 토큰은 더 많은 데이터 포인트를 의미합니다. 하지만 이는 더 많은 소음을 의미하기도 합니다.
\ 특정 비율에서는 노이즈가 신호를 압도합니다.
\ 법의학에 대해 생각해 보세요. 탐정에게 단 하나의 증거만 제시하면 설득력이 있습니다. 그들에게 백만 개의 증거를 제공했는데 그 중 99%가 관련이 없습니까? 그들은 실제 범죄를 놓칠 것입니다.
\ 그게 우리가 해왔던 일이에요. LLM에게 엄청난 양의 컨텍스트를 전달하고 왜 실적이 저조한지 궁금해합니다.
\ 실제 최적화는 더 큰 컨텍스트 창이 아닙니다. 무자비한 맥락 큐레이션입니다. 점진적인 주문형 컨텍스트 로딩. 중요한 정보만 있습니다.
실제 아키텍처: 백엔드로서의 MCP, 프런트엔드로서의 A2A
실제로 생태계에서 일어나는 일은 다음과 같습니다.
A2A(Agent-to-Agent 프로토콜)가 사용자 지향 표준으로 자리잡고 있습니다. MCP는 계속해서 그랬어야 했던 것, 즉 백엔드 문제가 되어가고 있습니다.
\ 이는 경쟁 프로토콜이 아닙니다. 그것들은 보완적입니다.
반대론자가 받아들인다
아무도 말하고 싶어하지 않는 말을 해보겠습니다.
→ 초기 MCP 채택이 실수였습니다. 너무 많은 회사가 MCP를 기반으로 구축되어 생산 준비가 완료되었다고 생각했습니다. 생태계는 순환을 낭비합니다.
→ 대부분의 개발자는 이것을 올바르게 구현하지 않습니다. MCP를 사용한 코드 실행에는 보안적 사고가 필요합니다. 시스템 프로그래밍 지식. 대부분의 팀에는 이러한 것이 없습니다.
실제 현실: 이것이 당신에게 의미하는 것
지금 MCP로 구축하고 있다면 다음과 같이 하세요.
→ MCP 도구를 즉시 감사하십시오. 5세 이상이라면 상황에 문제가 있는 것입니다. 10세 이상이면 구현이 거의 확실히 깨졌습니다.
→ 장난감 MCP 서버를 구축하지 마십시오. 하나를 구축할 생각이라면 먼저 OAuth, 권한 및 데이터베이스가 필요하다고 가정하세요.
→ 지금 코드 실행 패턴으로 마이그레이션하세요. 도구를 직접 호출하는 대신 에이전트가 코드를 작성하도록 하세요.
→ A2A 전환을 계획합니다. 전체 시스템을 다시 작성하지 않고도 구현을 교환할 수 있도록 추상화 계층을 구축하세요.
→ 토큰 효율성을 강박적으로 모니터링합니다. 요청당 컨텍스트 창 사용량 측정을 시작합니다.
더 큰 그림
MCP 이야기는 실제로 AI 산업이 문제 해결에 어떻게 접근하는지에 대한 이야기입니다.
\ 우리는 문제(도구가 모델과 잘 통합되지 않음)를 확인하고 신속하게 해결책을 선택했습니다. 당시에는 의미가있었습니다. 한동안은 효과가 있었습니다.
\ 그러자 현실이 맞았다. 솔루션이 확장되지 않았습니다. 우리는 더 나은 도구, 더 나은 정의, 더 큰 컨텍스트 창을 사용하여 패치를 시도했습니다.
\ 마침내 우리는 문제가 도구가 아니라는 것을 깨달았습니다. 문제는 아키텍처였습니다.
\ 아키텍처를 수정할 때. “모든 도구 정의를 미리 로드”에서 “코드 실행을 통해 요청 시 도구 로드”로 전환하면 문제가 깔끔하게 해결됩니다.
\ 전문성은 이런 모습이다. 지능이 아닙니다. 원시 기능이 아닙니다. 그러나 고장난 시스템을 배송하고 고치는 과정에서 어렵게 얻은 패턴 인식이 가능합니다.
결론
상황 효율성. 주문형 도구 검색. 우려의 분리.
\ MCP는 이를 지원하기 위해 발전할 것입니다. A2A는 이와 함께 성장할 것입니다. 생태계가 통합될 것입니다.
\ 그리고 2025년에 구축된 MCP 서버의 98%는요? 이는 조용히 보관되어 잘못된 측정항목에 대해 최적화할 때 어떤 일이 발생하는지 상기시켜 줍니다.
\ 하지만 나에게 희망을 주는 것은 바로 업계가 배우고 있다는 것입니다. 우리는 무엇이 효과가 없었는지 솔직하게 말하고 있습니다. 우리는 더 나은 아키텍처를 구축하고 있습니다. 우리는 제약 조건을 무시하는 대신 존중합니다.
\ 그건 실패가 아니야.
\ 그게 전문지식이에요.
\ 그리고 전문성은 지능과 달리 자동화될 수 없습니다.
자원
→ MCP를 사용한 Anthropic의 코드 실행:
→ A2A 프로토콜 사양:
→ MCP 프로토콜 문서:
→ 컨텍스트 엔지니어링에 관하여:
→ LLM의 신호 대 잡음비:
→ 원본 블로그:
\
Post Comment