MCP 새 스펙 변경점, 스테이트리스⁠·MRTR과 파이썬 SDK v2

MCP 새 스펙(2026-07-28 버전)과 공식 파이썬 SDK 버전 2에서 무엇이 바뀌었는지 핵심만 정리합니다. FastMCP가 MCPServer로 이름을 바꾼 것보다 중요한 변화는 세션을 없앤 스테이트리스 구조와, 서버가 되묻는 방식을 바꾼 MRTR입니다. 기존 서버를 옮길 때 확인할 코드 변경점도 함께 적었습니다.

MCP 새 스펙에서 무엇이 나왔나

MCP(Model Context Protocol)는 AI가 외부 도구⁠·데이터와 연결되는 공개 규격입니다. 2026년 7월 28일 이 규격의 새 버전(버전 이름도 날짜를 딴 2026-07-28)이 공개됐고, 같은 날 공식 파이썬 SDK도 2.0으로 크게 업데이트됐습니다. 파이썬 SDK에서는 기존 FastMCP 클래스가 MCPServer로 이름이 바뀌었습니다.

이름 변경은 눈에 띄지만 핵심은 아닙니다. 실제로 크게 바뀐 것은 세 가지입니다.

• 클라이언트와 서버가 통신하는 방식
• 세션을 관리하는 방식
• 서버가 클라이언트에게 추가 작업을 요청하는 방식

변화 1. 세션 중심에서 스테이트리스로

기존 구조: 먼저 악수하고, 그 연결 위에서 일한다

기존 MCP에서는 클라이언트가 서버에 처음 연결되면 "이니셜라이즈(initialize)"라는 과정을 먼저 거쳤습니다. 쉽게 말해 "나는 이런 기능을 지원하는 MCP 클라이언트야", "나는 이런 기능을 지원하는 MCP 서버야" 하고 서로 정보를 주고받는 단계입니다.

연결을 초기화한 다음에는 그 연결 위에서 툴 목록을 조회하거나 툴을 실행했습니다. 클라이언트와 서버 사이에 세션이라는 다리를 놓고, 그 연결 상태를 유지하며 요청을 처리하는 구조였습니다. 그래서 기존 MCP는 어느 정도 세션 중심의 프로토콜이었습니다.

바뀐 구조: 요청 하나하나가 독립적이다

새 스펙은 이 구조를 스테이트리스(stateless, 서버가 연결 상태를 기억하지 않는 방식)로 바꿨습니다. 이니셜라이즈 교환과 세션 ID 헤더(Mcp-Session-Id)가 빠졌습니다. 대신 각 요청이 프로토콜 버전, 클라이언트 정보, 지원 기능을 스스로 담아 서버에 독립적으로 전달됩니다.

왜 바꿨나: 클라우드에서 서버를 늘리기 쉽게

MCP가 로컬 컴퓨터를 넘어 원격 서버와 클라우드 환경에서 쓰이고 있기 때문입니다.

서버를 여러 대 띄워 놓고 로드밸런서로 요청을 나눈다고 해 봅시다. 서버가 특정 사용자의 세션을 계속 들고 있어야 한다면, 첫 번째 요청을 처리한 서버와 두 번째 요청을 처리하는 서버가 다를 때 문제가 생길 수 있습니다. 요청을 각각 독립적으로 처리할 수 있으면 어느 서버가 받아도 되니, 서버를 여러 대로 늘리기가 훨씬 쉬워집니다.

MCP가 로컬 컴퓨터에서 툴 몇 개를 연결하는 규격에서 벗어나, 클라우드에서 대규모로 운영되는 에이전트 인프라까지 고려하기 시작했다는 뜻입니다. 여러 요청에 걸쳐 상태가 필요한 앱은 이제 직접 관리해야 합니다. 공식 블로그는 툴이 상태를 가리키는 값(핸들)을 만들어 돌려주고, 모델이 다음 호출에 그 값을 다시 넘기는 방식을 권합니다.

변화 2. 서버가 되묻는 방식, MRTR

기존: 서버가 클라이언트에게 거꾸로 요청했다

기존 MCP에는 조금 독특한 구조가 있었습니다. 실행 중에 사용자 입력이 더 필요해지면, 서버가 클라이언트에게 "사용자에게 이 내용을 한 번만 물어봐 줘" 하고 요청할 수 있었습니다(elicitation). 클라이언트만 서버를 호출하는 게 아니라 서버도 클라이언트에게 요청을 보낼 수 있었던 셈입니다. 이를 위해 연결을 계속 열어 둬야 했습니다.

새 방식: 일단 응답을 끝내고, 다시 요청받는다

새 스펙은 "멀티 라운드트립 리퀘스트(Multi Round-Trip Requests)", 줄여서 MRTR이라는 구조를 들여왔습니다. 서버가 클라이언트를 역으로 호출하지 않습니다. "이 정보가 더 필요하다"는 결과(resultType이 input_required인 응답)로 일단 응답을 끝내면, 클라이언트가 필요한 정보를 얻은 다음 답을 담아 같은 요청을 다시 보냅니다.

왜 바꿨나: HTTP 방식에 잘 맞아서

요청을 보내고 응답을 받으면 끝나는, 웹에서 쓰는 일반적인 HTTP 리퀘스트⁠·리스폰스 구조에 훨씬 잘 맞기 때문입니다. 연결을 열어 둔 채 기다릴 필요가 없으니 변화 1의 스테이트리스 구조와도 맞물립니다.

공식 파이썬 SDK v2에서 바뀐 코드

기존 MCP 서버를 파이썬으로 만들어 쓰고 있다면 아래 일곱 가지를 확인합니다.

1. FastMCP 대신 MCPServer

• 새 공식 파이썬 SDK에서는 FastMCP 대신 MCPServer를 씁니다. 불러오는 경로도 mcp.server.fastmcp에서 mcp.server.mcpserver로 바뀌었습니다.
• @mcp.tool(), @mcp.resource(), @mcp.prompt()처럼 자주 쓰던 데코레이터는 v1과 같은 인자와 함수 형태를 그대로 받습니다.
• 그래서 MCP 툴만 만들어 쓰던 사람은 생각보다 고칠 코드가 많지 않을 수 있습니다.

2. 클라이언트가 간단해졌다

• 예전에는 ClientSession이나 Transport를 직접 다뤄야 하는 경우가 많았는데, 더 쓰기 쉬운 Client API가 들어왔습니다.
• MCP 서버 객체를 Client(server)처럼 직접 연결할 수 있어서, 서버를 실제로 띄우지 않고도 툴을 테스트하기 쉬워졌습니다.

3. Sampling과 Roots는 deprecated

• Sampling은 서버가 클라이언트에게 "네가 가지고 있는 LLM을 실행해 줘"라고 요청하는 기능이었습니다.
• Roots는 클라이언트가 접근할 수 있는 파일이나 디렉터리를 알려 주는 개념이었습니다.
• 새 스펙에서는 두 기능과 Logging이 deprecated(앞으로 쓰지 않도록 권고하는 상태)가 됐습니다. 최소 12개월은 계속 지원됩니다. 서버가 클라이언트를 역으로 호출하는 구조 자체가 줄어드는 흐름입니다.

4. WebSocket Transport 제거

• 앞으로는 주로 stdio와 Streamable HTTP 방식을 씁니다.
• WebSocket은 원래 MCP 공식 표준 Transport가 아니었고, 이번 SDK 개편에서 제거됐습니다.

5. 파이썬 코드는 snake_case

• 예전에는 inputSchema, isError, nextCursor 같은 이름을 썼다면, SDK v2에서는 input_schema, is_error, next_cursor처럼 snake_case로 바뀌었습니다.
• 다만 네트워크로 주고받는 JSON 형식은 기존처럼 camelCase입니다. 모델을 직접 JSON으로 바꿀 때는 by_alias=True를 줘야 camelCase로 나옵니다.

6. 변경 알림은 subscriptions/listen 하나로

• 툴이나 리소스가 바뀌었다고 알려 주는 방식이 여러 갈래였는데, subscriptions/listen 스트림 하나로 정리됐습니다. 클라이언트가 받고 싶은 알림 종류를 골라 구독합니다.

7. 캐시와 Extension 강화

• 서버가 "이 결과는 일정 시간 캐싱해도 된다"는 정보를 함께 보낼 수 있게 됐습니다. 툴 목록 같은 응답에 캐시 유지 시간(ttlMs)과 범위(cacheScope)가 붙습니다.
• MCP Apps, Tasks처럼 MCP 자체를 확장하는 Extension 구조도 더 명확해졌습니다.

기존 MCP 서버는 당장 다시 만들어야 하나

기존 MCP가 갑자기 전부 동작하지 않는 것은 아닙니다. 공식 파이썬 SDK v2도 기존 프로토콜과의 호환성을 고려하고, 폐기 예정 기능에는 최소 12개월의 유예 기간이 있습니다. 공식 이전 안내는 mcp 패키지에 의존하는 프로젝트라면 옮기기 전까지 버전 상한을 <2로 묶어 두라고 권합니다.

설치와 버전 확인은 아래 명령으로 합니다. 셋 중 필요한 줄만 실행합니다. uv를 쓰는 프로젝트라면 첫 줄 대신 uv add "mcp[cli]"입니다.

pip install -U "mcp[cli]"     # v2로 올리기
pip install "mcp[cli]<2"      # 옮기기 전까지 v1에 묶어 두기
pip show mcp                  # 설치된 버전 확인 (Version 줄)

[cli]를 붙이면 mcp dev(MCP Inspector로 열어 보기), mcp run 같은 명령줄 도구가 함께 깔립니다. 옮긴 서버를 클로드 코드에 붙여 시험하려면 내 컴퓨터에서 실행하는 서버 형식으로 등록하고 claude mcp list에서 연결됨으로 나오는지 봅니다. 파일 경로는 전체 경로로 적고, 시험이 끝나면 claude mcp remove demo로 지웁니다.

claude mcp add demo -- uv run --with "mcp[cli]" mcp run /전체경로/server.py

그래서 지금 당장 기존 서버를 모두 새로 만들기보다, 어떤 구조로 바뀌는지 먼저 이해하는 편이 낫습니다. 실제로 옮길 때는 공식 파이썬 SDK의 이전 안내(Migration Guide)에서 바뀐 이름과 지원 방식을 하나씩 대조합니다.

가장 큰 흐름은 한 줄로 줄어듭니다. MCP가 상태를 들고 있는 스테이트풀 프로토콜에서 리퀘스트⁠·리스폰스 기반의 스테이트리스 프로토콜로 바뀌었습니다. 로컬 도구를 연결하는 규격에서 출발해, 수많은 에이전트와 원격 MCP 서버가 클라우드에서 대규모로 돌아가는 상황까지 고려하는 에이전트 인프라용 웹 프로토콜로 성숙해 가는 과정입니다.