MCP가 아니라 에이전트가 문제다: CLI와 결합하는 실전 설계

URL: https://www.youtube.com/watch?v=pAnLpiAG6Es
날짜: 2026-10-03
채널: aiDotEngineer
발표자: Jan Čurn, Apify
원문 제목: MCP Doesn't Suck. Your Agent Does. — Jan Čurn, Apify

---

📌 핵심 질문 / 이 발표를 관통하는 논점

==MCP(Model Context Protocol)가 형편없는 것이 아니라, MCP를 모든 도구를 한꺼번에 컨텍스트에 밀어 넣는 방식으로 사용하는 에이전트 하니스(harness)가 문제다.== MCP의 원격 접근 표준성과 CLI(Command-Line Interface)의 점진적 발견·코드 실행 특성을 결합하면, 도구 호출의 컨텍스트 비용과 복잡성을 줄이면서도 MCP의 기능을 유지할 수 있다.

• MCP는 에이전트와 도구·리소스 사이의 표준으로 빠르게 확산됐고, 발표 시점에 서버가 약 1만~1만 5천 개에 이르렀다.
• 초기 MCP 클라이언트는 수십~수백 개 도구의 설명을 질문을 받기도 전에 모두 컨텍스트에 등록해 토큰과 정확도를 낭비했다.
• 하니스가 progressive tool discovery와 code mode를 사용하지 않은 책임을 MCP 프로토콜에 돌릴 수는 없다.
• 로컬 에이전트 인터페이스에는 CLI가 자연스럽고, 표준화된 원격 접근에는 MCP가 적합하므로 둘을 결합하는 편이 양쪽의 장점을 살린다.

핵심 결론은 MCP와 CLI 중 하나를 폐기하는 것이 아니라, MCP를 원격 프로토콜로 두고 CLI를 에이전트가 이미 잘 아는 로컬 실행 인터페이스로 사용하는 것이다. Jan Čurn이 소개한 MCPC는 MCP의 세션·인증·리소스·태스크를 CLI 뒤에 감싸고, JSON·파이프·비동기 실행으로 에이전트가 효율적으로 조합하도록 만든다.

1. MCP의 폭발적 성장과 갑작스러운 반발

1.1. 표준의 등장과 AI 생태계 확장

1. MCP의 역할

   1. 도구·리소스 접근 표준: MCP는 에이전트가 도구(tools)와 리소스(resources)에 안전하게 접근하도록 하는 프로토콜이며, 본질적으로 agent-to-tool interaction을 표준화한다.
   2. 등장 배경: Anthropic이 약 2년 전에 도입했고, 짧은 기간에 AI 생태계 전체를 휩쓸었다.

2. 서버와 클라이언트의 확산

   1. 서버 규모: 발표 시점에는 MCP 서버가 약 10,000~15,000개에 달한다고 언급된다.
   2. 클라이언트 채택: Claude와 ChatGPT 같은 클라이언트가 도구와 커넥터를 AI 에이전트에 연결하는 기본 방식으로 MCP를 채택했다.
   3. 레지스트리의 레지스트리: 서버가 너무 많아 MCP 서버 레지스트리가 생겼고, 레지스트리도 너무 많아져 MCP server registry registries까지 만들어야 하는 우스꽝스러운 단계에 이르렀다.

1.2. “MCP는 죽었다”는 서사

1. 비판이 유행한 이유

   1. 찬양에서 공격으로: 한때 AI 세계의 총아였던 MCP가 특히 전년부터 집중적인 비판을 받기 시작했다.
   2. Anthropic의 자기비판으로 인식된 발언: “MCP sucks”, “MCP is the wrong abstraction” 같은 말이 인용되며 Anthropic이 MCP를 고치려 애쓴다는 인상이 생겼다.

