1876년 알렉산더 그레이엄 벨이 전화기를 발명했을 때, 사람들은 전보 시스템이 즉시 사라질 것이라 예측했다. 그러나 현실은 달랐다. 전보는 수십 년간 공존하다 전화 인프라가 충분히 성숙한 뒤에야 퇴장했다. 흥미로운 점은 전보가 단순히 “구식”이어서 사라진 게 아니라, 전화라는 새 매체가 인간의 커뮤니케이션 방식에 더 적합했기 때문이라는 것이다. 인간은 글자를 두드리는 것보다 말하는 것이 자연스러운 존재였고, 전화는 그 본성에 부합했다.

지금 AI 에이전트 도구 생태계에서 벌어지고 있는 일도 이와 닮았다. 다만 방향이 정반대다. MCP(Model Context Protocol)는 “새로운 전화기”처럼 화려하게 등장했지만, 정작 에이전트들은 수십 년간 검증된 “전보”, 즉 CLI(Command Line Interface)를 더 능숙하게 다루고 있었다. 새 기술이 구 기술을 대체하는 것이 아니라, 구 기술이 오히려 새로운 소비자에게 더 적합하다는 사실이 드러나고 있는 것이다. 벨의 시대에는 인간이라는 사용자의 본성이 기술 선택을 결정했다. 지금은 에이전트라는 새로운 사용자의 본성이 기술 선택을 다시 뒤집고 있다.

Anthropic이 2024년 11월 MCP를 발표했을 때, 업계는 이를 “AI의 USB-C”라 불렀다. 모든 AI 모델과 모든 도구를 하나의 표준 프로토콜로 연결하겠다는 비전은 매력적이었다. USB-C가 수십 가지 충전 케이블의 혼란을 끝낸 것처럼, MCP도 에이전트-도구 연결의 파편화를 해결할 것이라는 기대였다. 그로부터 약 1년 반이 지난 2026년 3월, 풍경은 사뭇 달라져 있다. “MCP는 죽었다”는 선언이 개발자 커뮤니티를 뒤흔들었고, CLI의 재발견과 Agent-first 설계 철학이 새로운 흐름을 형성하고 있다. 이 변화는 단순한 도구 선호의 문제가 아니다. 소프트웨어 인터페이스 설계의 근본적 재정의가 진행되고 있다.

MCP의 등장, 열광, 그리고 균열

2026년 2월 28일, 인프라 엔지니어 Eric Holmes가 “MCP is dead. Long live the CLI”라는 도발적인 블로그 포스트를 발표했다. 이 글은 Hacker News를 뜨겁게 달궜고, 한국 개발자 커뮤니티 GeekNews에서도 활발히 논의되었다. Holmes의 주장을 한 마디로 요약하면, “MCP는 실질적 이점이 없으며, 없는 편이 나았을 것이다.”

과격해 보이는 주장이지만, 실제 경험에 비추어 보면 이 말에는 상당한 진실이 담겨 있다. 지난 1년간 MCP 생태계를 지켜보면서 느낀 가장 큰 위화감은, 대부분의 MCP 서버가 기존 API에 새 껍데기를 씌운 것에 불과하다는 점이었다. GitHub MCP 서버를 생각해보자. gh pr list 한 줄이면 끝나는 일을 위해 MCP 서버를 띄우고, JSON-RPC로 통신하고, 도구 정의를 컨텍스트 윈도우에 적재해야 한다. AWS 리소스를 조회하는 것도 마찬가지다. aws ec2 describe-instances 한 줄이면 충분한 작업에 MCP라는 중간 계층을 끼워넣는 것이 과연 “진보”인가?

Holmes가 이 글에서 던진 핵심 질문은 단순하지만 날카롭다. “LLM이 이미 접근할 수 있는 서비스에 왜 새로운 엔드포인트와 인증 체계를 추가하는가?” 그는 Anthropic이 MCP를 발표한 후 업계가 집단적으로 이성을 잃었다고 표현하며, 모든 기업이 “AI-first”를 증명하기 위해 앞다투어 MCP 서버를 구축했다고 비판했다. 마치 2000년대 초 닷컴 버블 때 모든 기업이 “.com”을 붙이던 것처럼, 2025년에는 모든 SaaS 기업이 “MCP 서버 지원”을 마케팅에 내세웠다. 하지만 정작 그 MCP 서버들이 하는 일은, 이미 존재하는 REST API를 JSON-RPC로 감싸는 것에 불과한 경우가 대부분이었다.

