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 모듈이 자체 자격 증명 수명 주기를 구현하는 대신 그 복잡성을 관리하기 위한 표준 패턴을 제공합니다.

기존 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일 릴리스 후보가 목표로 삼아야 할 버전입니다. 처음부터 명시적 핸들을 위해 설계하면 나중에 세션 기반 상태로부터 마이그레이션하는 일을 피할 수 있습니다.

---

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

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