여러 AI 앱에서 같은 사내 도구를 쓰도록 MCP를 도입하려 합니다. host·client·server는 각각 무엇을 맡나요?

MCP는 모델 자체의 추론 방식보다 AI 앱과 외부 도구·자료 사이의 통신 계약을 표준화합니다. host는 모델과 사용자 상호작용, 정책을 관리하는 애플리케이션이고, client는 host 안에서 서버와 프로토콜을 주고받는 연결 역할이며, server는 도구·리소스·프롬프트 같은 기능을 제공합니다. MCP 서버를 연결했다고 모델이 모든 기능을 반드시 사용하거나 모든 작업이 안전해지는 것은 아닙니다.

추론과 연결 책임을 나눕니다

사내 이슈 조회 서버가 도구 이름과 인자 스키마를 제공하면 host는 현재 요청에 필요한 도구를 모델에 보여 줄 수 있습니다. 모델이 호출을 제안해도 host의 승인·예산 검사와 서버의 실제 인가가 남습니다. client는 요청 ID와 결과·오류를 연결하고 버전 계약에 맞게 전송합니다. server는 이슈 저장소를 읽고 필요한 결과만 반환하며, 최종 답변의 사실성과 도구 선택은 별도 평가 대상입니다.

도구 연결용 MCP와 원격 에이전트에게 목표를 맡기는 프로토콜은 역할이 다릅니다. MCP 서버가 내부적으로 LLM을 쓸 수도 있지만, 그 구현 사실이 도구 호출을 에이전트 간 위임과 동일하게 만들지는 않습니다. 이름보다 공개 API가 함수 실행인지 장기 목표·작업 상태·산출물을 전달하는 계약인지 확인하겠습니다.

버전과 운영 경계를 명시합니다

2026년 9월 11일 확인한 MCP 최신 명세 페이지는 2026-07-28 리비전을 가리킵니다. 이 리비전은 요청별 프로토콜 버전·capability 전달과 stateless 구조를 설명하며, 과거 initialize 세션 절차를 모든 버전에 공통인 규칙으로 설명하면 안 됩니다. 실제 사용하는 SDK와 서버가 어느 버전을 지원하는지 확인하고 변경 이력과 호환 경로를 함께 검증하겠습니다. 최신 문서의 존재가 배포된 모든 클라이언트의 지원을 뜻하지는 않습니다.

도구 목록이 표준 형식이어도 의미·권한·오류는 실제 구현에 달려 있습니다. 읽기 전용 표시나 서버 설명은 그 서버가 제공한 주장일 수 있어 신뢰 근거를 별도로 확인합니다. 연결 허용 목록, 자격 증명 분리, 도구별 인가, 출력 크기 제한과 감사 기록을 host·server 경계에 둡니다. 도입 효과는 새 앱 연결 비용과 도구 선택·호출 오류 감소로 측정하고, 표준화와 운영 안전성을 같은 하나의 보장으로 묶지 않겠습니다.

실행 사례로 확인합니다

host 한 개가 여러 서버를 사용하면 서버별 자격 증명과 결과 출처를 구분해야 합니다. 서버 A의 resource를 읽었다고 서버 B가 그 자료를 자동으로 받을 수 있는 것은 아닙니다. client 연결을 별도로 만들더라도 host가 문맥을 합칠 때 데이터 공개 정책이 필요합니다. 장애도 서버별로 격리합니다. 한 검색 서버가 느려졌을 때 모든 도구 호출을 막을지 선택적인 기능만 축소할지 결정하고, timeout·재시도 예산을 사용자 요청과 연결합니다. MCP가 JSON-RPC 형태를 맞춰 주어도 외부 API의 지연·부분 성공·권한 철회는 사라지지 않습니다. 통합 시험은 발견에서 실제 호출과 오류 처리까지 전체 경로를 다루겠습니다.