제2장 — Model Context Protocol(MCP)의 베일 벗기

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 두 번째 글입니다. 멘탈 모델을 세웁니다 — 세 역할, JSON-RPC 와이어 포맷, 동적 발견 표면, 그리고 세션 라이프사이클 — 책의 나머지가 그 위에 설 수 있을 만큼 신중하게.

이 장이 존재하는 이유

제1장은 문제에 이름을 붙였습니다. 이 장은 답의 멘탈 모델을 짓습니다. MCP는 한 문장으로 요약될 수 있고 한 단락으로 오해될 수 있어서, 이 장은 천천히 갑니다. 와이어 수준에서 프로토콜이 무엇인지, 세 역할이 무엇을 뜻하고 각자 무엇을 소유하는지, 프로덕션에서 중요한 경우에 REST API와 어떻게 다른지, 그리고 연결에서 해체까지 세션 동안 무엇이 일어나는지. 목표는 — 다음 장을 읽기 전에 — 서버 프리미티브가 무엇이어야 하는지, 클라이언트 프리미티브가 무엇이어야 하는지, 그리고 MCP가 왜 가진 구조를 갖게 되었는지를 여러분이 예측할 수 있게 되는 것입니다.

2.1 MCP가 무엇이며 「AI를 위한 USB-C」는 실제로 무엇을 뜻하는가

Model Context Protocol은 LLM 애플리케이션이 외부 능력을 발견하고, 기술하고, 호출하는 방식에 대한 열린 명세입니다. 와이어에서는 소수의 전송 중 하나 위에서 도는 JSON-RPC 2.0입니다. 아키텍처 수준에서는 호스트가 맞춤 통합 코드 없이 모든 적합 서버와 일할 수 있게 해 주는 계약입니다. 프로토콜에 맞춰 한 번 만든 도구는 그것을 말하는 모든 호스트와 동작합니다. 프로토콜에 맞춰 한 번 만든 호스트는 그것을 말하는 모든 도구를 사용할 수 있습니다.

자리잡은 약칭은 「AI를 위한 USB-C」입니다. 구조적 모양은 정말로 USB-C를 닮았습니다 — 열린 디바이스 집단과 열린 호스트 집단을 중재하는 단일 연결 표준. 비유의 한계도 이름 붙일 가치가 있습니다. USB-C는 커넥터와 그 위의 스택을 표준화합니다. MCP는 프로토콜만 표준화합니다. USB-C는 하드웨어가 강제하는 프레이밍과 함께 전기적 시간 척도로 동작합니다. MCP는 소프트웨어가 정의한 프레이밍과 함께 네트워크 시간 척도로 동작합니다. 그래서 MCP는 더 유연할 수 있지만, USB-C가 다루지 않는 끊어진 연결과 느린 동료를 다루어야 합니다.

엔지니어에게 더 가까운 비교는 LSP입니다. Language Server Protocol은 모든 에디터와 모든 언어 서버가 말할 수 있는 프로토콜을 정의했습니다. MCP는 모든 LLM 호스트와 모든 능력 제공자가 말할 수 있는 프로토콜을 정의합니다. 승리의 모양은 동일합니다 — 다대다가 공유 프로토콜로 무너져 덧셈으로 확장되는 무언가가 됩니다. 새 와이어 포맷을 발명하는 대신 MCP를 JSON-RPC 2.0에 기반한 선택은 의도적이었습니다. JSON-RPC는 작고, 성숙하고, 언어 중립적이며, 화려하지 않습니다. 흥미로운 아키텍처적 선택은 와이어 수준에 있지 않습니다. Host, Client, Server가 책임을 나누는 방식에 있습니다.

2.2 Host, Client, Server — 각 역할이 소유하는 것

MCP는 세 역할을 정의하는데, 가장 먼저 이해할 점은 「Client」와 「Server」가 다른 곳에서 자주 뜻하는 바를 뜻하지 않는다는 것입니다. Server는 능력을 노출합니다 — 도구, 리소스, 프롬프트. Client는 더 큰 애플리케이션 안에서 관리되는, 하나의 Server에 대한 단일 프로토콜 연결입니다. 그 더 큰 애플리케이션이 Host입니다. Host는 모델, 사용자의 세션, 그리고 모델이 무엇을 해도 되는지에 대한 정책을 소유합니다. Server는 자신의 능력 표면을 소유합니다. Client는 그 사이의 선이며, Server당 하나입니다.

이 분할이 중요한 이유는 각 역할이 다른 책임과 다른 신뢰 자세를 갖기 때문입니다. Host는 사용자 관점에서 중요한 신뢰 경계입니다. 다른 모든 것은 Host가 들이기로 결정한 무언가입니다. 다섯 개의 Server와 말하는 Host는 자체 세션 상태, 자체 구독, 어떤 능력이 협상되었는지에 대한 자체 시야를 가진 다섯 개의 Client를 안에서 돌립니다. 한 Server가 추락하면 해당 Client가 추락하고, 다른 Client는 계속 돌고, Host는 살아 있습니다. Client는 한 나쁜 Server가 전체 세션을 오염시키지 않게 하는 연결당 격리자입니다.

이 분할에 대한 보안 논리도 있습니다. 모든 Server는 최소한 다른 사람이 쓴 코드입니다. Client는 Server가 Host에 영향을 줄 수 있는 모든 것 — 알림, 일리시테이션, 샘플링 요청, 발행된 리소스 — 을 중재하며, Server별 정책이 사는 자리입니다. Host, Client, Server는 논리적 역할이지 엄격하게 물리적인 것은 아닙니다. 로컬 설정에서 Server는 자주 stdio 위의 서브프로세스입니다. 원격 배포에서는 HTTP 기반 전송 위의 서비스입니다. 프로토콜은 신경 쓰지 않습니다. 역할 경계는 신경 씁니다.

2.3 MCP 대 REST — 동적 발견과 의미적 기술이 사 주는 것

합당한 질문은 「이것이 그냥 REST 아닙니까?」입니다. 차이는 표면적이지 않습니다. 가장 큰 차이는 동적 발견, LLM을 청중으로 한 의미적 기술, 그리고 양방향 메시지 모델입니다.

REST API는 사람 개발자를 위해 쓰인 문서에 엔드포인트를 발행합니다. 클라이언트가 쓰는 엔드포인트 집합은 빌드 시간에 고정되며, 새 엔드포인트는 재배포를 요구합니다. MCP는 이를 뒤집습니다. 세션 시작 시 Client는 「무엇을 제공합니까?」를 묻고 Server는 호스트가 프로그래밍적으로 쓰는 타입화된 카탈로그 — 스키마, 기술, 메타데이터 — 로 답합니다. Server가 나중에 도구를 추가하면 listChanged 알림이 재시작 없이 Client를 세션 중간에 갱신합니다. Server는 자신의 능력에 대한 진실의 권위 있는 원천입니다. 기술은 구현으로부터 표류할 수 없습니다 — 표류할 별도의 클라이언트 측 복사본이 없기 때문입니다.

의미적 기술이 두 번째 차이입니다. REST 엔드포인트의 문서는 읽고 결정할 개발자를 위해 쓰입니다. MCP 도구의 기술은 자신의 프롬프트의 일부로 그것을 읽고 자율적으로 결정할 LLM을 위해 쓰입니다. 「POST를 /users/:id/orders로」라고 읽히는 기술은 LLM에 쓸모가 없습니다. LLM은 도구가 어떤 개념적 작업을 수행하는지, 언제 선호되어야 하는지, 어떤 부작용이 있는지, 그리고 입력이 도메인 용어로 무엇을 뜻하는지를 알아야 합니다. API를 LLM이 읽을 수 있는 용어로 번역하는 일은 한 번, Server로 밀려났고, 그 능력에 가장 가까운 사람들이 유지보수합니다.

세 번째 차이는 양방향성입니다. REST는 요청-응답입니다. 연결이 닫힙니다. MCP는 설계상 양방향입니다. Server는 언제든 알림을 보낼 수 있고, Client에게 샘플링 요청을 시작할 수 있고, 흐름 중간에 사용자로부터 답을 일리시테이션할 수 있습니다. 이 중 어느 것도 REST에서 기술적으로 불가능하지는 않습니다. 다만 거기서는 어색합니다. MCP에서는 표준의 일부입니다.

2.4 능력 협상과 세션 라이프사이클

세션은 Client가 전송을 열고 자신의 프로토콜 버전과 능력을 담은 initialize 요청을 보낼 때 시작됩니다. Server는 자신의 능력으로 답합니다 — 도구를 노출하는지, 리소스를 노출하는지, 구독을 제공하는지, 고급 기능을 지원하는지. Client는 initialized 알림으로 확인합니다. 세션은 이제 운영 상태에 있고, 사용 가능한 메시지 유형은 양측이 합의한 부분집합 그대로입니다.

이 협상이 다른 기능 집합을 가진 Client와 Server가 생산적으로 공존하게 해 줍니다. 그것은 또한 버전 관리가 처리되는 곳입니다 — Server는 양측이 지원하는 가장 높은 버전을 고릅니다. 운영적으로 라이프사이클에는 결과가 있습니다. 초기화는 무료가 아닙니다. 라운드트립 비용이 있고, 원격 서버의 경우 그 위에 연결 설정이 있습니다. 장수명 세션이 선호되는 패턴입니다. 능력 변경은 재연결이 아니라 알림으로 흐릅니다. 이를 존중하는 호스트는 — 세션을 따뜻하게 유지하고, 네트워크 깜빡임 후 백그라운드에서 재연결하는 — 실질적으로 더 나은 지연 시간을 얻습니다. 매 요청마다 해체하고 재초기화하는 호스트는 올바르게 동작하지만 비효율적입니다.

고정해 둘 만한 비대칭: 요청은 응답을 갖습니다. 알림은 그렇지 않습니다. list-changed 이벤트는 알림이므로, 그것을 놓친 Client는 list_tools를 다시 호출해 자기 시야를 갱신할 준비가 되어 있어야 합니다. 알림은 최적화이지 보장이 아닙니다. 견고한 MCP 코드는 그것을 기록이 아니라 힌트로 다룹니다.

제2장이 준비하는 것

이제 멘탈 모델이 손에 있습니다. MCP는 세 역할을 가진 JSON-RPC 프로토콜, Server를 자신의 능력에 대한 권위로 만드는 동적 발견, LLM 청중을 위해 쓰인 기술, 알림과 서버 시작 요청을 가진 양방향 메시지 모델, 그리고 명시적 능력 협상으로 열려 양측이 합의한 부분집합 안에서 운영되는 라이프사이클입니다. Server와 Client가 각각 무엇을 노출하는지 구체적으로 말하기에 충분한 발판이며, 다음 두 장이 그 일을 합니다.

다음 → 제3장: 서버 프리미티브 — Resources, Prompts, Tools. 서버가 내놓을 수 있는 세 개의 명사, 왜 각각이 중요한지, 그리고 하나를 다른 것의 영역으로 과부하 하는 대신 알맞은 프리미티브를 고르는 규율.