에이전트-도구 상호 작용을 위한 MCP 표준 정의
생태계가 15,000개 서버로 확장됨에 따라, 메시지 통신 프로토콜(MCP)은 Claude 및 ChatGPT와 같은 AI 플랫폼이 도구 및 리소스에 안전하게 접근할 수 있도록 합니다.
이 프로토콜은 AI 에이전트에게 도구 및 리소스에 대한 보안 액세스를 제공하여 Claude 및 ChatGPT와 같은 플랫폼에서 사용되는 10,000~15,000개의 활성 서버로 생태계의 빠른 성장을 촉진합니다.
Apify CEO Jan Čurn에 따르면, 메시지 통신 프로토콜에 대한 많은 비판은 프로토콜 자체가 아니라 미숙한 에이전트 구현에서 비롯된다고 합니다.
생태계가 15,000개 서버로 확장됨에 따라, 메시지 통신 프로토콜(MCP)은 Claude 및 ChatGPT와 같은 AI 플랫폼이 도구 및 리소스에 안전하게 접근할 수 있도록 합니다.
이 프로토콜은 AI 에이전트에게 도구 및 리소스에 대한 보안 액세스를 제공하여 Claude 및 ChatGPT와 같은 플랫폼에서 사용되는 10,000~15,000개의 활성 서버로 생태계의 빠른 성장을 촉진합니다.
업계의 유명 인사들과 프로젝트들은 MCP에 대해 상당한 불만을 표명하며 근본적인 설계에 이의를 제기했습니다.
Peter Levels와 Gary Tan을 포함한 비평가들은 MCP가 잘못된 추상화이며, 모든 MCP 서버에 대해 결정론적 CLI가 더 우월한 대안이었을 것이라고 주장합니다.
초기 에이전트 구현은 시작 시 컨텍스트 창에 사용 가능한 모든 MCP 도구를 미숙하게 등록했습니다.
이러한 관행은 에이전트가 수백 개의 도구를 로드하여 실제 작업이 시작되기 전에 컨텍스트의 상당 부분을 낭비하게 했고, 이는 '컨텍스트 블로트'라는 현상을 초래했습니다.
Jan Čurn은 지속적인 도구 사용 및 결과 주입이 이러한 블로트를 더욱 악화시켜 정확성을 떨어뜨리고 토큰 비용을 증가시킨다고 지적하며, 이 문제가 MCP 프로토콜 자체가 아닌 에이전트의 하네스 구현에 있다고 주장합니다.
작업을 서브 에이전트로 분할하는 것이 특정 컨텍스트를 분리하는 데 도움이 될 수 있지만, 토큰이 여전히 소비되기 때문에 전체 토큰 비용을 줄이지는 못합니다.
도구에 의해 반환된 민감한 데이터는 컨텍스트 내에 남아 취약하며, 교차 도구 데이터 남용의 위험이나 대규모 데이터 세트 처리의 어려움을 해결하지 못합니다.
이 접근 방식은 근본적인 해결책을 제공하기보다는 문제를 단순히 연기하거나 재배치할 뿐입니다.
이 방법은 수백 개의 사용되지 않는 도구를 로드하는 문제를 해결하기 위해 필요할 때만 특정 도구를 동적으로 찾아 가져옵니다.
이를 통해 에이전트는 더 적은 토큰을 소비하여 더 빠른 실행과 낮은 운영 비용을 달성합니다.
이 접근 방식은 코드 분석 및 작성에 대한 대규모 언어 모델(LLM)의 고유한 강점을 활용하여 모델에 인공적인 '도구 호출' 구문을 가르칠 필요가 없습니다.
도구를 코드로 제시함으로써 LLM은 정의에 대해 자연스럽게 추론하고 상호 작용할 수 있습니다.
Cloudflare의 현재 코드 모드 구현은 플랫폼별이므로 광범위하게 채택하기 어렵습니다.
대부분의 기존 MCP 클라이언트는 프로토콜의 상당한 발전에도 불구하고 고급 기능을 지원하지 않습니다.
이러한 불일치는 많은 에이전트가 구식 기능으로 작동하여 MCP 표준의 최신 개선 사항을 활용하지 못한다는 것을 의미합니다.
에이전트는 전체 도움말 파일을 컨텍스트에 로드하지 않으므로 점진적 발견을 사용하여 명령줄 인터페이스(CLI) 도구와 자연스럽게 상호 작용합니다.
CLI 도구는 샌드박스 내에서 코드로 작동하며, 1969년부터 Linux/Unix 명령에 대한 LLM의 강점 및 훈련과 완벽하게 일치합니다.
40년 이상 개선된 터미널 인터페이스는 높은 정보 밀도를 제공하여 에이전트에 본질적으로 최적화되어 있습니다.
이러한 오랜 상호 작용 및 최적화 역사는 CLI를 원시 MCP에 비해 에이전트에게 더 직관적이고 효율적인 인터페이스로 만듭니다.
에이전트는 광범위한 훈련 데이터 덕분에 셸 명령을 실행하고 파이프하는 방법을 포함하여 깊이 이해하고 있습니다.
AI 연구소는 셸 명령을 탐색하여 무한한 훈련 데이터를 생성할 수 있으며, 이는 이러한 숙련도를 더욱 향상시킵니다.
이것은 셸을 LLM이 작동하기 위한 예측 가능하고 친숙한 환경으로 만듭니다.
내부 검사 및 표준화된 자격 증명 주입 메커니즘의 부재는 CLI 작업의 보안 및 모니터링을 어렵게 합니다.
원격 액세스 시나리오의 경우 MCP는 표준화된 프로토콜 기능 덕분에 확실한 이점을 유지합니다.
그러나 CLI는 표준 아웃엔드 전송 프로토콜이 없는 로컬 블랙박스입니다. 기본적으로 말하자면, 문자 그대로 블랙박스입니다. 검은 터미널 화면이죠. 그리고 그 안에서 무슨 일이 일어나는지 볼 수 없습니다.
이 접근 방식은 에이전트가 이미 능숙한 간단한 bash 도구 호출을 통해 모든 MCP 프로토콜 기능을 제공할 수 있어 MCP의 복잡성을 효과적으로 추상화합니다.
에이전트는 'bash'를 호출하는 방법만 이해하면 되므로 세션 관리 및 인증 프로세스가 간소화됩니다.
mcpc는 MCP 작업, 리소스 및 프롬프트를 지원하여 기본 프로토콜을 추상화하고 '코드 모드'와의 완벽한 호환성을 보장합니다.
'--JSON' 플래그를 포함하여 순수 JSON 출력을 제공하여 'jq'와 같은 도구와의 통합을 용이하게 하며, 브라우저 기반 인증 후 로컬 OS 키체인에 자격 증명을 저장하여 안전하게 관리합니다.
MCP 프로토콜에는 많은 현재 클라이언트가 지원하지 못하는 특정 지침이 포함되어 있습니다.
MCPC는 이러한 한계를 해결하기 위해 사용자가 연결을 끊어도 활성 상태를 유지하고 나중에 돌아올 수 있도록 상태를 유지하는 영구 세션을 지원합니다.
또한 grep과 유사한 명령을 통해 점진적인 도구 발견을 용이하게 하여 에이전트가 특정 서버 및 도구를 필터링하고 찾을 수 있도록 하며, 반복적인 설정 없이 구성 공유를 가능하게 합니다.
MCP 프로토콜은 이제 비동기 작업 기능을 포함하고 있지만, 많은 클라이언트가 아직 이를 지원하지 않습니다.
MCPC는 사용자가 서버에서 작업을 시작할 수 있도록 하여 로컬 작업을 차단하지 않고 백그라운드에서 실행되도록 합니다.
이 기능을 통해 사용자는 진행 중인 작업에서 분리된 다음 나중에 진행 상황을 확인하거나 결과를 검색할 수 있습니다.
MCPC의 `--JSON` 명령은 결과를 JSON 형식으로 출력하여 셸 스크립트에 원활하게 통합할 수 있도록 합니다.
이는 불필요한 정보를 로드하지 않아 컨텍스트 토큰을 절약하면서 MCP 서버의 백그라운드 실행을 가능하게 합니다.
또한 MCPC는 X42와 같은 도구에 대한 지원을 확장하여 클라이언트를 통해 로컬 지갑 관리가 가능하도록 합니다.
Apify는 다양한 커넥터의 성능을 벤치마킹하기 위해 'Connector Evals' 프레임워크를 개발했으며, 완료 시간 및 토큰 비용에 중점을 두었습니다.
Claude 3.5 Sonnet으로 수행된 테스트 결과 MCPC와 네이티브 CLI가 유사한 성능 지표를 보였습니다.
원시 MCP가 때로는 작업을 더 빨리 완료했지만, 특정 시나리오에서는 더 많은 토큰을 소비하는 경우가 있어 절충점이 있음을 나타냅니다.
결론은 MCP와 mcpc와 같은 CLI 클라이언트를 결합한 하이브리드 접근 방식이 성능과 비용 효율성 모두에서 최적의 균형을 제공한다는 것입니다.
자막에서 근거가 되는 대목을 찾아 답합니다.
AI Engineer의 다음 글도 받아볼까요?
AI Engineer에 새 영상이 올라오면, 방금 읽으신 것처럼 정리해서 메일로 보내 드릴게요.
이 채널은 지난 7일 동안 26편 올렸어요.