실제로 AWS MCP 서버를 별도로 설치하지 않아도, Claude Code는 이미 설치된 aws cli를 알아서 찾아 필요한 작업을 수행한다. 에이전트는 MCP라는 번역기 없이도 CLI를 직접 말할 수 있다. 마치 영어를 유창하게 구사하는 사람에게 굳이 통역사를 붙여준 격이다. 통역사가 있으면 오히려 대화가 느려지고, 뉘앙스가 손실되며, 비용만 추가된다.

물론 이 논쟁에는 균형 잡힌 시각도 있었다. “MCP의 이점이 없는 게 아니라, MCP의 이점이 없는 용도에 무차별적으로 사용하던 환상에서 깨어난 것”이라는 반론은 정당하다. SaaS 제품을 만드는 입장에서, CLI가 없는 서비스에 에이전트 접점을 제공하려면 MCP가 합리적 선택일 수 있다는 주장도 일리가 있다. 하지만 이 “무차별적 사용”이야말로 MCP의 본질적 한계를 드러내는 증상이다. 좋은 기술은 오용되더라도 핵심 가치가 훼손되지 않는다. HTTP가 남용된다고 HTTP의 가치가 의심받는가? REST API가 과잉 설계된다고 REST의 원칙이 부정되는가? MCP가 과대 적용되었을 때 그 한계가 즉시 드러났다는 것은, 적용 범위가 생각보다 좁았다는 뜻이다.

MCP의 구조적 문제를 좀 더 깊이 살펴보자.

가장 실무적이고 즉각적인 문제는 토큰 낭비다. LLM은 한 번에 처리할 수 있는 텍스트 분량에 한계가 있는데, 이 한계를 “컨텍스트 윈도우”라 부르고 그 단위를 “토큰”이라 한다. MCP는 연결 시점에 전체 도구 스키마를 이 컨텍스트 윈도우에 적재한다. 이것이 왜 문제인지 비유하자면, 도서관에 가서 책 한 권을 빌리려는데 도서관 전체 서가 목록을 먼저 암기해야 하는 것과 같다. GitHub MCP 하나만 연결해도 수만 토큰이 “배관 공사”에 사라진다. 엔터프라이즈 환경에서 GitHub, 데이터베이스, Jira, Slack의 MCP 서버를 동시에 물리면 어떻게 될까? 도구 정의만으로 컨텍스트의 상당 부분이 소진되어, 에이전트가 정작 추론에 사용할 공간이 부족해지는 본말전도가 발생한다. Jannik Reinhard의 엔터프라이즈 테스트에서는 MCP를 서너 번 도구 호출한 후 컨텍스트 품질이 급격히 저하되어 다중 세션으로 분리해야 했지만, CLI로는 컨텍스트 대부분을 추론에 활용하며 단일 세션으로 완료했다. CLI는 실행 시점에만 토큰을 소비하므로, 사용하지 않는 도구가 컨텍스트를 점유하는 문제가 원천적으로 발생하지 않는다.

보안 문제도 간과할 수 없다. 2025년 4월 Invariant Labs가 발견한 “Tool Poisoning Attack”은 MCP의 구조적 취약성을 적나라하게 드러냈다. 이 공격은 MCP 도구 설명에 악성 명령을 숨기는 방식이다. 에이전트가 도구를 호출할 때, 도구 설명에 포함된 숨겨진 지시를 따라 API 키 등 민감 정보를 외부로 전송한다. 자동 승인이 활성화된 에이전트에서 매우 높은 성공률을 보였다. 이것은 MCP의 신뢰 모델이 가진 근본적 약점이다. MCP는 도구 설명을 신뢰할 수 있다고 가정하지만, 서드파티 MCP 서버의 도구 설명은 누구나 조작할 수 있다. Simon Willison이 지적한 것처럼, 프롬프트 인젝션 문제가 근본적으로 해결되지 않은 상황에서 MCP의 이 신뢰 모델은 위험하다. CLI 도구는 운영체제의 권한 관리 체계 안에서 동작하므로, “도구 설명에 숨겨진 악성 명령”이라는 공격 벡터 자체가 존재하지 않는다. 물론 CLI에도 고유한 위험은 있다. 에이전트가 악의적 프롬프트에 의해 파괴적인 셸 명령을 실행할 가능성이 그것이다. 하지만 이것은 CLI 자체의 구조적 결함이 아니라 에이전트 실행 환경의 격리 문제이며, 컨테이너 샌드박싱이나 권한 제한으로 통제할 수 있다. MCP의 Tool Poisoning은 프로토콜 설계 자체에 내재한 취약점이라는 점에서 성격이 다르다.

