MCP(모델 컨텍스트 프로토콜) 구조 정리: 도구·리소스·프롬프트와 서버 클라이언트 동작 방식

핵심 메시지

• MCP(모델 컨텍스트 프로토콜)는 앤트로픽이 2024년 11월에 공개한 오픈소스 표준으로, 언어모델 애플리케이션이 새 데이터 소스를 붙일 때마다 맞춤 구현을 반복하던 문제를 표준화로 해결한다.
• 구조는 호스트(사용자가 보는 앱), 클라이언트(서버와의 연결·메시지 전달 담당), 서버(기능 제공) 세 축으로 나뉘며, 각 부분을 독립적으로 개발해도 서로 맞물린다.
• 서버가 노출하는 것은 크게 도구(tools), 리소스(resources), 프롬프트(prompts) 세 가지다. 도구는 모델이 호출하는 함수, 리소스는 앱이 제어하는 데이터, 프롬프트는 사용자가 부르는 템플릿이다.
• 도구는 목록 조회와 실행이 모두 서버 쪽에서 처리된다. 클라이언트는 서버가 준 도구 명세를 자기 모델 API 형식으로 변환만 하면 되므로, 통합할 때마다 도구를 일일이 작성할 필요가 없다.
• 리소스와 프롬프트는 도구와 달리 반드시 모델이 주도하지 않는다. 사용자가 슬래시 명령으로 부르거나 앱이 먼저 목록을 보여 주고 고르게 하는 등, 처리 방식은 클라이언트 개발자에게 열려 있다.

쉽게 이해하기

MCP가 나온 배경은 단순하다. 언어모델 기반 애플리케이션을 만들다 보면 새로운 데이터 소스를 붙일 때마다 그때그때 맞춤 코드를 쓰게 된다는 것이다. 강연자는 앤트로픽이 이 반복을 없애려고, 언어모델이 실행 중에 데이터 소스와 도구와 시스템을 어떻게 만날지를 하나의 개방형 표준으로 정리했다고 설명한다. 데이터를 가진 쪽이 MCP 서버를 만들어 노출하면, MCP를 지원하는 어떤 앱이든 그 서버에 붙을 수 있다.

가장 알기 쉬운 예는 클로드 데스크톱 앱에 웹 서핑 기능을 가진 MCP 서버를 물리는 경우다. 원래 클로드는 웹을 직접 검색하거나 웹 문서를 불러올 수 없었지만, 서버를 연결하는 순간 어떤 도구가 있는지 알고 실제로 쓸 수 있게 된다. 구성 요소로 보면 사용자가 보는 앱과 화면이 호스트, 뒤에서 웹 서핑 서버에 붙는 쪽이 클라이언트이며, 클라이언트-서버 구조에 익숙하다면 낯설지 않지만 언어모델 앱만 다뤄 온 사람에게는 이 분리 자체가 새로운 지점이다. 이렇게 나눠 두면 각 구성 요소를 독립적으로 개발하면서도 서로 맞물리는 모듈식 시스템이 된다.

서버가 맡는 일은 세 가지다. 도구는 모델이 호출해 무언가를 수행하거나 정보를 가져오는 함수이고, 리소스는 클라이언트가 접근하거나 모델의 컨텍스트로 넣어 줄 수 있는 데이터이며, 프롬프트는 서버를 만든 쪽이 미리 정의해 둔 재사용 가능한 템플릿이다. 도구 호출이나 PDF 전달 자체는 새로운 개념이 아니지만, 강연자는 이것들이 클라이언트와 서버 사이에서 표준화된 형태로 오간다는 점이 MCP의 힘이라고 짚는다.

예제는 문서 검색 서버다. 크로마DB 벡터 데이터베이스에 115쪽짜리 LLM 파인튜닝 가이드를 넣어 약 555개 청크로 쪼개 두고, 벡터 검색을 수행하는 도구와 컬렉션 정보를 조회하는 도구 두 개를 서버에 붙인다. 도구 목록은 서버의 데코레이터가 달린 함수가 돌려주고, 클라이언트는 그 목록을 받아 자신이 쓰는 모델 API 명세로 바꾸기만 한다. 실행도 마찬가지여서, 클라이언트는 모델이 뱉은 도구 이름과 인자를 그대로 서버에 넘기고 서버가 유사도 검색을 돌린 뒤 텍스트 결과를 돌려준다. 클라이언트는 그 결과를 대화에 덧붙여 다시 모델에 넣을 뿐이다.

리소스와 프롬프트는 결이 조금 다르다. 강연자는 도구가 명백히 모델을 위한 기능인 반면, 리소스는 앱이 제어하며 사용자에게 먼저 보여 주고 고르게 할 수 있는 데이터이고 프롬프트는 사용자가 슬래시 명령 같은 UI로 직접 부르는 템플릿이라고 구분한다. 예제에서는 테스트 폴더의 PDF들을 리소스로 목록화해 두고, 사용자가 명령으로 버트(BERT) 논문을 고르면 서버가 본문을 읽어 클라이언트로 넘기고 클라이언트가 이를 대화 기록에 넣는다. 그 뒤 논문 저자를 물으면 모델이 넘겨받은 본문을 근거로 답한다. 프롬프트에서는 역할이 한 번 더 갈려서, 목록과 내용을 돌려주는 일은 서버가 맡고 실제 실행은 클라이언트가 맡는다. 강연자는 전송 방식 같은 세부는 공식 문서를 보라고 안내하며, 이 영상은 MCP가 무엇에 쓸모가 있고 양쪽 동작이 어떻게 맞물리는지를 잡는 기초편이라고 정리한다.

주요 인사이트

• MCP가 바꾸는 것은 모델의 능력이 아니라 통합 비용이다. 데이터 소스마다 새로 짜던 코드를 한 번 정한 규약으로 대체하면, 서버와 앱을 만드는 사람이 서로를 몰라도 붙는다.
• 도구 실행을 서버 쪽에 둔 설계는 통제권 문제이기도 하다. 어떤 상호작용이 허용되고 어떤 데이터가 앱까지 올라가는지를 서버를 만든 쪽이 엄격하게 정할 수 있다.
• 도구·리소스·프롬프트의 구분은 결국 '누가 주도하는가'의 구분이다. 도구는 모델, 리소스는 애플리케이션, 프롬프트는 사용자가 방아쇠를 당긴다.
• 클라이언트가 하는 일이 명세 변환 수준으로 얇아진다는 점이 실무에서 체감되는 이득이다. 서버 하나를 만들어 두면 여러 앱에서 재사용된다.
• 이미 파일 접근과 검색, 데이터베이스 연동, 메모리 구현 같은 공식·커뮤니티 서버 목록이 쌓여 있어, 직접 만들기 전에 무엇이 가능한지 훑어보는 편이 빠르다.

자주 묻는 질문

관련 AI 소식