MCP 설명: Model Context Protocol 작동 방식

LLM은 한동안 도구를 호출할 수 있었지만, Model Context Protocol (MCP) 은 이를 위한 구조화되고 표준화된 방식을 제공합니다.

하지만 MCP가 실제로 무엇인지에 대해서는 여전히 혼란이 있습니다.

많은 사람이 MCP를 앱, API 또는 어떤 도구로 생각하지만, MCP는 그 어느 것도 아닙니다. MCP는 프로토콜이며, 이는 매우 구체적인 의미를 갖습니다.

하나씩 살펴보겠습니다.

MCP가 실제로 무엇을 가능하게 하는지 바로 보고 싶다면, 이 짧은 동영상을 확인하세요.

프로토콜이란 무엇인가요?

프로토콜은 두 개 이상의 시스템이 서로 통신하는 방식을 정의하는 규칙의 집합입니다.

프로토콜 자체가 무언가를 수행하지는 않습니다. 두 엔터티 사이의 대화 구조와 기대 동작을 정의할 뿐입니다. 컴퓨터가 정보를 교환하기 위해 따르는 엄격한 문법 규칙이 있는 공통 언어라고 생각하면 됩니다.

우편 시스템도 비슷한 일을 합니다. 특정 국가의 모든 우체국은 편지를 보내기 위해 표준화된 주소 형식을 따릅니다.

또는 AI 도구를 위한 USB-C와 같다고 생각할 수도 있습니다. 20년 전에는 시장에 다양한 종류의 충전 및 데이터 케이블이 넘쳐났습니다. AI 생태계에서도 언어 모델에 도구를 전달하는 방식이 여러 가지였습니다. LangChain, Haystack, Pydantic AI 같은 프레임워크는 모두 도구 통합을 위한 자체 형식을 정의했습니다. 즉, 개발자가 Google Maps용 도구 세트를 작성하려면 각 특정 기술마다 별도로 구현해야 했습니다.

이를 더 구체적으로 이해하기 위해 웹사이트를 구동하는 가장 널리 쓰이는 프로토콜인 HTTP (Hypertext Transfer Protocol)를 살펴보겠습니다. HTTP는 무엇보다도 브라우저(클라이언트)가 웹 서버에 웹페이지를 요청하는 방식과 서버가 응답해야 하는 방식을 정의합니다.

다음은 HTTP 요청-응답 주기의 예입니다.

브라우저가 HTTP 요청을 보냅니다

브라우저에 https://example.com을 입력하면, 브라우저는 웹 서버에 구조화된 HTTP 요청을 보냅니다.

다음은 예제에서 사용된 HTTP 매개변수와 값입니다.

"GET" – 동작입니다(웹페이지 요청).
"/index.html" – 요청된 특정 웹페이지입니다.
"HTTP/1.1" – 사용 중인 프로토콜 버전입니다.
"Host: example.com" – 웹사이트의 도메인 이름입니다.
"User-Agent: Mozilla/5.0" – 요청을 보내는 브라우저에 대한 정보입니다.

웹 서버는 HTTP가 이 형식을 표준화하기 때문에 이 요청을 해석하는 방법을 알고 있습니다. 이 “언어”를 이해합니다.

서버가 HTTP 프로토콜을 사용해 응답합니다

서버는 요청을 처리하고 구조화된 HTTP 응답을 다시 보냅니다.

"HTTP/1.1 200 OK" – 응답 코드입니다(200은 성공을 의미합니다).
"Content-Type: text/html" – 다시 보내는 콘텐츠의 유형입니다.
"Content-Length: 512" – 응답의 크기입니다.
HTML Content – 실제 웹페이지 콘텐츠입니다("Welcome to Example.com" 제목만 있습니다)

중요한 점은 HTTP 자체가 웹페이지를 _저장_하거나 표시하지 않는다는 것입니다. HTTP는 웹 브라우저와 웹 서버가 통신할 수 있는 _규칙_만 정의합니다. 해당 규칙을 따르는 모든 시스템은 HTTP가 정의한 인터넷에서 통신할 수 있습니다.

