요즘 핫한 ‘MCP’, 정체가 뭘까?

MCP의 정체, 에이전틱 워크플로우에서 MCP의 역할, 적용할 때 고려 사항

“아무리 정교하게 만들어진 모델이라도, 시시각각 변하는 외부 세계, 외부의 데이터와 단절되어 있다면 그 잠재력을 발휘할 수 없습니다 - 정보의 사일로(Silo)에 갇혀, 빠르게 낡아져만 가는 시스템에 갇혀있는 것 같이요”

앤트로픽, On Why Context Integration Matters

거대 언어 모델, LLM. 요즘은 그 자체로 ‘엄청나다’고 할 정도의 능력을 가지게 되었습니다. (‘똑똑하다’는 표현이 적확한지는 모르겠지만요, 가만히 생각해 보면 오해의 소지가 많은 표현이라는 생각이 들어서요.)

어쨌든, 이렇게 엄청난 능력을 가진 LLM도, 훈련할 때 사용한 학습 데이터의 범위를 넘어선 정보가 필요한 경우에는 어려움 을 겪게 됩니다. 그런데, 최근 한창 각광받는 AI 에이전트는, ‘적절한 시점’에 ‘적절한 맥락과 데이터’ - 파일, 지식 베이스(Knowledge Base), 도구(Tool) 같은 것들 - 에 접근할 수 있어야지만 진짜 유용 하겠죠.

지금까지 LLM을 중심으로 한 AI 모델을 다양한 외부 소스에 연결하는 작업은 보통 ‘지저분한 코드’를 작성해야 하기도 하고, 그 자체로 ‘임시 방편적’인 성격의 일이었다고 할 수 있습니다. 개발자들이 각각 데이터 소스나 API 스펙에 맞춰 커스텀 코드를 작성하든 아니면 특수한 플러그인을 사용하거나 해야 했다는 겁니다. 결국, 이런 통합의 작업은 ‘취약’하고 ‘확장하기 어려운’ 구조 를 만들어내게 됩니다.

MCP(Model Context Protocol)는 이 일을 단순화해 보자는 취지에서 앤트로픽이 고안한 프로토콜 입니다. 즉, AI 어시스턴트와 외부의 데이터, 도구의 세계를 연결하고, 다양한 맥락의 소스를 연결할 ‘개방형 표준’ 입니다.

MCP 발표 자체는 2024년 11월이었습니다. 지금 트렌드가 되어버린 MCP의 위상에 비해, 이상하리만큼 당시 시장의 반응은 사실 좀 시큰둥했죠. 하지만 지금 MCP는 화제성으로 보면 이미 랭체인(LangChain)은 추월했고, 주요 AI 플레이어들과 오픈소스 커뮤니티들이 MCP를 중심으로 모이는 모습 을 보입니다. 어쩌면, MCP가 에이전틱 AI 시스템을 구축하는데 있어서 변곡점을 만드는 일종의 게임 체인저가 될 수 있을지도 모르겠어요.

MCP의 Start History(빨간색)를 보세요 - 엄청나게 빨리 증가하고 있습니다

그래서 오늘은 MCP에 딥다이브 해 보려고 합니다 - MCP가 왜 지금 핫한 토픽이 되었는지, MCP가 ‘더 잘 통합되는, 맥락을 인식하는 AI 시스템으로의 전환’을 어떻게 도와주는지, 에이전틱 워크플로우에서의 MCP 위치, 그리고 개발자/연구자/AI엔지니어/임원들이 알아야 할 숨겨진 세부 사항 등에 대해 좀 알아보겠습니다. 그리고, 지금까지 소수의 개발자들만이 시도해 보고 있는, MCP의 재미있는 사용 방법도 살펴볼까 합니다.

자, 그럼 시작해 볼까요?

왜, MCP는 ‘지금’ 이렇게 큰 화제가 되고 있을까? 위에서 잠깐 이야기했다시피, MCP는 앤트로픽이 2024년 11월 말 처음 오픈소스로 공개, 발표했습니다. 당시에도 흥미로운 아이디어라고 생각해서 글 로 다루었지만, 그렇다고 많은 사람들이 주목하거나 진지하게 받아들인 건 아니었어요. 그러다가 2025년 초에 들어서 MCP가 AI 개발자 커뮤니티를 중심으로 부상하기 시작했는데요. 최근에 이런 관심을 받게 된 몇 가지 큰 이유 가 있다고 생각합니다:

