에이전트 AI - 26.7.28 MCP 업데이트 사양

https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

2026.5.21
[The 2026-07-28 MCP Specification Release Candidate]

이 블로그 게시물은 2026년 7월 28일로 예정된 Model Context Protocol(MCP)의 대규모 사양 업데이트와 그에 따른 주요 변화를 안내하고 있습니다. 이번 개편의 핵심은 기존의 복잡한 연결 방식을 탈피하여 일반적인 HTTP 환경에서 효율적으로 확장 가능한 무상태형(Stateless) 코어 체계로 전환하는 것입니다. 또한, 서버가 직접 사용자 인터페이스를 제공하는 MCP Apps와 독립적으로 운영되는 확장 프로그램 프레임워크를 도입하여 프로토콜의 유연성을 극대화했습니다. 궁극적으로 이 텍스트는 공식적인 지원 종료 정책과 보안 강화 조치를 통해 개발자들이 예측 가능한 환경에서 혁신적인 AI 도구를 구축할 수 있도록 돕는 안정적인 기술적 토대를 제시하고 있습니다.

 

이번 사양의 핵심은 기존의 상태 유지(Stateful) 방식에서 상태 비저장(Stateless) 코어로의 완전한 아키텍처 전환에 있습니다. 이는 복잡한 세션 관리와 스티키 세션(Sticky sessions)에 의존하던 기존 모델의 한계를 극복하고, 표준 HTTP 인프라 위에서 AI 서비스를 무한히 확장할 수 있는 기술적 토대를 제공합니다.

 

 

본 보고서에서는 아키텍처 관점에서 이번 업데이트의 4대 핵심 축인 상태 비저장 코어(Stateless Core), 확장 프레임워크(Extensions), 권한 부여 강화(Authorization), 공식 지원 중단 정책(Deprecation Policy)을  심층 분석합니다.

 

산업 표준 정렬: OAuth 2.0 및 OpenID Connect 기반 권한 부여 강화

MCP 보안 모델은 현대 엔터프라이즈 보안의 표준인 OAuth 2.0 및 OpenID Connect(OIDC)와의 정렬을 강화하여, "1개 클라이언트 - 다수 서버"라는 MCP 특유의 배포 패턴에서 발생할 수 있는 보안 취약점을 근본적으로 해결하고자 합니다.

 

기술적 세부 사항 및 기업 보안 가치

• RFC 9207 준수 및 믹스업 공격 방어: 다중 서버 환경에서는 인가되지 않은 서버가 토큰을 가로채는 '믹스업 공격(Mix-up attack)' 위험이 큽니다. SEP-2468은 iss(Issuer) 파라미터 검증을 강제함으로써 클라이언트가 신뢰할 수 있는 권한 부여 서버를 명확히 식별하게 합니다.
• 동적 클라이언트 등록(SEP-837): application_type 선언을 통해 로컬 개발 환경과 프로덕션 클라우드 간의 리다이렉트 URI 오류를 해결합니다. 이는 하이브리드 환경에서의 배포 마찰을 줄이는 실질적인 운영 이점을 제공합니다.
• 토큰 및 스코프 관리 최적화: 리프레시 토큰 요청의 공식화(SEP-2207)와 단계적 권한 상승(Step-up) 시의 스코프 누적 로직(SEP-2350) 명확화는 개발자가 보안 모범 사례를 유지하면서도 사용자 경험을 훼손하지 않도록 돕습니다.

 

보안 강화 및 워크플로우 영향 요약

SEP 번호	기술 표준	기업용 AI 워크플로우에의 영향
SEP-2468	RFC 9207 (iss 검증)	다중 서버 환경에서 신원 혼동을 방지하여 믹스업 공격 및 토큰 탈취 차단
SEP-837	Dynamic Client Registration	클라이언트 유형 명시를 통해 데스크톱/CLI 개발 및 배포 환경의 구성 오류 제거
SEP-2207	OIDC Refresh Token	세션 단절 없는 지속적인 도구 사용을 위한 표준화된 토큰 갱신 프로세스 확보
SEP-2350	Scope Accumulation	최소 권한 원칙 기반의 단계적 권한 확장 시 데이터 관리의 일관성 보장

 

확장 프로그램(Extensions) 프레임워크의 공식화와 아키텍처 가치

