MCP 클라이언트는 서버와 MCP 서버 간의 통신 브리지 역할을 합니다. MCP 서버가 제공하는 모든 도구에 대한 접근점이라고 생각하면 됩니다. 외부 기능을 사용해야 할 때, 클라이언트가 모든 메시지 전달과 프로토콜 세부 사항을 대신 처리해 줍니다.
전송 방식에 구애받지 않는 통신
MCP의 핵심 강점 중 하나는 전송 방식에 구애받지 않는다는 점입니다 - 클라이언트와 서버가 서로 다른 통신 방법을 사용하여 대화할 수 있다는 멋진 표현입니다. 가장 일반적인 설정은 MCP 클라이언트와 서버를 동일한 머신에서 실행하며, 표준 입출력을 통해 통신하는 방식입니다.
하지만 이 방식에만 제한되지는 않습니다. MCP 클라이언트와 서버는 다음을 통해서도 연결할 수 있습니다:
- HTTP
- WebSockets
- 기타 다양한 네트워크 프로토콜
메시지 유형
연결이 이루어지면, 클라이언트와 서버는 MCP 명세에 정의된 특정 메시지 유형을 교환합니다. 주로 다루게 될 메시지 유형은 다음과 같습니다:
ListToolsRequest/ListToolsResult: 클라이언트가 서버에게 "어떤 도구를 제공하나요?"라고 물으면, 사용 가능한 전체 기능 목록을 받습니다.
CallToolRequest/CallToolResult: 클라이언트가 서버에게 "이 인자들로 이 특정 도구를 실행하세요"라고 지시하면, 실행 결과를 받습니다.
실제 예시 흐름
이 모든 요소들이 어떻게 함께 작동하는지 살펴보기 위해 전체 예시를 따라가 보겠습니다. 사용자가 "내가 가진 저장소는 무엇인가요?"라고 묻는 상황을 상상해 보세요 - 전체 통신 체인은 다음과 같습니다:
이 과정은 사용자가 질문을 서버에 제출할 때 시작됩니다. 서버는 AI 요청을 하기 전에 Claude에게 사용 가능한 도구를 제공해야 한다는 것을 인식합니다.
서버는 MCP 클라이언트에게 도구 목록을 요청하며, 이는 MCP 서버로의 ListToolsRequest를 트리거합니다. 서버는 사용 가능한 모든 도구를 포함한 ListToolsResult로 응답합니다.
이제 서버는 초기 Claude 요청을 하는 데 필요한 모든 것을 갖추었습니다: 사용자의 질문과 사용 가능한 도구입니다. Claude는 도구를 분석하고 질문에 제대로 답하기 위해 도구를 호출해야 한다고 판단합니다.
Claude는 도구 사용 요청으로 응답합니다. 서버는 이를 인식하고 MCP 클라이언트에게 Claude가 지정한 인자로 도구를 실행하도록 요청합니다.
MCP 클라이언트는 MCP 서버에 CallToolRequest를 전송하며, 서버는 사용자의 저장소를 가져오기 위해 GitHub에 실제 API 호출을 합니다.
GitHub는 저장소 데이터를 반환하며, MCP 서버는 이를 CallToolResult로 감싸서 체인을 통해 다시 전송합니다. 서버는 이 데이터를 받아 이제 Claude에게 후속 요청을 할 수 있습니다.
마지막 단계에서는 도구 결과를 사용자 메시지의 일부로 Claude에게 전송합니다. 이제 Claude는 사용자의 저장소에 대한 완전한 응답을 작성하는 데 필요한 모든 정보를 갖추게 됩니다.
네, 이 흐름에는 많은 단계가 포함되어 있지만, 이를 이해하면 자신만의 MCP 클라이언트와 서버를 구현할 준비가 됩니다. 각 구성 요소는 특정한 역할을 가지고 있으며, 표준화된 메시지 유형은 기본 전송 메커니즘과 무관하게 모든 것이 원활하게 작동하도록 보장합니다.