MCP 2026 로드맵, 스테이트리스 코어와 Tasks·OAuth/OIDC로 향하는 표준화

MCP(Model Context Protocol)는 창안 이후 가장 큰 폭의 아키텍처 개정을 앞두고 있다. 스테이트리스(stateless) 코어 설계, Tasks 확장을 통한 장기 비동기 작업 지원, OAuth/OIDC 기반 인증 표준화, MCP Apps 서버사이드 렌더링 UI 프레임워크가 이번 로드맵의 네 축이다. 기존 sticky 세션·공유 세션에 의존하던 구조를 벗어나면 라운드로빈 로드밸런싱이 가능해지고, 엔터프라이즈 환경이 요구하는 수평 확장성과 고가용성을 함께 챙길 수 있게 된다.

서버가 늘어난 뒤 드러난 한계

MCP는 2024년 Anthropic이 공개한 뒤 빠르게 생태계를 넓혀왔다. Linux Foundation으로 이관돼 벤더 중립 표준으로 자리잡은 뒤 10,000개 이상의 MCP 서버가 등록됐지만, 기존 설계에는 명확한 한계가 셋 있었다.

첫째는 세션 의존성이다. MCP는 SSE(Server-Sent Events) 기반 전송으로 서버·클라이언트 간 상태를 세션 단위로 관리했는데, 그러다 보니 동일 클라이언트의 요청이 반드시 같은 서버 인스턴스로 가야 하는 sticky 세션이 필수였다. 둘째는 장기 작업 처리의 부재다. AI 에이전트가 수 분에서 수 시간씩 실행하는 태스크를 프로토콜 레벨에서 추적·재개·취소할 표준 메커니즘이 없었다. 셋째는 인증 파편화다. 서버마다 독자적인 인증 방식을 구현해 상호운용성이 낮았고, 엔터프라이즈 IdP(Identity Provider) 연동이 복잡했다. MCP 2026 로드맵은 이 세 가지를 한 번에 겨냥한다.

서버가 아무것도 기억하지 않는다면

스테이트리스 코어는 이번 로드맵에서 가장 근본적인 변화다. 서버 인스턴스가 클라이언트별 세션 상태를 메모리에 들고 있지 않고, 모든 요청이 독립적으로 처리된다.

설계 원칙은 세 가지로 요약된다. 클라이언트는 요청 페이로드 안에 처리에 필요한 모든 컨텍스트를 담아 보내는 요청 자급자족(Request Self-Containment)을 지키고, 세션 상태가 필요하면 Redis·DynamoDB 같은 분산 캐시에 저장해 어느 서버 인스턴스에서든 조회할 수 있게 하며, 동일 요청 ID로 재시도해도 부작용 없이 같은 결과를 돌려주는 멱등성(Idempotency)을 보장한다.

sticky 세션이 사라지면 Kubernetes HPA(Horizontal Pod Autoscaler), AWS ALB 라운드로빈, Nginx upstream 같은 표준 인프라를 그대로 붙일 수 있다. 서버 인스턴스를 자유롭게 늘리고 줄일 수 있어 트래픽이 갑자기 몰려도 무중단으로 확장할 수 있다는 뜻이다.

⤢✕

수 시간짜리 작업을 프로토콜이 직접 다룬다

Tasks 확장은 장기 실행 작업을 위한 표준 라이프사이클을 MCP 프로토콜에 추가한다. 기존의 단일 요청-응답 사이클로는 다룰 수 없던 수 분~수 시간 단위 에이전트 태스크를 이제 프로토콜 레벨에서 처리할 수 있다.

태스크는 등록돼 실행을 기다리는 pending, 에이전트가 실행 중이며 진행률을 스트리밍할 수 있는 running, 사람 확인(Human-in-the-Loop) 대기나 리소스 제한으로 멈춘 paused, 성공적으로 끝나 결과를 쓸 수 있는 completed, 오류가 나서 재시도할 수 있는 failed, 클라이언트 요청이나 타임아웃으로 취소된 cancelled까지 여섯 상태를 거친다.