이번 사양에서 확장은 단순한 추가 기능이 아닌 '1급 객체(First-class citizens)'로 격상되었습니다. 이는 MCP 코어 사양의 경량성을 유지하면서도 도메인별 특화 기능을 독립적으로 진화시킬 수 있는 플랫폼 독립적 구조를 완성합니다.

 

심층 분석 및 신규 기능

• 공식화된 관리 체계(SEP-2133): 역방향 DNS ID(Reverse-DNS IDs)와 독립적 버전 관리 도입은 엔터프라이즈 환경에서 컴포넌트 단위의 보안 검토와 가시성 확보를 가능하게 합니다.
• 전사적 데이터 계약을 위한 JSON Schema 2020-12 (SEP-2106): 도구의 입력/출력 스키마가 최신 표준으로 격상되었습니다. 이를 통해 oneOf, anyOf, $ref, 그리고 조건부 로직(if/then/else)을 지원하여, 복잡한 기업용 API 계약을 엄격하게 검증하고 런타임 에러를 획기적으로 줄일 수 있습니다.
• MCP Apps (SEP-1865): 서버 렌더링 UI가 샌드박스화된 iframe에서 작동합니다. 이는 호스트 시스템과 UI를 격리하여 보안을 강화하는 동시에, 도구별 맞춤형 인터랙션을 안전하게 제공합니다.
• Tasks 확장 (SEP-2663): 실험적 단계에서 공식 확장으로 전환된 Tasks는 tasks/get, update, cancel 수명 주기를 통해 상태 비저장 모델에서도 장기 실행 워크플로우를 최적화합니다.

가치 평가: Stateless Protocol, Stateful Applications

• 상태 관리의 패러다임 변화: 프로토콜 계층의 세션(Mcp-Session-Id)은 사라졌지만, 애플리케이션의 상태는 더욱 강력해졌습니다. 이제 서버는 basket_id와 같은 명시적 핸들(Explicit handles)을 발급하고, 모델이 이를 다음 호출의 인자로 전달하는 '모델 스레드 상태(Model-threaded state)' 방식을 취합니다. 이는 LLM이 세션 상태를 직접 추론하고 조작할 수 있게 하여 더욱 지능적인 워크플로우 구성을 가능케 합니다.
• 인프라 확장성 및 성능: 스티키 세션 제거로 일반적인 라운드 로빈 로드 밸런서 활용이 가능해졌습니다. 특히 Mcp-Method 및 Mcp-Name 헤더(SEP-2243)는 게이트웨이가 본문을 검사하지 않고도 레이어 7(L7) 라우팅을 수행하게 하여 처리 성능을 극대화합니다.
• 멀티 라운드 트립(SEP-2322): 기존의 긴 SSE 스트림 대신 InputRequiredResult 패턴을 도입했습니다. 클라이언트가 requestState를 포함하여 재요청하는 구조이므로, 어떤 서버 인스턴스라도 중단된 지점부터 작업을 재개할 수 있어 탄력적 인프라 운영이 가능합니다.
• 분산 추적성(Traceability): W3C Trace Context 전파(SEP-414)가 공식화되어 OpenTelemetry와 결합됩니다. 호스트 앱부터 MCP 서버, 하부 시스템까지의 전 과정을 단일 스팬 트리로 가시화할 수 있습니다.

규정 준수 및 프로토콜 진화 대응 전략

표준의 파편화를 방지하고 하위 호환성을 유지하기 위해 MCP는 엄격한 거버넌스 정책을 도입했습니다.

규정 준수 가이드 및 대체 경로

• 공식 지원 중단(Deprecation) 정책: 모든 기능은 Active -> Deprecated -> Removed의 수명 주기를 따르며, 최소 12개월의 유예 기간을 보장합니다.
• 기능의 현대적 디커플링(Decoupling): Roots, Sampling, Logging은 제거되는 것이 아니라 전문화된 도구로 분리됩니다. 로깅은 표준 출력이나 OpenTelemetry로, 샘플링은 LLM 제공사 API로 직접 통합하는 방식을 권장하여 각 레이어의 전문성을 높였습니다.
• 검증 체계: SDK 티어 시스템과 적합성 테스트 수트(Conformance Suite)를 통해 기업 솔루션의 안정성을 객관적으로 보장합니다.

 

2025-11-25 사양의 기술적 부채 vs 2026-07-28 개선점

기존 사양(2025-11-25)의 initialize 핸드셰이크와 Mcp-Session-Id는 대규모 확장 환경에서 치명적인 기술적 부채였습니다. 스티키 세션(Sticky Sessions)과 공유 세션 저장소는 인프라 복잡도를 가중시켰으며, 이는 곧 시스템의 단일 장애점(SPOF)으로 작용했습니다. 2026 사양은 이를 완전히 제거하고 모든 요청을 자기 완비적(Self-contained)인 무상태(Stateless) 구조로 전환하여, 표준 HTTP 인프라만으로도 무한한 확장이 가능하도록 설계되었습니다.

 

1. 미전환 시의 운영 리스크 

아키텍처 현대화를 지체할 경우 기업은 다음과 같은 리스크에 직면합니다.

• 인프라 경제성 고갈: 세션 고정(Session Pinning)으로 인한 부하 불균형과 오토스케일링 효율 저하로 인프라 비용이 기하급수적으로 증가합니다.
• 모델 지연 시간(Latency) 악화: 2026 사양의 ttlMs 기반 캐싱을 활용하지 못할 경우, 매 요청마다 반복되는 도구 검색(Discovery) 오버헤드가 사용자 경험을 저해합니다.
• 보안 및 규정 준수 결여: RFC 9207 기반의 인증 강화 사양을 충족하지 못해 엔터프라이즈 보안 감사 통과가 불가능해집니다.

2. 무상태성(Stateless) 아키텍처로의 전환 및 인프라 현대화

2026년 사양은 프로토콜 레벨의 세션을 "아키텍처적 목발"로 규정하고 이를 제거했습니다. 이제 모든 상태는 전송 계층이 아닌 모델과 페이로드 내에서 명시적으로 관리됩니다.

통신 방식의 근본적 변화와 SEP-2322 (Multi Round-Trip)

더 이상 initialize 과정은 존재하지 않습니다([SEP-2575]). 대신 서버-클라이언트 간의 복잡한 상호작용은 InputRequiredResult 패턴으로 해결합니다.

• 작동 원리: 서버가 작업 중 추가 정보가 필요하면 InputRequiredResult를 반환하고 연결을 종료합니다. 클라이언트는 필요한 입력을 수집한 후, 서버가 제공한 requestState를 에코(Echo)하며 원래의 요청을 재시도합니다.
• 이점: 서버는 요청 사이의 상태를 유지할 필요가 없으며, 재시도된 요청은 로드 밸런서에 의해 어떤 서버 인스턴스에 전달되어도 즉시 처리가 가능합니다.

3. 인프라 구성 요소 최적화

• L7 라우팅 현대화: Mcp-Method 및 Mcp-Name 헤더([SEP-2243])를 통해 페이로드 본문을 열어보지 않고도 게이트웨이 레벨에서 트래픽을 라우팅하고 Rate Limit을 적용할 수 있습니다.
• 분산 트레이싱(SEP-414): _meta 필드를 통해 W3C Trace Context를 전파하여, 호스트 앱부터 MCP 서버까지의 전 과정을 단일 스팬 트리로 시각화합니다.

 

[인프라 스택 비교표]

구분	기존 Stateful (2025)	신규 Stateless (2026)	아키텍처적 임팩트
연결 모델	initialize 세션 유지	InputRequiredResult (SEP-2322)	영구 연결 오버헤드 제거
인증	단순 토큰 방식	RFC 9207 + Dynamic Registration	엔터프라이즈 보안 등급 확보
부하 분산	L7 DPI / Sticky Session	라운드 로빈 로드 밸런싱	인프라 단순화 및 비용 절감
상태 관리	프로토콜 세션 의존	Explicit Handle (basket_id 등)	모델에 상태 제어권 반환

4. MCP 토큰 블로트(Token Bloat) 억제 및 컨텍스트 최적화 전략

대규모 도구 배치 시 도구 정의(Metadata)가 컨텍스트 윈도우의 40-50%를 점유하는 '토큰 블로트'는 모델의 지능을 저하시키는 주범입니다.

진보적 공개(Progressive Disclosure) 및 시맨틱 라우팅

모든 도구를 한꺼번에 주입하는 기존의 "뷔페식" 접근은 폐기해야 합니다.

• 인라인 도구 주입(@mention): 사용자가 특정 서버를 호출할 때만 도구 스키마를 동적으로 로드합니다.
• 시맨틱 라우터(Router Tool): 수백 개의 도구 스키마를 직접 로드하는 대신, RAG 기반의 라우터 도구 하나만 배치합니다. 에이전트의 의도를 파악하여 관련성 높은 상위 K개의 도구만 컨텍스트에 실시간 주입합니다.
• 서브에이전트 패턴: 도구 세트를 도메인별(읽기 전용, 쓰기 전용 등)로 격리된 서브에이전트에게 할당하여 개별 작업 메모리를 60% 이상 절감합니다.

