Amazon AWS, Stateless MCP 지원… 이제 진짜 시험대는 호환성

Amazon AWS는 사양의 최대 규모 아키텍처 개편이 안정 릴리스에 도달한 지 이틀 만에 AgentCore Gateway에 MCP 2026-07-28 지원을 추가했다. 하나의 UpdateGateway 호출로 기존 게이트웨이에서 새 프로토콜 버전을 활성화할 수 있다. 그러나 이 단순한 컨트롤 플레인 변경 뒤에는 클라이언트, 서버, 엔터프라이즈 보안팀이 해결해야 할 더 까다로운 전환 과제가 숨어 있다.

새로운 Model Context Protocol 개정판은 프로토콜 수준의 세션을 제거하고, 모든 요청이 자체 버전과 클라이언트 기능을 기술하도록 바꿨다. MCP는 AI 애플리케이션을 도구, 데이터 소스 및 기타 서비스에 연결하는 개방형 표준이다. 상태 비저장 설계는 게이트웨이의 확장, 라우팅, 복구를 더 쉽게 만들 것으로 기대된다.

이 이점에는 호환성 검증이 따른다. 클라이언트는 새 요청 메타데이터를 채택해야 하고, 서버는 디스커버리를 구현해야 하며, 기존 세션 가정은 더 이상 유효하지 않다. Amazon Bedrock AgentCore Gateway는 이제 이 두 프로토콜 시대 사이에 위치해, 엔터프라이즈 서비스를 MCP 도구로 변환하는 동시에 하나의 관리형 엔드포인트에서 접근 제어를 적용한다.

따라서 진짜 이야기는 단순한 버전 체크박스보다 훨씬 크다. Amazon AWS는 관리형 게이트웨이가 프로토콜 변화가 모든 애플리케이션 팀에 닿기 전에 이를 흡수할 수 있다는 데 베팅하고 있다. 이것이 효과를 낼지는 버전 협상, 인가의 정확성, 그리고 혼합된 클라이언트 환경의 동작에 달려 있다.

Amazon AWS, 대규모 MCP 재작성 과정을 한 번의 게이트웨이 업데이트로 전환

AWS는 인프라 단계를 하나의 API 작업으로 줄였지만, 애플리케이션은 여전히 개정된 프로토콜을 정확히 구사해야 한다.

MCP 유지보수팀은 5월에 시작된 릴리스 후보 기간을 거쳐 7월 28일 안정 버전인 2026-07-28 사양을 공개했다. 안정 MCP 릴리스는 프로토콜 초기 성장 과정에서 자리 잡은 여러 가정을 대체한다.

AWS는 이어 Amazon Bedrock AgentCore Gateway 지원을 제공했다. 회사의 AgentCore 업데이트에 따르면, 게이트웨이 소유자는 UpdateGateway를 통해 새 개정판을 추가할 수 있다. 이 요청은 게이트웨이의 MCP 프로토콜 구성과 지원 버전 목록을 업데이트한다.

관련 컨트롤 플레인 객체는 protocolConfiguration.mcp.supportedVersions다. AWS는 이 필드를 게이트웨이가 사용할 수 있는 MCP 버전 배열로 문서화한다. 서비스가 업데이트를 수락하면 UpdateGateway는 HTTP 상태 202를 반환하며, 이후 게이트웨이는 업데이트 상태를 거친다.

이 구분은 운영 측면에서 중요하다. 호출이 수락되었다고 해서 연결된 모든 클라이언트가 성공적으로 요청을 완료했다는 뜻은 아니다. 팀은 게이트웨이가 준비 상태로 돌아올 때까지 기다린 뒤, 실제 엔드포인트를 대상으로 적합성 및 워크로드 테스트를 실행해야 한다.

이 변경으로 조직이 게이트웨이 뒤의 모든 Lambda 함수, OpenAPI 서비스 또는 Smithy 서비스를 재구축할 필요는 없다. AgentCore Gateway는 이미 이러한 리소스를 MCP 호환 도구로 변환한다. 대상 구성에 따라 원격 MCP 대상과 기타 HTTP 서비스도 지원한다.

