MCP 2026-07-28 RC가 바꾼 에이전트 프로토콜 구조

Model Context Protocol(MCP)은 AI 에이전트와 외부 도구·데이터 소스·서비스 사이의 접점을 표준화한다. Anthropic이 2024년 11월 처음 발표한 뒤 업계 표준으로 자리 잡았고, 2026년 7월 28일 공개된 Release Candidate(RC)는 전송 계층과 상태 관리 구조를 크게 바꾸는 단일 최대 개정판으로 평가받는다.

이번 RC에는 스테이트리스 HTTP 코어 재설계, 장기 실행 작업을 위한 Tasks, UI 레이어인 MCP Apps, OAuth/OpenID Connect 인증 통합이 함께 담겼다. Linux Foundation으로 거버넌스를 이관하는 작업과 전 세계 1만 개 이상의 MCP 서버를 새 구조로 옮기는 일도 맞물려 있다.

연결을 유지하는 프로토콜에서 요청을 완결하는 프로토콜로

MCP 2026-07-28 RC도 JSON-RPC 2.0 기반 메시지 교환 구조는 유지한다. 달라지는 부분은 메시지를 운반하고 상태를 다루는 방식이다. 이전 스펙이 SSE(Server-Sent Events) 연결에 의존했다면, RC는 일반적인 HTTP 요청과 응답을 기본으로 삼고 상태가 필요한 기능을 확장 계층으로 분리한다.

모든 호환 서버가 구현해야 하는 최소 계층은 Stateless Core다. 각 호출은 단일 HTTP POST 요청으로 끝나며, 서버는 요청 사이의 클라이언트 상태를 저장할 의무가 없다. 수 분~수 시간 동안 이어지는 처리는 Tasks Extension이 맡는다. 서버가 UI 컴포넌트를 반환하는 MCP Apps와 엔터프라이즈 SSO를 위한 OAuth/OIDC 인증도 별도의 축으로 추가된다.

⤢✕

Stateless Core가 서버 운영을 단순하게 만드는 방식

이전 MCP 서버는 클라이언트와 SSE 스트림을 유지하면서 연결 상태까지 관리해야 했다. 이 구조는 로드 밸런서를 거치거나 AWS Lambda, Cloudflare Workers 같은 서버리스 플랫폼에 배포할 때 구현 복잡도를 높였다.

Stateless Core에서는 MCP 호출 하나가 HTTP POST 요청 하나로 완결된다. 서버가 다음 요청을 위해 클라이언트 상태를 보관하지 않아도 되며, 세션 정보가 필요하면 클라이언트가 요청 페이로드에 실어 보낸다. SSE 기반 스트리밍은 사라지는 대신 선택적인 Streaming Extension으로 이동한다.

그 결과 MCP 서버를 리버스 프록시, CDN, 오토스케일 그룹 등 표준 REST API에 사용하던 인프라 위에서 운영할 수 있다. Cloudflare Workers나 Vercel Edge Functions 같은 엣지 컴퓨팅 환경에도 완전한 MCP 서버를 배치할 수 있게 된다.

항목	기존 (2025)	RC (2026-07-28)
연결 방식	SSE 영구 연결	HTTP POST 단발
상태 관리	서버 세션 유지	클라이언트 보유
스케일링	스티키 세션 필요	완전 수평 확장
엣지 배포	제한적	완전 지원
스트리밍	기본 내장	선택적 확장
연결 유지 오버헤드	높음	없음

이 선택은 REST 아키텍처 스타일의 Stateless 제약과 같은 방향을 따른다. 상태를 클라이언트 쪽으로 밀어 서버를 무상태로 만들고, 클라우드 네이티브 환경에서 운영 복잡도를 낮추는 설계다.

오래 걸리는 처리는 Tasks로 분리한다

코드 컴파일, 대용량 파일 변환, 복잡한 에이전트 서브태스크는 단일 요청과 즉시 응답만으로 다루기 어렵다. Tasks Extension은 이런 장기 실행 작업을 비동기로 처리하고 상태를 추적하기 위해 도입됐다.

클라이언트가 tasks/create를 호출하면 서버는 task_id를 돌려준다. 이후 클라이언트는 tasks/get을 폴링하거나 미리 등록한 웹훅 URL로 상태를 받는다. 태스크는 pending에서 running으로 진행한 뒤 completed, failed, cancelled 가운데 하나로 끝난다. 완료 결과는 tasks/result에서 조회하거나 웹훅 페이로드로 전달받는다.

// Capability 협상 예시
{
  "capabilities": {
    "tasks": {
      "polling": true,
      "webhooks": true,
      "maxDuration": 86400
    }
  }
}

