02. 핵심 구성요소: Host · Client · Server

🎯 이 장의 목표

Host / Client / Server의 역할을 각각 구분해 설명할 수 있다
"클라이언트 하나가 서버 하나" 라는 1:1 연결 규칙을 이해한다
같은 서버를 여러 호스트가 쓸 수 있는 이유(서버는 호스트를 모른다)를 안다

식당 비유로 잡는 큰 그림

MCP의 세 주체를 식당에 비유하면 이해가 쉽습니다.

Host(호스트) = 손님이 앉은 식당 전체. AI 애플리케이션 그 자체입니다 (예: Claude Desktop, IDE, 챗 앱). 안에 LLM이 있고, 손님(사용자)을 응대합니다.
Client(클라이언트) = 담당 웨이터. 호스트 안에서 특정 서버 하나와 대화하는 전담 연결 담당입니다.
Server(서버) = 주방. 실제 음식(도구·데이터·프롬프트)을 만들어 내놓는 곳. 외부 시스템(파일·DB·API)과 맞닿아 있습니다.

손님은 주방에 직접 들어가지 않습니다. 항상 웨이터를 통하죠. 주방은 어느 식당에서 주문이 왔는지 신경 쓰지 않고, 표준 주문서(JSON-RPC 메시지)대로 요리를 내놓을 뿐입니다. 그래서 같은 주방(서버)을 여러 식당(호스트)이 쓸 수 있습니다.

flowchart TB
    subgraph HOST["Host — AI 애플리케이션"]
        LLM["LLM"]
        CA["Client A"]
        CB["Client B"]
        LLM --- CA
        LLM --- CB
    end
    SA["Server A\n(파일시스템)"]
    SB["Server B\n(GitHub API)"]
    EXT1[("로컬 파일")]
    EXT2[("GitHub")]

    CA <-->|JSON-RPC| SA
    CB <-->|JSON-RPC| SB
    SA --- EXT1
    SB --- EXT2

    classDef host fill:#fef3c7,stroke:#a16207,color:#000;
    classDef client fill:#fde68a,stroke:#b45309,color:#000;
    classDef server fill:#5eead4,stroke:#0f766e,color:#000;
    classDef data fill:#ddd6fe,stroke:#6d28d9,color:#000;
    class LLM host;
    class CA,CB client;
    class SA,SB server;
    class EXT1,EXT2 data;

각 주체의 책임

Host (호스트)

사용자와 직접 상호작용하는 AI 애플리케이션입니다. 호스트는 LLM을 품고 있고, 사용자의 요청을 받아 "어떤 도구를 써야 할지" 판단하며, 필요한 서버에 붙을 클라이언트들을 띄웁니다. 사용자 동의(consent)를 받고, 모델에게 줄 컨텍스트를 관리하는 것도 호스트의 몫입니다.

Client (클라이언트)

호스트 안에서 서버 하나와 1:1로 연결되는 통신 인터페이스입니다. 클라이언트는 JSON-RPC 2.0을 stdio 또는 HTTP 전송 위에서 말합니다. 서버 N개에 붙으려면 클라이언트도 N개입니다. 클라이언트의 일은 초기화 핸드셰이크, 서버 능력 발견(tools/list 등), 도구 호출 전달, 알림 수신 같은 프로토콜 기계 장치를 다루는 것입니다.

💡 팁

왜 1:1인가? 한 클라이언트가 여러 서버를 동시에 맡으면, 세션 상태·버전 협상·권한이 뒤엉킵니다. "클라이언트 1개 = 서버 1개"로 못 박으면 각 연결의 생명주기와 권한이 깔끔하게 분리됩니다. 여러 서버를 쓰는 복잡성은 호스트가 클라이언트 여러 개를 관리하는 방식으로 흡수합니다.

Server (서버)

컨텍스트와 기능을 클라이언트에 노출하는 주체입니다. 로컬(같은 머신의 파일시스템 서버처럼)일 수도 있고 원격(HTTPS로 호스팅된 서비스)일 수도 있습니다. 서버는 연결 시 자신이 제공하는 Tools(도구)·Resources(리소스)·Prompts(프롬프트) 를 선언합니다. 서버는 실제 외부 시스템(파일·DB·API·브라우저 등)과 맞닿아 일을 처리합니다.

서버는 JSON-RPC 2.0을 stdio 또는 HTTP 전송 위에서 말합니다. 이것이 우리가 이 안내서에서 직접 만들 대상입니다.

주체	한 줄 정의	개수 관계	우리가 만드나?
Host	사용자를 응대하는 AI 앱 (LLM 포함)	1	(보통 기존 호스트 사용)
Client	서버 하나와 1:1로 말하는 연결 담당	서버 수만큼	6부에서 다룸
Server	도구·데이터·프롬프트를 노출하는 주방	여러 개 가능	5부에서 직접 제작

"서버는 호스트를 모른다"

이 한 문장이 MCP 재사용성의 핵심입니다. 서버는 표준 메시지에만 응답할 뿐, 상대가 Claude Desktop인지 IDE인지 신경 쓰지 않습니다. 그래서 당신이 만든 서버는 오늘은 Claude Desktop에서, 내일은 다른 호스트에서 코드 변경 없이 동작합니다.

뒤집어 말하면, 서버는 "누가 부르는지 신뢰할 수 없다"는 뜻이기도 합니다.

🔒 보안 시사점: 서버가 호스트를 특정하지 못한다는 건, 들어오는 입력과 호출자를 기본적으로 신뢰하지 말아야 한다는 뜻입니다. 도구 인자 검증, 권한 확인, 위험한 작업에 대한 사람 확인(human-in-the-loop)을 서버 쪽에서 챙겨야 합니다. (7부에서 깊이 다룹니다.)

어디서 어떻게 도느냐 — 전송과의 관계

같은 세 주체라도 어디에 사는지에 따라 전송 방식이 달라집니다.

로컬: 서버가 클라이언트와 같은 머신에서 자식 프로세스로 돌고, stdio(표준 입출력)로 대화 — 네트워크 없음.
원격: 서버가 별도 HTTP 서비스로 돌고, Streamable HTTP로 대화 — 여러 클라이언트를 받을 수 있음.

전송은 3부에서 본격적으로 다룹니다. 지금은 "같은 메시지를 다른 통로로 보낼 수 있다"는 점만 기억하면 됩니다.

이 장에서 배운 것

Host는 AI 앱(식당), Client는 서버 하나와 1:1로 말하는 연결 담당(웨이터), Server는 도구·데이터·프롬프트를 내놓는 주방.
클라이언트와 서버는 1:1이며, 여러 서버를 쓰는 복잡성은 호스트가 클라이언트를 여러 개 관리해 흡수한다.
서버는 호스트를 모른다 — 그래서 재사용 가능하지만, 동시에 호출자를 신뢰하지 말아야 한다.
우리가 이 안내서에서 직접 만들 대상은 주로 서버다.

✍️ 확인 문제

한 호스트가 파일시스템·DB·캘린더 세 서버에 붙으려면 클라이언트는 몇 개 필요한가? 그 이유는?
"서버는 호스트를 모른다"가 재사용성에 좋은 점과, 동시에 보안상 주의할 점을 각각 한 가지씩 들어 보자.
식당 비유에서 LLM은 어디에 해당하나? Host·Client·Server 중 무엇과 가장 가까운가?

다음 장: 03. 다른 접근과의 비교, 그리고 생태계

← 이전01. 왜 MCP인가 — M×N 통합 문제와 해법다음 →03. 다른 접근과의 비교, 그리고 생태계