TL;DR. *AgentCore Gateway와 mcp-gateway-registry는 같은 일을 한다 — 다중 MCP 서버 페더레이션·인증·감사. 다른 건 라우팅 평면을 누가 소유하는가다.* AgentCore는 변환(Translation)·합성(Composition)·per-tool 자격증명 주입(Secure Credential Exchange)을 AWS IAM·Cognito에 결속해 벤더에 위탁하고, agentic-community의 mcp-gateway-registry는 Gateway·Registry·A2A·감사를 한 박스에 묶어 Keycloak/Entra OAuth로 자가 호스팅한다. AWS Agent Registry의 마찰 #6이 미뤄 둔 결정 — 어디서 라우팅하고 어디서 발견하는가 — 이 여기서 정면으로 풀린다.
왜 지금 문제인가
AWS Agent Registry의 마찰 #6은 이 자리를 명시적으로 forward-reference 한다: "사내에 이미 자체 MCP Gateway가 있으면 어디서 라우팅하고 어디서 발견할지를 재정의해야 하고, 이중 운영이 생길 수 있다."
그 이중 운영은 가설이 아니라 조직에서 이미 실재하는 분기점이다 — 자체 호스팅 MCP Gateway를 굴리는 팀이 벤더 관리형 Gateway 진입을 검토할 때, 결정은 기능 비교가 아니라 라우팅 평면을 누가 소유하는가로 좁혀진다.
두 게이트웨이는 무엇인가
AWS Bedrock AgentCore Gateway — API·Lambda·기존 서비스·기존 MCP 서버를 MCP 호환 단일 엔드포인트로 노출하는 벤더 관리형 라우팅 레이어. 세 가지를 한다: Translation(에이전트의 MCP 요청 ↔ API·Lambda 호출 변환), Composition(여러 API·함수·MCP 서버를 하나의 MCP 엔드포인트로 합성), Secure Credential Exchange(툴마다 다른 인증 요건에 맞춰 자격증명을 주입). MCP 서버를 target 타입으로 직접 받으며 프로토콜 버전 2025-06-18·2025-03-26·2025-11-25를 지원한다. AgentCore Registry(발견·거버넌스)와는 공식 포지셔닝상 상호 보완 — Gateway는 실행·페더레이션, Registry는 디스커버리.
agentic-community/mcp-gateway-registry — Gateway·Registry·A2A 허브·감사를 한 박스에 묶은 오픈소스, Docker Compose로 자가 호스팅. 다중 MCP 서버에 대한 통합 게이트웨이 + 등록·발견·거버넌스 레지스트리 + 에이전트 간 통신 허브. 인증은 Keycloak·Entra 등 OAuth 제공자, 개별 에이전트 단위 감사 추적, 메트릭은 SQLite(상세 이력) + OTEL export(Prometheus·CloudWatch·Datadog) 이중 경로, 서버·에이전트·스코프용 스토리지 백엔드 3종.
| 축 | AgentCore Gateway — 벤더 위탁 | mcp-gateway-registry — 자가 호스팅 |
|---|---|---|
| 라우팅 평면 소유 | AWS 관리형 엔드포인트 | 자체 인프라(Docker Compose) |
| 인증 | IAM SigV4 / Cognito·BYO OAuth + per-tool Secure Credential Exchange | Keycloak·Entra OAuth, 에이전트별 스코프 |
| 합성 단위 | API·Lambda·MCP 서버 → 단일 MCP 엔드포인트 | 다중 MCP 서버 → 통합 게이트웨이 |
| 감사 | CloudTrail 계열(AWS 평면) | SQLite + OTEL → Prometheus·CloudWatch·Datadog |
| 프로토콜 버전 | 벤더가 결정 (2025-06-18 / 2025-03-26 / 2025-11-25) |
배포자가 결정 |
| 발견·거버넌스 | 별도 제품(AgentCore Registry)으로 분리 | Gateway와 한 박스로 통합 |
같은 일을 하지만 평면이 반대다
둘 다 agent sprawl의 라우팅 측면 — 흩어진 MCP 서버를 단일 진입점으로 묶고 인증·감사를 얹는 것 — 을 푼다. 차이는 기능 목록이 아니라 라우팅 평면의 소유권이다. AgentCore는 변환·합성·자격증명을 AWS 평면에 위탁한다: 운영 부담이 사라지는 대신 인증·프로토콜 버전·target 정의의 통제권도 같이 넘어간다. mcp-gateway-registry는 정반대다: 통제권을 쥐는 대신 게이트웨이·레지스트리·감사 인프라를 직접 운영한다.
한쪽을 고르는 것은 쉽다. 문제는 이미 자가 호스팅 게이트웨이가 있는 조직이 벤더 게이트웨이를 추가할 때 — 즉 둘이 동시에 존재할 때다.
종합
MCP 인덱스는 "남은 문제는 운영"이라 결론지었고, 거버넌스 인덱스는 그 운영을 4축으로 쪼갰다. 라우팅 축의 교훈은 다른 축보다 더 날카롭다: 게이트웨이는 거버넌스를 흡수한다.
mcp-gateway-registry가 Gateway·Registry·A2A·감사를 한 박스로 묶었다는 사실 자체가 신호다. 라우팅 평면을 소유하는 쪽이 발견·인증·감사까지 같이 쥐게 되므로, 인덱스의 4축은 Gateway 평면 위에서 사실상 1축으로 수렴한다. 그래서 "둘 다 두기"는 안정 상태가 아니라 결정 유예다 — 두 평면이 각자 4축 전부를 주장하기 때문이다.
다음 분기의 결정은 하나로 좁혀진다: 라우팅 평면을 어느 쪽에 둘 것인가, 그리고 다른 쪽을 mirror로 강등할 것인가. AWS Agent Registry와 같은 결론 — 결정을 미루면 다음에 등장할 거버넌스 레이어가 그 결정을 대신 강제한다. 차이가 있다면, Gateway 축에서는 그 강제가 인증·프로토콜 버전 어긋남으로 조용히, 그리고 먼저 온다는 것이다.
참고
- Introducing Amazon Bedrock AgentCore Gateway (AWS ML Blog)
- Transform your MCP architecture: Unite MCP servers through AgentCore Gateway (AWS ML Blog)
- Amazon Bedrock AgentCore Gateway — Docs
- MCP server targets — Amazon Bedrock AgentCore Docs
- agentic-community/mcp-gateway-registry (GitHub)
- MCP Gateway & Registry — Docs
- mcp-gateway-registry — AgentCore 연동 문서
- The 2026 MCP Roadmap (MCP Blog)