leejk/ jk lee

Agent Governance: 표준화 이후 다음 챕터 · 2026.05

AWS Agent Registry: MCP 위에 얹힌 첫 거버넌스 레이어

에이전트 난립을 푸는 카탈로그·승인·감사 — 그리고 기존 스킬·MCP와의 8가지 마찰

·
#aws#agent-registry#mcp#agent-skill#governance#landscape

AWS Agent Registry는 2026년 4월 9일 Bedrock AgentCore 산하에 preview로 출시됐다. MCP·A2A·Skills·Custom 4종 리소스를 단일 카탈로그로 묶고 라이프사이클·승인·CloudTrail·하이브리드 검색·MCP 엔드포인트 노출까지 제공한다. MCP 표준화 이후 다음 챕터 — 거버넌스 레이어 — 가 양대 클라우드·양대 모델 회사에서 동시에 등장하는 모먼트의 첫 분석이다.

TL;DR. AWS Agent Registry는 MCP 표준화 이후 다음 챕터의 첫 신호다. 2026년 4월 9일 Bedrock AgentCore 산하 preview. MCP·A2A·Skills·Custom 4종 리소스를 단일 카탈로그에 묶고, 라이프사이클·승인·CloudTrail·하이브리드 검색·MCP 엔드포인트 노출을 한 묶음으로 제공. 다만 기존 스킬·로컬 MCP 게이트웨이와 동시 운영하면 인증·트리거·로케일에서 즉시 8가지 마찰이 등장한다.

왜 지금 문제인가

2026년 4월 한 달 사이 양대 클라우드와 양대 모델 회사가 agent sprawl 응답을 같은 자리에 동시 진입시켰다 (전체 5개 신호는 카테고리 인덱스 참조). 그 중 가장 구체적이고 1개월차 운영 신호가 잡히기 시작한 단일 제품이 AWS Agent Registry다 (2026-04-09 preview).

AWS Agent Registry는 무엇인가

AWS Agent Registry는 조직 내 AI 에이전트·MCP 서버·툴·스킬·커스텀 리소스를 중앙 집중적으로 등록·검색·거버넌스하는 Bedrock AgentCore 산하 프라이빗 카탈로그다. 4종 레코드 타입을 1급 시민으로 다룬다.

레코드 스키마 1줄 정의
MCP MCP Protocol Schema 전 버전 MCP 서버 자체
Agent A2A AgentCard Schema 전 버전 다른 에이전트가 호출 가능한 에이전트
Agent Skills AWS 고유 JSON Schema Draft-07 (v0.1.0) SKILL.md 본문 + AWS 메타데이터 한 겹
Custom 사용자 정의 그 외 자원

모든 레코드는 동일한 라이프사이클을 거친다. 수정하면 자동으로 DRAFT로 되돌아가 재승인이 필요하다는 점이 운영 마찰의 핵심.

stateDiagram-v2
    [*] --> UNREGISTERED
    UNREGISTERED --> DRAFT: 등록 시작
    DRAFT --> PENDING: 제출
    PENDING --> APPROVED: 승인
    PENDING --> REJECTED: 거부
    APPROVED --> DEPRECATED: 폐기
    APPROVED --> DRAFT: 수정시 재승인
    REJECTED --> DRAFT: 재시도

검색 결과에는 APPROVED 상태만 노출된다.

등장 배경

2025년부터 기업 내 에이전트·MCP 서버가 폭증했고, 같은 팀 안에서도 동일 기능 에이전트가 중복 개발되거나 어떤 에이전트가 어디서 도는지 보안·컴플라이언스 팀이 추적하지 못하는 상황이 일상이 됐다. MCP가 사실상 표준이 되면서 "MCP 서버는 늘어나는데 발견(discovery)과 거버넌스 레이어가 없다"는 비판이 누적됐다. AWS는 이를 "에이전트는 비밀이 아니어야 한다(Agents shouldn't be secret)" 라는 슬로건으로 받아치며 AgentCore 산하에 Registry를 추가했다.

핵심 5개 기능

  1. 중앙 집중 카탈로그(Centralized Discovery). 조직 전체의 에이전트·툴·MCP·스킬을 한 곳에서 검색. 중복 개발 회피가 1차 목적이다.
  2. 거버넌스·승인 워크플로(Governance & Approval). 위 라이프사이클을 강제. CloudTrail 감사 로그가 모든 상태 전이를 기록한다.
  3. 하이브리드 검색(Hybrid Search). semantic + keyword 동시 지원. "PDF에서 표 추출하는 툴 찾아줘" 같은 자연어 쿼리와 정확한 이름·태그 검색이 함께 작동한다.
  4. URL 기반 자동 발견(Auto Discovery). MCP·A2A 엔드포인트 URL만 등록하면 Registry가 직접 호출해 툴 스키마·capability·메타데이터를 끌어온다. 수동 JSON 작성 불필요.
  5. Registry 자체가 MCP 엔드포인트. Kiro·Claude Code 같은 MCP 클라이언트가 IDE에서 Registry를 직접 검색·invoke한다. IAM 모드는 mcp-proxy-for-aws가 SigV4 서명을 처리하고, JWT 모드는 Bearer Token으로 HTTP 호출.

이외에 4종 멀티-리소스 타입 지원, 멀티 클라우드/온프레미스 인덱싱, OAuth 2.0(Cognito 빠른 생성 또는 Keycloak·Entra BYO), CloudTrail 감사 등 표준 클라우드 기대치는 모두 충족한다.