시스템으로서의 ‘연동(Integration)’에 수반되는 문제를 해결 ‘AI 에이전트’, ‘에이전틱 워크플로우’. 2023년~2024년에 유행하기 시작한 용어들이지만, 여전히 아킬레스건이 남아 있었죠: 바로 이 에이전트들을 어떻게 실제 비즈니스 시스템과 데이터에 통합할 거냐 하는 문제요. 처음에는, ‘통합’ 자체가 아니라 모델의 기능, 프롬프트 기법 같은 것들에 관심이 많이 쏠렸는데, MCP는 AI의 워크플로우에 ‘기존의 데이터 소스 - 파일 시스템, DB, API 등 - 를 연결하는 방법’ 자체를 정의하는 것으로 이 갭을 정면으로 마주합니다. 사람들이 이걸 이해하기 시작하면서, MCP는 실제 환경, 즉 프로덕션(Production)에서 AI 에이전트를 돌리기 위해 채워야 하는, 퍼즐의 한 조각으로 인식되기 시작한 것이죠.

MCP를 채택하는 커뮤니티의 급증 하나의 ‘개념’에서 시작한 MCP는, 불과 몇 개월 만에 빠르게 성장하는 생태계로 발전했습니다. 초기에 MCP를 채택한 회사들로는 Block(Square), Apollo, Zed, Replit, Codeium, Sourcegraph 등이 있습니다. 이 회사들은 자사의 플랫폼을 강화하는 측면에서 MCP를 통합하기 시작했죠. 2025년으로 넘어오면서 생태계가 폭발적으로 성장하기 시작해, 2025년 2월에는 1,000개 이상의 커뮤니티가 만든 MCP 서버(커넥터)를 사용할 수 있게 되었습니다. 그뿐만 아니라 AI + 블록체인 결합이 본격화하면서 FLock이 BASE 네트워크의 MCP와 연동한 Web3 AI 에이전트를 공개했고, 이 에이전트로 지갑 관리, DeFi 자동 거래 등 온체인 업무를 할 수도 있다고 하는 등 광범위한 커뮤니티의 MCP 채택이 이어지고 있습니다. AI 산업 자체가 ‘통합’, ‘맥락의 더 심화된 인식’ 등 키워드로 이동하면서 MCP에 대한 공감대는 더 강해지고, 네트워크 효과를 거두지 않을까 생각합니다 - MCP를 통해서 사용할 수 있는 도구가 많을수록, 이 프로토콜을 채택하는 효과는 배가될 테니까요.

사실상 표준(De Facto Standard)으로서의 모멘텀 독점적이고 폐쇄적인 SDK나 일회성 프레임워크와는 달리 MCP는 모델 종류에 상관없고, 개방적이며, 주요 AI 모델 개발사들의 지지를 받고 있습니다. 즉, 어떤 모델(클로드(Claude), GPT-4, 오픈소스 LLM 등)이라도 MCP를 사용할 수 있고, 어떤 개발자나 회사도 누군가에게 허락받을 필요 없이 MCP를 기반으로 연동 구조를 만들 수 있다는 의미죠. AI 개발자 커뮤니티에서는 - 적어도 이 시점에서는 - MCP가 AI 시스템을 외부 데이터와 연결하는 표준화 경쟁에서 승자가 될 가능성이 있는 유력한 후보라고 보고 있습니다. USB, HTTP 등이 각자의 영역에서 보편적 표준이 된 것처럼요.

속도감 있는 발전, 그리고 교육 앤트로픽의 역할도 의미가 있습니다: 그냥 MCP를 출시하고 모른 체하지 않았어요. 적극적으로 MCP를 개선하고 개발자들에 대한 교육도 열심히 했습니다. 최근 AI 서밋에서, 앤트로픽의 Mahesh Murthy는 (지금은 아주 유명해진) 워크샵을 했는데, 이 워크샵 자체가 MCP가 더 널리 받아들여지고 채택되는 데 큰 역할을 했습니다. (관련 링크는 글 마지막에 포함되어 있습니다.)

다시, MCP가 ‘현재 시점’에서 왜 AI를 외부 세계의 정보 소스, 도구들과 연동하는 표준 경쟁에서 승자로 인식되고 있는지 간략하게 정리하면 아래와 같습니다:

MCP는 무엇이고, 어떤 방식으로 작동하는가? MCP는 AI 모델이 외부의 도구를 찾아서 연결하고, 사용하는 방법에 대한 명확한 규칙을 제시하는 틀 입니다. 그게 DB에 대한 쿼리(Query)든, 아니면 특정한 도구의 명령을 실행하는 것이든 말이죠. 이렇게 모델은 학습 데이터로부터 배운 걸 넘어 더 유연하게, 주변의 세계를 인식하거나 행동을 할 수 있게 됩니다.

기술적인 관점에서 살펴보는 MCP

한 가지 눈에 띄는 특징이라면, 바로 MCP의 ‘다이나믹 디스커버리 (Dynamic Discovery)’ 기능 입니다. AI 에이전트가 하드 코딩으로 연동을 하지 않아도, 이 기능으로 사용할 수 있는(available) MCP 서버, 그리고 그 서버가 제공하는 기능을 자동으로 감지 할 수 있습니다. 예를 들어서, 새로운 MCP 서버(CRM 같은)를 가동하면, 에이전트는 표준화된 API로 즉시 이를 인식하고 사용할 수 있어 전통적인 접근 방식이 따라가기 힘든 유연성을 제공 합니다.

MCP, 어떻게 시작하는 게 좋을까? 일단은 공식 MCP 문서, 그리고 리포지토리에서 시작하는 것이 제일 좋겠죠. 앤트로픽은 MCP 스펙을 오픈소스로 공개했고, SDK(Python과 Java 등 언어로)를 제공하고 있습니다. 일반적인 활용 순서는 다음과 같습니다:

1. 원하는 도구나 데이터 소스의 MCP 서버를 실행/설치

앤트로픽은 인기 있는 시스템(Google Drive, Slack, Git, 데이터베이스 등)을 대상으로 미리 만들어진 MCP 서버 리포지토리(오픈소스)를 갖고 있습니다. 이들 중에 원하는 것들을 설치하고 세팅할 수 있습니다. (Credential이나 Key를 가지고 명령을 실행하기만 하면 되는 경우도 있습니다)

2. AI 앱에서 MCP 클라이언트 설정

예를 들어 클로드(Claude) 앱을 사용하고 있다면, UI에서 서버를 추가할 수 있습니다. 별도로 에이전트를 개발하고 있다면, MCP SDK를 사용해서 서버에 연결합니다. (주소/포트를 제공)

3. 클라이언트에서 MCP 서비스를 활성화하면, 클라이언트가 추가 기능을 감지

추가 도구라든지, 제공되는 리소스, 프롬프트 템플릿 같은 것들을 확인할 수 있습니다.

4. MCP 서버 호출, 반복

모델/에이전트는 이제 필요한 경우에 MCP Tool Action을 호출할 수 있습니다. 이때는 서버를 올바르게 호출하고 있는지 로그를 모니터링해야 합니다. MCP 서버에 요청이 들어가고 응답이 돌아오는 것을 확인할 수 있습니다.

더 빠르게 시작해 보고 싶다면, 앤트로픽에서 Claude Desktop에서의 연동을 해 보거나 예제 서버를 실행하고, 회사가 제공하는 ‘QuickStart’ 가이드를 확인 해 보라고 권장하고 있습니다.

MCP 관련 커뮤니티도 아주 활발합니다. MCP 서버들의 카탈로그가 빠르게 확대되고 있죠. 일부 인기 있는 것들은 이렇습니다.

구글 서비스(Drive, Gmail, Calendar) 슬랙(채팅 및 파일 접근) GitHub/Git(코드 리포지토리) 데이터베이스(Postgres 등) 웹 브라우저나 웹 페이지 탐색용 커넥터(Puppeteer 등)

이 외에도 수많은 MCP 서버들이 커뮤니티 디렉터리에 등록되어 있고, 어떤 개발자들은 이런 MCP 서버 인덱스 사이트를 만들어 놓기도 했습니다. 공식 MCP 깃허브에도 많은 커넥터 정보가 있구요.

a16z에서 발행한 A Deep Dive Into MCP and the Future of AI Tooling 이라는 글도 한 번 보면 좋습니다. 이 글에서는 다양한 MCP 클라이언트, MCP 서버, MCP 마켓플레이스를 비롯한 각종 도구로 어떤 게 있는지 시장 지도(Market Map)를 제공하고 있습니다.

