Blog

최근 AI 분야, 특히 대규모 언어 모델(Large Language Model, 이하 LLM)의 발전은 실로 눈부십니다. 인간과 유사한 수준의 텍스트를 이해하고 생성하는 능력을 바탕으로, LLM은 이제 단순한 정보 검색 도구를 넘어 창의적인 콘텐츠 생성, 복잡한 문제 해결, 심지어 소프트웨어 코드 작성에 이르기까지 다양한 영역에서 그 가능성을 확장하고 있습니다. 하지만 LLM이 진정으로 강력한 지능형 에이전트로서 기능하기 위해서는 모델 내부에 국한된 지식을 넘어, 외부 세계의 실시간 정보에 접근하고 다양한 도구(Tool)들을 활용할 수 있는 능력이 필수적입니다.

이러한 배경에서, 미국의 AI 기업 Anthropic은 2024년 11월, LLM이 외부 세계와 상호작용하는 방식을 표준화하기 위한 중요한 제안을 내놓았습니다. 바로 모델 컨텍스트 프로토콜(Model Context Protocol, 이하 MCP)입니다. 본 포스팅에서는 IT 전문가 및 의사결정자 여러분을 위해 MCP가 무엇이며, 왜 등장했고, 어떤 구조를 가지며, 기존의 에이전트 간 통신(A2A)과는 어떤 차별점을 갖는지 심도 있게 살펴보도록 하겠습니다.

특히 MSA, 쿠버네티스, 클라우드 네이티브와 같은 현대적인 기술 트렌드를 처음 접하시는 분들이나, 이러한 기술 도입을 고민하시는 의사결정자분들께서는 이번 논의를 통해 각 아키텍처의 핵심 철학과 실질적인 효용을 파악하시는 데 큰 도움을 받으실 수 있을 것입니다.

마치 전문가가 옆에서 친절하게 설명해주는 책을 읽듯, 편안하게 따라와 주시기 바랍니다.

MCP의 핵심은 LLM이 외부의 다양한 툴(Tool)이나 서비스, 데이터베이스 등과 소통할 때 사용되는 표준 통신 규약, 즉 프로토콜이라는 점입니다. 현재 많은 LLM 기반 애플리케이션들은 저마다의 방식으로 외부 API를 호출하거나 데이터를 주고받고 있습니다. 이는 개발의 파편화를 야기하고, 서로 다른 시스템 간의 상호 운용성을 저해하며, 새로운 툴을 통합할 때마다 상당한 개발 비용을 발생시키는 요인이 됩니다.

MCP는 이러한 문제점을 해결하기 위해 LLM과 외부 툴 간의 일관되고 예측 가능한 상호작용 방식을 정의합니다. 마치 웹 서비스들이 HTTP와 REST API라는 표준을 통해 소통하듯, LLM도 MCP라는 표준을 통해 다양한 외부 기능들을 마치 자신의 확장 기능처럼 유연하게 활용할 수 있게 되는 것입니다.

이를 위해 MCP는 기본 통신 프로토콜로 JSON-RPC 2.0을 채택하고 있습니다. JSON-RPC 2.0은 매우 가볍고(lightweight) 상태 비저장(stateless) 특성을 가지며, 요청(request)과 응답(response) 메시지를 JSON(JavaScript Object Notation) 형식으로 표현하는 원격 프로시저 호출(Remote Procedure Call, RPC) 프로토콜입니다. 이미 널리 사용되고 있는 JSON 형식을 기반으로 하기에 다양한 프로그래밍 언어와 환경에서 쉽게 구현하고 통합할 수 있다는 장점이 있으며, 명확한 오류 처리 메커니즘도 포함하고 있어 안정적인 통신을 지원합니다. MCP는 이 JSON-RPC 2.0 규격을 기반으로 LLM과 툴 간의 메시지 구조, 호출 방식, 데이터 교환 형식 등을 구체적으로 정의함으로써, 개발자들이 보다 손쉽게 LLM 연동 툴을 개발하고 배포할 수 있는 생태계를 조성하는 것을 목표로 합니다.

