MCP란?

MCP는 host–client–server 3단 구조 위에서 동작합니다. host는 AI 에이전트나 챗 인터페이스가 실행되는 애플리케이션이며 클라이언트 인스턴스의 생성·권한·라이프사이클을 관리하고 사용자 동의를 받습니다. host 안에 있는 client는 특정 server와 1:1 stateful 세션을 맺으면서 프로토콜 메시지를 양방향으로 전달합니다. server는 외부 시스템과 직접 맞닿아 도구·리소스·프롬프트를 노출하는 쪽입니다. 한 host가 여러 client를 동시에 띄워 각자 다른 server에 붙는 구조가 일반적입니다.

메시지는 모두 JSON-RPC 2.0 형식을 따릅니다. 클라이언트가 메서드 호출(Request)을 보내면 서버가 결과나 오류(Response)를 돌려주고, 응답이 필요 없는 일방향 알림(Notification)은 별도 메시지로 처리됩니다. 세션 시작 시점에는 capability negotiation이 일어납니다. 서버는 자신이 지원하는 기능(tools, resources, prompts 등)을 선언하고, 클라이언트는 처리 가능한 기능을 선언합니다. 이 협상 덕에 단순한 서버와 복잡한 서버가 같은 클라이언트와 호환됩니다.

트랜스포트는 보통 둘 중 하나입니다. 로컬 도구나 IDE 통합용으로는 stdio 트랜스포트가 쓰이며, host가 server를 subprocess로 띄워 표준 입출력으로 메시지를 주고받습니다. 원격·프로덕션 환경에서는 Streamable HTTP 트랜스포트를 쓰며 HTTP POST와 선택적 Server-Sent Events로 양방향 통신을 만듭니다.

MCP 서버가 외부 시스템에서 가져와 모델 앞에 펼쳐 놓는 핵심 단위는 tools, resources, prompts입니다. tool은 모델이 호출할 수 있는 함수로 이름, 사람이 읽는 description, JSON Schema 기반 inputSchema가 함께 정의됩니다. 모델은 description을 읽고 어떤 도구를 언제 호출할지 결정하므로, 이 설명의 품질이 도구 사용의 정확도를 좌우합니다. resource는 모델 또는 사용자가 참조할 수 있는 컨텍스트 데이터(파일, DB 레코드, 라이브 데이터 피드)이며 URI로 식별되고 변경 시 알림을 구독할 수 있습니다. prompt는 사용자가 호출하는 템플릿 메시지로, 자주 쓰는 워크플로를 서버 쪽에서 미리 만들어 둘 때 씁니다.

이 구조의 차별점은 동적 발견(dynamic discovery)입니다. 일반 API Integration에서는 개발자가 문서를 읽고 통합 코드를 직접 작성하고, 함수 호출(function calling)에서는 매 요청마다 도구 정의를 같이 보내야 합니다. MCP에서는 클라이언트가 세션 도중 지식 베이스에 있는 검색 도구나 RAG 워크플로를 런타임에 발견하고, 필요할 때만 호출할 수 있습니다. 도구 정의는 서버 쪽에 한 번만 두고 여러 클라이언트가 공유합니다.

음성 에이전트가 통화 중 실제 업무를 처리하려면 LLM이 만든 답변뿐 아니라, 인증·조회·갱신·전송 같은 액션이 안정적으로 이어져야 합니다. MCP는 이런 액션을 모델이 일관된 방식으로 호출할 수 있게 만드는 자리에 들어갑니다. 사내 예약 시스템, 결제, 발송 시스템을 각각 MCP 서버로 노출하면, 새 통화 시나리오가 생겨도 도구 정의만 추가하면 됩니다. 같은 서버 묶음을 챗봇·내부 어시스턴트·외부 파트너 도구가 그대로 쓸 수 있어 통합 비용이 줄어듭니다.

MCP는 API Integration을 대체하지 않습니다. 그 위에 올라가는 layer로 동작하며, MCP 서버는 보통 내부적으로 REST API를 호출하고 MCP는 그 호출에 도구 발견·자격 증명 격리·세션 상태·표준 인터페이스를 더해 줍니다. 통화 종료 같은 이벤트를 외부 시스템에 알리는 데에는 여전히 웹훅이 적합합니다. 세 방식은 보통 함께 쓰입니다.

AI 에이전트 ↔ 도구 연결을 표준 프로토콜로 풀었다는 점은 도입 의사결정에도 영향을 줍니다. 특정 LLM 벤더에 묶이는 함수 호출 정의 대신, MCP 서버 한 번 구축으로 Claude, ChatGPT, 사내 모델을 같은 도구로 다 붙일 수 있게 됩니다. 도구가 늘어나도 매 요청마다 전부 보내지 않고 서버 쪽에서 필요할 때만 노출하므로, 토큰·지연 비용도 절감됩니다.

MCP 서버는 도구라는 형태로 임의 코드 실행 권한을 모델에게 노출합니다. 그래서 첫째로 확인해야 할 것은 사용자 동의와 권한 범위입니다. host는 도구를 호출하기 전 사용자의 명시적 동의를 받아야 하고, 도구 description은 신뢰할 수 없는 입력으로 취급해야 합니다. 악의적 서버가 description에 prompt injection을 심을 수 있다는 보고가 이미 나와 있습니다.

엔터프라이즈 환경에서는 정책 enforcement를 도구 호출 시점에 둬야 합니다. 사후 로그만으로는 부족하고, 미승인 서버는 게이트웨이에서 차단하고, 역할 기반 접근 제어(RBAC)로 팀별·사용자별 도구 사용 범위를 제한하며, 모든 호출은 사용자 ID·서버·도구·파라미터·결과까지 묶인 감사 로그로 남겨야 합니다. AI 가드레일과 개인정보 마스킹 정책도 보통 MCP 게이트웨이 layer에 함께 얹습니다.

공급망 위험도 따로 봐야 합니다. 공개 레지스트리에서 받은 MCP 서버는 의존성과 자격 증명 접근 범위가 불투명합니다. 사내 private registry에 vetting을 거친 서버만 등록하고, 컨테이너 sandbox에서 실행하는 패턴이 권장됩니다. HIPAA, SOC 2, GDPR, EU AI Act 같은 컴플라이언스 요건이 있는 운영에서는 이 레지스트리·게이트웨이·감사 추적을 권고 문서로 두면 안 됩니다. enforce된 인프라로 운영해야 사고가 났을 때 추적이 가능합니다.