2. CLI 옹호론의 대표 문구

   1. MCP의 실수라는 주장: “MCP was a mistake. Long live CLIs.”라는 구호가 나왔다.
   2. API와 CLI 승리론: OpenClaw가 API와 CLI가 이길 것이라는 점을 보여줬다는 주장, OpenClaw가 MCP를 MCP-to-CLI converter인 MCPorter(자막상 MCorter)를 통해서만 지원한다는 사례가 제시됐다.
   3. 결정적 CLI로의 환원: “MCP는 대부분 쓸모없다”, “모든 MCP는 deterministic CLI가 될 수 있었다”는 극단적 주장도 나왔다.
   4. 다른 인물들의 반응: Gary Tan은 “MCP sucks honestly”라고 했고, Peter Levels는 “thank god MCP is dead”라고 말했다는 사례가 소개됐다.

3. 문제 재정의

   1. 반발의 핵심 질문: 왜 모두 MCP를 공격하는지 살펴보려면 프로토콜 이름이 아니라 실제 사용 방식에서 무엇이 잘못됐는지 봐야 한다.
   2. 발표의 입장: 문제의 상당 부분은 MCP 자체가 아니라 MCP를 비효율적으로 사용하는 에이전트와 하니스에 있다.

2. MCP가 컨텍스트를 낭비하는 방식

2.1. 초기 클라이언트의 순진한 도구 등록

1. 도구 수의 폭증

   1. 서버와 도구의 단순 합산: 10개의 MCP 서버가 있으면 서버마다 10개 도구가 있다고 가정해 총 100개 도구를 갖는 식으로 처리했다.
   2. 질문 전 선등록: 에이전트는 사용자가 질문하기도 전에 100개 도구의 이름과 설명을 전부 컨텍스트에 등록했다.

2. 실제 비용

   1. 컨텍스트의 3분의 1: 아무 작업도 하기 전에 컨텍스트의 약 3분의 1이 도구 정의만으로 사라질 수 있다.
   2. 결과의 재투입: 도구를 호출할 때마다 입력과 결과가 컨텍스트에 다시 추가되어 컨텍스트가 계속 길어진다.
   3. 품질과 비용 악화: 컨텍스트가 오래 누적될수록 정확도가 떨어지고, 토큰 비용이 증가하며, 전체 실행이 비효율적으로 변한다.

2.2. 책임은 프로토콜보다 하니스에 있다

1. MCP 명세의 역할 범위

   1. 하니스 설계 공백: MCP specification은 하니스가 도구를 컨텍스트에 언제, 어떻게 넣어야 하는지 사실상 아무것도 규정하지 않는다.
   2. 구현자의 책임: 에이전트를 만드는 사람이 MCP를 효과적으로 사용하도록 설계해야 하며, 비효율적인 등록 방식은 프로토콜 결함이 아니라 harness 구현의 결함이다.

2. 컨텍스트를 저장소로 쓰는 위험

   1. 민감 정보 잔존: MCP 도구가 비밀번호 같은 민감한 값을 반환하면 그 값이 컨텍스트에 남는다.
   2. 후속 호출에 노출: 남아 있는 비밀번호나 민감 결과가 다른 도구 호출 또는 애플리케이션에 의해 악용될 수 있다.
   3. 대용량 데이터의 부적합성: 컨텍스트는 민감한 값이나 큰 데이터를 전달하기에 나쁜 장소다.

3. 컨텍스트 문제에 대한 세 가지 해법

3.1. 해법 1: 서브에이전트로 컨텍스트 분리

1. 작동 원리

   1. 특정 작업을 새 서브에이전트에 위임하고 별도의 컨텍스트를 부여한다.
   2. 서브에이전트의 도구 호출이 주 에이전트의 메인 컨텍스트 창을 직접 부풀리지 않게 만든다.

2. 한계

   1. 토큰 비용의 이동: 메인 창에서 사라졌을 뿐 서브에이전트가 사용하는 토큰 비용은 그대로 지불해야 한다.
   2. 민감 정보 문제의 지속: 서브에이전트의 컨텍스트에도 비밀번호와 대용량 결과가 남으므로 근본 해결이 아니다.
   3. 문제의 지연: 문제를 조금 뒤로 밀어낼 뿐 제거하지 못한다.

3.2. 해법 2: Progressive Tool Discovery

1. 필요할 때만 도구를 공개

   1. 도입 시기와 주체: 전년 말 무렵 Anthropic과 Cursor가 progressive tool discovery를 도입했다.
   2. 핵심 아이디어: 100개 도구를 처음부터 컨텍스트에 넣지 않고, 필요한 순간에 필요한 도구만 찾아 컨텍스트에 추가한다.

