Google 엔지니어가 공개했을 때

하지만 잠깐, 왜 CLI 도구를 사용하고 MCP 서버는 사용하지 않았을까요? 요즘은 MCP가 대세입니다. 마치 모두가 MCP 서버를 배포하는 것 같습니다.

MCP, 만병통치약인가?

MCP는 꽤 좋습니다. AI 에이전트가 모든 종류의 관련 컨텍스트를 노출하고 목표 달성을 위해 의미 있는 행동을 취할 수 있게 합니다.

하지만 MCP 패러다임에는 실제적인 문제가 있습니다. 인터넷은 보안 부서에서 다음과 같은 말이 가득합니다: Linux Foundation의

하지만 보안을 넘어, MCP는 에이전트 워크플로우에 통합되는 방식에서 패러다임 자체로 몇 가지 근본적인 한계를 가지고 있습니다.

에이전트 루프

MCP를 에이전트 패러다임의 한계로 이해하려면, 그것이 에이전트 루프 내 어디에 위치하는지 이해해야 합니다.

모델의 CoT(Chain of Thought)가 도구 호출(MCP 도구 포함)을 하고 싶다고 결정하면, 해당 도구 이름과 그를 위해 준비한 인자들을 나타내는 토큰을 방출합니다. 예를 들어, Bash(rm -rf /)

또는 mcp__atlassian__getJiraIssue(...)입니다. 권한 시스템은 별개로, 하네스(harness)가 해당 도구 호출을 실행합니다.

이 두 가지 모두 도구 호출로 실행되지만, Bash 스크립트의 동작은 런타임 매개인 반면, MCP 호출의 동작은 궁극적으로 모델 매개입니다.

사용자께서 말씀하시기에는, 이 두 가지 스타일의 도구 호출 사이에는 제어 평면(control plane) 계층과 데이터 평면(data plane) 계층에서 근본적인 차이가 있습니다.

만약 반복 횟수(iterations)가 다른 명령어의 결과에 따라 동적으로 결정되어야 하고, 각 하위 단계의 출력(예: jq로 파싱)과 조건부 로직을 조작해야 한다면, 문제없습니다. 단일 도구 호출 내부에 이미 튜링 완전한(Turing-complete) 실행 환경이 갖춰져 있기 때문입니다.

AI 모델들은 이 부분에 정말 능숙합니다. 복잡한 워크플로우를 효율적으로 처리하기 위해 종종 임시적이고 여러 줄로 된 스크립트를 단일 턴 내에서 방출(emit)합니다.

하지만 AI 에이전트가 MCP와 상호작용하는 방식은 다릅니다.

• Bash 스크립트의 경우, 추론(reasoning)의 단일 턴 결과는 여러 기본 요소(many API 호출)를 조합하는 복잡한 임시 스크립트를 실행하는 것일 수 있습니다.
• MCP의 경우, 추론의 단일 턴 결과는 오직 하나의 API 호출 또는 기본 요소를 나타내는 단일 MCP 호출을 실행하는 것만 가능합니다.

MCP를 사용하는 에이전트는 동일한 결과를 얻기 위해 1K번의 별도 추론 턴(inference turns)을 실행해야 하며, 각 턴마다 궤도를 유지하고 입력 + 추론 + 출력 토큰을 중복하게 만들어 지연 시간(latency), 컨텍스트 창(context window), 비용을 1K배로 증가시킵니다. 💳

데이터 평면의 한계 (The Data Plane Limitation)

제어 평면(control plane)이 어떤 행동을 취할 의도를 결정하는 반면(그리고 이는 추론 턴당 하나로 제한됨), 데이터 평면은 행동의 내용, 즉 입력 + 출력을 결정합니다.

예를 들어, 로그의 일부를 확인하거나, 특정 용어를 검색하거나, 문서를 읽고 싶다고 가정해 봅시다.

• Bash 스크립트의 경우, 에이전트는 head, tail, grep과 같은 도구들을 자연스럽게 조합하여 실제 출력이 컨텍스트에 도착하기 전에 조작합니다. - 이들은 무엇을 찾는지 알고 있기 때문에 4KiB(또는 더 나쁜 경우 잠재적으로 무한한)의 덩어리 콘텐츠를 컨텍스트 창으로 가져올 필요가 없습니다.

• 그들은 무엇을 찾는지 알기 때문에 4KiB(또는 더 나쁜 경우 잠재적으로 무한한)의 덩어리 콘텐츠를 컨텍스트 창으로 가져올 필요가 없습니다.

• MCP 서버는 종종 모델 매개 조작이나 필터링 기회 없이 방대한 양의 콘텐츠를 출력하여 컨텍스트 창을 폭발시키는 것으로 알려져 있습니다.

• 이론적으로 MCP 서버는 페이지네이션(pagination), 검색(search), 필터링(filtering) 및 타겟팅된 필드 하이드레이션(targeted field hydration)을 구현하도록 API를 설계할 수 있지만, 실제로는 대부분 그렇게 하지 않습니다.

