Sign in to save your progressYou can keep reading without an account, but completed lessons won't be saved.
Sign in

MCP 클라이언트는 서버와 MCP 서버 간의 통신 브리지 역할을 합니다. MCP 서버가 제공하는 모든 도구에 대한 접근 지점으로서, 메시지 교환과 프로토콜 세부 사항을 처리하여 애플리케이션이 이를 직접 처리할 필요가 없도록 합니다.

전송 방식에 구애받지 않는 통신

MCP의 핵심 강점 중 하나는 전송 방식에 구애받지 않는다는 점입니다 - 이는 클라이언트와 서버가 설정에 따라 다양한 프로토콜을 통해 통신할 수 있다는 것을 멋지게 표현한 말입니다.

가장 일반적인 설정은 MCP 클라이언트와 서버를 동일한 머신에서 실행하여 표준 입출력을 통해 통신하는 것입니다. 하지만 다음을 통해서도 연결할 수 있습니다:

  • HTTP
  • WebSockets
  • 기타 다양한 네트워크 프로토콜

MCP 메시지 유형

연결이 이루어지면, 클라이언트와 서버는 MCP 명세에 정의된 특정 메시지 유형을 교환합니다. 주로 다루게 될 메시지 유형은 다음과 같습니다:

ListToolsRequest/ListToolsResult: 클라이언트가 서버에 "어떤 도구를 제공하나요?"라고 묻고 사용 가능한 도구 목록을 받습니다.

CallToolRequest/CallToolResult: 클라이언트가 서버에 주어진 인자로 특정 도구를 실행하도록 요청한 다음 결과를 받습니다.

전체 작동 방식

다음은 사용자 쿼리가 전체 시스템을 통해 어떻게 흐르는지 보여주는 완전한 예시입니다 - 서버에서 MCP 클라이언트를 거쳐 GitHub와 같은 외부 서비스로, 그리고 다시 Claude로 돌아오는 흐름입니다.

사용자가 "내가 가진 저장소는 무엇인가요?"라고 묻는다고 가정해 보겠습니다. 단계별 흐름은 다음과 같습니다:

  1. 사용자 쿼리: 사용자가 서버에 질문을 제출합니다
  2. 도구 탐색: 서버는 Claude에 전달할 수 있는 도구가 무엇인지 알아야 합니다
  3. 도구 목록 교환: 서버가 MCP 클라이언트에 사용 가능한 도구를 요청합니다
  4. MCP 통신: MCP 클라이언트가 MCP 서버에 ListToolsRequest를 전송하고 ListToolsResult를 받습니다
  5. Claude 요청: 서버가 사용자의 쿼리와 사용 가능한 도구를 Claude에 전송합니다
  6. 도구 사용 결정: Claude가 질문에 답하기 위해 도구를 호출해야 한다고 판단합니다
  7. 도구 실행 요청: 서버가 MCP 클라이언트에 Claude가 지정한 도구를 실행하도록 요청합니다
  8. 외부 API 호출: MCP 클라이언트가 MCP 서버에 CallToolRequest를 전송하고, 서버는 실제 GitHub API 호출을 수행합니다
  9. 결과 반환: GitHub가 저장소 데이터로 응답하고, 이는 MCP 서버를 통해 CallToolResult로 다시 흘러갑니다
  10. Claude로 도구 결과 전달: 서버가 도구 결과를 다시 Claude에 전송합니다
  11. 최종 응답: Claude가 저장소 데이터를 사용하여 최종 답변을 작성합니다
  12. 사용자에게 답변 전달: 서버가 Claude의 응답을 사용자에게 전달합니다

네, 이 흐름에는 많은 단계가 포함되어 있지만, 각 구성 요소는 명확한 역할을 담당합니다. MCP 클라이언트는 서버 통신의 복잡성을 추상화하여, 강력한 외부 도구와 데이터 소스에 접근하면서도 애플리케이션 로직에 집중할 수 있게 해줍니다.

이 흐름을 이해하는 것은 매우 중요합니다. 다음 섹션에서 자신만의 MCP 클라이언트와 서버를 구축할 때 이러한 모든 요소를 다시 보게 될 것이기 때문입니다.