MCP가 프로토콜로 작동하는 방식

이제 같은 사고방식을 MCP (Model Context Protocol)에 적용해 보겠습니다.

MCP는 AI 에이전트가 외부 도구 및 데이터 소스와 통신하기 위한 프로토콜입니다. HTTP와 마찬가지로 MCP 자체는 데이터를 저장하거나 작업을 실행하지 않습니다. AI가 도구에서 정보를 요청하고 가져오기 위한 표준화된 방식을 정의할 뿐입니다.

그렇다면 그 “도구”란 무엇일까요?

LLM의 맥락에서 도구는 AI가 단순한 텍스트 생성을 넘어 기능을 확장하기 위해 상호작용할 수 있는 외부 시스템, API 또는 서비스입니다. 도구를 통해 AI 에이전트는 실시간 데이터를 가져오거나, 약속을 예약하거나, 친구에게 문자를 보낼 수 있으며, 실제 요구 사항에 훨씬 더 유용해집니다.

AI 에이전트에게 다음과 같이 묻는다고 해보겠습니다.

“지금 런던은 몇 시인가요?”

AI 모델에는 지식 기준일이 있기 때문에(OpenAI 모델은 2023년 10월), AI 자체는 정답을 알지 못합니다. 따라서 시간 서비스에서 실시간 데이터를 가져와야 합니다. 하지만 웹페이지를 요청하기 위해 HTTP를 사용하는 대신, AI는 시간 데이터를 요청하기 위해 MCP를 사용합니다.

다음과 같은 일이 일어납니다.

AI 에이전트가 시간 서비스에 MCP 요청을 보냅니다(예시)

"method": "tools.call" → AI가 외부 도구를 호출합니다.
"tool": "get_time" → 사용하려는 도구의 이름입니다.
"args": { "location": "London" } → 구체적인 입력 매개변수입니다.

HTTP와 마찬가지로 이 요청은 엄격한 형식을 따르므로, MCP 호환 도구는 이를 정확히 해석하는 방법을 알 수 있습니다.

MCP 시간 서버가 응답합니다

외부 도구(시간 서버)는 MCP의 응답 규칙을 따르며 다음을 다시 보냅니다.

"status": "success" → 요청이 올바르게 처리되었음을 확인합니다.
"result" → 실제 시간 데이터를 포함합니다.

이제 AI 에이전트는 이 데이터를 받아 다음과 같이 사용자에게 실제 응답을 작성할 수 있습니다.

“현재 런던 시간은 오후 12:20 (GMT)입니다.”

혼란을 정리해 요약하면 다음과 같습니다.

“MCP는 앱이다.” → 아니요, MCP는 규칙의 집합입니다. 실제로 사용하려면 MCP를 구현한 AI 소프트웨어와 도구가 필요합니다. Instagram 앱이 HTTP 요청에 응답하고 데이터를 전달하려면 실행 중인 Instagram 서버가 필요한 것과 같습니다.

“MCP는 데이터베이스다.” → 아니요, MCP는 데이터를 저장하지 않습니다. AI 에이전트가 데이터베이스나 API와 통신하도록 돕습니다.

“MCP는 API와 같다.” → 정확히는 아닙니다. API는 하나의 시스템과 상호작용하는 특정 방식인 반면, 프로토콜(MCP나 HTTP 같은 것)은 여러 서로 다른 시스템이 통신할 수 있는 보편적인 방식을 정의합니다. MCP는 AI 시스템이 여러 실제 API(시간, 데이터베이스, Stripe, Slack 등)와 상호작용하는 데 사용할 수 있는 언어입니다.

MCP와 프로토콜 비교 표

MCP가 흥미로운 이유

이제 MCP가 AI 소프트웨어가 외부 도구와 앱과 상호작용하기 위한 표준화된 방식이며, MCP는 API가 아니라는 것을 알았으니, 왜 AI 개발자 커뮤니티(저희 포함)가 여기에 관심을 갖게 되었는지 이해해 보겠습니다.

