MCP에 릴리스 캘린더가 생겼습니다: SEP-3398, Server Cards, 10월 보안 물결이 B2B 배포에 의미하는 것

핵심 요약

• MCP 사양이 이제 고정된 캘린더로 릴리스됩니다. SEP-3398가 2026년 10월 14일 채택되어 3월과 9월의 각각 마지막 화요일을 기준으로 6개월마다 릴리스를 정하고, 2026년 12월 목표를 2027년 3월 말로 옮겼습니다.
• Server Cards가 Final이 되었습니다. SEP-2127가 2026년 10월 6일 Final로 병합되어, MCP 서버에 연결 전에 전송 방식, 프로토콜 버전, 연결 가이드를 발견할 수 있는 표준화된 메타데이터 문서를 제공합니다.
• 공식 리포지토리에 28일간 31건의 보안 권고 — eSEOspace의 State of MCP October 집계 기준, MCP Inspector의 치명적인 2건 포함. 10월 21일 1.0.3 보안 릴리스에서 수정되었습니다.
• Smithery 프록시와 관리형 신원 서비스가 2026년 10월 31일 중단되었습니다. Smithery 자체 공지가 run.tools와 server.smithery.ai 서버 URL을 퇴역시켰습니다. 임대한 배포 경로가 운영 리스크라는 것에 대한 이번 달의 가장 명확한 증명입니다.
• 겨울 내내는 2026-07-28 사양을 기준으로. 스테이트리스 코어는 영향을 받지 않으며, 다음 릴리스는 2027년 3월 말에 예정되어 있습니다. 마이그레이션 단계를 changelog 추적이 아니라 캘린더에 올릴 수 있게 되었습니다.

Smithery의 MCP 프록시와 관리형 신원 서비스가 2026년 10월 31일 — 오늘 — 중단되었습니다. 여전히 run.tools나 server.smithery.ai URL로 서버를 확인하는 에이전트 배포는 그와 함께 멈췄습니다. Smithery 자체 공지가 사라진 것을 나열합니다: 호스팅 서버 URL, API, Connect와 Toolbox, 계정, API 키, CLI. 마이그레이션은 벤더 자체 엔드포인트로 가는 것 — linear.run.tools 대신 mcp.linear.app/mcp — 이며, 그 목록을 갖고 있지 않던 팀들은 오늘 그것을 쓰게 되었습니다.

같은 28일 동안 MCP 유지관리자들은 프로토콜의 첫 고정 릴리스 캘린더를 채택하고, Server Cards 발견 표준을 Final로 병합했으며, eSEOspace 집계 기준 공식 MCP 리포지토리에 31건의 보안 권고를 기록했습니다. 그중 두 건은 MCP Inspector에서 치명적으로 평가되었습니다.

이 조합은 하나의 전환을 세 방향에서 본 것입니다 — 일정, 발견, 운영. MCP는 빠르게 움직이는 접착제가 아니라 관리형 인프라처럼 동작하기 시작했습니다. 이 글은 10월의 기록을 하나의 신호로 읽고, 그것이 요구하는 운영 리듬을 정리합니다: 사양 버전을 고정하고, 릴리스 일정을 캘린더에 올리고, SDK를 보안 릴리스 트랙에 유지하고, 배포 경로를 임대하지 않습니다.

이 글은 MCP 2026-07-28: 스테이트리스 프로토콜이 B2B 에이전트 배포에 의미하는 것을 기초로 합니다. 그 글이 스테이트리스 코어, 명시적 핸들 패턴, 7월 28일 사양의 배포 산수를 다뤘다면, 여기의 초점은 10월에 그 사양 주위에서 바뀐 것 — 케이던스, 발견 계층, 권고 흐름, 배포 중단입니다. 스테이트리스 테제 자체는 그 어느 것에도 건드리지 않았습니다.

10월 기록을 한눈에

캡션: 28일간의 다섯 사건이 MCP를 굴러가는 사양에서, 캘린더와 발견 표준과 보안 릴리스 트랙을 갖추고 첫 서드파티 배포 중단을 겪은 플랫폼으로 바꾸었습니다.

채택되고 이어서 병합된 릴리스 캘린더

SEP-3398는 프로세스 SEP이고, 프로세스 SEP는 헤드라인에 오르기 어렵습니다 — 그러나 이것은 올라야 했습니다. 10월 14일에 채택되고 10월 27일에 병합된 이 SEP는 MCP의 릴리스 리듬을 문서로 고정합니다: 사양 릴리스는 6개월마다, "일반적으로 3월과 9월의 마지막 화요일". 각 릴리스는 8개월의 작업 주기를 갖습니다 — 두 달의 계획, 예정된 핵심 유지관리자(Core Maintainer) 검토 창구, 안정화 단계 — 그리고 인접한 두 주기는 두 달 겹칩니다. 이행 조항이 나머지를 정리합니다: 제안되었던 2026년 12월 릴리스 목표가 2027년 3월 말로 옮겨집니다.