이 아키텍처는 AWS가 각 하위 비즈니스 서비스에 동일한 변경을 요구하지 않고도 프로토콜 대면 계층을 바꿀 수 있게 한다. 예를 들어 고객 지원 API는 API로 유지하면서, 게이트웨이가 호환되는 에이전트에 작업을 도구로 노출할 수 있다.

AgentCore Gateway는 인바운드 인증, 아웃바운드 자격 증명, 도구 디스커버리, 라우팅 및 정책 적용도 처리한다. 하나의 엔드포인트가 여러 내부 팀이 소유한 서비스를 전면에 둘 때 이러한 제어 기능의 가치는 더 커진다.

그럼에도 UpdateGateway 호출은 게이트웨이가 선언한 지원 범위만 바꾼다. 2026 개정판을 사용하는 클라이언트는 여전히 필수 메타데이터와 헤더를 전송해야 한다. 기존 클라이언트는 상호 지원되는 개정판을 협상하거나 호환 가능한 대체 경로를 사용해야 한다.

이것이 AWS의 간단한 업그레이드 메시지 뒤에 놓인 첫 번째 제약이다. 관리형 서비스는 플랫폼 작업을 줄일 수 있지만, 오래된 SDK가 새 와이어 포맷을 출력하게 만들 수는 없다.

두 번째 제약은 테스트와 관련된다. 게이트웨이 소유자는 지원되는 각 버전에서 도구 목록, 도구 호출, 인증 실패, 스트리밍 동작 및 캐시 제어를 검증해야 한다. 하나의 최신 클라이언트에서 성공했다고 해서 엔터프라이즈 전체 클라이언트 환경의 호환성이 입증되는 것은 아니다.

따라서 실질적인 롤아웃은 인벤토리 파악에서 시작한다. 팀은 어떤 에이전트 애플리케이션이 게이트웨이에 연결되는지, 어떤 SDK 버전을 사용하는지, 그리고 해당 SDK가 MCP 2026-07-28을 지원하는지 식별해야 한다.

기술 의사결정과 테스트 증거를 검색 가능한 엔지니어링 지식 베이스에 관리하는 조직은 클라이언트와 프로토콜 버전별 결과를 기록할 수 있다. 이 기록은 장애가 특정 프레임워크나 배포 채널에서만 발생할 때 중요해진다.

AWS는 컨트롤 플레인 작업을 작게 만들었다. 애플리케이션 수준의 검증은 여전히 실제 마이그레이션 프로젝트로 남아 있다.

Stateless MCP가 게이트웨이 구도를 바꾸는 이유

Stateless MCP는 호환성 정보를 모든 요청으로 옮겨 수평 라우팅을 단순화하는 한편, 각 메시지가 독립적으로 완결되도록 요구한다.

이전 MCP 개정판은 프로토콜 세부 정보와 기능을 설정하기 위해 초기화 교환을 사용했다. 클라이언트가 initialize를 전송하면 서버가 응답했고, 클라이언트는 notifications/initialized로 시퀀스를 완료했다. Streamable HTTP는 이후 트래픽을 프로토콜 수준 세션과 연결하기 위해 Mcp-Session-Id 헤더를 사용할 수도 있었다.

MCP 주요 변경 사항은 새 개정판에서 이 수명 주기를 제거한다. 또한 프로토콜 수준 세션 식별자도 제거한다. 호출 간 상태가 필요한 서버는 클라이언트가 일반 도구 인수로 전달하는 명시적 핸들을 발급해야 한다.

모든 새 스타일 요청은 _meta 내부에 프로토콜 버전과 클라이언트 기능을 담는다. 클라이언트는 그곳에서 자신을 식별해야 하며, 서버는 결과 메타데이터 안에 자신의 정체성을 반환한다. 이로써 각 교환은 더 많은 정보를 자체적으로 설명하게 된다.

새로운 server/discover 메서드는 클라이언트가 다른 작업을 시작하기 전에 지원 버전, 기능 및 서버 정체성을 검사할 수 있게 한다. 2026-07-28 개정판을 사용하는 서버는 이 원격 프로시저 호출을 구현해야 한다.

