빠른 요약

  • MCP 2026-07-28 사양은 initialize handshake와 Mcp-Session-Id를 없애고 각 요청에 프로토콜 및 client context를 담는다.
  • 팀은 프로토콜 전용 sticky session과 session store를 줄이면서 업무 상태는 명시적인 식별자로 유지할 수 있다.
  • sticky routing과 session store를 조사하고 tool을 idempotent하게 만든 뒤 MCP 2026-07-28을 canary로 전환한다.

무슨 일이 있었나

프로토콜 계층의 stateless

2026년 7월 28일 MCP 개정은 프로토콜 코어를 stateless로 바꿨다. initialize handshake와 Mcp-Session-Id header가 더 이상 필요하지 않고, 각 요청이 필요한 protocol version과 client context를 포함한다. 따라서 client의 첫 메시지가 실제 tool call이 될 수 있고 load balancer 뒤의 어떤 instance도 처리할 수 있다.

AWS가 강조하듯 stateless protocol은 stateless application을 뜻하지 않는다. 도구가 여러 호출에 걸친 연속성을 필요로 하면 server는 datastore에 상태를 저장하고 식별자를 반환한다. model은 다음 호출에서 그 식별자를 tool argument로 전달한다. transport header에 숨겨진 session보다 상태가 명시적이고 관측 가능해진다.

배포 구조의 변화

기존 stack은 ALB stickiness와 MCP 전용 session store를 없애고 round-robin routing을 사용할 수 있다. Lambda도 request-in, response-out 구조에 자연스럽게 맞는다. server/discover는 version, capability, identity를 제공하고 ttlMs와 cacheScope는 tool list caching을 지원한다. 관측은 W3C Trace Context와 OpenTelemetry를 활용하며 복구는 안전하게 재시도할 수 있는 idempotent tool에 의존한다.

보안 제약은 여전히 중요하다. tenant별 정보가 포함된 응답에 public cacheScope를 사용하면 공유 중간 계층을 통해 데이터가 노출될 수 있으므로 private가 기본이어야 한다. 운영팀은 구형 client를 조사하고 제한된 호환 기간을 제공하며 session 인프라를 단계적으로 제거하고 retry가 중복 부작용을 만들지 검증해야 한다.

전환 전후에는 instance별 요청 편중, 재시도 횟수, tool latency와 오류율을 같은 dashboard에서 비교해야 한다. 업무 상태 식별자에는 짧은 수명, tenant binding과 권한 검사를 적용해야 하며 session header를 tool argument로 이름만 바꾸는 방식은 피해야 한다.

관련 글

참고 자료

MCP went stateless: Is your AWS MCP server deployment well-architected?

개발자가 주목해야 하는 이유

팀은 프로토콜 전용 sticky session과 session store를 줄이면서 업무 상태는 명시적인 식별자로 유지할 수 있다.

  1. 1sticky routing과 session store를 조사하고 tool을 idempotent하게 만든 뒤 MCP 2026-07-28을 canary로 전환한다.