등장인물 소개: Host, Client, Server 그리고 세 가지 마법 도구

용어만 정리돼도 MCP 문서가 갑자기 쉬워진다

MCP 문서를 처음 읽으면 이상하게 단어는 쉬운데 문장은 어렵습니다. Host, Client, Server, Tool, Resource, Prompt… 전부 어디선가 본 말 같은데, 막상 이어 붙이면 머리가 잠깐 멈춥니다.

그 이유는 간단합니다. 단어 뜻을 사전식으로 아는 것과, 누가 무슨 역할을 맡는지 머릿속에 장면으로 그려지는 것은 완전히 다르기 때문입니다.

이번 장에서는 복잡한 규격 이야기는 잠시 미뤄 두고, MCP 무대 위의 등장인물부터 소개하겠습니다. 이 장만 제대로 이해해도 이후 문서에서 이런 문장이 훨씬 편하게 읽힙니다.

"Host가 Client를 통해 Server와 연결하고, Server는 Tools·Resources·Prompts를 노출한다."

처음엔 주문 같지만, 알고 나면 그냥 평범한 설명입니다.

먼저 한 장면만 떠올려 보자

당신이 Claude Desktop이나 Cursor 같은 앱에서 이렇게 말한다고 해 봅시다.

"내 프로젝트 README를 읽고, 해야 할 일을 정리해서 이슈 초안으로 만들어 줘."

이 한 문장 뒤에는 사실 여러 역할이 움직입니다.

사용자와 직접 만나는 앱이 있습니다. 이 앱은 전체 상황을 조율합니다. 이게 Host입니다.

그 앱 안에는 특정 MCP 서버와 실제로 대화하는 연결 담당이 있습니다. 이게 Client입니다.

그리고 파일 읽기나 GitHub 연동 같은 실제 기능을 제공하는 별도 프로그램이나 서비스가 있습니다. 이게 Server입니다.

즉, 사용자는 보통 Host만 보지만, 실제 뒤편에서는 Client가 뛰어다니고, Server가 일을 합니다.

이제 각 역할을 차근차근 보겠습니다.

Host: 사용자가 만나는 무대 감독

Host는 사용자가 직접 사용하는 AI 애플리케이션입니다. Claude Desktop, VS Code 확장, Cursor, 사내 AI 챗 앱 같은 것이 여기에 들어갑니다.

쉽게 말해 Host는 전체 상황을 지휘하는 총감독입니다. 사용자의 질문을 받고, 어떤 MCP 서버가 필요한지 판단하고, 결과를 다시 사람 말로 정리해 보여 줍니다.

중요한 점은 Host가 단순한 채팅창이 아니라는 것입니다. Host는 보통 다음과 같은 일을 맡습니다.

사용자의 요청을 받아 해석하고, 어떤 기능을 보여 줄지 결정합니다. 또한 어떤 서버를 연결할지, 어떤 도구 실행은 허용하고 어떤 것은 막을지 같은 정책도 관리합니다. 쉽게 말해 Host는 "이 무대에서 누구를 출연시킬 것인가?"를 결정하는 사람입니다.

그래서 Host는 보통 권한과 승인에 민감합니다. 예를 들어 파일을 읽는 건 허용해도, 파일을 지우는 건 다시 물어보게 만들 수 있습니다. 사용자는 이 결정을 직접 의식하지 않을 때가 많지만, 안전한 MCP 경험은 대개 Host의 판단 위에서 만들어집니다.

한 문장으로 정리하면 이렇습니다.

Host는 사용자가 만나는 앱이며, 전체 흐름과 권한을 관리하는 중심입니다.

Client: 말이 통하게 만드는 통역사

Client는 Host 안에서 움직이는 연결 담당자입니다. Host와 Server 사이에서 실제 프로토콜 통신을 맡습니다.

이 부분이 처음엔 가장 헷갈립니다. 많은 사람이 Host와 Client를 같은 것으로 생각합니다. 실제로 둘이 같은 앱 안에 들어 있는 경우가 많기 때문입니다. 하지만 역할은 분명히 다릅니다.

