"MCP는 죽어가고 있다" CLI가 AI 에이전트의 표준 도구로 부상...MCP의 한계

AI 에이전트 도구 연결 표준으로 각광받던 MCP, 복잡성·인증 문제로 CLI에 밀린다

[한국정보기술신문] 앤트로픽이 주도한 모델 컨텍스트 프로토콜(MCP)이 등장한 지 1년여 만에 그 실효성에 의문을 제기하는 목소리가 기술 업계에서 나오고 있다. 인프라 엔지니어 에릭 홈스는 지난 2월 28일 'MCP는 죽었다. CLI여 영원하라(MCP is dead. Long live the CLI)'라는 제목의 글을 게재하며, MCP가 실질적인 이점을 제공하지 못하고 있다고 주장해 주목을 받고 있다.

MCP란 무엇인가

MCP는 앤트로픽이 2024년 공개한 오픈 프로토콜로, 대규모 언어 모델(LLM)이 외부 서비스 및 도구와 표준화된 방식으로 통신할 수 있도록 설계됐다. 발표 당시 업계는 큰 관심을 보였고, 수많은 기업이 자사 서비스에 MCP 서버를 탑재하며 'AI 퍼스트' 기업임을 증명하려 했다. 새로운 엔드포인트와 통신 형식, 인증 체계에 막대한 자원이 투입됐다.

홈스는 LLM이 CLI(명령줄 인터페이스) 도구를 이미 매우 잘 활용할 수 있다고 주장한다. LLM은 수백만 건의 매뉴얼 페이지, 스택 오버플로우 답변, 깃허브 스크립트 등을 학습했기 때문에, 별도의 프로토콜 없이도 CLI 명령어를 능숙하게 다룬다는 것이다. 그는 클로드에게 gh pr view 123 같은 명령어를 지시하면 별다른 설정 없이 작동한다고 설명했다.

또한 그는 MCP가 제시하는 '더 깔끔한 인터페이스'의 약속이 실제로는 지켜지지 않는다고 지적한다. MCP를 사용하더라도 각 도구의 기능, 파라미터, 사용 시점 등을 결국 문서화해야 하기 때문에, 프로토콜 자체가 추가적인 이점을 주지 못한다는 것이다.

디버깅과 조합성에서 CLI가 우위

홈스가 강조하는 CLI의 또 다른 강점은 디버깅 용이성과 조합성이다. AI가 도구를 사용하다 오류가 발생할 경우, CLI 환경에서는 사람이 동일한 명령어를 직접 실행해 동일한 결과를 확인할 수 있다. 반면 MCP는 도구가 LLM 대화 내부에만 존재하기 때문에 문제가 생기면 JSON 전송 로그를 일일이 분석해야 한다.

조합성 면에서도 CLI가 우위를 점한다. CLI는 jq, grep 등 기존 도구와 파이프를 통해 자유롭게 연결할 수 있지만, MCP에서는 대용량 데이터를 컨텍스트 창에 통째로 올리거나 MCP 서버 내에 별도 필터링 로직을 구현해야 한다. 대형 테라폼 플랜을 분석하는 사례를 예로 들며, CLI가 더 실용적이고 경제적임을 역설했다.

실사용의 불편함도 지적

홈스는 일상적인 사용 중 겪는 불편함도 열거했다. MCP 서버가 초기화에 실패해 클로드 코드를 재시작해야 하는 경우가 잦고, 여러 MCP 도구를 함께 사용할 경우 도구마다 인증을 반복해야 한다는 점도 문제로 꼽았다. 또한 권한 설정이 도구 이름 단위로만 가능해, CLI처럼 읽기 전용 작업과 쓰기 작업을 세밀하게 구분할 수 없다는 점도 아쉬운 부분으로 지적했다.

반면 CLI는 AWS SSO, 깃허브 로그인, kubeconfig 등 기존에 검증된 인증 방식을 그대로 활용할 수 있어, AI가 구동하는 상황에서도 별도의 문제 없이 작동한다고 그는 설명했다.

MCP가 완전히 무용한 것은 아니다

다만 홈스는 MCP가 전혀 쓸모없다는 극단적인 주장을 펼치지는 않는다. CLI 대안이 없는 도구에 한해서는 MCP가 합리적인 선택일 수 있으며, 표준화된 인터페이스로서 일정한 가치가 있을 수 있다고 인정했다. 실제로 그 역시 선택의 여지가 없을 때는 MCP를 사용한다고 밝혔다.

홈스는 글을 마무리하며 MCP 서버 개발에 투자하고 있지만 공식 CLI가 없는 기업들에게 방향을 재고하라고 촉구했다. 먼저 좋은 API를 출시하고, 그 다음 좋은 CLI를 만드는 것이 우선이라고 강조했다. 그렇게 하면 AI 에이전트가 스스로 방법을 찾아낼 것이라고 덧붙였다. 그의 글은 MCP 열풍이 과연 실질적인 기술 발전을 이끌었는지, 아니면 'AI 퍼스트'라는 트렌드에 편승한 과잉 투자였는지를 되돌아보게 한다.

한국정보기술신문 인공지능분과 김성현 기자 news@kitpa.org