Amazon Bedrock AgentCore Gateway가 기업용 MCP 인프라 계층이 되었습니다. 실제로 무엇이 바뀌었을까요?

기업 내부에서 MCP 서버가 빠르게 확산되고 있습니다. 모든 팀이 각자 서버를 배포하고, 각 서버는 독립적으로 자격 증명(Credentials)을 처리하며, 모든 보안 팀은 이를 개별적으로 검토합니다. 결과적으로 누가 어떤 도구를 호출하고 있는지에 대한 통합된 뷰를 가진 사람은 아무도 없습니다. Amazon Bedrock AgentCore Gateway가 방금 중요한 기능 확장을 이루었으며, 이러한 추가 사항들은 기업의 MCP 배포가 실제 운영 환경에서 어디에서 무너지고 있는지를 정확히 보여줍니다.

대규모 연합 MCP(Federated MCP)의 문제점

조직 내에 MCP 서버가 몇 개 이상 생기는 순간, 거버넌스(Governance) 문제가 발생합니다. 법무 팀의 계약 검토 서버, 재무 팀의 데이터 검색 서버, 운영 팀의 장애 대응 서버는 각각 동일한 인프라 부담을 안고 있습니다: 자격 증명 관리, 액세스 제어(Access Control), 로깅(Logging), 프라이빗 네트워크 연결성 등입니다. 보안 검토는 쌓여만 가고, 개발자들은 승인을 기다립니다. 그리고 에이전트가 단일 작업에서 세 개의 서로 다른 MCP 서버를 호출할 때, 통합된 감사 추적(Audit Trail)은 존재하지 않으며, 단지 세 개의 서로 다른 시스템에 세 개의 별도 로그가 남을 뿐입니다.

표준적인 해결책은 이러한 공유 계층을 직접 구축하는 것이었습니다. AgentCore Gateway의 제안은 여러분이 그럴 필요가 없어야 한다는 것입니다.

AgentCore Gateway가 실제로 작동하는 방식

AgentCore Gateway는 MCP 클라이언트와 조직 내의 모든 MCP 서버 사이에 위치하여, 모든 MCP 트래픽에 대한 단일 인증 엔트리 포인트(Entry Point) 역할을 합니다. 팀들은 서버를 위한 비즈니스 로직만 구축하면 됩니다. 게이트웨이가 자격 증명 관리, 정책 집행(Policy Enforcement), 관찰 가능성(Observability), AWS PrivateLink를 통한 프라이빗 네트워크 라우팅, 그리고 이제는 대폭 확장된 프로토콜 표면(Protocol Surface)을 포함한 나머지 모든 것을 처리합니다.

새로운 기능은 다섯 가지 카테고리로 나뉘며, 각 카테고리는 특정 운영 환경의 실패 모드(Failure Mode)를 해결합니다.

Full MCP primitive support (전체 MCP 기본 요소 지원). 이전에는 Gateway가 주로 도구 호출 (tool calls)에 집중했습니다. 이제는 MCP prompts (MCP 프롬프트)와 MCP resources (MCP 리소스)를 도구와 함께 일급 시민 (first-class citizens)으로 취급합니다. Gateway에 연결된 클라이언트는 모든 백엔드 서버로부터 집계된 하나의 통합된 카탈로그 — 즉, 하나의 도구 목록, 하나의 프롬프트 라이브러리, 하나의 리소스 네임스페이스 (namespace) — 를 보게 됩니다. tools/list, tools/call, prompts/list, prompts/get, resources/list, resources/read, 그리고 resources/templates/list와 같은 전체 메서드 세트가 지원됩니다. 이제 도구 정의에는 예상되는 출력 구조를 정의하기 위한 outputSchema와, 도구가 읽기 전용인지 또는 파괴적인지(destructive)와 같은 동작 특성을 설명하는 annotations가 포함됩니다.

사용자별 권한 범위 설정을 위한 동적 목록화 (Dynamic listing for per-user capability scoping). 이는 더 미묘한 추가 사항이며 멀티 테넌트 (multi-tenant) 배포에서 매우 중요합니다. *기본 목록 모드 (default listing mode)*에서 Gateway는 대상 등록 시점에 도구 및 기능 목록을 캐싱하고, 목록 호출 시 캐시에서 이를 제공합니다. 빠르지만 정적입니다. *동적 목록 모드 (dynamic listing mode)*에서는 목록 호출이 요청 시점에 호출하는 사용자의 신원(identity)을 바탕으로 MCP 서버로 실시간 전달됩니다. 즉, 서버 자체가 각 사용자에게 무엇을 보여줄지 결정한다는 의미입니다. 권한을 인식하는 서버는 approve_expense를 관리자에게만 노출할 수 있습니다. 의료 분야를 대상으로 하는 서버는 의료 자격이 있는 고객에게만 HIPAA를 준수하는 도구를 반환할 수 있습니다. 백엔드 서버의 기존 액세스 제어 (access control) 로직은 Gateway 계층에서 재구현할 필요 없이 그대로 유지됩니다.