Host가 "무엇을 할지 결정하는 쪽"이라면, Client는 "그 결정을 실제 메시지로 주고받는 쪽"입니다.

예를 들어 Host가 "파일 서버에 도구 목록 좀 물어봐"라고 판단하면, 실제로 MCP 형식에 맞는 요청을 보내고 응답을 받는 것은 Client입니다. Host가 감독이라면, Client는 무전기를 들고 뛰어다니는 현장 진행 요원에 가깝습니다.

여기서 꼭 기억할 규칙이 하나 있습니다.

보통 하나의 Client는 하나의 Server와 연결됩니다.

반대로 말하면, 하나의 Host는 여러 Client를 만들 수 있습니다.

그래서 하나의 Host가 파일 시스템 서버, GitHub 서버, 데이터베이스 서버, 검색 서버에 동시에 연결할 수 있습니다. 이때 Host가 여러 Client를 거느리고, 각 Client가 각자의 Server와 전용 통로를 유지하는 모습이라고 생각하면 이해가 쉽습니다.

즉, Client는 눈에 잘 보이지 않지만 매우 중요합니다. 실제 연결이 끊기거나 초기 협상이 꼬이거나 메시지 형식이 맞지 않으면, 사용자는 "왜 이 도구 안 되지?"라고 느끼게 되는데 그 뒤에는 보통 Client 차원의 일이 숨어 있습니다.

한 문장으로 정리하면 이렇습니다.

Client는 Host 안에서 특정 Server와의 연결을 유지하며, MCP 대화를 실제로 수행하는 통신 담당입니다.

Server: 실제 기능을 꺼내 주는 공급자

Server는 MCP를 통해 기능을 제공하는 프로그램 또는 서비스입니다. 파일 읽기, GitHub 이슈 생성, 검색, 데이터베이스 조회 같은 실제 능력이 여기에 들어 있습니다.

여기서 "서버"라는 단어 때문에 괜히 거창하게 느껴질 수 있습니다. 마치 데이터센터 한복판에서 팬 돌아가는 큰 기계를 떠올리기 쉽죠. 하지만 MCP에서 Server는 꼭 그런 뜻이 아닙니다.

로컬에서 실행되는 작은 프로그램일 수도 있고, 클라우드에 떠 있는 웹 서비스일 수도 있습니다. 내 노트북에서 돌아가는 파일 시스템 MCP도 Server이고, 회사 클라우드에서 운영하는 사내 문서 검색 MCP도 Server입니다.

중요한 건 생김새보다 역할입니다. Server는 도구와 데이터와 템플릿을 표준 방식으로 내놓는 제공자입니다.

그리고 Server는 대개 스스로 똑똑한 척하지 않습니다. 즉, 보통 LLM 자체가 Server 안에 있는 것은 아닙니다. 대화의 전체 맥락을 붙잡고 사람과 자연스럽게 대화하는 쪽은 Host이고, Server는 주어진 요청에 맞는 기능을 수행하거나 자료를 건네주는 쪽입니다.

조금 냉정하게 말하면 Server는 "왜 이걸 하느냐"를 깊이 고민하기보다 "요청받은 기능을 정확히 수행하느냐"에 더 집중합니다. 그래서 오히려 역할 분리가 깔끔해집니다.

한 문장으로 정리하면 이렇습니다.

Server는 MCP를 통해 도구, 정보, 프롬프트를 제공하는 기능 공급자입니다.

셋의 관계를 식당 비유로 이해하면 쉽다

비유 하나를 들고 가면 오래 기억됩니다.

당신은 식당의 손님입니다. 원하는 메뉴를 말하고, 마지막에 나온 음식을 확인합니다.

당신이 주문하는 창구나 키오스크가 Host입니다. 사용자가 직접 마주하는 인터페이스이기 때문입니다.

그 주문을 주방이 이해하는 형식으로 전달하는 주문 시스템이 Client입니다. 눈에 잘 띄지는 않지만, 실제 전달을 맡습니다.

