MCP가 Linux Foundation에 합류: 차세대 AI 도구와 에이전트를 구축하는 개발자에게 의미하는 바

Source: GitHub Blog

지난 1년 동안 AI 개발이 폭발적으로 성장했습니다. 현재 110만 개가 넘는 공개 GitHub 저장소가 LLM SDK를 가져가고 있으며(+178 % YoY), 개발자들은 거의 70만 개의 새로운 AI 저장소를 만들었습니다. 올해 Octoverse 보고서에 따르면 에이전트형 도구인 vllm, ollama, continue, aider, ragflow, 그리고 cline 등이 현대 개발자 스택의 일부분으로 빠르게 자리 잡고 있습니다.

이 생태계가 확장됨에 따라 모델을 외부 도구와 시스템에 안전하고 일관되게, 그리고 플랫폼 간에 연결해야 할 필요성이 커지고 있습니다. 바로 그 격차를 Model Context Protocol (MCP)이 빠르게 메우고 있습니다.

Anthropic 내부에서 오픈소스 아이디어로 탄생한 MCP는 처음부터 오픈되어 있었고, 커뮤니티가 함께 확장·채택·형성하도록 설계되었기 때문에 빠르게 성장했습니다. 이러한 개방성은 MCP가 업계에서 가장 빠르게 성장하는 표준 중 하나가 된 핵심 이유이며, GitHub와 Microsoft 같은 기업들이 참여해 표준을 구축하는 데 기여할 수 있게 했습니다.

이제 Anthropic이 MCP를 Agentic AI Foundation에 기부하고, 해당 재단은 Linux Foundation이 관리하게 됩니다. 프로토콜은 새로운 공동 관리 단계에 들어서며, 개발자들에게 장기적인 툴링, 프로덕션 에이전트, 기업 시스템을 위한 기반을 제공하게 됩니다. MCP 커뮤니티에 참여해 온 우리에게는 매우 흥미로운 일이며, Linux Foundation을 오랫동안 지원해 온 입장에서 이 움직임을 크게 환영합니다.

지난 1년은 MCP에게 엄청난 성장과 변화를 가져다 주었습니다. 여기서 MCP가 어떻게 현재에 이르렀는지, 그리고 Linux Foundation으로의 전환이 차세대 AI 개발에 어떤 의미를 갖는지 살펴보겠습니다.

MCP 이전: 파편화된 API와 부실한 통합

LLM은 처음에 고립된 시스템으로 시작했습니다. 프롬프트를 보내면 응답을 받는 형태였죠. 우리는 RAG(검색‑증강 생성) 같은 패턴을 사용해 데이터를 끌어와 LLM에 더 많은 컨텍스트를 제공하려 했지만, 그 한계가 있었습니다. OpenAI의 함수 호출 도입은 큰 변화를 가져왔습니다. 처음으로 외부 함수를 호출할 수 있게 된 것이죠. 이는 GitHub Copilot의 기반이 되었습니다.

2023년 초까지 개발자들은 서로 호환되지 않는 API들의 조각을 통해 LLM을 외부 시스템에 연결하고 있었습니다. 맞춤형 확장, IDE 플러그인, 플랫폼‑특화 에이전트 프레임워크 등 다양한 방식이 있었지만, 각 제공자는 자체적인 통합 방식을 가지고 있었고, 그 방식들은 서로 완전히 달랐습니다.

“모든 플랫폼이 함수 호출, 플러그인 API, 확장 등 자체적인 시도를 했지만, 큰 반향을 일으키지는 못했습니다.” – Nick Cooper, OpenAI 엔지니어이자 MCP 운영 위원회 위원

이것은 툴링 문제라기보다 아키텍처 문제였습니다.

실시간 웹, 데이터베이스, 티켓 시스템, 검색 인덱스, CI 파이프라인 등에 모델을 연결하려면 매번 맞춤형 코드를 작성해야 했고, 모델 업데이트가 있을 때마다 깨지는 경우가 빈번했습니다. 개발자들은 플랫폼마다 깊은 통합 코드를 일일이 작성해야 했습니다.

“업계는 너무 많은 클라이언트와 시스템, 그리고 이를 연결할 공유 프로토콜이 없는 상황에서 n×m 통합 문제에 정면으로 부딪히고 있었습니다.” – David Soria Parra, Anthropic 수석 엔지니어이자 MCP 원래 설계자