다양한 MCP 관련 스타트업의 시장 지도(Market Map)

만약, 본인이 원하는 일을 하는 MCP 서버가 없다면, SDK를 사용해서 직접 만들어볼 수도 있습니다. 근본적으로, MCP 서버는 MCP의 스펙대로 함수를 노출하는, 백엔드에 있는 도구 API를 감싼 래퍼(Wrapper)이니까요.

또, 유튜브나 블로그에 Claude Desktop 등을 사용해 다양한 MCP 서버들과 연결하는 예제들도 있으니 살펴보면 바로 이해할 수 있을 겁니다. 좀 특이한 예제로, The Focus AI의 Will Schenk가 Tezlab의 Tesla 모니터링 서비스를 사용하는 실습 Walkthrough를 공유 한 것이 있습니다.

MCP 이전에는 AI 시스템이 어떻게 ‘맥락’을 처리하고 ‘도구’를 사용했나? 지금까지 MCP가 무엇이고 어떻게 작동하는지 살펴봤습니다. 그렇다면 조금 되돌아가 그럼 이전에는 AI 모델에게 외부의 지식을 제공해 주거나 외부 도구로 어떤 작업을 처리할 수 있게 하는 기법으로 어떤 것들이 있었는지, MCP와는 어떻게 다른 건지 간단히 살펴볼까요?

MCP 이전의 ‘맥락’ 및 ‘외부 데이터’ 제공 + ‘작업 처리 기능’ 부여 기법들

커스텀 API 연동(일회성, 즉 One-off 커넥터) 가장 쉽게 생각할 수 있는, 초기의 방법이죠. 각 서비스마다 맞춤화된 코드를 작성하거나, 아니면 제공되는 SDK를 사용하는 겁니다. 예를 들어, AI 에이전트가 구글 드라이브와 SQL 데이터베이스에 접근하도록 만들고 싶다면, 구글 API와 데이터베이스 드라이버를 각각 따로 설치하고 연동해야 합니다. 여기에 별도로 고유한 방식의 인증도 해야 하고, 서로 다른 데이터 형식과 특성을 이해하면서 작업해야 하죠. 꽤 귀찮은 일이 많겠죠? 반면에, MCP는 하나의 단일한 방식 - 프로토콜 - 을 제공해서 클라이언트에 특별한 변경이 없어도 새로운 MCP 서버를 추가할 수 있습니다.

언어 모델의 플러그인 연동(오픈AI 플러그인 등) 2023년부터 소개된 방법이라고 하면 맞을 텐데요. 언어 모델에 ‘표준화된 플러그인 스펙(주로 오픈AI 스키마)’을 제공해서 제어를 하면서 외부의 API를 호출하게 하는 겁니다. 개념적으로 이 기법은 MCP와 비슷하지만, 그 성격이 ‘독점적’이기에, ‘제한적’이라는 근본적인 차이가 있죠 - 각각 플러그인을 여전히 별도로 구축하고 호스팅해야 하고, 챗GPT나 빙 챗(Bing Chat) 같은 특정한 플랫폼에서만 사용할 수 있죠. 또 다른 이슈는, 플러그인이 지속적으로 세션을 유지하기보다는 단방향의 데이터 검색(모델이 API를 호출하고 정보를 얻는 등)에 초점을 맞추는 경향이 있었다는 겁니다. 반면에, MCP는 오픈소스로서 보편적으로 누구든 구현할 수 있고, 특정한 AI 모델 개발사에 종속되지 않고, 풍부한 양방향의 상호작용을 지원한다는 점에서 차별화가 있죠.

