Stateful vs. Stateless MCP 코어.

(Anthropic의 가장 큰 MCP 업데이트)

그것이 무엇을 의미하는지 설명하겠습니다:

이번 릴리스 전까지 MCP 서버와 통신하는 것은 전화 통화와 같았습니다. 양측 모두 초기화 핸드셰이크 (initialize handshake)를 수행했으며, 서버는 이후의 모든 요청에 전달되는 세션 ID (session id)를 반환했습니다.

그 세션은 협상된 상태 (negotiated state)를 보유하며 특정 서버 프로세스 내부에 존재하는 라이브 객체였습니다.

주문을 받은 웨이터만이 무엇이 주문되었는지 알고 있는 레스토랑을 상상해 보세요. 그 웨이터가 퇴근하기 전까지는 모든 것이 잘 작동합니다.

이러한 상태가 하나의 프로세스에 존재하기 때문에, 로드 밸런서 (balancer)가 세 개의 MCP 서버 인스턴스에 요청을 분산할 수 없었습니다. 팀들은 스티키 세션 (sticky sessions)으로 클라이언트를 고정하거나 세션 상태를 공유 저장소에 밀어 넣어야 했으며, 이는 오토스케일링 (autoscaling)을 방해하고 단 한 번의 재시작만으로도 모든 열려 있는 세션을 끊어지게 만들었습니다.

최신 업데이트는 이 모든 것을 삭제합니다. 핸드셰이크와 Mcp-Session-Id 헤더는 사라졌으며, 이제 각 요청은 자체적인 프로토콜 버전 (protocol version), 클라이언트 식별 정보 (client identity), 그리고 기능 (capabilities)을 _meta 필드에 담아 전달합니다.

사전에 기능 목록을 확인하고 싶은 클라이언트는 server/discover를 호출할 수 있지만, 반드시 그래야 할 필요는 없습니다.

이제 레스토랑은 반대로 작동합니다. 레스토랑의 방식이 뒤집힌 것입니다. 이제 모든 요청은 작성된 주문서와 같으며, 어떤 웨이터라도 이를 처리할 수 있습니다.

따라서 공유 세션 저장소 없이도 일반적인 라운드 로빈 (round-robin) 로드 밸런서 뒤에 있는 어떤 인스턴스로든 모든 요청이 도달할 수 있습니다. MCP 서버는 서버리스 (serverless) 및 에지 (edge)에서 실행되며 재시작 후에도 생존하는 일반적인 HTTP 서비스가 됩니다.

세션을 제거하면서 세 가지 기능이 깨졌기에, 각각을 다시 구축했습니다.

→ 통화 중간에 사용자에게 무언가를 물어봐야 하는 도구 (Tools)들은 이전에는 열려 있는 스트림 (held-open stream)을 통해 해당 요청을 밀어 넣었습니다. 이제 서버는 input_required를 반환하며, 클라이언트는 답변을 첨부하여 재시도합니다.

→ 메서드 (Method) 및 도구 (tool) 이름이 Mcp-Method 및 Mcp-Name 헤더로 이동하여, 게이트웨이 (gateway)나 속도 제한기 (rate limiter)가 JSON-RPC 본문을 파싱하지 않고도 라우팅 및 측정을 할 수 있습니다.

→ 목록 응답 (List responses)은 ttlMs와 cacheScope를 포함하므로, 클라이언트는 매번 재연결할 때마다 다시 가져오는 대신 도구 카탈로그 (tool catalogs)를 캐싱할 수 있습니다.

여기서 상태(State)가 사라진 것이 아니라, 모델이 볼 수 있는 곳으로 이동한 것입니다.

연속성(continuity)이 필요한 애플리케이션은 도구로부터 명시적인 핸들(handle)을 전달받으며, 모델은 다음 호출 시 이를 인자(argument)로 다시 전달합니다.

헤더에 포함된 세션 ID(session id)는 모델에게 보이지 않지만, 인자에 포함된 핸들은 모델이 읽을 수 있고, 도구 간에 스레드(thread)를 형성하며, 호출 실패 후에도 복구할 수 있는 요소입니다.

공식 명세(Official Spec): https://t.co/jC4Lu7eGi5

MCP에 대해 다루고 있는 만큼, 왜 MCP 대 CLI 논쟁이 잘못된 방향이었는지, 그리고 에이전트가 모든 스키마(schema)를 컨텍스트(context)에 로드하는 대신 코드를 작성함으로써 어떻게 도구를 호출할 수 있는지에 대해서도 작성했습니다.

해당 기사는 아래에 인용되어 있습니다.