MCP 2026-07-28: 스테이트리스 프로토콜이 B2B 에이전트 배포에 의미하는 것

이 릴리스가 배포 계산법을 바꾸는 이유

모델 컨텍스트 프로토콜(MCP)은 AI 에이전트를 외부 시스템에 연결하기 위한 개방형 표준입니다. 2026년 7월 28일, MCP는 출시 이후 가장 큰 개정판을 배포합니다 — 프로토콜 계층을 스테이트리스로 만들고, 일급 확장을 도입하며, 프로덕션에서 그 복잡성만큼의 가치를 하지 못한 세 가지 기능을 폐기하는 최종 사양입니다.

B2B 에이전트 시스템 뒤에 MCP 서버를 배포하는 팀에게 실질적인 영향은 구체적입니다: 더 이상 스티키 세션, 공유 세션 스토어, 또는 세션 인식 로드 밸런서가 필요 없습니다. 에이전트가 여러 도구 호출에 걸쳐 필요로 하는 상태는 명시적 핸들이 됩니다 — 모델에게 보이고, 로그에서 감사 가능하며, 중개자가 캐시할 수 있습니다. 이 글은 B2B 배포에 중요한 변경 사항과 그것이 우리가 이미 출시하는 MCP 모듈 패턴에 어떻게 매핑되는지를 살펴봅니다.

스테이트리스 프로토콜 계층

핵심 변경 사항: initialize / initialized 핸드셰이크와 Mcp-Session-Id 헤더가 제거됩니다. 이제 요청은 자체 완결적입니다. 프로토콜 버전, 클라이언트 정보, 역량은 서버가 기억해야 하는 협상된 세션이 아니라 모든 요청의 _meta에 담겨 이동합니다.

이것이 B2B 배포에서 제거하는 것:

• 스티키 세션 로드 밸런서. 원격 MCP 서버는 평범한 라운드 로빈 로드 밸런서 뒤에 위치할 수 있습니다. 요청을 해석하는 데 서버 측 상태가 필요 없으므로 어떤 서버 인스턴스도 어떤 요청이든 처리할 수 있습니다.
• 공유 세션 스토어. 오늘날 수평으로 확장한다면, 모든 MCP 서버 인스턴스는 동일한 세션 상태에 접근해야 합니다 — 일반적으로 Redis 또는 데이터베이스입니다. 스테이트리스 프로토콜은 그 의존성을 제거합니다.
• 세션 재생 인프라. 워크플로 중간에 세션이 끊어지면, 클라이언트는 다시 초기화하고 컨텍스트를 재확립해야 합니다. 스테이트리스 프로토콜에는 끊어질 세션이 없습니다; 모든 요청이 필요한 것을 담고 있습니다.

배포 형태는 더 단순해집니다: 로드 밸런서 뒤의 스테이트리스 MCP 서버 인스턴스 풀, 그 사이에 공유 상태 계층이 없습니다. 이는 여느 스테이트리스 HTTP API와 동일한 형태입니다 — 검증되고, 관측 가능하며, 확장이 저렴합니다.

상태 저장 워크플로를 위한 명시적 핸들 패턴

스테이트리스는 상태가 사라진다는 뜻이 아닙니다. 여러 도구 호출에 걸치는 워크플로 — RFQ 접수, 견적 협상, 재고 홀드 — 는 여전히 연속성이 필요합니다. 최종 사양는 숨겨진 세션 상태를 명시적 핸들 패턴으로 대체합니다: 도구가 핸들(order_id, quote_id, basket_id)을 발행하고 모델은 이후 호출에서 이를 일반 인자로 다시 전달합니다.

이는 세 가지 이유로 B2B 배포에 의미 있는 전환입니다.

