MCP 승리, 그러나 전쟁은 이제 시작: Standardization이 Lock-in에서 우리를 구하지 못하는 이유

발행: (2025년 12월 10일 오전 04:48 GMT+9)
6 min read
원문: Dev.to

Source: Dev.to

표준화로의 전환

각 기업이 독점적인 표준으로 사용자를 가두던 혼란스러운 AI 산업은 이제 “에이전트 AI 표준화”라는 통합된 방향으로 움직이고 있습니다. MCP의 모멘텀은 이제 멈출 수 없습니다:

  • 10,000+ 활성 공개 MCP 서버
  • 97 M+ 월간 Python 및 TypeScript SDK 다운로드
  • 주요 플랫폼 전면 채택: ChatGPT, Cursor, Gemini, Microsoft Copilot, VS Code 및 사실상 모든 개발자 도구가 이제 MCP를 지원
  • 즉각적인 인프라 지원: AWS, Cloudflare, Google Cloud, Microsoft Azure가 MCP 서버용 배포 환경을 제공

MCP는 더 이상 “Anthropic의 편리한 표준”이 아니라 AI 에이전트를 실행하기 위한 사실상의 배관이 되었습니다.

공급업체 중립성

이번 기부의 가장 큰 의미는 공급업체 중립성을 확립하는 데 있습니다. 지금까지 MCP는 비록 오픈 소스였지만 “Anthropic의 표준”으로 인식되었습니다. 언제든 사양을 바꿀 수 있는 경쟁사의 기술에 베팅하는 것은 다른 기업들에게 위험 요소였습니다. Anthropic은 기부 이유를 명확히 밝혔습니다: “MCP가 오픈 소스이며, 커뮤니티 주도이고, 공급업체 중립성을 유지하도록 보장하기 위해.”

AAIF에 기부된 추가 프로젝트

AGENTS.md (OpenAI 기부)

에이전트가 사용하는 도구와 기능을 설명하기 위한 메타데이터 표준. 기업 간에 흩어져 있던 “에이전트를 위한 지시사항”을 통합합니다.

goose (Block 기부)

견고한 AI‑에이전트 개발을 위한 프레임워크.

이 프로젝트들을 동일한 재단 아래 관리함으로써 상호 운용성이 크게 향상될 것으로 기대됩니다. “goose로 만든 에이전트가 AGENTS.md에 정의된 사양을 읽고 MCP를 통해 도구를 실행한다”는 미래가 공급업체가 섞여 있더라도 현실이 되고 있습니다.

최근 사양 업데이트 (11월 25일)

  • 비동기 작업 – 에이전트가 시간 소모적인 프로세스를 기다리지 않고 진행 가능.
  • 무상태성 – 서버 측 상태 관리 부담을 줄여 확장성을 향상.
  • 서버 아이덴티티 – 연결 정당성 검증 강화.
  • 공식 확장 – 표준 기능을 안전하게 확장할 수 있는 메커니즘.

Claude 디렉터리에는 이미 75개 이상의 커넥터가 나열되어 있으며, “Tool Search”와 API를 통한 “Programmatic Tool Calling” 같은 기능이 견고해져 “플러그‑인‑하고‑작동한다”는 세계에 한 걸음 더 다가가고 있습니다.

지속되는 과제

진전에도 불구하고 AI 개발 전반은 여전히 문제점이 많습니다:

  • 수개월 내에 도태되는 표준의 급증.
  • 특정 실행 환경에 의존하는 독점적인 “Skills”와 “Ecosystems”를 통한 공급업체 락‑인 (예: Claude의 에코시스템).
  • 문제성 작업의 사일로화 — 어떤 도구든 MCP를 통해 연결할 수 있더라도, 그 도구를 현명하게 활용하기 위한 “Brain (Skills)”은 각 기업의 독점 사양에 기술되어 있습니다.

“Agent‑first” 패러다임 전환은 공급업체들의 방어선을 메우고 사용자의 학습 비용을 낮췄지만, 동시에 공급업체들은 Skills와 Ecosystems 같은 부가가치로 사용자를 묶어두려 합니다. 그들의 절박함은 자신들이 대체 가능한 상품이 되는 것을 두려워하기 때문입니다.

전망

Ilya Sutskever가 팟캐스트에서 언급했듯이, “우리는 스케일링 시대에서 연구 시대로 이동하고 있다.” 우리는 아직도 “연구 시대”에 있습니다. 프롬프트 엔지니어링, 모델 환각, 비결정적 행동 등 고통 포인트는 계속될 것입니다.

결론: MCP는 표준화 전쟁에서 승리했지만, AI 개발과 공급업체 락‑인이라는 근본적인 과제는 여전히 남아 있습니다. 전쟁은 아직 끝나지 않았습니다.

Back to Blog

관련 글

더 보기 »

왜 GitFlow는 인프라에서 실패하는가

TL;DR GitFlow의 장기 운영 피처 또는 환경 브랜치를 Terraform에 적용하면 상태 드리프트와 취약한 파이프라인이 자주 발생합니다. 애플리케이션 코드와 달리 Infra...