인증의 복잡성은 엔터프라이즈 도입의 가장 큰 장벽이다. MCP의 OAuth 2.1 기반 인증 스펙은 이론적으로는 우아하지만 현실과 충돌한다. 엔터프라이즈 아키텍트 Christian Posta는 MCP 인증 스펙의 기업 환경 부적합성을 강도 높게 비판했고, OAuth 2.1 스펙 편집자 Aaron Parecki조차 현실적 한계를 인정했다. 문제의 핵심은 Dynamic Client Registration(DCR)이다. MCP는 클라이언트가 자동으로 등록되는 DCR을 전제하는데, 대부분의 기업은 보안 정책상 익명 클라이언트 등록을 허용하지 않는다. 결국 MCP를 도입하려면 기존 보안 체계를 우회하거나 별도의 인증 인프라를 구축해야 하는데, 이것은 MCP가 약속한 “단순화”와 정반대다. 반면 CLI는 ~/.aws/credentials, gh auth login, kubeconfig 등 수십 년간 검증된 인증 메커니즘을 그대로 사용한다. 독립된 컨테이너 구성을 하면 호스트의 인증 정보를 상속받으므로 별도의 추가 토큰이나 재인증이 불필요하다. 바퀴를 다시 발명할 이유가 없는 것이다.

AI·RPA 아키텍트 Denis Urayev는 2026년 1월 “MCP 표준이 조용히 사라질 수 있는 이유”를 발표했다. 그의 분석에 따르면, MCP는 에이전트가 도구를 다루는 방법을 몰랐던 시절의 산물이다. 에이전트에게 도구 사용법을 구조화된 스키마로 알려주는 것은, 에이전트가 스스로 도구를 탐색하고 학습하는 능력이 부족했을 때 합리적인 접근이었다. 하지만 에이전트의 능력이 급속히 발전하면서, 도구의 man page를 읽고 help 명령을 실행하고 에러 메시지를 해석하여 스스로 사용법을 파악하는 것이 가능해졌다. MCP가 제공하는 구조화된 스키마는 이제 보조 바퀴와 같다. 초보자에게는 필요하지만, 자전거를 탈 줄 아는 사람에게는 오히려 방해가 된다.

CLI가 에이전트의 모국어인 이유

CLI가 에이전트에게 최적의 인터페이스라는 주장은 직관에 반할 수 있다. CLI는 인간에게도 어렵지 않은가? 그래서 GUI가 발명되었고, 웹이 등장했고, 모바일 앱이 나온 것 아닌가? 맞다. 인간에게는 그렇다. 하지만 에이전트는 인간이 아니다. 바로 여기서 패러다임 전환이 시작된다.

인간은 시각적 피드백과 직관적 인터페이스를 선호한다. 마우스로 클릭하고, 드래그하고, 화면에 표시된 버튼을 누른다. 인간의 뇌는 시각 정보 처리에 최적화되어 있기 때문이다. GUI는 인간의 이 인지적 특성에 부합하는 인터페이스다. 하지만 에이전트에게 GUI는 오히려 장애물이다. 에이전트가 GUI를 사용하려면 스크린샷을 찍고, 이미지를 해석하고, 좌표를 계산하여 클릭해야 한다. 이것은 에이전트에게 자연스러운 행위가 아니다. 에이전트는 본질적으로 텍스트를 처리하는 존재다. 입력도 텍스트, 출력도 텍스트, 사고 과정도 텍스트다. CLI는 에이전트의 이 본질적 특성에 정확히 부합하는 인터페이스다.