앞서 언급했듯이, MCP(Model Context Protocol)는 2024년 11월, AI 전문 기업인 Anthropic에 의해 처음 공개되었습니다. Anthropic은 자연어 처리 분야에서 Claude라는 강력한 대형 언어 모델(LLM)을 개발한 기업으로, 단순히 챗봇 기능을 넘어 다양한 외부 시스템과의 연동이 가능한 AI를 추구해왔습니다. MCP는 이러한 맥락에서 등장한 기술적 결과물로, 단순한 API 수준의 통합을 넘어서 AI가 외부 툴과 안전하고 일관된 방식으로 상호작용할 수 있도록 설계된 표준화된 인터페이스 프로토콜입니다.

Anthropic이 MCP를 제안한 가장 근본적인 이유는, 대형 언어 모델의 활용이 본격화되면서 그 쓰임새가 더 이상 단일 텍스트 응답에 머물 수 없게 되었기 때문입니다. LLM은 이제 단순한 질의응답을 넘어서, 특정 문서 기반 검색, 복잡한 수식 계산, 데이터베이스 조회, 캘린더 예약, 실시간 정보 조회, 심지어는 장치 제어 등까지 다양한 영역으로 확장되고 있습니다. 그러나 이런 외부 기능을 호출하는 방식은 기존까지는 각 AI 제품마다 독자적으로 구성되어 있어, 개발자와 사용자 모두에게 과도한 복잡성을 안기는 문제를 야기했습니다.

Anthropic은 이처럼 난립한 통합 방식이 산업 생태계 전반에 비효율을 초래하고 있다고 판단했고, LLM이 외부 툴과 안전하고 일관되게 연결될 수 있는 표준이 필요하다는 문제의식을 바탕으로 MCP를 오픈소스 프로젝트로 선언합니다. MCP는 단순히 하나의 프로토콜이라기보다는, 툴 호출을 위한 계약 형식(Contract), 안전한 통신 경로, 실행 구조에 대한 명세까지 포함한 포괄적인 아키텍처 모델이라 할 수 있습니다.

LLM과 툴의 연동이 본격화되면서 다음과 같은 구조적인 문제들이 표면화되었습니다:

1. 연동 방식의 난립으로 인한 개발 복잡성LLM마다 툴을 부르는 방식이 달라, 개발자는 동일한 기능을 구현하기 위해 각 모델마다 따로 코드를 작성해야 했습니다. 이는 유지보수와 확장성 측면에서 큰 부담으로 작용했고, 결과적으로 LLM의 상호 교체 가능성도 낮추는 요인이 되었습니다.
2. 호환성과 상호 운용성의 부재특정 LLM에 최적화된 툴이 다른 모델에서는 작동하지 않거나, 추가적인 변환 작업이 필요했습니다. 이로 인해 툴 생태계는 단절되었고, AI 툴 개발의 재사용성이 떨어졌습니다. 이는 툴 공급자 입장에서 시장 확장의 걸림돌이 되었고, 사용자 입장에서는 플랫폼 종속성을 키우는 결과를 낳았습니다.
3. 보안 및 통제의 어려움LLM이 외부 시스템을 호출하고 그 결과를 응답에 포함할 때, 그 과정이 명시적이지 않거나, 통제 불가능한 방식으로 이루어진다면 보안 위협이 발생할 수 있습니다. MCP는 이러한 위험 요소를 줄이기 위해 툴 호출 방식과 데이터 전달 형식을 명확히 정의된 JSON-RPC 기반의 표준으로 통일하고, 모든 입력과 출력이 추적 가능하게 설계되어 있습니다.

MCP는 이러한 문제들을 해결하고, LLM과 툴 간의 연결을 구조적으로 일원화함으로써 생태계 전체의 확장성과 신뢰성을 높이는 데 핵심적인 역할을 하게 됩니다. 구체적으로 다음과 같은 변화가 기대됩니다:

• 툴을 하나만 만들면 여러 LLM에서 재사용 가능
• 보안 정책과 응답 형식의 일관성 확보
• 툴 실행 과정을 LLM이 통제 가능한 범위 내에서 명확히 인식
• LLM 기반 에이전트(AI Agent)의 실제 활용 범위 확대

궁극적으로 MCP는 단순한 기술 스펙을 넘어, LLM 중심 애플리케이션 생태계의 새로운 기초 인프라로 작용하게 될 가능성이 큽니다. 개발자는 특정 LLM에 종속되지 않고 다양한 툴을 자유롭게 개발할 수 있으며, 사용자들은 더 많은 기능과 옵션을 손쉽게 활용할 수 있게 됩니다. 이와 같은 선순환 구조는 향후 LLM이 단순 응답형 챗봇을 넘어서, 진정한 에이전트 형태의 AI로 진화하는 데 결정적인 역할을 하게 될 것입니다.

MCP의 아키텍처는 LLM을 중심으로 외부 툴과의 안정적이고 유연한 연동을 지원하도록 설계되었습니다. 기본적인 구성은 MCP 호스트(Host, 또는 Agent), 클라이언트(Client), 그리고 툴을 포함하는 서버(Server) 형태로 이루어집니다. 각 구성 요소의 역할은 다음과 같습니다.

📌MCP Host (호스트 ), Agent

• • MCP 호스트는 대개 LLM 자체 또는 LLM의 기능을 조율하는 에이전트 시스템을 의미합니다. 사용자의 요청을 받아 분석하고, 특정 작업을 수행하기 위해 외부 툴의 도움이 필요하다고 판단되면 MCP 클라이언트를 통해 해당 툴 서버에 요청을 지시하는 역할을 합니다. 예를 들어, “내일 서울 날씨를 알려주고, 비가 오면 우산을 챙기라는 메시지를 캘린더에 등록해줘”라는 요청을 받으면, 호스트는 ‘날씨 정보 조회 툴’과 ‘캘린더 등록 툴’을 순차적으로 호출할 필요성을 인지합니다.
  • MCP 클라이언트는 다음과 같은 기능을 지원할 수 있습니다:
    • 리소스(Resources): AI 모델이 접근할 수 있는 데이터 소스입니다.
    • 프롬프트(Prompts): AI 모델의 응답을 유도하는 템플릿입니다.
    • 도구(Tools): AI 모델이 호출할 수 있는 함수나 API입니다.
    • 디스커버리(Discovery): 클라이언트가 서버의 기능을 탐색할 수 있는 기능입니다.
    • 샘플링(Sampling): 서버가 클라이언트에 에이전트 행동을 제안할 수 있는 기능입니다.
    • 루트(Roots): AI 모델의 상호작용을 추적하고 관리하는 기능입니다.

📌MCP Client (클라이언트 )

• • 클라이언트는 MCP 호스트 내부에 존재하거나 호스트와 긴밀하게 연동되어, 특정 작업을 수행하기 위해 외부 툴 서버에 요청을 보내는 역할을 담당합니다. 호스트의 지시에 따라 JSON-RPC 2.0 규격에 맞는 요청 메시지를 생성하여 툴 서버로 전송하고, 서버로부터 응답을 받아 다시 호스트에게 전달합니다. 이 과정에서 통신 채널 관리, 요청/응답 직렬화 및 역직렬화 등을 처리합니다.

📌MCP Server (서버, Tool 포함)

• • 서버는 LLM이 외부 시스템과 통신할 수 있도록 중개 역할을 합니다. 이러한 서버는 다음과 같은 세 가지 주요 구성 요소를 제공합니다:
    • Tools: LLM이 특정 작업을 수행할 수 있도록 하는 기능입니다. 예를 들어, 파일 읽기/쓰기, API 호출 등이 있습니다.
    • Resources: LLM이 참조할 수 있는 데이터 소스입니다. 예를 들어, 데이터베이스 쿼리 결과나 문서 내용 등이 포함됩니다.
    • Prompts: LLM과의 상호작용을 위한 사전 정의된 입력 템플릿입니다.
  • 서버는 실제 툴의 기능을 캡슐화하고 있으며, 클라이언트로부터 MCP 규격에 따른 요청을 받아 해당 툴을 실행하고 그 결과를 다시 클라이언트에게 전달합니다. 예를 들어, ‘날씨 정보 조회 툴 서버’는 특정 지역과 날짜를 입력받아 해당 날씨 정보를 반환하는 API를 내부에 가지고 있으며, MCP 요청을 해석하여 이 API를 호출하고 결과를 JSON-RPC 2.0 응답 형식으로 가공하여 클라이언트에게 회신합니다.