이 라이프사이클은 네 가지 엔드포인트로 표준화된다. 새 태스크를 만들고 task_id를 받는 POST /tasks, 현재 상태·진행률을 조회하는 GET /tasks/{task_id}, 태스크를 취소하는 DELETE /tasks/{task_id}, SSE 스트림으로 실시간 진행 이벤트를 구독하는 GET /tasks/{task_id}/events다.

네트워크가 끊기거나 서버가 재시작돼도 작업을 이어갈 수 있도록, 체크포인트 스냅샷을 분산 저장소에 저장해둔다. 클라이언트는 resume_token을 들고 재연결하면 중단 지점부터 다시 시작할 수 있다. Kubernetes Pod가 재스케줄되거나 스팟 인스턴스가 교체되는 상황에서도 작업 연속성을 지켜주는 엔터프라이즈급 기능이다.

API 키에서 OAuth 2.1 + OIDC로

MCP 2026은 OAuth 2.1과 OIDC(OpenID Connect)를 프로토콜 레벨에서 통합해 인증·인가를 표준화한다. 기존에는 API 키 방식이 주를 이뤄 세밀한 권한 제어가 어려웠는데, 새 구조에서는 토큰 기반 흐름을 따른다. 클라이언트가 Authorization Server에 PKCE 코드 챌린지를 포함한 인가 요청을 보내고, 사용자 동의 후 Authorization Code를 받는다. 이 코드로 Access Token(JWT)과 Refresh Token을 발급받아 MCP 요청 헤더에 Authorization: Bearer <token>을 담아 보내면, MCP 서버는 JWKS 엔드포인트에서 공개키를 조회해 JWT 서명을 검증한다. 토큰이 만료되면 Refresh Token으로 자동 갱신된다.

권한은 스코프 단위로 세밀하게 나뉜다.

mcp:tools:read        — 도구 목록 조회
mcp:tools:execute     — 도구 실행
mcp:resources:read    — 리소스 읽기
mcp:resources:write   — 리소스 쓰기
mcp:tasks:create      — 태스크 생성
mcp:tasks:manage      — 태스크 수정·취소

Okta, Azure AD, Google Workspace 같은 기업 IdP와의 OIDC 연동도 표준화된다. IT 부서는 기존 AD 그룹 정책을 MCP 스코프에 매핑해 세밀한 접근 제어를 구현할 수 있다.

데이터가 아니라 화면을 반환하는 MCP Apps

MCP Apps는 MCP 서버가 단순한 데이터 API를 넘어 렌더링된 UI 컴포넌트를 돌려줄 수 있게 하는 프레임워크다. 에이전트가 데이터 조회 결과를 구조화된 카드·폼·인터랙티브 위젯 형태로 내놓으면 사용자 경험이 크게 달라진다. MCP 서버는 요청을 처리한 뒤 마크다운이나 JSON 구조체가 아니라 렌더러블 컴포넌트 스펙을 반환하고, Claude Desktop이나 웹 앱 같은 클라이언트가 이를 네이티브 UI로 렌더링한다. 이를 통해 대화형 대시보드, 폼 입력, 승인 버튼 같은 풍부한 상호작용이 가능해진다.

단번에 바꾸지 않는다 — 단계적 마이그레이션

기존 MCP 서버를 2026 스펙으로 옮길 때는 단계적 접근이 권장된다.

1단계는 상태 분리(State Externalization)다. 서버 메모리에 저장된 세션 상태를 Redis 같은 외부 저장소로 옮긴다. 코드 변경 범위가 세션 읽기/쓰기 로직에 국한되므로, 프로토콜 변경 없이 이 작업부터 먼저 끝낼 수 있다.

2단계는 Tasks 확장 도입이다. 장기 실행 도구 호출을 Tasks API로 감싸는데, 기존 동기 도구는 호환성을 유지한 채 신규 장기 작업만 Tasks 엔드포인트로 노출하면 되므로 점진적 전환이 가능하다.