Tasks를 코어에 넣지 않은 이유는 하위 호환성에 있다. 기존 MCP 서버는 이 확장을 구현하지 않아도 계속 동작해야 한다. 클라이언트는 서버의 capabilities 응답을 확인해 Tasks 지원 여부를 협상한다.

텍스트와 JSON을 넘어 UI까지 전달하는 MCP Apps

MCP Apps는 RC에 포함된 기능 가운데 가장 실험적인 영역이다. 도구 실행 결과를 텍스트나 JSON 데이터로만 반환하지 않고, 서버가 UI 컴포넌트 트리를 만들어 클라이언트에 보내는 방식이다. Claude Desktop이나 Cursor 같은 클라이언트는 전달받은 구조를 네이티브 UI로 렌더링한다.

컴포넌트 표현은 React Server Components에서 영감을 받았다. 서버가 JSON으로 직렬화한 트리를 보내면 클라이언트가 버튼, 폼, 테이블, 차트 등을 해당 스펙에 맞춰 구성한다.

GitHub MCP 서버라면 PR 목록과 작업 버튼을 한 화면에 제공할 수 있다. 데이터베이스 서버는 쿼리 결과를 정렬 가능한 그리드로 보여주고, 캘린더 서버는 일정 선택기 UI를 직접 반환할 수 있다. 에이전트가 인터랙티브 화면까지 제공하는 셈이다.

MCP Apps는 RC에서 선택적 확장으로 분류된다. API는 2027년 정식 릴리스 전까지 변경될 수 있다.

서버마다 달랐던 인증을 OAuth/OIDC로 맞춘다

기존 스펙은 인증 구현을 각 서버에 맡겼다. 그 결과 Bearer Token, API Key, 커스텀 헤더가 서버마다 다르게 사용됐고, 하나의 에이전트가 여러 MCP 서버를 조합할수록 인증 관리가 복잡해졌다.

2026-07-28 RC는 OAuth 2.1과 OpenID Connect를 표준 인증 레이어로 채택한다. 클라이언트는 먼저 서버의 /.well-known/mcp-configuration 엔드포인트를 조회한다. 서버가 지원하는 Authorization Server URL을 반환하면 클라이언트는 PKCE가 필수인 OAuth 2.1 Authorization Code Flow를 수행한다.

발급받은 Access Token은 모든 MCP 요청의 Authorization: Bearer 헤더에 포함된다. 서버는 토큰 인트로스펙션이나 JWT 검증으로 요청을 인가한다.

기업 환경에서는 Okta, Azure AD, Google Workspace 같은 IdP를 Authorization Server와 연결해 SSO를 구성할 수 있다. 에이전트 사이의 권한 위임에는 Token Exchange(RFC 8693)를 사용할 수 있도록 스펙에 포함했다.

무상태와 상태 유지 모델의 운영 차이

비교 항목	스테이트리스 프로토콜	스테이트풀 프로토콜
서버 메모리 사용	요청 처리 중만	세션 전체 유지
수평 확장성	완전 지원	스티키 세션 또는 공유 세션 저장소 필요
연결 복구	자동 (재시도)	세션 재확립 필요
디버깅	단순 (요청 단위)	복잡 (세션 상태 추적)
지연 시간	요청별 컨텍스트 포함으로 증가 가능	연결 후 컨텍스트 생략 가능
서버리스 호환	완전	제한적
적합한 워크로드	단발성 도구 호출, CRUD	대화형 세션, 스트리밍
MCP 적용	Stateless Core (필수)	Streaming Extension (선택)

무상태 모델은 요청 단위로 관찰하고 확장하기 쉽지만, 필요한 컨텍스트가 매 요청에 포함되면서 지연 시간이 늘 수 있다. 반대로 상태 유지 모델은 연결 이후 컨텍스트를 생략할 수 있는 대신 서버가 세션을 계속 추적해야 한다. RC는 단발성 도구 호출과 CRUD에 맞는 무상태 방식을 필수 코어로 두고, 대화형 세션과 스트리밍은 선택 확장으로 남겼다.

Linux Foundation으로 이동하는 표준화 체계

Anthropic은 2026년 초 MCP 표준화를 Linux Foundation에 이관한다고 발표했다. 특정 기업이 주도하는 프로토콜에서 업계 공동 표준으로 전환하려는 결정이다.

거버넌스의 중심은 Technical Steering Committee(TSC)다. Anthropic, Microsoft, Google, AWS, Meta 등 주요 기술 기업 대표가 참여하며, 스펙 변경은 RFC(Request for Comments) 절차를 통해 제안·심의·승인한다. 의사결정 과정은 분기별 공개 TSC 미팅으로 공유한다.