MCP 클라이언트와 MCP 서버는 JSON-RPC 메시지를 주고받는 통신 경로만 표준화되어 있을 뿐, 물리적 통신 경로 자체는 여러 방식을 활용할 수 있습니다. MCP 명세에서는 로컬 통신과 원격 통신 두 가지 상황을 모두 지원하기 위해 STDIO와 HTTP(SSE) 방식을 모두 정의하고 있습니다.

1. stdio (Standard Input/Output) 방식:
   • 개념: stdio 방식은 주로 클라이언트와 서버(툴)가 동일한 시스템 내에서 로컬 프로세스로 실행될 때 유용합니다. 클라이언트는 실행하고자 하는 툴 프로세스를 자식 프로세스로 생성하고, 이 자식 프로세스의 표준 입력(stdin)을 통해 MCP 요청을 전달하며, 표준 출력(stdout)을 통해 MCP 응답을 수신합니다.
   • 특징: 구현이 비교적 간단하고, 네트워크 설정 없이 로컬 환경에서 빠르게 툴을 연동할 수 있다는 장점이 있습니다. 하지만, 네트워크를 통한 원격 통신이나 비동기적 스트리밍에는 제약이 따릅니다. 주로 개발 초기 단계나 간단한 로컬 툴 연동에 적합합니다.
2. SSE (Server-Sent Events) 방식:
   • 개념: SSE는 서버가 클라이언트에게 단방향으로 지속적인 데이터 스트림을 보낼 수 있게 하는 HTTP 기반 프로토콜입니다. 클라이언트가 서버에 한 번 연결 요청을 하면, 서버는 해당 연결을 유지하면서 필요할 때마다 클라이언트에게 이벤트(데이터)를 푸시(push)할 수 있습니다.
   • 특징: SSE는 LLM이 툴의 진행 상황을 실시간으로 받거나, 긴 작업의 중간 결과들을 순차적으로 받아 처리해야 할 때 매우 효과적입니다. 예를 들어, 복잡한 데이터 분석 툴이 실행되는 동안 중간 분석 결과를 스트리밍 형태로 LLM에게 전달하여 사용자가 진행 상황을 파악하거나, LLM이 다음 단계를 미리 준비할 수 있도록 합니다. WebSocket과 유사하지만, SSE는 서버에서 클라이언트로의 단방향 통신에 특화되어 있어 구현이 더 단순하고 특정 시나리오에 더 적합할 수 있습니다. 원격 툴과의 연동이나 비동기적 응답 처리가 필요한 경우 강력한 선택지가 됩니다.

이러한 통신 방식을 통해 MCP는 로컬 환경의 간단한 툴부터 네트워크 너머의 복잡한 서비스까지 다양한 외부 자원들을 일관된 방식으로 LLM에 통합할 수 있는 유연성을 제공합니다.

MCP에서 언급되는 ‘툴(Tools)’이란 매우 광범위한 개념을 포괄합니다. 단순히 특정 기능을 수행하는 작은 유틸리티 프로그램부터, 복잡한 비즈니스 로직을 처리하는 외부 서비스, 방대한 데이터를 저장하고 있는 데이터베이스, 심지어는 IoT 장치 제어 인터페이스까지도 툴이 될 수 있습니다.

구체적으로 예를 들자면 다음과 같습니다:

• 정보 검색 툴: 웹 검색 API, 특정 주제의 학술 논문 검색기, 기업 내부 문서 검색 시스템
• 계산 및 데이터 처리 툴: 고급 계산기, 통계 분석 패키지, 코드 실행기(Python, SQL 등), 데이터 변환 및 시각화 도구
• 외부 서비스 연동 툴: 이메일 발송기, 캘린더 일정 등록기, 소셜 미디어 포스팅 도구, 전자상거래 플랫폼 API
• 데이터베이스 접근 툴: SQL 데이터베이스 쿼리 실행기, NoSQL 데이터베이스 인터페이스
• 하드웨어/장치 제어 툴: 스마트 홈 장치 제어 API, 로봇 팔 제어 인터페이스

중요한 것은 LLM이 스스로 수행할 수 없는 작업, 또는 외부의 실시간 정보나 특정 시스템의 기능을 활용해야 하는 작업을 대신 처리해 줄 수 있는 모든 외부 기능 또는 서비스가 MCP의 컨텍스트에서는 ‘툴’로 간주될 수 있다는 점입니다. MCP는 이러한 다양한 툴들이 LLM과 표준화된 방식으로 ‘대화’할 수 있도록 하는 약속인 것입니다. 이를 통해 툴 개발자들은 자신의 툴을 더 넓은 LLM 생태계에 쉽게 제공할 수 있고, LLM 개발자들은 풍부한 툴들을 손쉽게 활용하여 더욱 강력하고 지능적인 애플리케이션을 구축할 수 있게 됩니다.

MCP에 대해 이해하셨다면, 이제 또 다른 중요한 개념인 A2A(Agent-to-Agent) 통신과의 관계를 짚어볼 필요가 있습니다. A2A는 말 그대로 자율적으로 판단하고 행동하는 소프트웨어 에이전트들 간의 상호작용 및 통신을 의미합니다. 여기서 에이전트는 LLM 기반의 지능형 에이전트일 수도 있고, 특정 작업을 수행하는 규칙 기반 에이전트일 수도 있으며, 심지어는 여러 에이전트가 결합된 복합 에이전트일 수도 있습니다.

MCP와 A2A의 관계를 명확히 이해하기 위해 그 차이점과 각자의 역할을 구분해 보겠습니다.

• MCP (Model Context Protocol):
  • 초점: MCP는 주로 LLM(에이전트의 일종)이 특정 기능을 수행하는 외부 툴(일종의 서비스 에이전트 또는 기능 모듈)과 통신하기 위한 저수준 프로토콜에 가깝습니다. 즉, ‘어떻게’ 데이터를 주고받을 것인가(JSON-RPC 2.0 기반), 어떤 형식으로 요청하고 응답할 것인가에 대한 구체적인 약속입니다.
  • 범위: LLM과 단일 툴 간의 직접적인 상호작용을 표준화하는 데 중점을 둡니다. 툴의 발견, 호출, 결과 수신 과정에 대한 명확한 규약을 제공합니다.
  • 역할: LLM이 외부 기능을 안정적이고 효율적으로 사용할 수 있도록 하는 ‘기술적 통신 규약’ 입니다. 다양한 툴들이 LLM과 쉽게 통합될 수 있도록 하는 인터페이스 표준 역할을 합니다.
• A2A (Agent-to-Agent) 통신:
  • 초점: A2A는 보다 광범위한 에이전트 간의 상호작용 프레임워크나 철학을 의미할 수 있습니다. 여기에는 여러 에이전트가 협력하여 복잡한 목표를 달성하기 위한 작업 분배, 협상, 신뢰 구축, 목표 공유, 역할 조정 등의 고수준 상호작용이 포함될 수 있습니다.
  • 범위: 두 개 이상의 자율적 에이전트 간의 모든 형태의 소통을 포괄합니다. 이는 단순한 정보 교환을 넘어, 공동의 목표 달성을 위한 복합적인 협업 과정을 포함할 수 있습니다.
  • 역할: 지능형 시스템이 개별 에이전트의 능력을 뛰어넘는 복잡한 문제를 해결하기 위해 ‘협력하고 조율하는 방식’ 에 대한 개념입니다. A2A는 특정 프로토콜에 국한되지 않고, FIPA ACL(Agent Communication Language)과 같은 에이전트 통신 언어나 멀티 에이전트 시스템(Multi-Agent System, MAS) 아키텍처 등 다양한 형태로 구현될 수 있습니다.