프레임워크 기반 도구 사용(랭체인 도구, 에이전트 등) 랭체인(LangChain) 같은 에이전트 오케스트레이션 라이브러리는, 모델에 설명이 포함된 ‘도구(즉, 함수)’를 제공하는 아이디어를 대중화했죠. 예를 들어서, search() 도구나 calculate() 도구를 보면, 에이전트는 LLM을 거쳐 이 도구들을 언제 어떻게 호출할지 결정하게 됩니다. 이런 라이브러리는 강력하기는 하지만, 여전히 각각 도구를 내부적으로 커스텀 개발을 해야 하는 부분이 있죠 - 랭체인 라이브러리는 동일한 인터페이스를 기반으로 500개 이상 도구를 포함한 프레임워크로 성장했지만, 개발자들이 여전히 직접 그 도구들이 어떤 건지, 나한테 필요한지 확인해야 하고 연결해야 합니다. MCP 서버도 ‘어떤 에이전트든 사용할 수 있는 기성품 라이브러리’ 정도로 해석한다면 비슷한 측면이 있기도 한데요. 다만, 랭체인이 외부 도구를 에이전트의 코드에 통합하기 위해서 ‘개발자 중심의 표준’ - 도구(Tool) 클래스 인터페이스 - 에 초점을 맞췄다면, MCP는 ‘모델 중심의 표준’을 만들었다는 차이가 있죠. 이 차이는 근본적으로 꽤 큰 차이라고 봅니다. 특정한 도구에 맞게 에이전트의 코드를 작성하지 않아도, 모델이 쉽고 빠르게, 즉각적으로 여러 가지 도구들을 통합해서 사용할 수 있다는 뜻이니까요. (랭체인 팀도 이런 상황에 빠르게 적응하고 있습니다. 이들은 모든 MCP 서버를 쉽게 랭체인 툴로 취급할 수 있는 어댑터를 제공하기도 합니다.)

RAG와 벡터 데이터베이스 LLM에 컨텍스트, 즉 맥락 있는 데이터를 제공하는 또 다른 일반적인 방법이 있습니다. 바로 검색기(Retriever)로 지식 베이스(문서, 임베딩)를 검색해 와서 상위의 결과를 프롬프트에 결합하고 LLM에 제공하는 겁니다. 이 RAG 기법은 모델이 훈련하면서 습득한 지식이 제한적일 때, 그리고 메모리 문제가 있을 때 유용합니다. 그렇지만 RAG는 보통 정적인 텍스트를 다루며, 인덱스된 것 이상 추가적인 작업을 수행하기에 좋은 구조는 아니죠. 물론, MCP와 RAG를 함께 작동하도록 할 수 있습니다. 예를 들어, MCP 서버를 벡터 DB나 검색 엔진하고 연결해서, 모델이 매번 프롬프트를 받을 때마다 검색에 의존하기보다 ‘도구’로서 검색 쿼리를 날리도록 하는 거죠. 지금은 아무래도 MCP가 RAG 대비 더 광범위하고 범용적인 기법이라고 봐야 합니다. RAG가 수동적인 컨텍스트를 제공한다면, MCP는 모델이 능동적으로 컨텍스트를 가져오거나 더 나아가 행동할 수 있게 해 줍니다.

MCP, ‘만능열쇠’일까? 그렇다고 MCP가 뭐든 해결해 주는 ‘만능열쇠’, ‘만병통치약’일 수는 없습니다. 아주 편리하게 LLM을 외부의 데이터나 도구와 통합할 수 있게 해 주지만, 그 이면에 또 고려해야 할 자기만의 복잡성이나 이슈가 있을 수밖에 없습니다.

고려해 봐야 할 점들 중에 하나는, ‘여러 가지 도구의 서버를 관리해야 하는 추가적인 오버헤드’ 겠죠. 수많은 로컬 서버에 연결하고 유지하는 건 아무래도 번거로운 작업이며, 특히 가동 시간이나 보안, 확장성 등이 중요한 프로덕션(Production) 환경이라면 더 그럴 겁니다. 일단 현재 MCP의 구현은 로컬, 그리고 데스크탑에서 사용하는 걸 염두에 두고 설계되어 있어, 클라우드 기반 아키텍처라든가 수많은 사용자가 있는 시나리오에 얼마나 잘 적용될지는 확인해 봐야 할 문제입니다. 그래서 많은 개발자가 ‘MCP를 Stateless로, 분산 환경에 적응할 수 있도록 만들자’는 제안을 하기도 했는데, 아직 논의가 진행 중이죠.