이 설계는 게이트웨이가 기억해야 하는 내용을 바꾼다. 더 이상 하나의 연결을 통해 완료된 초기화 교환에 의존하거나, 이후 프로토콜 트래픽을 불투명한 MCP 세션과 연결할 필요가 없다.

로드 밸런서는 프로토콜 수준의 연결 친화성을 유지하지 않고도 개별 요청을 라우팅할 수 있다. 열 번째 호출을 받는 게이트웨이 인스턴스도 첫 번째 인스턴스가 받은 것과 동일한 핵심 호환성 정보를 검사할 수 있다.

이 모델은 관리형 클라우드 게이트웨이에 잘 맞는다. 상태 비저장 서비스는 모든 요청을 해석하기 전에 MCP 세션 레코드를 복원하지 않아도 워커 전반으로 확장하고, 비정상 용량을 교체하며, 트래픽을 분산할 수 있다.

또한 수명이 짧은 클라우드 인프라와 연결 지향적 프로토콜 동작 간의 불편한 불일치를 줄인다. 서버리스 함수와 분산 게이트웨이는 일반적으로 요청이 독립적 처리에 필요한 정보를 담을 때 가장 잘 작동한다.

다만 상태 비저장이라고 해서 에이전트의 작업에 상태가 전혀 없다는 의미는 아니다. 구매 워크플로에는 승인 정보, 거래 참조 또는 이전 교환에서 수집한 데이터가 여전히 필요할 수 있다. 이 사양은 그러한 상태를 전송 세션 안에 숨기는 대신 명시적인 애플리케이션 수준 핸들로 옮긴다.

이 전환은 가시성을 향상시킬 수 있다. 도구 인수와 서버 발급 핸들은 연결에서 추론되는 상태보다 더 명확한 소유권 경계를 만든다. 동시에 클라이언트가 요청을 재시도하거나 오래된 핸들을 제시할 수 있으므로 신중한 설계가 필요하다.

새 개정판은 Last-Event-ID 및 서버 전송 이벤트 식별자를 통한 Streamable HTTP 재개 가능성을 제거한다. 요청 중 응답 스트림이 끊기면 클라이언트는 새 요청 ID로 새 요청을 보내야 한다.

이 규칙은 중요한 운영상 질문을 만든다. 스트림이 실패하기 전에 도구가 부작용을 수행했다면, 애플리케이션이 멱등성을 구현하지 않는 한 무분별한 재시도가 작업을 반복할 수 있다.

지원 티켓을 생성하는 에이전트를 생각해 보자. 응답 스트림이 사라지는 동안 티켓 서비스는 레코드를 성공적으로 저장했을 수 있다. 재시도는 애플리케이션 수준의 멱등성 키를 포함하거나 다른 티켓을 생성하기 전에 이전 작업을 조회해야 한다.

AWS는 프로토콜 경계에서 모든 하위 멱등성 문제를 해결할 수 없다. 게이트웨이 로그와 추적은 반복 호출을 보여줄 수 있지만, 대상 서비스가 안전한 재시도 동작을 정의해야 한다.

이 개정판은 별도의 서버 시작 호출도 Multi Round-Trip Requests로 대체한다. 이 패턴에서 서버는 여전히 필요한 정보를 설명하는 input_required 결과를 반환한다. 클라이언트는 요청된 응답을 포함해 원래 요청을 재시도한다.

이 접근 방식은 제어를 요청 및 재시도 시퀀스 안에 유지한다. 다른 게이트웨이 인스턴스가 소유할 수 없는 연결을 통해 독립적인 서버-클라이언트 요청이 도착하는 일을 피한다.

이제 모든 결과에는 일반적으로 complete 또는 input_required인 resultType이 포함된다. 이전 서버와 통신하는 클라이언트는 누락된 값을 완료된 결과로 취급해야 하며, 이는 제한적인 호환성 연결 고리를 보존한다.