그리고 실제로 음식을 만드는 주방이 Server입니다. 손님과 직접 긴 대화를 나누지는 않지만, 진짜 일을 하는 쪽입니다.

이 비유가 좋은 이유는 역할이 섞이지 않기 때문입니다. 손님이 곧 Host는 아닙니다. 손님은 Host를 사용하는 사람입니다. Host는 주문을 받는 창구이고, Client는 그 주문을 전달하는 통신 담당이며, Server는 실제 기능을 수행하는 공급자입니다.

MCP도 비슷합니다. 사용자는 Host를 통해 요청하고, Client가 프로토콜 통역을 맡고, Server가 실제 작업이나 정보 제공을 담당합니다.

한 번에 보면 더 명확하다: 실제 흐름

이제 짧은 예시를 하나 보겠습니다.

사용자가 Cursor에서 이렇게 말합니다.

"현재 프로젝트의 package.json을 읽고, 사용 중인 주요 라이브러리를 요약해 줘."

먼저 Host인 Cursor가 요청을 받습니다. 그리고 "이건 파일 내용을 읽어야 하네"라고 판단합니다.

그다음 파일 시스템 MCP 서버와 연결된 Client가 움직입니다. Client는 서버에 적절한 요청을 보내고, package.json 내용이나 관련 리소스를 받아옵니다.

Server는 실제 파일 시스템에 접근해 필요한 내용을 전달합니다.

마지막으로 Host는 이 결과를 바탕으로 LLM이 이해하기 쉬운 컨텍스트를 만들고, 사용자에게 "이 프로젝트는 React, TypeScript, Vite를 주로 사용하고 있네요" 같은 식으로 정리해 보여 줍니다.

즉, 흐름은 보통 이렇게 생각하면 됩니다.

사용자가 Host에 말한다. Host가 필요한 Server를 고른다. Client가 그 Server와 대화한다. Server가 결과를 준다. Host가 다시 사람 말로 정리한다.

이 다섯 문장만 머릿속에 들어오면, MCP 구조의 절반은 이미 이해한 셈입니다.

이제 진짜 핵심: Server가 꺼내 놓는 세 가지 마법 도구

MCP Server는 아무거나 막 던지지 않습니다. 보통 기능을 세 가지 큰 범주로 나누어 보여 줍니다.

바로 Tools, Resources, Prompts입니다.

이 셋을 제대로 구분하지 못하면 MCP 문서가 계속 헷갈립니다. 반대로 이 셋만 명확해지면, 문서가 갑자기 한국어처럼 읽히기 시작합니다.

가장 쉬운 구분법은 이것입니다.

Tool은 무언가를 한다.

Resource는 무언가를 보여 준다.

Prompt는 무언가를 잘 시키는 틀을 준다.

이제 하나씩 봅시다.

Tool: 행동하는 손과 발

Tool은 실행 가능한 기능입니다. 즉, Server가 제공하는 "할 수 있는 일"입니다.

파일 읽기, 파일 쓰기, GitHub 이슈 만들기, 데이터베이스 질의, 웹 검색, 메시지 보내기 같은 것이 모두 Tool이 될 수 있습니다.

Tool의 핵심은 행동입니다. 그리고 그 행동은 때로 바깥세상에 흔적을 남깁니다. 파일이 바뀌고, 이슈가 생성되고, 이메일이 전송될 수 있습니다. 이런 것을 보통 부작용이라고 부르는데, 쉽게 말해 "실행하고 나면 세상이 조금 달라지는 일"입니다.

그래서 Tool은 강력하지만 조심해서 다뤄야 합니다. 읽기 전용 조회 도구보다, 삭제나 수정이 가능한 도구가 훨씬 민감한 이유가 여기 있습니다.

사용하는 사람 입장에서는 Tool을 이렇게 이해하면 됩니다.

"AI가 대신 버튼을 눌러 주는 기능"

만드는 사람 입장에서는 이렇게 보면 됩니다.

"LLM이 안전하게 호출할 수 있도록 이름, 설명, 입력 형식, 결과 형식을 잘 정의한 실행 함수"

예를 들어 create_github_issue 같은 Tool이 있다면, 이름만 있어서는 부족합니다. 어떤 저장소가 필요한지, 제목과 본문은 어떤 형식인지, 실패하면 무엇을 돌려주는지까지 분명해야 합니다. Tool은 힘이 센 대신, 설명서가 흐리면 사고도 크게 납니다.

Resource: 읽고 참고하는 지식 창고

Resource는 읽기용 정보입니다. Tool처럼 뭔가를 실행하기보다, AI가 참고할 수 있는 자료를 제공합니다.

파일 내용, 설정 파일, 로그, 문서, 데이터베이스 스키마, API 응답 스냅샷 같은 것이 Resource가 될 수 있습니다.

여기서 중요한 포인트는 읽기 중심이라는 점입니다. Resource는 대체로 "이걸 참고해"에 가깝고, "이걸 실행해"는 아닙니다.

그래서 Resource는 AI가 상황을 이해하는 데 아주 유용합니다. 예를 들어 데이터베이스 질의를 수행하는 Tool이 있더라도, 그 전에 테이블 구조를 알려 주는 Resource가 함께 있으면 AI는 훨씬 덜 헤맵니다.

쉽게 비유하면 Tool이 손이라면, Resource는 메모장이나 안내판입니다.

사용하는 사람 입장에서는 Resource를 이렇게 이해하면 좋습니다.

"AI에게 그냥 설명만 하지 말고, 실제 자료를 읽혀 주는 방법"

만드는 사람 입장에서는 이렇게 볼 수 있습니다.

"내 시스템의 중요한 읽기 전용 맥락을 안전하게 드러내는 창구"

예를 들어 사내 문서 서버를 만든다면, docs://handbook/onboarding 같은 Resource를 통해 온보딩 문서를 읽게 할 수 있습니다. 혹은 db://schema/users 같은 Resource로 스키마 설명을 제공할 수도 있습니다.

Tool 없이도 Resource만으로 꽤 똑똑한 경험을 만들 수 있습니다. AI가 '아는 척'이 아니라 '읽고 말하기'를 하게 되기 때문입니다.

Prompt: 잘 부탁하는 공식 템플릿

Prompt는 재사용 가능한 지시문 템플릿입니다. 쉽게 말해 "이 작업은 이런 식으로 시키면 잘 된다"를 미리 정리해 둔 틀입니다.

예를 들어 코드 리뷰, 회의록 요약, 버그 리포트 작성, 커밋 메시지 생성 같은 작업은 매번 비슷한 구조를 가집니다. 그럴 때 Prompt를 쓰면 사용자는 빈손으로 AI를 설득할 필요가 없습니다.

"이 코드를 리뷰해 줘"보다, "성능, 가독성, 잠재 버그, 테스트 필요성을 기준으로 리뷰해 줘"가 더 좋고, 그것이 아예 템플릿으로 준비되어 있으면 훨씬 일관된 결과가 나옵니다.

Prompt의 중요한 특징은 보통 사용자나 애플리케이션이 명시적으로 선택해서 쓴다는 점입니다. Tool이 모델의 행동과 더 가깝고, Resource가 참고 자료와 더 가깝다면, Prompt는 "일을 시키는 방식의 정답지"에 가깝습니다.

사용하는 사람 입장에서는 Prompt를 이렇게 생각하면 됩니다.

"자주 쓰는 요청을 버튼 하나나 슬래시 명령처럼 꺼내 쓰는 것"

만드는 사람 입장에서는 이렇게 보면 좋습니다.

"좋은 질문법과 좋은 작업 흐름을 템플릿으로 제품 안에 심는 것"

특히 Prompt는 초보자에게 큰 도움이 됩니다. 무엇을 어떻게 요청해야 할지 몰라도, 잘 설계된 Prompt 하나면 꽤 훌륭한 결과를 얻을 수 있기 때문입니다.

Tool, Resource, Prompt를 헷갈리지 않는 가장 쉬운 기준

이 셋은 자주 비슷해 보이지만, 판단 기준은 의외로 단순합니다.

어떤 기능이 실행되고 결과로 세상이 바뀔 수 있다면 Tool입니다.

어떤 기능이 읽기만 가능한 정보 제공이라면 Resource입니다.

어떤 기능이 LLM에게 일을 잘 시키기 위한 템플릿이라면 Prompt입니다.

예를 들어 보겠습니다.

send_email은 Tool입니다. 실제 메일이 나가니까요.

file://report.md의 내용 읽기는 Resource입니다. 정보를 주는 것이니까요.

bug-report 템플릿은 Prompt입니다. 버그 리포트를 잘 쓰게 도와주는 틀이니까요.

여기서 감이 안 오면, 스스로 이렇게 물어보면 됩니다.

"이건 버튼인가, 문서인가, 양식인가?"

버튼이면 Tool, 문서면 Resource, 양식이면 Prompt인 경우가 많습니다.

같은 서버 안에 셋이 함께 있는 이유

실전에서는 하나의 MCP 서버가 Tool만 제공하지 않는 경우가 많습니다. 오히려 셋을 함께 제공할 때 더 강력해집니다.

예를 들어 데이터베이스 서버를 생각해 봅시다.

이 서버는 SQL 질의를 실행하는 Tool을 제공할 수 있습니다. 동시에 테이블 구조를 보여 주는 Resource도 제공할 수 있습니다. 그리고 "안전한 분석 쿼리를 생성하는 프롬프트" 같은 Prompt까지 제공할 수도 있습니다.

이 조합이 왜 좋을까요?

AI는 먼저 Resource로 구조를 이해하고, Prompt로 적절한 작업 형식을 잡고, Tool로 실제 질의를 실행할 수 있기 때문입니다.

즉, Tool만 있으면 힘은 센데 눈이 어두울 수 있습니다. Resource만 있으면 똑똑한데 손이 없습니다. Prompt만 있으면 말은 예쁘게 하는데 실제 행동이 약합니다.

셋이 함께 있을 때 비로소 "읽고, 생각하고, 행동하는" 흐름이 자연스러워집니다.

사용하는 사람의 관점: 무엇을 알면 충분한가

MCP를 쓰는 입장에서 가장 중요한 것은 프로토콜 내부보다 역할 감각입니다.

사용자는 보통 이렇게 이해하면 충분합니다.

Host는 내가 쓰는 앱입니다. Client는 그 앱 안에서 서버와 대화하는 연결 담당입니다. Server는 실제 기능을 제공하는 바깥쪽 도우미입니다.

그리고 서버가 보여 주는 기능은 세 갈래입니다. Tool은 실행, Resource는 참고자료, Prompt는 잘 쓰기 위한 템플릿입니다.

이렇게만 이해해도, 앞으로 어떤 MCP 서버를 연결할 때 "이건 무엇을 제공하는 서버인지"를 빠르게 판단할 수 있습니다. 예를 들어 파일 서버라면 Resource와 Tool이 많겠구나, 문서 요약 서버라면 Prompt가 강하겠구나, GitHub 서버라면 생성·수정 Tool이 중요하겠구나 하고 감이 옵니다.

그러면 사용자 입장에서도 질문이 더 좋아집니다.

"이 서버는 읽기만 하나요, 수정도 하나요?"

"이건 도구인가요, 리소스인가요?"

"반복 작업용 프롬프트도 있나요?"

이런 질문을 할 수 있게 되면 MCP를 그냥 '신기한 기능'이 아니라 '설계된 시스템'으로 보게 됩니다.

만드는 사람의 관점: 무엇을 어떻게 나눠야 하는가

MCP 서버를 만드는 입장에서는 이 구분이 더 중요합니다. 같은 기능처럼 보여도 Tool로 낼지, Resource로 낼지, Prompt로 낼지에 따라 사용 경험이 크게 달라지기 때문입니다.

