모델 컨텍스트 프로토콜(MCP)이란 무엇인가요?

AI 모델은 점점 더 강력해지고 있지만, 한 가지 문제가 있습니다. 이들은 훈련 중에 배운 정보에만 접근할 수 있기 때문에 그들이 알고 있는 것과 할 수 있는 것에 한계가 있습니다. 마치 매우 똑똑한 비서를 고용했지만, 그 비서는 이미 머릿속에 있는 내용만 가지고 일할 수 있고, 자료를 찾거나 파일을 확인하거나 실제 업무를 여러분 대신 수행할 수는 없는 것과 같습니다.

대규모 언어 모델(LLM)은 컨텍스트에 접근하고 다른 도구 및 애플리케이션에서 작업을 수행할 수 있을 때 훨씬 더 강력해집니다. 최근까지는 이러한 모델들을 다른 앱과 연결할 수 있는 통일된 방식이 없었습니다. Anthropic이 처음 개발한 모델 컨텍스트 프로토콜(MCP)은 AI 에이전트 시스템이 다른 애플리케이션과 인터페이스하는 표준 방식으로 빠르게 자리 잡고 있으며, AI의 "USB-C 커넥터"가 되었습니다.

Figma가 MCP를 지원하는 방법에 대해 더 자세히 알아보려면 Figma의 MCP 서버를 소개하는 블로그 게시물을 확인해 보세요. 이제 MCP가 무엇인지, 어떻게 작동하는지, 그리고 이것이 왜 중요한지 자세히 알아보겠습니다.

MCP란?

모델 컨텍스트 프로토콜(MCP)은 AI 기반 시스템이 소프트웨어 애플리케이션, 도구, 플랫폼에 연결되는 방식에 대한 오픈 소스 표준입니다.

MCP는 양방향 통신 프로토콜입니다. 한쪽에는 LLM이 자신의 소프트웨어에서 데이터에 접근하고 작업을 수행할 수 있기를 원하는 데이터 제공자와 앱 개발자가 있습니다. 이들은 MCP 서버라고 불리는 것을 구축하여 MCP를 지원합니다. 한편으로는, AI 기반 도구나 AI 에이전트 시스템을 구축하는 개발자들이 있습니다. 이들은 MCP 클라이언트를 구현하며, 이를 통해 AI 모델이 MCP 서버에 연결하여 컨텍스트를 가져오고 다른 앱에서 작업을 수행할 수 있습니다.

예를 들어, Cursor와 같은 AI 코딩 도구에는 Figma와 GitHub이 제공하는 MCP 서버에 연결할 수 있는 MCP 클라이언트가 포함되어 있을 수 있습니다. 클라이언트와 서버 간의 통신은 마치 HTTP가 인터넷 통신 프로토콜을 정의하는 것과 같이 표준 프로토콜을 사용해 이루어집니다. MCP는 어떤 종류의 메시지를 보낼 수 있는지, 메시지 형식은 어떠해야 하는지, 인증은 어떻게 작동하는지 등을 구체적으로 명시합니다.

문제: 왜 MCP가 필요한가

다가오는 휴가를 위한 항공권 예약, 주간 판매 보고서를 위한 분석 데이터 수집, 새로운 기능의 프로토타입 제작과 같은 작업은 LLM의 학습 데이터 이상의 다양한 앱과 서비스 생태계로 확장되는 컨텍스트가 필요합니다. AI 어시스턴트가 더 많은 컨텍스트를 가질수록 요청의 구체적인 뉘앙스를 더 잘 이해하고, 더 높은 품질의 결과를 제공할 수 있습니다.

디자인 파일로부터 코드를 생성하기 위해 AI 코딩 도구를 사용하는 상황이라고 생각해 보겠습니다. LLM이 파일의 스크린샷을 보고 훈련 데이터를 사용하여 픽셀을 해석한다면, 대략적인 프로토타입을 만들 수 있을지도 모릅니다. 하지만 정말로 유용한 최종 제품을 얻으려면 구체적인 변수, 컴포넌트, 스타일, 또는 기능을 설명하는 의사코드 같은 더 많은 컨텍스트가 필요합니다. 이러한 컨텍스트는 AI에게 매우 귀중하지만, 일반적으로 Figma와 같은 다른 도구 내부 깊은 곳에 저장되어 있습니다.

MCP 이전에는 AI 에이전트 도구를 개발하는 모든 개발자가 외부 앱 및 서비스와의 맞춤형 통합을 구축해야 했으며, 그 결과 개발 속도 저하와 생태계 파편화가 발생했습니다. 각 앱마다 데이터와 함수를 노출하는 방식이 저마다 조금씩 달랐기 때문에, 새로운 통합을 할 때마다 상당한 양의 사전 작업이 필요했습니다.

