AI 서비스가 ‘MCP를 지원한다’고 발표하면 이제 외부 자료를 읽고 업무까지 처리한다는 뜻일까. MCP 지원만으로 알 수 있는 범위는 그보다 좁다. 어떤 애플리케이션이 연결을 맡고, 연결된 서버가 어떤 기능을 제공하는지 함께 봐야 실제 의미가 드러난다. MCP(Model Context Protocol)는 대규모 언어 모델인 LLM을 사용하는 애플리케이션과 외부 데이터·도구를 연결하는 공개 프로토콜이다. 프로토콜은 구성 요소들이 통신할 때 따르는 공통 규칙이다. MCP를 이해하는 핵심은 ‘누가 연결하는가’와 ‘무엇을 제공하는가’를 나누는 데 있다. 이 글은 2025-06-18 명세에 담긴 기본 구조를 기준으로 설명한다.
연결을 맡는 세 가지 역할
MCP의 연결 구조에는 호스트, 클라이언트, 서버가 등장한다. 호스트는 연결을 시작하는 LLM 애플리케이션이고, 클라이언트는 그 호스트 내부에서 연결을 맡는 구성 요소다. 서버는 연결 상대에게 맥락과 기능을 제공하는 서비스다. 여기서 맥락은 사용자나 모델이 작업을 이해하는 데 활용할 정보라고 생각하면 된다. 개념 설명을 위해 회사 문서를 참고하는 가상의 AI 업무 앱을 떠올려 보자. 사용자가 여는 업무 앱이 호스트이고, 앱 안에서 MCP 연결을 맡는 부분이 클라이언트다. 문서 관련 정보나 기능을 제공하는 서비스는 서버에 해당한다. 이는 역할을 설명하기 위한 가상 장면이며 특정 제품의 실제 동작을 뜻하지 않는다. 따라서 클라이언트와 호스트를 서로 무관한 두 앱으로 이해하면 구조가 헷갈린다. 클라이언트는 호스트 안의 연결 구성 요소라는 관계가 중요하다. 또 서버라는 단어는 여기서 맥락과 기능을 제공하는 역할을 가리킨다. 이 구분을 잡으면 발표 속 제품이 사용자가 쓰는 앱인지, 그 앱이 연결할 서비스인지부터 읽을 수 있다.
공통 메시지 규칙의 의미
서로 다른 구성 요소가 통신하려면 주고받는 메시지에 공통 규칙이 필요하다. 해당 MCP 명세는 구성 요소 사이의 통신에 JSON-RPC 2.0 메시지를 사용한다고 설명한다. 비개발자라면 이를 연결 양쪽이 메시지를 주고받기 위해 사용하는 정해진 형식과 규칙으로 이해하면 충분하다. 여기서 구분할 것은 통신 규칙과 제공 기능이다. 공통 규칙을 따른다는 설명은 메시지를 어떤 방식으로 구성하는지에 관한 것이다. 그 연결에서 회사 문서를 제공할지, 정형화된 작업 지침을 제공할지, 실행할 함수를 제공할지는 별도의 문제다. 이 때문에 MCP를 지원한다는 한 문장을 곧바로 특정 업무의 완성으로 해석하기는 어렵다. 업무 앱에 연결 기능이 있다는 설명과 상대 서비스에 필요한 기능이 있다는 설명이 함께 있어야 한다. 공통 연결 규칙을 갖췄다는 사실에서 실제 업무 범위를 읽으려면 서버가 제공하는 내용을 한 단계 더 살펴야 한다.
데이터·프롬프트·도구의 차이
서버가 제공할 수 있는 기능은 Resources, Prompts, Tools로 구분된다. Resources는 사용자나 AI 모델이 활용할 맥락과 데이터다. 앞의 가상 업무 앱에서 문서 내용을 참고 정보로 제공한다고 가정하면 Resources의 역할을 이해하기 쉽다. 중심은 작업에 사용할 정보 자체다. Prompts는 사용자를 위한 정형 메시지와 작업 흐름이다. 같은 가상 장면에서 문서를 검토할 때 사용할 질문 틀이나 정해진 검토 흐름을 제공한다고 생각해 보자. 참고할 문서 내용을 건네는 것과 그 내용을 다룰 메시지 틀을 건네는 것은 서로 다른 기능이다. 이 예시는 개념 비교를 위한 것이며 명세가 특정 검토 양식을 정한다는 뜻은 아니다. Tools는 AI 모델이 실행할 함수다. 가령 가상의 서버가 문서를 찾는 검색 함수를 제공한다면, 그 함수는 실행할 기능이라는 점에서 Tools로 설명할 수 있다. 검색 결과가 정보라고 해서 검색 함수까지 Resources와 같은 개념이 되는 것은 아니다. 비교 대상이 제공된 데이터인지, 실행할 함수인지가 차이를 만든다. 이 세 기능은 데이터 제공에서 프롬프트 제공을 거쳐 도구 실행으로 넘어가는 필수 순서가 아니다. 명세는 서버가 이들 기능 중 어떤 것이든 제공할 수 있다고 설명한다. 따라서 Resources 제공만 명시된 서버를 보고 Prompts와 Tools도 모두 갖췄다고 확대해서 읽으면 실제 제공 범위를 놓치게 된다.
MCP 지원 발표를 읽는 기준
AI 기술동향에서 MCP 지원 소식을 읽을 때는 먼저 발표의 주어를 보자. 사용자용 AI 앱이 외부 서비스를 연결한다는 발표인지, 외부 서비스가 AI 앱에 맥락과 기능을 제공한다는 발표인지 구분한다. 전자는 연결을 시작하는 쪽, 후자는 제공하는 쪽의 설명에 가깝다. 같은 ‘지원’이라는 표현도 가리키는 역할이 다를 수 있다. 그다음에는 제공 대상을 구체적인 기능으로 바꿔 읽는다. 자료를 맥락으로 제공한다면 Resources, 정형 메시지나 작업 흐름을 제공한다면 Prompts, 실행할 함수를 제공한다면 Tools에 해당하는 설명인지 살핀다. 기능의 이름만 보는 것보다 무엇을 제공한다고 적었는지를 보면 독자에게 필요한 차이가 드러난다. 예를 들어 문서 내용을 참고하는 것이 목적이라면 어떤 정보가 제공되는지가 먼저다. 특정 작업을 함수로 실행하려는 목적이라면 그 함수가 제공되는지가 중요하다. 둘 다 외부 연결을 활용하지만 필요한 기능은 같지 않다. 따라서 두 제품의 발표를 비교할 때도 MCP 지원 여부 하나보다 연결 역할과 필요한 기능을 나란히 놓는 편이 유용하다.
연결 범위와 권한을 함께 보기
MCP 연결은 데이터 접근과 코드 실행으로 이어질 수 있으므로 보안과 신뢰 문제도 함께 따라온다. 명세 역시 이를 별도의 고려사항으로 다룬다. MCP 지원이라는 표현 자체를 안전성 보증으로 읽어서는 안 되는 이유다. 공통 통신 규칙을 쓴다는 사실만으로 실제 서비스의 데이터 처리나 실행 범위까지 설명되지는 않는다. 특히 Tools가 있다는 사실과 어떤 작업을 어디까지 허용하는지는 구분해야 한다. 함수의 이름과 용도는 제공 기능을 이해하는 단서지만, 실제 접근 대상이나 권한, 실행 승인 조건은 해당 구현의 구체적인 설명이 필요하다. 여기서 설명한 기본 구조만으로 모든 제품이 같은 승인 방식이나 인증 규칙을 쓴다고 볼 수는 없다. 도입을 검토한다면 필요한 작업을 먼저 한 문장으로 적어 보자. ‘문서를 참고하고 싶다’와 ‘문서 관련 함수를 실행하고 싶다’는 서로 다른 요구다. 그 요구에 맞춰 연결할 앱과 서버, 제공되는 정보 또는 함수, 접근·실행이 허용되는 범위를 대응시키면 된다. 발표에 빠진 것이 실행 권한이라면 권한 설명을, 필요한 함수라면 함수 제공 여부를 구체적으로 물어야 한다. 그것이 MCP 지원 소식을 실제 선택으로 바꾸는 다음 단계다.
참고자료
참고 1: Model Context Protocol · Specification (2025-06-18) https://modelcontextprotocol.io/specification/2025-06-18