이 메커니즘은 분명히 분산 인프라를 선호한다. 그 대가로 SDK와 애플리케이션은 더 명시적인 메타데이터, 재시도 로직 및 상태 처리를 채택해야 한다.

압박은 SDK와 혼합된 클라이언트 환경에 쏠린다

AgentCore Gateway는 두 프로토콜 시대를 지원할 수 있지만, 각 조직은 자사 클라이언트가 올바른 버전을 협상한다는 점을 입증해야 한다.

즉각적인 압박 대상은 게이트웨이 뒤에 숨은 API가 아니다. MCP 엔드포인트에 연결하는 클라이언트 소프트웨어다.

2026-07-28 개정판을 표방하는 클라이언트는 각 요청에 프로토콜 버전과 기능을 전송해야 한다. server/discover, 필수 결과 유형 및 수정된 다단계 상호작용 처리를 이해해야 한다.

HTTP 클라이언트는 Mcp-Method와 Mcp-Name을 포함한 표준 MCP 요청 헤더도 사용해야 한다. 이러한 헤더를 통해 인프라는 모든 JSON-RPC 본문을 파싱하지 않고도 트래픽을 검사하고 라우팅할 수 있다.

이 변경은 게이트웨이, 관측성 시스템 및 보안 제어에 유용하다. 동시에 불완전한 클라이언트가 도구 실행 전에 실패할 수 있는 또 하나의 검증 지점을 만든다.

MCP는 이 새로운 경계를 위한 특정 오류를 정의한다. 헤더 불일치에는 코드 -32020이 사용되고, 필수 클라이언트 기능 누락에는 -32021, 지원되지 않는 프로토콜 버전에는 -32022가 사용된다.

이 코드는 플랫폼 팀에 더 명확한 장애 분류 체계를 제공한다. -32022 응답의 증가는 버전 협상 문제를 나타내며, -32020은 HTTP 헤더와 포함된 요청 간의 불일치를 가리킨다.

SDK 전환은 언어별로 동시에 일어나지 않을 것이다. 공식 구현체는 서로 다른 일정으로 안정 사양을 채택할 수 있으며, 애플리케이션은 새 릴리스가 나온 뒤에도 오랫동안 라이브러리 버전을 고정하는 경우가 많다.

엔터프라이즈에는 완전히 통제할 수 없는 클라이언트도 있다. 직원은 승인된 데스크톱 어시스턴트, 내부 명령줄 에이전트, 다른 팀이 만든 IDE 확장을 사용할 수 있다. 각각 MCP를 다르게 협상할 수 있다.

AgentCore의 지원 버전 목록은 이러한 혼합 환경을 위한 연결 고리를 제공한다. 게이트웨이는 모든 클라이언트에게 한 번에 새 와이어 포맷을 강제하는 대신 둘 이상의 개정판을 알릴 수 있다.

그 지원은 동일한 동작을 보장한다는 증거가 아니라 마이그레이션 메커니즘으로 취급해야 합니다. 2026 코어에서 제거된 기능은 이전 프로토콜 흐름에는 여전히 존재합니다. 이전 리비전을 협상한 뒤 통과한 테스트는 무상태 경로에 관해 거의 알려주지 않습니다.

Roots, Sampling, Logging은 이제 전체 사양에서 즉시 제거되는 대신 더 이상 사용되지 않는 기능으로 지정됩니다. 새 구현은 이를 채택하지 말아야 하며, 기존 구현에는 명확한 전환 기간이 제공됩니다.

MCP의 새 기능 수명 주기 정책은 최소 12개월의 사용 중단 기간을 정합니다. 이 거버넌스 변경으로 구현자는 비공식적인 사용 중단 문구보다 더 예측 가능한 사전 통지를 받을 수 있습니다.

프로토콜은 대안을 제시합니다. 애플리케이션은 Roots 대신 도구 매개변수나 리소스 식별자를 통해 디렉터리를 전달할 수 있습니다. 서버는 Sampling에 의존하는 대신 모델 제공업체 API를 직접 호출할 수 있습니다. 구현체는 프로토콜 Logging 대신 OpenTelemetry나 표준 오류 스트림을 사용할 수 있습니다.