MCP는 API가 아니라 AI 앱이 실제 API와 대규모로 상호작용할 수 있게 해주기 때문에, 많은 외부 시스템에 연결해야 하는 프로젝트가 더 빨리 시작되도록 돕습니다. 도구는 모델에 범위를 부여하며, OpenAI Hugging Face 사건에서 일어난 일은 그 범위가 작업을 넘어설 때 어떤 모습인지 보여줍니다. 이를 위해 개발자는 때때로 전체 API 통합 개발 주기를 거쳐야 했지만, 오늘날에는 보통 필요한 기능을 제공하는 기존 라이브러리나 오픈소스 프로젝트(예: GitHub에서 제공)를 사용합니다.

이러한 라이브러리를 사용하면 개발을 빠르게 시작할 수 있지만, 이를 시스템에 올바르게 통합하는 일(GitHub에서 찾은 구현과 호환되지 않는 경우)은 도구가 AI와 함께 작동하도록 만들기 위해 여전히 노력이 필요합니다.

MCP에서는 프레임워크가 마련되면 새 통합(예: Google Drive 통합)을 추가하는 것이 몇 줄의 코드로 Google Drive MCP 서버에 연결하는 문제일 수 있습니다. 양쪽 모두 같은 프로토콜인 MCP를 사용하므로 호환성 문제를 겪지 않습니다.

두 접근 방식을 비교해 차이를 더 명확히 살펴보겠습니다.

표준 통합과 Model Context Protocol (MCP) 사용 비교

이 비교를 구체화하기 위해 AI Agent에 Google Drive 파일 접근을 추가하는 과정을 살펴보겠습니다. 먼저 수동으로, 그다음 MCP 호환 도구로 진행합니다.

표준 통합

라이브러리 찾기 및 조정: Google Drive API 클라이언트나 오픈소스 프로젝트를 찾습니다. Google은 클라이언트 라이브러리(예: Python용 Google Drive API)를 제공합니다. 이를 프로젝트에 포함합니다. 그래도 AI 환경에서 작동하는지 확인해야 합니다.
로직 구현: 예를 들어 파일을 검색하거나 Drive에서 문서를 가져오는 함수를 작성합니다. AI가 무언가를 필요로 할 때 이러한 함수를 호출해야 합니다. AI의 요청을 Google Drive 전용 API 호출 형식으로 변환합니다. Google에서 응답을 받은 뒤, 콘텐츠를 추출해 AI의 컨텍스트로 다시 전달합니다.
오류와 엣지 케이스 처리: “파일을 찾을 수 없음”, 권한 오류, API 속도 제한 같은 경우를 처리하는 코드를 추가합니다. Google API가 오류를 반환하면 이를 잡아내고, 사과 메시지로 응답하거나 AI에게 다시 표현하도록 요청할 수 있습니다. 또한 AI가 너무 빠르게 너무 많은 요청을 보내지 않도록 보호해야 합니다.
유지보수: 시간이 지나 Google이 API나 라이브러리를 업데이트하면 코드를 업데이트해야 합니다. 라이브러리에서 버그를 발견하면 패치하거나 다른 소스를 찾아야 할 수 있습니다. 본질적으로 AI 애플리케이션 내에서 이 Google Drive 통합의 유지보수자가 됩니다.

이 과정은 다른 도구에도 확장됩니다. AI에 Slack이나 데이터베이스를 추가하고 싶다면, 각 도구마다 전체 과정을 반복해야 합니다.

MCP 통합

이제 MCP를 사용할 때 그 과정이 어떻게 보이는지 살펴보겠습니다.

먼저 핵심 개념을 정의하겠습니다.

클라이언트 – 하나 이상의 서버에 연결을 설정하고, 사용자가 요청한 작업을 수행하기 위해 정보나 액션을 요청하는 AI 애플리케이션(ChatGPT, Claude app, Quickchat AI)입니다.