상태가 모델에게 보입니다. 오늘날 세션 상태는 LLM이 결코 보지 못하는 전송 메타데이터에 존재합니다. 명시적 핸들을 사용하면 모델은 자신의 추론에서 핸들을 보유하고 참조합니다. 모델이 get_quote(quote_id="q-7f3a")를 호출할 때, 자신이 어떤 견적에 대해 작동하고 있는지 압니다. 이는 다단계 워크플로에서 도구 선택 정확도를 향상시킵니다.

상태가 로그에서 감사 가능합니다. 모든 요청은 애플리케이션 로거가 제거하는 헤더가 아니라 요청 본문에 핸들을 담고 있습니다. 감사 추적은 요청 인자를 읽음으로써 어느 시점에서든 전체 워크플로 상태를 재구성할 수 있습니다 — 세션 스토어 로그와의 상관 관계가 필요 없습니다.

상태가 중개자에 의해 캐시 가능합니다. 핸들이 요청의 일부이기 때문에, 게이트웨이 또는 캐시 계층이 이를 키로 삼을 수 있습니다. 목록 및 리소스 결과는 ttlMs와 cacheScope 필드를 담고 있어, 안정적인 핸들을 가진 카탈로그 쿼리는 업스트림 시스템에 도달하지 않고 캐시에서 제공될 수 있습니다.

이것이 RFQ 워크플로에 어떻게 매핑되는가

다섯 개의 도구 호출에 걸쳐 실행되는 견적 워크플로를 생각해 봅시다: 요청 생성, 카탈로그 검색, 견적 생성, 재고 홀드, 가격 티어 적용. 세션 기반 프로토콜에서는 이 다섯 호출이 서버 측 세션을 공유합니다. 명시적 핸들 패턴에서는:

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

모든 호출은 자신이 필요로 하는 핸들을 담고 있습니다. 어떤 서버도 호출 사이에 아무것도 기억하지 않습니다. 로드 밸런서가 호출 4를 호출 3과 다른 인스턴스로 라우팅하더라도 여전히 작동합니다 — 핸들이 요청 안에 있기 때문입니다. 감사 팀이 일주일 후에 이 워크플로를 재구성해야 한다면, 요청 인자 안의 핸들이 전체 이야기를 들려줍니다.

확장: 일급이며 독립적으로 버전 관리됨

최종 사양는 **확장(extensions)**을 일급 개념으로 도입합니다. 확장은 역방향 DNS 식별자(예: com.example.workflow)를 얻고, 자체 ext-* 저장소를 소유하며, 위임된 유지 관리자를 두고, 코어 프로토콜과 독립적으로 버전 관리됩니다.

첫 두 개의 확장은 구체적입니다:

• MCP Apps — 샌드박스화된 iframe으로 전달되는 서버 렌더링 HTML UI. MCP 서버는 클라이언트가 렌더링하는 UI를 제공하여, 클라이언트가 커스텀 프론트엔드를 구축하지 않고도 휴먼 인 더 루프 승인 화면을 가능하게 합니다.
• Tasks — 태스크 핸들을 사용하는 장기 실행 작업. 도구는 몇 분 동안 연결을 열어 두는 대신 태스크 핸들을 즉시 반환하고 클라이언트는 완료를 폴링할 수 있습니다.

B2B 배포에서 MCP Apps는 에이전트가 진행하기 전에 사람이 트랜잭션을 승인해야 하는 경우에 중요합니다 — 임계값을 초과하는 구매 주문, 비표준 할인이 있는 견적. 승인 화면은 별도의 프론트엔드를 요구하는 대신 MCP 모듈과 함께 제공될 수 있습니다. Tasks는 단일 요청 타임아웃을 초과하는 워크플로에 중요합니다: 생성하는 데 90초가 걸리는 공급업체 견적, 몇 분 동안 실행되는 카탈로그 동기화.

폐기: Roots, Sampling, Logging

세 가지 기능이 폐기됩니다(12개월 동안 주석 전용; 제거는 별도의 표준 프로세스가 필요):

• Roots → 도구 매개변수와 리소스 URI로 대체됩니다. Roots는 클라이언트가 서버에 파일시스템 위치를 알려주는 방법이었습니다; 동일한 의도가 이제 파일을 읽는 도구에 대한 인자로 표현됩니다.
• Sampling → 직접적인 LLM 공급자 API 통합으로 대체됩니다. LLM 호출이 필요한 서버는 클라이언트에게 샘플링 왕복을 수행하도록 요청하는 대신, 공급자에게 직접 호출합니다.
• Logging → stderr와 OpenTelemetry로 대체됩니다. 서버 로깅은 MCP 로깅 채널이 아니라 표준 프로세스 출력과 분산 추적으로 이동합니다.

Logging의 폐기는 B2B 배포에 가장 관련이 깊습니다. 모든 도구 호출이 요청, 응답, 지연 시간, 결과를 로깅하는 감사 로깅 패턴이 이제 프로토콜별 로깅 채널이 아니라 OpenTelemetry에 맞춰집니다. 이는 MCP 서버 로그가 커스텀 전송 없이 기존 관측 가능성 파이프라인(Datadog, CloudWatch, Honeycomb)과 통합됨을 의미합니다.

라우팅 가능, 캐시 가능, 추적 가능

프로덕션 운영에 영향을 미치는 세 가지 추가 사항:

• Mcp-Method와 Mcp-Name 헤더는 본문 검사 없이 게이트웨이 라우팅을 가능하게 합니다. 게이트웨이는 헤더 수준에서 메서드와 도구 이름으로 라우팅할 수 있습니다 — 라우팅 계층에서 JSON 파싱이 없습니다.
• **목록/리소스 결과의 ttlMs와 cacheScope**는 중개자에게 표준 캐싱 계약을 제공합니다. 카탈로그 목록 응답은 5분 TTL을 선언할 수 있고, 경로상의 어떤 게이트웨이도 이를 준수할 수 있습니다.
• W3C Trace Context 전파가 OpenTelemetry 호환성을 위해 문서화됩니다. 에이전트 클라이언트가 시작한 추적이 MCP 서버를 거쳐 업스트림 시스템 호출로 전파되므로, 단일 RFQ 워크플로가 그것이 닿는 모든 시스템에 걸쳐 하나의 추적으로 나타납니다.

NetSuite, HubSpot, 공급업체 카탈로그를 위한 MCP 서버를 실행하는 B2B 배포에서, 이는 다음을 의미합니다: 게이트웨이가 본문을 파싱하지 않고 도구 이름으로 라우팅하고, 선언된 TTL 동안 카탈로그 응답을 캐시하며, 단일 견적 요청을 에이전트에서 ERP로, 공급업체 API로 하나의 스팬 트리로 추적할 수 있습니다.

일대다 형태를 위한 인증 강화

최종 사양는 B2B 에이전트 시스템이 실제로 사용하는 배포 형태를 위해 OAuth와 OpenID Connect를 개선합니다: 하나의 클라이언트(에이전트)가 여러 서버(NetSuite, HubSpot, BigCommerce, 공급업체 카탈로그)에 연결하는 형태입니다. 토큰 갱신, 스코프 관리, 다중 서버 자격 증명 처리가 각 통합이 독립적으로 해결하도록 남겨지는 대신 사양에서 다뤄집니다.

이것이 중요한 이유는 B2B 에이전트 시스템이 하나의 시스템에 연결되지 않기 때문입니다. 전형적인 RFQ 에이전트는 ERP(NetSuite), CRM(HubSpot), 이커머스 플랫폼(BigCommerce), 그리고 두세 개의 공급업체 카탈로그에 연결되며 — 각각 자체 OAuth 흐름, 토큰 수명, 스코프 세트를 가집니다. 이제 프로토콜은 각 MCP 모듈이 자체 자격 증명 수명 주기를 구현하는 대신 그 복잡성을 관리하기 위한 표준 패턴을 제공합니다.

Update — 2026-08-06: Terraform MCP CVE-2026-16496 (CVSS 10.0) — the stateless thesis validated in production

HashiCorp patched CVE-2026-16496 (CVSS 10.0) in Terraform MCP Server before version 1.1.0 — the first maximum-severity CVE in the MCP ecosystem. The vulnerability is an authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This CVE is the first production evidence that the stateful transport mode is a security liability, not just an operational complexity — and it validates the core thesis of this article. The stateless protocol layer the July 28 final specification introduced exists precisely to eliminate the server-side session state that this attack exploits. The attack vector (session-ID theft leading to credential reuse) exists only because the server holds a session state that an attacker can steal and reuse. A stateless server has no session to steal. The explicit-handle pattern this article describes — where stateful workflows mint handles that travel in the request body, not in a server-side session — is the architecture that closes this vulnerability class. The vulnerability affects only the stateful streamable-HTTP transport mode; the stateless protocol core is not affected.

For B2B deployments, the implication is direct: if your MCP servers run stateful streamable-HTTP with Mcp-Session-Id, they carry the session-hijacking attack surface that CVE-2026-16496 exploits. Migrating to the stateless protocol core (Control 1 in the MCP Security Hardening Checklist) eliminates the attack surface at the architecture level, not the patch level. The 12-month SSE deprecation window is now a security deadline, not just an operational one.

보안: 세 가지 새로운 공격 표면과 심층 방어 데이터 포인트

스테이트리스 재설계는 최종 사양 공개 당일 backslash.security의 분석에서 식별된 세 가지 새로운 공격 표면을 도입합니다:

• 핸들 하이재킹. 명시적 핸들은 서버 측 세션 상태를 대체하지만, 핸들은 일반 인자입니다. 핸들 공간이 예측 가능하거나 전송에 무결성 보호가 없는 경우, 핸들을 관찰하거나 추측한 공격자가 이를 자신의 요청에 주입할 수 있습니다 — 워크플로 소유자를 가장합니다. 해결책은 암호학적 핸들 생성(무작위, 추측 불가)과 요청 본문뿐만 아니라 인증된 호출자에게 핸들을 바인딩하는 것입니다.
• 파일시스템 범위 간격. Roots 폐기로 인해 클라이언트 측 파일시스템 경계 선언이 제거됩니다. 파일을 읽는 도구는 이제 경로를 인자로 받지만, Roots 경계가 없으면 도구가 클라이언트가 노출할 의도가 없었던 파일시스템 위치에 접근할 수 있습니다. 해결책은 더 이상 존재하지 않는 프로토콜 수준 경계에 의존하는 것이 아니라, 도구별 경로 검증입니다.
• MCP Apps HTML 렌더링. MCP Apps 확장은 서버가 샌드박스 iframe에서 HTML UI를 제공할 수 있게 합니다. 샌드박스는 보안 경계이지만, HTML 콘텐츠는 서버에서 옵니다 — 손상되거나 악의적인 MCP 서버는 샌드박스를 탈출하거나 사용자에게 피싱을 시도하는 UI를 제공할 수 있습니다. 해결책은 MCP Apps HTML을 신뢰할 수 없는 콘텐츠로 취급하는 것입니다: 엄격한 Content Security Policy, same-origin 접근 없음, 새 서버의 앱 서피스를 렌더링하기 전 사용자 확인.

심층 방어 데이터 포인트: Auto Mode가 활성화된 Claude Opus 5는 129개 테스트 시나리오에서 0%의 브라우저 기반 프롬프트 인젝션 공격 성공률을 달성했습니다 — 브라우저 에이전트 프롬프트 인젝션을 0으로 줄일 수 있다는 첫 번째 구체적 데이터 포인트입니다. Auto Mode는 입력 계층 프롬프트 인젝션 프로브와 출력 계층 액션 분류기를 결합합니다. 브라우저 에이전트가 MCP 도구를 호출하는 스테이트리스 MCP 배포에서, 입력 스캐닝 + 태스크 차단 패턴은 프로토콜의 스테이트리스 설계가 시행을 더 쉽게 만드는 심층 방어의 구체적 구현입니다: 각 요청은 자체 포함형이며, 프로브와 분류기는 각 요청에서 독립적으로 작동하고, 손상될 세션 상태가 없습니다.

