Model Context Protocol: 과잉인가 아니면 에이전트 워크플로우의 미래인가?

Model Context Protocol (MCP)은 그 아키텍처의 필요성에 대해 개발자들 사이에서 논쟁을 불러일으켰습니다. 이 프로토콜의 핵심은 AI 에이전트가 데이터 및 도구와 상호작용하는 방식을 표준화하는 것을 목표로 합니다. 그러나 비판론자들은 명령 발견(command discovery) 및 권한 범위 지정(permission scoping)과 같은 프로토콜이 제공하는 기능이 이미 수십 년 동안 CLI(Command Line Interface)를 통해 해결되어 왔다고 주장합니다.

이러한 긴장은 AI 시대의 근본적인 질문을 던집니다. 새로운 프로세스 계층을 도입함으로써 로컬 환경에 불필요한 복잡성을 추가하고 있는 것일까요, 아니면 MCP가 CLI가 제공할 수 없는 중요한 추상화 계층을 제공하고 있는 것일까요?

CLI 논거: 왜 또 다른 프로세스가 필요한가?

숙련된 많은 개발자들에게 Model Context Protocol은 중복처럼 보입니다. 로컬 머신에서 MCP 프로세스가 확산되는 것에 반대하는 주요 논거는 다음과 같습니다:

• 권한 범위 지정 (Permission Scoping): CLI 명령은 이미 특정 권한으로 범위를 지정할 수 있어, 도구가 시스템에서 수행할 수 있는 작업을 제한할 수 있습니다.
• 발견 가능성 (Discoverability): 표준 --help 플래그와 man pages는 사용자(및 잠재적으로 에이전트)가 명령과 필요한 인자를 발견할 수 있는 강력한 방법을 제공합니다.
• 리소스 오버헤드 (Resource Overhead): 단일 PC에서 수십 또는 수백 개의 별도 MCP 프로세스를 실행하는 것은 불필요한 오버헤드를 생성하고 시스템 불안정성의 잠재적 영역을 넓힙니다.

이러한 관점에서 MCP는 "많은 이점 없이 추가적인 복잡성과 구동 부품을 더하는 것"으로 간주됩니다.

로컬 프로세스를 넘어: 서버 측 MCP

"100개의 프로세스"에 대한 우려에 대한 한 가지 반론은 MCP가 반드시 로컬 실행을 필요로 하지 않는다는 점입니다. 이 프로토콜은 유연하게 설계되어 서버 측 호스팅이 가능합니다.

커뮤니티 구성원들이 언급했듯이, Atlassian과 같은 기업들은 이미 이 방식을 구현하고 있습니다. MCP를 서버 측에서 호스팅하고 Dynamic Client Registration 및 OAuth를 활용함으로써, 조직은 사용자의 로컬 머신에 부담을 주지 않고 도구에 대한 안전하고 인증된 액세스를 제공할 수 있습니다. 이는 oauth2-proxy 및 Nginx를 사용하여 오픈 소스 MCP를 SSO(Single Sign-On) 계층으로 래핑하여 엔터프라이즈 환경에 적합하게 만드는 것을 가능하게 합니다.

상태 관리 및 감사 가능성

CLI는 명령을 실행하고 결과를 받는 데는 탁월하지만, 복잡하고 다단계인 에이전트 워크플로우에 필요한 상태 관리를 해결하지 못합니다.

AI 에이전트가 50단계에 걸친 작업을 수행할 때, 단순한 CLI 호출은 컨텍스트를 쉽게 "롤백"하거나 특정 지점에서 실패했을 때 복사를 복구할 수 없습니다. 이 지점에서 더 구조화된 프로토콜로의 전환이 필수적이게 됩니다. 에이전트 메모리를 위한 Git과 유사한 브랜칭 및 스냅샷 기능의 필요성이 프로세스를 감사 가능하고 복구 가능하게 만드는 핵심 요구사항으로 떠오르고 있으며, 이는 "100개의 프로세스"를 부채가 아닌 구조화되고 관리 가능한 기록 시스템으로 변화시킵니다.

결론

미래가 수백 개의 로컬 MCP 프로세스를 포함할지, 아니면 중앙 집중식 서버 측 아키텍처를 포함할지 여부와 관계없이, Model Context Protocol은 AI를 위한 도구 통합 방식에 대한 우리의 사고방식을 변화시키는 것을 나타냅니다. CLI가 인간 개발자에게는 여전히 강력한 도구이지만, AI 에이전트의 요구사항(특히 상태, 원격 인증 및 표준화된 발견 기능)은 단순한 스크립트 실행을 넘어 진정한 자율적 에이전트 워크플로우로 나아가기 위해 더 공식적인 프로토콜이이 필요할 수 있음을 시사합니다.