더 결정적인 것은 LLM의 학습 데이터다. 이 점을 충분히 이해하려면, LLM이 어떻게 훈련되는지를 생각해봐야 한다. 현재의 대형 언어 모델들은 인터넷의 방대한 텍스트로 훈련된다. 그 중 man page, Stack Overflow의 커맨드라인 답변, GitHub의 셸 스크립트, 기술 블로그의 CLI 예시, DevOps 문서의 운영 절차 같은 터미널 관련 콘텐츠는 상당한 비중을 차지한다. 수십억 줄의 이런 텍스트로 훈련된 LLM에게 git commit -m "fix bug", docker build -t myapp ., kubectl get pods -n production 같은 명령은 제2언어가 아니라 모국어에 가깝다.

전 Tesla AI 수장 Andrej Karpathy가 2026년 2월 “CLI는 ‘레거시’ 기술이기 때문에 흥미롭다”고 말한 것은 역설이 아니라 정확한 관찰이다. “레거시”란 곧 오래되었다는 뜻이고, 오래되었다는 것은 훈련 데이터에 풍부하게 존재한다는 뜻이며, 풍부한 훈련 데이터는 곧 높은 수행 능력을 의미한다. 반면 MCP는 2024년 11월에 등장한 신생 프로토콜이다. LLM의 훈련 데이터에 MCP 관련 콘텐츠는 거의 없다. 에이전트가 MCP 도구를 사용하려면 매번 스키마를 읽고 해석해야 하지만, CLI 도구는 이미 “알고 있는” 것이다. gh pr view 123 같은 명령을 Claude에게 시키면 아무런 추가 설명 없이 그대로 동작한다. 별도의 스키마 정의도, 프로토콜 학습도 필요 없다.

CLI의 조합성(composability)은 MCP가 구조적으로 따라올 수 없는 영역이다. 한 가지 일을 잘하는 작은 프로그램들을 파이프로 연결한다는 유닉스 철학의 핵심은 에이전트의 작업 방식과 놀랍도록 일치한다. 에이전트는 복잡한 작업을 작은 단계로 분해하고, 각 단계의 결과를 다음 단계의 입력으로 전달하는 방식으로 사고한다. 이것은 정확히 유닉스 파이프의 동작 방식이다.

terraform show -json plan.out | jq '.resource_changes[] | select(.change.actions | contains(["delete"]))'를 예로 들어보자. 인프라 변경 계획에서 삭제될 리소스만 필터링하는 이 명령은, 두 개의 독립적인 도구(terraform과 jq)를 파이프로 연결한 것이다. MCP로 같은 작업을 하려면 “Terraform 계획 조회” 도구와 “JSON 필터링” 도구를 별도로 정의하고, 두 도구 간의 데이터 전달을 MCP 프로토콜로 중개해야 한다. 가능은 하지만, 복잡성과 토큰 비용이 불필요하게 증가한다. CLI에서는 이미 존재하는 도구들을 파이프 기호 하나로 연결하면 그만이다.

디버깅의 용이성도 간과할 수 없는 이점이다. 소프트웨어 개발에서 “디버깅은 코딩보다 두 배 어렵다”는 격언이 있다. 에이전트가 작업을 수행할 때도 문제는 반드시 발생하고, 문제를 진단하고 해결하는 능력은 생산성을 결정한다. MCP에서 문제가 발생하면, 도구 호출이 LLM 대화 내부에 숨어 있기 때문에 JSON-RPC 전송 로그를 뒤져야 한다. 어떤 파라미터로 어떤 도구가 호출되었는지, 응답이 어떻게 왔는지를 추적하려면 별도의 디버깅 도구가 필요하다. CLI에서는 에이전트가 실행한 정확히 그 명령을 터미널에 복사·붙여넣기하면 재현이 끝난다. 인간 개발자와 에이전트가 동일한 도구, 동일한 명령어, 동일한 출력 포맷을 공유하므로 협업이 자연스럽다. 에이전트가 무엇을 했는지 이해하기 위해 별도의 “번역” 과정이 필요 없다는 것은, 실무에서 엄청난 시간 절약이다.