Streamable HTTP 전송을 통한 스트리밍 (Streaming via Streamable HTTP transport). 스트리밍이 없다면, 45초 동안 실행되는 도구 호출 (tool call)은 완료될 때까지 아무것도 반환하지 않습니다. 새로운 SSE 기반 스트리밍 지원을 통해, Accept: application/json, text/event-stream을 전송하는 클라이언트는 백엔드 서버에서 방출되는 실시간 진행 상황 알림, 로깅 메시지 및 최종 결과를 받을 수 있습니다. Accept: application/json만 전송하는 클라이언트는 계속해서 단일 JSON 응답을 받게 되며, 이는 완전한 하위 호환성 (backward compatibility)이 유지됨을 의미합니다. 스트리밍은 선택 사항이며, 게이트웨이 프로토콜 설정에서 enableResponseStreaming: true를 설정하여 활성화할 수 있습니다.

상태 유지형 멀티턴 워크플로우를 위한 세션 관리 (Session management for stateful multi-turn workflows). 이제 Gateway는 첫 번째 initialize 요청 시 Mcp-Session-Id를 생성하고 이를 응답 헤더로 반환합니다. 클라이언트는 이후의 요청에 이 헤더를 포함하며, 이를 통해 Gateway는 클라이언트 세션을 다운스트림 서버 세션에 매핑하고 해당 매핑을 재사용하여 반복적인 초기화 오버헤드를 방지하는 등 다단계 대화 전반에 걸쳐 상태를 유지할 수 있습니다. 세션은 사용자 범위(user-scoped)로 지정됩니다. Gateway는 JWT 베어러 토큰 (JWT bearer token) 또는 IAM 자격 증명 (IAM credentials)에서 사용자 신원을 도출하고, 세션 내의 모든 요청이 동일한 사용자로부터 오는지 검증합니다. 이는 세션 하이재킹 (session hijacking)을 직접적으로 방지합니다. 타임아웃은 15분에서 8시간까지 설정 가능합니다.

실행 중 Human-in-the-loop을 위한 유도 (Elicitation). 이는 운영 측면에서 가장 흥미로운 추가 사항입니다. 유도 (Elicitation) 기능을 통해 Gateway 뒤에 있는 MCP 서버는 실행을 일시 중지하고, 계속 진행하기 전에 최종 사용자로부터 입력을 요청할 수 있습니다. 세 가지 모드가 있습니다: 폼 모드 (form mode) (서버가 JSON Schema를 전송하고 클라이언트가 폼을 렌더링함), URL 모드 (URL mode) (서버가 URL을 전송하며, 일반적으로 OAuth 동의 화면 또는 외부 승인 워크플로우임), 그리고 URL 예외 모드 (URL exception mode) (서버가 URLElicitationRequiredError를 반환하면 클라이언트가 사용자를 리다이렉트하고 완료 후 재시도함). 유도 (Elicitation)를 사용하려면 스트리밍 (streaming)과 세션 (sessions)이 모두 활성화되어 있어야 합니다. Gateway는 기능 협상 (capability negotiation)을 처리합니다. 만약 클라이언트가 초기화 과정에서 유도 (elicitation) 지원을 선언하지 않으면, 백엔드 서버는 유도 요청을 보내려고 시도하지 않습니다. 세션당 여러 개의 동시 유도 (elicitation) 요청이 지원됩니다.

OAuth 2.0 대리인 토큰 교환 (on-behalf-of token exchange). 에이전트가 인증된 사용자를 대신하여 다운스트림 리소스에 접근해야 할 때, Gateway는 이제 AgentCore Identity를 통해 RFC 8693 토큰 교환을 지원합니다. 원래 사용자의 신원 (identity)은 보존되어 체인의 모든 홉 (hop)을 통해 전파됩니다. 즉, Gateway가 Gateway 대상(audience)으로 범위가 지정된 JWT A를 수신하면, 이를 MCP 서버 대상(audience)으로 범위가 지정된 JWT B로 교환하고, MCP 서버는 더 하위의 다운스트림 API 대상(audience)으로 범위가 지정된 JWT C를 얻을 수 있습니다. 모든 홉에서 원래 사용자의 sub 클레임 (claim)이 계속 전달됩니다. 다운스트림 서비스는 추가적인 동의 흐름 (consent flows)을 트리거하지 않고도 사용자별 권한 부여 (authorization)를 강제할 수 있습니다. AgentCore Identity는 중앙 토큰 브로커 (token broker) 역할을 수행하며, Gateway나 MCP 서버는 자격 증명 (credentials)을 직접 처리하지 않습니다.

팀들이 실제로 이를 사용하는 용도