MCP는 이 문제에 대해 "한 번 작성하면 어디서든 사용할 수 있는(write once, use anywhere)" 방식으로 접근합니다. 앱 개발자는 모든 AI 에이전트 시스템에서 사용할 수 있는 하나의 MCP 서버를 개발하여, 오류 처리 같은 유용한 기능과 함께 표준화된 도구 및 데이터를 제공할 수 있습니다. 마찬가지로, AI 시스템은 프로토콜을 구현하여 현재 존재하는 혹은 미래에 등장할 그 어떤 MCP 서버와도 연결할 수 있습니다.

MCP의 기원

MCP는 2024년 여름, Claude Desktop이 로컬 파일 시스템과 같은 데이터 소스와 더 쉽게 작업할 수 있도록 하기 위해 Anthropic에서 시작되었습니다.. 개발자들은 Microsoft의 언어 서버 프로토콜(LSP)에서 영감을 받았는데, 이는 다양한 프로그래밍 언어에서 통합 개발 환경(IDE)이 문맥 강조 표시나 코드 자동 완성 같은 기능을 지원하는 방식에 대한 표준입니다.

프로토콜을 구축하고 내부에서 사용한 후, Anthropic은 2024년 11월에 MCP를 오픈 소스로 공개하여 전체 프로토콜 명세를 문서 및 SDKS(예: Python)와 함께 공개했습니다.

그 이후로 채택이 크게 증가했습니다. 2025년 1월과 2월에는 Cursor 및 Windsurf와 같은 AI IDE가 MCP를 지원하기 시작했습니다. 3월에 OpenAI가 MCP 지원을 추가했으며, GitHub가 곧이어 자체 MCP 서버를 공개했습니다. 시장에 자리 잡은 제품들도 MCP를 채택하고 있습니다. Microsoft Windows는 향후 몇 달 내에 이 프로토콜을 지원할 예정이라고 발표했습니다.

MCP는 어떻게 작동하나요?

MCP는 본질적으로 요청과 응답을 주고받는 과정으로, LLM이 데이터를 요청하거나 작업을 트리거하면 외부 앱이 이에 응답합니다. 네트워크 용어로 말하자면, MCP는 한쪽(클라이언트)이 요청을 보내면 다른 쪽(서버)이 데이터를 반환하거나 작업을 수행하는 클라이언트-서버 아키텍처를 따릅니다.

MCP 명세는 서버가 클라이언트에게 제공하는 세 가지 유형의 기능을 다음과 같이 정의합니다.

• 리소스: 데이터베이스 레코드, 파일, 스크린샷, 코드 블록 등 앱이 LLM에 제공하는 데이터와 콘텐츠입니다.
• 도구: 앱에서 작업을 수행하는 기능들로, 예를 들어, PostgreSQL MCP 서버는 데이터베이스 내에서 SQL 쿼리를 실행하는 도구를 노출할 수 있습니다.
• 프롬프트: AI 시스템이 사용할 수 있도록 사전 정의된 텍스트 템플릿과 업무 흐름으로, 앱의 리소스 및 도구와 원활하게 연동되도록 디자인되어 있습니다.

MCP는 서버가 리소스, 도구, 프롬프트를 클라이언트에게 표준화된 방식으로 노출하는 방법을 정의하며, 여기에는 다음이 포함됩니다.

• 응답 형식: 데이터는 JSON 블롭, SQL 행 또는 심지어 원시 이미지로 전송될 수 있으며, MCP 서버는 받은 데이터가 무엇이든 MCP 클라이언트가 기대하는 표준 형식(JSON-RPC 2.0)으로 변환합니다.
• 명령어 파싱: MCP 서버는 번역기 역할을 수행하여, LLM의 요청을 API 호출과 같이 앱이 처리할 수 있는 명령어로 변환합니다.
• 오류 처리: MCP는 표준 오류 코드를 정의하고 오류를 다시 LLM으로 보내 작업을 재시도하거나 사용자에게 도움을 요청할 수 있도록 합니다.
• 도구 탐색: MCP 서버는 해당 서버에서 사용 가능한 도구 목록을 보여주는 기능을 제공하므로, AI 시스템이 외부 앱에서 수행할 수 있는 작업을 빠르게 확인할 수 있습니다.

아키텍처: MCP 호스트, 클라이언트, 서버

MCP는 네트워킹 분야의 공통적인 아키텍처 패턴을 기반으로 하며, 호스트, 클라이언트, 서버를 포함합니다. 프로토콜은 각 역할에 대한 구체적인 책임을 정의합니다.