이러한 대체는 단순한 문법이 아니라 아키텍처를 바꿉니다. 이전에 MCP 클라이언트를 통해 모델 샘플링을 요청하던 서버는 직접적인 제공업체 통합, 별도 자격 증명, 새로운 비용 제어 정책이 필요할 수 있습니다.

따라서 압력은 보안 및 재무 팀으로도 확장됩니다. 모델 접근 권한을 클라이언트 기능에서 서버로 옮기면 자격 증명이 저장되는 위치와 사용량이 표시되는 위치가 달라집니다.

게이트웨이 소유자는 클라이언트를 세 그룹으로 분류해야 합니다. 첫 번째 그룹은 2026 리비전을 완전히 지원합니다. 두 번째는 이전 안정 버전에서만 작동합니다. 세 번째는 동작이 불분명하며 테스트가 완료될 때까지 격리해야 합니다.

테스트는 tools/list를 넘어야 합니다. 유용한 매트릭스에는 탐색, 인증된 도구 호출, 거부된 범위, 응답 스트리밍, 중단된 요청, 목록 캐싱, 추가 사용자 입력이 필요한 애플리케이션이 포함됩니다.

팀은 텔레메트리에서 협상된 버전도 검증해야 합니다. 이 신호가 없으면 성공한 요청이 이전 프로토콜로의 예상치 못한 다운그레이드를 숨길 수 있습니다.

새 경로가 대표적인 프로덕션 워크로드를 처리할 때 마이그레이션은 성공합니다. 게이트웨이가 업데이트된 supportedVersions 필드를 수락한다는 이유만으로 성공한 것은 아닙니다.

확장 기능이 코어를 벗어나면서 인증은 더 엄격해진다

MCP 2026-07-28은 선택적 기능을 거버넌스와 협상이 적용되는 확장 시스템으로 옮기는 한편, 자격 증명 관련 모호성을 줄입니다.

개정된 인증 규칙은 에이전트가 여러 서버에 연결될 때 위험해지는 ID 경계에 초점을 맞춥니다. MCP 클라이언트는 여러 인증 서버에서 자격 증명을 얻을 수 있으며, 각각은 서로 다른 도구와 데이터를 보호합니다.

이제 사양은 클라이언트가 저장된 자격 증명을 이를 발급한 issuer에 연결해야 한다고 명시합니다. 클라이언트는 다른 인증 서버에 자격 증명을 재사용해서는 안 되며, issuer가 변경되면 다시 등록해야 합니다.

이 규칙은 자격 증명 혼동 문제를 다룹니다. 유사한 서버 이름, 리디렉션 또는 변경되는 메타데이터 때문에 한 서비스의 클라이언트 자격 증명이 다른 인증 경계로 전달되어서는 안 됩니다.

인증 서버는 인증 응답에 iss 값도 포함해야 합니다. 이 필드가 존재할 경우, 클라이언트는 인증 코드를 교환하기 전에 이를 미리 기록한 issuer와 대조해 검증해야 합니다.

이 검증은 인증 서버 혼동 공격을 방지하도록 설계된 Internet Engineering Task Force 표준인 RFC 9207을 따릅니다. 하나의 클라이언트가 여러 issuer와 상호작용하거나 인증 메타데이터를 동적으로 탐색할 때 이 검사는 중요합니다.

동적 클라이언트 등록도 더 엄격한 지침을 받습니다. MCP 클라이언트는 적절한 애플리케이션 유형을 지정해야 하며, 이를 통해 네이티브 및 웹 애플리케이션의 리디렉션 URI 규칙을 둘러싼 충돌을 줄입니다.

이러한 요구사항이 모든 배포를 자동으로 안전하게 만드는 것은 아닙니다. SDK 옵션은 여전히 올바르게 구성해야 하고, 저장된 자격 증명 레코드는 적절한 키 지정이 필요하며, ID 제공업체는 일관된 issuer 정보를 반환해야 합니다.

