MCP의 기본 구조 한눈에 보기

2026-09-15Views 15약 8분생성형 AI 활용

Summary

MCP는 '앱 하나'가 아니라 세 부분의 협업이다

MCP를 처음 볼 때 가장 헷갈리는 지점은 "어디까지가 AI 앱이고, 어디부터가 MCP 서버인가?"이다. Claude Desktop, Cursor, VS Code 같은 앱을 열고 설정 파일에 서버를 추가하다 보면, 서버가 AI 모델처럼 느껴지기도 하고, 클라이언트가 별도 프로그램처럼 보이기도 한다.

간단히 나누면 이렇다.

Host: 사용자가 실제로 대화하고 작업하는 AI 애플리케이션
Client: Host 안에서 특정 MCP Server와 연결을 유지하는 통신 담당자
Server: 파일, 데이터베이스, SaaS API, 사내 시스템을 MCP 규칙으로 감싸서 제공하는 프로그램

비유하자면 Host는 호텔 프런트, Client는 각 부서로 연결되는 전용 내선, Server는 객실 관리·식당·주차장 같은 실제 서비스를 제공하는 부서다. 사용자는 프런트에 요청한다. 프런트는 필요한 부서에 연락하고, 부서에서 받은 결과를 정리해 사용자에게 돌려준다.

MCP 공식 문서도 이 구조를 Host, Client, Server의 관계로 설명한다. Host는 하나 이상의 Server에 연결할 수 있고, 이를 위해 Server마다 MCP Client를 만든다. 각 Client는 자신에게 대응되는 Server와 전용 연결을 유지한다.¹ 이 한 문장만 기억해도 MCP 설정 화면에서 길을 잃을 가능성이 크게 줄어든다.

MCP의 기본 구조 한눈에 보기 AI 생성 이미지

Host: 사용자가 만지는 AI 작업 공간

MCP Host는 사용자가 직접 여는 애플리케이션이다. 예를 들면 Claude Desktop, Cursor, VS Code 같은 도구가 Host 역할을 할 수 있다. 중요한 점은 Host가 단순한 채팅창이 아니라는 것이다. Host는 다음 일을 맡는다.

사용자 입력을 받는다.
LLM에게 어떤 맥락과 도구가 있는지 알려준다.
여러 MCP Server 연결을 관리한다.
도구 실행 전 사용자 허가를 받거나 보안 정책을 적용한다.
서버에서 돌아온 결과를 다시 모델과 사용자에게 전달한다.

즉 Host는 "모델을 호출하는 앱"이면서 동시에 "외부 도구 사용을 조율하는 작업대"다. 사용자가 "이 폴더의 회의록을 읽고 이번 주 할 일을 정리해 줘"라고 말하면, Host는 모델에게 요청을 전달하는 것에서 끝나지 않는다. 연결된 파일 서버가 있는지 확인하고, 필요한 경우 파일 읽기 도구를 호출하며, 결과를 모델에게 다시 넣어 최종 답변을 만들게 한다.

여기서 주의할 점이 있다. Host와 LLM은 같은 말이 아니다. LLM은 텍스트를 이해하고 생성하는 모델이다. Host는 그 모델을 사용자가 쓸 수 있는 형태로 감싸고, 외부 도구와 연결해 주는 애플리케이션이다. 어떤 Host는 모델을 내부 서비스처럼 제공하고, 어떤 Host는 외부 모델 API를 호출한다. 사용 권한 확인, 서버 연결, UI 표시, 설정 관리 같은 일은 보통 Host가 담당한다.

Client: Host 안의 전용 연결 담당자

MCP Client는 사용자가 직접 실행하는 앱처럼 보이지 않는 경우가 많다. 대부분 Host 내부에 들어 있다. 그래서 초보자는 "내가 Client를 설치한 적이 없는데?"라고 느낄 수 있다.

MCP에서 Client는 특정 Server 하나와 대화하는 연결 단위다. Host가 GitHub 서버, 파일시스템 서버, Slack 서버를 동시에 연결한다면 Host 안에는 보통 서버 수만큼 Client 연결이 생긴다. 명세에서도 하나의 Host가 여러 Client 인스턴스를 만들 수 있고, 각 Client는 특정 Server와 1:1 세션을 유지한다고 설명한다.²

