매일같이 "MCP 연결했더니 AI가 진짜 뭐든지 다 해준다"는 말을 듣다가, 갑자기 "MCP는 죽었다, CLI 만세"라는 이야기가 들려오면 당연히 혼란스럽다. 도대체 MCP가 뭐고, CLI는 또 뭔데, 바이브코딩을 하려는 입장에서 어느 쪽을 써야 하는가? 이 질문에 명확히 답하려면 MCP가 어디서 왜 태어났는지부터 이해해야 한다.
이 혼란은 2025년 내내 개발자 커뮤니티를 뜨겁게 달궜고, 2026년 2월 말 Eric Holmes라는 개발자가 자신의 블로그에 "MCP is dead, long live the CLI(MCP는 죽었다, CLI여 영원하라)"는 도발적인 글을 올리면서 정점에 달했다. 그렇다면 실제로 MCP는 죽었을까? 아니면 CLI가 과대평가된 걸까? 진실은 훨씬 더 복잡하고, 더 실용적이다.
이 글에서는 MCP의 탄생 배경과 1년간의 진화 과정, CLI와의 핵심 차이, 그리고 바이브코딩을 하는 사람이라면 반드시 알아야 할 상황별 선택 기준을 데이터와 사례를 통해 명확하게 설명한다.
바이브코딩이란 무엇인가 - 코딩의 민주화가 시작된 날
모든 이야기는 2025년 2월로 거슬러 올라간다. 테슬라와 OpenAI 출신의 저명한 AI 연구자 안드레이 카르파티(Andrej Karpathy)가 X(구 트위터)에 짧은 글 하나를 올렸다. 그가 붙인 이름은 "바이브 코딩(Vibe Coding)"이었다.
카르파티의 정의는 간단하면서도 혁명적이었다. "나는 LLM 같은 AI에게 문제 해결을 완전히 맡기고, 코드는 아예 보지 않으며, 그냥 코드가 실행되길 바란다." 즉, 사람은 큰 그림과 직관(vibe)을 담당하고, AI가 나머지 구체적인 코드 작성을 전부 처리하는 개발 방식이다. 더 직관적으로 말하면, 자연어로 내가 원하는 것을 말하면 AI가 코드를 만들어 주는 것이다.
이 개념은 즉시 폭발적인 반응을 불러일으켰다. 비개발자도 앱을 만들 수 있다는 소프트웨어 개발의 민주화가 현실이 된 것이다. 콜린스 영어사전은 2025년 11월 "바이브 코딩"을 올해의 단어로 선정하기도 했다. 단어가 탄생한 지 불과 9개월 만의 일이다.
바이브코딩의 핵심 도구들은 빠르게 성장했다. Claude Code(Anthropic의 CLI 기반 AI 코딩 도구), Cursor(VS Code 기반 AI 편집기), Lovable, Bolt.new 등이 대표적인 바이브코딩 플랫폼으로 자리 잡았다. 그리고 이 도구들의 중심에는 AI가 외부 세계와 통신하는 방식, 즉 MCP와 CLI 문제가 자연스럽게 떠올랐다.
** 바이브코딩은 코딩을 '완전히 모르는 사람'만을 위한 것이 아니다. 오히려 숙련된 개발자가 반복적이고 소모적인 작업은 AI에게 위임하고, 자신은 아키텍처 설계와 문제 해결에 집중하는 방식으로 가장 강력한 효과를 발휘한다.
MCP란 무엇인가 - AI의 USB 포트가 탄생하다
탄생 배경: AI는 왜 갇혀 있었나
2024년 이전, AI 모델들은 본질적으로 "고립된 천재"였다. ChatGPT나 Claude에게 "내 회사 데이터베이스에서 이번 달 매출을 가져와줘"라고 하면, AI는 그렇게 할 방법이 없었다. 매번 새로운 연결 방식을 커스텀으로 개발해야 했고, GitHub 연동을 위한 코드, Slack 연동을 위한 코드, 데이터베이스 연동을 위한 코드가 전부 따로따로였다. 마치 각 기기마다 다른 충전 방식이 있던 시절처럼 파편화되어 있었다.
Antropic의 엔지니어들은 이 문제를 근본적으로 해결하고 싶었다. 그 결과가 바로 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)다.
MCP의 공식 탄생: 2024년 11월 25일
2024년 11월 25일, Anthropic은 MCP를 오픈소스로 공개했다. 공식 정의는 "AI 어시스턴트와 데이터 소스, 비즈니스 도구, 개발 환경을 연결하기 위한 새로운 표준"이다. 쉽게 말하면, AI와 외부 도구 사이의 표준화된 USB 포트를 만든 것이다.
USB가 등장하기 전에는 프린터, 마우스, 키보드마다 다른 포트가 필요했다. USB가 등장하자 모든 기기를 하나의 표준 방식으로 연결할 수 있게 됐다. MCP는 AI와 외부 도구의 관계에서 바로 그 USB의 역할을 한다.
MCP 공개와 함께 Anthropic은 Google Drive, Slack, GitHub, Git, PostgreSQL, Puppeteer 등을 위한 사전 구축된 MCP 서버를 오픈소스로 즉시 공개했다. Block, Apollo, Zed, Replit, Codeium, Sourcegraph가 초기 파트너로 참여했다.
MCP의 구조: 세 가지 역할자가 만드는 생태계
MCP는 세 가지 구성 요소가 함께 작동한다.
MCP 호스트(Host)는 사용자가 직접 쓰는 AI 애플리케이션이다. Claude Desktop, Claude Code, ChatGPT, Cursor 같은 것들이 여기에 해당한다. 호스트는 여러 MCP 클라이언트를 관리하고 조율하는 역할을 한다.
MCP 클라이언트(Client)는 호스트 내부에서 동작하며 각 MCP 서버와 1:1로 연결되는 중개자다. 호스트가 원하는 것을 서버에 전달하고, 서버의 응답을 다시 호스트에게 가져다주는 통역관이라고 보면 된다.
MCP 서버(Server)는 실제 외부 서비스(GitHub, Slack, DB 등)와 연결된 서버다. 외부 시스템의 기능을 MCP 표준 방식으로 AI에게 노출한다. 예를 들어 GitHub MCP 서버는 AI가 "저장소의 최근 커밋 목록을 보여줘"라고 하면 GitHub API를 호출해 그 결과를 표준화된 형태로 돌려준다.
** MCP 서버는 AI가 실제 파일 시스템 접근, 코드 실행, 외부 API 호출 등 강력한 작업을 수행할 수 있게 해준다. 신뢰할 수 없는 출처의 MCP 서버를 설치하면 보안 문제가 발생할 수 있으므로, 반드시 공식 또는 검증된 MCP 서버만 사용해야 한다.
MCP 1년간의 진화 - 내부 실험에서 산업 표준으로
폭발적 성장: 6개 파트너에서 10,000개 서버로
MCP 출시 후 커뮤니티의 반응은 예상을 훨씬 뛰어넘었다. 2025년 2월까지 커뮤니티가 구축한 MCP 서버는 이미 1,000개를 돌파했고, 2025년 10월 기준으로는 6,000개 이상이 등록됐다. 2025년 말에는 일부 MCP 마켓플레이스에서 16,000개 이상의 서버를 집계하기도 했다.
아래 표는 MCP 출시 시점과 1년 후의 주요 변화를 보여준다.
| 항목 | 2024년 11월 (출시) | 2025년 12월 (1년 후) |
|---|---|---|
| 전송 방식 | stdio, HTTP+SSE | 추가: Streamable HTTP |
| 인증 방식 | 사양에 미포함 | OAuth 2.1 + PKCE 공식화 |
| 생태계 규모 | 초기 파트너 6개사 | 10,000개 이상 MCP 서버 |
| 주요 채택사 | Anthropic 단독 | OpenAI, Google, Microsoft, AWS |
| 거버넌스 | Anthropic 단독 소유 | Linux Foundation AAIF 기증 |
| 보안 | 기본 없음 | OAuth 2.1 인증 공식 사양 |
핵심 마일스톤 타임라인
2024년 11월 25일 - Anthropic이 MCP를 오픈소스로 공개. Google Drive, Slack, GitHub 등 주요 MCP 서버 함께 공개.
2025년 3월 26일 - 가장 결정적인 순간이 왔다. OpenAI CEO 샘 알트만(Sam Altman)이 X에 "사람들은 MCP를 매우 좋아하고 있으며, 전반적인 제품군에 MCP 지원을 추가하게 되어 매우 기대하고 있습니다"라고 공개 지지를 선언했다. 경쟁사가 상대방의 프로토콜을 채택한 것은 사실상 MCP의 업계 표준 지위를 공식화한 사건이었다. 동시에 Streamable HTTP 전송 방식 사양이 공개되어 원격 MCP 서버 시대가 열렸다.
2025년 5월 22일 - Anthropic이 MCP Connector, Code Execution Tool, Files API, Extended Prompt Caching 4가지 신기능을 발표. 특히 Code Execution과 MCP를 결합하면 토큰 사용량을 최대 98.7% 절감할 수 있다는 충격적인 수치가 공개됐다.
2025년 6월 18일 - OAuth 2.1 기반 인증 사양이 공식화. 기업 환경에서 MCP를 안전하게 사용할 수 있는 표준이 마련됐다.
2025년 9월 - ChatGPT가 MCP 완전 지원을 발표. 이제 Claude, ChatGPT, Gemini 어디서든 동작하는 AI 도구를 MCP 하나로 구축할 수 있게 됐다.
2025년 12월 9일 - Anthropic이 MCP를 Linux Foundation 산하 Agentic AI Foundation(AAIF)에 기증. Anthropic, Block, OpenAI가 공동으로 AAIF를 설립하고, Google, Microsoft, AWS, Cloudflare가 플래티넘 멤버로 참여했다. MCP가 이제 특정 기업의 기술이 아닌 오픈소스 업계 공용 표준이 된 것이다.
** MCP가 Linux Foundation에 기증됐다는 것은 단순한 행정 절차가 아니다. Linux 커널이나 Kubernetes처럼 중립적인 거버넌스 체계 아래서 오랫동안 안정적으로 유지·발전할 것이라는 신호다. 특정 기업의 이해관계에 따라 갑자기 바뀌거나 사라질 위험이 크게 줄어든 것이다.
CLI란 무엇인가 - AI의 오래된 친구
CLI(Command Line Interface, 명령줄 인터페이스)는 마우스 클릭 없이 키보드로 명령어를 입력해 컴퓨터를 제어하는 방식이다. 개발자라면 매일 쓰는 터미널 창, 그 검은 화면에 git commit -m "fix bug" 같은 명령어를 입력하는 것이 바로 CLI다.
바이브코딩 맥락에서 CLI가 주목받는 이유는, AI 코딩 에이전트들이 이미 CLI를 매우 잘 활용하기 때문이다. Claude Code, Gemini CLI, OpenAI Codex CLI 같은 도구들은 터미널에서 직접 AI와 대화하며 코딩 작업을 수행한다. 이 도구들은 MCP 없이도 git, docker, npm, kubectl 같은 수천 개의 CLI 명령어를 능숙하게 사용할 수 있다.
왜 AI가 CLI를 잘 쓸까? 이유는 간단하다. AI 모델들은 Stack Overflow 답변, GitHub 저장소, 기술 문서, 튜토리얼 등 수십억 줄의 터미널 상호작용 데이터로 학습됐기 때문이다. git log --oneline -10이 최근 10개의 커밋을 보여준다는 것을 AI는 이미 깊이 학습되어 있다. 별도의 스키마 설명 없이도 바로 쓸 수 있는 것이다.
MCP vs CLI 핵심 비교 - 무엇이 다른가
MCP와 CLI를 가장 선명하게 비교할 수 있는 것은 토큰 소비량이다. 토큰은 AI가 처리하는 텍스트 단위로, 많을수록 비용이 높아지고 남은 컨텍스트 공간이 줄어든다.
2026년 2월, 한 엔지니어가 실제 기업 업무(Microsoft Intune 디바이스 규정 준수 자동화)에서 MCP와 CLI 방식을 비교한 결과가 개발자 커뮤니티에 큰 반향을 일으켰다.
| 단계 | MCP 방식 토큰 비용 | CLI 방식 토큰 비용 |
|---|---|---|
| 도구 스키마 로딩 | 약 28,000 토큰 | 0 토큰 |
| 에이전트 추론 및 도구 선택 | 약 3,200 토큰 | 약 800 토큰 |
| 도구 호출 및 응답 처리 | 약 6,300 토큰 (N회 반복) | 약 150 토큰 |
| 출력 파싱 | 약 4,500 토큰 | 약 3,200 토큰 |
| 50개 디바이스 처리 총합 | 약 145,000 토큰 | 약 4,150 토큰 |
결과는 충격적이었다. 동일한 작업에서 CLI가 MCP보다 약 35배 적은 토큰을 사용했다. 또 다른 벤치마크에서는 CLI가 토큰 효율 점수(TES) 202점 대 MCP의 152점으로 33% 효율 우위를 보였고, 작업 완료율에서도 CLI가 높은 성과를 보였다.
왜 이런 차이가 생길까? 가장 큰 이유는 MCP의 스키마 로딩 비용이다. GitHub MCP 서버 하나를 연결하면 93개의 도구 정의가 자동으로 AI의 컨텍스트 창에 들어온다. 이게 약 55,000 토큰에 달한다. 여기에 GitHub, 데이터베이스, Microsoft Graph, Jira 등 여러 MCP 서버를 연결하면 질문 하나 하기 전에 이미 150,000 토큰 이상이 도구 정의에 낭비된다. 반면 CLI는 AI가 이미 git, docker 등의 명령어를 학습으로 알고 있기 때문에 스키마 토큰이 0이다.
** 토큰 비용만 보고 MCP가 무조건 나쁘다고 결론 내리는 것은 위험한 단순화다. 각 방식의 강점이 다르며, 사용 목적과 사용자 유형에 따라 최적의 선택이 달라진다. 이 차이는 다음 섹션에서 상세히 다룬다.
'MCP is Dead' 논쟁 - 2026년 3월 현재 상황
Eric Holmes의 도발과 커뮤니티의 반응
2026년 2월 28일, Eric Holmes는 자신의 블로그에 "MCP is dead, long live the CLI"라는 제목의 글을 올렸다. 핵심 주장은 명확했다. "AI 에이전트에게 가장 좋은 도구는 이미 CLI로 잘 작동하고 있다. MCP는 불필요한 복잡성을 더할 뿐이다." 그는 "최고의 도구는 인간과 기계 모두에게 작동해야 한다(The best tools work for both humans and machines)"고 강조했다.
이 글은 개발자 커뮤니티에서 격렬한 토론을 촉발했다. 실제로 2026년 3월 기준 Reddit, Twitter 등에서 진행 중인 논의를 보면, "에이전트가 --help 출력만으로 처음 보는 CLI 플래그를 스스로 알아내는 반면, MCP 서버는 하나같이 불안정해서 계속 돌봐줘야 했다"는 개발자의 증언이 많은 공감을 얻고 있다.
한 벤치마크 비교에서는 CLI가 MCP보다 비용이 최대 32배 저렴하고, 작업 완료 신뢰도도 CLI 100% 대 MCP 72%로 나타났다. 이런 수치들이 "MCP가 죽었다"는 논쟁에 구체적인 근거를 제공하고 있다.
하지만 MCP는 '정상화' 중이다
그렇다고 MCP가 실제로 죽어가는 건 아니다. 여러 분석에 따르면 MCP는 "죽는" 것이 아니라 정상화(normalizing)되고 있다. 처음에는 "만능 해결사"로 과대평가됐다가, 지금은 진짜 필요한 곳에만 쓰이는 실용적인 도구로 자리매김하고 있다는 것이다.
실제로 2026년 3월 현재 한국의 개발자 커뮤니티에서도 "MCP가 죽었다는 말도 나오는데, 그래도 현시점 쓸만한 MCP 10개"를 정리하는 글이 활발히 작성되고 있다. MCP가 완전히 사라질 것이라는 주장보다는, CLI와 MCP를 상황에 맞게 조합하는 실용주의가 주류 의견으로 자리잡고 있다.
** Playwright(브라우저 자동화 도구)를 예로 들면, 기능 수와 토큰 효율에서는 playwright-cli가 압도적이고, 구조화된 권한 관리가 필요한 프로덕션 환경에서는 Playwright MCP가 적합하다. 하나의 도구라도 상황에 따라 다른 접근이 정답일 수 있다.
상황별 선택 기준 - MCP와 CLI 언제 무엇을 써야 하나
아래 비교표는 MCP와 CLI의 강점이 갈리는 핵심 기준을 정리한 것이다.
| 비교 기준 | CLI가 우세 | MCP가 우세 |
|---|---|---|
| 토큰 효율 | 압도적 우세 (최대 35배 절약) | 스키마 로딩으로 비용 높음 |
| AI 학습도 | 이미 깊이 학습됨 | 런타임 처음 만나는 스키마 |
| 설치/설정 복잡도 | 낮음 | 높음 (서버 설치, 설정 필요) |
| 안정성/신뢰도 | 높음 | 서버 불안정 이슈 있음 |
| 보안 제어 | 제한적 | OAuth, 권한 스코핑 강력 |
| 비개발자 접근성 | 낮음 (터미널 이해 필요) | 높음 (자연어 대화 가능) |
| 다중 조직 서비스 | 제한적 | 강점 (팀 공유 서비스) |
| 비CLI 도구 연동 | 불가능 (Figma, Notion 등) | 가능 |
| 도구 탐색/발견 | AI가 이미 알고 있어야 함 | tools/list로 자동 탐색 |
| 멀티테넌트 환경 | 제한적 | 강점 |
CLI를 선택해야 할 때는 개발자 중심의 작업, 즉 코드 작성, 테스트 실행, 파일 관리, Git 작업, 서버 배포 같은 전형적인 터미널 워크플로우다. AI 코딩 에이전트가 이런 작업에서 CLI를 쓰면 컨텍스트 창의 95%를 실제 문제 해결에 쓸 수 있다.
MCP를 선택해야 할 때는 터미널을 열 일 없는 비개발자가 AI와 상호작용해야 하는 경우다. 재무팀이 "이번 달 서비스별 API 사용량을 보여줘"라고 자연어로 질문하고 답을 받는 시나리오, 법무팀이 "전체 레포지토리에서 사용 중인 오픈소스 라이선스 목록을 뽑아줘"라고 요청하는 시나리오가 대표적이다. 또한 Figma, Notion처럼 CLI가 없는 도구를 AI와 연결해야 할 때도 MCP가 사실상 유일한 선택지다.
현재 가장 실용적인 접근법으로 개발자 커뮤니티에서 권장되는 것은 "CLI를 기본(default)으로 쓰고, MCP는 CLI가 닿지 않는 곳에만 적용"하는 하이브리드 전략이다.
바이브코딩 실전 - MCP와 CLI를 함께 쓰는 법
바이브코딩 맥락에서 가장 강력한 조합은 Claude Code(CLI 기반)에 소수의 핵심 MCP 서버를 선택적으로 연결하는 방식이다. Claude Code는 파일 시스템, Git, 코드 실행을 CLI로 직접 처리하면서, Slack 알림 전송이나 Jira 이슈 생성처럼 CLI로는 처리하기 어려운 작업에만 MCP를 사용하는 것이다.
핵심은 MCP 서버를 무분별하게 많이 연결하지 않는 것이다. GitHub MCP 서버 하나만으로도 AI 컨텍스트에 55,000 토큰이 들어간다. 필요한 기능만 최소한으로 연결하거나, 가능하다면 gh CLI를 먼저 활용하는 것이 훨씬 효율적이다.
또한 Anthropic이 2025년 11월에 발표한 Code Execution + MCP 조합도 주목할 만하다. 대용량 데이터를 처리할 때 중간 데이터를 AI 컨텍스트로 넘기지 않고 샌드박스에서 처리해 최종 결과만 받아오는 방식으로, 특정 워크플로우에서 토큰 사용량을 최대 98.7%까지 줄일 수 있다.
** 바이브코딩으로 만든 코드는 빠르게 만들 수 있지만, 유지보수와 보안 취약점에 주의해야 한다. AI가 생성한 MCP 연동 코드는 반드시 보안 검토를 거쳐야 하며, 특히 프롬프트 인젝션(AI에게 악의적인 지시를 주입하는 공격)에 취약할 수 있다.
결론 - MCP도, CLI도 아직 끝나지 않았다
2024년 11월 조용히 등장한 MCP는 1년 만에 OpenAI, Google, Microsoft가 채택하고 Linux Foundation의 공식 표준이 됐다. 그리고 2026년 초, "MCP는 죽었다"는 도발적인 주장과 함께 CLI의 토큰 효율 우위가 데이터로 입증되며 새로운 논쟁이 시작됐다. 이 흐름은 바이브코딩 시대에 도구를 어떻게 선택해야 하는지를 더욱 명확하게 만들어 주고 있다.
핵심은 이것이다. MCP와 CLI는 경쟁 관계가 아니라 보완 관계다. 터미널에서 코드를 다루는 개발자 워크플로우에서는 CLI가 압도적으로 효율적이다. 비개발자가 자연어로 AI와 상호작용해야 하거나, 터미널이 없는 서비스와 AI를 연결해야 할 때는 MCP가 독보적인 해결책이다.
바이브코딩을 이제 막 시작하는 사람이라면, 먼저 CLI 기반 도구(Claude Code, Gemini CLI 등)로 시작해서 개발 흐름을 익히는 것을 권장한다. 그리고 Notion이나 Figma처럼 CLI로는 연결하기 어려운 서비스가 필요해질 때, 또는 비개발자 팀원과 AI 도구를 공유해야 할 때 MCP를 도입하면 된다.
도구는 목적을 위해 존재한다. CLI가 더 효율적인 곳에 MCP를 억지로 쓸 이유가 없고, MCP만이 닿을 수 있는 곳에 CLI를 고집할 필요도 없다. 2026년 현재, 가장 뛰어난 바이브코더는 두 도구를 상황에 맞게 선택하는 사람이다. 지금 바로 Claude Code를 설치하고 첫 번째 명령어를 입력해보자.