AgentCore Gateway는 인바운드 호출자를 인증하고 아웃바운드 자격 증명을 별도로 관리할 수 있으므로 유용한 집행 지점을 제공합니다. AWS 문서에 따르면 이 서비스는 사용자 지정 JSON Web Token 인증, AWS Identity and Access Management 및 기타 구성된 인증 모드를 지원합니다.

이 분리는 필수적입니다. 게이트웨이를 호출할 수 있는 ID가 그 뒤에 있는 모든 대상에 대해 자동으로 제한 없는 자격 증명을 받아서는 안 됩니다.

AgentCore는 게이트웨이에 정책 엔진을 연결할 수도 있습니다. 이 엔진은 에이전트 도구 호출을 평가하고 구성된 정책에 따라 각 작업을 허용할지 거부할지 결정합니다.

게이트웨이 모델이 최소 권한 원칙의 필요성을 없애지는 않습니다. 관리형 ID 서비스에 저장되더라도 범위가 넓은 대상 자격 증명은 여전히 범위가 넓습니다.

팀은 성공적인 호출만큼이나 부정 사례를 신중히 테스트해야 합니다. 범위가 불충분한 클라이언트는 무관한 프로토콜 오류나 인접 도구에 대한 접근이 아니라 통제된 인증 응답을 받아야 합니다.

확장 시스템은 병행되는 거버넌스 변화를 만듭니다. 이제 선택적 기능은 표준화된 식별자, 기능 선언 및 협상을 사용하면서 코어 프로토콜 외부에서 발전할 수 있습니다.

extensions framework에 따르면 공식 식별자는 io.modelcontextprotocol 접두사를 사용합니다. 제3자는 자신이 소유한 역순 도메인을 사용해야 하며, 이는 관련 없는 기능 간 충돌을 줄입니다.

클라이언트는 요청별 기능 안에서 지원하는 확장을 알립니다. 서버는 server/discover를 통해 자신이 지원하는 확장을 알립니다. 양측은 모두 명시적으로 옵트인해야 하며, 확장은 기본적으로 비활성화됩니다.

공식 확장에는 비동기 Tasks, 대화형 MCP Apps, OAuth 클라이언트 자격 증명, 엔터프라이즈 관리형 인증이 포함됩니다. 구현자가 사용하기 전에 코어가 모든 특수 기능을 흡수할 필요는 더 이상 없습니다.

이 구조는 코어 복잡성을 제한할 수 있습니다. 동시에 플랫폼 팀이 클라이언트, 서버, 게이트웨이, SDK 버전 전반에서 추적해야 하는 지원 매트릭스를 만듭니다.

대화형 인터페이스 확장을 지원하는 클라이언트는 서버가 원활히 기능을 축소할 수 있을 때도 의미 있는 텍스트 응답을 처리해야 합니다. 특정 인증 확장이 필요한 서버는 호환되지 않는 클라이언트를 대신 거부할 수 있습니다.

AgentCore Gateway의 첫 번째 의무는 올바른 코어 프로토콜 동작입니다. 2026 리비전 지원을 현재 또는 미래의 모든 확장에 대한 보편적 지원으로 해석해서는 안 됩니다.

이것이 AWS 발표의 핵심 불확실성입니다. 게이트웨이는 확장 기능 정보를 전달할 수 있지만, 고객은 워크플로가 의존하는 모든 확장에 대해 명시적인 문서와 테스트가 필요합니다.

인증 변경과 확장 프레임워크는 하나의 원칙을 공유합니다. 자격 증명 issuer, 클라이언트 기능, 선택적 동작에 관한 숨겨진 가정이 명시화되고 있습니다.

이러한 명시성은 엔터프라이즈 통제에 유리합니다. 하지만 불완전한 구성은 허용적인 통합 환경에서보다 더 눈에 띄게 실패하게 된다는 의미이기도 합니다.

Amazon AWS 고객이 여전히 입증해야 할 사항

다음 세 가지 신호는 협상된 버전 텔레메트리, 인증 실패의 품질, 실제 워크로드에서의 확장 지원입니다.

