불과 일주일 전, Model Context Protocol은 2025-11-25 사양 릴리스와 함께 첫 번째 기념일을 맞이했습니다 [1]. 이 발표는 당연히 승리의 순간이었습니다. MCP는 실험적인 오픈소스 프로젝트에서 GitHub, OpenAI, Microsoft, Block이 지원하는 기초 표준으로 진화했으며, 수천 개의 활성 서버가 프로덕션 환경에서 운영되고 있습니다 [1].
\n\n하지만 축하 이면에는 더 흥미로운 이야기가 있습니다. 이번 사양 릴리스는 단순한 진화가 아니라 엔터프라이즈 준비성을 향한 전략적 전환입니다. 지난 1년 동안 MCP는 개발자 도구로서 성공했습니다. 실험 단계에서 AI 모델을 데이터 및 기능에 연결하는 편리한 방법이었죠. 2025-11-25 사양은 다릅니다. 조직이 에이전트-도구 생태계를 엔터프라이즈 규모로 배포하는 것을 막는 운영, 보안, 거버넌스 문제를 해결하기 위해 명시적으로 설계된 기능을 도입합니다.
\n\n이 글에서는 새로운 사양의 세 가지 핵심 기능을 살펴보고, 제가 \"프로덕션 격차\"라고 부르는 것, 즉 실험적 에이전트 프로토타입과 엔터프라이즈급 에이전트 인프라 사이의 거리를 어떻게 좁히는지 분석합니다.
\n\n기술적 기능을 살펴보기 전에, 이들이 해결하려는 문제를 이해해야 합니다. 조직들은 수개월 동안 MCP 기반 에이전트를 실험해왔으며, 통제된 환경에서 종종 인상적인 결과를 얻었습니다. 그러나 이러한 프로젝트의 대부분은 파일럿 단계에 갇혀 프로덕션 배포로 진행하지 못하고 있습니다. 장벽은 기술적 변덕이 아니라 근본적인 운영 요구사항입니다:
\n\n| 요구사항 | \n중요한 이유 | \n부족했던 것 | \n
|---|---|---|
| 비동기 작업 | \n보고서 생성, 데이터 분석, 워크플로우 자동화와 같은 실제 작업은 밀리초가 아니라 몇 분 또는 몇 시간이 걸릴 수 있습니다. | \nMCP 연결은 동기식입니다. 장시간 실행되는 작업은 클라이언트가 연결을 계속 유지하거나 사용자 정의 폴링 시스템을 구축하도록 강제합니다. | \n
| 엔터프라이즈 인증 | \n조직은 어떤 사용자, 에이전트, 서비스가 민감한 도구와 데이터에 액세스할 수 있는지 중앙 집중식으로 제어해야 합니다. | \n원래 OAuth 플로우는 소비자 앱 모델을 가정했습니다. 머신 간 인증 지원이 부족했고 엔터프라이즈 Identity Provider와 통합되지 않았습니다. | \n
| 확장성 | \n다양한 산업과 사용 사례는 핵심 프로토콜을 분열시키지 않으면서 사용자 정의 기능을 필요로 합니다. | \n확장을 표준화하는 공식적인 메커니즘이 없어 독점적이고 호환되지 않는 구현으로 이어졌습니다. | \n
이것들은 엣지 케이스가 아닙니다. 프로덕션 시스템의 기본 요구사항입니다. 2025-11-25 사양은 각각을 직접적으로 해결합니다.
\n\n아마도 가장 혁신적인 추가 사항은 새로운 Tasks 기본 요소입니다 [2]. 아직 실험적으로 표시되어 있지만, 에이전트가 장시간 실행 작업을 위해 MCP 서버와 상호작용하는 방식을 근본적으로 변화시킵니다.
전통적인 MCP는 고전적인 RPC 패턴을 따릅니다. 클라이언트가 요청을 보내고, 서버가 처리하고, 서버가 응답을 반환합니다. 모두 단일 연결 내에서 이루어집니다. 이것은 데이터베이스 행 읽기나 날씨 API 확인과 같은 빠른 작업에는 완벽하게 작동합니다. 하지만 현실적인 엔터프라이즈 워크플로우에서는 문제가 발생합니다:
\n\n조직들은 사용자 정의 해결 방법을 구축해야 했습니다: 작업 큐, 폴링 시스템, 콜백 웹훅 등. 모두 비표준이며, 모두 복잡성을 증가시키고 상호운용성을 감소시킵니다.
\n\n새로운 Tasks 기능은 표준 \"지금 호출, 나중에 가져오기\" 패턴을 도입합니다:
task 힌트와 함께 MCP 서버에 요청을 보냅니다.taskId를 반환합니다.working, completed, failed)를 주기적으로 확인합니다.taskId를 사용하여 최종 결과를 검색합니다.이것은 단순한 구문적 설탕 이상입니다. 전체 MCP 생태계에 걸쳐 비동기 작업에 대한 균일한 추상화를 제공합니다. 에이전트 프레임워크는 데이터 파이프라인, 배포 시스템, 문서 프로세서 중 무엇을 호출하는지 알 필요가 없습니다. 비동기 패턴은 동일합니다.
\n\n프로덕션 환경에서 이것은 모든 것을 바꿉니다. 복잡한 워크플로우를 조율하는 AI 어시스턴트는 다음을 수행할 수 있습니다:
\n\n이것이 실제 자율 에이전트가 작동하는 방식입니다. Tasks 기본 요소는 이를 표준 상호운용 가능한 프로토콜 내에서 가능하게 만듭니다.
원래 MCP 사양에는 OAuth 2.0 지원이 포함되어 있었지만, 소비자 앱 패턴(\"GitHub로 로그인\"과 같은)을 모델로 했습니다. 이 모델은 조직이 중앙 집중식 ID 관리, 감사 추적, 정책 기반 액세스 제어를 필요로 하는 엔터프라이즈 사용 사례에는 작동하지 않습니다. 2025-11-25 사양은 이 격차를 해소하기 위해 두 가지 중요한 업데이트를 도입합니다.
\n\n첫 번째 변경 사항은 Dynamic Client Registration (DCR)을 Client ID Metadata Documents (CIMD)로 대체하는 것입니다 [3]. 이전 모델에서는 모든 MCP 클라이언트가 사용하려는 모든 인증 서버에 등록해야 했습니다. 연합 엔터프라이즈 환경에서는 확장성 악몽이었죠.
\n\nCIMD를 사용하면 client_id는 이제 클라이언트가 제어하는 URL입니다(예: https://agents.mycompany.com/sales-assistant). 인증 서버가 이 클라이언트에 대한 정보가 필요할 때 해당 URL에서 JSON 메타데이터 문서를 가져옵니다. 이 문서에는 다음이 포함됩니다:
이 접근 방식은 DNS와 HTTPS에 기반한 분산 신뢰 모델을 생성합니다. 인증 서버는 클라이언트와 기존 관계가 필요하지 않습니다. URL에 게시된 메타데이터를 신뢰합니다. 수십 개의 에이전트 애플리케이션과 여러 MCP 제공자를 보유한 대규모 조직의 경우, 이는 운영 오버헤드를 극적으로 줄입니다.
\n\n두 번째 중요한 추가 사항은 M2M OAuth 확장을 통한 OAuth 2.0 client_credentials 플로우 지원입니다. 이는 머신 간 인증을 가능하게 하여 에이전트와 서비스가 사용자 개입 없이 MCP 서버와 직접 인증할 수 있게 합니다.
왜 이것이 중요할까요? 다음 엔터프라이즈 시나리오를 고려해보세요:
\n\n이들 중 어느 것도 대화형 사용자를 포함하지 않습니다. 조직을 대신하여 도구에 액세스하기 위해 영구적이고 안전한 자격 증명이 필요한 자율 서비스입니다. client_credentials 플로우는 정확히 이 사용 사례를 위한 표준 OAuth 메커니즘이며, MCP에 포함되어 헤드리스 에이전트 시스템을 실행 가능하게 만듭니다.
대규모 엔터프라이즈에 가장 전략적으로 중요한 기능은 Cross App Access (XAA) 확장입니다. 이는 엔터프라이즈 AI의 소비자화를 괴롭혀온 거버넌스 문제, 즉 통제되지 않는 도구 확산을 해결합니다.
\n\n표준 OAuth 플로우에서 사용자는 도구에 액세스하기 위해 AI 애플리케이션에 직접 동의를 부여합니다. 엔터프라이즈 Identity Provider (IdP)는 \"Alice가 AI 앱에 로그인했다\"만 볼 뿐, \"Alice의 AI 에이전트가 이제 급여 시스템에 액세스하고 있다\"는 것을 보지 못합니다. 이는 거버넌스 블랙홀을 만듭니다.
\n\nXAA는 엔터프라이즈 IdP를 중앙 정책 시행 지점으로 삽입하도록 인증 플로우를 변경합니다. 이제 에이전트가 MCP 서버에 액세스하려고 시도할 때:
\n\n이는 전체 에이전트-도구 생태계에 대한 중앙 집중식 가시성과 제어를 제공합니다. 보안 팀은 어떤 에이전트가 어떤 도구에 액세스하는지 모니터링하고, 조직 전체 정책을 설정하고(예: \"에이전트는 사람의 검토 없이 PII에 액세스할 수 없음\"), 모든 위임된 액세스를 감사할 수 있습니다. 섀도우 AI를 제거하고 규제 산업이 요구하는 규정 준수 스토리를 제공합니다.
\n\n이러한 OAuth 개선 사항은 함께 MCP를 개발자 편의성에서 거버넌스되고 감사 가능한 통합 레이어로 변환합니다. 조직은 다음을 수행할 수 있습니다:
\n\n세 번째 주요 추가 사항은 공식 확장 프레임워크의 도입입니다 [3]. 이는 프로토콜 자체에 대한 거버넌스 메커니즘으로, 커뮤니티가 생태계를 분열시키지 않으면서 새로운 기능을 개발할 수 있게 합니다.
\n\n모든 성공적인 프로토콜은 이 딜레마에 직면합니다: 진화하는 사용 사례를 따라잡을 만큼 빠르게 혁신을 가능하게 하되, 상호운용성을 유지할 만큼 신중하게 표준화해야 합니다. 너무 느리게 움직이면 커뮤니티가 생태계를 분열시키는 독점 확장을 구축합니다. 너무 빠르게 움직이면 핵심 프로토콜이 대부분의 구현에 필요하지 않은 틈새 기능으로 비대해집니다.
\n\nMCP의 솔루션은 구조화된 확장 프로세스입니다. 새로운 기능은 Specification Enhancement Proposals (SEPs)로 제안되며, 커뮤니티 검토를 거쳐 점진적으로 채택될 수 있습니다. 확장은 네임스페이스가 지정되고 명확하게 표시되므로 구현이 호환성을 깨지 않고 선택적으로 지원할 수 있습니다.
\n\n엔터프라이즈에게 이것은 중요합니다. 다양한 산업에는 고유한 요구사항이 있습니다:
\n\n공식 확장 프레임워크를 통해 조직은 이러한 기능을 독점 포크가 아닌 표준 상호운용 가능한 확장으로 개발할 수 있습니다. 이는 MCP의 핵심 가치 제안인 에이전트-도구 통신을 위한 범용 프로토콜을 보존하면서 프로덕션 사용에 필요한 사용자 정의를 가능하게 합니다.
\n\n언급할 가치가 있는 또 다른 기능이 있습니다: Sampling with Tools [3]. 이를 통해 MCP 서버 자체가 다단계 추론 및 도구 사용이 가능한 에이전트 시스템으로 작동할 수 있습니다. 서버는 이제 클라이언트에 자신을 대신하여 LLM을 호출하도록 요청할 수 있어 서버 측 에이전트를 가능하게 합니다.
\n\n왜 이것이 강력할까요? 구성적 에이전트 아키텍처를 가능하게 합니다. 상위 수준 에이전트는 전문화된 MCP 서버에 위임할 수 있으며, 이들은 자체적으로 에이전트 추론을 사용하여 복잡한 요청을 수행합니다. 예를 들어:
\n\n이러한 중첩된 계층적 접근 방식은 실제 자율 시스템이 확장되는 방식입니다. 이를 사용자 정의 구현이 아닌 표준 프로토콜 기능으로 만듦으로써 MCP는 전문화되고 구성 가능한 에이전트의 풍부한 생태계를 위한 기반을 제공합니다.
\n\n2025-11-25 MCP 사양은 급진적인 재설계가 아닙니다. 엔터프라이즈 채택을 막는 장벽을 직접적으로 해결하는 목표 지향적인 개선 사항 세트입니다. 다음을 도입함으로써:
\n\n사양은 프로덕션 격차, 즉 실험적 프로토타입과 확장 가능하고 안전한 엔터프라이즈급 시스템 사이의 거리를 해소합니다.
\n\n이것은 MCP가 유망한 개발자 도구에서 엔터프라이즈 인프라의 기초 요소로 전환하는 순간입니다. \"프로덕션 준비성\" 신호를 기다려온 조직들은 이제 그것을 가지고 있습니다. 기능이 있습니다. 거버넌스 메커니즘이 있습니다. 보안 모델이 있습니다.
\n\n에이전트 AI의 다음 단계는 화려한 데모가 아니라 엔터프라이즈 워크플로우에 깊이 통합된 자율 시스템의 조용하고 안정적이며 대규모 운영으로 정의될 것입니다. 2025-11-25 MCP 사양은 이 미래를 가능하게 하는 기술적 기반입니다.
\n\nMCP 기반 인프라에 투자할지 평가하는 기술 리더들에게 계산이 바뀌었습니다. 이것은 더 이상 실험적 프로토콜이 아닙니다. 프로덕션 표준입니다. 지금 이를 채택하고, 그 위에 에이전트 생태계를 구축하고, 지속적인 진화에 기여하는 조직이 엔터프라이즈 AI의 다음 10년을 정의할 것입니다.
\n\n참고문헌:
\n\n\n\n[2] Model Context Protocol. (2025, November 25). Tasks. Model Context Protocol Specification.
\n\n\n\n\n\n", "source_hash": "sha256:ea07631d24ec71a2eeb27320d3216318879d24370148bc466f28b99355798962", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-02T02:29:35.912965+00:00" }