한눈에 보기
AWS가 2026년 4월 9일, Amazon Bedrock AgentCore를 통해 AWS Agent Registry 프리뷰를 공개했다. 핵심은 기업 내부에 점점 늘어나는 AI agent, tool, skill, MCP server, custom resource를 한곳에 등록하고, 검색하고, 승인하고, 감사할 수 있는 private governed catalog다.
이 발표는 "agent를 어떻게 만들까"보다 "이미 만들어진 agent를 어떻게 관리할까"에 가까운 이야기다. 기업 안에서 agent가 많아질수록 중복 개발, 권한 관리, 승인 절차, 감사 로그 문제가 같이 따라오기 때문이다.
이번 발표 뭐가 나왔나
AWS Agent Registry는 Amazon Bedrock AgentCore에서 제공되는 프리뷰 기능이다. 조직 내부에서 agent, tool, skill, MCP server, custom resource를 등록하고 찾을 수 있는 사설 카탈로그 역할을 한다.
접근 방식도 여러 가지다. AgentCore Console UI에서 볼 수 있고, API를 통해 AWS CLI나 AWS SDK로 다룰 수 있다. 또 MCP server 형태로도 제공되어, builder가 IDE 안에서 registry를 query하거나 invoke하는 방식도 가능하다.
등록 방식은 두 갈래다. 콘솔이나 API로 수동 등록할 수 있고, live MCP server 또는 agent endpoint에서 tool schema와 capability description 같은 metadata를 가져오는 URL-based discovery도 지원한다.
핵심 변화 3가지
첫째, agent와 tool이 "찾을 수 있는 자산"이 된다. 지금까지는 팀별로 만든 agent나 MCP server가 문서, 채팅방, 개인 기억 속에 흩어지기 쉬웠다. Registry에 등록되면 기존 기능을 먼저 찾아보고 재사용할 수 있다.
둘째, 승인 전에는 노출되지 않는 흐름을 만들 수 있다. AWS 문서에 따르면 record는 auto-approval 또는 manual review 설정에 따라 Pending approval 또는 Approved 상태로 이동할 수 있다. 검색 결과에는 Approved record만 나온다. draft, pending, rejected, deprecated 상태는 discoverable하지 않다.
셋째, 감사를 전제로 한 운영이 가능해진다. IAM과 OAuth Custom JWT 기반 인증을 지원하고, registry access와 admin action에 대해 AWS CloudTrail audit trail을 남길 수 있다. agent가 많아질수록 "누가 무엇을 등록했고 누가 접근했는가"가 꽤 현실적인 운영 이슈가 된다.
본문 이미지
실제로 뭐가 달라지나
일반 사용자
일반 사용자가 바로 Agent Registry 콘솔을 만질 일은 많지 않을 수 있다. 대신 회사 안에서 승인된 agent와 tool을 더 안정적으로 쓰게 될 가능성이 있다. 같은 기능의 agent가 여러 개 생겨 혼란스러운 상황도 줄어들 수 있다.
개발자
개발자에게는 재사용성이 커진다. 이미 등록된 MCP server나 tool schema를 찾아보고, 새로 만들기 전에 비슷한 기능이 있는지 확인할 수 있다. 검색은 semantic search와 keyword search를 함께 쓰는 hybrid search 방식이다.
다만 검색 동작에는 운영상 알아둘 점이 있다. AWS 문서 기준으로 searchQuery는 1-256자이고, maxResults는 1-20 범위이며 기본값은 10이다. name, descriptorType, version 필터도 제공된다. 승인 후 search indexing은 eventually consistent라 몇 분 정도 걸릴 수 있다.
창업자
AI agent를 B2B 제품으로 만들거나, 기업 내부 자동화 플랫폼을 운영하는 입장에서는 "agent catalog" 자체가 새로운 관리 계층이 될 수 있다. 예전 SaaS 관리에서 app catalog와 권한 관리가 필요했던 것처럼, agent 시대에는 agent catalog와 MCP server governance가 필요해지는 흐름이다.
좋은 점
가장 좋은 점은 agent를 만드는 속도와 관리하는 속도 사이의 간극을 줄이려 한다는 것이다. 회사 안에서 agent가 늘면 "이거 이미 누가 만들지 않았나?"라는 질문이 반복된다. Registry는 이 질문에 답할 수 있는 기본 장치를 제공한다.
또 하나는 승인과 감사가 기능 안에 들어왔다는 점이다. approval workflow를 거쳐야 record가 discoverable해지고, CloudTrail로 접근과 관리 작업을 추적할 수 있다. 기업용 기능에서 이런 부분은 화려하지 않지만 실제 도입 여부를 가르는 요소가 된다.
지원 리전도 공개됐다. 프리뷰 기준으로 US West Oregon, Asia Pacific Tokyo, Asia Pacific Sydney, Europe Ireland, US East N. Virginia에서 사용할 수 있다.
아쉬운 점
프리뷰라서 실제 운영에서 어느 정도까지 매끄럽게 쓸 수 있을지는 더 봐야 한다. 특히 여러 팀이 이미 각자 MCP server와 agent endpoint를 운영하고 있는 회사라면, metadata 품질을 맞추는 일이 생각보다 일이 될 수 있다.
또 검색 인덱싱이 eventually consistent라는 점도 운영 문서나 배포 흐름에 반영해야 한다. 승인 직후 바로 검색되지 않을 수 있다는 점은 사용자에게는 작은 혼란이 될 수 있다.
내 생각
이번 발표는 agent 시장이 한 단계 넘어가는 신호처럼 보인다. 작년까지는 "무엇을 자동화할 수 있나"가 중심이었다면, 이제는 "누가 만든 자동화를 조직 안에서 어떻게 믿고 쓸 것인가"가 앞으로 나온다.
특히 MCP server까지 catalog 대상으로 넣은 점이 눈에 들어온다. agent 자체보다 tool과 MCP server가 더 중요한 자산이 되는 경우가 많기 때문이다. 잘 만든 tool 하나가 여러 agent에서 재사용될 수 있고, 반대로 검증되지 않은 tool 하나가 여러 agent에 위험을 퍼뜨릴 수도 있다.
AWS Agent Registry가 당장 모든 회사의 표준이 된다고 말하긴 이르다. 그래도 agent가 많아지는 조직이라면 결국 비슷한 문제를 만나게 된다. 목록, 승인, 검색, 감사. 재미없어 보이지만, 실제 운영에서는 이런 것들이 오래 간다.
요약 카드 이미지
결론
AWS Agent Registry는 Amazon Bedrock AgentCore 안에서 제공되는 사내 AI agent catalog 기능이다. agent, tool, skill, MCP server, custom resource를 등록하고, 승인된 record만 검색되게 하고, IAM/OAuth 인증과 CloudTrail 감사까지 붙이는 방식이다.
agent를 하나 만드는 것보다, 조직 안에서 이미 만들어진 agent를 찾고 믿고 재사용하는 일이 더 어려워지는 시점이 오고 있다. 이번 프리뷰는 그 문제를 AWS식 인프라와 거버넌스로 풀어보려는 시도다.
한 줄 평
AWS Agent Registry는 AI agent가 많아진 회사에 필요한 "사내 agent 주소록 + 승인대장 + 감사로그"에 가깝다.