MCP가 Stateless로 바뀌는 날: 7월 28일 전 AI 에이전트 연동에서 점검할 6가지

읽는 시간 약 8분

한 줄 결론: MCP 2026-07-28은 프로토콜의 세션을 없애지만, 업무 상태까지 없애지는 않습니다. 기존 연동은 “세션을 어디에 붙일까”가 아니라 “작업 상태를 어떤 명시적 핸들로 넘길까”를 먼저 점검해야 합니다.

7월 28일 공개 예정인 MCP(Model Context Protocol) 2026-07-28 사양은 원격 MCP 서버를 운영하는 팀에게 꽤 큰 전환점입니다. 프로토콜 수준의 핸드셰이크와 세션 ID가 사라지고, 각 요청이 독립적으로 처리되는 구조로 바뀌기 때문입니다.

이 변화는 서버를 여러 대로 늘릴 때의 부담을 줄여주지만, 기존 코드가 Mcp-Session-Id나 초기 연결에서 얻은 정보를 전제로 한다면 그대로 지나칠 수는 없습니다. 이 글에서는 “지금 당장 무엇을 바꿔야 하나요?”라는 질문에 맞춰, 운영 관점의 점검 순서를 정리합니다.

핵심 요약

프로토콜 세션은 사라집니다. initialize/initialized와 Mcp-Session-Id에 기대던 흐름을 확인해야 합니다.
애플리케이션 상태는 남습니다. 장바구니, 브라우저 작업, 장기 실행 작업처럼 이어지는 정보는 명시적 핸들로 돌려받고 다시 전달하는 방식으로 설계해야 합니다.
배포 인프라는 단순해질 수 있습니다. 고정 라우팅이나 프로토콜 세션용 공유 저장소의 필요성이 줄어듭니다.
SDK와 게이트웨이를 함께 점검해야 합니다. 헤더 검증, 재시도, 인증 응답, 관측 데이터가 새 흐름과 맞는지 확인하는 것이 핵심입니다.

왜 지금 점검해야 할까요?

MCP는 AI 애플리케이션이 도구, 데이터, 외부 서비스를 연결할 때 쓰는 개방형 프로토콜입니다. 이번 릴리스 후보는 2026-07-28을 목표로 하며, 프로토콜 코어를 stateless로 바꾸는 변경을 포함합니다. 공식 발표에 따르면 이전 흐름의 initialize 핸드셰이크와 Mcp-Session-Id 헤더는 제거되고, 프로토콜 버전·클라이언트 정보·기능은 요청별 메타데이터로 전달됩니다.

이전에는 최초 요청을 처리한 서버에 후속 호출을 붙이기 위해 고정 라우팅이나 공유 세션 저장소를 고려해야 했습니다. 새 구조에서는 한 요청을 어느 인스턴스가 받아도 처리할 수 있으므로, 일반적인 HTTP 로드밸런서와 더 잘 맞습니다. GitHub도 자사 MCP Server에서 초기화 시점과 매 호출의 Redis 세션 읽기·쓰기를 없앴다고 설명했습니다.

중요: 이것은 “모든 서버가 자동으로 호환된다”는 뜻은 아닙니다. 공식 사양은 호환성을 위한 유예와 폐기 정책을 두고 있지만, 직접 작성한 클라이언트·프록시·도구 서버는 세션 가정이 코드나 모니터링 규칙에 남아 있을 수 있습니다.

Stateless는 상태가 없다는 뜻이 아닙니다

가장 흔한 오해는 “세션이 없어졌으니 상태 저장소도 필요 없다”는 결론입니다. 사라지는 것은 프로토콜이 숨겨서 관리하던 연결 상태입니다. 사용자의 작업 흐름이나 도구 실행 결과처럼 애플리케이션이 계속 기억해야 하는 정보는 여전히 남습니다.

권장되는 방향은 명시적 핸들입니다. 예를 들어 도구가 browser_id, job_id, basket_id 같은 식별자를 반환하고, 다음 호출이 그 값을 인자로 다시 전달하게 만듭니다. 이 방식은 상태의 주체와 수명을 코드에서 확인하기 쉬워지며, 인스턴스가 바뀌어도 Redis·데이터베이스·서명된 토큰 등 애플리케이션 저장소에서 같은 상태를 찾아갈 수 있습니다.

AI 에이전트가 명시적인 상태 핸들을 전달해 서버 저장소의 작업 상태를 이어가는 개념 — 상태는 연결에 숨기기보다, 도구가 반환한 핸들과 애플리케이션 저장소로 명시적으로 이어가는 편이 운영하기 쉽습니다.

구분	이전 세션 중심 흐름	새 요청 중심 흐름
연결 시작	초기화 후 세션 ID를 받음	요청 자체에 필요한 정보를 포함
분산 처리	특정 인스턴스에 붙는 경로를 고려	어느 인스턴스에서도 처리 가능
업무 상태	세션 저장소에 섞이기 쉬움	명시적 핸들과 애플리케이션 저장소로 관리
문제 추적	세션과 연결 로그 중심	요청 ID·핸들·분산 추적 중심

배포 전 6가지 점검표

다음 항목은 사양이 확정되기 전, 스테이징 환경에서 먼저 확인하면 좋습니다.

