사내 에이전트를 몇 개 업무에 붙여 본 조직은 이미 같은 벽을 만났다. 데모에서는 툴 호출이 된다. 현업 파일도 읽고, 내부 API도 친다. 그런데 운영으로 넘기려는 순간 게이트웨이, 인증, 세션, 감사 로그, 장기 작업, UI 승인 흐름이 한꺼번에 엉킨다.
MCP 2026-07-28 Release Candidate는 이 엉킴을 우회하지 않는다. 오히려 정면으로 드러낸다. 공식 RC는 2026년 5월 21일 잠겼고, 최종 사양은 2026년 7월 28일 공개 예정이라고 명시했다. 핵심은 stateless core, Extensions, Tasks, MCP Apps, OAuth/OIDC 정합성, deprecation policy다.
세션을 없애면 책임 위치가 보인다
이전 MCP 운영의 난점은 세션이 숨어 있었다는 점이다. Streamable HTTP 위에서 initialize를 하고 Mcp-Session-Id를 들고 다니면, 운영팀은 결국 sticky session, 공유 session store, 본문 검사 라우팅을 떠안는다.
2026 RC는 initialize/initialized handshake와 protocol-level session을 제거한다. MCP-Protocol-Version, Mcp-Method, Mcp-Name, _meta가 요청마다 들어간다. 요청 하나가 자기 설명적이어야 한다.
stateless core의 의미는 “상태가 없다”가 아니라 “상태를 프로토콜 뒤에 숨기지 말라”다.
사내 툴 레이어는 이 기준으로 다시 나눠야 한다.
| 영역 | 기존 관성 | RC 이후 설계 기준 |
|---|---|---|
| 사용자 맥락 | 세션에 보관 | 명시적 handle 또는 권한 토큰으로 전달 |
| 라우팅 | 연결 또는 본문 검사 | Mcp-Method, Mcp-Name 헤더 기준 |
| 캐시 | 클라이언트별 임시 판단 | ttlMs, cacheScope 기준 |
| 추적 | 서버 로그 수집 | W3C Trace Context와 OpenTelemetry 연계 |
이 표가 마이그레이션의 출발점이다. 코드 호환성보다 먼저 운영 책임 경계를 다시 그어야 한다.
Tasks는 장기 작업의 계약이다
사내 업무에는 즉시 끝나지 않는 작업이 많다. 보고서 생성, 대량 조회, 승인 대기, 배치 실행, 외부 시스템 반영은 툴 호출 하나로 끝나지 않는다. 기존처럼 연결을 붙잡고 기다리는 방식은 운영 장애를 만든다.
RC에서 Tasks는 core가 아니라 extension으로 재배치됐다. 서버는 tools/call에 대해 task handle을 돌려주고, 클라이언트는 tasks/get, tasks/update, tasks/cancel로 생명주기를 민다. tasks/list는 세션 없이 안전하게 scope를 잡기 어렵기 때문에 제거됐다.
따라서 마이그레이션 기준은 단순하다.
- 3초 안에 끝나는 조회성 호출은 일반 tool로 둔다.
- 외부 job ID가 생기는 작업은 처음부터 Task로 감싼다.
- 사람 승인이나 추가 입력이 필요한 흐름은 Task와 elicitation을 분리한다.
- 취소는 자체 플래그가 아니라
tasks/cancel계약으로 맞춘다.
AX Ops 관점에서는 여기서 운영 지표도 바뀐다. tool 성공률만 보면 안 된다. task 생성, 진행 상태 갱신, 사용자 입력 대기, 취소, 최종 결과 회수까지 한 사이클로 봐야 한다.
MCP Apps와 OAuth는 같은 통제면이다
MCP Apps는 서버가 interactive HTML UI를 제공하고 host가 sandboxed iframe에서 렌더링하는 확장이다. 이것은 예쁜 화면 문제가 아니다. 승인, 비교, 편집, 예외 처리처럼 텍스트 대화만으로 위험한 조작을 통제면 안으로 끌어오는 방식이다.
하지만 UI가 붙는 순간 보안 경계도 넓어진다. 공식 MCP Apps 문서는 per-server authorization과 per-tool authorization을 구분한다. 민감한 서버는 모든 요청에 Bearer token을 요구한다. 일부 tool만 민감하면 JSON-RPC 본문에서 protected tool 호출 여부를 검사하고, HTTP boundary에서 401을 반환한다. tool 내부 에러로 인증을 처리하지 않는다.
OAuth 하드닝은 네 가지를 체크리스트로 박아야 한다.
- Protected Resource Metadata와 authorization server discovery를 구현한다.
- authorization response의
iss를 검증하고 issuer에 client credential을 묶는다. - token 요청에
resourceparameter를 넣고, 서버는 audience를 검증한다. - access token은 Authorization header로만 보내며 query string에 넣지 않는다.
최근 MCP 보안 논문들은 tool description poisoning, indirect prompt injection, dynamic trust violation 같은 semantic attack surface를 반복해서 지적한다. 그래서 OAuth는 로그인 기능이 아니다. agent가 어떤 tool을 어떤 resource 권한으로 호출했는지 감사 가능한 형태로 고정하는 장치다.
참고와 다음 행동
이번 마이그레이션은 SDK 버전 업그레이드 티켓으로 처리하면 실패한다. AX Ops에서는 먼저 툴 레이어 인벤토리를 만들고, 각 tool을 네 축으로 분류한다. stateless 가능 여부, Task 필요 여부, MCP Apps UI 필요 여부, OAuth scope와 resource 경계다. 그 다음 gateway, client, server, 관측 체계를 같은 sprint 안에서 맞춘다.
참고:
- Model Context Protocol Blog, “The 2026-07-28 MCP Specification Release Candidate”, 2026: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
- Model Context Protocol Draft Authorization, 2026 draft: https://modelcontextprotocol.io/specification/draft/basic/authorization
- MCP Apps Authorization, 2026: https://apps.extensions.modelcontextprotocol.io/api/documents/authorization.html
- MCP Tasks overview, 2026: https://modelcontextprotocol.io/extensions/tasks/overview
- “MCP-38: A Comprehensive Threat Taxonomy for Model Context Protocol Systems”, arXiv, 2026: https://arxiv.org/abs/2603.18063
지금 할 일은 명확하다. 사내 에이전트의 툴 목록을 기능 목록이 아니라 운영 계약 목록으로 다시 작성하라. 다음 단계는 AX Ops 기준으로 함께 설계한다. AX Ops 방법론 →