여기서 말하는 1:1은 "Client 하나가 담당하는 연결 상대가 Server 하나"라는 뜻이다. 원격 MCP Server처럼 여러 사용자나 여러 Host가 함께 접속할 수 있는 서버라면, 서버 전체가 Client 하나만 받는다는 의미는 아니다. Server 입장에서는 여러 Client를 받을 수 있지만, Host 내부에서 만들어진 개별 Client는 자신에게 배정된 Server와 전용 연결을 유지한다고 보면 된다.

Client가 하는 일은 크게 네 가지다.

세션 시작: Server와 연결하고 초기화한다.
기능 확인: Server가 어떤 도구, 리소스, 프롬프트를 제공하는지 확인한다.
메시지 전달: Host의 요청을 Server에 보내고, Server의 응답을 Host로 돌려준다.
상태 관리: 연결이 살아 있는지, 알림이나 구독이 필요한지 관리한다.

이 과정에서 MCP는 JSON-RPC 기반 메시지를 사용한다. JSON-RPC는 "어떤 메서드를 호출할지"와 "파라미터가 무엇인지"를 JSON 형식으로 주고받는 가벼운 원격 호출 규칙이다. 개발자가 아니라면 세부 문법을 모두 외울 필요는 없다. 다만 MCP Client와 Server는 그냥 아무 문자열이나 주고받는 것이 아니라, 정해진 메시지 형식으로 대화한다는 점을 이해하면 된다.

예를 들어 Host가 파일 서버에 "문서 목록을 보여줘"라고 요청해야 한다면, Client는 이를 MCP 메시지로 바꿔 Server에 보낸다. Server는 결과를 MCP 형식으로 돌려주고, Client는 그 결과를 Host가 이해할 수 있게 전달한다.

Server: 외부 세계를 MCP 규칙으로 감싸는 프로그램

MCP Server는 실제 기능을 제공하는 쪽이다. 하지만 Server가 꼭 거대한 백엔드 시스템일 필요는 없다. 내 노트북에서 실행되는 작은 프로그램일 수도 있고, 사내 API 앞단에 붙인 서비스일 수도 있고, 클라우드에 배포한 원격 서버일 수도 있다.

Server가 감쌀 수 있는 대상은 다양하다.

로컬 파일과 폴더
PostgreSQL, SQLite 같은 데이터베이스
GitHub, GitLab, Slack 같은 SaaS API
사내 문서 검색 시스템
업무 자동화 스크립트
웹 검색, 브라우저 자동화, 시간 변환 같은 유틸리티

공식 예시 서버들도 파일시스템, Git, 데이터베이스, 웹 가져오기, Slack, GitHub 등 여러 범주의 외부 시스템을 MCP로 노출한다.³

Server는 보통 세 가지 형태로 기능을 제공한다.

Tools: 실행 가능한 기능이다. 예: 파일 읽기, 이슈 생성, DB 조회, Slack 메시지 작성
Resources: 모델이 읽거나 참고할 수 있는 데이터다. 예: 문서, 파일, 레코드, 로그
Prompts: 자주 쓰는 지시문이나 작업 템플릿이다. 예: 코드 리뷰 프롬프트, 회의록 요약 프롬프트

이 장에서는 세 단어의 차이를 깊게 다루지 않는다. 지금은 Server가 "AI 작업 공간에서 꺼내 쓸 수 있는 기능과 맥락을 메뉴판처럼 제공한다"고 이해하면 충분하다. 다음 장에서 Tools, Resources, Prompts의 차이를 따로 정리한다.

하나의 Host가 여러 Server를 연결할 때

실제 업무에서는 Server 하나만 연결하는 경우보다 여러 Server를 함께 쓰는 경우가 많다. 예를 들어 Cursor에 다음 MCP Server들을 연결했다고 해 보자.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./project"]
    },
    "github": {
      "command": "docker",
      "args": ["run", "github-mcp-server"]
    },
    "slack": {
      "command": "node",
      "args": ["./servers/slack/index.js"]
    }
  }
}

위 예시는 구조를 보여주기 위한 단순화된 형태다. 실제 설정 키와 실행 방식은 Host와 Server마다 다를 수 있다. 중요한 것은 mcpServers 아래에 여러 서버가 있고, Host가 각각에 대해 별도 Client 연결을 만든다는 점이다.