기존 MCP 모듈에 대해 무엇이 바뀌는가

이미 MCP 모듈을 출시했다면 — 예를 들어, 도구가 MCP_CONFIGURATION을 통해 등록되고 도메인 믹스인이 공유 GraphQL 클라이언트 위에 구성되는 38개 도구 RFQ 프로세서 패턴 — 스테이트리스 프로토콜은 모듈 코드가 아니라 배포를 변경합니다.

모듈의 도구 등록, 입출력 스키마, 속도 제한, 감사 로깅은 동일하게 유지됩니다. 바뀌는 것:

• 시작 시 세션 초기화 없음. 모듈은 initialize 핸드셰이크에 참여하지 않습니다. 프로토콜 버전과 역량을 담은 _meta와 함께 요청을 받고 응답합니다.
• 상태 저장 도구가 핸들을 발행합니다. 오늘날 어떤 도구가 다단계 워크플로를 추적하기 위해 서버 측 세션에 의존한다면, 명시적 핸들을 발행하여 반환해야 합니다. 클라이언트는 다음 호출에서 이를 다시 전달합니다. RFQ 프로세서의 경우, request_id, quote_id, hold_id가 이미 핸들입니다 — 이 패턴은 도메인에 자연스럽습니다.
• 로깅이 OpenTelemetry로 이동합니다. 모듈이 MCP 로깅 채널을 통해 로깅한다면, stderr와 OpenTelemetry 스팬으로 마이그레이션하세요. 감사 내용(요청, 응답, 지연 시간, 결과)은 유지되고; 전송이 바뀝니다.
• 캐싱이 선언적입니다. 목록 및 리소스 엔드포인트는 응답에 ttlMs와 cacheScope를 선언하여, 중개자가 추측 없이 캐시할 수 있게 합니다.

B2B 팀을 위한 결론

스테이트리스 프로토콜은 MCP 기반 에이전트 배포가 요구하는 인프라를 줄입니다. 스티키 세션과 공유 세션 스토어를 요청 인자 안의 명시적 핸들과 맞바꾸게 됩니다 — 시스템을 더 쉽게 확장하고, 더 쉽게 감사하며, 표준 도구에서 더 관측 가능하게 만드는 교환입니다.

당신의 팀이 MCP 기반 에이전트 배포를 범위 설정하고 있다면, 7월 28일 최종 사양가 목표로 삼아야 할 버전입니다. 처음부터 명시적 핸들을 위해 설계하면 나중에 세션 기반 상태로부터 마이그레이션하는 일을 피할 수 있습니다.

업데이트 — 2026-10-04: MCP Events — 스테이트리스 명세 이후 첫 새 전송 원시

이 문서가 기록하는 스테이트리스 코어에 2026-07-28 명세 주기 이후 첫 새 전송 원시가 더해졌다: MCP Events, OpenAI가 MCP 서버에 추가한 이벤트 구독 메커니즘. events/subscribe 메서드는 구독을 생성하며 전송 모드, 콜백 URL, HMAC 서명 시크릿, 커서를 실는다 — 서명된 웹훅으로 MCP 서버가 ChatGPT 에이전트를 이벤트 주도로 깨울 수 있게 되어, cron과 인간 메시지에 병렬하는 세 번째 트리거 계층이다. 스테이트리스 논제는 모순 없이 이를 흡수한다: 구독은 수명 주기를 지닌 상태 아티팩트이고, 바로 그 수명 주기가 운영 리스크가 집중되는 지점이다 — ChatGPT는 웹훅 기상 모드를 지원하지만 terminated 봉투를 지원하지 않아 철회는 비대칭이며, WorkOS가 구독 자체를 순환과 철회 규율이 필요한 자격 증명으로 프레임하는 것은 정확히 이 지점을 겨냥한다.