• MCP 호스트: 호스트는 클라이언트와 서버 간의 탐색, 권한, 통신을 관리합니다. 일반적으로 호스트는 Windows OS나 Claude Desktop과 같이 사용자가 AI 에이전트에 접해서 작업을 수행하는 제품이나 플랫폼을 의미합니다. 모델이 외부 앱에 접근해야 하는 경우, 호스트는 해당 앱의 MCP 서버와 그에 일치하는 클라이언트를 실행하고 연결해 줍니다.
• MCP 클라이언트: 클라이언트는 MCP 서버에 연결을 시작하고 유지하며, 서버당 클라이언트는 하나입니다. 클라이언트는 LLM과 MCP 서버 간에 요청과 응답을 주고받는 역할을 합니다.
• MCP 서버: 서버는 외부 시스템(Figma, Google Drive, Postgres 등)에 직접 연결되어, LLM이 데이터와 기능에 접근할 수 있도록 합니다. MCP 서버는 MCP 클라이언트로부터 요청을 받아 API 호출이나 데이터베이스 쿼리와 같은 외부 앱용 명령으로 변환합니다. 또한, 앱의 응답을 받아 이를 표준 형식으로 파싱합니다. 앱 개발자가 MCP 서버를 구현하기 때문에 LLM이 접근할 수 있는 항목을 제어할 수 있으며, 해당 프로토콜이 보안 및 권한에 관한 가이드라인을 제공합니다.

각 요소들이 어떻게 서로 맞물리는지 확인하기 위해, Figma의 MCP 서버를 사용하는 업무 흐름을 살펴보겠습니다.

• 사용자가 MCP가 활성화된 AI 코딩 도구인 Cursor를 자신의 코드 저장소에서 엽니다.
• 사용자는 Cursor의 LLM에 최신 Figma 파일을 가져와 코드베이스에 구현해 달라고 요청합니다.
• Cursor는 Figma MCP 서버와 해당하는 MCP 클라이언트를 실행합니다.
• LLM은 클라이언트를 통해 서버로부터 사용 가능한 프롬프트, 리소스, 도구 목록을 받습니다.
• 그런 다음 LLM은 호출하려는 도구와 관련된 매개변수(예: Figma 파일 ID)를 포함한 메시지를 서버에 보냅니다. 서버는 이를 API 요청 형식으로 변환하고 Figma의 API를 통해 요청을 전송합니다.
• 서버는 Figma API 응답으로부터 파일 데이터가 올 때까지 기다렸다가 이를 문자열로 형식으로 변환하여 클라이언트를 통해 LLM에 다시 전송합니다.
• Figma로부터 필요한 모든 추가 컨텍스트를 확보하고 난 다음, LLM이 Cursor 내에서 관련된 코드 생성을 시작할 수 있습니다.

MCP의 장점: AI 통합에서 MCP가 중요한 이유

개발자들이 MCP를 채택하는 이유는 LLM을 앱에 연결하는 과정을 단순화해 주기 때문입니다. 맞춤형 통합과 비교했을 때, MCP는 여러 가지 장점이 있습니다.

첫째, AI 에이전틱 시스템 개발자가 MCP를 한 번만 통합해 두면 그 후에 어떤 MCP 서버든 사용할 수 있습니다. 외부 애플리케이션 개발자도 MCP 서버를 한 번만 구축하면, 그 후에는 MCP를 지원하는 모든 AI 도구가 해당 서버에 연결할 수 있습니다.

둘째, 모든 MCP 서버와 클라이언트가 동일한 핵심 인터페이스를 제공해야 하므로, 서버나 클라이언트를 전환하는 작업이 매우 간단합니다. 즉, 개발자와 사용자가 Dropbox 및 Google Docs, 또는 Slack 및 Microsoft Teams와 같은 앱 사이를 쉽게 전환할 수 있다는 의미입니다.

마지막으로, AI 제품이 MCP를 통해 컨텍스트를 더 잘 이해하게 되면서 전 세계 사용자를 위한 AI 도구가 전반적으로 발전합니다. 또한 생태계에 표준 프로토콜이 도입되면 개발자는 반복적인 통합 코드 작성에 소비하는 시간을 줄이고, 새로운 기능을 개발하는 데 더 많은 시간을 쏟을 수 있습니다.

MCP와 기존 API의 차이점은 무엇일까요?

MCP 대신 API를 쓰면 안 되나요? API도 앱 내의 수많은 동일한 데이터와 액션에 접근할 수 있는 권한을 제공하기 때문에, 이는 흔히 제기되는 질문입니다. 실제로 많은 MCP 서버는 내부적으로 API를 사용하여 데이터와 기능을 제공합니다.

간단히 말해, MCP를 사용하면 AI 어시스턴트가 모든 API에 대해 하나의 명령어 세트만 사용할 수 있으므로 통합 과정이 크게 단순해집니다. API를 직접 사용하려면 요청, 응답, 재시도를 위한 맞춤형 코드를 작성해야 하는 반면, MCP를 사용하면 개발자가 MCP 서버를 가져오는 것만으로 동일한 결과를 얻을 수 있습니다. MCP 서버 간 전환은 쉽지만, API를 전환하려면 완전히 새로운 코드 세트를 작성해야 합니다.