서버 – 각 서버는 데이터베이스나 API(Google Drive) 같은 것에 연결하고, 제공할 수 있는 “도구” 또는 데이터 집합을 정의할 수 있습니다. 이 경우 서버는 이러한 도구와 기능을 클라이언트(AI 앱)에 노출하는 프로그램입니다.

개발자는 무엇을 하려는지에 따라 양쪽 중 하나를 선택할 수 있습니다. 데이터를 노출하는 서버를 만들 수도 있고, 어떤 서버와도 통신할 수 있는 AI 클라이언트를 만들 수도 있습니다. 대부분은 두 번째 옵션을 원하지만, MCP가 단계별로 어떻게 작동하는지 이해하기 위해 서버 측부터 시작하겠습니다.

MCP 서버 초기화. 개발자나 시스템 관리자가 특정 도구 또는 데이터 소스에 대한 MCP 서버를 설정합니다. MCP 서버는 보통 MCP 사양을 구현한 작은 프로그램일 뿐입니다. 예를 들어 문서를 검색하고 가져오는 방법을 알고 있는 사전 구축된 Google Drive MCP 서버가 제공됩니다.

서버를 초기화할 때 대상 시스템(Google Drive)에 접근 권한을 부여합니다. 그러면 서버는 처리할 수 있는 액션이나 쿼리에 해당하는 도구 집합을 노출합니다. 본질적으로 한쪽에서는 MCP를 말하고 다른 쪽에서는 네이티브 서비스를 말하는 API 어댑터입니다.

서버가 실행되면 요청을 기다립니다.
LLM(클라이언트)을 MCP 서버에 연결. 다음으로 AI 애플리케이션(“클라이언트” 측)이 해당 서버에 연결해야 합니다. 실제로 Claude Desktop처럼 MCP를 지원하는 AI 플랫폼을 사용하는 경우, 서버를 시작할 주소나 명령으로 설정합니다. 연결되면 클라이언트는 MCP의 핸드셰이크를 따라 서버와 세션을 설정합니다. Claude의 인터페이스를 사용 중이라면 Claude가 특정 MCP 서버에 “connected”되어 있음을 볼 수 있습니다(UI가 사용 가능한 커넥터를 표시할 수 있습니다).

도구가 추가된 Claude

Claude UI에서는 이렇게 보입니다

사용 가능한 도구 발견. 연결이 설정되면 가장 먼저 해야 할 일은 서버가 무엇을 제공하는지 확인하는 것입니다(때로는 서버에 연결한 뒤 자동으로 발생합니다). MCP 클라이언트는 서버에 tools/list 요청을 보냅니다(이는 프로토콜에 정의되어 있습니다). 서버는 사용 가능한 도구 목록을 반환하며, 각 도구에는 이름, 설명, 입력 스키마 같은 세부 정보가 포함됩니다.

예를 들어 서버는 create_file(path, content), read_file(path), search_files(query) 도구를 사용할 수 있다고 응답할 수 있습니다. 그러면 클라이언트는 이 정보를 LLM이 사용할 수 있도록 합니다. 많은 구현에서 클라이언트는 이러한 도구 설명을 형식화해 모델의 컨텍스트에 포함합니다(예: 시스템 프롬프트에 “다음 도구에 접근할 수 있습니다… [도구 목록]” 추가).

시스템 프롬프트

사용자의 현재 시간 요청 메시지와 함께 표시된 AI 시스템 프롬프트입니다

프롬프트의 MCP 도구

MCP 도구가 구현되면 “get_current_time”이라는 도구가 통합되어 AI가 외부 리소스에 접근하고 런던의 정확한 시간을 가져올 수 있습니다

이는 AI 앱이 어떤 작업을 완료하기 위해 필요할 수 있는 모든 잠재적 액션을 미리 생각하고 프로그래밍할 필요가 없다는 뜻입니다. MCP를 사용하면 AI는 MCP 서버에 요청해 가능한 모든 액션을 즉석에서 발견하고, 필요한 것을 선택할 수 있습니다.

