이 글의 목차
MCP 2026-07-28의 무상태(stateless) 전환은 로그인이나 업무 상태가 필요 없어진다는 뜻이 아닙니다. 프로토콜의 연결 세션과 애플리케이션의 장바구니·작업·사용자 권한을 구분해야 합니다. 오래된 initialize 예제를 새 서버에 붙였다가 실패하는 경우에도 모델 성능보다 명세·SDK 호환을 먼저 확인하세요.
공식 변경 목록은 프로토콜 수준 세션과 초기화 handshake의 제거, 요청 단위 메타데이터, server/discover, Tasks의 확장 분리 등을 명시합니다. MCP 2026-07-28 변경 목록
왜 이 변화가 운영에 중요할까요?
프로토콜 세션에 연결 상태가 묶여 있으면 요청을 같은 서버로 보내거나 세션 정보를 공유해야 하는 상황이 생깁니다. 새 코어는 요청이 필요한 정보를 갖고 전달되는 방향으로 바뀌었습니다. 다만 업무 데이터나 권한이 특정 프로세스 메모리에만 있다면 프로토콜이 무상태여도 애플리케이션은 여전히 그 서버에 의존합니다.
최근 공식 로드맵도 2026-07-28의 변화를 일반적인 HTTP 인프라에서 운영할 수 있는 방향으로 설명합니다. MCP 새 로드맵 이 설명은 모든 배포가 설정 없이 자동 확장된다는 보장이 아닙니다.
세 가지 상태를 따로 생각하기
| 상태 | 예시 | 어디에서 관리하나 |
|---|---|---|
| 프로토콜 정보 | 명세 버전, 클라이언트 기능 | 지원 명세에 맞춘 요청·응답 |
| 인증·인가 | 로그인 주체, 허용 범위 | 인증 서버와 서비스의 권한 검사 |
| 업무 상태 | 장바구니, 보고서 생성 작업 | 저장소와 명시적 작업 식별자 |
‘세션이 없어졌다’는 말은 첫 번째 변화에 관한 것입니다. 사용자마다 다른 자료를 반환하는 서버가 누구의 요청인지 구별하지 않아도 된다는 뜻으로 확대하면 안 됩니다.
명시적 핸들은 권한 토큰이 아닙니다
예를 들어 보고서 생성 도구가 report_id를 반환하고, 다음 도구가 그 ID로 결과를 읽는 구조를 생각할 수 있습니다. 이 ID는 업무 상태를 가리킵니다. 서버는 요청자가 해당 보고서를 읽을 수 있는지 매번 확인해야 합니다.
사용자 A → 보고서 생성 → report_id 반환사용자 A → report_id로 상태 조회 → 소유권·권한 검사 → 결과사용자 B → 같은 report_id 조회 → 소유권·권한 검사 → 거부ID가 추측하기 어렵다는 것과 접근이 허용된다는 것은 다른 조건입니다. 저장 기간, 만료, 삭제, 다른 사용자에게 전달 가능한 범위도 명시해야 합니다. 이 원칙은 장바구니·파일 업로드·브라우저 작업 핸들에도 적용됩니다.
SDK 전환 전에 만드는 호환표
명세 페이지가 새 버전이라고 설치한 SDK와 AI 클라이언트가 모두 지원하는 것은 아닙니다. 각 조합에서 지원하는 버전을 확인하고 고정하세요.
| 확인 대상 | 적을 정보 | 검증 방법 |
|---|---|---|
| AI 호스트·클라이언트 | 지원 명세, 확장 | 실제 서버 탐색·도구 호출 |
| 서버 SDK | 패키지 버전, 전송 방식 | 잠금 파일과 release notes |
| 프록시 | 필요한 헤더·stream 처리 | 테스트 요청과 응답 기록 |
| 도구 | 입력·출력·실패 동작 | 고정한 요청 사례 재현 |
| 인증 | 발급자·대상·권한 범위 | 정상·만료·다른 대상 토큰 시험 |
2025-11-25용 흐름과 2026-07-28용 흐름을 반씩 섞으면 진단이 어려워집니다. 한 테스트 환경에서 하나의 명세 조합을 먼저 완성하고 이전 클라이언트를 지원할 경로를 별도로 정하세요. API 버저닝과 호환성의 문제와도 연결됩니다.
응답을 못 받았을 때 다시 실행해도 될까요?
연결이 끊긴 순간 서버가 작업을 끝냈는지 클라이언트는 모를 수 있습니다. 도구가 읽기 전용 검색인지, 파일 생성인지, 주문 확정인지에 따라 재시도 정책이 달라져야 합니다.
프로토콜 요청 ID와 업무상 중복 실행을 막는 식별자는 역할이 다릅니다. 새 요청 ID로 다시 호출한다고 같은 주문이 중복되지 않는 보장이 생기지는 않습니다. 변경 작업은 멱등성 키와 결과 저장을 검토하세요. 긴 작업은 사용 중인 클라이언트와 서버가 Tasks 확장을 지원하는지도 확인해야 합니다.
도구 목록 캐시도 사용자 범위를 따져야 합니다
모든 사용자에게 같은 도구 설명을 제공하는 서비스와, 권한에 따라 다른 자료를 제공하는 서비스는 캐시 조건이 다릅니다. 무상태 요청이라는 이유로 사용자별 결과를 공유 캐시에 넣으면 안 됩니다.
가상의 사내 검색 도구에서 A는 인사 문서에 접근할 수 있고 B는 일반 기술 문서만 볼 수 있다고 합시다. 도구 이름이 같아도 결과의 범위는 다릅니다. 키에 단순 검색어만 넣은 캐시는 이런 차이를 숨길 수 있습니다. TTL, 무효화, 사용자 범위는 Redis 로컬 캐시의 일관성 기준처럼 데이터 성격에 맞게 정하세요.
전환 성공을 확인할 최소 시험
- 정상 버전에서 도구 탐색·호출·응답 해석이 성공합니다.
- 지원하지 않는 버전은 명확하게 실패합니다.
- 다른 사용자 핸들로 자료를 조회할 수 없습니다.
- 만료된 인증으로 변경 작업을 수행할 수 없습니다.
- 연결 중단 뒤 재시도가 중복 상태 변경을 만들지 않습니다.
- 서버 인스턴스가 바뀌어도 허용된 업무 상태를 조회할 수 있습니다.
모델이 답을 잘 작성하는 것과 프로토콜 전환이 안전하게 끝난 것은 별개입니다. 서버 로그·오류율·재시도 횟수와 업무 상태를 함께 검증하세요.
자주 묻는 질문
MCP가 stateless면 OAuth도 필요 없나요?
무상태 전송과 인증은 다른 문제입니다. 보호된 자료와 변경 작업에는 서비스에 맞는 인증·인가가 필요합니다.
새 명세에서는 모든 클라이언트가 바로 동작하나요?
지원 명세와 확장이 맞아야 합니다. 명세 공개와 개별 SDK·호스트의 구현 시점은 같다고 가정할 수 없습니다.
Tasks 확장이 있으면 중복 실행 문제도 해결되나요?
긴 작업의 상태를 다루는 기능과 업무상 멱등성은 별개입니다. 재시도·장애 상황에서 실제 작업이 한 번만 반영되는지는 서버의 업무 설계로 검증해야 합니다.
참고 자료
2026년 10월 8일 확인. 예시는 설계 설명이며 적용할 명세·SDK·호스트 조합의 호환성을 별도로 검증해야 합니다.
