MCP

MCP 새 사양 마이그레이션 체크리스트: 서버 제작자가 이번 주에 할 일

DevPilot 2026. 7. 28. 09:00

핵심 요약: MCP 사상 최대 개정(2026-07-28)이 확정되면서 질문이 "뭐가 바뀌나"에서 "그래서 뭘 하나"로 넘어왔습니다. 역할별 요약 — 일반 사용자: 없음(클라이언트 업데이트만 따라가기). 서버 제작자: SDK 업데이트 추적 + 세션 상태 의존 로직 제거(상태가 필요하면 Tasks 패턴으로) + 구버전 병행기 대응. 원격 서버 운영자: 스티키 라우팅·세션 저장소 제거 계획 + 인증 강화 요건 반영. 서두를 필요는 없습니다 — 전환기가 설계돼 있으니, 이번 주의 할 일은 "실행"보다 내 서버의 마이그레이션 대상을 파악하는 것입니다.

이 글에서 다루는 내용: 역할별 체크리스트, 코드에서 찾아야 할 패턴, 전환기 운영 요령. 개정 내용 자체는 미리보기 글 참고.

먼저: 나는 어느 역할인가

사용자(Cursor·Claude Code에서 MCP를 쓰기만 함) → 이 글을 닫아도 됩니다. 클라이언트·SDK가 호환을 처리하고, 체감할 일은 전환기의 간헐적 버전 불일치 정도입니다. 제작자(서버 코드를 유지보수) → 아래 체크리스트가 본론. 운영자(원격 MCP를 호스팅) → 제작자 항목 + 인프라 항목까지.

제작자 체크리스트

① SDK 버전 추적. 대부분의 변경(헤더 처리, server/discover, initialize 제거)은 SDK가 흡수합니다 — 사용하는 SDK(Python·TypeScript 등)의 새 사양 대응 릴리스를 확인하고 업그레이드 계획부터. 직접 프로토콜을 구현했다면 일이 커지니, 이 기회에 공식 SDK로 옮기는 것도 검토 대상입니다.

② 세션 상태 의존 코드 찾기. 코드에서 이런 패턴을 검색하세요 — 세션 ID를 키로 쓰는 딕셔너리·캐시, "이전 요청에서 만든 것"을 다음 요청이 참조하는 흐름, initialize 시점에 준비하는 리소스. stateless 세계에서 이것들이 깨지는 지점이고, 처방은 두 갈래입니다: 짧은 상태는 요청에 실어 왕복(클라이언트가 들고 다니게), 긴 작업은 Tasks 패턴(새 사양의 장시간 작업 표준)으로 재설계.

③ 도구 목록·능력 조회 경로 점검. initialize 핸드셰이크에서 하던 초기화가 있다면 server/discover 응답으로 옮겨질 수 있는지 확인 — 무겁게 준비하던 것이 있다면 지연 초기화로 바꿀 시점입니다.

④ 구버전 병행기 계획. 클라이언트들이 일제히 갈아타지 않으므로, 당분간 구·신 사양 요청이 섞여 들어올 수 있습니다. SDK가 협상을 처리해주는지 확인하고, 직접 구현이라면 버전별 분기의 수명(언제 구버전을 끊을지)을 정해두세요 — 새 사양의 공식 폐기 정책이 그 기준선을 줍니다.

운영자 추가 체크리스트

⑤ 라우팅 단순화. 스티키 세션·공유 세션 저장소가 프로토콜 요구사항에서 빠졌으니, 마이그레이션 완료 후 제거 일정을 잡으세요 — 인프라 비용과 장애 지점이 함께 줄어드는, 이번 개정의 보상 항목입니다. ⑥ 인증 강화 대응. 강화된 authorization 요건을 검토하고, 토큰 처리·권한 범위가 새 기준에 맞는지 확인 — 보안 커뮤니티가 주시하는 지점이라 엔터프라이즈 고객이 있다면 우선순위가 높습니다. ⑦ 모니터링 갱신. 세션 개념이 사라지면 세션 기반 메트릭도 의미를 잃습니다 — 요청 단위 관측으로 대시보드를 재편하세요.

전환기 운영 요령

당분간 디버깅 체크리스트(그 순서)에 한 줄이 추가됩니다 — "클라이언트와 서버의 사양 버전이 맞는가." "어제까지 되던 서버가 안 될" 때 업데이트 타이밍 불일치가 새 용의자입니다. 그리고 서버를 새로 만들기 시작하는 입장이라면(Python 편 등) 처음부터 새 사양 기준 SDK로 시작하세요 — 지금 구버전으로 배우는 건 이사 예정인 집을 수리하는 셈입니다.

자주 묻는 질문 (FAQ)

Q. 마이그레이션 안 하면 언제부터 문제가 되나요?

A. 당장은 아닙니다 — 전환기와 폐기 정책이 있으니까요. 다만 클라이언트들의 신사양 채택이 진행될수록 구버전 전용 서버의 호환 범위가 좁아지므로, 분기 내 계획을 권합니다.

Q. 로컬(stdio) 서버도 해당되나요?

A. stateless 전환의 실익은 원격(HTTP) 쪽이 큽니다. 로컬 서버는 SDK 업데이트를 따라가는 수준으로 충분한 경우가 많지만, 세션 상태 의존 로직(②)은 로컬이라도 점검 대상입니다.

Q. Tasks 패턴이 뭔가요?

A. 새 사양이 도입한 장시간 작업의 표준 처리 방식입니다 — 요청-응답 한 번에 안 끝나는 작업을 추적 가능한 작업 단위로 다룹니다. 세션에 상태를 숨기던 설계의 공식 대체재라고 이해하면 됩니다.

한눈에 보는 요약

사용자는 관전, 제작자는 SDK 추적 + 세션 상태 제거(Tasks로), 운영자는 라우팅 단순화 + 인증 강화. 이번 주 할 일은 실행이 아니라 대상 파악 — 그리고 새 서버는 처음부터 새 사양으로.

함께 보면 좋은 글

MCP 사상 최대 개정: 뭐가 바뀌나 (미리보기)
원격 MCP vs 로컬 MCP
MCP 서버가 안 붙을 때 디버깅 체크리스트

참고 자료

MCP 공식 블로그 (사양 발표)
MCP 공식 문서