MCP를 통해 도구 사용. AI가 액션을 수행하거나 데이터를 가져와야 할 때, MCP를 통해 도구를 호출합니다. AI의 관점에서(특히 도구 사용을 네이티브로 지원하는 Claude 같은 모델의 경우), AI는 추론 과정에서 “이 매개변수로 도구 X를 호출해야 한다”고 결정합니다. MCP 클라이언트는 그 의도를 포착하고 MCP 형식의 tools/call 요청을 적절한 서버(Google Drive MCP 서버)에 보냅니다.
MCP 서버는 브리지 역할을 합니다. AI 에이전트로부터 구조화된 MCP 호환 요청을 받고, 이를 올바른 Google Drive API 엔드포인트에 매핑하고, 요청을 실제 Google Drive API 호출로 다시 작성하고, 요청을 실행하고, 응답을 처리한 뒤, AI 에이전트에 다시 보내기 전에 다시 MCP 호환 응답으로 재형식화합니다.

주목할 점은 MCP 서버가 오류 처리에 구조화된 접근 방식을 따른다는 것입니다. 이를 통해 AI Agents가 오류를 효과적으로 해석하고 조치할 수 있습니다.

AI Agent가 Google Drive에서 파일을 찾기 위해 MCP 도구를 사용한다고 해보겠습니다. 요청에 잘못된 파일 ID(예: 예상 형식 대신 다섯 글자 길이의 문자열)가 포함되어 있다면, MCP 서버는 오류 메시지를 반환합니다.

단순히 실패하는 대신, AI Agent는 이 구조화된 응답을 받아 사용자 친화적인 피드백으로 재구성할 수 있습니다.

“제공하신 파일 ID가 너무 짧은 것 같습니다. Google Drive 파일 ID는 일반적으로 28자입니다. 다시 확인한 뒤 시도해 주시겠어요?”

이 접근 방식은 오류가 막다른 길로 이어지지 않도록 하며, 대신 AI Agent가 사용자를 성공적인 해결로 안내할 기회가 되게 합니다.
사용자의 질문/요청에 답변. MCP 서버가 결과를 반환하면, MCP 클라이언트는 해당 데이터를 AI 앱으로 다시 전달합니다. 그러면 모델은 결과를 추론에 포함하거나 사용자에게 생성하는 출력에 직접 포함합니다.

사용자가 새 Google Sheets 파일 생성을 요청하면, 서버의 응답(파일 ID와 생성된 링크 포함)이 모델에 전달됩니다. 그러면 모델은 사용자에게 다음과 같이 응답합니다. “좋은 소식입니다. 새 Google Sheets 파일이 준비되었습니다. 여기에서 접근할 수 있습니다: [link].”

MCP 작동 흐름

이 과정 전반에서 AI는 흐름을 계속 제어합니다. 언제 도구를 호출할지, 그 결과를 답변 작성에 어떻게 사용할지 결정합니다. 그동안 개발자는 이러한 단계를 수동으로 오케스트레이션할 필요가 없습니다. MCP 프레임워크와 AI 모델이 이를 처리합니다. 최종적으로 사용자는 외부 정보나 액션이 필요한 복잡한 질문 또는 작업을 AI에 요청할 수 있고, AI는 MCP를 통해 이를 자율적으로 수행한 뒤 결과를 반환할 수 있습니다.

MCP 사용의 이점

이 접근 방식이 많은 세부 사항을 추상화한다는 점에 주목하세요. 클라이언트는 API 키나 HTTP 상태 코드를 처리하지 않았습니다. 이는 MCP 서버가 처리합니다.

핵심은 통합 지점의 단순성입니다. 우리는 고객을 “요청”하고 고객을 받습니다. 고객을 가져오는 방식의 로직은 다른 곳에 캡슐화되어 있습니다. 즉, AI 측에서 작업하는 개발자는 새 액션마다 새로운 HTTP 호출을 작성할 필요가 없습니다. 이름으로 도구를 호출하기만 하면 됩니다. 어려운 작업(인증, Google Drive 엔드포인트 호출, 응답 형식화)은 재사용 가능하고 표준화된 MCP 서버 코드에서 수행됩니다.