또 다른 문제는, ‘도구의 사용성’ 이죠. MCP가 AI 모델이 접근할 툴셋을 확장해 주는 좋은 프로토콜이라는 건 부인할 수 없지만, 그것과 모델이 이런 도구를 ‘효과적으로 사용’한다는 건 다른 이야기입니다. MCP 구조를 이용해서 좋은 에이전트를 만들려면, MCP 서버에 대해 잘 설명하는 스펙, 그리고 이를 AI 모델이 잘 해석해 내는 것, 이렇게 두 손바닥이 잘 만나 박수를 쳤을 때 경쾌한 소리가 나야 한다 는 겁니다. 랭체인의 창립자 해리슨 체이스(Harrison Chase)는 ‘커뮤니티 주도’의 접근 방식으로 잘 문서화된 도구가 사용성을 향상시킬 수 있다고 믿지만, 여전히 리스크가 있고 지속적으로 들여다봐야 할 겁니다.

시간이 어느 정도 해결해 주겠지만, ‘MCP의 성숙도’ 또한 고려해 봐야 할 겁니다. MCP는 비교적 새로운 프로토콜이라서, 변화도 빠르게 나타날 겁니다. 따라서 이 표준이 어떤 방향으로 발전할지 불확실성이 있습니다. 에이전트를 개발하는 사람이라면, 앞으로 업데이트가 얼마나 빈번하게 일어날 것이며, 호환성에 문제를 일으키게 될지 예상하고 준비해야 할 겁니다.

‘호환성’도 또 하나의 문제가 될 수 있습니다. 지금은 MCP가 앤트로픽 생태계 안에서 최고 수준의 지원을 받고 있지만, 더 광범위하게 채택이 될지 어떨지는 확실치 않습니다. 만약, 주요 AI 개발사가 MCP를 기본적으로 지원하지 않는다면, 추가적인 어댑터의 커스텀 코딩이 필요하겠죠. 주요한 AI 플랫폼 전반에 걸쳐서 MCP가 수용되기 전에는, 유용성에도 제한이 있을 겁니다.

위에서 말한 것과 별도로, 내가 만들려고 하는 애플리케이션에 MCP 정도 프로토콜이 필요한가 하는 것 역시 꼭 챙겨봐야 하는 질문입니다. AI 모델이, 길게 봐서도 하나, 두 개 정도의 간단한 API만 사용하면 되는 수준의 애플리케이션이라면, MCP를 구현하는 것보다 직접 API 호출을 하는 게 간편하고 효율적인 방법이 될 수도 있습니다.

MCP 기반 애플리케이션의 보안, 모니터링도 신경 써야 하는 영역 입니다. MCP가 중간 브로커(Broker) 역할을 하기 때문에, 이에 대한 임의적인 접근은 막아야 하고, 이를 위해 강력한 인증, 권한 제어를 해야 합니다. 이미 MCP Guardian 같은 오픈소스 이니셔티브가 등장하기는 했지만, 기업의 환경에서 MCP를 보호하는 건 아직 초기 작업입니다.

전반적으로 이러한 여러 가지 고려 사항에도, 사실 치명적인 영향을 주는 건 없다고 생각합니다. 다만 MCP를 활용해서 유연하고 확장성 있는 에이전트 애플리케이션을 만드는 ‘감각’을 익힌다는 마음가짐으로, 어느 정도 실험적인 성격이 있고, 그 중요성이 너무 크지 않은 영역에서 시작하는 것이 좋다고 봅니다. 그리고 커뮤니티를 많이 활용하세요. MCP(뿐 아니라 비슷한 도구들)의 가장 좋은 점 하나는 ‘참여하는 커뮤니티’가 적극적이고 서로 도와주기를 꺼리지 않는다는 겁니다. ‘오픈소스’라서, 내가 닥친 문제를 다른 커뮤니티의 멤버들하고 논의해 가면서 해결할 수도 있겠죠.

에이전틱 워크플로우를 위한 ‘오케스트레이션’과 MCP의 역할 ‘자율 에이전트’의 구성 요소로는 프로파일, 지식, 기억, 추론과 계획, 성찰, 그리고 행동 이있습니다. 간단히 설명해 보면, 에이전트는 자기 주변의 환경을 관찰/이해하고 (프로파일과 지식) , 이전에 했던 상호작용을 기억하며 (기억) , 행동을 계획하고 (추론) , 이러한 행동을 실제로 바꿔 (도구의 호출이나 출력) , 성찰하며 학습하는 거죠. 자, 그럼 여기서 ‘MCP’의 역할이 뭔가요?

MCP는 그 자체로 ‘에이전트 프레임워크’라고 할 수는 없습니다 - 에이전트를 위한 표준화된 통합 계층으로 작동하면서 에이전트의 ‘행동’ 영역에서 외부 데이터나 도구와 관련된 행동을 수행할 방법을 제공 하는 거라고 봐야겠죠.