유지관리자에게 이것은 검토 용량 관리입니다. B2B 배포에게는 계획 인프라입니다.

• 폐기 창구가 이제 캘린더화 가능해졌습니다. Roots, Sampling, Logging과 폐기된 HTTP+SSE 전송은 7월 28일 사양부터 12개월의 애너테이션 전용 창구를 갖고 있었습니다. 고정 캘린더는 "7월 28일부터 12개월"을 ERP 릴리스 창구와 같은 로드맵 위의 일정으로 바꿉니다.
• 미완료 작업은 옮겨지고, 날짜는 움직이지 않습니다. 릴리스에 묶인 제안은 soft freeze 전까지 Final로 병합되어야 합니다. 미완료 제안은 다음 주기로 옮겨지지만 릴리스 날짜는 움직이지 않습니다. 팀이 플랫폼 벤더에게 기대하는 행동 — 예측 가능성이 완전성보다 우선 — 입니다.

즉각적인 실무 결론은 eSEOspace가 10월 데이터에서 끌어낸 것입니다: 10월에는 새 사양 버전이 나오지 않았습니다 — 최신은 여전히 2026-07-28이며, 캘린더는 다음을 2027년 3월 말로 옮겼습니다. 오늘 배포가 고정한 스테이트리스 코어는 겨울 내내 현행입니다.

Server Cards: 발견이 더 이상 설정 파일이 아닙니다

SEP-2127 (MCP Server Cards)는 캘린더 SEP보다 먼저 10월 6일 Final로 병합되어 배포 문제의 나머지 절반을 닫습니다. 스테이트리스 사양은 에이전트가 연결된 이후 서버와 어떻게 통신하는지를 정의했습니다. Server Cards는 에이전트가 수동 구성 없이 어떻게 서버를 찾는지를 정의합니다: 전송 방식, 프로토콜 버전, 연결 가이드를 기술한 표준화된 메타데이터 문서가 서버가 노출하고, 클라이언트가 어떤 연결이 열리기 전에 읽는 방식으로.

SEP 자체의 메커니즘: 각 서버는 자신의 card를 노출합니다 — card는 예약되지 않은 어떤 URI에서도 호스팅될 수 있고, 권장 위치는 <streamable-http-url>/server-card — 확장 식별자 io.modelcontextprotocol/server-card 아래입니다. 도메인 수준의 "AI Catalog"가 관련 card를 링크하거나 임베드할 수 있으며, 이것이 레지스트리 크롤링과 서비스 자동 발견을 각 엔드포인트를 손으로 만지지 않고 가능하게 합니다.

B2B의 대응물은 A2A의 agent card — .well-known/agent-card.json — 이며, 우리의 A2A 커버리지는 이미 이것을 기계 간 발견의 기본 요건으로 다룹니다. Server Card는 프로토콜 서버를 위한 같은 생각이며, 오늘날 대부분의 에이전트 배포가 유지하는 산출물 — 손으로 쓴 서버 엔드포인트와 그 도구 스키마 목록 — 을 삭제합니다. 그 목록이 발견 가능한 메타데이터가 되면 운영 자세는 세 방향으로 바뀝니다 — 새 서버가 스스로의 표면을 알립니다. 오래된 엔드포인트는 감사 가능해집니다(가동 중인 서버와 더 이상 일치하지 않는 card는 그 자체가 발견 사항입니다). 벤더 업그레이드가 클라이언트 쪽 재구성을 필요로 하지 않게 됩니다.

SDK와 클라이언트 지원은 SEP가 명시한 다음 단계이므로 실용적인 움직임은 지금 설계에 넣는 것입니다: card 위치를 염두에 두고 엔드포인트를 구축하고, 서버 목록이 설정이 아니라 메타데이터가 될 준비를 갖추십시오.

10월 보안 물결: 권고는 운영 리듬의 일부입니다

10월 기록에서 가장 날카로운 행은 보안 행이며, 취미 프로젝트의 changelog가 아니라 플랫폼 벤더의 패치 화요일처럼 읽힙니다. MCP Inspector의 치명적인 두 건이 10월 21일 공개되었고 둘 다 1.0.3 보안 릴리스에서 수정되었습니다:

• GHSA-6x67-4w4w-9f3w — 원격 MCP App이 프록시의 인증 토큰을 훔쳐 임의의 로컬 명령을 실행할 수 있습니다 (RCE). 영향 버전: Inspector 0.20.0부터 1.0.2까지.
• GHSA-4fc4-wcmh-4g86 — 악의적인 MCP OAuth 콜백이 전송 방식을 stdio로 전환해 임의의 로컬 명령을 실행할 수 있습니다 (RCE). 영향 버전: 0.13.0부터 1.0.2까지.

Inspector 밖에서 TypeScript SDK의 10월 권고는 B2B에 이빨이 있는 것입니다: GHSA-jm63-cq47-j5jp — "공유된 전송 또는 서버 인스턴스가 한 HTTP 클라이언트의 메시지를 다른 곳에 전달했다" — 상급 평가, 2.0.0부터 영향을 받고 2.3.0에서 수정. 공유 전송을 통한 클라이언트 간 데이터 유출은 정확히 B2B 배포가 감당할 수 없는 결함 클래스이며, 실험적인 구석이 아니라 SDK의 핵심 패키지에 왔습니다.

릴리스 날짜는 심각도만큼 명확하게 플랫폼 이야기를 전합니다. Python SDK 2.3.0은 10월 2일 도구 등록 시 더 엄격한 헤더 검사와 함께 나왔습니다. TypeScript SDK 2.4.0은 10월 23일 Skills-over-MCP (SEP-2640) 지원을 더했습니다. Kotlin 0.16.0은 10월 27일 메모리 고갈 구멍을 막고 SSE를 폐기 대상으로 지정하며 나왔습니다(릴리스; 성격 규정은 eSEOspace의 릴리스 노트 검토). 주요 공식 SDK 전부가 이번 달 최소 한 번은 릴리스했고, eSEOspace의 검토에 따르면 공통 주제는 강화입니다: 요청 크기, 세션 수, 메모리의 하드 리미트. 공식 리포지토리에 걸친 그들의 권고 집계 — 28일간 31건 — 는 그들 자신의 집계지만, 그것이 기술하는 형태는 검증됩니다. 보안 릴리스 트랙은 이제 간헐적이 아니라 연속입니다.

운영자에게 읽어내는 것은 단순합니다. 당신의 MCP 자산에 SDK 업데이트 정책이 있다면, 10월은 그 정책이 두 번 발동해야 했던 달입니다. 없다면, 위의 권고들이 쌓이는 것입니다.

Smithery: 배포 계층의 계약이 만료되었습니다

세 번째 사건은 운영팀이 오늘 느끼는 것입니다. Smithery의 공지는 모호함이 없습니다: 2026년 10월 31일, Smithery는 연결 관리 서비스를 중단했습니다 — 즉 모든 run.tools와 server.smithery.ai 서버 URL, 호스팅 프록시 경로, API, 계정, API 키, CLI가 중단되었습니다. smithery.ai 디렉터리는 공개 디렉터리로 남아 있으며, 지금은 Arcade.dev가 지원합니다.

벤더 네이티브 엔드포인트를 가진 서버에게 마이그레이션은 단순합니다 — Smithery 자신의 예시가 linear.run.tools 대신 mcp.linear.app/mcp를 가리키는 것입니다. 프록시를 배포 전략으로 삼아 구축한 배포에게는 몸싸움입니다: 벤더 네이티브 URL이 없고, 당신의 컨트롤 플레인에서 무엇이 그것을 대체할지에 대한 계약이 없으며, 트래픽을 기록하던 프록시가 사라진 지금 누가 연결하는지에 대한 감사도 없습니다.

이 교훈은 한 벤더를 넘어 일반화됩니다: 당신의 에이전트 부대가 MCP 서버를 확인하는 경유 엔드포인트가 제3자에게 속한다면, 그 엔드포인트의 수명주기는 당신이 선택하지도 추적하지도 않은 의존성입니다. 10월은 이 증명을 — 프로토콜이 발견 메타데이터를 표준화하고 자신의 릴리스 캘린더를 고정한 같은 달에 — 전달했습니다. 지속 가능한 입장은 Smithery 자체 마이그레이션 가이드에 따른 벤더 네이티브 엔드포인트, 또는 당신 팀이 운영하는 엔드포인트입니다 — 우리의 MCP 서버 보호 분석이 경계에 대해 그린 buy-vs-build 선을 이 기록이 배포 분야에서 증명합니다.

B2B MCP 배포의 운영 체크리스트