사용자가 이렇게 요청했다고 하자.

"이번 주 닫힌 GitHub 이슈를 요약하고, 팀 Slack에 올릴 공유 초안을 만들어 줘. 내가 확인하면 전송까지 해 줘."

실행 흐름은 대략 다음과 같다.

사용자가 Host에 요청한다.
Host는 현재 연결된 Server 목록과 각 Server의 기능을 모델에게 알려준다.
모델은 GitHub Server의 이슈 조회 도구가 필요하다고 판단한다.
Host는 필요한 경우 사용자에게 "GitHub 데이터를 조회해도 되나요?"라고 확인한다.
GitHub Client가 GitHub Server에 도구 호출 메시지를 보낸다.
GitHub Server는 GitHub API를 호출하고 결과를 반환한다.
Host는 결과를 모델에게 전달한다.
모델은 요약문과 Slack 공유 초안을 만든다.
사용자가 초안을 확인하고 전송을 원하면, Host는 Slack 메시지 작성 도구 실행을 다시 확인한다.
Slack Client가 Slack Server에 메시지 작성 요청을 보내고, Host는 실행 결과를 사용자에게 보여준다.

여기서 핵심은 모델이 모든 외부 시스템에 직접 접속하는 것이 아니라는 점이다. 모델은 "어떤 도구가 필요할지" 판단하는 데 참여하고, Host가 권한과 실행 흐름을 통제하며, Client가 Server와 통신하고, Server가 실제 외부 시스템을 다룬다.

전체 호출 과정을 한 줄로 그리기

MCP의 호출 흐름을 가장 단순하게 쓰면 다음과 같다.

사용자 요청
  ↓
Host가 요청을 받고 사용 가능한 MCP 기능을 모델에 제공
  ↓
모델과 Host가 필요한 기능이나 맥락을 결정
  ↓
Host가 권한과 정책을 확인
  ↓
해당 Server와 연결된 Client가 MCP 메시지 전송
  ↓
Server가 파일, DB, API, 사내 시스템을 호출하거나 필요한 데이터를 반환
  ↓
Server 결과가 Client를 거쳐 Host로 반환
  ↓
Host가 결과를 모델에 반영하고 사용자에게 답변

이 흐름을 이해하면 MCP 문서의 여러 표현이 덜 낯설어진다. "서버를 추가한다"는 말은 LLM을 하나 더 붙인다는 뜻이 아니다. Host가 사용할 수 있는 외부 기능 제공자를 하나 더 등록한다는 뜻이다. "클라이언트가 서버와 세션을 만든다"는 말은 Host 내부의 연결 담당자가 특정 Server와 대화할 준비를 마쳤다는 뜻이다.

구조를 이해할 때 조심할 점

첫째, Server는 모든 대화 내용을 알아야 하는 존재가 아니다. MCP 구조에서는 Host가 전체 대화와 사용자 경험을 관리하고, Server는 자신에게 필요한 요청만 처리하는 쪽에 가깝다. 이 분리는 보안상 중요하다. 파일 서버가 Slack 서버의 내용까지 볼 필요는 없고, GitHub 서버가 사용자의 전체 대화 기록을 가져갈 이유도 없다. 필요한 맥락만 필요한 Server에 전달되도록 설계하는 것이 좋다.

둘째, 도구가 보인다고 항상 실행되는 것은 아니다. 좋은 Host는 민감한 작업 전에 사용자 확인을 요구한다. 예를 들어 파일 삭제, 메시지 전송, 결제, 운영 DB 수정 같은 작업은 반드시 권한 확인과 제한이 필요하다.

셋째, Server의 품질이 결과 품질을 좌우한다. 모델이 아무리 똑똑해도 Server가 부정확한 데이터를 주거나, 도구 설명이 모호하거나, 권한 범위가 과도하면 위험한 결과가 나온다. MCP는 연결 표준이지 품질 보증 장치가 아니다.

넷째, 여러 Server를 연결할수록 편리하지만 공격면도 넓어진다. 연결된 Server가 많아지면 모델이 선택할 수 있는 행동도 많아진다. 파워유저라면 꼭 필요한 Server만 켜고, 개발자라면 Server별 권한과 로그를 분리해 관리해야 한다.