또한 MCP는 LLM 사용에 더욱 최적화되어 있습니다. MCP는 LLM이 시스템에 접근하는 데 필요한 모든 것이 구조화된 방식으로 명확하게 정의되고 문서화되도록 보장합니다. 임시 API 정의에는 중요한 설명이 누락되어 있을 수 있고, 또는 AI가 이해하지 못하거나 잘못 해석할 수 있는 방식으로 데이터를 제공하기도 합니다.

MCP와 AI 에이전트가 밀접하게 연결된 방식

AI 에이전트는 현실 세계에서 사용자를 대신해 작업을 수행하는 모든 AI를 뜻합니다. MCP는 AI 에이전트를 훨씬 쉽게 구축할 수 있도록 해줍니다. 개발자는 API를 하나씩 통합하는 대신 프로토콜을 구현하여 자신의 AI 도구가 MCP를 지원하는 모든 애플리케이션에서 작동하도록 할 수 있습니다.

MCP 생태계가 성장할수록 AI 에이전트도 더 강력해집니다. AI 에이전트는 사용자의 작업공간에 있는 여러 도구를 넘나들며 계획하고 실행할 수 있어야 합니다. 에이전트가 사용할 수 있는 도구가 많을수록 사용자에게 더 유용해집니다. MCP를 통해 에이전트는 점점 늘어나는 작업 자동화용 도구를 쉽게 찾고 사용할 수 있습니다.

MCP와 A2A: 두 프로토콜이 서로를 보완하는 방식

새로운 프로토콜이 MCP만 있는 것은 아닙니다. 최근에 Google은 Agent2Agent(A2A) 프로토콜을 발표했습니다. 하지만 개발자가 둘 중 하나만 선택할 필요는 없습니다. 이 프로토콜들은 서로 다른 문제를 해결하며, 실제로는 서로를 보완합니다.

MCP는 AI 시스템이 외부 환경 배우고 그 안에서 실행하도록 하는 데 중점을 둡니다. A2A는 AI 시스템들이 협업하고, 업무를 할당하며, 논쟁하고, 권한을 위임하거나 협상하기 위해 서로의 작업과 의도에 대해 소통할 수 있도록 하는 데 집중합니다.

두 개의 AI 에이전트는 A2A를 사용해 누가 실제 작업을 수행하고, 누가 그 작업을 감독할지 결정할 수 있습니다. 그런 다음, 수행해야 할 작업과 사용할 데이터에 대한 지침을 서로 주고받기 위해 MCP를 사용할 수도 있습니다.

MCP와 AI 통합의 미래

MCP 팀은 프로토콜을 지속적으로 업데이트하고 있으며, 한 달에 여러 차례 새로운 릴리스를 출시하고 있습니다. 또한 MCP는 개방형 표준이기 때문에, 더 넓은 AI 커뮤니티가 함께 로드맵에 기여할 수 있습니다. 향후 릴리스에서는 보안에 더욱 집중할 것으로 예상됩니다. 여기에는 인증, 권한 부여, 그리고 헬스케어나 금융 같은 특정 도메인을 위한 데이터 필터링 및 개인정보 보호 메커니즘 등이 포함될 것입니다.

MCP가 광범위하게 채택된다면, AI 산업 전반에서 MCP 활용을 최적화하기 시작할 수 있습니다. 모델 개발자들이 훈련 데이터에 MCP 도구 사용을 포함하기 시작할 수 있으며, LLM 오케스트레이션 프레임워크(예: LangChain)도 사용 사례에서 MCP를 핵심 기능으로 지원하게 될 수 있습니다.

시간이 지나면서 MCP는 도구와 서비스로 구성된 전체 디지털 환경에 AI를 연결하는 사실상의 표준이 될 수 있습니다. 외부 시스템의 데이터와 작업을 LLM 경험으로 가져오는 과정은 AI 생태계에서 점점 플러그 앤 플레이(plug-and-play) 방식으로 간편해질 것입니다. 개발자들에게는 맞춤형 래퍼가 더 줄어들고, AI 도구는 더 좋아지며, 사용자들이 실제로 가치를 느끼는 기능을 만드는 데 더 많은 시간을 투입할 수 있음을 의미합니다. 데이터가 방대한 앱을 출시하는 기업들에게, 이는 MCP를 지원하는 모든 AI 플랫폼과 즉시 호환될 수 있다는 것을 의미합니다. 그리고 최종 사용자 입장에서는, 번거롭고 지루한 개입 없이도 AI가 마침내 정확한 컨텍스트를 불러오고 적절한 버튼을 누르며, 실제 작업을 수행할 수 있는 더 나은 AI 애플리케이션과 개인 어시스턴트를 활용할 수 있게 됩니다.