2. Tool Search 방식

   1. 검색 도구: Anthropic의 Claude에는 다른 도구를 찾는 tool search tool이 들어갔다.
   2. 토큰 절약: 실제 작업에서 필요한 도구는 대개 한두 개이므로, 거의 쓰지 않을 100개 도구를 항상 넣는 것보다 컨텍스트를 크게 줄일 수 있다.
   3. 실행 효과: 컨텍스트가 작아져 더 효율적이고, 더 저렴하며, 더 빠르게 실행된다.

3. 채택 현실

   1. 당연한 기능의 늦은 등장: 너무 단순한 아이디어라서 이제야 이런 방식을 적용해야 한다는 사실 자체가 아플 정도라고 농담한다.
   2. 보편화의 부족: 모든 에이전트가 이 기능을 써야 할 것처럼 보이지만 실제로는 그렇지 않다.

3.3. 해법 3: Code Mode

1. 도구를 코드로 취급

   1. 도입 주체: Cloudflare가 전년 말 무렵 code mode를 소개했다.
   2. 핵심 전환: MCP 도구를 컨텍스트에 넣어야 하는 함수 목록으로 취급하지 않고, 코드로 변환해 코드처럼 탐색하고 실행한다.

2. 모델이 코드에 강한 이유

   1. 탐색 능력: 모델은 grep 같은 도구로 검색하고, 올바른 정의를 찾고, 코드 구조를 탐색하는 데 익숙하다.
   2. 도구 설명 탐색: 같은 능력으로 도구 설명과 관련 정보를 코드 형태로 찾아갈 수 있다.
   3. 학습 데이터의 차이: 일반적인 tool calling은 실제 세계나 모델의 자연스러운 학습 데이터에 존재하는 방식이 아니라 LLM에 가르치기 위해 합성된 인공 구조다.
   4. 코드 호출의 자연스러움: 반면 코드 작성과 코드 호출은 모델이 훨씬 많이 보고 학습한 패턴이므로 tool calling보다 잘 처리한다.

3. Code Mode의 한계

   1. 플랫폼 종속성: Cloudflare 구현은 사용하기 어렵고 해당 플랫폼에 강하게 묶여 있다.
   2. 낮은 접근성: 사용 방식이 직관적이지 않아 일부 사례를 제외하면 실제로 쓰는 사람이 많지 않다.
   3. 클라이언트의 지체: MCP 프로토콜은 새로운 기능을 많이 얻으며 발전했지만, 대부분의 MCP 클라이언트가 progressive discovery나 code mode를 지원하지 않아 여전히 “암흑시대”에 머물러 있다.

4. CLI가 기본적으로 효율적인 이유

4.1. 점진적 발견과 기본 Code Mode

1. CLI는 전체 명세를 미리 넣지 않는다

   1. 에이전트는 CLI의 모든 명령을 탐색하고 help 내용을 전부 컨텍스트에 넣지 않는다.
   2. 필요한 순간에만 CLI를 호출하며, 이 점진적 사용이 기본값이다.

2. 모델의 사전 지식과 도움말

   1. 기본 Linux 명령처럼 오래된 명령은 모델이 학습 데이터에서 이미 알고 있는 경우가 많다.
   2. 모르는 CLI는 help나 매뉴얼 페이지를 실행해 필요한 부분만 배울 수 있다.
   3. CLI 실행은 기본적으로 샌드박스(sandbox)나 머신 같은 런타임에서 수행하는 코드다.
   4. 따라서 CLI는 처음부터 bash code로 실행되는 code mode를 갖고 있으며, MCP가 나중에 code mode로 성장해야 했던 것과 다르다.

4.2. 에이전트가 Shell을 잘 다루는 이유

1. 오랜 역사와 압축된 인터페이스

   1. 자막에는 Linux shell로 잡혔지만, Unix가 1969년 Ken Thompson과 Dennis Ritchie가 만든 뒤 오래 이어졌다고 말한다. 정확히 말하면 1969년에 두 사람이 만든 것은 Unix이며, 이 역사적 맥락이 현재의 셸 도구 생태계로 이어진다.
   2. 검은색 화면에 80열, 약 25행이 표시되는 전통적인 터미널은 컴퓨터에서 일어나는 일을 매우 압축해 전달하는 인터페이스다.
   3. 수십 년 동안 각 문자와 바이트가 가장 중요한 정보만 전달하도록 최적화돼 왔다.