SDK 버전을 고정하고 호환 범위를 확인하세요. 사용 중인 클라이언트와 서버 SDK가 2026-07-28 지원을 어떤 버전에서 제공하는지 확인하고, 운영 환경에 바로 올리기 전에 통합 테스트를 돌립니다.
세션 ID 의존 코드를 찾으세요. Mcp-Session-Id, initialize, sticky session, 세션 키 이름을 코드·프록시 설정·대시보드에서 검색합니다. 단순 로그 필드인지 실제 라우팅 조건인지 구분해야 합니다.
상태를 핸들 단위로 분리하세요. 작업 재개에 필요한 값이 있다면 반환값과 저장 위치, 만료 시간, 권한 확인 방식을 정합니다. 핸들만 안다고 다른 사용자의 작업에 접근할 수 없어야 합니다.
게이트웨이 헤더를 검증하세요. 새 Streamable HTTP 흐름에서는 Mcp-Method, Mcp-Name 같은 헤더가 라우팅과 제한에 쓰일 수 있습니다. 헤더와 본문 메서드가 불일치할 때의 거부 동작도 확인합니다.
장기 작업과 사용자 입력 흐름을 테스트하세요. Tasks 확장과 다중 왕복 요청은 기존 장기 연결 방식과 다를 수 있습니다. 승인 요청, 취소, 재시도, 중단 후 재개를 실제로 눌러 보아야 합니다.
관측 기준을 요청 단위로 바꾸세요. 요청 ID, 명시적 핸들, traceparent를 연결해 한 번의 도구 호출이 게이트웨이·MCP 서버·하위 API를 어떻게 지나갔는지 볼 수 있게 합니다.

MCP 마이그레이션 전 점검 항목과 서버 운영 요소를 보여 주는 체크리스트 일러스트 — 마이그레이션의 중심은 버전 교체 하나가 아니라 상태·재시도·관측·권한을 함께 확인하는 일입니다.

AI 에이전트 운영에는 무엇이 달라질까요?

에이전트가 한 번의 도구 호출로 끝나지 않는다면, 연결이 아니라 작업 단위를 중심으로 운영 기준을 세우는 편이 좋습니다. 예를 들어 콘텐츠 생성 작업에는 job_id, 브라우저 자동화에는 browser_id, 승인 대기에는 재개 가능한 요청 상태를 둡니다. 그러면 어떤 인스턴스가 처리하더라도 “누가, 어떤 권한으로, 어느 작업을 이어받았는가”를 추적할 수 있습니다.

FLOWIT처럼 여러 자동화 흐름을 다루는 환경에서는 특히 다음 두 가지가 중요합니다. 첫째, 상태 핸들에 사용자·프로젝트 경계를 묶어 권한 검증을 누락하지 않는 것입니다. 둘째, 재시도가 같은 외부 작업을 두 번 실행하지 않도록 멱등성 키나 작업 상태를 설계하는 것입니다. 분산 처리가 쉬워질수록 중복 실행을 막는 기준도 더 분명해야 합니다.

운영 판단: Redis를 없애는 것이 목표가 되어서는 안 됩니다. 프로토콜 세션을 위해서만 두었던 저장소는 줄일 수 있지만, 작업 상태·속도 제한·공유 캐시처럼 제품 자체에 필요한 데이터는 목적에 맞게 남겨 두어야 합니다.

자주 묻는 질문

MCP 서버를 지금 바로 바꿔야 하나요?

바로 운영 환경을 바꾸기보다, 먼저 SDK의 지원 상태와 직접 작성한 세션 의존 코드를 확인하는 편이 안전합니다. 공식 릴리스 후보는 검증 기간을 제공하고 있으므로, 스테이징에서 연결·재시도·장기 작업을 먼저 시험해 보세요.

Stateless가 되면 Redis는 필요 없나요?

프로토콜 세션을 공유하기 위해서만 사용했다면 사용 목적이 줄어들 수 있습니다. 다만 업무 상태, 캐시, 속도 제한, 명시적 핸들에 연결된 데이터는 별도의 저장소가 필요할 수 있습니다.

기존 도구 호출의 상태는 어떻게 이어가나요?

도구가 작업 또는 리소스의 명시적 핸들을 반환하고, 다음 호출이 이를 일반 인자로 전달하도록 설계합니다. 핸들의 만료·권한·재시도 규칙도 함께 정의해야 합니다.

게이트웨이에서 가장 먼저 확인할 것은 무엇인가요?

고정 라우팅 규칙, 세션 헤더 기반 정책, 요청 본문을 깊게 검사하는 규칙을 우선 점검하세요. 새 헤더와 본문 메서드의 일치 검증, 요청 단위 추적도 함께 테스트하는 것이 좋습니다.

마무리

MCP의 stateless 전환은 원격 도구 서버를 일반 HTTP 서비스처럼 확장하고 운영할 수 있게 만드는 변화입니다. 다만 좋은 전환은 세션 코드를 지우는 데서 끝나지 않습니다. 상태의 소유자, 핸들의 수명, 권한, 재시도, 추적을 작업 단위로 다시 정리했을 때 비로소 에이전트 자동화가 더 단순하고 안전해집니다.

참고 자료

이 글이 마음에 드세요?

RSS 피드를 구독하세요!

FLOWIT on YouTube

영상으로도 FLOWIT을 이어서 보세요

AI 자동화, Claude Code, n8n, 데이터 분석 흐름을 블로그와 영상으로 함께 정리하고 있습니다.

YouTube 채널 보기