실질적으로 n×m 통합 문제는 모델 클라이언트(n) 가 도구·서비스·시스템(m) 각각과 별도로 통합해야 하는 상황을 의미합니다. AI 클라이언트 5개가 내부 시스템 10개와 연동한다면 50개의 맞춤형 통합이 필요하고, 각각은 다른 의미론, 인증 흐름, 오류 처리 방식을 갖게 됩니다. MCP는 단일하고 벤더 중립적인 프로토콜을 정의함으로써 이를 하나로 압축합니다.

표준이 없다는 것은 단순히 비효율적인 것이 아니라, 실제 채택을 지연시키는 요인이었습니다. 금융, 의료, 보안 등 규제가 엄격한 산업에서는 모델이 시스템과 통신할 수 있는 안전하고 감사 가능한, 크로스‑플랫폼 방식이 필요했지만, 대신 불명확한 신뢰 경계가 있는 독점 플러그인 생태계가 제공되었습니다.

MCP: 개발자 작업 방식에 맞춘 프로토콜

Anthropic, GitHub, Microsoft 등 여러 기업의 엔지니어들은 모두 모델을 컨텍스트와 도구에 안정적으로 연결하는 데 같은 벽에 부딪혔습니다. Anthropic 내부에서는 팀들이 내부 프로토타입을 만들면서 데이터 요청, 도구 호출, 장기 작업 처리와 같은 패턴이 점점 수렴하는 것을 발견했습니다.

Soria Parra는 MCP의 탄생을 간단히 이렇게 설명했습니다: “Anthropic 엔지니어들이 반복해서 재발명하던 패턴을 표준화하려는 시도였습니다.” MCP는 이러한 패턴을 통신 중심으로 정리했습니다—모델과 시스템이 서로 어떻게 대화하고, 컨텍스트를 요청하며, 도구를 실행하는지를 정의한 프로토콜이죠.

Anthropic의 Jerome Swanwick은 “모든 엔트리가 MCP 위에 구축된 초기 내부 해커톤”을 회상했습니다. 그때의 개발자 관심이 바로 씨앗이 되었습니다. 이후 Anthropic이 MCP를 공개적으로 출시하고 고품질 레퍼런스 서버를 제공하자, 커뮤니티는 즉시 그 가치를 인식했습니다. MCP는 클라이언트, 런타임, 벤더에 관계없이 모델이 외부 시스템과 소통할 수 있는 공통된 방법을 제공했습니다.

MCP가 성공한 이유: 실제 개발자 워크플로에 최적화

MCP가 출시되자 채택은 즉각적이었고, 기존 어떤 표준보다도 빠른 속도로 확산되었습니다.

“그때 바로 직관에 와 닿았습니다. 해결하려는 문제와 왜 이게 필요한지 바로 이해했어요.” – Den Delimarsky, Microsoft 수석 엔지니어이자 보안·OAuth 담당 MCP 운영 위원회 핵심 멤버

몇 주 만에 Anthropic, Microsoft, GitHub, OpenAI, 그리고 독립 개발자들의 기여자가 프로토콜을 확장하고 견고하게 만들었습니다. 이후 9개월 동안 커뮤니티는 다음과 같은 기능을 추가했습니다:

• 원격 서버를 위한 OAuth 흐름
• 샘플링 의미론(도구 호출이나 컨텍스트 요청 시 모델 동작의 일관성 보장)
• 정제된 도구 스키마
• 일관된 서버 탐색 패턴
• 확장된 레퍼런스 구현
• 향상된 장기 작업 지원

장기 작업 API는 핵심 기능입니다. 빌드, 인덱싱, 배포 등 수분에 걸친 작업을 예측 가능하게 추적할 수 있게 해 주며, 폴링 해킹이나 맞춤형 콜백 채널 없이도 처리할 수 있습니다. 이는 현재 우리가 보는 장기 실행 AI 에이전트 워크플로에 필수적입니다.

Delimarsky의 OAuth 작업은 또 다른 전환점이었습니다. 그 이전에는 대부분의 MCP 서버가 로컬에서만 실행돼 기업 환경에서 사용이 제한적이었고, 설치 마찰이 컸습니다. OAuth를 도입하면서 원격 MCP 서버가 가능해졌고, 대규모로 안전하고 규정 준수되는 통합을 구현할 수 있게 되었습니다. 이 변화는 다중 머신 오케스트레이션, 공유 기업 서비스, 비‑로컬 인프라에 MCP를 적용할 수 있게 만든 핵심 요인이었습니다.

동시에 OAuth는 MCP에 익숙하고 검증된 보안 모델을 제공했으며, 독점적인 토