주요 이점을 요약하면 다음과 같습니다.

API별 글루 코드를 줄입니다. MCP 이전에는 AI가 외부 서비스를 사용하게 하려면 보통 많은 “글루” 코드를 작성해야 했습니다. API를 호출하고, 응답을 모델이 이해할 수 있는 텍스트로 변환하고, 모델의 출력을 파싱해 다른 API를 호출하는 식입니다. MCP를 사용하면 이러한 글루의 상당 부분이 제거됩니다. 모델의 클라이언트와 서버가 구조화된 방식으로 데이터를 교환하므로, JSON 같은 다른 형식을 텍스트로 수동 변환하거나 그 반대로 변환할 필요가 없습니다. 프로토콜이 이를 처리합니다. 또한 언제 무엇을 호출할지 결정하는 로직을 작성할 필요도 없습니다. AI가 도구 설명과 자체 추론 또는 프롬프트의 안내를 받아 이를 수행합니다.
일회성 API 래퍼 대신 재사용 가능한 공유 커넥터. MCP를 사용하면 통합을 한 번 작성하고 여러 프로젝트와 AI 시스템에서 재사용할 수 있습니다. 예를 들어 회사 내부 위키용 MCP 서버를 만들 수 있습니다. MCP를 지원하는 모든 AI 앱은 해당 서버 하나에 연결해 위키를 조회할 수 있습니다. 새 AI 챗봇마다 또는 LLM 공급업체마다 “위키 검색”을 다시 구현할 필요가 없습니다. 이러한 재사용성은 과거에 모든 팀이 같은 API를 위해 약간씩 다른 자체 통합을 작성하던 방식에서의 변화입니다. MCP는 공유하고 공동으로 개선할 수 있는 커넥터 라이브러리를 장려합니다.
서로 다른 LLM과의 플러그 앤 플레이 통합. MCP는 모델에 구애받지 않습니다. 클라이언트가 MCP 인터페이스를 처리할 수 있는 한, 프로토콜은 클라이언트가 Claude, GPT-4, DeepSeek 또는 미래의 어떤 모델인지 신경 쓰지 않습니다. 앞으로 다른 모델로 전환하고 싶다면, 모든 통합을 다시 작성하지 않고도 그렇게 할 수 있습니다.
더 쉬운 유지보수. MCP는 개방형 표준이므로, 처음부터 빌드하는 대신 활용할 수 있는 사전 구축 서버(데이터베이스, 인기 API 등)에 기여하는 커뮤니티가 성장하고 있습니다. 더 많은 시스템을 통합할수록 MCP는 많은 지점 간 통합의 “스파게티”를 피하는 데 도움이 됩니다. 또한 다른 공급자의 모든 API 업데이트를 모니터링할 필요가 없습니다.

API 통합은 쓸모없어질까요?

기존 API 통합과 MCP는 모두 제자리가 있습니다. 최선의 접근 방식은 프로젝트의 성격, 팀의 전문성, 장기 목표에 따라 달라질 수 있습니다.

하나 또는 두 개의 외부 서비스와만 통합하면 되고 상호작용이 비교적 단순하다면, 직접 API 통합이 가장 빠른 해결책인 경우가 많습니다. 웹 앱이 결제 시 Stripe 결제 토큰을 검증하기만 하면 된다면, Stripe API를 직접 호출하는 것이 간단하고 효과적입니다. 이 시나리오에 MCP를 도입하는 것은 과도할 수 있습니다. MCP 서버를 실행하지 않고도, 검토된 HTTP Action 하나로 AI Agent를 문서화된 REST API에 연결하거나 리드 및 데모 요청을 기록하기 위한 Google Sheets 같은 원클릭 통합을 사용할 수 있습니다.

요청/응답을 매우 정밀하게 제어해야 하는 경우(성능 튜닝, 특수 데이터 처리, 독점 프로토콜 등)에는 API에 직접 작성하는 것이 더 나을 수 있습니다. 기존 통합을 사용하면 API의 모든 고급 기능을 활용하고 호출을 정확하게 맞춤화할 수 있습니다. API에 특이한 요구 사항이 있거나 최대한의 명확성과 제어를 위해 추상화 계층을 피하고 싶다면, 기존 방식이 적절합니다.

