회사 곳곳에서 AI 에이전트를 만들기 시작하면 뜻밖의 문제가 생깁니다. 누가 어떤 에이전트를 만들었는지, 어떤 데이터에 접근하는지, 비슷한 기능이 이미 있는지 아무도 정확히 모르게 됩니다. AWS가 2026년 8월 31일 ‘AWS Agent Registry’를 정식 출시한 배경입니다.
이 서비스는 에이전트뿐 아니라 에이전트가 쓰는 도구, 스킬, MCP 서버와 기타 자원을 회사 내부 목록에 등록하고 찾게 해줍니다. 단순한 앱스토어가 아니라 승인, 접근 제어, 변경 추적을 붙인 기업용 관리대장에 가깝습니다.
에이전트가 늘수록 생기는 그림자 IT
부서마다 고객 응대, 자료 조사, 개발 자동화 에이전트를 따로 만들면 같은 기능을 중복 개발하기 쉽습니다. 더 큰 문제는 담당자가 떠난 뒤에도 오래된 에이전트가 남아 예전 권한으로 작동하는 경우입니다. 일반 소프트웨어보다 에이전트가 위험한 이유는 스스로 도구를 골라 여러 단계를 실행할 수 있기 때문입니다.
레지스트리는 등록된 자원을 키워드와 의미 검색으로 찾게 하고 승인 절차와 감사 기록을 남깁니다. 무엇이 존재하는지 보여주는 가시성이 먼저 생겨야 중복을 줄이고 위험한 권한을 회수할 수 있습니다. 회사가 AI를 많이 도입할수록 ‘만드는 능력’보다 ‘파악하는 능력’이 중요해집니다.
MCP 시대의 사내 서비스 카탈로그
MCP는 AI가 외부 데이터와 도구를 호출하는 방식을 표준화합니다. 연결이 쉬워지는 만큼 검증되지 않은 서버나 도구가 회사 안으로 들어올 가능성도 커집니다. AWS는 MCP 서버 자체도 레지스트리에 등록하고, 개발자가 IDE에서 레지스트리를 MCP 서버처럼 조회할 수 있게 했습니다.
이 구조가 자리 잡으면 개발자는 새 에이전트를 만들기 전에 승인된 도구를 검색해 재사용할 수 있습니다. 보안팀은 어떤 에이전트가 어떤 도구를 쓰는지 추적할 기반을 얻습니다. 다만 목록에 등록됐다는 사실이 안전을 보증하는 것은 아닙니다. 코드 검토, 권한 범위, 데이터 처리 방식과 운영 이력을 별도로 평가해야 합니다.
자동 발견과 관리 코드화
정식 버전에는 AgentCore 실행 환경과 게이트웨이에 있는 에이전트를 자동으로 찾아 중앙 목록에 반영하는 기능이 추가됐습니다. 사람이 엑셀에 이름을 적는 방식으로는 빠르게 늘어나는 에이전트를 따라갈 수 없기 때문입니다. 클라우드포메이션, 테라폼, CDK로 레지스트리를 관리할 수 있어 인프라 변경과 같은 방식으로 승인 절차를 다룰 수도 있습니다.
태그는 비용 배분과 접근 통제에 활용됩니다. 어느 부서의 에이전트인지, 어떤 데이터 등급을 다루는지, 운영 책임자가 누구인지 표시할 수 있습니다. 기술적으로는 사소해 보이지만 실제 기업 도입에서는 이런 메타데이터가 사고 대응 시간을 크게 좌우합니다.
아직 AWS 안에 머무는 한계
Agent Registry는 현재 미국 버지니아·오리건, 도쿄, 시드니, 아일랜드 등 다섯 리전에서 제공됩니다. AWS의 AgentCore, Amazon Quick, Kiro와 자연스럽게 연결되는 대신 다른 클라우드와 사내 시스템까지 얼마나 일관되게 관리할 수 있는지는 별도 확인이 필요합니다.
또 중앙 목록은 통제의 출발점일 뿐입니다. 잘못된 에이전트를 빠르게 폐기하고, 권한이 바뀌었을 때 연결된 도구까지 함께 갱신하는 운영 절차가 없으면 목록만 최신인 척할 수 있습니다. 기업이 봐야 할 핵심 지표는 등록 수가 아니라 미등록 에이전트 비율, 권한 검토 주기, 사고 시 차단 시간입니다.
AWS의 출시는 에이전트 시장이 실험 단계를 지나 운영 단계로 들어가고 있다는 신호입니다. 에이전트를 만드는 도구 다음에 돈이 되는 것은 그 에이전트를 찾아내고, 승인하고, 책임자를 붙이는 관리 계층입니다.