“MCP Client가 AI 앱이고, MCP Server가 외부 서비스 아닌가요?”
절반은 맞지만 정확한 설명은 아닙니다. 사용자가 보는 AI 애플리케이션 전체는 Host이고, 그 안에서 특정 Server와 통신하는 구성요소가 Client입니다. Server는 외부 데이터와 기능을 MCP 방식으로 제공합니다.
이번 글에서는 세 역할을 한눈에 구분하고, 왜 Server마다 전용 Client가 필요한지, 로컬과 원격 연결은 무엇이 다른지 최신 MCP 구조를 기준으로 알아보겠습니다.
1. MCP 구조를 한 장으로 이해하기
MCP는 Host → Client → Server 구조로 이해하면 쉽습니다. Host가 전체 작업을 조정하고, Host가 만든 Client가 특정 Server와 통신하며, Server가 Tool·Resource·Prompt 같은 기능과 컨텍스트를 제공합니다.
여기서 Server는 반드시 인터넷 어딘가에 있는 컴퓨터를 뜻하지 않습니다. 사용자 PC에서 실행되는 로컬 프로그램도, 클라우드에서 실행되는 원격 서비스도 MCP Server가 될 수 있습니다.
2. MCP Host는 전체 경험을 관리한다
Host는 사용자가 직접 대화하고 작업을 요청하는 AI 애플리케이션입니다. Claude Code, Cursor, Codex, VS Code처럼 MCP 연결을 지원하는 앱을 떠올리면 됩니다. Host는 단순한 화면이 아니라 모델과 MCP 연결 사이의 통제 지점입니다.
연결할 Server마다 Client를 만들고 연결 상태와 수명 주기를 관리합니다.
여러 Server에서 발견한 Tool·Resource·Prompt를 사용자와 모델이 쓸 수 있게 정리합니다.
중요한 Tool 호출 전에 확인 화면을 보여 주거나 조직 정책을 적용합니다.
어떤 결과를 모델에 전달할지 결정하고 Server 간 정보가 섞이지 않도록 경계를 관리합니다.
Host는 연결된 Server 목록과 도구를 모델에게 제공하고 실행을 중개합니다. 따라서 Server를 신뢰하는 것만큼 Host의 권한 관리, 승인 화면과 로그 정책을 확인하는 일도 중요합니다.
3. MCP Client는 Server별 전용 연결이다
Client는 Host 안에서 MCP 통신을 담당하는 구성요소입니다. 공식 아키텍처에서 Host는 각 MCP Server마다 하나의 MCP Client를 만듭니다. Client는 해당 Server가 제공하는 기능과 버전을 발견하고 요청을 보내며 결과를 Host에 전달합니다.
Client가 담당하는 일은 전송 방식에 따라 조금 달라질 수 있지만 핵심은 같습니다. Server의
기능을 확인하고, MCP 메시지를 주고받고, 오류와 결과를 Host가 사용할 수 있는 형태로 전달합니다.
| Client의 역할 | 쉬운 설명 | 예시 |
|---|---|---|
| 서버 발견 | Server가 지원하는 버전과 기능을 확인 | Tools와 Resources 지원 여부 확인 |
| 요청 전달 | 모델 또는 사용자가 선택한 작업을 Server에 전송 | 문서 검색 Tool 호출 |
| 결과 수신 | 응답과 오류를 받아 Host에 전달 | 검색 결과나 권한 오류 표시 |
| 연결 격리 | 다른 Server의 연결과 기능을 분리 | Figma 연결과 Drive 연결을 별도 관리 |
4. MCP Server는 기능과 컨텍스트를 제공한다
Server는 외부 시스템의 기능과 데이터를 MCP가 이해하는 공통 형식으로 제공합니다. 직접 파일을 읽거나 데이터베이스를 조회할 수도 있고, 기존 REST API나 사내 서비스를 호출하는 어댑터 역할을 할 수도 있습니다.
좋은 Server는 많은 기능을 무조건 노출하지 않습니다. 도구 이름과 설명, 입력 스키마를 명확하게 만들고, 업무에 필요한 권한만 요청하며, 실패했을 때 Host와 사용자가 원인을 이해할 수 있는 오류를 반환해야 합니다.
5. 왜 Client와 Server는 1:1로 연결될까?
Host 안에 Client 하나만 두고 모든 Server를 연결하면 단순해 보일 수 있습니다. 하지만 Server마다 지원 기능, 인증, 신뢰 수준과 장애 상태가 다르므로 연결을 분리하는 편이 안전하고 관리하기 쉽습니다.
어떤 Tool이 어느 Server에서 왔는지 추적하기 쉽습니다.
한 Server의 연결 실패가 다른 Server의 연결 상태와 섞이지 않습니다.
Server마다 다른 인증 정보와 접근 범위를 적용할 수 있습니다.
필요한 연결만 시작·중지하고 업데이트할 수 있습니다.
분리된 Client는 경계를 만들기 좋은 구조일 뿐입니다. Host가 서버별 도구를 구분하고, 인증 정보를 섞지 않으며, 사용자 승인과 로그를 제대로 적용해야 실제 보안 경계가 됩니다.
6. 로컬 Server와 원격 Server는 무엇이 다를까?
MCP Server는 실행 위치와 전송 방식에 따라 크게 로컬과 원격으로 나눌 수 있습니다. 로컬 Server는 보통 Host와 같은 컴퓨터에서 실행되며 STDIO로 통신합니다. 원격 Server는 네트워크 너머에서 실행되며 일반적으로 Streamable HTTP를 사용합니다.
| 구분 | 로컬 MCP Server | 원격 MCP Server |
|---|---|---|
| 실행 위치 | Host와 같은 컴퓨터의 별도 프로세스 | 클라우드 또는 외부 서버 |
| 대표 전송 | STDIO | Streamable HTTP |
| 대표 활용 | 로컬 파일, 개발 도구, 개인 스크립트 | SaaS, 조직 데이터, 중앙 관리 서비스 |
| 주요 확인 | 실행 명령, 설치 패키지, 로컬 파일 권한 | URL, OAuth·토큰, TLS, 서버 운영 주체 |
| 장점 | 낮은 지연, 로컬 자원 접근, 간단한 개인 실습 | 중앙 업데이트, 여러 사용자 지원, 조직 정책 적용 |
STDIO는 Host가 Server 프로세스를 실행하고 표준 입력과 출력으로 메시지를 주고받는 방식입니다. Streamable HTTP는 HTTP 요청을 사용해 원격 Server와 통신하며 표준 웹 인증 방식을 적용할 수 있습니다. 어떤 방식이 더 우수한 것이 아니라 실행 위치와 운영 목적에 따라 선택합니다.
7. 실제 요청은 어떤 순서로 이동할까?
현재 MCP 2026-07-28 구조에서 Client는 필요하면 Server의 지원 버전과 기능을 발견하고, 각 요청에 필요한 프로토콜 정보와 기능 정보를 담아 Server로 전달합니다. 모델이 Tool 사용을 제안하더라도 Host의 권한 확인과 승인 정책을 거친 뒤 실행되어야 합니다.
↓
② Client가 필요하면 Server 버전·기능 발견
↓
③ Host가 사용 가능한 Tool을 모델과 사용자에게 제공
↓
④ 모델이 Tool과 입력값을 제안
↓
⑤ Host가 권한과 사용자 승인을 확인
↓
⑥ Client가 Server에 요청하고 결과 수신
↓
⑦ Host가 결과를 검증해 모델과 사용자에게 전달
2025년 계열 사양은 연결 초기에
initialize 교환과 세션을 사용했습니다. 2026-07-28 사양은 상태 비저장 구조와 선택적 server/discover를 사용합니다. 실제 설정과 개발에서는 Host, Server와 SDK가 지원하는 사양 버전을 먼저 확인하세요.8. 연결 전에 무엇을 확인해야 할까?
MCP 설정 파일에 Server 하나를 추가하는 일은 단순한 즐겨찾기 추가가 아닙니다. Host에 새로운 데이터 접근 경로와 실행 기능을 연결하는 작업입니다. 역할별로 확인할 책임을 나누면 위험을 더 쉽게 발견할 수 있습니다.
Server의 이름과 버전 정보는 표시와 디버깅에 유용하지만 보안 신원의 증거는 아닙니다. 공식 배포 경로, 코드 서명·패키지 출처, 원격 도메인, OAuth 권한과 조직 정책을 별도로 확인해야 합니다.
9. 핵심 정리
Host = 전체 조정과 승인 Client = Server별 전용 연결 Server = 기능과 데이터 제공 로컬 = 주로 STDIO 원격 = 주로 Streamable HTTP
사용자는 Host에 요청하고, Host는 Server마다 별도의 Client를 통해 통신합니다. Server는 Tool·Resource·Prompt를 제공하며 기존 API나 파일·데이터베이스를 연결할 수 있습니다. 이 역할 분리는 기능과 오류, 인증과 신뢰 경계를 관리하기 위한 구조이지 안전을 자동 보장하는 장치는 아닙니다.
다음 글에서는 MCP와 API가 경쟁 관계인지, Function Calling과는 어떻게 다른지, 어떤 상황에서 API만 쓰고 언제 MCP 계층을 추가하면 좋은지 비교하겠습니다.
🔗 MCP 완전정복 시리즈
참고: MCP 공식 Architecture overview, MCP 공식 Server concepts, MCP 2026-07-28 공식 사양, MCP TypeScript SDK v2 Protocol versions
확인일: 2026-09-19 · MCP 사양과 Host별 구현은 변경될 수 있으므로 실제 연결 전 최신 공식 문서를 확인하세요.