첫 번째 신호는 프로덕션 클라이언트가 실제로 MCP 2026-07-28을 협상하는지 여부입니다. 게이트웨이 구성만으로는 이 질문에 답할 수 없습니다.

팀은 단계적 롤아웃 이후 요청 메타데이터와 프로토콜 관련 오류를 모니터링해야 합니다. 클라이언트 이름, 클라이언트 버전, 프레임워크, 배포 채널별로 결과를 비교해야 합니다.

지원되지 않는 버전 및 헤더 불일치 오류 비율이 감소하면 AWS의 관리형 마이그레이션 사례가 더 설득력을 얻습니다. 오류가 지속된다면 병목은 게이트웨이 가용성이 아니라 클라이언트 SDK 채택임을 보여줄 것입니다.

다운그레이드도 동등한 주의를 받을 만합니다. 이전 리비전으로 조용히 폴백하는 클라이언트는 해결되지 않은 마이그레이션 문제를 숨긴 채 워크플로를 계속 실행할 수 있습니다.

조직은 테스트한 각 클라이언트에 대해 예상 리비전을 정의해야 합니다. 그러면 경고는 승인된 호환성 폴백과 의도하지 않은 다운그레이드를 구분할 수 있습니다.

두 번째 신호는 여러 ID 제공업체와 대상 전반에서 인증 실패가 어떻게 동작하는지입니다. 팀은 issuer 변경, 잘못된 iss 값, 만료된 토큰, 불충분한 범위, 자격 증명 재사용 시도를 테스트해야 합니다.

가장 안전한 결과는 대상이 실행되기 전의 정확한 거부입니다. 로그는 호출자에게 비밀 정보를 노출하지 않으면서 관련된 정책 또는 인증 경계를 식별해야 합니다.

명확한 부정 테스트 결과는 AgentCore가 사용자 지정 보안 작업을 줄인다는 주장에 힘을 실어줄 것입니다. 혼란스러운 실패나 일관되지 않은 issuer 처리는 특히 여러 사업 부문에 걸친 게이트웨이에서 그 주장을 약화할 것입니다.

세 번째 신호는 확장 상호운용성입니다. Tasks, MCP Apps 또는 인증 확장을 사용하는 워크플로는 확장별 동작을 호출하기 전에 기능을 검증해야 합니다.

테스트에는 원활한 기능 축소가 포함되어야 합니다. UI를 지원하지 않는 클라이언트도 서버가 폴백을 약속한다면 유용한 코어 콘텐츠를 받아야 합니다.

반대 사례도 중요합니다. 안전한 운영을 위해 확장이 필수라면 서버는 부분 워크플로를 시도하는 대신 요청을 명확히 거부해야 합니다.

이 세 가지 우선순위 아래에는 더 광범위한 운영 신호가 있습니다. 새 리비전이 스트림 재개 기능을 제거하므로, 팀은 중단된 부작용 발생 호출에서 중복 작업이 발생하는지 살펴봐야 합니다.

캐싱도 검토해야 합니다. 이제 목록과 리소스 결과에는 밀리초 단위로 측정되는 신선도 힌트인 ttlMs와 공개 캐시 가능 여부와 비공개 캐시 가능 여부를 구분하는 cacheScope가 포함됩니다.

결정론적인 도구 순서는 클라이언트 측 및 모델 프롬프트 캐싱을 개선할 수 있습니다. 그러나 오래된 도구 설명은 에이전트가 구식 스키마를 호출하게 만들 수 있으므로, 대상 업데이트 중 캐시 동작을 테스트해야 합니다.

관측성에는 분산 추적 컨텍스트가 포함되어야 합니다. 사양은 traceparent, tracestate, baggage에 대한 _meta 규칙을 문서화하여 팀이 클라이언트, 게이트웨이, 대상 전반에서 작업을 추적할 수 있도록 돕습니다.

이 추적은 재시도 중 특히 유용해집니다. 운영자는 이를 하나의 JSON-RPC 요청 ID로 취급하지 않으면서 원래 실패한 스트림과 새로 발행된 요청을 연결해야 합니다.

