IT 실무자를 위한 MCP 개념 정리: 호스트·클라이언트·서버와 연결 방식

AI 도구에 사내 문서 검색, 이슈 조회, 데이터베이스 조회 같은 기능을 붙이려면 예전에는 도구마다 별도 플러그인이나 연동 코드를 만들어야 했다. AI 도구가 N개, 연결할 시스템이 M개면 연동도 N×M개가 된다. Model Context Protocol(MCP)은 이 연결 방식을 하나의 표준 프로토콜로 맞춰, 시스템 쪽은 MCP 서버 하나만 만들면 MCP를 지원하는 여러 AI 도구에서 쓸 수 있게 한다. 이 글은 공식 명세의 현재 버전인 2026-07-28을 기준으로, 설정 파일을 읽고 도입을 판단할 수 있을 만큼의 개념을 정리한다.

세 가지 역할: 호스트, 클라이언트, 서버

명세의 아키텍처 문서는 MCP를 클라이언트-호스트-서버 구조로 설명한다. 헷갈리기 쉬운 점은 "클라이언트"가 사용자가 쓰는 앱 자체가 아니라는 것이다.

호스트 하나가 여러 클라이언트를 만들고, 각 클라이언트는 정확히 하나의 서버와 연결된다. 명세의 설계 원칙 중 실무에서 중요한 것은 "서버는 전체 대화를 읽거나 다른 서버를 들여다볼 수 없어야 한다"는 항목이다. 대화 기록은 호스트에 남고, 서버는 필요한 정보만 받는다. 여러 서버를 붙여도 서로의 데이터가 섞이지 않게 막는 책임이 호스트에 있다는 뜻이다.

서버가 제공하는 것: 도구, 리소스, 프롬프트

서버가 제공하는 기능은 세 종류다. 도구는 모델이 호출해 실제 작업을 하는 함수(예: 이슈 검색, 쿼리 실행), 리소스는 맥락으로 읽어 들일 데이터(예: 파일, 문서), 프롬프트는 재사용할 수 있는 요청 템플릿이다. 도구 명세는 도구가 모델이 스스로 골라 호출하는 방식(model-controlled)이라고 설명하면서, 사람이 호출을 거부할 수 있는 단계가 항상 있어야 한다고 권고한다. 도입 검토에서 가장 먼저 볼 것도 결국 "이 서버가 어떤 도구를 노출하고, 그중 무엇이 데이터를 바꾸는가"다.

요청은 이렇게 생겼다

MCP는 JSON-RPC 위에서 동작한다. 2026-07-28 버전부터는 연결 시작 시의 초기화 절차(handshake)가 없어지고, 모든 요청이 자기 프로토콜 버전을 _meta에 담아 보내는 무상태 구조가 됐다. 도구 호출 요청은 대략 다음과 같다.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": { "query": "로그인 오류", "limit": 5 },
    "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" }
  }
}

버전 문서에 따르면 서버가 요청한 버전을 지원하지 않으면 지원 버전 목록과 함께 UnsupportedProtocolVersionError를 돌려주고, 클라이언트는 공통 버전으로 다시 요청한다. 서버는 지원 버전과 기능을 알려 주는 server/discover를 반드시 구현해야 한다. 이전 방식(2025-11-25 이하)과의 차이와 옮길 때 확인할 항목은 MCP 2026-07-28 무상태 전환 가이드에서 따로 다룬다.

로컬 서버와 원격 서버: 연결 방식이 보안을 가른다

서버와 연결하는 방식(transport)은 두 가지가 기본이다. stdio는 호스트가 서버를 로컬 프로세스로 직접 실행하고 표준 입출력으로 통신하는 방식이고, Streamable HTTP는 네트워크 너머의 서버와 HTTP로 통신하는 방식이다. 둘의 차이는 인증에서 드러난다. 인가 명세는 HTTP 기반 연결은 OAuth 2.1 기반 절차를 따르도록 하고, stdio 연결은 이 절차 대신 환경 변수 등 실행 환경에서 자격 증명을 가져오도록 권한다.

• stdio(로컬): 설정 파일에 실행 명령과 인자를 적는다. 서버가 내 계정 권한으로 실행되므로 명령의 출처 확인이 중요하다.
• Streamable HTTP(원격): 설정에 URL을 적고, 처음 연결할 때 브라우저로 로그인해 권한 범위(scope)를 승인한다.

로컬 서버를 설정 파일로 추가하는 실제 예시는 VS Code Continue와 MCP 연동 가이드에, 원격 서버를 직접 만들 때의 인증 구현은 MCP 서버 OAuth 구현 항목에 정리했다.

도입을 판단할 때 던질 질문

1. 연결하려는 시스템에 이미 공식 MCP 서버가 있는가, 직접 만들어야 하는가
2. 그 서버는 로컬(stdio)인가 원격(HTTP)인가, 원격이라면 어떤 권한 범위를 요청하는가
3. 노출되는 도구 중 쓰기·삭제·실행 도구는 무엇이고, 호스트에서 호출 전 확인을 켤 수 있는가
4. 도구 호출 기록을 어디에 남기고 누가 확인하는가

이 질문에 답하는 과정이 곧 MCP 도입의 보안 설계다. 공식 보안 문서가 경고하는 위험과 권한을 넓혀 가는 순서는 MCP 서버를 늘리기 전에 칼럼에서 이어서 다룬다.