역할 측면에서 보면, MCP는 A2A 통신의 한 가지 구체적인 구현 방식 또는 하위 구성 요소로 활용될 수 있습니다. 예를 들어, 여러 AI 에이전트가 협업하는 A2A 시나리오에서 특정 에이전트(예: 작업 계획 에이전트)가 데이터 분석 툴(또는 데이터 분석 전문 에이전트)을 사용해야 할 때, 해당 에이전트와 툴(또는 툴을 제공하는 에이전트) 간의 통신은 MCP를 통해 이루어질 수 있는 것입니다.

다시 말해, MCP는 A2A라는 큰 그림 안에서, LLM 에이전트가 특정 ‘기능’을 가진 외부 컴포넌트(툴)와 소통하는 구체적인 ‘언어’와 ‘문법’을 제공한다고 볼 수 있습니다. 반면 A2A는 에이전트들이 서로의 ‘의도’를 전달하고, ‘작업’을 요청하며, ‘결과’를 공유하는 등 보다 포괄적인 상호작용의 틀을 다룹니다.

따라서 MCP는 A2A와 경쟁하거나 대체하는 관계가 아니라, A2A 환경에서 LLM 에이전트의 툴 활용 능력을 강화하고 표준화함으로써 전체 시스템의 효율성과 확장성을 높이는 데 기여하는 보완적인 관계에 있다고 이해하는 것이 적절합니다. MCP는 툴 연동의 ‘표준 인터페이스’를 제공함으로써 A2A 환경에서 에이전트들이 다양한 툴을 일관된 방식으로 활용할 수 있는 기반을 마련해 줍니다.

*https://github.com/modelcontextprotocol/servers을 번역한 내용입니다.

이 저장소는 MCP( 모델 컨텍스트 프로토콜 ) 에 대한 참조 구현 과 커뮤니티에서 구축한 서버 및 추가 리소스에 대한 참조를 모아 놓은 곳입니다.

이 저장소의 서버는 MCP의 다재다능함과 확장성을 보여주며, 대규모 언어 모델(LLM)에 도구 및 데이터 소스에 대한 안전하고 제어된 액세스를 제공하는 데 어떻게 사용될 수 있는지 보여줍니다. 각 MCP 서버는 Typescript MCP SDK 또는 Python MCP SDK 로 구현됩니다 .

참고: 이 README의 목록은 새 항목을 추가할 때 병합 충돌을 최소화하기 위해 알파벳순으로 정리되었습니다.

📌MCP 레퍼런스 서버

• • 이러한 서버는 MCP 기능과 TypeScript 및 Python SDK를 시연하는 것을 목표로 합니다.
    • Everything – 프롬프트, 리소스 및 도구가 포함된 참조/테스트 서버
    • Fetch – 효율적인 LLM 사용을 위한 웹 콘텐츠 페치 및 변환
    • Filesystem – 구성 가능한 액세스 제어를 통한 안전한 파일 작업
    • Git – Git 저장소를 읽고, 검색하고, 조작하는 도구
    • Memory– 지식 그래프 기반 지속 메모리 시스템
    • Sequential Thinking – 사고 순서를 통한 역동적이고 반성적인 문제 해결
    • Time – 시간 및 시간대 변환 기능

📌Archived

• • 다음 참조 서버는 현재 보관되어 servers-archived 에서 찾을 수 있습니다 .
    • AWS KB 검색 – Bedrock Agent Runtime을 사용하여 AWS 지식 기반에서 검색
    • Brave Search – Brave의 검색 API를 사용한 웹 및 로컬 검색
    • EverArt – 다양한 모델을 활용한 AI 이미지 생성
    • GitHub – 저장소 관리, 파일 작업 및 GitHub API 통합
    • GitLab – GitLab API를 통해 프로젝트 관리 가능
    • Google 드라이브 – Google 드라이브의 파일 액세스 및 검색 기능
    • Google 지도 – 위치 서비스, 길찾기 및 장소 세부 정보
    • PostgreSQL – 스키마 검사를 통한 읽기 전용 데이터베이스 액세스
    • Puppeteer – 브라우저 자동화 및 웹 스크래핑
    • Redis – Redis 키-값 저장소와 상호 작용
    • Sentry – Sentry.io에서 문제 검색 및 분석
    • Slack – 채널 관리 및 메시징 기능
    • Sqlite – 데이터베이스 상호 작용 및 비즈니스 인텔리전스 기능

자세한 내용은 아래의 MCP Server 레퍼런스를 참조해 주세요.
https://github.com/modelcontextprotocol/servers

Model Context Protocol(MCP)는 AI 애플리케이션과 외부 도구 및 데이터 소스 간의 통합을 표준화하는 개방형 프로토콜입니다. MCP를 지원하는 다양한 클라이언트 애플리케이션이 존재하며, 각 클라이언트는 MCP 서버와의 통합 수준에 따라 다양한 기능을 지원합니다. 이러한 기능에는 리소스(Resources), 프롬프트(Prompts), 도구(Tools), 디스커버리(Discovery), 샘플링(Sampling), 루트(Roots) 등이 포함됩니다.

다음은 MCP를 지원하는 클라이언트 애플리케이션의 일부 예시입니다:

• Claude.ai: Anthropic의 AI 플랫폼으로, 도구, 프롬프트, 리소스를 지원합니다.
• Claude Desktop App: 로컬 및 원격 MCP 서버에 연결하여 도구, 프롬프트, 리소스를 활용할 수 있습니다.
• Continue: 개발자 도구로, 도구, 프롬프트, 리소스를 지원합니다.
• fast-agent: 다양한 MCP 기능을 지원하는 멀티모달 클라이언트로, 샘플링과 루트 기능도 포함되어 있습니다.
• Postman: API 테스트 도구로, 도구, 리소스, 프롬프트, 샘플링을 지원합니다.
• VS Code GitHub Copilot: Visual Studio Code의 확장으로, 도구와 루트 기능을 지원합니다.

각 클라이언트는 특정 기능을 지원하며, 사용자의 요구에 따라 적절한 클라이언트를 선택할 수 있습니다.

각 클라이언트는 이러한 기능 중 일부 또는 전부를 지원하며, 자세한 내용은 MCP 클라이언트 목록에서 확인할 수 있습니다.

지금까지 우리는 LLM의 기능 확장을 위한 핵심 프로토콜, MCP에 대해 자세히 살펴보았습니다. MCP는 Anthropic이라는 선도적인 AI 기업이 제안한 만큼, LLM과 외부 툴 생태계에 상당한 영향을 미칠 것으로 예상됩니다. 이 프로토콜이 성공적으로 정착된다면, 개발자들은 더욱 혁신적이고 다양한 LLM 연동 툴을 손쉽게 개발하고 공유할 수 있게 될 것이며, 이는 곧 LLM 기술의 대중화와 응용 분야 확대로 이어질 것입니다.

IT 전문가 및 의사결정자 여러분께서는 MCP와 같은 표준화 동향을 주시하시고, 향후 LLM 기반 솔루션 도입 및 개발 전략 수립 시 이러한 기술적 변화를 적극적으로 고려하시길 권합니다. 표준화된 프로토콜은 기술의 성숙도를 높이고, 생태계를 풍요롭게 하며, 궁극적으로는 사용자에게 더 나은 가치를 제공하는 핵심 동력이기 때문입니다. MCP가 만들어갈 LLM의 새로운 미래를 기대해 봅니다.

• modelcontextprotocol.io
• modelcontextprotocol/servers
• Model Context Protocol
• Examples | Model Context Protocol
• Awesome MCP Servers
• Use MCP Servers in Visual Studio Code
• Intro to MCP (YouTube)