MCP가 없다면, 에이전트가 파일을 가져오거나, 데이터베이스에 쿼리를 날리거나, API를 호출하거나 할 때, 개발자가 커스텀 코드를 작성하거나 임시적인 솔루션을 그때그때 사용하든 할 겁니다. 비유해 보면, 이건 로봇을 만드는데 축구공을 잡을 때와 럭비공을 잡을 때 각각 다른 손가락을 만들어야 하는 상황과 비슷합니다. 지루하고 확장성도 없죠.

다시 한번 강조 하는 게 좋겠습니다. MCP는 그 자체로 AI를 위한 오케스트레이션 엔진이나 에이전트 프레임워크가 아닙니다. 에이전트 아키텍처 안에 있는 통합 계층이자 프로토콜 이죠. 에이전트가 외부의 도구나 데이터와 연결해 뭔가 할 ‘도구 상자’ 정도 역할을 하면서 랭체인, 랭그래프(LangGraph), 크루AI(CrewAI) 또는 라마인덱스(LlamaIndex) 같은 에이전트 오케스트레이션 도구를 보완해 줍니다.

MCP를 LLM이 사용하는 표준화된 API 게이트웨이로 생각해도 되겠습니다. 클라이언트(에이전트)와 서버(도구) 간의 보편적인 호환성(Universal Compatibility)을 보장해, 연동 작업의 복잡성을 ‘NxM’ 문제에서 ‘N+M’ 차원의 문제로 단순화해 주니까요. 이렇게 외부 기능과의 연동을 간소하게 만들어 에이전트가 더 다재다능하고, 환경 변화에 잘 적응하면서, 다양한 컨텍스트를 이해하고 복잡한 작업을 수행할 수 있게 해 줍니다.

MCP가 여는 새로운 가능성 MCP는 등장한 지 아직 얼마 안 된 새로운 기술입니다. 그런 만큼 아직 그 잠재력을 탐색하고 있는 단계죠. 일단 그 첫 번째 단계로는, 기업의 데이터를 채팅 어시스턴트나 Q&A 엔진에 연결할 때, 아니면 리포지토리나 파일 시스템에 쉽게 접근하게 만들어 코딩 에이전트의 능력을 끌어올리는 데 쓰일 겁니다.

AI 에이전트를 다음 단계로 끌어올리는 새로운 MCP 기반 애플리케이션으로는, 아래와 같은 것들을 상상해 볼 수도 있겠죠:

복잡한 단계로 작동하는, 크로스 시스템 워크플로우 에이전트 시스템 예를 들어, AI가 이벤트를 계획한다고 생각해 볼게요: 캘린더를 확인하고, 장소를 예약하고, 손님들에게 이메일을 보내고, 여행을 준비하고, 예산 엑셀 시트를 업데이트합니다. 지금 이런 작업을 하려면 API를 하나하나 수동으로 연결해야 하겠지만, MCP를 사용하면 이 모든 작업을 하나의 인터페이스로 처리할 수 있습니다. 에이전트 - 내부의 LLM - 가 필요한 작업이 있을 때마다 MCP 서버를 호출해서 사용하고, 이 세션들 간에 공유 컨텍스트를 유지합니다.

주변 환경을 이해하는 에이전트(로보틱스 포함) 도구에 접근하는 것을 넘어, MCP는 스마트 환경(스마트 홈이든 운영 체제든)에 내장된 AI 에이전트를 지원할 수 있습니다. 즉, AI 어시스턴트가 표준화된 MCP 서버로 센서, IoT 장치 또는 OS 기능과 통신할 수 있다는 겁니다. 이렇게 AI가 실시간으로 환경에 대한 정보를 얻고 주변을 인식하면 더 자연스럽고 능동적인 사용자 지원을 할 수 있게 됩니다.

서로 협력해서 작업하는 에이전트(에이전트 사회) 이 부분이 아주 흥미로운 부분입니다. MCP는 멀티 에이전트 시스템을 지원하는 일종의 ‘공유 작업 공간’ 역할을 할 수 있다고 생각합니다. 전문화된 AI 에이전트 - 예를 들어, 하나는 연구용, 하나는 계획용, 하나는 실행용 등이라고 해 보죠 - 들이 MCP를 활용해 정보를 교환하고 다이나믹하게 작업을 조정할 수 있습니다. MCP를 사용하면 각각 에이전트들을 직접 연동할 필요가 없고, 단순히 공통의 도구 셋에 접근만 하면 되니까요.