2. 학습 데이터와 조합성

   1. 에이전트는 CLI 명령을 호출하고, 여러 명령을 pipe로 연결하며, shell을 사용하는 방법을 학습 데이터에서 매우 많이 봤다.
   2. AI 연구소는 shell을 실행해 명령을 조합하고, 매뉴얼 페이지에서 정보를 뽑고, 파이프라인을 탐색하는 합성 학습 데이터를 사실상 무한히 만들 수 있다.
   3. 그 결과 에이전트가 shell을 잘 알고, CLI를 코드처럼 조합하는 능력이 강화된다.

4.3. CLI의 한계와 MCP의 강점

1. CLI는 로컬 블랙박스다

   1. CLI에는 표준화된 외부 transport protocol이 없고, 내부에서 무슨 일이 일어나는지 보이지 않는 검은 터미널처럼 동작한다.
   2. 기업 환경에서 CLI를 계측(instrument)하려면 내부 프로토콜을 역추적해야 한다.
   3. 그 CLI가 API를 사용하는지 WebSocket을 사용하는지 알기 어렵고, 외부에서 자격 증명을 주입할 표준적인 방법도 없다.

2. 접근 범위에 따른 선택

   1. 로컬 인터페이스로는 CLI가 훌륭하지만, 원격 접근에는 MCP가 더 낫다.
   2. 원격 MCP 커넥터 대신 CLI 커넥터를 쓰는 에이전트 사례는 거의 없으며, 원격 서비스 연결이라는 목적에는 CLI가 자연스럽지 않다.
   3. 따라서 MCP는 표준 원격 접근을 담당하고 CLI는 로컬 에이전트 인터페이스를 담당하는 조합이 적절하다.

5. MCP의 원격 기능을 CLI로 감싸는 MCPC

5.1. 설계 목표

1. Bash 하나 뒤에 복잡성을 숨기기

   1. MCP의 세션(session), 인증(authorization), OAuth 및 기타 프로토콜 복잡성을 에이전트가 이미 아는 단일 도구 호출인 bash 뒤에 숨긴다.
   2. 에이전트는 단순히 bash를 호출하면서 MCP의 기능을 코드 실행 방식으로 사용할 수 있다.

2. MCPC의 탄생

   1. MCPC는 MCP를 위한 universal CLI client다.
   2. 12월 “Winter of Claude” 기간에 취미 프로젝트로 시작했지만, 발표 시점에는 가장 기능이 풍부한 MCP CLI 중 하나로 발전했다.
   3. npm 또는 Bun으로 설치할 수 있다.

3. 프로토콜 호환성

   1. MCP protocol이 제공하는 task, resources, prompts 등 가능한 기능을 폭넓게 지원하는 것이 목표다.
   2. 가볍고 어디서나 실행하기 쉬워야 하며, MCPC 자체에는 LLM이 들어 있지 않다.
   3. MCPC는 프로토콜을 추상화하는 CLI wrapper일 뿐, 판단을 대신하는 에이전트가 아니다.
   4. 에이전트와 사람 모두가 쉽게 사용할 수 있고, code mode를 끝까지 지원해야 한다.

5.2. JSON 조합과 코드 실행

1. 순수 JSON 출력

   1. MCPC의 모든 명령에는 --json 옵션(자막상 D-JSON)을 붙여 MCP specification에 맞는 순수 JSON 표현을 받을 수 있다.
   2. JSON 결과는 코드로 다루기 쉬우므로 jq 같은 도구로 필터링하고 여러 CLI 호출을 pipe로 연결할 수 있다.

2. 컨텍스트 밖의 시퀀스 구성

   1. 여러 도구 호출을 shell script로 조합해 MCP 서버를 백그라운드에서 실행할 수 있다.
   2. 도구 결과를 매번 장황한 자연어 컨텍스트로 되돌리지 않고 JSON 파이프라인으로 처리하므로 컨텍스트 토큰을 낭비하지 않는다.

