Model Context Protocol: AI와 도구를 잇는 공통 규격의 시작

핵심 판단: MCP의 가치는 모델 성능이 아니라 데이터·도구 연결을 서버 계약으로 분리해, 에이전트와 통합의 다대다 복잡성을 낮춘 데 있다.

AI 앱마다 GitHub, 문서, 데이터베이스 연결을 별도로 만들면 모델 수와 데이터 소스 수가 늘 때 통합 수가 곱셈으로 증가한다. Model Context Protocol은 호스트, 클라이언트, 서버의 역할을 나누고 도구·리소스·프롬프트를 공통 방식으로 노출하려 했다. USB 비유가 자주 쓰이지만, 실제 설계에서는 신뢰 경계와 권한 위임을 더 먼저 봐야 한다.

발표를 한눈에 보기

• 발표 주체: Anthropic
• 공식 발표일: 2024-11-25
• 대상: Model Context Protocol
• 발표 당시 상태: 오픈 프로토콜, SDK와 초기 서버 구현 공개
• 이 글의 질문: 공통 프로토콜이 에이전트 통합 비용을 줄이면서 어떤 보안 책임을 남기는가?

클라이언트·서버 구조의 명세와 SDK, 로컬 데이터 연결 예제, 오픈소스 저장소를 함께 발표했다.

기술 구조: 무엇이 실제로 달라졌나

JSON-RPC 기반 프로토콜이 리소스, 프롬프트, 도구 발견과 호출을 표준화해 모델과 통합 대상 사이의 N×M 어댑터 문제를 줄인다.

MCP 호스트는 사용자와 상호작용하는 AI 애플리케이션이고, 호스트 안의 클라이언트가 각 서버와 연결된다. 서버는 읽을 자료인 resources, 호출 가능한 actions인 tools, 재사용할 지침인 prompts 등을 선언한다. 기능 탐색과 호출 결과를 프로토콜 수준에서 주고받으므로 모델 제공자와 데이터 소스의 결합을 낮출 수 있다.

표준화는 권한을 자동으로 안전하게 만들지 않는다. 서버가 도구를 설명하고 클라이언트가 호출할 수 있다는 사실과, 특정 사용자가 그 작업을 승인했다는 사실은 다르다. 서버 출처, 입력 검증, 비밀정보 전달, 사용자 확인, 결과의 신뢰 수준을 호스트가 정책으로 관리해야 한다.

작동 흐름: 호스트가 서버에 연결 → 기능과 스키마 탐색 → 모델이 후보 도구 선택 → 호스트가 정책·사용자 승인 확인 → 서버 실행 → 구조화 결과를 대화에 반환

이 구조에서 개발자가 가져갈 설계 원칙은 다음과 같다:

• 도구 이름과 설명을 단순 UI 문자열이 아니라 모델의 실행 표면으로 보고 버전·검토 절차를 둔다.
• 읽기와 쓰기, 로컬과 원격, 저위험과 고위험 도구를 서로 다른 승인 정책으로 분리한다.
• 서버가 반환한 콘텐츠도 신뢰하지 않는 입력으로 취급하고 프롬프트 인젝션과 과도한 데이터 노출을 검사한다.

발표가 바꾼 것과 바꾸지 않은 것

AI 에이전트 생태계에서 USB-C처럼 재사용 가능한 연결 계층이 필요하다는 공감대를 만들었다.

MCP는 에이전트 생태계가 모델 API만으로 완성되지 않는다는 점을 분명히 했다. 연결 계층을 독립 규격으로 만들면 같은 서버를 여러 호스트에서 재사용하고, 내부 도구 팀과 AI 제품 팀의 책임을 나눌 수 있다. 이후 개인용 앱부터 개발 도구까지 MCP 지원 자체가 통합 전략이 됐다.

다만 다음 문제까지 해결됐다고 확대 해석해서는 안 된다:

• 프로토콜 호환성이 서버 구현의 품질, 데이터 정확성, 가용성을 보장하지 않는다.
• 도구 스키마가 같아도 인증과 사용자 권한 모델은 조직마다 별도로 설계해야 한다.
• 악성 또는 손상된 서버, 도구 설명을 통한 인젝션, 결과 기반 간접 인젝션은 여전히 남는다.

직접 평가한다면 이렇게 본다

발표사의 종합 점수 하나를 재현하는 것보다, 실제 제품의 입력과 실패 비용에 맞춘 평가가 더 유용하다. 이 주제라면 다음 순서로 확인한다:

• 서버 연결과 기능 탐색 실패, 스키마 버전 불일치, 타임아웃을 정상 경로만큼 테스트한다.
• 읽기 전용 요청이 쓰기 도구로 승격되지 않는지 권한 조합별로 확인한다.
• 도구 설명과 반환 문서에 악성 지시를 넣어 호스트 정책이 이를 데이터로 취급하는지 시험한다.
• 호출 ID, 사용자 승인, 입력, 결과 요약을 감사 로그에서 한 작업 단위로 추적한다.

MCP 서버를 설치하는 행위는 플러그인을 설치하는 것과 비슷한 공급망 결정이다. 연결 성공보다 최소 권한과 제거 가능성을 먼저 검증해야 한다.

내 판단

MCP는 에이전트 시대의 중요한 기반 규격이지만, “한 번 연결하면 무엇이든 쓴다”는 편의만 강조하면 위험하다. 좋은 구현은 서버 재사용성과 호스트 정책을 동시에 강화한다. 특히 쓰기 작업은 모델의 도구 선택과 사용자의 권한 부여 사이에 명시적인 승인 계층을 유지해야 한다.

초기 명세는 인증·원격 배포·권한 위임이 성숙하지 않았고 악성 서버와 도구 출력에 대한 신뢰 경계를 직접 설계해야 했다.

검증 범위

이 글은 공식 발표와 공개된 기술 자료를 바탕으로 구조와 제품 영향을 분석했다. 직접 벤치마크나 장기 운영 검증은 수행하지 않았으며, 발표사가 제시한 수치는 해당 기관의 평가 조건에 한정해 해석했다. 업데이트 시점은 2026년 7월 18일이다.