TL;DR

• MCP는 한 번의 도구 호출을 Host, Client, Server라는 구분된 세 역할로 나눠 처리한다. 외부 서비스는 Server 뒤의 선택적 backend일 뿐 MCP 참여자가 아니다.
• Host는 앱 전체를 조정하는 컨테이너다. LLM 통합·sampling과 여러 Client의 생성·관리를 맡는다.
• Client는 Host가 만드는 프로토콜 엔드포인트로, Server 하나와 정확히 1:1로 통신한다.
• Server는 도구·리소스를 구현해 노출한다. 실제 작업은 Server 자신이 하거나 뒤의 외부 서비스에 위임한다.

MCP는 Host·Client·Server·외부 서비스로 역할을 나눈다

MCP 상호작용은 한 덩어리로 도는 게 아니다. 책임이 나뉜 참여자들이 협업한다. 흔한 오해가 둘 있다. "MCP Client = LLM", 그리고 "Host = Client"다. 둘 다 틀렸다. 공식 아키텍처는 Host, Client, Server를 세 개의 구분된 역할로 정의한다. Host는 앱을 조정하는 컨테이너, Client는 Host가 만들어 Server 하나에 연결하는 프로토콜 엔드포인트, Server는 도구 제공자다. LLM 통합은 Host의 책임이지만 모델 추론은 외부 API에서 수행될 수도 있다. MCP Architecture.

graph TD
    U[User] --> H
    subgraph H[Host 애플리케이션]
        L[LLM 통합·sampling·조정]
        CA[Client A]
        CB[Client B]
    end
    L -. 도구 후보 선택 .-> CA
    CA -->|1:1| SA[Server A: 도구 구현]
    CB -->|1:1| SB[Server B: 도구 구현]
    SA -. 선택적 .-> EA[외부 backend: API·DB·파일]

각 역할

역할	정체	책임
User	사람	자연어로 의도를 전달
Host	앱 컨테이너 (예: Claude Desktop, IDE)	앱 조정, LLM 통합·sampling, 여러 Client 생성·관리, 사용자 승인·보안 정책
LLM	Host가 통합하는 로컬 또는 원격 모델	자연어 이해, 도구 후보 선택, 결과 해석
Client	Host가 만드는 프로토콜 엔드포인트	Server 하나와 1:1 연결, JSON-RPC 송수신, 버전·capability 교섭, 구독·알림
Server	도구 제공자 (예: GitHub MCP)	도구·리소스 구현·노출, 입력 검증, 로직 실행
(외부 backend)	Server 뒤의 선택적 시스템	원격 API·DB·파일. Server가 직접 처리할 수도 있어 필수 참여자가 아니다

Host, Client, Server는 구분된 세 역할

Host는 앱 전체의 컨테이너이자 조정자다. 그 안에서 여러 Client 인스턴스를 생성하고 관리한다. 각 Client는 Host가 만들며 Server 하나와 정확히 1:1로 통신한다. Server는 도구·리소스를 구현해 노출한다. 한 제품·프로세스 안에 Host와 Client가 함께 구현될 수 있다는 사실이 둘을 같은 역할로 만들지는 않는다. 공식 문서도 "Host는 컨테이너이자 조정자", "각 Client는 Host가 만들어 Server 하나와 통신"으로 나눠 정의한다.

Host는 LLM 통합을, Client는 프로토콜을 맡는다

LLM 통합과 sampling 조정은 Host의 책임이다. Client는 Host가 관리하는 프로토콜 엔드포인트로, Server 하나와의 메시지·버전 교섭·구독·알림을 담당한다. 특정 앱이 LLM 객체를 Client 옆에 합성(composition)으로 두는 구현은 가능하지만, 그건 그 앱의 선택이지 MCP 역할 정의가 아니다. 역할을 이렇게 나누면 실익이 있다.

• 교체 가능성: 판단 모델을 바꿔도 프로토콜·통신 코드는 그대로다.
• 테스트 용이성: LLM을 목(mock)으로 갈아 끼워 프로토콜 경로만 검증할 수 있다.
• 관심사 분리: Host는 조정·정책, Client는 프로토콜, Server는 실행을 맡는다. Client·LLM의 경계를 워크플로우로 본 것이 MCP에서 도구 발견은 코드가 하고 선택은 LLM이 한다이다.

왜 이렇게 나누나

지원하는 버전·기능이 맞으면 공통 프로토콜로 새 Server를 통합하고 여러 Host에서 재사용하기 쉽다. 다만 인증·확장 지원에 따라 추가 구현이 필요할 수 있다. Client와 Server의 1:1 관계는 Client 인스턴스 기준이며, 원격 Server 하나가 여러 Client를 받는 것을 막지 않는다. 모델 판단과 실행 환경의 역할 분리는 하네스 엔지니어링과 연결된다.

---

Connections

• MCP에서 도구 발견은 코드가 하고 선택은 LLM이 한다 — Host/Client(코드)와 LLM(판단)의 역할 경계를 실행 흐름으로 본 노트
• MCP는 JSON-RPC 2.0 요청-응답으로 도구를 호출한다 — Client와 Server가 이 역할대로 주고받는 메시지 규격
• Model Context Protocol 2026-07-28 사양은 핸드셰이크와 프로토콜 세션을 없앤다 — 이 역할 구조 위에서 전송·세션 방식을 바꾼 개정
• 하네스 엔지니어링은 모델 바깥의 실행 환경을 설계하는 일이다 — Host·Client·Server=결정적 하네스, LLM=모델이라는 대응

Related MOCs

• MOCs - Harness Engineering
• MOCs - Computer Science(CS)