6. MCPC 시연에서 확인한 기능

6.1. 로컬 MCP 서버 연결

1. 도움말 중심 인터페이스

   1. MCPC는 help를 제공하며, 별도 외부 skill 없이도 에이전트가 곧바로 이해하도록 도움말을 많이 최적화했다.
   2. 도움말 자체가 에이전트가 명령을 점진적으로 발견하는 진입점이다.

2. stdio와 파일 시스템 서버

   1. 로컬 프로세스를 실행하는 stdio 전송을 지원한다.
   2. file system FS라는 로컬 MCP 서버에 연결하면 서버 이름, 프로토콜 capability, 도구, 사용 가능한 명령을 확인할 수 있다.
   3. 파일 시스템 서버의 명령 목록을 일반 텍스트로 보거나 JSON 형식으로 받아 후속 코드에 넣을 수 있다.

6.2. 원격 로그인과 세션 유지

1. 브라우저 인증

   1. 원격 Apify MCP 서버를 사용하려면 먼저 로그인 명령을 실행한다.
   2. 브라우저가 열리면 계정을 선택해 인증하고, 인증 정보는 로컬 운영체제(OS) keychain에 안전하게 저장된다.
   3. 이후 저장된 자격 증명으로 여러 리소스에 안전하게 연결할 수 있다.

2. 서버 지침과 세션

   1. Apify MCP 서버에 연결하면 서버의 기본 정보와 함께 instructions가 표시된다.
   2. MCP protocol에는 서버가 자신의 역할을 설명하는 instructions primitive가 있지만, 대부분의 클라이언트는 이 기본 기능조차 지원하지 않는다.
   3. MCPC는 instructions를 지원하고 도구 목록과 사용 가능한 명령도 확인한다.
   4. 실행 화면에는 세 개의 MCP 세션이 보였고, MCPC는 세션을 유지해 사용자가 자리를 비웠다가 돌아와도 상태를 이어간다.
   5. 한 번 연결·설정한 뒤 Claude Code, Codex 같은 여러 에이전트가 동일한 설정을 공유해 사용할 수 있다.

6.3. Progressive Discovery와 비동기 태스크

1. grep 명령을 통한 도구 검색

   1. MCPC에는 grep 명령이 있어 도구나 서버 설명에서 find 같은 단어를 검색할 수 있다.
   2. 시연에서 FS 파일 시스템 MCP 서버에서는 검색어와 일치하는 도구 세 개, Apify 서버에서는 네 개가 발견됐다.
   3. 모든 도구 정의를 컨텍스트에 넣지 않고 검색 결과만 확인하는 방식으로 progressive discovery를 구현한다.

2. Apify Browser와 비동기 실행

   1. Apify의 regular browser 도구를 실행해 웹 검색을 수행하는 예가 사용됐다.
   2. MCP의 새 기능인 asynchronous task를 사용하면 작업을 서버에서 시작한 뒤 로컬에서 다른 일을 계속할 수 있다.
   3. 백그라운드 작업의 진행 상황을 확인하고 나중에 결과를 가져올 수 있으며, 필요하면 작업을 detach한 뒤 다른 일을 할 수 있다.
   4. 대부분의 MCP 클라이언트가 이 기능을 지원하지 않는 가운데 MCPC는 asynchronous task를 지원한다.
   5. 시연자는 시간이 조금 부족해 작업을 detach하고 상세 프레젠테이션으로 돌아갔다.

6.4. 추가 기능

1. x402 지원

   1. 최근 로컬 지갑을 관리할 도구가 많지 않다는 이유로 x402(자막 인식상 X4/X42) 지원을 MCPC에 추가했다.
   2. MCPC는 x402에 사용할 수 있는 가장 멋진 도구 중 하나라고 평가했다.

2. 프록시와 샌드박싱

   1. MCPC에는 샌드박싱을 위한 proxy 같은 특수 명령도 있다.
   2. 시연에서는 이 기능의 상세한 동작까지는 들어가지 않았다.

7. Connector Evals로 비교한 MCP·MCPC·CLI

7.1. 벤치마크의 관점 전환

1. 기존 eval의 대상

   1. 일반적인 eval과 벤치마크는 서로 다른 에이전트를 비교한다.
   2. 예를 들어 Terminal Bench는 Codex와 Claude Code 중 어느 쪽이 더 나은지 비교한다.

2. Connector Evals의 대상

   1. Connector Evals는 비교 대상을 뒤집어 같은 에이전트가 서로 다른 connector를 사용할 때 성능이 어떻게 달라지는지 측정한다.
   2. CLI, raw MCP, MCPC 등 어떤 도구 연결 방식이 더 효과적인지를 평가한다.
   3. 발표 시점의 테스트는 아직 초기 단계라 추가 검증과 기여가 필요하다.

7.2. 초기 결과

1. 측정 축과 조건

   1. 그래프의 가로축은 작업을 끝내는 데 걸린 시간이다.
   2. 세로축은 사용한 토큰의 비용이다.
   3. 결과는 Claude Code와 Sonnet 5(자막 표기)를 사용한 테스트로 제시됐다.

2. 관찰된 성능 패턴

   1. MCPC와 네이티브 CLI: 두 방식은 작업 완료 시간과 토큰 비용에서 상당히 비슷하게 수행했다.
   2. Raw MCP: 어떤 테스트에서는 raw MCP가 더 빨리 끝났지만 토큰을 더 많이 사용했다.
   3. 반복된 결과: 다른 테스트에서도 MCPC와 CLI는 비교 가능하게 수행했고 raw MCP는 더 나쁜 성능을 보였다.
   4. 해석의 주의점: 표본과 프레임워크가 아직 초기이므로 이 결과를 최종적인 우열 판정으로 받아들여서는 안 된다.

주요 발언 모음

“MCP doesn't suck, your agent does.”

“MCP was a mistake. Long live CLIs.”

“Every MCP could have been a deterministic CLI.”

“MCP sucks honestly.”

“Thank god MCP is dead.”

“Please stop saying CLI is better than MCP because MCP plus CLI is the best.”

• “MCP는 문제가 아니다. 네 에이전트가 문제다”라는 제목은 프로토콜 비판의 초점을 하니스 구현으로 돌리는 압축된 주장이다.
• 결말의 문장은 CLI가 MCP를 대체한다는 구도를 거부하고, MCP와 CLI를 합친 구성이 최선이라는 결론을 강조한다.

핵심 데이터 & 수치

• 약 2년: Anthropic이 MCP를 도입한 뒤 발표 시점까지의 대략적인 기간이다.
• 10,000~15,000개: 언급된 MCP 서버의 대략적인 규모다.
• 10개 서버·100개 도구: 초기 클라이언트가 서버당 10개 도구를 모두 등록하는 예시다.
• 컨텍스트의 약 3분의 1: 질문 전 도구 정의만으로 소모될 수 있다고 제시된 비율이다.
• 한두 개 도구: 실제 작업에서 보통 필요한 도구 수의 예시다.
• 1969년: Ken Thompson과 Dennis Ritchie의 Unix 개발 역사를 설명하며 언급된 연도다.
• 80열·약 25행: 전통적인 터미널의 압축된 화면 크기를 설명하는 예시다.
• 세 개 세션: MCPC 실행 화면에서 확인된 MCP 세션 수다.
• 세 개와 네 개: find 검색 시 FS 서버와 Apify 서버에서 각각 일치한 도구 수다.
• 가로축과 세로축: Connector Evals에서 각각 작업 완료 시간과 토큰 비용을 나타낸다.

결론 및 시사점

