MCP: '무한한 연결'을 통한, '컨텍스트'의 완성
MCP로 가속화될, 액션형 AI 에이전트를 기대하며
이번엔 이전 화에서 언급한 MCP에 대해, 기획자의 시선에서 이야기 해보려고 한다.
2025년 상반기에 가장 화두가 된 AI 용어 중 하나가 Anthropic의 'MCP'라고 생각된다.
얼마 전, 에이전트 서비스 기획 중, 다양한 3rd Party의 사이트와 연동하여 최종 구매까지의 편의성을 제공하는 시나리오를 구상한 적이 있다.
AI 기반으로 다양한 외부 사이트들의 상품을 분석해, 사용자의 요청에 딱 맞는 상품 후보를 추천하는 것이다.
사실 쇼핑, 음식 배달, 여행 등 카테고리별로 수 많은 사이트와 제휴하고 API 연동하는 것은 사업과 개발 리소스가 꽤 소요되는 과정이다.
일러스트 by Chat GPT 4o여기에 더해, 공수를 들여 연동을 했을 때 ’LLM 모델이 여러 3rd Party들의 회신 값을 토대로 정확도 높은 만족스러운 답변을 만들 것인가?' 라는 고민도 생긴다.
한발 더 나아가 ‘3rd Party를 계속 추가해 확장해 나간다면, LLM의 답변이 일관성 있는 품질을 유지할 수 있을까?’도 고려하게 되었다.
그래서 액션형 에이전트는 일단 후순위 과제로 미루게 되었는데, MCP가 등장하면서 다시 솔루션을 찾아볼 수 있게 되었다.
MCP의 기본 개념과 구성 요소
MCP(Model Context Protocol)는 2024년 11월 Anthropic이 발표한, AI가 다양한 데이터 소스나 외부 툴에 안전하고 통제된 방식으로 접근할 수 있게 해주는 개방형 표준 프로토콜이다.
* 공식 페이지: Introducing the Model Context Protocol \ Anthropic
MCP는 크게 3개의 요소로 구성되어 있다.
Host: Claude 같은 AI 모델 기반의 사용자 인터페이스
사용자가 자연어로 요청한 내용을 이해하고 처리하기 위해 외부 툴 연결이 필요하다고 판단되면, MCP Client에 요청한다.
Client: Host와 MCP Server 사이에서 통신을 담당하는 컴포넌트
외부 Tool 사용과 관련한 권한 및 보안 처리를 담당하고,MCP Server로부터 받은 결과 데이터를 AI가 사용할 수 있는 형태로 다시 변환하는 역할도 한다.
Server: 실제 외부 툴과 Data 소스에 접근하여 정보를 통신하는 역할
각 툴 단위로 별도의 서버가 존재하고, 서버는 해당 툴과 연동할 수 있게 구현한다. 클라이언트의 요청을 받은 서버는 외부 리소스와 통신하여 필요한 작업을 수행하게 된다.
MCP의 기본 구조 (출처: Anthropic)MCP로 연동하면 뭐가 좋아지나요?
다양한 외부 툴을 연동하여 사용자 맞춤형 결과를 제공하고자 한다면, MCP 구조로 적용했을 때 다음과 같은 이점이 있다.
쉬운 확장성: 새로운 외부 3rd Party 툴을 추가하거나 다른 AI 모델과 연동하는 경우에, 표준화된 규격에 따라 효율적으로 개발할 수 있게 된다.
보안/인증의 용이성: Client를 통해, 사용자 인증 상태에 따른 툴 접근 권한이나, 필요한 값에 대한 검증, 정보 보안을 세심히 처리할 수 있다.
결과의 안정성: LLM(결과 추론)과 MCP서버(외부 Tool과 송수신)의 역할이 구분되기 때문에, 연동되는 3rd Party가 많아지더라도, LLM이 생성한 결과에 오류가 적을 가능성이 높을 것이다. 외부 툴을 계속 확장해도, 답변의 정확도나 사용 경험의 일관성이 어느 정도 보장되는 것이다.
예를 들어 본다면,
사용자가 "다음 달 도쿄 여행 숙소 찾아줘" 라고 요청을 했다고 가정하자.
기존의 Function call 방식으로 적용한다면, LLM이 직접 ‘숙소 예약’ Function을 호출한다. 그리고 주로 연결된 단일 API (e.g. 익스피디아 사이트)의 결과를 토대로 답변을 제공한다. Function Call의 호출 결과는 기본적으로 일회성으로 처리되며, 별도의 프레임워크나 개발자의 추가 구현 없이는 대화 컨텍스트에 자동으로 누적되지 않는다.
하나의 Function (숙소 예약)에 대해, 하나의 3rd Party 연동을 기반으로 처리하는 게 서비스의 방향이라면, 이 방식도 나쁘지 않을 것이다.
하지만 여러 3rd Party를 통해 결과 값을 받아, 최적의 가격과 장소를 추천해 주고 싶다면? 그리고 기존에 사용자가 만족/불만족했던 3rd Party나 상품 정보까지 고려해, 맞춤형 답변까지 제공하고 싶다면?
LLM이 직접 ‘숙소 예약’ 해당하는 다수의 개별 API을 호출하고, 그 값을 토대로 추론 답변을 만들어야 한다. 이 과정에서 누락된 호출이 발생하고, 추론 답변의 일관성이나 정확도는 낮아질 가능성이 생긴다.
반면, MCP 구조에서는 LLM과 MCP 서버의 역할이 분리되어 있어, 여러 외부 사이트와 통신해 더 좋은 답변을 제공하는 게 쉬워진다.
LLM은 '다음 달/ 도쿄 여행 / 숙소 예약'을 요청했다는 걸 판단하고 Client에 요청을 한다. 클라이언트는 필수 정보와 보안 여부를 체크하고, ’숙소 예약‘을 맡고 있는 MCP 서버에게 작업 처리를 요청한다. 사용자가 선호하지 않는 3rd party 사이트는 대상에서 제외시킬 수도 있다.
MCP 서버는 연동된 외부 사이트들을 호출해 해당 정보를 받아오고, 받은 정보를 클라이언트에 알려준다.
클라이언트는 수집된 정보들을 LLM이 처리할 수 있는 형태로 가공하여 LLM에 전달한다. LLM은 전체 정보에서 누락 없이 최적의 후보군을 추론하여 답변을 생성한다.
MCP 방식으로 구현된 액션형 에이전트는 유저 입장에서 일관성과 정확도가 높은 결과를 얻게 해줄 수 있다. 사용자는 ‘나를 대신하여 다양한 비교군을 검색하고, 나의 니즈에 가장 잘 맞는 곳을 좋은 가격 옵션으로 제공해 준다’고 느낄 것이다.
좀 더 쉽게 비유해 보자면,
AI를 퍼스널 쇼퍼라고 생각해 보자. 고객이 "이브닝 파티에 입을 드레스 후보 찾아서 구매해줘" 라고 퍼스널 쇼퍼에게 요청했다.
단순 Function Call 방식은 퍼스널 쇼퍼가 직접 모든 제휴사 사이트를 컨택하며 후보 드레스를 찾은 후, 고객에게 추천하는 것에 가깝다. 브랜드마다 원하는 컨택 방식도 달라, A브랜드는 전화로 B 브랜드는 메일로 컨택을 해야 한다.
브랜드가 늘어날수록 퍼스널 쇼퍼는 각각 다른 소통 방식을 기억하며 처리해야 하니 실수가 생기기 쉽고, 사용자에게 일관성 있는 서비스를 제공하기 어려워진다.
MCP는 전문가 체제의 분업 방식이다. 퍼스널 쇼퍼(LLM)가 구매 관리자(클라이언트)에게 지시를 내리면, 구매 관리자가 보안과 주요 사항을 체크한 후 해당 카테고리 담당자(서버)에게 표준화된 방식으로 요청한다.
그럼 담당자는 연결된 모든 브랜드들과 일관된 방식으로 소통하여 드레스 정보를 수집하고, 이를 정리하여 관리자에게 보고한다. 관리자는 이 정보들을 퍼스널 쇼퍼가 이해하기 쉬운 규격 문서로 작성해서 전달하고, 퍼스널 쇼퍼는 고객의 취향과 상황에 맞는 최적의 선택지는 판단하여 제공하게 된다.
둘 중 어떤 방식이 고객에게 더 좋은 선택지를 제공할 확률이 높을까? 당연히 후자일 것이다.
왜 Model Context Protocol이라 지었을까?
Anthropic은 왜 (LLM) Model과 Tool을 연결하는 Model Tool Protocol이 아니라, Model Context Protocol 이라고 이름을 지었을까?
여기엔 MCP를 통해 구현하고자 하는 철학이 담겨 있다고 생각이 된다. 단순히 AI에 외부 Tool 연결을 쉽게하는 데에 초점이 있는 게 아니라, 다양한 외부 리소스를 사용자의 context에 안전하고 표준화된 방식으로 통합하는 것이 핵심이다.
즉, 여러 툴과의 연결이 확장되고 체계화됨으로ㅌ써 AI 모델이 더 풍부한 맥락(context) 정보를 바탕으로 사용자에게 딱 맞는 결과를 제공할 수 있게 된다는 의미다. 결국 우리가 AI agent에게 기대하는 건, 나의 니즈에 딱 맞는 무언가를 찾아주고 알아서 처리도 해주는 거니깐. 때로는 스스로도 잊고 있었던 지난 선택과 취향을 참고해서 말이다.