이러한 문제가 한데 모일 때 관리형 게이트웨이의 가장 강력한 가치가 나타납니다. 하나의 엔드포인트가 호출자를 인증하고, 정책을 적용하고, 프로토콜 트래픽을 변환하고, 도구를 선택하고, 대상 자격 증명을 주입하고, 감사 증거를 생성할 수 있습니다.

주요 위험도 바로 그 지점에서 나타납니다. 게이트웨이는 영향력이 큰 제어 지점이 되므로 구성 실수 하나가 많은 에이전트와 서비스에 동시에 영향을 미칠 수 있습니다.

신중한 롤아웃은 비핵심 게이트웨이 또는 제한된 클라이언트 코호트에서 시작해야 합니다. 팀은 새 지원 버전을 추가하고, 준비 상태를 기다린 뒤, 버전별 테스트 스위트를 실행할 수 있습니다.

다음 단계에서는 명시적 핸들을 사용하는 대표적인 상태 저장 워크플로를 도입해야 합니다. 중단된 요청 하나와 안전하게 재시도한 부작용 하나를 포함해야 합니다.

인증 테스트는 성공 및 거부된 호출을 모두 포함해 이어져야 합니다. 확장 의존 워크플로는 코어 프로토콜 동작이 안정화된 뒤 마지막에 도입해야 합니다.

롤백 계획은 여전히 필요합니다. 지원 버전 목록에 이전 안정 리비전을 유지하면 팀이 결함을 조사하는 동안 호환 가능한 클라이언트에 폴백을 제공할 수 있습니다.

그러나 폴백이 영구적인 모호성이 되어서는 안 됩니다. 조직은 남아 있는 이전 클라이언트를 검토할 날짜와 여전히 사용하는 사용 중단 기능에 대한 계획이 필요합니다.

개발자는 이 리비전이 상태를 배치하는 위치와 재시도 방식을 바꾸므로 관심을 가져야 합니다. 플랫폼 팀은 호환성이 게이트웨이 경계에서 관측 가능해지므로 관심을 가져야 합니다.

엔터프라이즈 구매자는 관리형 프로토콜 지원이 중복 인프라를 줄일 수 있으므로 관심을 가져야 합니다. 또한 어떤 확장, SDK, 리전, ID 구성, 대상 유형이 프로덕션 검증을 완료했는지 계속 물어야 합니다.

지식 노동자들은 그 결과를 간접적으로 체감하게 될 것입니다. 이들의 어시스턴트는 더 적은 연결 실패로 더 많은 도구에 연결할 수 있게 되겠지만, 그 전제는 도구 전반에서 신원과 동의가 명확하게 유지되는 것입니다.

Amazon AWS는 첫 번째 마이그레이션 작업을 이례적으로 작게 만들었습니다. 더 중요한 질문은 팀이 안전성, 호환성 또는 가시성을 잃지 않고 모든 요청을 자체 완결적으로 만들 수 있는지입니다.

향후 1~3개월 동안 주요 SDK 전반의 협상된 버전 데이터, 권한 부여 거부의 품질, 확장 기능 적합성을 주시해야 합니다. 이 신호들은 상태 비저장 MCP가 프로덕션 표준이 되었는지, 아니면 클라이언트를 기다리는 게이트웨이 기능으로 남아 있는지를 보여줄 것입니다.

이미 AgentCore Gateway를 운영 중인 팀이라면, 다음으로 취할 실질적인 조치는 통제된 호환성 감사입니다. 게이트웨이 하나를 업데이트하고, 지원하는 모든 클라이언트를 테스트하며, 협상된 리비전을 기록하고, 액세스를 확대하기 전에 실패 사례를 강제로 재현해야 합니다.

그러한 증거는 API 호출 하나가 겉보기에는 단순하다는 사실보다 더 중요합니다. Amazon AWS는 이제 MCP 2026-07-28로 향하는 다리를 제공하지만, 각 조직은 자사 에이전트가 그 다리를 안전하게 건널 수 있음을 입증해야 합니다.