MCP의 호스트·클라이언트·서버 구분하기

도구마다 다른 연결 코드를 줄이기

AI 애플리케이션 하나가 파일, 데이터베이스, 이슈 추적기와 사내 API를 사용한다고 생각해 봅시다. 각 서비스마다 연결, 기능 목록, 인자 형식과 오류 처리를 별도로 구현하면 애플리케이션과 서비스 수가 늘수록 접착 코드도 반복됩니다. 다른 AI 클라이언트로 옮길 때 같은 연동을 다시 만들어야 하고, 어느 계층에서 권한을 통제하는지도 흐려집니다.

Model Context Protocol(MCP)은 AI 애플리케이션이 외부 기능을 발견하고 사용하는 공통 메시지 규약을 제공합니다. 서버는 실행 가능한 도구, 읽을 수 있는 리소스와 재사용할 프롬프트를 정해진 형식으로 공개하고, 클라이언트는 목록을 조회하거나 선택한 기능을 호출합니다. MCP는 특정 모델이나 에이전트 프레임워크가 아니라 서로 다른 프로그램 사이의 연결 계약입니다.

그림: 호스트는 각 서버 연결마다 클라이언트를 만들고 서버 기능을 애플리케이션에 노출합니다.

MCP 호스트는 사용자 경험과 모델 호출, 승인 및 권한 정책을 관리하는 애플리케이션입니다. 호스트 안의 MCP 클라이언트는 보통 특정 서버 하나와 연결을 유지하고 프로토콜 메시지를 주고받습니다. MCP 서버는 자체 데이터나 외부 시스템을 감싸 도구, 리소스 또는 프롬프트를 공개합니다. 서버가 기능을 제공한다고 해서 모델이 모든 기능을 자동으로 실행할 권한을 얻는 것은 아닙니다.

예를 들어 데스크톱 호스트가 로컬 파일 서버와 이슈 관리 서버에 연결한다면 서버마다 별도의 클라이언트 연결이 생깁니다. 모델이 “문서를 읽고 이슈를 만들어야 한다”고 제안해도 호스트는 파일 접근 범위와 이슈 생성 권한을 각각 검사합니다. 프로토콜이 연결 방식을 표준화해도 신뢰 경계는 사라지지 않습니다.

메시지 흐름 읽기

연결이 시작되면 양쪽이 프로토콜 버전과 지원 기능을 협상하고 초기화합니다. 이후 클라이언트는 도구·리소스·프롬프트 목록을 조회하고 필요한 항목을 호출하거나 읽습니다. 이 초기화 과정 덕분에 호스트는 서버가 무엇을 제공하는지 미리 알 수 있지만, 목록의 설명만 믿고 실행 권한까지 넘겨서는 안 됩니다.

같은 컴퓨터의 자식 프로세스는 표준 입출력 전송을 사용할 수 있고, 원격 서버는 Streamable HTTP 같은 공식 전송 방식을 사용할 수 있습니다. 전송은 메시지가 오가는 통로이고 도구 스키마는 그 안의 내용이므로 둘을 구분합니다. 원격 연결에는 인증, 암호화와 서버 신원 확인이 추가로 필요합니다. 어떤 전송을 쓰든 애플리케이션은 반환 결과의 스키마와 출처를 확인합니다.

서버 설정에는 명령, 주소와 인증 정보가 포함될 수 있습니다. 비밀값을 공개 저장소에 넣지 않고 서버별 최소 권한을 부여합니다. 파일 시스템 서버라면 허용 디렉터리를 제한하고, 쓰기 도구는 별도 승인 흐름과 결합합니다.

서버도 신뢰할 수 없는 입력을 받을 수 있다는 점을 고려합니다. 도구 인자 검증, 호출 속도 제한과 오류 정리는 서버 책임이고, 어떤 서버와 기능을 사용자에게 노출할지는 호스트 책임입니다. 연결을 해제할 때 프로세스와 세션을 정리하고, 서버 기능 목록이 바뀌었을 때 다시 승인할 범위도 정책으로 정합니다.

MCP와 도구 호출의 관계

MCP는 기능을 발견하고 호출하는 연결 규약이며, 어느 도구를 언제 쓸지 판단하는 모델 전략은 아닙니다. 또한 샌드박스나 접근 제어 제품 자체도 아닙니다. ReAct와 도구 호출이 실행 반복을 설명한다면, MCP는 그 반복에서 사용할 기능의 공통 접점을 제공합니다. 하네스는 MCP로 받은 기능도 다른 도구와 마찬가지로 사용자 권한과 실행 정책에 따라 제한해야 합니다.

프로토콜과 도구 호출을 실제 작업 흐름으로 연결하는 예는 음성 회의록 에이전트 파이프라인에서 살펴봅니다.

참고 문서

• MCP 공식 문서 — Architecture
• MCP 공식 명세