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