MCP 2026-07-28 상세 분석: 무상태 서버, MCP 애플리케이션, 작업, 기업 인증 및 새로운 에이전트 인프라
모델 컨텍스트 프로토콜은 출시 이후 가장 큰 규모의 아키텍처 개정을 맞이했습니다. MCP는 처음에 AI 애플리케이션이 모델과 ...을 연결하는 보편적인 방식으로 도입되었습니다.
MCP 2026-07-28 해석: 프로토콜이 무상태(Stateless)로 전환되어 확장성이 향상됨
서론
모델 컨텍스트 프로토콜(MCP)이 출시 이후 가장 큰 규모의 아키텍처 개정을 맞이했습니다.
MCP는 처음 도입될 때 AI 애플리케이션이 모델과 도구, API, 데이터 소스, 파일 및 외부 시스템을 연결하는 보편적인 방식으로 자리 잡았습니다. 2년도 채 되지 않는 기간 동안 MCP는 Anthropic이 주도하는 통합 프로젝트에서 자체 거버넌스 프로세스, SDK 생태계, 워킹 그룹, 확장 프로그램, 그리고 수많은 AI 제품 전반에 걸친 구현을 갖춘 보다 광범위한 오픈소스 프로토콜로 성장했습니다.
2026-07-28 개정판은 MCP가 개발자의 노트북을 벗어나 대규모 프로덕션 환경에 진입할 때 발생하는 문제에 초점을 맞추고 있습니다.
가장 주요한 변경 사항은 다음과 같이 요약할 수 있습니다:
MCP가 프로토콜 계층에서 무상태(Stateless)로 전환되고 있습니다.
이 변경은 새로운 온라인 형식에서 프로토콜 수준의 세션 및 초기화 핸드셰이크를 제거하여, 원격 MCP 서버가 일반적인 로드 밸런서, 서버리스 인프라, 엣지 컴퓨팅 노드 및 수평 확장 아키텍처 뒤에서 더 쉽게 배포될 수 있도록 합니다.
하지만 무상태 전송은 이번 업데이트의 일부에 불과합니다.
이번 개정판은 또한 확장 프레임워크를 공식화하고, 장기 실행 작업을 재설계하며, 다중 왕복 요청을 도입하고, 라우팅 가능한 HTTP 헤더와 캐시 힌트를 추가하며, 권한 부여 메커니즘을 강화하고, JSON Schema 지원을 확장하며, 공식적인 기능 폐기 정책을 수립했습니다.
프로토콜 자체 외에도 MCP 생태계는 인터랙티브 애플리케이션, 엔터프라이즈급 호스팅 인증, 프라이빗 네트워크 터널링 및 더 강력한 개발자 도구를 추가하고 있습니다.
바로 이 지점에서 MCP는 더 이상 편리한 에이전트 커넥터가 아닌 프로덕션급 인프라로 변모하기 시작합니다.
MCP 채택 속도의 급격한 성장
소스 보고서는 MCP 사용량의 증가 속도를 강조합니다.
소스 기사에서 인용한 Claude 개발자 발표에 따르면:
- MCP SDK 월간 다운로드 수가 4억 회를 초과했습니다.
- 연간 기준 SDK 월간 사용량이 약 4배 증가했습니다.
- TypeScript 및 Python SDK의 누적 다운로드 수 모두 매우 큰 이정표를 돌파했습니다.
- 수백 개의 MCP 통합이 Claude의 커넥터 생태계를 통해 제공되고 있습니다.
이러한 7월 말의 구체적인 수치는 발표 자료의 지표로, 핵심 사양에 게시된 수치가 아닙니다.
Anthropic의 이전 공식 발표는 유용한 기준점을 제공합니다: 2026년 1월, Anthropic은 MCP가 월 1억 건의 다운로드를 달성했다고 밝혔습니다.
이는 7월 프로토콜 재설계 이전에 이미 생태계가 상당히 컸다는 것을 의미합니다.
따라서 이번 업데이트의 의미는 MCP가 미래에 유용해지려는 것이 아니라, 유지보수자들이 이미 프로덕션 규모에서 드러난 문제를 중심으로 프로토콜을 재설계하고 있다는 점입니다.
이러한 문제는 다음과 같습니다:
- 고정 세션(Sticky Session)
- 공유 세션 저장소
- 수평 확장
- 서버리스 배포
- 게이트웨이 라우팅
- 인증 복잡성
- 장기 실행 에이전트 작업
- 인터랙티브 인터페이스
- 하위 호환성
- 프로토콜 진화
이전의 상태 저장(Stateful) 설계가 확장의 걸림돌이 된 이유
초기 원격 MCP 배포는 프로토콜 수준의 세션 상태를 유지할 수 있었습니다.
클라이언트는 일반적으로 초기화를 수행하여 연결을 설정하고 세션 식별자를 획득했습니다. 이후 요청은 해당 세션과의 연관성을 유지해야 했습니다.
단순화된 2025-11-25 흐름은 다음과 같습니다:
POST /mcp HTTP/1.1
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {},
"clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
초기화 이후, 후속 호출은 다음을 포함할 수 있습니다:
Mcp-Session-Id: 1868a90c-3a3f-4f5b
이 방법은 많은 애플리케이션에서 작동했지만 몇 가지 인프라 계층의 요구 사항을 수반했습니다.
프로덕션 배포에는 다음이 필요할 수 있습니다:
- 고정 로드 밸런서 라우팅
- 공유 세션 저장소
- 세션 복제
- 세션 만료 로직
- 장애 조치 처리
- 연결 인식 관측 가능성
- 서버 재시작에 대한 특별 처리
MCP 유지보수자들은 이러한 요구 사항이 프로토콜 자체와 너무 밀접하게 결합되어 있다고 결론을 내렸습니다.
새로운 개정판은 이러한 가정을 제거합니다.
MCP 이제 프로토콜 계층에서 무상태(Stateless) 구현
2026-07-28 프로토콜 설계에서 각 요청은 서버가 요청을 처리하는 데 필요한 모든 정보를 포함합니다.
공식 예시는 다음과 같습니다:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {
"q": "otters"
},
"_meta": {
"io.modelcontextprotocol/clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
}
더 이상 프로토콜 수준의 Mcp-Session-Id가 없습니다.
더 이상 요청을 단일 서버 인스턴스에 바인딩하는 강제적인 연결 세션이 없습니다.
호환되는 모든 서버 인스턴스가 해당 요청을 처리할 수 있습니다.
이것은 클라우드 배포에 있어 중요한 개선입니다.
원격 MCP 서버는 이제 기존 아키텍처에 적응할 수 있습니다:
클라이언트
↓
API 게이트웨이 / 로드 밸런서
↓
MCP 서버 인스턴스 A
MCP 서버 인스턴스 B
MCP 서버 인스턴스 C
이전 요청이 특정 인스턴스에 도달했다는 이유만으로 요청이 해당 인스턴스로 돌아갈 필요가 없습니다.
새 온라인 형식에서 initialize 핸드셰이크 제거
무상태 재설계는 또한 2026-07-28 온라인 형식에서 기존의 initialize / initialized 라이프사이클을 제거했습니다.
이전에 초기화 중에 한 번만 전송되던 정보는 이제 메타데이터를 통해 각 요청과 함께 전송됩니다.
클라이언트가 서버 기능을 사전에 발견하려는 경우 새로운 server/discover 메서드를 사용할 수 있습니다.
이는 기존 클라이언트가 즉시 작동을 중지한다는 의미는 아닙니다.
현재 SDK 문서에는 초기 프로토콜 버전에 대한 호환성 동작 설명이 포함되어 있습니다. 예를 들어, C# SDK는 새로운 무상태 경로를 지원하면서도 2025-11-25 프로토콜을 사용하는 클라이언트와 레거시 세션 기반 동작을 계속 협상할 수 있습니다.
중요한 마이그레이션 차이점은 다음과 같습니다:
2026-07-28：
무상태 요청 모델, 프로토콜 세션 없음.
이전 버전:
초기화 핸드셰이크 및 세션 인식 동작은 여전히 지원될 수 있음
버전 협상 및 SDK 호환 경로를 통해.
개발자는 서버만 업그레이드하고 모든 클라이언트가 새 버전을 이해한다고 가정하는 대신, 통합의 양쪽 끝을 테스트해야 합니다.
무상태 프로토콜이 무상태 애플리케이션을 의미하지는 않음
가장 흔히 저지르는 실수 중 하나는 이 변경 사항을 다음과 같이 이해하는 것입니다:
MCP 애플리케이션은 더 이상 상태를 유지할 수 없습니다.
이것은 사양의 의미가 아닙니다.
프로토콜 계층은 무상태입니다.
애플리케이션은 상태가 유용한 곳에서 여전히 상태를 유지할 수 있습니다.
쇼핑 도구가 쇼핑 바구니를 생성한다고 가정해 보겠습니다.
서버는 다음과 같이 반환할 수 있습니다:
{
"basket_id": "basket_8472"
}
모델은 이후 호출에서 해당 값을 전달할 수 있습니다:
{
"basket_id": "basket_8472",
"item_id": "item_123"
}
이렇게 하면 애플리케이션 상태가 일반 도구 데이터로 표시되며, 전송 메타데이터에 숨겨지지 않습니다.
동일한 패턴은 브라우저 세션, 보고서 작업, 장바구니, 워크플로 ID, 배포 ID, 문서 편집 상태 및 장기 실행 분석 작업에도 사용할 수 있습니다.
명시적 핸들이 더 나은 이유
보이는 핸들에는 몇 가지 장점이 있습니다.
모델은 다음을 할 수 있습니다:
- 관련 도구 간에 전달.
- 어떤 핸들이 어떤 작업에 속하는지 추론.
- 로그에 포함.
- 재시도 후 복구.
- 다른 워크플로 단계에 전달.
서버는 다음을 할 수 있습니다:
- 핸들 검증.
- 만료 처리.
- 사용자 또는 테넌트에 바인딩.
- 만료된 상태 거부.
- 실제 상태를 데이터베이스에 저장.
따라서 무상태 MCP는 상태 관리를 전송 계층에서 명시적 애플리케이션 설계로 이동시킵니다.
서버리스 및 수평 확장이 훨씬 쉬워짐
원문 기사는 서버리스 배포를 강조했으며, 이는 새 프로토콜의 가장 실질적인 성과 중 하나입니다.
요청이 자체 포함된 경우 MCP 서버는 다음 환경에서 더 쉽게 실행될 수 있습니다:
- AWS Lambda.
- Cloudflare Workers.
- Vercel.
- 기타 서버리스 함수.
- 컨테이너 자동 확장 플랫폼.
- 일반 무상태 Kubernetes 배포.
- 엣지 환경.
이것이 모든 MCP 워크로드가 자동으로 모든 서버리스 플랫폼에서 실행된다는 의미는 아닙니다.
개발자는 여전히 실행 시간, 스트리밍 지원, 콜드 스타트, 영속 애플리케이션 상태, 키, 아웃바운드 네트워크, 장기 실행 작업, 파일 시스템 요구 사항 및 데이터베이스 연결을 고려해야 합니다.
프로토콜이 더 이상 세션 아키텍처를 강제하지 않으므로 주요 장애물이 제거되었습니다.
라운드 로빈 로드 밸런싱이 자연스러운 기본값이 됨
수평 확장된 서버는 더 이상 프로토콜 계층에서 단일 클라이언트를 단일 인스턴스에 바인딩할 필요가 없습니다.
즉, 간단한 라운드 로빈 로드 밸런서가 여러 인스턴스에 요청을 분산할 수 있습니다.
이것은 다음을 개선합니다:
- 자동 확장.
- 인스턴스 교체.
- 장애 복구.
- 롤링 배포.
- 다중 지역 라우팅.
- 인프라 단순성.
또한 서버 작성자가 숨겨진 인메모리 상태를 고려할 때 사고 방식을 바꿉니다.
어떤 도구가 이전 요청이 특정 프로세스 내에서 딕셔너리를 채웠기 때문에 정상 작동한다면, 다음 요청이 다른 인스턴스에 도달했을 때 해당 구현은 실패할 수 있습니다.
좋은 마이그레이션 테스트는 다음과 같습니다:
모든 도구 호출이 다른 서버 프로세스에 도달하더라도 동일한 워크플로가 계속 작동합니까?
대답이 아니오라면, 서버에 명시적으로 만들어야 하거나 영속 공유 저장소로 마이그레이션해야 하는 애플리케이션 상태 의존성이 포함되어 있음을 의미합니다.
다중 라운드 트립 요청이 지속적인 인콜 연결을 대체
무상태 설계에서도 서버가 클라이언트에 추가 정보를 요청할 수 있는 방법이 여전히 필요합니다.
예를 들어 사용자 확인, 추가 매개변수, 안내 질문, 모델 생성 응답 또는 작업 영역 관련 값이 있습니다.
새 메커니즘은 다중 라운드 트립 요청(Multi Round-Trip Requests, MRTR)입니다.
도구는 불완전한 결과를 반환할 수 있습니다:
{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "파일 3개를 삭제하시겠습니까?",
"schema": {
"type": "boolean"
}
}
},
"requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}
클라이언트는 필요한 답변을 수집합니다.
그런 다음 inputResponses와 반환된 requestState를 사용하여 원래 호출을 반복합니다.
상태가 요청 흐름에서 전달되므로 다른 서버 인스턴스가 다음 라운드를 처리할 수 있습니다.
이것은 장기간 유지되는 서버-클라이언트 연결을 요구하는 것보다 무상태 아키텍처에 훨씬 적합합니다.
헤더 기반 라우팅으로 MCP가 게이트웨이에 더 친숙해짐
새 Streamable HTTP 형식은 작업 메타데이터를 HTTP 헤더에 직접 추가합니다.
중요한 헤더는 다음과 같습니다:
Mcp-Method: tools/call
Mcp-Name: search
이것은 프로덕션 인프라에 중요합니다.
API 게이트웨이, 웹 애플리케이션 방화벽, 속도 제한기 또는 관찰 가능성 계층은 JSON 본문을 파싱하지 않고도 작업을 식별할 수 있습니다.
가능한 용도는 다음과 같습니다:
- 모든 검색 도구를 동일한 풀로 라우팅.
- 파괴적 작업에 더 엄격한 제한 적용.
- 도구 이름별 지연 시간 기록.
- 메서드별 사용량 측정.
- 게이트웨이에서 허용되지 않는 도구 차단.
- 독립적인 신뢰성 정책 생성.
프로토콜 사양은 헤더와 JSON-RPC 본문 간의 일관성도 요구합니다.
서버는 둘 사이에 불일치가 있는 요청을 거부해야 합니다.
목록 및 읽기 결과가 캐시 인식 지원
MCP 클라이언트는 도구 목록, 리소스, 프롬프트 목록 및 리소스 읽기와 같은 비교적 안정적인 메타데이터를 자주 요청합니다.
동일한 정보를 반복적으로 가져오면 네트워크 트래픽과 서버 용량이 낭비됩니다.
새 개정판은 다음과 같은 캐시 메타데이터를 도입합니다:
ttlMs
cacheScope
이 값들은 서버가 결과가 신선하게 유지되어야 하는 기간과 결과가 사용자 또는 컨텍스트 간에 공유될 수 있는지 여부를 나타낼 수 있게 합니다.
이것은 일반 HTTP 캐싱과 유사한 원리입니다.
도구 중심 에이전트의 경우 반복적인 메타데이터 로딩을 줄일 수 있습니다.
분산 추적이 표준화됨
이 개정판은 또한 W3C Trace Context 전파를 문서화합니다.
다음과 같은 키:
traceparenttracestatebaggage
는 MCP 메타데이터를 통해 전파될 수 있습니다.
이것은 단일 분산 추적이 다음 링크를 따라 작업을 추적할 수 있게 합니다:
호스트 애플리케이션
→ MCP 클라이언트
→ MCP 게이트웨이
→ MCP 서버
→ 다운스트림 API
→ 데이터베이스
엔터프라이즈급 배포에서 이는 중요합니다. 팀이 지연 시간이 실제로 발생하는 위치를 볼 수 있을 때 느린 도구 호출을 디버깅하기가 훨씬 쉬워지기 때문입니다.
확장이 일급 프로토콜 기능이 됨
프로토콜은 선택적 기능이 진화하는 방식도 변경하고 있습니다.
현재 프레임워크는 확장에 다음을 부여합니다:
- 역방향 DNS 식별자.
- 기능 협상.
- 독립적 버전 관리.
- 전용 코드 저장소.
- 위임된 관리자.
- SEP 프로세스 내 공식 확장 트랙.
이것은 핵심 프로토콜이 모든 새로운 아이디어를 흡수할 필요가 없기 때문에 중요합니다.
기능은 먼저 확장으로 성숙할 수 있으며, 검증된 기능은 이후에 핵심에 더 가까워질 수 있습니다.
MCP Apps: 대화 내 인터랙티브 UI
가장 눈에 띄는 MCP 확장 중 하나는 MCP Apps입니다.
MCP 도구는 전통적으로 텍스트, 구조화된 JSON 또는 리소스를 반환했습니다.
일부 작업에는 인터페이스가 필요합니다.
예를 들어 대시보드, 차트, 지도, 양식, 작업 보드, 구성 패널, 디자인 캔버스 및 비디오 플레이어가 있습니다.
MCP Apps를 통해 서버는 UI 리소스를 선언할 수 있고, 호스트는 이를 샌드박스 처리된 iframe에서 렌더링합니다.
간소화된 흐름은 다음과 같습니다:
- 도구가 UI 리소스를 선언합니다.
- 모델이 해당 도구를 호출합니다.
- 호스트가 샌드박스에서 UI를 로드합니다.
- 도구 데이터가 인터페이스로 전달됩니다.
- 사용자가 애플리케이션과 상호작용합니다.
- 애플리케이션은 호스트를 통해 추가 도구 호출을 요청할 수 있습니다.
- 호스트는 이러한 작업에 대해 권한 및 감사 제어를 유지합니다.
MCP Apps는 Claude 및 MCP를 지원하는 기타 개발 제품을 포함한 여러 호환 호스트에서 지원됩니다.
MCP Apps 기본 설치
공식 확장 패키지는 다음 명령어로 설치할 수 있습니다:
npm install -S @modelcontextprotocol/ext-apps
공식 예제 코드 저장소는 로컬에서 실행할 수 있습니다:
git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start
이 명령어들은 공식 MCP Apps 문서에서 가져온 것으로, 확장 기능의 발전에 따라 변경될 수 있습니다.
Tasks: 연결을 차단하지 않는 장기 실행 작업
Agent 도구는 점점 더 일반적인 HTTP 요청 중에 완료할 수 없는 작업을 시작하고 있습니다.
예로는 CI 파이프라인, 대규모 데이터 처리 작업, 클라우드 배포, 장기 연구 작업, 비디오 렌더링 및 인간 승인 프로세스가 있습니다.
MCP Tasks 확장을 사용하면 서버가 작업 완료를 차단하며 기다리는 대신 지속적인 작업 핸들을 반환할 수 있습니다.
공식 확장에서 정의한 메서드는 다음과 같습니다:
tasks/get
tasks/update
tasks/cancel
작업은 다음 상태 간에 전환될 수 있습니다:
working
input_required
completed
cancelled
failed
클라이언트는 tasks/get을 폴링할 수 있습니다.
서버가 사용자 입력이 필요한 경우 작업은 input_required 상태로 전환될 수 있습니다.
클라이언트는 tasks/update를 통해 입력을 제출할 수 있습니다.
이 설계는 연결이 끊어진 상황에서도 정상적으로 작동하며, 장기 유지 연결이 필요하지 않습니다.
중요 호환성 참고 사항
작업 기능은 2025-11-25 핵심 사양에서 실험적 기능으로 존재했습니다.
새로운 Tasks 확장은 이전 API의 단순한 이름 변경 복사본이 아닙니다.
공식 SDK 문서는 최신 Tasks 확장이 초기 실험적 구현과 온라인 프로토콜에서 호환되지 않는다고 경고합니다.
기존 Tasks 기능을 사용하는 애플리케이션은 자동 호환을 기대하지 말고 마이그레이션해야 합니다.
엔터프라이즈 호스팅 권한 부여
기업 배포에서 직면하는 권한 부여 문제는 소비자급 통합과 다릅니다.
한 회사에는 수천 명의 직원과 수십 개의 승인된 MCP 서버가 있을 수 있습니다.
모든 직원이 각 커넥터를 개별적으로 승인하도록 하는 것은 바람직하지 않습니다.
엔터프라이즈 호스팅 권한 부여 확장을 통해 조직은 ID 공급자를 통해 액세스 제어를 중앙에서 관리할 수 있습니다.
지원되는 엔터프라이즈 IdP 방식에는 Microsoft Entra ID, Okta 및 기업 SSO 시스템과 같은 제품이 포함될 수 있습니다.
조직은 어떤 직원이 어떤 MCP 서버에 액세스할 수 있는지, 그리고 액세스 권한을 언제 취소해야 하는지 결정할 수 있습니다.
직원은 각 MCP 서버에 대해 별도의 OAuth 승인을 완료할 필요 없이 기업 ID로 인증합니다.
공식 MCP 문서는 엔터프라이즈 호스팅 권한 부여를 모든 클라이언트에서 기본적으로 활성화되는 기능이 아닌 확장으로 설명합니다.
클라이언트와 조직의 ID 인프라 모두 이 확장을 지원해야 합니다.
권한 부여 메커니즘의 광범위한 강화
핵심 권한 부여 작업에는 여러 보안 개선 사항도 추가되었습니다.
RFC 9207 발급자 검증
권한 부여 응답에는 iss 발급자 매개변수가 포함될 수 있습니다.
클라이언트는 권한 부여 코드를 교환하기 전에 발급자를 검증합니다.
이는 권한 부여 서버 혼동 공격을 방지하는 데 도움이 됩니다.
클라이언트 자격 증명과 발급자 바인딩
등록된 클라이언트 자격 증명은 관련 없는 권한 부여 서버 간에 재사용되어서는 안 됩니다.
리소스가 다른 발급자로 이전되면 클라이언트는 해당 발급자에 대해 적절히 등록해야 합니다.
개선된 데스크톱 및 CLI 등록
이 개정판은 동적 클라이언트 등록 중 application_type의 동작을 명확히 합니다.
이는 권한 부여 서버가 네이티브 CLI 또는 데스크톱 애플리케이션을 웹 클라이언트로 오인하여 로컬 리디렉션 URI를 거부하는 상황을 방지하는 데 도움이 됩니다.
CIMD는 새로운 클라이언트 등록 지침
MCP 권한 부여 프로젝트는 새로운 구현을 위해 클라이언트 ID 메타데이터 문서(Client ID Metadata Documents, CIMD) 방향으로 추진해 왔으며, 필요한 곳에서는 DCR 호환성을 유지합니다.
실질적인 권장 사항은 이전 MCP 튜토리얼에 따라 클라이언트 등록을 구현하는 대신 현재 권한 부여 문서를 따르는 것입니다.
도구의 전체 JSON Schema 2020-12
도구 스키마도 더욱 표현력이 풍부해졌습니다.
inputSchema와 outputSchema는 전체 JSON Schema 2020-12 기능을 지원합니다.
입력 스키마는 다음을 사용할 수 있습니다:
oneOf
anyOf
allOf
$ref
$defs
조건문
출력 스키마는 더 이상 단일한 좁은 객체 형태로 제한되지 않습니다.
structuredContent는 스키마가 지원하는 모든 JSON 값을 나타낼 수 있습니다.
이는 API에 유니온 타입, 조건부 필드, 중첩된 재사용 가능한 정의, 여러 출력 형태, 배열 또는 스칼라 결과가 있을 때 MCP 도구가 이를 더 정확하게 설명할 수 있게 한다.
Roots, Sampling 및 Logging은 더 이상 사용되지 않음
세 가지 이전 핵심 기능이 공식적으로 더 이상 사용되지 않음(Deprecated)으로 지정되었다:
| 기능 | 권장 방향 |
|---|---|
| Roots | 도구 매개변수, 리소스 URI 또는 서버 구성 |
| Sampling | LLM 제공자와의 직접 통합 |
| Logging | stdio는 stderr 사용, 구조적 관찰 가능성은 OpenTelemetry 사용 |
더 이상 사용되지 않음(Deprecation)이 즉시 제거를 의미하는 것은 아니다.
새로운 수명 주기 정책에 따르면, 더 이상 사용되지 않는 기능은 제거가 허용되기 전에 최소 12개월의 전환 기간을 가져야 한다.
현재 SDK는 호환성 유지를 위해 이러한 기능을 계속 지원할 수 있다.
공식적인 폐지 정책이 MCP 업그레이드 리스크를 변화시킴
무상태(Stateless) 재설계에는 파괴적 변경이 포함되어 있다.
유지보수자들은 이러한 수준의 중단이 일반적인 상황이 되지 않기를 원한다고 밝혔다.
새로운 기능 수명 주기는 다음 단계를 정의한다:
활성(Active)
더 이상 사용되지 않음(Deprecated)
제거됨(Removed)
더 이상 사용되지 않는 기능은 제거 전에 최소 지원 기간을 보장받는다.
확장 기능은 핵심과 분리되어 독립적으로 발전할 수도 있다.
이는 팀에게 더 예측 가능한 마이그레이션 계획을 제공한다.
MCP 터널은 다른 기업 문제를 해결함
프로토콜 개정으로 공용 원격 MCP 서버를 더 쉽게 확장할 수 있게 되었다.
기업은 일반적으로 정반대의 문제에 직면한다: 서버를 공개적으로 노출하고 싶지 않다는 것이다.
Anthropic의 MCP 터널 기능은 Claude 호스팅 에이전트 및 지원되는 Claude 플랫폼 워크플로우를 위한 이 사용 사례를 해결한다.
경량 게이트웨이가 기업 네트워크 내부에서 실행되며 아웃바운드 연결을 설정한다.
Anthropic은 이 패턴을 다음과 같이 설명한다:
- 공용 MCP 엔드포인트 없음.
- 인바운드 방화벽 규칙 없음.
- 공용 IP 불필요.
- 종단 간 암호화된 트래픽.
내부 데이터베이스, ERP 시스템, 비공개 API, 지식 베이스 및 티켓 시스템은 기업 네트워크 경계 내에 유지될 수 있다.
MCP 터널은 여전히 핵심 MCP 프로토콜 요구 사항이 아닌 Claude의 제품 기능이다.
Anthropic은 현재 이를 연구 미리보기(Research Preview) 로 설명한다.
MCP 앱과 터널을 혼동해서는 안 됨
두 기능 모두 프로덕션 환경에서 MCP를 개선하지만 서로 다른 문제를 해결한다.
| 기능 | 해결하는 문제 |
|---|---|
| MCP 앱 | MCP 호스트 내 풍부한 상호작용 인터페이스 |
| 작업(Tasks) | 지속적인 장기 실행 도구 작업 |
| 엔터프라이즈 호스팅 권한 부여 | 중앙 집중식 회사 |
액세스 정책 |
| MCP 터널 | 공개 노출 없이 비공개 MCP 서버에 액세스 |
| 무상태 MCP 핵심 | 확장 가능한 프로토콜 전송 |
| MRTR | 장기 프로토콜 세션 없이 통화 중 클라이언트 입력 |
서버는 이러한 기능 중 하나, 여러 개 또는 전부를 사용할 수 있다.
기존 MCP 서버 개발자는 무엇을 변경해야 하는가?
서버가 이미 이전 MCP 클라이언트와 함께 작동한다면 개발자가 모든 것을 즉시 다시 작성할 필요는 없다.
구조화된 마이그레이션을 수행해야 한다.
1단계: 숨겨진 세션 의존성 파악
다음에 의존하는 코드를 검색하라:
Mcp-Session-Id- 메모리 내 세션별 사전
- 고정 라우팅(Sticky Routing)
- 연결 로컬 클라이언트 상태
- 초기화 전용 기능 저장소
- 서버 인스턴스 선호도(Affinity)
각 의존성이 프로토콜 상태, 애플리케이션 상태, 인증 상태 또는 임시 실행 상태인지 판단하라.
애플리케이션 상태는 명시적 핸들 또는 적절한 영구 저장소로 이동하라.
2단계: 무상태 요청 처리 테스트
2026-07-28 개정판을 지원하는 SDK 버전을 사용하라.
그런 다음 여러 서버 인스턴스로 테스트하라.
유용한 테스트 구성 중 하나는 다음과 같다:
클라이언트
↓
라운드 로빈 로드 밸런서
↓
서버 A / 서버 B / 서버 C
다단계 워크플로우를 전송하여 연속 요청이 작업을 중단하지 않고 다른 인스턴스에 도달할 수 있는지 확인하라.
3단계: 명시적 상태 핸들 추가
상태가 필요한 워크플로우의 경우 안정적인 식별자를 반환하라:
{
"job_id": "job_7f18c9"
}
후속 호출이 해당 식별자를 포함하도록 요구하라:
{
"job_id": "job_7f18c9",
"action": "continue"
}
서버 측에서 각 핸들을 검증하라.
좋은 핸들은 강력한 엔트로피, 테넌트 바인딩, 권한 부여 검사, 만료 시간, 취소 메커니즘 및 명확한 오류 처리를 갖추어야 한다.
4단계: 게이트웨이 규칙 업데이트
Streamable HTTP를 사용하는 경우 다음 헤더를 활용하라:
Mcp-Method
Mcp-Name
라우팅, 속도 제한, 메트릭, WAF 정책 및 액세스 로그를 추가하라.
5단계: 캐시 지원 추가
적절한 목록 및 읽기 응답에 대해 다음을 따르거나 생성하라:
ttlMs
cacheScope
사용자별 데이터와 관련된 민감한 캐시 콘텐츠를 사용자 간에 공유하지 말라.
6단계: 이전 작업 마이그레이션
애플리케이션이 실험적인 2025-11-25 Tasks API를 사용했다면 이를 확장 수명 주기로 업데이트하라.
테스트:
tasks/get
tasks/update
tasks/cancel
및 input_required 상태.
7단계: 더 이상 사용되지 않는 기능 검토
Roots, Sampling 및 MCP Logging을 검색하라.
명시적 도구 매개변수 또는 리소스 URI, 직접 모델 제공자 호출, stderr 또는 OpenTelemetry로의 마이그레이션을 계획하라.
8단계: 권한 부여 재테스트
발급자 검증, 리디렉션 URI, 클라이언트 등록, 새로 고침 토큰, 범위 처리 및 ID 공급자 호환성을 검증하라.
엔터프라이즈 배포는 EMA 적용 여부를 평가해야 한다.
9단계: 이전 클라이언트 테스트
하위 호환성은 서버만의 문제가 아닌 생태계 문제다.
테스트 매트릭스를 유지하라:
| 클라이언트 | 프로토콜 개정판 | 결과 |
|---|---|---|
| 현재 클라이언트 | 2026-07-28 |
예상 무상태 경로 |
| 이전 클라이언트 | 2025-11-25 |
호환성 경로 |
| 지원되지 않는 클라이언트 | 이전 버전/알 수 없음 | 명확한 협상 실패 |
모든 클라이언트가 동시에 업그레이드된다고 조용히 가정하지 말라.
10단계: 프로덕션 전 관찰 가능성 추가
최소한 다음을 측정해야 한다:
- 요청 수.
- 도구 이름.
- 지연 시간.
- 오류율.
- 작업 지속 시간.
- 입력 요청 빈도.
- 캐시 적중률.
- 인증 실패 횟수.
- 다운스트림 API 지연 시간.
- 추적 ID.
무상태 시스템은 확장이 더 쉽지만 분산 시스템은 여전히 좋은 관찰 가능성이 필요하다.
예시: 마이그레이션 전후 비교
마이그레이션 전
서버가 보고서 객체를 메모리에 저장한다:
sessions[session_id]["report"] = report
다음 도구 호출이 동일한 프로세스에 도달할 것으로 예상한다.
마이그레이션 후
서버가 영구 상태를 저장한다:
report_id = save_report(report)
return {"report_id": report_id}
다음 도구가 다음을 수신한다:
{
"report_id": "report_123"
}
모든 서버 인스턴스가 해당 보고서를 로드할 수 있다.
중요한 변화는 아키텍처 수준에서 이루어진다:
숨겨진 전송 세션 상태
→ 명시적 애플리케이션 상태
무상태 MCP가 더 낮은 비용을 의미하는가?
가능성은 있지만 자동으로 실현되지는 않는다.
무상태 배포는 인프라 복잡성을 줄일 수 있다:
- 공유 MCP 세션 저장소 불필요.
- 고정 라우팅 요구 감소.
- 자동 확장 용이.
- 서버리스 배포 용이.
- 장애 조치 단순화.
캐싱은 또한 반복적인 메타데이터 호출을 줄일 수 있다.
그러나 애플리케이션 상태는 여전히 비용이 든다.
워크플로우에 영구 상태가 필요한 경우 개발자는 여전히 Redis, SQL 데이터베이스, 객체 저장소, 작업 큐 또는 워크플로우 엔진이 필요할 수 있다.
새로운 설계는 개발자가 저장 아키텍처를 선택할 수 있게 해주며, 프로토콜 세션이 하나를 강제로 지정하지 않습니다.
MCP가 'AI 분야의 HTTP'가 되고 있는가?
원문 기사에서 이 비유를 사용했습니다.
이 비유는 유용하지만 문자 그대로 해석해서는 안 됩니다.
HTTP는 거의 모든 인터넷 시스템에서 사용되는 기본적인 웹 전송 표준입니다.
MCP는 AI 클라이언트와 에이전트를 도구, 리소스, 프롬프트, 인터페이스 및 외부 서비스에 연결하기 위한 특수 목적 프로토콜입니다.
이 비유가 포착하는 것은 발전 방향입니다:
- 표준 인터페이스.
- 다수의 독립 서버.
- 다수의 호환 클라이언트.
- 공유된 규약.
- 요청을 범용적으로 라우팅하고 관찰할 수 있는 인프라.
2026-07-28 재설계는 MCP 트래픽이 이제 기존의 무상태 HTTP 인프라에 더 자연스럽게 맞기 때문에 이 비유를 강화합니다.
MCP가 HTTP 수준의 보편성에 도달할 수 있을지는 여전히 미해결 과제입니다.
생태계는 Claude보다 더 광범위함
MCP는 Anthropic에서 시작되었지만, 현재는 더 넓은 오픈소스 프로토콜 프로젝트로 관리되고 있습니다.
이 생태계에는 독립 유지관리자, 워킹 그룹, 사양 개선 제안, 다양한 언어의 SDK, MCP 앱, 태스크, 엔터프라이즈 권한 부여 확장, 레지스트리 및 여러 AI 제품에서의 구현이 포함됩니다.
예를 들어, MCP 앱은 MCP 커뮤니티 기여자 및 Anthropic, OpenAI, MCP-UI 참가자들과 공동 개발되었습니다.
이것은 클라이언트와 서버 모두 단일 공급업체에 의존하지 않고 프로토콜을 구현할 수 있을 때 프로토콜의 가치가 더 커지기 때문에 중요합니다.
현재 SDK 현황
공식 MCP 프로젝트는 여러 언어의 SDK 구현을 유지 관리하거나 승인합니다.
주요 저장소에는 TypeScript, Python, Go, C# 및 기타 생태계용 SDK가 포함됩니다.
2026년 6월
릴리스 후보 발표는 4개의 1급 SDK에 대한 베타 지원을 특별히 강조했습니다:
- TypeScript.
- Python.
- Go.
- C#.
7월 하순까지 현재 SDK 문서에는 2026-07-28 동작이 포함되어 있습니다.
SDK 채택은 독립적으로 이루어지므로, 사용 중인 정확한 언어와 버전의 릴리스 노트를 항상 확인하세요.
더 안전한 마이그레이션 전략
프로덕션 시스템의 경우 '전환일' 방식의 마이그레이션을 피하세요.
더 안전한 프로세스는 다음과 같습니다:
- 개발 환경을 업그레이드합니다.
- 일관성 테스트를 실행합니다.
2026-07-28클라이언트를 테스트합니다.- 이전 버전 클라이언트를 테스트합니다.
- 사전 릴리스 환경에서 무상태 배포를 활성화합니다.
- 여러 서버 인스턴스를 추가합니다.
- 요청이 인스턴스 간 분산되도록 강제합니다.
- 인증을 테스트합니다.
- 장기 실행 작업을 테스트합니다.
- 애플리케이션 상태 핸들을 테스트합니다.
- 지연 시간과 오류를 모니터링합니다.
- 점진적으로 출시합니다.
새 개정판이 의도적으로 핵심 수명주기 동작을 변경했기 때문에 이는 특히 중요합니다.
가정해서는 안 되는 사항
모든 서버가 자동으로 서버리스화된다고 가정하지 마세요
이 프로토콜은 서버리스 배포를 더 자연스럽게 지원합니다.
애플리케이션에는 여전히 데이터베이스, 영속적 작업 실행기, 파일 저장소 또는 더 긴 실행 시간이 필요할 수 있습니다.
모든 상태가 사라진다고 가정하지 마세요
프로토콜 수준 세션 상태만 새로운 온라인 모델에서 제거됩니다.
애플리케이션 상태는 여전히 애플리케이션 자체의 문제입니다.
MCP 앱이 모든 클라이언트에서 실행된다고 가정하지 마세요
확장 기능은 협상을 통해 결정되며 호스트별 지원이 다릅니다.
태스크가 이전 버전과 호환된다고 가정하지 마세요
현재 Tasks 확장은 초기 실험적 구현과 다릅니다.
더 이상 사용되지 않음이 비활성화를 의미한다고 가정하지 마세요
Roots, Sampling 및 Logging은 지원 중단 기간 동안 계속 사용할 수 있습니다.
모든 클라이언트가 2026-07-28을 이미 지원한다고 가정하지 마세요
SDK와 제품의 채택 진행 속도는 각기 다릅니다.
'개방형 프로토콜'이 '보안 작업 불필요'를 의미한다고 가정하지 마세요
MCP는 강력한 도구를 실행할 수 있습니다.
권한 부여, 사용자 동의, 샌드박싱, 도구 설계, 비밀 관리 및 감사는 여전히 필수적입니다.
자주 묻는 질문
MCP 2026-07-28이란 무엇인가요?
MCP 2026-07-28은 출시 이후 모델 컨텍스트 프로토콜의 가장 큰 아키텍처 개정입니다. 주요 변경 사항으로는 무상태 프로토콜 코어, 새 온라인 형식의 세션 핸드셰이크 제거, 1급 확장, MCP 앱, 재설계된 Tasks, MRTR, 강화된 권한 부여, 캐시 메타데이터 및 공식 지원 중단 정책이 포함됩니다.
MCP는 이제 완전히 무상태인가요?
2026-07-28 프로토콜 계층은 무상태로 설계되었습니다. 애플리케이션은 명시적 핸들, 데이터베이스, 워크플로 시스템 또는 기타 영속적 저장소를 통해 상태를 유지할 수 있습니다.
Mcp-Session-Id는 어떻게 변경되었나요?
2026-07-28 온라인 형식은 프로토콜 수준의 Mcp-Session-Id 메커니즘을 제거했습니다. 현재 SDK는 이전 프로토콜 개정판을 협상할 때 하위 호환성을 위해 세션 기반 동작을 계속 지원할 수 있습니다.
AWS Lambda 또는 Cloudflare Workers에 MCP 서버를 배포할 수 있나요?
무상태 프로토콜은 요청에 더 이상 프로토콜 수준 세션 선호도가 필요하지 않으므로 서버리스 및 엣지 배포를 더 쉽게 만듭니다. 서버는 여전히 런타임의 실행, 네트워크, 저장 및 기간 제한을 충족해야 합니다.
MCP 앱이란 무엇인가요?
MCP 앱은 호환 MCP 호스트에서 도구가 대시보드, 양식, 차트 및 기타 HTML 경험과 같은 대화형 인터페이스를 반환할 수 있게 하는 공식 확장입니다. 이 인터페이스는 샌드박스 처리된 iframe에서 실행되며 MCP 호스트를 통해 통신합니다.
MCP 태스크란 무엇인가요?
태스크 기능은 서버가 장기 실행 작업을 위해 영속적 비동기 태스크 핸들을 반환할 수 있게 합니다. 클라이언트는 tasks/get으로 상태를 폴링하고, tasks/update로 필요한 입력을 제공하거나, tasks/cancel로 작업을 취소할 수 있습니다.
엔터프라이즈 호스팅 권한 부여란 무엇인가요?
엔터프라이즈 호스팅 권한 부여는 조직의 ID 공급자를 통해 중앙 집중식 액세스 제어를 구현하는 MCP 확장입니다. IT 관리자가 엔터프라이즈 ID 정책에 따라 MCP 서버 액세스를 관리할 수 있게 하며, 사용자가 각 서버를 개별적으로 승인할 필요가 없습니다.
기존 MCP에서 즉시 마이그레이션해야 하나요?
반드시 그렇지는 않습니다. SDK는 버전 협상을 통해 이전 프로토콜 개정판을 지원할 수 있으며, 더 이상 사용되지 않는 기능은 명확한 지원 기간을 받습니다. 프로덕션 팀은 무상태 설계가 세션, 장기 실행 작업 및 인프라에 대한 가정을 변경하므로 테스트를 시작해야 합니다.
관련 도구
- Model Context Protocol: MCP 사양, 아키텍처, SDK, 확장 및 개발자 가이드의 공식 문서.
- MCP TypeScript SDK: MCP 클라이언트 및 서버용 공식 TypeScript 구현.
- MCP Python SDK: MCP 개발용 공식 Python SDK 및 예제.
- MCP Go SDK: 공식 Go 구현으로, 현재 무상태 프로토콜 경로를 지원합니다.
- MCP C# SDK: 무상태 모드, 태스크 및 호환성에 대한 상세 문서가 포함된 공식 .NET SDK.
- MCP Apps: MCP 호스트 내 대화형 인터페이스를 위한 공식 확장 문서 및 SDK.
- MCP Tasks: 장기 실행 비동기 MCP 작업을 위한 공식 문서.
- [MCP Registry](https://registry.modelcontextprotocol.
io/): 게시된 MCP 서버를 발견하기 위한 공식 레지스트리 인프라입니다.
관련 링크
- MCP 2026-07-28 릴리스 후보 개요: 공식 유지관리자가 무상태 리팩토링, 확장, 인증 변경, 캐싱 및 폐기 내용에 대해 설명합니다.
- MCP 사양 저장소 릴리스: 프로토콜 개정판의 공식 GitHub 릴리스 기록입니다.
- MCP 2026 로드맵: 전송 확장성, 에이전트 통신, 거버넌스 및 엔터프라이즈 대비를 다루는 공식 로드맵입니다.
- MCP 앱 공식 문서: 인터랙티브 MCP 애플리케이션의 사양, SDK, 예제 및 개발자 가이드입니다.
- MCP 태스크 확장: 공식 태스크 사양, 수명 주기, 보안 모델 및 지원되는 메서드입니다.
- 엔터프라이즈 관리형 인증: 중앙 집중식 ID 공급자 기반 MCP 액세스에 대한 공식 문서입니다.
- Anthropic MCP 터널: Claude 관리형 에이전트의 프라이빗 네트워크 MCP 연결에 대한 Anthropic 문서입니다.
요약
MCP 2026-07-28 개정판은 프로토콜을 대규모 웹 시스템에서 이미 널리 채택된 인프라 패턴으로 이끕니다. 요청은 자체 포함되며, 프로토콜 수준 세션은 새로운 온라인 형식에서 사라지고, 게이트웨이 라우팅은 더 쉬워지며, 일반적인 수평 확장은 더 이상 고정 MCP 세션을 요구하지 않습니다.
동시에 생태계도 상향 성장하고 있습니다. MCP 앱은 인터랙티브 UI를 추가하고, 태스크는 지속형 비동기 작업을 지원하며, 엔터프라이즈 관리형 인증은 기업 액세스를 중앙 집중화하고, MCP 터널은 Claude 플랫폼 사용자에게 내부 프라이빗 서버에 접근할 수 있는 경로를 제공합니다.
마이그레이션은 단순히 "세션 ID 삭제"가 아닙니다. 팀은 숨겨진 상태 의존성을 식별하고, 애플리케이션 상태를 명시적 핸들이나 영구 저장소로 이전하며, MRTR 및 태스크를 테스트하고, 인증을 업데이트하며, 이전 클라이언트와의 호환성을 유지하고, 적절한 관측성을 추가해야 합니다.
가장 중요한 변화는 아키텍처 차원입니다. MCP는 연결 지향적 에이전트 통합 패턴에서 현대 클라우드 인프라에 더 자연스럽게 맞는 무상태, 확장 가능한 프로토콜로 전환되고 있습니다.