에이전트 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 도구를 구축할 수 있도록 돕는 안정적인 기술적 토대를 제시하고 있습니다.

 

가장 중요한 변화는 MCP가 이제 프로토콜 계층에서 상태 비저장(stateless) 방식을 채택했다는 점입니다.

이를 위해 6개의 사양 개선 제안 (SEP)이 함께 추진되었으며, 이는 지난 12월 'MCP 전송의 미래' 에서 제시했던 계획을 완성하는 것입니다 .

 

 

프로토콜은 앞으로 어떻게 발전할까요?

이번 릴리스에는 호환성을 깨뜨리는 변경 사항이 포함되어 있습니다. 앞으로는 이런 일이 자주 발생하지 않도록 의도했습니다.

이번 릴리스에 포함된 세 가지 거버넌스 SEP는 향후 개정에서 핵심 기능을 손상시키지 않고 프로토콜을 발전시킬 수 있도록 설계되었습니다. 기능 수명 주기 정책은 모든 기능에 활성(Active ) , 사용 중단(Deprecated) , 제거(Removed)의 수명 주기를 부여하며, 사용 중단과 가장 빠른 제거 시점 사이에 최소 12개월의 간격을 둡니다. 확장 프레임워크를 통해 새로운 기능은 선택적 확장 기능으로 출시되어 안정화된 후, 필요한 경우 사양에 포함될 수 있습니다. 또한 표준 트랙 SEP는 일치하는 시나리오가 적합성 평가 도구 모음 ( SEP -2484 )에 포함될 때까지 최종(Final) 상태로 전환될 수 없으며, 이 도구 모음은 새로운 SDK 등급 시스템에서 공식 SDK를 평가하는 데 사용하는 것과 동일한 도구 모음입니다.

이번 릴리스의 스테이트리스(stateless) 재작업은 완전히 새로운 방식으로 진행되어야 했던 근본적인 변화입니다. 이번 변경 사항이 적용되었고, 향후 표준 도구로 사용 중단 알림 및 확장 기능이 제공됨에 따라, 해당 기능을 대상으로 하는 구현자는 2026-07-28전송 또는 라이프사이클 코드를 다시 작성하지 않고도 향후 개정판을 적용할 수 있을 것으로 예상합니다.

 

1. 전략적 배경: 2026년 MCP 사양 변화와 기업용 에이전트의 진화

2026년 7월 28일 확정된 Model Context Protocol(MCP) 신규 사양은 단순한 업데이트가 아닌, 에이전트 아키텍처의 패러다임 전환입니다. 지난 20년간 분산 시스템을 설계해 온 관점에서 볼 때, 이번 변화의 핵심은 '전송 계층의 세션 의존성 제거'와 '모델 중심의 상태 관리'로의 회귀입니다. 이제 기업은 기존의 RESTful 원칙을 '망각(Unlearning)'하고, 에이전트의 추론 능력에 최적화된 새로운 인터페이스 설계 원칙을 수용해야 합니다.

 

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

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

 

미전환 시의 운영 리스크 (So What?)

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

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

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

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

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

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

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

인증 및 권한 관리 강화 (Authorization Hardening)

엔터프라이즈 환경에서 가장 중요한 변화는 OAuth 2.0 및 OpenID Connect와의 긴밀한 통합입니다.

• RFC 9207 준수: 클라이언트는 인증 응답에서 iss(Issuer) 파라미터를 반드시 검증하여 믹스업(Mix-up) 공격을 방지해야 합니다([SEP-2468]).
• 동적 클라이언트 등록(SEP-837): 데스크톱 및 CLI 클라이언트는 application_type을 명시하여 로컬 호스트 리다이렉션 시의 보안 정책을 최적화합니다.

인프라 구성 요소 최적화

• 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 등)	모델에 상태 제어권 반환

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

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

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

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

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

스키마 미니멀리즘

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

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

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

무상태 구조에서 발생하는 반복 호출 비용은 지능형 캐싱과 데이터 하이진(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 미러링하지 마십시오.
  • 모델이 모든 과거 세션을 기억할 것이라 믿고 상태 식별자를 누락하지 마십시오.