1. MCP를 탓하기 전에 하니스를 점검해야 한다: 도구를 전부 미리 등록하고 결과를 계속 컨텍스트에 쌓는 구현이 비용·정확도·보안 문제를 만든다.
2. 서브에이전트는 격리이지 삭제가 아니다: 메인 컨텍스트를 보호하지만 토큰 비용과 민감 정보 보관 문제를 없애지 못한다.
3. Progressive tool discovery를 기본값으로 삼아야 한다: 검색과 필요한 도구만의 로딩은 간단하면서도 즉시 토큰을 절약한다.
4. Code mode가 tool calling의 대안이 될 수 있다: 모델이 이미 잘 아는 코드 탐색과 실행을 통해 도구 정의를 다루면 인공적인 함수 호출 부담을 줄일 수 있다.
5. CLI의 장점은 새로 발명된 것이 아니다: CLI는 원래 점진적으로 실행되고, help로 발견되며, shell code로 호출되는 인터페이스라 code mode와 잘 맞는다.
6. CLI는 원격 표준의 대체물이 아니다: CLI는 내부가 보이지 않는 로컬 블랙박스이므로 기업용 원격 인증·계측·전송에는 MCP가 적합하다.
7. MCP와 CLI를 계층적으로 결합해야 한다: MCP는 remote access와 프로토콜 기능을, CLI와 bash는 local agent access와 실행 조합을 담당하게 한다.
8. MCPC의 핵심 가치는 프로토콜 기능의 보존이다: task, resources, prompts, instructions, 세션, 인증, 비동기 실행을 CLI로 감싸면서 --json, jq, pipe를 제공한다.
9. 초기 Connector Evals는 방향을 제시한다: MCPC와 네이티브 CLI가 비슷한 비용·속도를 보이고 raw MCP가 더 많은 토큰을 쓴다는 결과는 연결 방식도 에이전트 품질의 중요한 변수임을 보여준다.
10. 최종 선택은 MCP 대 CLI가 아니다: MCP의 원격 표준성과 CLI의 로컬·코드 실행성을 결합하는 “MCP plus CLI”가 발표의 최종 제안이다.

별도 Q&A 세션은 없었고, 로컬 FS 서버 연결, Apify 로그인, 도구 검색, 비동기 브라우저 태스크 실행으로 주장을 검증하는 라이브 데모가 진행됐다.

핵심 요약 (20줄)

MCP는 에이전트와 도구·리소스 사이의 안전한 상호작용을 표준화한 프로토콜이다. Anthropic의 도입 이후 MCP는 약 2년 만에 AI 생태계의 사실상 표준으로 확산됐다. 발표 시점에 MCP 서버는 약 1만~1만 5천 개까지 늘어났다. 초기 클라이언트는 사용자가 질문하기도 전에 모든 MCP 도구를 컨텍스트에 등록했다. 10개 서버에서 100개 도구를 미리 넣으면 컨텍스트의 약 3분의 1이 사라질 수 있다. 도구 호출 결과를 컨텍스트에 계속 되돌리면 비용과 지연이 늘고 정확도가 떨어진다. 이 문제의 핵심 원인은 MCP 명세가 아니라 이를 순진하게 구현한 에이전트 하니스다. 서브에이전트는 메인 컨텍스트를 분리하지만 토큰 비용과 민감 정보 노출을 없애지 못한다. Progressive tool discovery는 필요한 순간에 필요한 도구만 찾아 컨텍스트에 추가한다. Code mode는 MCP 도구를 함수 목록이 아니라 모델이 잘 다루는 코드로 취급한다. CLI는 기본적으로 필요한 명령만 점진적으로 실행하므로 progressive discovery가 내장돼 있다. 에이전트는 shell과 CLI를 학습 데이터에서 많이 접해 명령 조합과 pipe 사용에 익숙하다. CLI는 로컬 인터페이스에 강하지만 원격 인증과 계측을 위한 표준 transport가 부족하다. MCP는 표준 원격 접근에 적합하고 CLI는 로컬 에이전트 실행에 적합하다. MCPC는 MCP의 기능을 CLI와 bash 뒤에 감싸는 universal CLI client다. MCPC는 세션·인증·instructions·resources·prompts·태스크를 지원한다. MCPC의 JSON 출력은 jq와 pipe로 도구 호출을 코드와 셸 스크립트로 조합하게 한다. MCPC 시연에서는 FS 서버, Apify 로그인, find 검색, 비동기 Browser 태스크가 작동했다. Connector Evals의 초기 결과에서 MCPC와 네이티브 CLI는 비슷했고 raw MCP는 더 많은 토큰을 사용했다. MCP와 CLI를 경쟁시키기보다 MCP plus CLI 조합을 최선의 에이전트 인터페이스로 삼아야 한다.