요약: MCP 2026-07-28은 프로토콜 수준의 세션과 필수 초기화 핸드셰이크를 제거합니다. 프로덕션 팀은 숨겨진 세션 의존성을 찾아내고, 요청당 프로토콜 메타데이터를 도입하며, 다중 왕복 요청(MRTR)을 구현하고, 게이트웨이 정책을 업데이트한 뒤, 레거시 동작을 중단하기 전에 새 프로토콜을 카나리 배포해야 합니다.
2026년 7월 28일 공개된 Model Context Protocol 사양은 원격 전송 지원이 추가된 이후 MCP에 가장 큰 아키텍처 변경을 도입했습니다.
프로토콜은 이제 상태 비저장 요청-응답 코어를 사용합니다. 필수였던 initialize 및 notifications/initialized 교환이 사라졌고, Mcp-Session-Id가 제거되었으며, 각 요청이 처리에 필요한 프로토콜 정보를 자체적으로 포함합니다.
이번 릴리스에는 다중 왕복 요청(MRTR), HTTP 라우팅 헤더, 캐시 가능한 목록 응답, 더 엄격한 인가 동작, 확장 프레임워크, 공식 사용 중단 수명주기도 포함됩니다. 프로토콜 수준의 세부 사항은 와 를 참조하세요.
구매, 삭제, 크레딧 차감 또는 외부 쓰기를 완료하기 전에 input_required를 반환하지 않는 동작은 피하세요.
단계적 작업이나 멱등성 키를 사용하여 재시도가 작업을 중복 수행하지 않도록 하십시오. 전체 상호작용 모델은 공식 MRTR 사양을 참고하세요.
5. 게이트웨이, 캐싱, 인가 업데이트
인프라 변경 사항은 서로 밀접하게 관련되어 있으므로 함께 테스트해야 합니다.
MCP 라우팅 헤더 검증
Streamable HTTP POST 요청은 다음을 포함합니다:
MCP-Protocol-Version
Mcp-Method
Mcp-Name
이 헤더를 사용하면 게이트웨이가 모든 JSON 본문을 파싱하지 않고도 트래픽을 라우팅, 측정, 인가, 레이트 리미팅할 수 있습니다.
예를 들어 다음과 같은 제어를 지원할 수 있습니다:
툴별 레이트 제한
목록과 실행 메서드에 대한 분리된 정책
비용이 큰 툴을 위한 전용 워커 풀
고위험 작업에 대한 접근 제한
툴별 지연 시간 및 오류 메트릭
인프라 비용 귀속
해당 값은 여전히 클라이언트가 제공합니다. 정책 적용 전 JSON-RPC 본문과 비교하세요.
요청이 본문에서는 다른 툴을 호출하면서 헤더 Mcp-Name에 저위험 툴을 주장할 수 있어서는 안 됩니다. 헤더-본문 불일치는 거부하고 로깅해야 합니다.
인가 인지 캐시 키 사용
새 프로토콜은 다음과 같은 캐시 가능한 결과에 ttlMs와 cacheScope를 추가합니다:
tools/list
prompts/list
resources/list
resources/templates/list
resources/read
캐시 키는 일반적으로 다음을 포함해야 합니다:
protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
TTL이 만료되지 않았다는 이유만으로 개인 캐시 엔트리를 사용자나 테넌트 간에 재사용하지 마십시오.
툴의 결정적 정렬도 중요합니다. 안정적인 카탈로그는 불필요한 캐시 미스를 방지하고, 툴 정의가 프롬프트에 삽입될 때 모델 프롬프트 캐시 재사용을 개선할 수 있습니다.
OAuth 발급자 처리 강화
인가 마이그레이션 중에는 다음을 수행하세요:
반환된 iss 값을 해당 플로우에 기록된 발급자와 검증
저장된 클라이언트 자격 증명을 발급자 기준으로 키잉
다른 인가 서버에서 자격 증명을 재사용하지 않기
DCR 중 적절한 application_type 설정
Client ID Metadata Documents 도입 대비
Dynamic Client Registration은 하위 호환을 위해 여전히 사용할 수 있지만, 기본 등록 방식으로는 사용 중단 방향입니다.
6. 알림, Tasks 및 사용 중단 기능 마이그레이션
이전 HTTP GET 알림 경로와 resources/subscribe 또는 resources/unsubscribe 흐름은 subscriptions/listen으로 대체되었습니다.
클라이언트는 장기 POST-응답 스트림을 열고 필요한 알림 범주를 옵트인합니다. 요청별 진행 상황 및 로그 알림은 해당 요청을 설명하는 응답 스트림에 계속 연결됩니다.
멀티 인스턴스 배포에서, 한 서버 인스턴스에서 생성된 알림이 다른 곳에 연결된 구독에 도달해야 한다면 공유 이벤트 버스를 사용하세요.
Tasks 확장
장기 작업은 코어 프로토콜의 실험적 기능에서 다음으로 이동했습니다:
io.modelcontextprotocol/tasks
해당 확장은 다음을 사용합니다:
tasks/get 폴링용
tasks/update 클라이언트→서버 업데이트용
내구성 있는 작업 핸들
옵트인된 업데이트를 위한 subscriptions/listen
이전의 tasks/result 및 tasks/list 패턴은 새 구현으로 가져오지 마십시오.
사용 중단(Deprecated) 기능
다음 기능은 사용 중단 예정입니다:
기능
권장 방향
MCP 2026-07-28
마이그레이션 조치
Roots
디렉터리를 툴 인자, 리소스 URI 또는 구성으로 전달
필수 핸드셰이크 없음
최신 요청의 초기화 게이트 제거
Sampling
모델 공급자 API와 직접 통합
프로토콜 수준 세션 없음
필요한 상태를 명시적으로 관리
Logging
stdio의 stderr 또는 프로덕션에서는 OpenTelemetry 사용
선택적 server/discover 호출
디스커버리 및 버전 협상 구현
Dynamic Client Registration
Client ID Metadata Documents로 전환
요청 _meta에 포함
요청당 프로토콜 메타데이터 전송
레거시 HTTP+SSE
Streamable HTTP로 마이그레이션
Mcp-Method 및 Mcp-Name 헤더
라우팅, 정책, 가시성 업데이트
사용 중단된 includeContext 값
필드 생략 또는 "none" 사용
다중 왕복 요청
input_required 및 재시도 처리
목록 캐싱
카탈로그 반복 조회
ttlMs, cacheScope, 결정적 정렬
인가 인지 캐싱 추가
알림
GET 스트림 및 리소스 구독
subscriptions/listen
변경 알림을 새 스트림으로 이전
인가
DCR 중심 등록
더 강력한 issuer 규칙과 CIMD 방향성
OAuth 클라이언트 및 자격 증명 저장소 감사
장기 작업
코어의 실험적 Tasks
io.modelcontextprotocol/tasks 확장
사용 중단 기능은 사용 중단 기간 동안 계속 제공되지만, 새 구현에서 채택하지 마십시오. MCP 수명주기 정책은 최소 12개월의 사용 중단 기간을 제공하지만, 모든 기능에 동일한 제거 시점을 보장하지는 않습니다.
Modern client + modern server
→ Use MCP 2026-07-28
Modern client + legacy server
→ Probe and fall back when supported
Legacy client + dual-version server
→ Continue on the legacy path
Unsupported combination
→ Return a clear protocol-version error
새 MCP 사양의 릴리스가 생태계 전체 전환을 의미하지는 않습니다. 클라이언트, 서버, SDK, 호스티드 플랫폼은 서로 다른 속도로 마이그레이션됩니다.
수집해야 할 텔레메트리
신호
의미
요청별 프로토콜 버전
채택 현황 및 비호환 조합
디스커버리 성공 및 폴백 비율
버전 협상 동작
누락되었거나 잘못된 MCP 헤더
구식 클라이언트 또는 게이트웨이 오류
헤더/본문 불일치
클라이언트 버그 또는 정책 우회 시도
MRTR 요청 및 완료
인터랙티브 워크플로 신뢰성
MRTR 거부 또는 타임아웃
사용자 및 클라이언트 실패 경로
요청 상태 검증 실패
변조, 재생 또는 만료
중복 작업 방지
멱등성 제어의 효과성
범위별 캐시 적중률
안전한 트래픽 절감
발급자 검증 실패
OAuth 구성 문제
HTTP+SSE 트래픽
남은 전송 마이그레이션 작업
사용 중단 메서드 트래픽
퇴출 계획 근거
툴 지연 시간 및 승인된 작업 비율
사용자 체감 신뢰성
성공적인 원샷 tools/call 요청만으로 마이그레이션을 측정할 수는 없습니다. 반복적으로 타임아웃되거나 불필요한 입력을 요구하거나 외부 쓰기를 중복 수행하는 워크플로는 여전히 프로덕션 실패입니다.
CometAPI가 MCP 아키텍처에 맞는 방식
MCP는 모델 API를 대체하지 않습니다. 두 레이어는 서로 다른 통합 문제를 해결합니다.
레이어
주요 책임
MCP
에이전트를 툴, 리소스, 프롬프트, 승인, 작업에 연결
통합 모델 API
애플리케이션을 모델, 자격 증명, 사용량, 과금에 연결
애플리케이션 오케스트레이션
언제 어떻게 모델과 툴을 호출할지 결정
일반적인 프로덕션 아키텍처는 다음과 같습니다:
Application or agent
↓
MCP clients and servers
Tools, resources, approvals, tasks
↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models
MCP는 에이전트가 툴과 컨텍스트와 상호작용하는 방식을 표준화합니다. 모델 가격, 공급자 자격 증명, 추론 엔드포인트, 공급자 페일오버는 표준화하지 않습니다.
이는 사용 중단된 Sampling 기능에서 마이그레이션할 때 특히 유용합니다. MCP 서버나 이를 소비하는 에이전트가 여전히 모델 추론이 필요하다면, 애플리케이션은 더 이상 기존 MCP Sampling 흐름에 의존하지 않고 모델 API를 직접 호출할 수 있습니다.
통합 모델 게이트웨이가 도움이 되는 경우
다음 상황에서 통합 모델 게이트웨이는 운영 작업을 줄일 수 있습니다:
여러 MCP 서버가 다양한 모델 공급자에 접근해야 하는 경우
서로 다른 툴이 서로 다른 모델을 필요로 하는 경우
팀이 공급자별 통합을 다시 작성하지 않고 모델을 전환하려는 경우
자격 증명, 사용량, 과금을 중앙에서 관리해야 하는 경우
모델 접근을 MCP 전송 변경과 독립적으로 유지해야 하는 경우
CometAPI는 MCP 애플리케이션 뒤에서 모델 접근 계층으로 사용할 수 있는 OpenAI 호환 엔드포인트를 제공합니다. 이를 통해 모델 공급자 로직을 MCP 툴, 리소스, 작업 오케스트레이션으로부터 분리할 수 있습니다.
예를 들어, MCP 툴은 애플리케이션의 다른 곳에서 사용하는 동일한 OpenAI 호환 클라이언트를 통해 모델을 호출할 수 있습니다:
