MCP 이전에는 AI 앱을 도구에 연결하는 작업이 매번 맞춤형(bespoke)으로 이루어져야 했습니다. 모든 앱은 연결하고자 하는 각 도구에 대해 자신만의 커넥터를 직접 작성해야 했습니다: M개의 앱 × N개의 도구 = M×N개의 접착제(glue) 조각이 필요했으며, 그 중 재사용 가능한 것은 하나도 없었습니다. Anthropic(2024)에서 발표한 오픈 표준인 Model Context Protocol (MCP)은 이 혼란을 M+N으로 축소합니다. 이것은 AI를 위한 USB-C 프레임워크이며, 실제 메시지 흐름을 시각화하는 도구를 만드는 과정이 저에게는 이를 구체적으로 체감하게 해주었습니다. 그 구조는 다음과 같습니다.

Host, Client, Server

세 가지 역할이 있으며, 명칭 때문에 혼동하는 경우가 많으니 확실히 짚고 넘어갑시다:

• Host — AI 앱 자체: Claude Desktop, IDE, 커스텀 에이전트 등. 모델을 보유합니다.
• Client — Host '내부'에 있는 커넥터로, 하나의 서버와 1:1 연결을 유지합니다. 서버당 하나의 클라이언트가 존재합니다.
• Server — 균일한 프로토콜을 통해 특정 기능(파일 시스템, GitHub, 데이터베이스 등)을 노출하는 별도의 프로세스입니다.

서버를 한 번 작성하면 모든 MCP Host가 이를 사용할 수 있습니다. 클라이언트를 한 번 작성하면 모든 Server와 통신할 수 있습니다. 이러한 재사용성 — 즉, Claude Desktop용으로 구축된 서버가 IDE나 맞춤형 에이전트에서도 변경 없이 작동하는 것 — 이 바로 M+N이 주는 핵심적인 이점입니다.

서버는 세 가지 종류의 것을 노출합니다

단순히 도구(tools)만 있는 것이 아닙니다. MCP 서버는 세 가지 기능 유형을 광고할 수 있으며, 그 차이점은 '누가 각 기능을 제어하는가'에 있습니다:

• Tools — 모델이 호출할 수 있는 동작 (write_file, run_query). 모델이 제어합니다.
• Resources — URI로 주소 지정되는 읽기 전용 데이터 (file:///path, 특정 행). 앱이 제어합니다.
• Prompts — 사용자가 선택할 수 있는 재사용 가능한 템플릿. 사용자가 제어합니다.

클라이언트는 tools/list, resources/list, prompts/list를 통해 이들을 '발견(discovers)'하고, tools/call 또는 resources/read를 통해 이들을 '호출(invokes)'합니다.

통신에는 JSON-RPC가 사용됩니다

모든 메시지는 단순한 JSON-RPC 2.0 엔벨로프(envelope)입니다. 일회성 라이프사이클 핸드셰이크 (initialize)가 연결을 열고, 발견 단계 (tools/list)가 Host에게 무엇을 사용할 수 있는지 알려주며, 그 후 모델이 도구가 필요할 때마다 사용 루프가 반복됩니다:

1. initialize 호스트 ↔ 서버 핸드셰이크 (handshake), 기능 (capabilities) 교환 (1회)
2. tools/list 클라이언트가 서버가 제공하는 기능을 요청 (1회)
3. 사용자가 질문을 함
   ...

탐색 (Discovery)는 한 번만 이루어집니다. 그 이후에는 모델이 결정할 때마다 호스트가 tools/call을 실행하기만 하면 됩니다. 전송 계층 (transport)은 로컬 서버의 경우 stdio를, 원격 서버의 경우 HTTP를 사용하지만, 어떤 방식이든 동일한 프로토콜을 따릅니다.

이것은 함수 호출 (function-calling)을 대신하는 것이 아니라, 그 위에 구축되었습니다

이것이 사람들이 놓치는 지점입니다. MCP는 단순한 함수 호출 (function-calling)을 대체하지 않습니다. 모델은 여전히 이전과 똑같이 구조화된 도구 호출 (tool call)을 생성합니다. MCP가 표준화하는 것은 그 호출을 둘러싼 모든 것입니다: 도구가 어떻게 탐색 (discovered) 되는지, 요청이 어떻게 전송 (transported) 되는지, 그리고 결과가 어떻게 돌아오는지에 대한 것입니다. 함수 호출 (function-calling)이 모델이 "이 인자 (args)로 이것을 호출해"라고 말하는 것이라면, MCP는 접착제 코드 (glue code)를 다시 작성하지 않고도 어떤 앱에서든 동일한 도구에 접근할 수 있게 해주는 상호 운용 가능한 배관 (interoperable plumbing)입니다. 그렇기에 하나의 MCP 서버를 Claude Desktop, IDE, 그리고 여러분의 자체 에이전트(agent)에 똑같이 바로 적용할 수 있는 것입니다. 도구 정의는 한 번만 작성하면 되고, 프로토콜이 이를 어디든 전달합니다.

왜 M+N 수학이 실제로 이득이 되는가

M×N에서 M+N으로의 축소는 단순히 산술적으로 깔끔해지는 것만이 아닙니다. 이는 누가 작업을 수행하는지를 변화시킵니다. 기존 모델에서는 새로운 AI 앱을 만들면 사용자가 원하는 모든 도구에 대한 커넥터 (connector)를 만들어야 했고, 새로운 도구를 만들면 모든 앱에 대한 커넥터를 만들어야 했습니다. 양측 모두 상대방의 성장에 따라 함께 규모가 커져야 했습니다. MCP 체제에서는 도구 제작자가 정확히 하나의 서버만 작성하면 끝납니다. 그러면 현재의 모든 호스트와 미래의 모든 호스트가 해당 도구에 접근할 수 있습니다. 앱 제작자는 하나의 클라이언트 (client)를 작성함으로써 기존의 모든 서버 카탈로그를 무료로 물려받게 됩니다. 네트워크 효과가 올바른 방향으로 작동합니다. 각 새로운 서버는 모든 호스트의 능력을 향상시키고, 각 새로운 호스트는 모든 서버의 가치를 높이며, 이 과정에서 누구도 접착제 코드 (glue code)를 다시 작성할 필요가 없습니다.

따라서 멘탈 모델 (mental model)은 단순합니다. 호스트는 연결당 하나의 클라이언트 (client)를 실행하며, 각 클라이언트는 도구 (tools), 리소스 (resources), 프롬프트 (prompts)를 광고하는 서버 (server)와 JSON-RPC로 통신합니다. 탐색 (discovery)은 */list를 통해 이루어지며, 사용 (use)은 */call을 통해 이루어집니다. M×N 방식의 맞춤형 커넥터 (bespoke connectors)를 M+N 방식의 재사용 가능한 커넥터로 전환하면, 일회성 어댑터 (one-off adapters)의 더미 대신 하나의 생태계 (ecosystem)를 얻게 됩니다. 서버를 하나 선택하고, 모든 JSON-RPC 메시지가 단계별로 전송되는 과정을 지켜보세요: