MCP 2.0: AI 에이전트에게 마침내 범용 전원 콘센트를 제공하는 프로토콜

중소 규모의 SaaS 기업 팀이 자신들의 AI 에이전트가 Salesforce, Jira, Confluence, 그리고 내부 데이터 웨어하우스(data warehouse)와 통신할 수 있도록 커스텀 통합 계층(custom integration layer)을 구축하는 데 6주를 보냈습니다. 도구는 4개였습니다. 기간은 6주였습니다. 하지만 에이전트는 여전히 48시간마다 수동 개입 없이 OAuth 토큰 갱신(token refresh)을 처리할 수 없었습니다.

그들의 경쟁사는 동일한 기능을 4일 만에 출시했습니다.

6주 대 4일이라는 이 격차를 실제로 메워주는 것이 바로 Model Context Protocol 2.0입니다.

MCP란 무엇인가 (그리고 왜 이것이 필요할 때까지 이토록 오래 걸렸는가)

Model Context Protocol은 Anthropic이 2024년 11월에 출시한 개방형 표준으로, AI 애플리케이션과 외부 도구, 데이터 소스 및 서비스 간의 범용 통신 계층을 정의합니다. 이를 AI 에이전트를 위한 USB-C라고 생각하십시오. USB-C가 나오기 전에는 모든 장치에 서로 다른 케이블이 필요했습니다. MCP가 나오기 전에는 모든 AI 통합에 커스텀 커넥터 코드(custom connector code)가 필요했습니다.

기존 사양은 깔끔한 클라이언트/서버(client/server) 아키텍처를 구축했습니다. 즉, AI 애플리케이션(MCP 클라이언트)은 각 도구의 구현 세부 사항을 알 필요 없이 MCP 서버가 노출하는 도구를 발견하고 호출합니다. 몇 달 안에 GitHub, Slack, Notion, PostgreSQL, Google Drive 및 수십 개의 공식 MCP 서버가 출시되었습니다.

하지만 첫 번째 버전에는 실제 운영 환경에서의 격차가 있었습니다. 표준화된 인증 흐름(authorization flow)이 없었고, 장기 실행 작업(long-running operations)을 처리하는 데 어려움을 겪는 전송 계층(transport layer)이 있었으며, 에이전트가 도구 호출을 재시도해도 안전한지 알 수 있는 프로토콜 수준의 방법이 없었습니다. 데모나 내부 프로토타입용으로는 관리 가능한 수준이었지만, 고객 데이터에 접근하고, 컴플라이언스 감사 추적(compliance audit trails)이 필요하며, 24시간 내내 작동해야 하는 기업용 운영 배포(enterprise production deployments) 환경에서는 이러한 문제들이 차단 요소(blockers)였습니다.

2025년 3월의 사양 업데이트 — 커뮤니티에서 MCP 2.0이라 부르는 것 — 는 이 세 가지 문제를 모두 해결했습니다.

MCP 2.0에서 실제로 변경된 점

세 가지 변화가 있습니다. 각각은 특정 운영 실패 모드(production failure mode)를 해결합니다.

OAuth 2.0 인증 (Authorization)

기존 MCP 명세는 인증(auth)을 구현자의 몫으로 남겨두었습니다. 실제로 이는 에이전트가 장기 유지되는 관리자 자격 증명(admin credentials)을 보유하게 된다는 것을 의미했으며, 이는 가장 저항이 적은 경로인 동시에 컴플라이언스(compliance) 측면에서는 악몽과도 같았습니다.

MCP 2.0은 OAuth 2.0을 일급 프로토콜 요소(first-class protocol element)로 만듭니다. MCP 서버는 자신의 인증 요구 사항을 선언하며, 클라이언트는 도구 호출(tool calls)이 허용되기 전에 이를 충족해야 합니다. EHR 시스템에 연결하는 의료 에이전트는 상시 관리자 권한(standing admin access)이 아닌, 범위가 제한되고 유효 기간이 정해진 토큰(scoped, time-limited tokens)을 받게 됩니다. 컴플라이언스 팀은 기존 OAuth 인프라를 통해 에이전트의 권한을 감사(audit)할 수 있습니다. 최소 권한 원칙(Least-privilege access)은 단순히 배포 압박 속에서 무시되기 쉬운 정책적 열망이 아니라, 프로토콜 수준에서 강제될 수 있게 됩니다.

스트리밍 가능한 HTTP 전송 (Streamable HTTP Transport)

기존의 전송 방식은 서버 전송 이벤트(Server-Sent Events, SSE)였습니다. 실시간 업데이트에는 유용했지만, 단방향적이고 상태가 없는(stateless) 특성 때문에 장시간 실행되는 작업(long-running operations)을 처리하기에는 어색한 면이 있었습니다. 만약 에이전트가 20분짜리 데이터 파이프라인을 트리거하고 실시간 진행 상황 업데이트가 필요하다면, SSE는 고통스러운 타협안이었습니다.

MCP 2.0은 SSE를 스트리밍 가능한 HTTP (Streamable HTTP)로 대체합니다. 이는 양방향(bidirectional)이며, 재개 가능(resumable)하고, 단일 HTTP 요청보다 오래 지속되는 작업을 위해 구축되었습니다. CI/CD 파이프라인을 모니터링하는 개발 도구 에이전트는 폴링(polling) 없이도 실시간 빌드 이벤트를 받을 수 있습니다. 500개의 문서 코퍼스(corpus)를 처리하는 에이전트 워크플로우는 타임아웃(timeout) 없이 실시간으로 진행 상황을 보고합니다.

도구 주석 (Tool Annotations)

MCP 2.0 이전에는 에이전트가 delete_customer_record가 되돌릴 수 없는 작업이라거나, get_account_balance가 부작용(side effects) 없이 10번 호출해도 안전하다는 것을 프로토콜 수준에서 알 수 있는 신호가 없었습니다.

Tool annotations가 이 문제를 해결합니다. 서버 작성자는 도구가 readOnly (읽기 전용), destructive (파괴적), 또는 idempotent (멱등성) 인지 선언합니다. 오케스트레이션 에이전트 (orchestrating agent)는 도구별로 별도의 가드레일 (guardrail) 로직을 구현할 필요 없이, 읽기 전용 도구는 병렬로 실행하고 파괴적인 도구는 확인 단계를 거치도록 제어할 수 있습니다. 이러한 어노테이션 (annotations)은 강제되는 제약 조건은 아닌 힌트(hints)이지만, 에이전트가 기본적으로 합리적으로 동작하는 데 필요한 정보를 제공합니다.

4 MCP 2.0이 판도를 바꾸는 4가지 활용 사례

1. 엔터프라이즈 데이터 에이전트 (Enterprise Data Agents)

Salesforce를 쿼리하고, 데이터 웨어하우스 (data warehouse)에서 데이터를 가져오며, SharePoint 지식 베이스를 교차 참조하는 에이전트는 이전에는 세 가지 별도의 통합 (integrations)이 필요했습니다. 즉, 각각 다른 인증 패턴 (auth patterns), 다른 응답 스키마 (response schemas), 그리고 각기 다른 에러 처리 (error handling) 방식이 필요했습니다.

MCP를 사용하면 에이전트는 하나의 프로토콜을 사용하여 세 개의 MCP 서버와 통신합니다. 네 번째 데이터 소스를 추가해야 하나요? 또 다른 MCP 서버를 세우기만 하면 됩니다. 에이전트에는 아무런 변경이 필요 없습니다. 도구의 수가 늘어나도 통합 표면 (integration surface)은 평탄하게 유지됩니다. 5~15개의 내부 시스템에서 AI 에이전트를 실행하는 클라이언트에게 이것은 유지 관리 가능한 아키텍처와, 매 분기마다 깨지는 취약한 맞춤형 통합 사이의 결정적인 차이입니다.

2. 인증 기반 기록을 사용하는 헬스케어 에이전트 (Healthcare Agents with Auth-Gated Records)

헬스케어는 MCP 2.0의 OAuth 레이어 (layer)가 가장 중요한 분야입니다. 서로 다른 시스템에서 환자 기록, 검사 결과, 처방 이력을 가져오는 AI 에이전트는 단일 관리자 키 (admin key)를 보유할 수 없습니다. HIPAA는 감사 추적 (audit trails)이 포함된 범위 제한적 접근 (scoped access)을 요구하기 때문입니다.

MCP 2.0의 OAuth 2.0 프레임워크는 정확히 그 기능을 제공합니다. 즉, 언제든 취소 가능하고 표준 OAuth 인프라를 통해 감사가 가능한, 범위가 지정된 권한을 가진 시스템별 토큰 (tokens)을 제공합니다. 에이전트는 필요한 것에만 접근하며, 그 외의 것에는 접근할 수 없습니다. 그리고 모든 접근은 컴플라이언스 (compliance) 팀이 이미 읽는 법을 알고 있는 형식으로 기록됩니다.

3. 멀티 에이전트 오케스트레이션 (Multi-Agent Orchestration)

AI 시스템이 단일 에이전트에서 전문화된 에이전트 네트워크로 이동함에 따라, 에이전트 간의 통신 레이어 (communication layer)는 에이전트 자체만큼이나 중요해지고 있습니다.

MCP는 멀티 에이전트 아키텍처 (multi-agent architectures)에서 점점 더 중요한 프로토콜 레이어 (protocol layer)가 되고 있습니다. 즉, 오케스트레이팅 에이전트 (orchestrating agent)가 MCP 도구 호출 (tool calls)을 통해 전문화된 하위 에이전트 (sub-agents)에게 작업을 할당하고, 결과를 수집하며, 이를 종합합니다. 오케스트레이터는 리서치 에이전트 (research agent)가 정보를 어떻게 검색하는지, 또는 코드 에이전트 (code agent)가 테스트를 어떻게 실행하는지 알 필요가 없습니다. 그저 MCP로 노출된 도구들을 호출하기만 하면 됩니다. 이것이 단순한 연구 논문 속의 모델이 아니라, 실제 운영 환경 (production environments)에서 작동하고 있는 멀티 에이전트 프레임워크 (multi-agent frameworks)의 핵심 패턴입니다.

4. 개발자 도구 에이전트 (Developer Tooling Agents)

GitHub, CI/CD 시스템, 애플리케이션 모니터링을 연결하는 개발 에이전트 (dev agent)는 과거에 고통스러운 선택에 직면해야 했습니다. 업데이트를 위해 폴링 (poll)을 할 것인지 (느리고 비용이 많이 듦), 아니면 각 도구에 맞춤형 웹훅 (webhooks)을 구축할 것인지 (복잡하고 취약함) 중 하나를 택해야 했습니다.

Aviasole의 역할

우리는 데모나 2개월 만에 중단될 개념 증명 (proof-of-concepts)이 아닌, 실제 운영을 위한 AI 에이전트를 구축합니다. MCP 2.0은 우리가 에이전트 기반 AI 서비스 (agentic AI engagements)를 위한 통합 아키텍처를 설계할 때 핵심적인 부분입니다. 왜냐하면 MCP 2.0은 기업 환경에서 에이전트 프로젝트를 실제로 무산시키는 문제들을 해결하기 때문입니다: 컴플라이언스 (compliance) 팀을 만족시키는 인증 (auth), 새로운 도구를 추가해도 파편화되지 않는 통합, 그리고 커넥터마다 별도의 가드레일 (guardrails)을 설정하지 않아도 에이전트가 합리적으로 행동할 수 있게 하는 충분한 프로토콜 수준의 안전 정보 등이 그것입니다.

LLM 애플리케이션 개발 (LLM application development)을 진행하는 고객들에게 MCP는 컨텍스트 검색 (context retrieval)에 대한 사고방식 또한 변화시킵니다. 즉, 맞춤형 검색 커넥터 (bespoke retrieval connectors)에서 벗어나, 스택 내의 어떤 에이전트라도 중복 없이 재사용할 수 있는 프로토콜 네이티브 도구 서버 (protocol-native tool servers)로 이동하는 것입니다.

MCP 도입 비용을 지불할 가치가 있는지 판단할 수 있는 실질적인 신호는 다음과 같습니다: 만약 당신의 에이전트가 두세 개 이상의 외부 시스템을 호출하고 있다면, 당신은 이미 맞춤형 통합의 복잡성이라는 대가를 치르고 있는 것입니다. MCP 2.0은 이제 OAuth, 스트리밍 (streaming), 그리고 점점 성장하는 공식 서버 생태계를 갖추어, 대부분의 엔터프라이즈급 에이전트 아키텍처에 대한 정답이 될 수 있을 만큼 충분히 성숙했습니다.

MCP 네이티브 에이전트를 구축할 준비가 되셨나요?

만약 여러분의 에이전트 아키텍처 (agent architecture)를 위해 MCP 2.0을 검토 중이거나, 이미 시작했지만 인증 (auth), 전송 (transport), 또는 통합 확산 (integration sprawl) 문제로 어려움을 겪고 있다면, 저희 팀에 문의해 주세요. 저희는 여러분의 스택 (stack)에 대한 구체적인 사항들을 함께 검토하여, MCP가 실제로 여러분의 문제를 해결할 수 있는지, 아니면 더 간단한 접근 방식이 더 적합한지를 솔직하게 말씀드리겠습니다.