실제적인 모습은 다음과 같습니다: 단일 Gateway 배포를 통해 조직 내 모든 MCP 서버에 대한 서버별 자격 증명 관리(per-server credential management)를 대체할 수 있습니다. Lambda interceptor 기능을 사용하면 모든 서버에 로직을 중복해서 구현하는 대신, Gateway 계층에서 커스텀 권한 부여 로직 (authorization logic), 데이터 정제 (sanitization), 또는 요청 변환 (request transformation)을 주입할 수 있습니다. AgentCore Policy (현재 프리뷰 단계)는 Gateway 평면(plane)에서 Cedar 기반의 결정론적 정책 집행 (deterministic policy enforcement)을 추가합니다. 이는 AgentOps 프레임워크에서 다루는 것과 동일한 "지금 이 작업을 수행할 수 있는가"에 대한 집행 계층이며, 이제 MCP 트래픽에 직접 연결됩니다.

이중 리스팅 모드 (dual listing mode) 아키텍처는 대부분의 멀티 테넌트 (multi-tenant) 구현에서 문제를 일으키는 상황, 즉 일부 기능은 보편적이고 일부는 사용자별로 구분되어야 하는 상황을 처리합니다. 공유 카탈로그를 위한 기본 모드 (default mode)와 신원 (identity)에 따라 범위를 지정해야 하는 항목을 위한 동적 모드 (dynamic mode)가 있습니다. 두 모드 모두 동일한 Gateway 엔드포인트를 통해 라우팅됩니다.

이것이 보기보다 더 중요한 이유

MCP는 에이전트형 AI (agentic AI) 배포를 위한 핵심 기반 인프라 (load-bearing infrastructure)가 되고 있으며, 기업 도입의 관건은 항상 기능이 아닌 거버넌스 (governance)였습니다. 역량 있는 엔지니어링 팀이라면 누구나 MCP 서버를 구축할 수 있습니다. 하지만 그들이 쉽게 할 수 없는 것은 서로 다른 사업 부서에 걸쳐 있는 수십 개의 MCP 서버에 대해 컴플라이언스 팀에는 통합된 감사 추적 (audit trail)을, 보안 팀에는 중앙 집중식 자격 증명 관리를, 플랫폼 팀에는 네트워크 격리 보장 (network isolation guarantees)을 동시에 제공하는 일입니다.

프롬프트(prompts)와 리소스(resources)를 일급 기본 요소(first-class primitives)로 다루도록 확장된 Gateway의 기능은 스트리밍(streaming), 세션(sessions), 유도(elicitation), 그리고 OBO 토큰 교환(OBO token exchange)과 결합되어, "데모에서 작동하는 MCP"와 "규제 대상 기업 환경에서 작동하는 MCP" 사이의 간극을 메워줍니다. 특히 유도(elicitation) 지원은 의미 있는 프로토콜 수준의 약속입니다. 이는 인간 참여형(human-in-the-loop) 방식을 애플리케이션 계층에서 나중에 고려할 사항이 아니라, 인프라가 명시적으로 처리하는 기본 요소(primitive)로 취급함을 의미합니다.

이를 배포하려는 모든 분들을 위해 AWS 문서의 리소스 URI 보안 주의 사항을 강조할 가치가 있습니다. 리소스 URI는 다운스트림 MCP 서버로부터 전달되며 Gateway에 의해 정제(sanitize)되지 않기 때문에, 침해된 서버가 내부 엔드포인트나 로컬 파일 시스템 경로를 가리키는 URI를 반환할 수 있습니다. 신뢰할 수 없는 대상으로부터 오는 리소스 URI를 따르기 전에 반드시 검증하십시오. 이는 이론적인 문제가 아니라 실제 운영(production) 환경에서의 문제입니다.

가용성 및 액세스 (Availability and Access)

여기에 설명된 모든 기능은 현재 Amazon Bedrock AgentCore Gateway에서 사용할 수 있습니다. 스트리밍(Streaming)은 CreateGateway / UpdateGateway API 수준에서 구성됩니다. 세션 관리(Session management)와 유도(elicitation)는 각각 명시적인 활성화가 필요하며, 유도를 위해서는 스트리밍과 세션이 모두 켜져 있어야 합니다. 동적 목록 생성(Dynamic listing)은 CreateGatewayTarget 시 타겟별로 지정됩니다. OAuth OBO 토큰 교환은 AgentCore Identity를 통해 처리됩니다. 실습 예제는 awslabs/agentcore-samples GitHub 리포지토리에서 확인할 수 있습니다. AgentCore 정책(Policy) 통합은 여전히 프리뷰(preview) 단계입니다.

이제 MCP 생태계는 관리형 기업 인프라 계층을 갖추게 되었습니다. 문제는 기업에 이런 것이 필요한가 하는 점이 아니라, AWS가 기업들이 실제로 채택할 만한 것을 구축했는가 하는 점입니다.

MCP, 에이전트형 AI(agentic AI), 그리고 AI 인프라에 대한 더 많은 소식을 위해 팔로우해 주세요.