2026-07-28 MCP 스펙은 세션(sessions)과 초기화 핸드셰이크(initialize handshake)를 제거합니다. src/ 디렉토리에 대해 다음 7가지 grep 명령어를 실행하여 모든 변경 사항을 찾은 다음, 세션, 핸드셰이크, 에러 코드 순서로 마이그레이션을 진행하세요.

2026-07-28 MCP 스펙은 프로토콜 출시 이후 가장 큰 개정 사항이며, 하위 호환성(backward compatible)을 지원하지 않습니다. 만약 프로덕션 환경에서 MCP 서버를 운영 중이라면, 해당 날짜에 코드가 작동을 멈추게 됩니다.

대부분의 글들은 그 '이유'(MCP가 상태가 없는 stateless 방식이 된 이유)를 설명합니다. 하지만 여러분에게 필요한 것은 '무엇'이 바뀌는지입니다: 어떤 줄이 깨지는지, 그리고 그것을 무엇으로 변경해야 하는지 말이죠. 여기 바로 실행해 볼 수 있는 Before/After 코드와 grep 명령어를 포함한 7가지 변경 사항이 있습니다.

핵심 요약 (Key Takeaways)

• 2026-07-28 MCP 스펙은 세션(sessions)과 초기화 핸드셰이크(initialize handshake)를 제거합니다.
• src/ 디렉토리에 대해 다음 7가지 grep 명령어를 실행하여 모든 변경 사항을 찾은 다음, 세션, 핸드셰이크, 에러 코드 순서로 마이그레이션을 진행하세요.

1. 세션이 사라짐 (SEP-2567)

Mcp-Session-Id 헤더와 프로토콜 레벨의 세션이 제거되었습니다. 전송 계층(transport)은 이제 상태가 없는(stateless) 방식입니다. 즉, 어떤 요청이든 어떤 서버 인스턴스로도 도달할 수 있습니다.

장점: 더 이상 스티키 세션(sticky sessions), 공유 세션 저장소(shared session stores) 또는 스마트 게이트웨이가 필요하지 않습니다. 일반적인 라운드 로빈(round-robin) 로드 밸런싱 뒤에서 실행하면 됩니다.

비용: 세션을 읽거나 쓰는 모든 기능이 깨집니다.

// 변경 전 (before) — TS SDK
new StreamableHTTPServerTransport({
  sessionIdGenerator: () => randomUUID(),
...

세션에 존재하던 정보는 이제 모든 요청의 _meta에 포함되어 전달됩니다. 세션 ID 대신 요청마다 프로토콜 버전, 클라이언트 정보, 기능(capabilities)을 읽으십시오.

grep -rn "Mcp-Session-Id\|sessionIdGenerator\|sessionStore" src/

호출 간에 상태(state)를 유지해야 합니까? 도구(tool)로부터 명시적인 핸들(예: cart_id, run_id)을 생성하고, 모델이 이를 인자(argument)로 다시 전달하도록 하십시오.

2. 초기화 핸드셰이크가 제거됨 (SEP-2575)

더 이상 initialize/initialized 왕복(round trip) 과정이 없습니다. 세션이 없으므로 이를 고정할 '연결 시간(connection time)'도 존재하지 않습니다.

기능(Capability) 데이터는 이제 각 요청의 _meta를 통해 전달됩니다. 기능 확인(capability checks) 로직을 사용하는 위치로 인라인(inline) 이동시키십시오.

grep -rn "initialized\|onInitialize\|InitializeRequestSchema" src/

3. 에러 코드 -32002가 -32602로 변경됨 (SEP-2164)

MCP-custom "resource not found" 코드는 이제 표준 JSON-RPC -32602 (Invalid Params, 잘못된 파라미터)를 반환합니다.

// 이전
throw new McpError(-32002, "Unknown resource");
// 이후
...

서버에서 던지는(throws) 에러와 클라이언트의 매칭 여부를 모두 확인하십시오:

grep -rn "32002" src/ test/

4. 두 개의 새로운 필수 라우팅 헤더 (SEP-2243)

스트리밍 가능한 (Streamable) HTTP 전송(transport) 방식은 이제 Mcp-Method 및 Mcp-Name 헤더를 필수로 요구합니다. 이를 통해 로드 밸런서(load balancers)가 요청 본문(request body)을 읽지 않고도 라우팅할 수 있습니다.

프록시(proxy) 또는 게이트웨이(gateway) 뒤에 있는 경우, 이 헤더들이 통과되는지 확인하십시오. HTTP를 직접 구현(hand-roll)하는 경우, 이 헤더들을 설정하십시오.

5. list/read 응답의 ttlMs 및 cacheScope (SEP-2549)

기존 기능을 깨뜨리지 않는 추가적인(Additive) 변경 사항입니다. 무료 클라이언트 측 캐싱(client-side caching)을 위해 응답에 ttlMs를 설정하십시오. 나머지 코드가 컴파일되면 한 번 검토할 가치가 있습니다.

6. Roots, sampling, logging의 사용 중단 예정 (SEP-2577)

2026-07-28 기준으로 여전히 작동하지만, 제거까지 12개월의 유예 기간(2027년 7월까지)이 있습니다.

• sampling: 직접적인 LLM API 호출로 교체
• roots: 작업 컨텍스트(working context)를 도구 입력(tool inputs)으로 전달
• logging: stderr 또는 OpenTelemetry로 이동

grep -rn "createMessage\|ListRootsRequest\|sendLoggingMessage\|setLoggingLevel" src/

7. Tasks가 확장 기능(extension)으로 이동 (SEP-2663)

Tasks는 코어(core) 대신 버전이 지정된 확장 기능(extension)으로 제공됩니다. 재설계 과정에서 tasks/result는 tasks/get을 통한 폴링(polling) 방식으로 대체되었고, tasks/update가 추가되었으며, tasks/list는 제거되었습니다.

grep -rn "tasks/list\|tasks/result\|CreateTaskRequest" src/

작업 순서 구성 방법

최우선 과제 (강제 적용, 7월 28일 실패 시 작동 불가): 세션(sessions) (1), 핸드셰이크(handshake) (2), 에러 코드(error code) (3). 이를 먼저 배포하십시오. 그 다음 헤더(headers) (4), 캐싱(caching) (5), 사용 중단 예정 항목(deprecations) (6, 7)을 더 긴 유예 기간에 맞춰 진행하십시오.

귀하의 src/ 디렉토리에 대해 일곱 가지 grep 명령을 모두 실행하십시오. 약 2분 안에 명백한 호출 지점(call sites)들을 찾아낼 수 있습니다. 검색 결과(hits)를 읽어보되 — 단순히 개수만 믿지는 마십시오 — 하지만 수정해야 할 항목 리스트(punch list)는 짧을 것입니다.

출처: dev.to

원문 게시지: gentic.news