운영 안정성 측면에서도 CLI의 우위는 명확하다. CLI 도구는 디스크 위의 바이너리일 뿐이다. 호출하면 실행되고, 결과를 반환하면 종료된다. 상태를 유지하지 않고, 백그라운드 프로세스가 필요 없으며, 연결이 끊어질 걱정도 없다. 반면 MCP 서버는 백그라운드에서 계속 실행되어야 한다. 서버 프로세스의 생명주기를 관리해야 하고, 비정상 종료 시 복구 로직이 필요하며, 메모리 누수를 감시해야 한다. 실제로 MCP 서버가 생성하고 정리하지 않은 좀비 Node.js 프로세스가 수십 개씩 쌓이는 것은 농담이 아니라 실무에서 흔히 발생하는 문제다. OpenClaw이 Docker 컨테이너 내에서 에이전트에 전체 터미널 접근을 부여하며 파괴적 작업만 인간 승인을 요구하는 방식을 채택한 것은, 이런 운영 현실을 반영한 설계다.

그렇다면 MCP는 완전히 쓸모없는가? 그렇게 보기는 어렵다. 데이터베이스 커넥션을 유지하면서 여러 쿼리를 순차 실행하는 것처럼 상태를 유지해야 하는 장기 작업에서는 MCP의 상태 관리가 유용하다. 구조화된 보안 감사가 필요한 엔터프라이즈 환경에서 모든 도구 호출을 로깅하고 감사하는 데는 MCP의 중앙화된 프로토콜이 유리하다. ChatGPT 웹 인터페이스처럼 셸 접근이 불가능한 웹 기반 클라이언트에서 외부 도구를 사용하는 경우에는 MCP가 사실상 유일한 선택지다.

여기서 제안하는 원칙은 간단하다. “CLI-first, 선택적 MCP.” CLI가 존재하는 서비스라면 CLI를 우선 사용하고, CLI가 없거나 상태 관리가 필수적인 경우에만 MCP를 채택하라. “MCP를 설치할 것인가?”가 아니라 “CLI가 이미 있는가?”를 먼저 물어야 한다. 이것이 2026년 초 에이전트 개발자 커뮤니티가 실무적 경험을 통해 도달한 합의다.

Agent-first 설계의 선두주자들

MCP vs CLI 논쟁이 개발자 커뮤니티에서 뜨겁게 달궈지는 동안, 이미 업계의 주요 기업들은 한발 더 나아가 Agent-first 설계를 제품에 구현하고 있었다. 이론적 논쟁보다 실제 제품의 변화가 더 많은 것을 말해준다. 특히 Google과 Vercel의 행보는 Agent-first 전환의 속도와 방향을 가장 잘 보여주는 사례다.

가장 인상적인 사례는 Google의 gws(Google Workspace CLI)다. 2026년 3월, Google Developer Relations의 Justin Poehnelt가 공개한 이 Rust 기반 CLI 도구는 Agent-first 설계의 교과서라 할 만하다. 여기에는 흥미로운 배경이 있다. gws 등장 직전까지 커뮤니티에서는 Peter Steinberger가 만든 gog이라는 Google Workspace CLI 도구가 주목받고 있었다. Steinberger는 기존 Google API를 CLI로 깔끔하게 감싸 Claude Code 같은 에이전트가 Google Workspace를 조작할 수 있게 만들었고, 개발자들 사이에서 호평을 받고 있었다. 그런데 불과 며칠 만에 Google 공식 조직에서 gws가 나온 것이다. Steinberger 자신도 “gog은 인간 터미널 사용에, gws는 AI 에이전트 통합에 더 적합할 것”이라는 반응을 보였다. 이 에피소드는 Agent-first CLI에 대한 수요가 커뮤니티 도구를 넘어 플랫폼 기업의 공식 전략으로 격상되었음을 보여준다.

gws의 설계에서 가장 주목할 점은 동적 명령 생성(Dynamic Command Generation)이다. 기존 CLI 도구들은 지원하는 명령을 코드에 정적으로 내장한다. 새로운 API가 추가되면 CLI도 업데이트해야 한다. gws는 이 패러다임을 뒤집었다. Google Discovery Service를 런타임에 읽어 전체 명령 체계를 자동 구축한다. Google이 새 API 엔드포인트를 추가하면 CLI 업데이트 없이 즉시 반영된다. 이것은 에이전트 관점에서 혁명적이다. 에이전트가 항상 최신 API에 접근할 수 있고, 도구 정의를 수동으로 관리할 필요가 없기 때문이다. 마치 사전이 자동으로 업데이트되는 것과 같다. 새 단어가 추가될 때마다 사전을 다시 구입할 필요가 없는 것이다.

