MCP는 죽었다; MCP 만세

• 최근 CLI 중심의 유행이 확산되며 MCP가 과거의 기술로 평가받고 있으나, 글은 조직 단위의 AI 엔지니어링에서는 여전히 MCP가 핵심임을 강조
• CLI는 토큰 절약과 단순성에서 장점이 있으나, 맞춤형 CLI의 경우 LLM이 사용법을 학습하지 못해 오히려 비효율이 발생
• MCP는 HTTP 기반 중앙화 구조를 통해 인증, 보안, 텔레메트리, 콘텐츠 동기화 등 조직 운영에 필요한 관리 기능을 제공
• MCP Prompts와 Resources는 서버에서 최신 문서와 스킬을 동적으로 제공해, 모든 팀과 리포지토리에서 일관된 지식 전달을 가능하게 함
• 개인 개발자에게는 과도할 수 있으나, 엔터프라이즈 환경에서의 가시성·보안·품질 관리를 위해 MCP는 여전히 필수적 도구로 평가됨

요약

• 최근 업계 담론은 MCP에서 CLI로 이동했으며, MCP는 과거의 과대광고로 여겨지고 있음
  • 그러나 글은 MCP의 구조적 가치가 여전히 유효하다고 지적
  • 특히 조직적 도입과 운영에서는 MCP가 필수적임을 강조

인플루언서 주도의 하이프 사이클

• 6개월 전까지만 해도 Model Context Protocol(MCP) 관련 제품이 폭발적으로 등장했으나, 현재는 CLI 중심으로 여론이 이동
• MCP는 단순히 API 래퍼로 인식되어 직접 API 호출보다 비효율적이라는 평가를 받음
• 글은 AI 인플루언서들이 유행을 주도하며 기술 담론을 왜곡한다고 비판
• CLI가 유용한 경우도 있지만, 모든 상황에 적합하지 않으며 MCP의 역할을 대체하지 못함

오해의 이해

• MCP가 모든 경우에 적합하지 않다는 점은 인정하지만, CLI와 MCP의 효율성 논쟁에는 오해가 많음
• CLI는 모델 학습 데이터에 포함된 표준 도구(jq, curl, git 등)일 때만 토큰 절약 효과가 있음
  • 맞춤형 CLI는 LLM이 사용법을 모르는 경우가 많아 추가 문서와 지시어가 필요
• CLI 체인으로 데이터 추출·변환 시 일부 절약이 가능하지만, 이는 MCP만의 한계가 아님
• 점진적 컨텍스트 소비는 가능하나, 복잡한 CLI 구조에서는 오히려 더 많은 상호작용이 필요
• MCP의 “복잡성” 비판은 과장되었으며, 스마트한 MCP 설계가 있다면 CLI 대비 손실이 크지 않음

MCP의 이중성

• stdio 기반 MCP는 과도하지만, HTTP 기반 스트리밍 MCP는 조직 단위 도입의 핵심 요소로 평가
• 중앙화된 MCP 서버는 보안, 인증, 상태 관리, 텔레메트리를 통합적으로 처리 가능
• Ephemeral 환경(GitHub Actions 등) 에서도 MCP는 설치 없이 복잡한 백엔드 접근을 지원
• 인증은 OAuth 기반 중앙 관리로 단순화되며, 개발자별 키 노출을 방지
• OpenTelemetry 통합을 통해 팀 단위의 도구 사용 현황과 실패 지점을 추적 가능

표준화된 최신 콘텐츠 제공

• MCP는 구독 및 알림 기능을 통해 클라이언트에 최신 업데이트를 자동 전달
• MCP Prompts는 서버 제공 SKILL.md, MCP Resources는 서버 제공 /docs 역할 수행
• 이를 통해 조직은 다음을 실현 가능
  1. 동적 콘텐츠 생성 – 문서와 스킬을 실시간으로 업데이트
  2. 자동 동기화 – 로컬 파일 관리 없이 항상 최신 상태 유지
  3. 조직 전체 지식 공유 – 모든 팀이 동일한 표준 문서와 스킬을 활용
• MCP 클라이언트 설정만으로 배포가 완료되며, 업데이트 관리 부담이 제거됨

결론

• 업계는 빠르게 변하며 인플루언서 중심의 유행이 반복되고 있음
• MCP는 개인 개발자에게는 과도할 수 있으나, 조직적 엔지니어링 체계 구축에는 필수적
• 보안·품질·일관성·관찰 가능성을 확보하기 위해 MCP는 여전히 최적의 선택
• AI 에이전트가 생산한 코드를 운영·유지하려면, ‘바이브 코딩’에서 ‘에이전트 중심 엔지니어링’으로의 전환이 필요
• MCP는 이러한 전환을 가능하게 하는 현재와 미래의 핵심 인프라로 제시됨