버전 정책에서는 Stateless Core 인터페이스의 하위 호환성을 보장하고 최소 3년간 Breaking Change를 금지한다. Tasks와 MCP Apps 같은 확장 레이어는 별도로 버전을 관리하며, 기능을 폐기할 때는 Deprecation 공지 후 최소 12개월 동안 유지한다.

스펙 변경은 GitHub의 modelcontextprotocol/specification 공개 PR로 기여할 수 있다. Python, TypeScript, Java, Go, Rust 공식 SDK는 각각 별도 저장소에서 관리한다. MCP Compatible 배지를 위한 공식 테스트 스위트도 인증 프로그램의 일부로 제공된다.

이관이 완료되면 기업은 특정 벤더 종속에 대한 우려를 줄이고 표준 기반 구현을 선택할 수 있다. 이에 따라 엔터프라이즈 채택 속도도 빨라질 것으로 전망된다.

기존 서버 생태계가 넘어야 할 이전 구간

2026년 6월 기준 MCP 서버 레지스트리에는 약 1만 개의 서버가 등록돼 있다. 이 생태계를 2026-07-28 RC 구조로 옮기는 작업이 표준 전환의 큰 과제다.

서버 유형	이전 난이도	주요 변경 사항
단순 도구 제공 서버	낮음	HTTP 엔드포인트 추가만 필요
SSE 스트리밍 서버	중간	Streaming Extension 전환
세션 상태 의존 서버	높음	상태 관리 로직 클라이언트 이전
커스텀 인증 서버	중간	OAuth/OIDC 표준 인증으로 교체

단순 도구 서버는 HTTP 엔드포인트를 추가하는 수준이지만, SSE 스트리밍 서버는 Streaming Extension으로 전환해야 한다. 세션 상태에 의존하는 서버는 상태 관리 로직을 클라이언트로 옮겨야 하므로 난도가 높다. 자체 인증을 사용하던 서버도 OAuth/OIDC 체계에 맞춰 변경해야 한다.

Anthropic은 이전 작업을 위해 기존 서버 코드를 분석하고 필요한 변경을 제안하는 mcp-migrate CLI를 제공한다. 구 클라이언트가 신규 서버에 접속할 수 있도록 Compatibility Shim도 지원한다. Python과 TypeScript 공식 SDK에는 이전 가이드와 헬퍼 함수가 포함된다.

목표는 2026년 12월 정식 릴리스까지 상위 100개 서버가 RC 호환성을 확보하는 것이다.

아키텍처 관점에서 읽어야 할 지점

Stateless Core는 REST의 무상태 제약을 에이전트 프로토콜에 적용한 사례다. 서비스 계약을 표준화한다는 점에서는 SOA와 연결되고, 배포 구조에서는 마이크로서비스의 API Gateway 패턴과 맞닿는다.

인증 계층에는 OAuth 2.0/2.1 Authorization Code Flow, PKCE(Proof Key for Code Exchange), OpenID Connect의 ID Token과 UserInfo, Token Exchange(RFC 8693)의 위임 시나리오가 함께 등장한다.

Tasks는 Long-polling과 Webhook의 선택, Task Queue 기반 비동기 처리와 CQRS의 연계, pending → running → completed 상태 머신 관리라는 분산 시스템 문제를 드러낸다. Stateless Core와 Tasks Extension을 분리한 구조는 SoC(Separation of Concerns)가 프로토콜 설계에 적용된 사례이기도 하다.

Linux Foundation 이관은 오픈 표준, 벤더 중립성, RFC 기반 표준화가 실제 산업 프로토콜에서 어떻게 작동하는지 보여준다. 기술 구조뿐 아니라 거버넌스가 상호운용성과 기업 채택에 미치는 영향까지 함께 볼 필요가 있다.

RC 이후의 관건

MCP 2026-07-28 RC는 에이전트 인프라를 연결 중심 구조에서 요청 중심 구조로 옮긴다. Stateless Core는 클라우드 네이티브 환경에서 서버 운영을 단순화하고, Tasks는 복잡한 에이전트 작업을 비동기 방식으로 다룬다. MCP Apps는 결과 표현 범위를 UI까지 넓히며, OAuth/OIDC는 기업 인증 체계와의 접점을 표준화한다.

Linux Foundation 이관으로 MCP는 특정 벤더의 프로토콜을 넘어 HTTP나 OAuth 같은 인터넷 인프라의 기초 계층을 지향한다. 2026년 12월 정식 릴리스와 기존 서버 생태계의 호환성 확보가 그 방향을 실제 표준으로 굳힐 분기점이 될 전망이다.