Poehnelt의 설계 철학은 명확하다. “첫날부터 AI 에이전트가 모든 명령, 모든 플래그, 모든 바이트의 주요 소비자가 될 것이라는 전제 하에 설계했다.” 이 한 문장이 Agent-first의 정수다. 이 철학은 구체적인 기술적 선택으로 이어졌다. 100개 이상의 SKILL.md 파일이 포함되어, “변경 작업 전 반드시 --dry-run을 사용하라”, “대량 삭제 시 확인 프롬프트를 건너뛰지 마라” 같은 에이전트가 직관적으로 파악할 수 없는 안전 규칙을 구조화된 형태로 제공한다. 이것은 에이전트의 환각(hallucination)을 전제한 방어적 설계다. 에이전트가 “이 파일을 삭제해도 될 것 같다”고 환각을 일으키더라도, SKILL.md에 인코딩된 규칙이 안전장치 역할을 한다.

입력값 검증에서도 이 철학이 관철된다. 경로 탐색(../../.ssh) 차단, 제어 문자 거부, 이중 URL 인코딩 방지 등은 인간 사용자를 위한 CLI에서는 굳이 필요하지 않은 보호 장치다. 인간은 ../../.ssh를 입력하면 그것이 무엇을 의미하는지 안다. 하지만 에이전트는 악의적 프롬프트에 의해 이런 위험한 입력을 생성할 수 있다. gws는 이런 시나리오를 미리 차단한다. --tool-mode compact 옵션으로 노출 도구를 수백 개에서 약 26개로 축소할 수 있어 컨텍스트 윈도우를 절약하는 것도 같은 맥락이다. 인간은 수백 개의 명령 목록을 참고서처럼 펼쳐놓을 수 있지만, 에이전트에게는 그 목록 자체가 토큰을 소비하는 비용이다.

Vercel의 행보도 주목할 만하다. 2026년 2월 발표된 콘텐츠 협상(Content Negotiation) 기능은 기술적으로는 단순하지만 함의는 심대하다. HTTP Accept 헤더를 통해 에이전트가 마크다운을 요청하면, HTML/CSS/JavaScript 대신 순수 마크다운을 반환한다. 일반적인 블로그 포스트가 HTML로 수백 KB에 달하는 반면 마크다운으로는 수 KB에 불과하다. 네트워크 사용량이 극적으로 절감되고, 이는 곧 토큰 소비의 극적인 감소를 의미한다.