마찬가지로, 프로듀서 측면에서도 이 워크플로우가 있다고 가정해 봅시다:

• 에이전트와 함께 디자인 문서를 작업하고 있습니다.
• 에이전트에게 작업을 수행하여 로컬에 .md 파일로 작성하게 하고, 이를 검토하며 피드백을 기반으로 sed 또는 다른 도구를 사용하여 타겟팅된 편집을 하도록 합니다. 따라서 문서의 특정 섹션을 수정할 때마다(예:

파일 내용을 메인 대화 컨텍스트로 먼저 가져와 모델에 전송한 다음, 이를 기반으로 JSON 형식의 MCP 요청을 추론할 필요가 없습니다. 파일 읽기와 JSON MCP 요청 추론 과정에서 토큰이 전혀 소모되지 않습니다.

작고 목표 지향적인 편집을 반복적으로 수행하고 자주 업로드하는 것이 극도로 효율적입니다.

Google Workspace CLI인 gws는 에이전트와 잘 작동하는 CLI의 모델 예시입니다:

• 정적인 명령어 목록을 배포하는 대신, 런타임에 Google Discovery API를 호출하여 전체 명령어 표면(command surface)을 동적으로 구축합니다.
• Google Workspace가 API를 업데이트하면 gws도 즉시 반영됩니다.
• CLI 인터페이스는 자체 설명적이며 자체 문서화되어 있어 에이전트가 스키마를 인트로스펙션(introspect)할 수 있게 합니다. 이를 통해 사용 가능한 API를 스스로 발견하고, 해당 명령어를 사용하는 방법에 대한 메타데이터까지 파악할 수 있습니다.
• 에이전트에게 이 CLI를 어떻게 사용하는지 가르치는 기술(skills)과 함께 배포됩니다.

이는 기술(Skill)의 문제입니다

MCP는 일반적인 CLI 도구에 비해 여러 장점을 가지고 있습니다.

하나는 MCP가 사용 가능한 도구에 대한 컨텍스트를 모델에게 사전에 자동으로 노출하며, 언제 그리고 어떻게 사용해야 하는지를 알려준다는 점입니다.

• 이러한 명령어 사전 로딩(instruction preloading)의 결과로, 에이전트는 종종 언제 MCP 서버를 사용할지, 어떤 도구를 사용하고 어떻게 사용할지 자동으로 알게 됩니다. 반면 CLI 도구의 경우, 에이전트는 which 명령어로 CLI가 존재하는지 확인하기 위해 애쓰거나, --help 명령어로 사용 방법을 알아내거나, 문서를 검색해야 합니다. - 단점은 컨텍스트 낭비입니다: MCP 서버가 노출하는 모든 도구와 명령어는 사용 여부와 관계없이 컨텍스트로 끌어당겨집니다.

CLI 도구의 발견 가능성(discoverability gap) 중 상당 부분은 적절한 기술을 통해 해결될 수 있습니다. 이 기술들은 에이전트에게 언제 CLI를 사용할지 지시하며, 모델이 필요하다고 판단할 때만 전체 기술 문서가 컨텍스트로 끌어와 모델에게 CLI 사용법을 가르칠 수 있게 합니다.

MCP의 장점

발견 가능성(discoverability)과 명령어 제공(instruction) 외에도, MCP 패러다임은 여러 가지 장점을 가지고 있습니다.

예를 들어, 구현체마다 매우 일관성이 없고 때로는 보안에 취약하게 구현된 인증/인가(authn/authz) 패러다임으로 악명이 높음에도 불구하고, MCP는 외부 시스템 에이전트가 무엇과 상호작용할 수 있는지, 그리고 그 안에서 무엇을 할 수 있는지에 대한 제어권을 중앙 집중화하여 제공할 수 있는 능력을 제공합니다.

결론

MCP는 여전히 매우 유익하며 활발한 개발이 진행 중이고, 생태계가 이를 중심으로 표준화됨에 따라 AI 에이전트는 점점 더 역량을 갖추게 될 것입니다.

하지만 모든 작업에 적합한 패러다임은 아닙니다. 많은 워크플로우의 경우, 소박한 CLI(Command Line Interface)가 저평가되어 있으며 훨씬 더 적합합니다.

MCP를 사용할 때, 모든 도구 호출은 추론 경계(inference boundary)입니다. 만약 에이전트가 N개의 파일을 확인하고, 특정 라인을 필터링하며, DB를 업데이트해야 한다면, N번의 개별 텍스트 생성 턴을 반복해야 합니다. 이는 상당한 지연 시간(latency), 토큰 비용, 그리고 루프 중간에 발생할 수 있는 N×의 환각(hallucination) 위험을 초래합니다.

스크립트를 사용하면 에이전트는 엔지니어처럼 작동합니다. 워크플로우와 데이터 조작을 처리하고 모델에게 보여줄 출력을 구성하는 Bash/Python 스크립트를 작성하며, 모델은 루프 중간에 원시 데이터를