MCP를 기반으로 ‘심도 있는 연동’을 하는 AI 어시스턴트 사용자가 자신만의 AI를 개발/구성해서 개인의 데이터라든가 자기가 사용하는 앱과 안전하게 연동하도록 할 수 있겠죠. 로컬 MCP 서버를 활용해서 민감한 개인 정보를 외부에 노출하지 않으며 AI가 이메일, 메모, 기타 스마트 디바이스 등에 접근하게 할 수 있습니다. 이렇게 하면, 클라우드 기반 서비스에 의존성이 없는 ‘초개인화 AI 어시스턴트’를 만들 수 있습니다.

기업의 거버넌스 또는 보안 에이전트 MCP는 기업의 내부 도구에 대한 AI의 접근 방식을 표준화합니다. 그 때문에 다양한 도구를 통합하는데 따라오는 오버헤드를 줄여주고 효과적으로 ‘거버넌스’ 체계를 운영할 수 있게 해 줍니다. AI의 상호작용을 감독 계층으로 기록, 모니터링, 제어하면서, 효율성도 유지하고 리스크가 있는 작업이 진행되는 걸 방지합니다.

이처럼 새로운 가능성을 보여주는 MCP 기반의 에이전트와 애플리케이션들은 MCP의 잠재력을 보여주는 초기의 모습들일 뿐입니다. MCP는 유연하게 컨텍스트를 인식/이해하고, 멀티 스텝의 상호작용을 편하게 하도록 도와주는, 진짜 제대로 된 자율 워크플로우를 실행할 AI 에이전트 시대에 한 걸음 다가가게 해 주는 징검다리 라고 하겠습니다.

마치며 2024년 11월, 앤트로픽이 제안한 MCP는 AI를 ‘혼자 떨어져 있는 고립된 두뇌’에서 ‘다재다능한 작업 수행 엔진’으로 변모시켜 주는, 강력한 표준 프로토콜로 빠르게 발전하고 있습니다. 앤트로픽의 Mahesh Murag이 진행했던 워크샵 을 기준으로 보면, MCP에는 앞으로 아래와 같은 기능이 추가적으로 탑재될 것으로 예상 됩니다.

원격 서버 및 OAuth

SSE를 사용한 원활한 원격 호스팅 안전한 연동을 위한 내장 OAuth 2.0 (예: Slack)

공식 MCP 레지스트리

중앙에서 서버를 발견하고 검증 호스트가 비공개 레지스트리를 운영할 수 있는 기업 친화적 구조

‘Well-Known’ 엔드포인트 (Endpoints) 설정

자사(1st Party) 서버를 발견하기 위한, 표준화된 .well-known/mcp 파일

추가 개선 사항

스트리밍 지원, 상태없는(Stateless) 커넥션, 능동적 서버 동작과 더 좋은 네임스페이스

이 모든 업데이트가 실행된다면 MCP 프로토콜은 더 견고하고 안전한, 쓰기 좋은 구조 가 될 겁니다. 곧, AI 에이전트가 실제 워크플로우에 더 밀접하게 통합되기 쉬워지겠죠. 게다가 이 모든 작업은 ‘커뮤니티가 주도하는’ 작업 이니까, 여러분도 로드맵을 보면서 논의에도 참여하고, AI와 소프트웨어가 만나고 연동하는 미래를 만들어 가는데 기여해 보면 좋을 것 같습니다.

보너스: 참고자료 Introducing the Model Context Protocol by Anthropic Model Context Protocol documentation and quickstart guide MCP docs Model Context Protocol on GitHub Collection of Servers for MCP on GitHub Building Agents with Model Context Protocol (and especially the part: What’s next for MCP) by Mahesh Murag from Anthropic, Workshop @AI Engineering Summit Why MCP Won by swyx from Latent Space GitHub Star History (Charts) MCP: Flash in the Pan or Future Standard? by LangChain MCP Guardian on Github Exposing Services with MCP Initial reaction to MCP on reddit

갑자기 많은 관심을 받고 있는 'MCP', 한 번 알아봅시다.