MCP 도구가 커스텀 API 액션과 함께 프로덕션 AI Agent에 노출되는 구체적인 예는 Quickchat AI Agents가 두 접근 방식을 결합하는 방식을 참고하세요. MCP, 개별 AI Actions, “Generate from Text”를 언제 사용할지에 대한 더 깊은 논의는 AI 에이전트를 위한 API: MCP에서 커스텀 엔드포인트까지에 있습니다. 직접 시도하려면 단계별 가이드에 따라 AI Agent를 원격 MCP 서버에 연결해 대화 중에 실제 도구를 호출하도록 설정하세요.

사용 가능한 MCP 서버 목록

MCP를 시작하려면 아래 MCP 서버 디렉터리를 확인하세요.

코드를 작성하지 않고도 실행할 수 있습니다. 모든 Quickchat AI Agent는 MCP 서버로 전환할 수 있으며, Claude, ChatGPT, Cursor가 도구로 호출하는 호스팅 URL이 제공됩니다. 연결은 반대 방향으로도 작동합니다. Quickchat AI Agent는 공급업체의 호스팅 MCP 서버를 도구로 호출할 수 있습니다. 이것이 Calendly의 MCP 서버를 기반으로 구축된 AI 일정 관리 어시스턴트가 실제 가능 시간을 확인하고 채팅에서 미팅을 예약하는 방식이며, Notion AI 챗봇이 실시간 헬프 센터에서 답변하고 지원 요청을 Notion 데이터베이스에 다시 기록하는 방식입니다.

Quickchat AI는 자체 계정을 위한 원격 MCP 서버도 운영합니다. 이를 ChatGPT, Claude, Cursor 또는 Codex에 연결하면 단일 OAuth 로그인 뒤에서 AI Agents를 관리할 수 있습니다. 분석, 대화 기록, 지식 베이스 업데이트, 새 Agent 생성이 가능합니다. 각 클라이언트의 설정 안내는 MCP로 ChatGPT, Claude, Codex에서 AI Agent 관리하기에 있습니다.

FAQ

Claude에서만 작동하나요?

MCP는 모델에 구애받지 않습니다. 클라이언트가 MCP 인터페이스를 처리할 수 있는 한, 프로토콜은 클라이언트가 Claude, GPT-4, 로컬 LLaMA 파생 모델 또는 미래의 어떤 모델인지 신경 쓰지 않습니다. 즉, 도구 통합을 구축할 때 단일 AI 공급자에 종속되지 않습니다.

모델에 필요한 모든 정보를 처음부터 제공하는 것과 MCP는 어떻게 다른가요? 프롬프트에 데이터를 넣으면 안 되나요?

MCP는 데이터를 모델의 프롬프트에 밀어 넣는 방식과 근본적으로 다릅니다. 정적인 사전 로드 프롬프트로 작업하는 대신, 모델이 필요할 때 동적으로 정보를 가져올 수 있기 때문입니다. 프롬프트에 텍스트를 넣는 방식은 한계에 부딪힙니다. AI 모델에는 고정된 컨텍스트 창이 있으므로 데이터가 너무 많으면 중요한 세부 정보가 손실되고, 응답이 느려지며, API 비용이 증가할 수 있습니다(LLM 공급업체가 사용하는 토큰당 과금 모델 때문입니다). 또한 이는 특정 한 시점의 지식만 제공합니다. 반면 MCP는 실시간 외부 데이터에 접근할 수 있게 하고, AI가 정보를 읽기만 하는 것이 아니라 액션을 수행하게 합니다. 가득 찬 프롬프트를 가진 AI는 고객 세부 정보를 알 수는 있지만, 기록을 업데이트하거나 거래를 처리할 수는 없습니다.

AI에 _수십 개_의 도구를 연결하면 어떻게 되나요? 모델이 부담을 느끼거나 도구를 잘못 사용하지 않을까요?