이 접근에서 주목할 것은 기술 자체보다 그 함의다. Vercel은 별도의 프로토콜이나 SDK를 만들지 않았다. 이미 수십 년간 존재해온 HTTP 표준의 콘텐츠 협상 메커니즘을 그대로 활용했다. Claude Code가 Accept: text/markdown, text/html, */* 헤더를 보내면 서버가 마크다운을 반환하는 것, 이것이 전부다. URL에 .md 접미사를 붙이는 것도 가능하다. 새로운 프로토콜을 발명하는 대신 기존 표준을 활용하는 이 접근은, MCP가 왜 과잉이었는지를 역설적으로 보여준다. 기존 인프라에 이미 에이전트 최적화의 도구가 있었는데, 우리는 그것을 보지 못하고 새로운 프로토콜을 만들어낸 셈이다.

Cloudflare도 유사한 “Markdown for Agents” 기능을 출시하며 동일한 방향으로 움직이고 있다. 에이전트가 웹 페이지를 읽을 때 HTML 전체를 파싱하는 대신 핵심 콘텐츠만 마크다운으로 받을 수 있게 한 것이다. Vercel과 Cloudflare라는 웹 인프라의 두 거인이 동시에 같은 방향으로 움직이고 있다는 사실은, Agent-first가 일시적 트렌드가 아니라 구조적 전환임을 시사한다.

Vercel CEO Guillermo Rauch는 Sequoia Capital 팟캐스트에서 “미래의 고객은 인간만큼이나 AI 에이전트가 될 것”이라며, “에이전트는 그 자체로 독립적인 모달리티”라고 선언했다. 이 말은 수사가 아니다. Vercel은 실제로 llms.txt 파일, AGENTS.md, 40개 이상의 에이전트 스킬, MCP 서버 등 종합적인 에이전트 리소스 생태계를 이미 구축했다. “2026년은 Skills와 CLI의 해”라는 Rauch의 트윗은, Vercel이 자사의 미래를 에이전트 플랫폼에 걸고 있음을 보여준다.

한편 2025~2026년 사이 모든 주요 AI 기업이 CLI 도구를 출시하며 AI CLI 4강 체제가 형성되었다. Anthropic의 Claude Code, Google의 Gemini CLI, Microsoft의 GitHub Copilot CLI, OpenAI의 Codex CLI가 그것이다. 이 네 도구는 경쟁하면서도 하나의 공통 메시지를 전달한다. CLI가 에이전트의 주 인터페이스라는 것이다.

각 도구의 차별화 전략도 흥미롭다. Claude Code는 Agent Teams(다중 에이전트 협업), 백그라운드 에이전트, 세션 텔레포테이션(/teleport으로 CLI와 웹 간 전환) 등 에이전트 간 협업과 인간-에이전트 상호작용에서 앞서 있다. Gemini CLI는 오픈소스와 무료 사용이라는 파격적 전략으로 GitHub 스타 8만 개 이상을 기록하며, Google 계정만 있으면 누구나 쓸 수 있다는 접근성으로 빠르게 성장하고 있다. Copilot CLI는 2026년 2월 GA를 달성하며 Autopilot 모드(완전 자율 실행)와 Fleet(다중 에이전트 병렬 워크플로우)을 제공한다. Codex CLI는 한 개발자가 7개 인스턴스를 동시에 실행하여 게임의 여러 모듈을 병렬로 개발한 사례가 보고될 정도로 병렬 작업에 강점이 있다.

주목할 점은 이 네 도구 모두 MCP 서버를 지원하면서도 CLI 우선 접근을 채택하고 있다는 것이다. MCP를 완전히 폐기한 것이 아니라, CLI를 기본으로, MCP를 보조로 배치했다. 에이전트는 기본적으로 터미널에서 CLI를 실행하고, CLI가 없는 서비스에 한해 MCP를 확장 메커니즘으로 사용한다. 앞서 제안한 “CLI-first, 선택적 MCP” 원칙이 이미 업계 표준으로 자리 잡고 있는 셈이다.

Human-first에서 Agent-first로, 소프트웨어의 재정의

이 모든 변화를 관통하는 하나의 질문이 있다. 소프트웨어의 일차적 소비자가 인간인 시대는 끝나가고 있는가?

데스크톱에서 웹으로, 웹에서 모바일로 소프트웨어 인터페이스의 패러다임은 이미 두 번의 대전환을 겪었다. 각각의 전환은 소프트웨어 산업 전체를 재편했다. 웹 전환기에 적응하지 못한 기업은 도태되었고, 모바일 전환기에 “모바일 퍼스트”를 선언한 기업이 승리했다. 지금 진행되고 있는 것은 세 번째, 아니 어쩌면 가장 근본적인 전환이다. 이전의 전환들은 모두 “인간이 소프트웨어를 사용하는 방식”의 변화였다. 데스크톱 앱에서 웹 브라우저로, 브라우저에서 모바일 앱으로 이동했을 뿐, 사용 방식은 바뀌었지만 사용 주체는 항상 인간이었다. 이번에는 “소프트웨어를 사용하는 주체 자체”가 바뀌고 있다.

Cloudflare의 2025년 연례 보고서에 따르면 봇 트래픽이 HTML 페이지 요청의 절반 이상을 차지하며 인간 트래픽을 넘어섰다. 웹사이트 방문자의 과반이 이미 인간이 아닌 것이다. 이것은 미래의 예측이 아니라 현재의 사실이다. 그리고 이 비율은 에이전트의 능력이 향상되고 비용이 감소함에 따라 빠르게 확대되고 있다. Gartner는 2026년 말까지 엔터프라이즈 애플리케이션의 상당수가 빌트인 AI 에이전트를 보유할 것으로 예측한다.

프로토콜 표준화도 이 전환을 반영하며 세 축으로 진행되고 있다. Anthropic의 MCP는 2025년 12월 Linux Foundation의 Agentic AI Foundation에 기부되어 OpenAI, AWS, Google, Microsoft 등이 참여하는 범산업 표준으로 발전하고 있다. 비판에도 불구하고, MCP가 “에이전트-도구 통신”이라는 문제 영역을 정의하고 공론화한 공로는 인정해야 한다. MCP 이전에는 각 에이전트가 각자의 방식으로 도구를 호출했고, 이에 대한 표준화된 논의 자체가 부재했다. MCP는 그 논의의 출발점을 제공했다.

Google의 A2A(Agent-to-Agent Protocol)는 에이전트 간 수평 통신이라는 또 다른 문제를 다룬다. MCP가 에이전트와 도구 사이의 수직적 연결이라면, A2A는 에이전트와 에이전트 사이의 수평적 대화를 표준화한다. 코딩 에이전트, 테스트 에이전트, 배포 에이전트가 순차적으로 협력하는 것처럼 복수의 에이전트가 협업하여 복잡한 작업을 수행하는 시나리오에서 A2A가 필요해진다.

2026년 2월에는 Chrome 146 Canary에 WebMCP가 내장되어, 웹 페이지가 AI 에이전트의 구조화된 도구로 직접 기능하기 시작했다. 브라우저가 단순한 “웹 페이지 렌더러”에서 “에이전트-웹 인터페이스”로 진화하고 있는 것이다. llms.txt 표준도 빠르게 확산되고 있다. 사이트의 핵심 콘텐츠를 마크다운으로 제공하는 이 단순한 규약을 수십만 개의 웹사이트가 구현했다. 재미있는 것은 Google이 이를 “키워드 메타태그의 재림”이라며 거부한 반면, Vercel은 “신규 가입의 10%가 ChatGPT를 통해 유입된다”며 실질적 효과를 주장하고 있다는 점이다. 에이전트 친화적 웹의 가치를 둘러싼 이 시각 차이는, 아직 업계가 Agent-first 전환의 초기 단계에 있음을 보여준다.

이 전환의 핵심 교훈은 특정 기술의 승패가 아니다. MCP냐 CLI냐의 이분법이 아니라, “소프트웨어를 설계할 때 누구를 일차적 소비자로 상정하는가”라는 더 근본적인 물음이다. gws가 에이전트의 환각을 전제하고 방어적 입력 검증을 설계에 내장한 것, Vercel이 HTTP 콘텐츠 협상으로 에이전트 전용 응답을 제공하는 것, AI CLI 4강이 모두 컨테이너 격리와 병렬 실행을 기본 기능으로 채택한 것이 모두 같은 방향을 가리킨다. 소프트웨어의 설계 기준점이 “인간에게 편리한가”에서 “에이전트가 효율적으로 사용할 수 있는가”로 이동하고 있다.

2010년대 “모바일 퍼스트”를 선언한 기업들이 스마트폰 혁명의 승자가 되었듯, 2026년 “에이전트 퍼스트”를 내면화하는 기업들이 다음 시대의 승자가 될 것이다. 이것은 MCP를 버리고 CLI를 채택하라는 단순한 기술 조언이 아니다. 소프트웨어의 사용자가 인간만이 아닌 세상에서, 인터페이스를 어떻게 설계할 것인가에 대한 근본적 사고의 전환이다.

결국 에이전트는 스스로 도구를 선택했다. 화려한 신규 프로토콜이 아니라, 수십 년간 검증된 CLI였다. Holmes의 선언이 촉발한 논쟁의 핵심 교훈은 MCP의 폐기가 아니라, 소프트웨어의 소비자가 달라졌다는 사실의 인정이다. 인간을 위해 설계된 GUI도, 인간을 위해 설계된 MCP도, 에이전트의 본성에는 맞지 않았다. 에이전트에게는 텍스트 입출력, 파이프 조합, 기존 인증 체계의 재사용이 가능한 CLI가 가장 자연스러운 언어였다.

Rauch의 표현대로 “2026년은 Skills와 CLI의 해”다. 좋은 API를 만들고, 좋은 CLI를 출시하라. 에이전트가 알아서 활용할 것이다. 벨의 시대에 전보가 전화에 자리를 내준 것은 인간의 본성 때문이었다. 지금 CLI가 돌아온 것은 에이전트의 본성 때문이다. 당신의 소프트웨어는 아직 인간만을 위해 설계되어 있는가?

참고 자료