캡션: 10월의 신호를 배포 정책으로 바꾸는 여섯 개의 관리 항목 — 각 항목은 이번 달 날짜가 있는 사건 하나에 대응합니다.

#	관리 항목	그것이 대응하는 10월 사건	배포에서의 모습
1	사양 버전을 고정	10월에는 새 사양 버전 없음; 다음 릴리스는 2027년 3월 말	2026-07-28을 명시적으로 지정; 그 버전을 지원한다고 선언하는 SDK를 실행; 각 캘린더 일정에서 고정을 재검토
2	릴리스 일정을 캘린더에 올리기	SEP-3398: 3월과 9월의 마지막 화요일	soft freeze (T−2.5개월)와 hard freeze (T−1개월)를 팀 로드맵에 검토 창구로 배치, 놀람으로 남기지 않기
3	SDK 보안 트랙에 머무르기	10월 31건의 권고; Inspector 1.0.3의 치명 2건	SDK 바닥을 보안 릴리스에 고정 (TS ≥ 2.3.0, Inspector ≥ 1.0.3); 공식 리포지토리의 권고 피드 구독
4	벤더 네이티브 또는 자체 운영 엔드포인트 선호	Smithery의 run.tools / server.smithery.ai가 10월 31일 EOL	서버 목록의 모든 비벤더 엔드포인트를 목록화; 프록시 의존 경로를 종료하거나 스스로 운영
5	Server Cards 메타데이터를 향해 설계	SEP-2127이 10월 6일 Final, SDK/클라이언트 지원은 뒤따름	card 위치를 염두에 두고 엔드포인트 설계; 서버 목록이 설정이 아니라 발견 가능한 메타데이터가 될 준비
6	레지스트리 등재는 미심사로 취급	공식 레지스트리 52,141개 서버, 66%가 원격 엔드포인트 제공 (eSEOspace 집계)	등재는 보안 신호가 아닙니다. 서드파티 서버를 연결하기 전에 거버넌스 체크리스트의 모듈 승인 게이트를 적용

2026-07-28 배포 패턴은 여기서 어떻게 됩니까

우리의 이전 분석이 제시한 스테이트리스 코어는 10월이 건드리지 않은 부분입니다 — 그리고 그것이 솔직하게 밝힐 가치가 있는 지점입니다. SEP-3398은 미래 릴리스를 다시 일정 짓습니다. 겨울 내내 당신이 고정한 사양을 건드리지 않습니다. Server Cards는 전송을 바꾸지 않고 발견을 더합니다. 권고는 같은 프로토콜 버전 위에서 SDK를 강화합니다. Smithery의 중단은 제3자의 상업적 결정이며, 프로토콜 사건이 아닙니다.

당신의 배포 패턴이 "MCP는 너무 빨라 고정할 수 없고 너무 어려서 캘린더에 올릴 수 없다"고 가정했다면, 10월은 그 반증 기록입니다. changelog 관람에서 캘린더 관람으로 전환한 팀은 2027년 3월 말 릴리스를 예정된 검토로 다룰 것입니다. 나머지는 장애물이 되어 그것을 알게 될 것입니다.

함께 읽기

• MCP 2026-07-28: 스테이트리스 프로토콜이 B2B 에이전트 배포에 의미하는 것 — 부모 분석: 스테이트리스 코어, 명시적 핸들 패턴, 7월 28일 사양의 배포 산수, 그리고 pre-final 상태의 Server Cards 제안
• MCP 보안: 거버넌스된 모듈 — 권고와 승인 흐름을 모듈 수준 관리로 바꾸는 거버넌스 계층
• MCP 서버 보호: 사겠느냐 만들겠느냐 — 이 10월 기록이 배포로 확장한 경계의 질문: 연결 경로의 어느 부분이 당신의 것인가

---

대표적인 구축 사례: NetSuite, BigCommerce, 세 개의 공급업체 카탈로그를 연결하는 유통업체의 에이전트 플랫폼이 모든 MCP 모듈을 벤더 네이티브 또는 자체 운영 엔드포인트에서 실행하고, 2026-07-28 사양에 고정하며, 3월/9월 릴리스 일정과 권고 피드를 런북에 넣어 두면 — Smithery급 중단과 1.0.3급 보안 릴리스가 모두 루틴 티켓이지 장애가 아닙니다. 이 구축은 Discovery → Governance → Automation → Expansion의 4단계 방식을 따르며, 보통 5–8주 안에 가동됩니다.

범위를 정한 구축을 요청하십시오. 1주간의 디스커버리. 시스템 인벤토리, 워크플로 맵, 고정 범위를 얻게 됩니다 — 우리와 함께 만들지 여부와 상관없이.