예를 들어 "프로젝트 상태를 보여 준다"는 요구가 있다고 해 봅시다.

만약 현재 상태를 읽어 오기만 하면 된다면 Resource가 더 어울립니다. 반면 "배포를 시작한다"처럼 실제 행동이 필요하면 Tool이 맞습니다. 또 "배포 전 점검 체크리스트를 따라 리뷰해 달라"면 Prompt가 더 자연스럽습니다.

즉, 만드는 사람은 기능을 구현하기 전에 먼저 질문해야 합니다.

"이건 실행 기능인가?"

"이건 읽기 전용 맥락인가?"

"이건 작업을 잘 유도하는 템플릿인가?"

이 분류가 깔끔해야 Host도 이해하기 쉽고, LLM도 덜 헷갈리고, 사용자도 더 안전하게 사용할 수 있습니다.

좋은 MCP 서버는 기능이 많은 서버가 아니라, 역할 구분이 선명한 서버인 경우가 많습니다.

자주 헷갈리는 오해 몇 가지

처음 배우는 사람들이 자주 헷갈리는 지점도 미리 정리해 두겠습니다.

첫째, Host와 Client는 종종 같은 프로그램 안에 있지만 같은 역할은 아닙니다. Host는 판단과 관리, Client는 연결과 통신입니다.

둘째, Server는 꼭 원격 클라우드 서비스일 필요가 없습니다. 내 컴퓨터에서 실행되는 작은 로컬 프로그램도 MCP Server가 될 수 있습니다.

셋째, Tool이 있다고 해서 무조건 좋은 것은 아닙니다. 강력한 Tool일수록 권한과 승인 설계가 더 중요합니다.

넷째, Resource는 단순한 데이터 덩어리라기보다, 데이터를 안전하고 구조적으로 보여 주는 창구에 가깝습니다.

다섯째, Prompt는 "그냥 프롬프트 하나 더 적는 것"이 아닙니다. 반복 작업의 품질을 안정시키는 제품 기능이 될 수 있습니다.

이 다섯 가지만 피하면, MCP 구조를 훨씬 덜 삐끗하고 이해하게 됩니다.

이 장의 핵심을 한 번에 묶어 보자

이제 한 문단으로 정리해 보겠습니다.

MCP에서 Host는 사용자가 만나는 앱이고, Client는 그 앱 안에서 특정 Server와 통신하는 연결 담당이며, Server는 실제 기능과 정보를 제공하는 공급자입니다. 그리고 Server는 보통 Tools, Resources, Prompts라는 세 가지 형태로 능력을 드러냅니다. Tool은 행동, Resource는 정보, Prompt는 요청 템플릿입니다.

이 구조가 머릿속에 들어오면, 앞으로 MCP 문서에서 나오는 많은 표현이 평범하게 읽힙니다.

"Host가 여러 서버를 연결한다"는 말은, 하나의 AI 앱이 여러 기능 공급자를 묶는다는 뜻입니다.

"Client가 서버와 세션을 유지한다"는 말은, 중간 연결 담당이 전용 통로를 유지한다는 뜻입니다.

"Server가 tools/resources/prompts를 노출한다"는 말은, 그 서버가 버튼과 문서와 양식을 꺼내 보여 준다는 뜻입니다.

갑자기 문서가 사람 말 같아지지 않나요?

다음 장에서 보게 될 것

이번 장에서는 등장인물 소개에 집중했습니다. 누가 누구인지, 무엇이 무엇인지부터 분명히 했습니다.

다음 장에서는 이제 이 등장인물들이 어떻게 대화하는지를 봅니다. JSON-RPC는 무엇인지, 세션은 왜 필요한지, stdio와 HTTP 같은 전송 방식은 어떻게 다른지 살펴보게 됩니다.

이번 장에서 사람을 익혔다면, 다음 장에서는 대화법을 배우는 셈입니다. 무대 위 배우 소개가 끝났으니, 이제 대본을 볼 차례입니다.