目錄
지난 2년간 AI Agent에 관한 논의는 대부분 여러 요소를 어떻게 연결할지에 집중됐습니다. MCP Server, Tools, Skills, Agent Framework가 잇따라 등장하는 동안에는 이후의 관리 문제보다 일단 Workflow를 작동시키는 일이 더 급한 경우가 많았습니다. 하지만 같은 회사 안에서 수십 개, 수백 개의 Agent가 생기기 시작하면 문제의 종류도 달라집니다. 어떤 기능을 이미 다른 사람이 만들지는 않았는지, 지금 이 Agent의 책임자는 누구인지, 더 이상 유지보수되지 않는 Tool은 무엇인지, 겉보기에는 쓸 수 있는 MCP Server가 내부 심사를 통과했는지 확인해야 합니다.
2026년 8월 31일, AWS Agent Registry가 정식으로 General Availability 단계에 들어갔습니다. 모델의 추론 능력을 강화하는 기능도 아니고 또 다른 Agent Builder도 아닙니다. 조직 안의 Agents, MCP Servers, Agent Skills와 기타 Custom Resources를 검색하고 심사하며 관리할 수 있는 Registry로 정리하는 중앙화된 Catalog이자 Discovery Layer입니다. AWS도 문제를 매우 직접적으로 설명합니다. Agent System이 소수의 Tools에서 수백 개 규모로 커지면 진짜 병목은 “Finding what already exists and trusting what you find”로 바뀝니다.
이런 제품은 새 모델 발표만큼 화려해 보이지 않지만, Agent가 실제 업무 환경에 들어간 뒤 어떤 문제를 만나게 되는지 잘 보여 줍니다. MCP에 연결할 수 있는지가 유일한 어려움은 아닙니다. 연결한 뒤 무엇이 존재하는지, 누가 사용하고 있는지, 어떤 Version이 아직 유효한지, 어떤 Resource를 다른 Agent가 찾을 수 있는지가 또 하나의 업무 계층이 됩니다.
Automation이 몇 개뿐인 스튜디오라면 AWS Agent Registry는 당연히 지나치게 무거운 선택입니다. 하지만 그 배경에 있는 논리는 훨씬 이른 시점부터 나타납니다. Agent가 3개나 5개뿐일 때는 정리하지 않아도 전혀 문제가 없어 보입니다. Tool을 몇 차례 교체하고 OAuth 권한이 계속 늘어나면, 반년 뒤 가장 먼저 잊는 것은 보통 Prompt가 아니라 어떤 Workflow가 지금도 실제로 작동하고 있는지입니다.
AWS Agent Registry는 Preview에서 GA로 전환되며 어떤 문제를 해결했나?
AWS Agent Registry는 2026년 4월 9일 Preview로 먼저 출시됐고 8월 31일 정식 GA가 됐습니다. 그 사이는 약 4개월 3주입니다. Preview 때부터 중앙 등록, Semantic＋Keyword Search, Approval Workflow, URL-based Discovery, MCP Endpoint, CloudTrail 연동 등 핵심 기능을 갖추고 있었습니다. GA에서는 Infrastructure as Code, Tags, AWS RAM을 통한 Cross-account Sharing, AgentCore Resource Auto-detection, Amazon Quick과 Kiro 등 더 많은 이용 경로가 추가됐습니다.
이 일정에서 “AWS가 Preview 제품을 빠르게 정식 전환했다”는 점보다 더 눈여겨볼 부분은 Preview와 GA 사이에 추가된 기능 대부분이 기업의 실제 배포 이후에 생기는 문제를 다룬다는 사실입니다. Account를 넘어 어떻게 공유할지, IaC로 어떻게 관리할지, 분류와 비용 귀속을 어떻게 처리할지, 능동적으로 등록되지 않은 Agent를 어떻게 찾아낼지가 그 대상입니다.
즉 Registry의 문제는 처음부터 “Agent를 만들 수 있는가”가 아니라, 만든 뒤 믿을 수 있는 Inventory가 존재하는가였습니다.
기업이 AI Agent를 대량 도입한 뒤 가장 자주 만나는 세 가지 관리 문제는?
AWS는 GA 글에서 문제를 간단히 정리합니다. 첫째, 중앙화된 Inventory가 없어 조직에 어떤 Agent, Tools, Skills가 있는지, Owner가 누구인지 알 수 없습니다. 둘째, 팀 간 Discovery가 부족해 이미 같은 기능이 존재해도 다른 팀이 찾지 못하고 다시 만듭니다. 셋째, 발견한 Resource를 신뢰할 수 있는지가 불분명합니다. Owner, Version, Approval Status, Description, Endpoint가 명확하지 않다면 검색이 가능해도 안심하고 재사용하기 어렵습니다.
Registry에 등록하는 것은 Agent만이 아니라 네 가지 Record Type
현재 정식으로 지원하는 최상위 recordType은 AGENT, MCP, SKILL, CUSTOM 네 가지입니다. Agent Record는 A2A Agent Card를 사용해 Agent와 Skills를 설명할 수 있습니다. MCP Record는 MCP Server 정의를 저장하고 해당 Server가 제공하는 Tool Definitions도 함께 담을 수 있습니다. Skill은 Agent Skill Definition을 저장하며, Custom은 나머지 조직 고유 Resource를 Custom Metadata로 관리할 때 사용합니다.
MCP Tool은 독립된 다섯 번째 Record Type이 아니라 일반적으로 MCP Server Record의 Tool Definitions 안에 들어간다는 점에 주의해야 합니다. 이 차이는 API, CLI, IaC로 실제 Registry Record를 만들 때 중요합니다.
Keyword Search와 Semantic Search를 결합해 Resource를 찾는다
Registry의 검색은 이름 일치에만 의존하지 않습니다. SearchDiscoverableRegistryRecords는 Semantic Search와 Keyword Search를 동시에 실행한 뒤 결과를 합쳐 정렬합니다. 따라서 정확한 이름으로 검색할 수도 있고, “Ticket Routing을 처리할 수 있는 Tool을 찾아 달라”처럼 자연어로 요구 사항을 설명할 수도 있습니다. MCP Server의 Tool Name, Description, Input Schema 등도 검색 대상이 됩니다.
모든 사람이 어떤 Tool의 이름을 미리 알아야 찾을 수 있다면, 그것은 보기 좋은 Excel에 불과합니다. 진짜 Discovery는 사용자가 “지금 무엇을 해야 하는지”만 알고, 회사 안에서 이미 누군가 그 기능에 어떤 이름을 붙였는지는 몰라도 검색할 수 있어야 합니다.
Approval은 설정할 수 있지만 Discovery에는 Approved Records만 나타난다
원고에는 “Record가 관리자의 승인을 받아야 검색된다”고 적혀 있습니다. 방향은 비슷하지만 조금 더 정확히 볼 필요가 있습니다. Registry는 Manual Approval을 사용할 수도 있고 auto_approve를 설정할 수도 있습니다. 고정된 규칙은 Discovery Plane의 일반적인 Search, Browse, MCP Discovery에는 최신 Revision 상태가 APPROVED인 Record만 나타난다는 점입니다. Draft, Pending Approval, Rejected, Deprecated 상태는 일반 Consumer Search에 표시되지 않습니다.
Record가 업데이트되면 다시 Draft로 돌아가 기존에 설정한 Lifecycle을 다시 거칩니다. Tool Version, Endpoint, 기능이 바뀌면 이전 Approval이 계속 적합하다고 할 수 없으므로, 한 번 등록한 뒤 영구적으로 유효한 방식보다 더 합리적입니다.
CloudTrail은 감사 기능을 제공하지만 모든 Event가 기본으로 완전히 저장되지는 않는다
AWS Agent Registry는 CloudTrail과 정식으로 연동됩니다. Registry의 Create, Update 같은 Management Events는 기본적으로 CloudTrail Event History에 들어가며 90일 동안 보관됩니다. Discovery 같은 Data Events까지 기록하려면 Trail을 별도로 만들거나 수정하고 Agent Registry의 Data Event Selector를 추가해야 합니다.
따라서 “모든 Registry Access가 처음부터 전부 CloudTrail에 완전히 기록된다”는 표현보다는, Registry가 완전한 CloudTrail Audit 구조를 지원하고 Management Events는 기본적으로 추적할 수 있으며 Data Events는 필요에 따라 따로 활성화해야 한다는 설명이 더 정확합니다.
Registry 자체도 MCP Endpoint를 제공한다
이 점은 Agent Registry에서 특히 흥미로운 부분입니다. 각 Registry는 MCP-compatible Endpoint를 제공할 수 있고 MCP Client는 search_discoverable_registry_records, list_discoverable_registry_records, batch_get_discoverable_registry_record를 직접 호출할 수 있습니다. 따라서 Registry는 관리자만 Console에서 조회하는 시스템이 아닙니다. IDE나 Agent 자체도 이를 Discovery Tool로 사용해 승인된 Resource를 찾은 뒤 어떤 Tool이나 Agent에 연결할지 결정할 수 있습니다.
AWS의 GA 글은 Consumers를 Developers, Business Users, Autonomous Agents라고 명확히 정의합니다. 다시 말해 “Agent가 직접 Registry를 검색해 Tool을 찾는 방식”은 확장된 상상이 아니라 제품이 명시적으로 지원하는 이용 방식입니다.
다만 Registry가 Endpoint와 Authentication Information을 반환한다고 해서 검색한 주체가 기반 Tool의 권한을 자동으로 얻는 것은 아닙니다. 이후 Agent나 MCP Server를 실제로 호출하려면 각 Resource의 Onboarding과 Credentials에 따라 권한 부여를 마쳐야 합니다.
GA 버전에는 Preview보다 어떤 기업 관리 기능이 추가됐나?
GA 이후 Registry는 AWS CloudFormation, Terraform, AWS CDK를 통해 Infrastructure as Code로 생성하고 관리할 수 있어 Registry 설정을 Console에만 남겨 둘 필요가 없습니다. Registries와 Records에는 Tags도 추가할 수 있어 조직화, Cost Allocation, Access Control에 활용할 수 있습니다.
AWS RAM은 Registry를 AWS Accounts 사이에 공유할 수 있게 합니다. 기업은 각 Account가 서로 보이지 않는 Catalog를 따로 관리하는 대신 Organization-wide Registry를 만들 수 있습니다. GA에는 AWS Organization 전체의 AgentCore Runtime과 AgentCore Gateway Resource를 Auto-detection하는 기능도 추가됐습니다. 새로 배포된 Agent나 MCP Endpoint를 먼저 Draft Record로 발견한 뒤 Review／Approval 절차로 넘길 수 있습니다.
여기서는 현재 기능과 roadmap의 경계를 특히 주의해야 합니다. 현재 GA에서 자동으로 감지할 수 있는 대상은 AgentCore Runtime과 AgentCore Gateway입니다. AWS GA Blog는 앞으로 EC2, EKS, ECS 같은 다른 환경으로 확대하고 Federation을 통해 AWS 외부 Resource도 볼 수 있게 하려는 계획을 언급하지만, 이는 이후의 방향이며 현재 이미 전면 지원된다는 뜻은 아닙니다.
이용 경로도 늘었습니다. Registry Resources는 이제 Amazon Bedrock AgentCore, Amazon Quick, Kiro에서 찾을 수 있습니다. Quick은 조직 Registry의 승인된 Agent와 MCP Server를 직접 검색한 뒤 Chat, Agents, Apps, Flows, Deep Research에서 사용할 수 있게 할 수 있습니다.
AI Agent에 Registry가 필요해지기 시작한 이유
MCP가 확산되면서 외부 Tool을 Agent에 연결하는 방식은 과거보다 많이 통일됐습니다. REST API, Database, 내부 Service를 MCP Server로 감싸 모델이 이해할 수 있는 Tools로 제공할 수 있습니다. Integration Friction이 줄어든 것은 사실이지만 “연결 비용이 거의 0이 됐다”고 쓸 수는 없습니다. Authentication, Permission, Schema, Deployment, Observability, Runtime Maintenance는 여전히 남아 있기 때문입니다.
실제 변화는 연결이 쉬워지면서 Tool을 만드는 문턱이 낮아졌고, 조직 안에 유사한 기능이 대량으로 동시에 존재하기 쉬워졌다는 점입니다. 먼저 검색할 곳이 없다면 Shadow Agents, 중복 MCP Servers, 누가 유지보수하는지 모르는 Tools가 자연스럽게 생깁니다. AWS도 “Teams build in isolation”과 “rebuild what already exists”를 Registry가 해결하려는 핵심 문제로 꼽습니다.
이 흐름은 과거 Software Engineering과 비슷합니다. Package가 늘면 Package Registry가 필요하고, Container Image가 많아지면 Image Registry가 필요하며, API가 늘면 Catalog, Gateway, Governance가 필요합니다. Agent와 MCP Tool이 실제 운영 환경에 들어간 뒤 Registry가 하나 더 생기는 것은 이상한 일이 아닙니다. AI Tool도 같은 Asset Management 단계에 들어선 것입니다.
같은 날 AWS가 Observability와 Multi-tenant Isolation도 다룬 것은 무엇을 의미하나?
8월 31일 AWS Machine Learning Blog에는 관측 가능한 Agentic Retrieval, Managed Bedrock Knowledge Base 위의 Multi-tenant Data Isolation, AgentCore Runtime의 MCP Server를 Amazon Quick에 연결하는 구현 등 Production Agentic Systems 관련 글이 여러 편 함께 올라왔습니다.
같은 날 공개된 이 글들을 보면 Agent를 만든 다음 Retrieval을 추적할 수 있는지, Tenant 사이에서 데이터가 섞이지 않는지, 기존 Tool을 재사용할 수 있는지가 새로운 문제로 떠오른다는 공통 주제를 발견할 수 있습니다. 다만 이것은 같은 시기 AWS가 공개한 내용을 바탕으로 정리한 제품 관찰입니다. AWS가 공식적으로 “Agent 시대가 구축 단계에서 수습 단계로 넘어갔다”고 발표한 것은 아닙니다.
더 신중하게 표현하면, 2026년의 Agent Infrastructure에는 Governance, Observability, Isolation, Discovery 같은 Production Concern이 분명히 늘어나고 있습니다.
AWS가 Forrester AI Infrastructure Leader로 선정된 것과 Agent Registry는 직접 관련이 있나?
8월 31일 AWS는 『The Forrester Wave: AI Infrastructure Solutions, Q4 2025』의 13개 Provider 평가에서 Leader로 선정됐고 Strategy Category에서 최고 점수를 받았다고 발표했습니다.
이는 같은 시기 AWS가 AI Infrastructure를 강조한다는 배경으로는 활용할 수 있지만, “Agent Registry 덕분에 AWS가 Leader가 됐다”는 증거로 사용할 수는 없습니다. 해당 Forrester 평가는 Training, Fine-tuning, Inference Infrastructure와 전체 전략을 포함하는 더 넓은 범위이며, 평가 시점도 Agent Registry가 2026년 Preview로 공개되기 전인 Q4 2025이기 때문입니다.
마찬가지로 “모델 능력이 점점 비슷해지므로 Governance가 Cloud Provider의 진짜 moat가 된다”는 말은 시장에 대한 추론으로 보는 편이 맞습니다. 이 AWS 문서 몇 편이 직접 증명하는 결론은 아닙니다. 지금 확실한 것은 Cloud Platform 경쟁이 이미 모델 자체에만 머물지 않고 Agent Runtime, Identity, Gateway, Evaluation, Registry, Observability, Governance까지 포함한다는 사실입니다.
AWS Agent Registry 도입 전에 주의할 두 가지 Governance Risk
Registry의 Metadata 자체가 내부 Architecture를 노출할 수 있다
AWS는 Enterprise Considerations에서 “Resource를 검색할 수 있는 권한”과 “새 Resource를 등록할 수 있는 권한”을 완전히 같게 두어서는 안 된다고 특별히 설명합니다. Tool Metadata에는 Internal Endpoint나 Architecture Details가 포함될 수 있으며, 이런 정보 자체가 공격자에게 가치가 있습니다. 따라서 넓게 검색 가능한 Registry에 어떤 Metadata를 넣고 어떤 정보는 더 엄격한 Access Boundary 안에 둘지 검토해야 합니다. AWS는 누가 Registry를 검색하는지, 검색 빈도는 어느 정도인지 Audit할 것도 권합니다.
따라서 Registry를 만든다는 것은 모든 Architecture 정보를 한곳에 모아 회사 전체가 마음대로 검색하게 한다는 뜻이 아닙니다. Catalog 자체에도 Data Classification과 IAM Boundary가 필요합니다.
등록됐다고 안전하거나 Security Review가 끝난 것은 아니다
또 하나 정확히 짚어야 할 부분은 AWS Agent Registry에 모든 Security Scan, Duplicate Detection, Compliance Assessment를 자동으로 완료하는 기능이 현재 내장돼 있지 않다는 점입니다.
AWS가 현재 제공하는 것은 Record Lifecycle, Approval States, EventBridge Hooks, Approval API이며, 기업은 여기에 자체 심사 절차를 연결할 수 있습니다. AWS가 GA Blog에서 제시한 최소 권장 사항은 공개 전에 비슷한 Resource가 이미 있는지 확인하고 Agent／Tool／Skill에 Security Scan을 실시한 뒤, 마지막으로 사람이 Approver가 되어 Metadata가 완전한지, 원래 개발팀이 아닌 사람도 Description을 이해할 수 있는지, 해당 Resource를 Registry에 올려도 되는지 확인하는 것입니다. 처음에는 단순한 CI/CD Checklist나 Slack Approval Flow만 사용해도 됩니다.
Security／Vulnerability Assessments, Compliance Evaluations, De-duplication Analysis가 Approval Workflow에 더 직접 들어가는 것은 이후의 일입니다. AWS는 이를 What's next로 명확히 적었으며 현재는 Roadmap에 해당합니다.
따라서 “Approved”가 실제로 의미하는 것은 조직이 자체적으로 설정한 Approval Bar를 통과했다는 것이지, AWS가 그 Agent의 종합적인 안전 인증을 끝냈다는 뜻이 아닙니다.
기업이 정말 Agent Registry를 필요로 하기 전에 할 수 있는 일
첫 단계는 바로 Registry를 구매하는 것이 아니라 현재 무엇이 있는지 파악하는 일입니다. Agent, Automation, MCP Server, Skill, 중요한 Integration을 Inventory로 만들고 적어도 이름, 용도, Owner, 현재 Environment, 접근하는 데이터, Write Permission 보유 여부, 마지막 검증일, 현재 상태를 기록할 수 있습니다. 이 표만 만들어도 중복되거나 아무도 유지보수하지 않는 항목을 상당수 찾을 수 있습니다.
두 번째는 매우 가벼운 공개 기준을 만드는 것입니다. Tool을 처음 다른 사람에게 제공할 때 같은 종류의 기능이 이미 있는지, Authentication과 Permission은 적절한지, 누가 유지보수하는지, 문제가 생겼을 때 중지할 수 있는지 확인합니다. 팀이 작을 때 Approval을 10단계로 설계할 필요는 없습니다. Checklist 하나와 Reviewer 한 명만 있어도 Governance가 전혀 없는 상태보다 훨씬 낫습니다.
세 번째는 Lifecycle을 완성하는 일입니다. Agent를 만든 뒤 상태를 단순히 “존재함” 하나로 두지 말고 적어도 Draft, Active, Deprecated, Retired로 나누고 Replacement Link를 남길 수 있습니다. AWS Agent Registry도 비슷한 Lifecycle을 사용하며, 더 이상 필요하지 않은 Approved Record는 Curator가 Deprecated로 표시할 수 있습니다.
개인 Creator나 소규모 Studio에도 AWS Agent Registry가 필요한가?
대부분의 경우 필요하지 않습니다. 보유한 Agent와 Automation이 몇 개뿐이라면 관리만을 위해 AWS Registry를 별도로 만드는 것이 System을 더 복잡하게 할 수 있습니다. 하지만 Registry가 해결하려는 문제는 작은 환경에서도 금방 나타납니다. Workflow 이름이 기억나지 않고, OAuth 권한이 잔뜩 남아 있으며, 같은 작업을 두 Version으로 만들고, 어떤 것이 아직 작동하는지 모르고, Automation이 고장 난 뒤에야 기존 Tool이 몇 달 전에 중단됐다는 사실을 알게 되는 문제입니다.
더 간단한 방법은 현재 사용하는 Knowledge Tool에 “Automation／Agent Registry” 표를 하나 남기는 것입니다.
| 항목 | 기록할 내용 |
| 이름 | Agent, Automation 또는 MCP 이름 |
| 용도 | 실제로 어떤 문제를 해결하는지 한 문장으로 설명 |
| Owner | 현재 유지보수 담당자 |
| Trigger | 수동, Schedule, Webhook 또는 기타 조건 |
| Tools／Connections | Gmail, Notion, Drive, Slack, GitHub 등 |
| Access | Read-only／Write／Delete／Send 등 |
| 비용 | 월 요금, Tokens, Credits 또는 API 비용 |
| Status | Draft／Active／Deprecated |
| 마지막 확인일 | 마지막으로 실제 정상 작동한 날짜 |
| Replacement | 중단됐을 때 이를 대체한 새 Workflow |
정말 유용한 것은 표를 멋지게 꾸미는 일이 아닙니다. 반년 뒤 낯선 Integration을 발견했을 때 그것이 무엇인지 확인하려고 채팅 기록부터 뒤지지 않아도 된다는 점입니다.
Automation이 세 개뿐이라면 이 표를 한 달 동안 열지 않을 수도 있습니다. 하지만 열 개가 넘는 Tools를 연결하고 여러 차례 Agent를 교체해 OAuth 화면에 긴 권한 목록이 생기면 그 가치가 갑자기 분명해집니다.
AWS Agent Registry가 실제로 보여 주는 것은 Agent가 Asset Management 단계에 들어섰다는 사실
AWS Agent Registry는 어떤 Agent의 답변 정확도도 높여 주지 않고, 안전하지 않은 MCP Server를 자동으로 안전하게 만들지도 않습니다. 이 서비스가 다루는 것은 더 현실적인 다른 문제입니다. Agent, Tools, Skills가 기억만으로 관리하기 어려울 만큼 늘어나면 무엇이 존재하는지, 어떤 항목이 현재의 사용 기준을 통과했는지, 담당자는 누구인지 파악할 곳이 필요합니다.
AWS는 이제 Agent 자체가 MCP를 통해 Registry를 검색할 수 있게 합니다. 이는 이 Catalog가 IT 관리자를 위한 Asset List에 그치지 않고 Agent Discovery 자체의 일부가 될 수 있다는 뜻입니다.
하지만 Registry 하나로 Governance 작업 전체가 끝나는 것은 아닙니다. Security Scan, Duplicate Analysis, 세밀한 Discovery Policy와 더 많은 Observability 기능 가운데 일부는 기업이 직접 구축해야 하고 일부는 아직 AWS Roadmap에 있습니다. 오히려 이는 현재 Agent Ecosystem의 현실과 더 가깝습니다. Agent를 만드는 Tool은 이미 많지만, 장기간 쉽게 찾을 수 있고 이해할 수 있으며 누군가가 유지보수하는 상태로 만드는 체계는 아직 보완 중입니다.
소규모 팀도 Agent가 1,000개가 될 때까지 이 문제를 미룰 필요는 없습니다. “이 Workflow가 지금도 작동하고 있는가”라는 질문에 답할 수 없게 된 순간이 사실상 Registry를 남겨야 할 시점입니다.
자주 묻는 질문
AWS Agent Registry는 Amazon Bedrock AgentCore Ecosystem에서 AWS가 제공하는 중앙화된 Agent Catalog로, 조직 안의 Agents, MCP Servers, Agent Skills와 기타 Custom Resources를 등록하고 관리합니다. Agent 자체를 만들거나 모델 능력을 강화하는 기능은 아닙니다. 주로 Resource Discovery, 중복 구축, 불분명한 Owner, Version Management, Governance 문제를 해결합니다. Keyword Search와 Semantic Search를 지원하므로 Tool의 정확한 이름을 몰라도 자연어로 요구 사항을 설명해 검색할 수 있습니다.
AWS Agent Registry는 2026년 4월 9일 Preview로 먼저 출시됐고 2026년 8월 31일 정식 General Availability가 됐습니다. GA 버전에는 Infrastructure as Code, Tags, AWS RAM Cross-account Sharing, AgentCore Runtime／Gateway Resource Auto-detection 같은 기업 관리 기능이 추가됐습니다. Preview에서 GA까지는 약 4개월 3주이며 4개월 미만은 아닙니다.
문제가 “Agent를 만들 수 있는가”에서 “Agent가 늘어난 뒤 어떻게 관리하는가”로 바뀌고 있기 때문입니다. 여러 팀이 Agent, MCP Server, Skills를 빠르게 만들 수 있게 되면 중복 구축, Shadow Agent, 불분명한 Owner, 중단된 Tool의 계속된 사용 같은 문제가 생깁니다. Registry의 가치는 AI 능력을 높이는 것이 아니라 기존 능력을 쉽게 찾고 이해하며 관리할 수 있게 하는 데 있습니다. 유지보수해야 할 Resource와 내려도 되는 Resource를 구분하기도 쉬워집니다.
그렇지 않습니다. Registry는 Discovery와 Governance 문제를 해결하지만 Resource의 품질을 자동으로 보장하지는 않습니다. 실제 사용 전에는 Owner, Version, Authentication, Permission Scope, 현재도 유지보수되는지, 조직의 Security／Compliance Review가 끝났는지 확인해야 합니다. Registry Metadata 자체에 Endpoint나 Architecture 정보가 들어갈 수 있으므로 “누가 검색할 수 있는가”와 “누가 Record를 만들거나 수정할 수 있는가”의 권한도 분리해 설계해야 합니다.
대부분 AWS Agent Registry를 직접 도입할 필요는 없지만 같은 관리 논리를 적용할 가치는 있습니다. 여러 Agent, Automation, MCP Server, OAuth Integration을 사용한다면 이름, 용도, Owner, Trigger, Tools／Connections, Read／Write 권한, 비용, Status, 마지막 작동 확인일을 기록한 간단한 Registry부터 만들 수 있습니다. 정리가 필요한 시점은 Agent가 1,000개가 됐을 때가 아니라 “이 Workflow가 지금도 작동하는가”에 답할 수 없게 됐을 때입니다.
Registry는 AWS CloudTrail과 연동되지만 Management Events와 Data Events를 구분해야 합니다. 생성과 업데이트 같은 Management Operations는 CloudTrail Event History에 표시됩니다. Discovery나 Search 같은 Data Events까지 기록하려면 별도로 Trail을 만들거나 조정하고 해당 Data Event Selector를 활성화해야 합니다. 따라서 “모든 Registry 행동이 기본으로 완전히 저장된다”고 단순화할 수는 없지만, AWS는 완전한 감사를 구성할 수 있는 기반을 제공합니다.
지원합니다. GA 버전에는 AWS Resource Access Manager, 즉 AWS RAM이 추가돼 Registry를 다른 AWS Accounts와 공유할 수 있습니다. 각 Account가 서로 보이지 않는 Catalog를 따로 관리하지 않고 더 중앙화된 Organization Registry를 만들 수 있습니다. Registry와 Records에는 Tags도 추가해 분류, 비용 배분, Access Control에 사용할 수 있습니다.
MCP는 “AI가 외부 Tools에 일관된 방식으로 연결되는 방법”을 해결합니다. Agent Registry는 “MCP Servers와 Agents가 늘어났을 때 무엇이 존재하고 무엇이 승인됐으며 누가 유지보수하는지 파악하는 방법”을 해결합니다. Registry는 MCP Server Definition과 Tool Metadata를 저장하고 기존 MCP Endpoint에서 관련 정보를 동기화할 수 있습니다. Registry 자체도 MCP Endpoint를 제공하므로 MCP Client가 조직 안의 승인된 Resource를 검색할 수 있습니다. 둘은 대체 관계가 아니라 서로 다른 계층의 Infrastructure입니다.
가능합니다. Agent Registry 자체가 MCP-compatible Endpoint를 제공하며 MCP Client는 승인된 Registry Records를 검색하고 나열하며 가져올 수 있습니다. 개발자가 IDE 등에서 Registry를 검색할 수 있을 뿐 아니라 Agent도 Registry를 Discovery Layer로 사용해 어떤 Agent, MCP Server, Skill을 이용할 수 있는지 확인한 뒤 Resource를 선택할 수 있습니다. 다만 Registry에서 Tool을 찾았다고 기반 System의 권한까지 자동으로 얻는 것은 아닙니다. 실제 실행 시에는 해당 Service의 Authentication과 Access Control을 충족해야 합니다.
현재는 그렇게 이해할 수 없습니다. AWS Agent Registry는 Approval Workflow, Record Lifecycle, EventBridge Hooks와 관련 API를 제공해 기업이 Security Scan, Duplicate Check, Compliance Review, 사람의 심사를 자체 공개 절차에 연결할 수 있게 합니다. 하지만 완전한 Automated Security Assessment와 De-duplication Analysis가 현재 GA에 모두 내장된 것은 아닙니다. AWS는 더 자동화된 Security／Compliance／Dedup Signals 중 일부를 향후 방향으로 제시했습니다. 따라서 APPROVED는 조직이 설정한 심사 기준을 통과했다는 의미이며 AWS가 그 Agent의 종합적인 안전 인증을 완료했다는 뜻은 아닙니다.
반드시 그렇지는 않습니다. Registry는 Manual Approval을 사용할 수도 있고 Auto-approve를 설정할 수도 있습니다. 고정된 규칙은 일반 Discovery Plane에서 현재 상태가 APPROVED인 최신 Record Revision만 검색되고 발견된다는 점입니다. Draft, Pending Approval, Rejected, Deprecated Record는 일반 Consumer Search에 나타나지 않습니다. 이후 Record를 수정하면 다시 Lifecycle에 들어가며 한 번 승인됐다고 같은 상태가 영구적으로 유지되는 것은 아닙니다.
현재 정식으로 지원하는 최상위 Record Type은 AGENT, MCP, SKILL, CUSTOM 네 가지입니다. MCP Server가 제공하는 Tools는 MCP Record의 Tool Definitions 안에 들어갑니다. 따라서 실제로 MCP Tools를 검색하고 관리할 수 있지만 Tool이 독립된 다섯 번째 Record Type은 아닙니다. 앞의 세 유형에 해당하지 않지만 기업이 Governance 범위에 넣고 싶은 Resource는 Custom Metadata로 저장할 수 있습니다.