업데이트 — 2026-09-18: AGNTCon + MCPCon Europe — 스테이트리스 코어가 프로덕션 증거를 확보하다

AGNTCon + MCPCon Europe는 9월 17~18일 암스테르담 RAI에서 Linux Foundation 산하 Agentic AI Foundation 주관으로 2,000명 이상이 참석한 가운데 열렸고, 이 글의 논지가 필요로 하던 프로덕션 증거를 전달했습니다. MCP 공동 창시자 David Soria Parra가 첫날 기조연설에서 MCP가 새로운 확장 프레임워크, 인가 변경, 공식 폐기 정책을 갖춘 스테이트리스 코어로 이동한다고 발표했습니다 — 바로 이 글이 다루는 7월 28일 릴리스의 공식화입니다. AAIF 멤버 펄스 설문(n=186)은 도입 현실을 구체화했습니다: 응답 조직의 81%가 에이전트를 프로덕션에서 운영하고(51%는 프로덕션 규모), 89%가 MCP를 사용하거나 평가합니다 — 가장 널리 도입된 에이전트 표준 — 그리고 60%가 멀티 에이전트 시스템을 운영합니다. 생태계 수치도 그에 상응하게 커졌습니다: GitHub는 2026년 3월 한 달에만 AI 에이전트가 공동 작성한 풀 리퀘스트 1,780만 건, 8월에 푸시된 커밋 29억 건 — 2025년 전체의 3배를 보고했습니다. Claude는 누적 10억 회의 MCP 도구 호출을 돌파했고, Anthropic 티어원 SDK 다운로드는 5억 회를 넘었습니다.

같은 컨퍼런스에서 B2B 배포자를 위한 경고 두 가지가 나왔습니다. 첫째, 메인테이너 라운드테이블은 일부 프로덕션 MCP 서버가 **"명백히 자동 생성되어 매우 짧은 시간에 조립된 것"**이라고 지적했습니다 — 무엇이 좋은지 평가할 줄 모르는 사람들이 출시한 이 서버 품질 문제는 바로 이 글의 모듈 패턴 절이 존재하는 이유이며, 이제 프로토콜의 메인테이너들 스스로 확인한 사실입니다(평가 기준은 MCP 프로덕션 튜토리얼이 다룹니다). 둘째, Clare Liguori(AWS, MCP 코어 메인테이너)는 외부 이벤트까지 아이들 상태로 대기하는 리액티브 에이전트를 스테이트리스 코어가 가능하게 하는 패턴으로 제시했습니다: 대부분의 프로덕션 에이전트는 마지막 턴 이후 15~60분 동안 서버리스 컨테이너에서 아이들 상태를 유지하며, AWS의 실험적 프로젝트 Infinity는 75,000개의 리액티브 에이전트를 라즈베리 파이(Raspberry Pi)의 메모리에 수용했습니다 — 스테이트리스 에이전트는 대기 중에 열린 연결을 유지하지 않기 때문입니다. 스테이트리스 코어는 단순한 스케일링 단순화가 아니라 다음 배포 경제성의 기반입니다.

---

NetSuite, BigCommerce, 그리고 세 개의 공급업체 카탈로그를 실행하는 유통업체는 이메일 또는 포털로 RFQ를 받고, 카탈로그 그래프에 대해 제품과 대체품을 해석하며, 고객 티어별로 가격을 책정하고, 만료 기한과 함께 재고를 홀드하며, 수락된 견적을 NetSuite에 다시 기록하는 에이전트를 얻습니다 — 모든 단계가 로깅됩니다. 그 구축은 4단계 방법론의 2-3단계이며 일반적으로 5-8주 내에 가동됩니다.

범위가 정해진 구축을 요청하세요. 1주간의 디스커버리. 시스템 인벤토리, 워크플로 맵, 고정된 범위를 얻습니다 — 우리와 함께 구축하든 하지 않든.