5. 스키마 미니멀리즘

신규 사양의 JSON Schema 2020-12([SEP-2106]) 지원을 활용하십시오.

• 축약형 표기: 장황한 description을 모델이 이해할 수 있는 핵심 키워드로 압축합니다.
• 조건부 로딩: oneOf, anyOf를 사용하여 필요한 페이로드 구조만 선택적으로 노출함으로써 토큰 소모량을 30~50% 최적화합니다.

6. 고성능 에이전트를 위한 데이터 관리 및 지능형 캐싱 전략

무상태 구조에서 발생하는 반복 호출 비용은 지능형 캐싱과 데이터 하이진(Hygiene) 전략으로 상쇄해야 합니다.

응답 크기 최적화: Breadcrumb 패턴

RAG 트레이스와 같은 대용량 데이터 전송 시 모델이 컨텍스트를 상실하지 않도록 관리해야 합니다.

• 요약 우선(Summary First): 초기 응답에는 핵심 요약과 ID 리스트만 반환합니다.
• 계층적 탐색: 상세 데이터가 필요한 경우에만 모델이 특정 ID를 참조하여 추가 조회를 수행하게 유도합니다. 이 'Breadcrumb' 방식은 모델의 추론 공간을 깨끗하게 유지합니다.

신규 사양 기반 캐싱 (SEP-2549)

ttlMs와 cacheScope 파라미터는 2026 사양의 핵심 운영 도구입니다.

• 도구 목록 캐싱: 서버가 도구 목록의 유효 기간(ttlMs)을 지정하면 클라이언트는 매번 tools/list를 호출할 필요가 없어지며, 이는 콜드 스타트 지연 시간을 획기적으로 줄입니다.
• 시맨틱 캐싱: 동일하거나 유사한 의도의 요청에 대해 LLM 추론을 거치지 않고 캐시된 응답을 반환하여 비용을 절감합니다.

5. 엔터프라이즈급 에이전트 도구 설계: 범용성 및 자기 치유(Self-Healing)

단순히 REST API를 1:1로 래핑하는 것은 "계약이 위반되면 처벌하는" 과거의 방식입니다. 에이전트에게는 "실수를 교정하고 가르치는" 인터페이스가 필요합니다.

범용 도구(Universal Tools) 아키텍처

엔티티별로 파편화된 수십 개의 도구 대신, 다음 4가지 표준 패턴으로 통합하십시오.

1. list(entity, filters): 모든 컬렉션 조회.
2. read(entity, id): 특정 객체 상세 확보.
3. write(operation, data): Enum 기반의 쓰기 작업 통합.
4. schema(operation): 필요한 경우에만 상세 페이로드 구조 요청. 이 구조는 모델이 학습해야 할 패턴을 최소화하고, 새로운 엔티티 추가 시에도 도구 목록이 늘어나지 않게 합니다.

자기 치유(Self-Healing) 디자인

모델의 잘못된 호출에 대해 에러를 던지고 끝내는 것이 아니라, 명확한 수정 가이드를 반환하십시오. "잘못된 필드명입니다. 사용 가능한 필드는 [A, B, C]입니다"와 같은 응답을 통해 모델은 단 1턴 만에 스스로를 치유하고 작업을 완수할 수 있습니다.

코드 모드(Code Mode)로의 워크플로우 위임

자연어로 수십 번의 도구 호출을 지시하는 대신, 에이전트가 직접 워크플로우 코드를 생성하여 실행하게 하십시오. 복잡한 로직 처리를 컨텍스트 윈도우 외부(Code Execution 환경)로 격리함으로써 토큰 효율성을 극대화할 수 있습니다.

[도구 설계 Do & Don't]

• Do:
  • 범용 4대 도구 패턴을 준수하여 모델의 학습 부하를 줄이십시오.
  • InputRequiredResult를 활용해 무상태 상호작용을 구현하십시오.
  • 에러 응답에 모델이 즉시 수정 가능한 힌트를 포함하십시오.
• Don't:
  • 기존 REST API 엔드포인트를 무분별하게 1:1 미러링하지 마십시오.
  • 모델이 모든 과거 세션을 기억할 것이라 믿고 상태 식별자를 누락하지 마십시오.