3단계는 OAuth/OIDC 인증 적용이다. API 키 인증을 OAuth 2.1로 바꾸되, 먼저 개발·스테이징 환경에서 토큰 검증 로직을 검증한 뒤 프로덕션에 올린다. 기존 클라이언트를 위한 API 키 하위 호환성은 전환 기간 동안 유지한다.

4단계는 수평 확장 설계 완성이다. 스테이트리스 전환이 끝난 뒤 라운드로빈 로드밸런서를 전면 적용하고, Kubernetes HPA 정책으로 CPU/메모리 임계값 기반 자동 스케일링을 켠다.

각 단계가 실제로 끝났는지는 다음 항목으로 검증할 수 있다.

항목	검증 방법
세션 상태 외부화 완료	동일 요청을 다른 인스턴스로 라우팅 후 일관성 확인
멱등성 보장	동일 `request_id`로 재시도 시 중복 처리 없음 확인
Tasks 라이프사이클	태스크 중단 후 재개 시 체크포인트 복원 확인
JWT 검증	만료·위변조 토큰 거부, JWKS 캐싱 동작 확인
라운드로빈 LB	sticky 없이 다수 인스턴스 분산 처리 확인

스테이트리스가 항상 정답은 아니다

스테이트리스 코어와 기존 WebSocket 세션 기반 통신을 나란히 놓으면 트레이드오프가 뚜렷해진다.

비교 항목	MCP 2026 스테이트리스	WebSocket 세션 기반
수평 확장	라운드로빈 표준 LB 적용 가능	Sticky 세션 필수, 확장 복잡
서버 재시작 영향	무중단(상태는 외부 저장)	세션 끊김, 클라이언트 재연결 필요
지연(Latency)	약간 높음(상태 저장소 조회)	낮음(메모리 직접 접근)
인프라 복잡도	분산 캐시 필요	단순(단일 인스턴스 시)
장애 복구	자동(요청 재라우팅)	수동 개입 또는 별도 HA 구성
엔터프라이즈 적합성	높음	규모 증가 시 낮아짐

스테이트리스 방식은 초기 구성 복잡도가 높지만, 트래픽이 늘어날수록 운영 비용과 안정성 면에서 우위가 뚜렷해진다.

Tasks 확장을 LangChain의 AgentExecutor와 비교해도 성격 차이가 드러난다.

비교 항목	MCP Tasks 확장	LangChain AgentExecutor
표준화 수준	프로토콜 레벨 표준	프레임워크 레벨(LangChain 종속)
체크포인트/재개	기본 지원	별도 구현 필요
취소(Cancellation)	`DELETE /tasks/{id}` 표준 API	스레드 인터럽트 등 구현 의존적
진행률 스트리밍	SSE 표준 이벤트	콜백 방식(구현 다양)
멀티 벤더 호환	모든 MCP 호환 클라이언트	LangChain 생태계 내부
Human-in-the-Loop	`paused` 상태 기본 지원	별도 인터럽트 메커니즘

MCP Tasks는 특정 프레임워크에 묶이지 않는 표준 인터페이스라는 점에서, 멀티 벤더 환경이나 장기적인 생태계 확장을 고려하는 엔터프라이즈에 유리하다.

MCP 2026 로드맵은 단순한 기능 추가가 아니라 프로토콜의 근본적인 재설계다. 스테이트리스 코어로 엔터프라이즈 확장성을 확보하고, Tasks 확장으로 장기 에이전트 워크플로우를 표준화하며, OAuth/OIDC 통합으로 보안 체계를 다진다. 기존 MCP 서버를 운영 중인 팀이라면 단계별 마이그레이션 계획을 세워 서비스 중단 없이 전환하는 편이 낫고, 신규 구축이라면 처음부터 스테이트리스 설계 원칙을 적용하는 쪽이 2026년 엔터프라이즈 AI 인프라의 표준 방향에 가깝다.