MCP(Model Context Protocol)의 이해: 작동 원리와 구조

MCP는 Model Context Protocol의 약자입니다. 이는 AI 모델이 외부 도구(tools), 데이터 소스(data sources), 그리고 소프트웨어 시스템(software systems)에 안전하게 연결될 수 있도록 돕기 위해 만들어진 오픈 소스 표준(open-source standard)입니다.

MCP를 사용하는 대부분의 엔지니어들은 실제로 통신망(on the wire)에서 어떤 일이 일어나고 있는지 설명하지 못합니다.

그들은 저장소(repo)를 클론하고, 서버를 실행하고, 작동하는 것을 지켜봤을 뿐입니다. initialize가 무엇을 하는지, 혹은 서버를 몇 개 추가한 뒤 왜 토큰 비용(token bill)이 조용히 두 배로 늘어났는지 물어보면 대화는 금방 끊기고 맙니다.

그래서 제가 프로토콜(protocol) 전체를 매핑했습니다. 이미지 하나로 정리했으니 저장해 두세요.

𝗪𝗵𝘆 𝗶𝘁 𝗲𝘅𝗶𝘀𝘁𝘀 (존재 이유)
MCP 도입 전: N개의 모델 × M개의 도구 = 모든 쌍마다 커스텀 브릿지(custom bridge) 필요.
MCP 도입 후: N + M. 중간에 하나의 프로토콜이 존재.

𝗧𝗵𝗲 𝘁𝗵𝗿𝗲𝗲 𝗿𝗼𝗹𝗲𝘀 (세 가지 역할)
Host(호스트)는 사용자가 사용하는 앱입니다. Client(클라이언트)는 호스트 내부에 존재합니다. Server(서버)는 기능을 노출하는 여러분의 코드입니다.
그 밑바탕에는 JSON-RPC 2.0이 있습니다. 특별할 것 없는 방식입니다.

𝗧𝗵𝗲 𝘁𝗵𝗿𝗲𝗲 𝗽𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲𝘀 (세 가지 기본 요소)
Tools(도구) — 모델이 제어합니다. AI가 호출 시점을 결정합니다.
Resources(리소스) — 앱이 제어합니다. 앱이 컨텍스트(context)를 밀어넣습니다.
Prompts(프롬프트) — 사용자가 제어합니다. 사용자가 이를 호출합니다.

𝗧𝗵𝗲 𝗽𝗮𝗿𝘁 𝗻𝗼𝗯𝗼𝗱𝘆 𝘁𝗮𝗹𝗸𝘀 𝗮𝗯𝗼𝘂𝘁 (아무도 말하지 않는 부분)
모든 도구 스키마(tool schema)는 모든 LLM 호출 시 함께 전달됩니다. 도구가 50개라면, 매 턴(turn)마다 50개의 스키마가 전달됩니다.
여러 서버에 걸친 OAuth는 실제적인 비밀 키 순환(secret rotation) 작업이 됩니다.
도구의 확산(Tool sprawl)은 새로운 마이크로서비스 확산(microservices sprawl) 문제입니다.
스키마 드리프트(Schema drift)는 에이전트(agents)를 소리 없이 고장 냅니다.

MCP는 프레임워크(framework)가 아닙니다. 프로토콜(protocol)입니다. 멘탈 모델(mental model)은 LangChain이 아니라 HTTP입니다. 지루하고 기초적이며, 서서히 어디에나 스며들 것입니다.

누군가 MCP가 실제로 어떻게 작동하는지 물어볼 때를 대비해 이 그래픽을 저장해 두세요.

Credit: codewithbrij
[IMG:1]