구현에 따라 다르지만, 현재 LLM이 많은 옵션을 구분하고 선택하는 능력에는 한계가 있는 것이 사실입니다. 예를 들어 모델에 50개의 가능한 도구를 제시하면 잘못된 도구를 선택할 위험이 있습니다. MCP 접근 방식 자체가 모든 것을 한 번에 로드하도록 강제하지는 않습니다. 컨텍스트에 따라 관련 도구를 연결해야 합니다. 좋은 관행은 현재 작업/도메인에 필요한 도구만 연결하고 멀티에이전트 협업을 활용하는 것입니다. 이는 일종의 도구 라우팅이거나, 먼저 고려할 도구 하위 집합을 결정하는 에이전트입니다.

MCP와 Function Calling 비교

전통적인 function calling(OpenAI API나 다른 LLM에서 볼 수 있는 방식)은 개발자가 함수 집합을 정의하고, 그 정의를 모델에 제공한 뒤, 모델이 인수와 함께 이름으로 해당 함수를 “호출”할 수 있게 합니다. 이는 AI 통합에서 큰 진전이었지만 한계가 있습니다. 주요 차이 중 하나는 도구가 언제, 어떻게 정의되는가입니다. 전통적인 function calling에서는 가능한 모든 함수를 사전에(설계 시점에) 프롬프트나 API를 통해 선언해야 합니다. 모델은 해당 고정 함수만 호출할 수 있습니다. MCP에서는 도구를 런타임에 발견할 수 있습니다. AI가 사용 가능한 항목을 조회하고 세션 중간에 새 도구를 얻을 수도 있습니다.

MCP와 GPT Actions 및 Plugins 비교

GPT Actions/Plugins는 ChatGPT용 플러그인(웹 브라우저나 PDF 리더 같은 것)을 활성화하거나, 도구 사용이 가능한 “GPTs”(커스텀 ChatGPT 에이전트)를 만들 수 있었던 OpenAI 생태계를 의미합니다. 이는 흥미로웠지만, 각 플러그인마다 커스텀 개발이 필요했고 OpenAI 플랫폼으로 제한되었습니다. 특정 작업을 위한 ChatGPT 플러그인을 원하면 API와 manifest를 만들고, OpenAI의 승인을 거치거나 최소한 수동으로 활성화해야 했습니다. 각 플러그인은 본질적으로 사일로였습니다. 날씨 플러그인, 여행 플러그인 등 각각 고유한 엔드포인트와 로직을 가졌습니다. MCP는 이를 통합하고 개방함으로써 이 개념을 개선합니다.

MCP와 RAG (Retrieval-Augmented Generation) 비교

Retrieval-Augmented Generation (RAG)은 LLM에 외부 지식 베이스를 보완하는 기법입니다. 일반적으로 RAG에는 벡터 데이터베이스나 검색 인덱스가 포함됩니다. 사용자의 쿼리를 사용해 관련 문서나 데이터를 가져오고(의미 검색 또는 다른 방법으로), 해당 문서를 모델이 답변을 구성할 때 “읽을” 추가 컨텍스트로 제공합니다. RAG는 모델이 원래 갖고 있지 않은 지식을 제공하는 데 관한 것으로, 사실 기반 QA나 도메인별 정보에 특히 유용합니다. 그러나 RAG는 읽기 전용입니다. 모델은 텍스트 구절을 검색하지만, 검색을 넘어서는 액션을 수행하지 않습니다.

반대로 MCP는 정보성 컨텍스트를 검색하는 것뿐 아니라 액션을 수행하거나 임의의 작업을 실행하는 것에 관한 것입니다. MCP를 사용하면 AI는 무언가를 할 수 있습니다. 데이터베이스에 쓰고, 이메일을 보내고, 코드를 실행하는 등입니다. 지식 가져오기에 제한되지 않고 외부 시스템의 변경을 트리거할 수 있습니다. 따라서 여러 면에서 RAG와 MCP는 서로 다른 목적을 수행합니다.