기존 스킬·MCP 운영과 충돌하는 8가지

기존 스택과 같이 굴릴 때 즉시 등장하는 마찰이다.

  1. 인증 모델 단일 선택 + 변경 불가. Registry는 IAM SigV4 또는 JWT 중 하나만 선택 가능하고 생성 후 변경 불가. JWT 모드에서는 AWS CLI/SDK(SigV4 기반)를 못 쓰므로 search API를 curl/Postman으로 직접 호출해야 한다. 사내에 IAM 자동화와 OAuth 사용자 액세스가 공존하면 Registry를 둘로 쪼개야 한다.
  2. 네이밍 충돌 처리 부재. 같은 이름의 툴이 Registry·로컬 skills·외부 MCP 서버에 동시에 존재할 때 호출 우선순위는 클라이언트 정책에 위임된다. 외부 MCP Gateway 계열은 alias로 해결하지만 AWS 공개 문서에서 명시적 alias 기능은 확인되지 않는다.
  3. 레코드 업데이트 마찰. 수정 → DRAFT 환원 → 재승인. 빠른 반복 개발이 필요한 로컬 스킬을 Registry에 그대로 미러링하면 릴리스 사이클이 깨진다.
  4. Skill 메타데이터 레이어 차이. Registry의 Skill 레코드는 두 겹이다. (a) SKILL.md 본문은 official AgentSkills specification으로 검증되므로 Anthropic 계열과 정렬. (b) 그 위에 AWS 고유의 Skill definition JSON Schema(v0.1.0, repository / package / _meta 등) 한 겹 추가. 본문은 공유 가능하지만 AWS 전용 메타데이터를 매번 채워야 한다.
  5. 트리거 vs 명시적 invoke 모델. Anthropic 계열은 description을 보고 자동 트리거, Registry는 search → invoke 명시 흐름. 같은 스킬이 양쪽에 등록되면 자동 트리거 경로와 Registry 경로가 분기되어 어느 쪽을 단일 소스로 둘지가 정해져야 한다.
  6. 검색·라우팅 책임 분담 (Gateway vs Registry). AgentCore Gateway(실행/페더레이션)와 Registry(디스커버리/거버넌스)는 공식 포지셔닝상 상호 보완. 그러나 사내에 이미 자체 MCP Gateway가 있으면 "어디서 라우팅하고 어디서 발견할지"를 재정의해야 하고, 이중 운영이 생길 수 있다.
  7. 언어·로케일 한계. Semantic search가 영어 메타데이터 기준으로 동작하는 구조라, 일본어·한국어 같은 비영어 쿼리에서 검색 품질이 떨어질 수밖에 없다(메타데이터 언어와 쿼리 언어가 어긋나는 자리). 이중 언어 description 병기로 완화는 가능하나 운영 오버헤드가 누적된다.
  8. 승인 워크플로 vs 빠른 실험. 로컬 skills/MCP는 즉시 만들고 즉시 쓰지만 Registry는 승인을 강제. 두 흐름을 동시에 굴리면 "공식 채널에 등록 안 된 로컬 전용 스킬"이 늘어나 거버넌스 의도가 무력화될 수 있다.

여덟이 모두 같은 패턴의 변주다 — 클라우드 거버넌스는 단일 소스 모델을 가정하고, 로컬 스택은 다중 소스를 가정한다. 둘을 그대로 합치면 어느 쪽 가정도 만족되지 않는다.

종합

MCP 인덱스는 "남은 문제는 운영"이라 결론지었다. AWS Agent Registry는 그 운영 문제에 대한 클라우드의 첫 답이다. 발견·승인·감사를 한 묶음으로 묶고 다시 MCP 엔드포인트로 노출하는 layer-on-layer 설계.

그러나 클라우드의 답은 기존 로컬 스킬·로컬 게이트웨이와 동시 운영을 전제하지 않는다 — 그래서 8가지 마찰이 즉시 등장한다. 다음 분기 운영 화두는 둘 중 어느 쪽을 단일 소스로 둘 것인가 — 또는 둘 다 두면서 어느 한쪽을 mirror로 강등할 것인가 — 의 결정이다. AWS·Microsoft·Anthropic·OpenAI가 같은 자리에 동시에 진입한 만큼, 이 결정을 미루면 다음에 등장할 거버넌스 레이어가 그 결정을 강제할 가능성이 높다.

참고

  • AWS Launches Agent Registry in Preview to Govern AI Agent Sprawl across Enterprises (InfoQ, 2026-04)
  • The 2026 MCP Roadmap (MCP Blog)
  • agentic-community/mcp-gateway-registry
  • AWS What's New — Agent Registry now available in Preview (2026-04-09)
  • AWS Machine Learning Blog — The future of managing agents at scale: AWS Agent Registry now in preview
  • AWS Machine Learning Blog — Transform your MCP architecture: Unite MCP servers through AgentCore Gateway
  • Amazon Bedrock AgentCore Docs — Agent Registry, Supported record types, Concepts and terminology, Searching the registry, Using the Registry MCP endpoint, Amazon Cognito
  • The Register — AWS: Agents shouldn't be secret, so we built a registry
  • Heeki Park (Medium) — Integrating AWS Agent Registry into your agent platform
  • Gerardo Arroyo's Blog — AWS Agent Registry: a private catalog to stop agent sprawl

같은 주제