왜 지금 도구 레지스트리가 중요해지나

초기 AI 에이전트는 미리 등록된 몇 개의 도구만 사용했다. 웹 검색, 파일 읽기, 이메일 전송, 캘린더 수정처럼 에이전트 런타임에 이미 들어 있는 도구 목록 안에서 LLM이 하나를 고르는 구조다. 도구 수가 적을 때는 이 방식이 단순하고 효과적이다.

문제는 에이전트가 실제 업무 환경으로 들어가면서 생긴다. 회사에는 HR 시스템, 결재 API, 데이터웨어하우스, Jira, GitHub, Slack, CRM, 회계 시스템, 사내 문서 검색, 배포 파이프라인 같은 수많은 도구가 있다. 모든 도구를 에이전트 설정에 수동으로 등록하고, 모든 도구 설명을 매번 LLM 컨텍스트에 넣는 방식은 오래 버티기 어렵다.

여기서 도구 레지스트리의 필요성이 나온다. 에이전트가 처음부터 모든 도구를 들고 있는 것이 아니라, 필요한 순간에 “이 작업에 맞는 능력이 어디에 있는가”를 검색하고, 검증하고, 선택 후보로 가져오는 구조가 필요하다.

앱스토어 비유가 유용한 이유

스마트폰 앱 생태계에서 앱스토어는 단순 파일 저장소가 아니다. 사용자는 앱스토어에서 앱을 검색하고, 설명과 리뷰를 보고, 권한을 확인하고, 설치한다. 개발자는 앱을 등록하고, 버전을 관리하고, 배포 채널을 얻는다. 플랫폼은 정책, 결제, 보안, 심사, 업데이트를 관리한다.

AI 에이전트 도구 레지스트리도 비슷한 문제를 다룬다. 다만 사용자가 사람이 아니라 에이전트라는 점이 다르다. 에이전트는 앱 아이콘이나 마케팅 문구보다 기계가 읽을 수 있는 메타데이터가 필요하다. 어떤 작업에 적합한지, 호출 방식은 무엇인지, 누가 제공하는지, 신뢰할 수 있는지, 어떤 권한이 필요한지를 구조화된 형태로 받아야 한다.

Agent Registry는 무엇을 저장하나

레지스트리가 저장하거나 색인하는 것은 “코드 전체”가 아닐 수 있다. 더 중요한 것은 에이전트가 판단할 수 있는 설명과 연결 정보다. 예를 들어 어떤 MCP 서버가 있다면, 레지스트리는 그 서버가 어떤 기능을 제공하는지, 어떤 자연어 요청에 적합한지, 어떤 URL이나 엔드포인트로 연결되는지, 누가 게시했는지, 어떤 인증이 필요한지 같은 정보를 다룬다.

Google Developers Blog가 소개한 Agentic Resource Discovery, ARD는 이 문제를 표준 명세 관점에서 다룬다. ARD 공식 문서는 이를 “AI 클라이언트가 이 작업에 무엇을 사용할 수 있는가를 물으면, 발견 서비스가 맞는 리소스를 돌려주는 개방형 발견 프로토콜”로 설명한다. 또한 ARD는 호출 런타임이 아니라 호출 전 발견 계층이라고 못박는다.

Google Cloud 문서의 Agent Registry도 같은 흐름을 제품 인프라 관점에서 보여준다. 문서 목차만 봐도 agents, endpoints, MCP servers, tools, discovery, search, access control 같은 항목이 함께 등장한다. 즉, 레지스트리는 단순 목록 페이지가 아니라 에이전트와 도구를 운영하는 관리 계층으로 확장된다.

도구 레지스트리가 해결하려는 5가지 문제

1. 에이전트가 모든 도구를 미리 알 필요가 없다

현재 방식에서는 도구를 쓰려면 에이전트 설정이나 코드에 먼저 등록해야 한다. 레지스트리 방식에서는 필요한 능력을 검색해 후보를 가져올 수 있다. 이는 도구가 수십 개에서 수백 개로 늘어날 때 특히 중요하다.

2. LLM 컨텍스트에 모든 도구 설명을 넣지 않아도 된다

도구 설명이 많아질수록 컨텍스트 비용과 선택 오류가 커진다. 레지스트리는 전체 도구 목록을 매번 LLM에 주는 대신, 검색으로 소수 후보를 좁히는 역할을 할 수 있다. LLM은 모든 도구가 아니라 관련 후보 안에서 선택한다.

3. 신뢰와 출처를 기계적으로 확인할 수 있다

에이전트가 런타임에 도구를 찾는다면 피싱 도구나 잘못된 엔드포인트를 피해야 한다. 도메인 기반 카탈로그, 게시자 정보, trust metadata, 조직 정책은 “이 도구를 믿고 연결해도 되는가”라는 질문에 답하기 위한 장치다.

4. 기업 내부 도구 거버넌스가 가능해진다

기업에서는 공개 웹보다 사내 레지스트리가 먼저 중요해질 수 있다. 어떤 에이전트가 어떤 도구를 호출할 수 있는지, 민감 데이터가 외부로 나가지 않는지, 승인된 MCP 서버만 쓰는지, 감사 로그가 남는지 같은 문제가 실제 운영 병목이 되기 때문이다.

5. 도구 생태계가 플랫폼을 넘어 연결된다

한 회사의 에이전트 플랫폼 안에서만 도구를 찾는 구조는 폐쇄적이다. ARD 문서가 강조하듯, 공개 웹과 기업 내부에는 여러 발견 서비스가 존재할 수 있다. 이는 하나의 중앙 앱스토어가 아니라, 여러 레지스트리가 서로 다른 커뮤니티와 정책에 맞게 색인하는 구조에 가깝다.

MCP, A2A, ARD와의 관계

이 주제에서 가장 흔한 혼동은 레지스트리와 실행 프로토콜을 섞는 것이다. MCP는 도구를 연결하고 호출하는 방식이다. A2A는 에이전트 간 협업 방식이다. OpenAPI는 HTTP API를 설명하고 호출하는 방식이다. 반면 Agent Registry와 ARD는 그런 리소스를 “어디서 찾고 어떻게 믿을 것인가”에 초점을 둔다.

따라서 Agent Registry는 MCP의 경쟁자가 아니다. 오히려 MCP 서버가 많아질수록 “좋은 MCP 서버를 어떻게 찾고, 공식 제공자인지 어떻게 확인하고, 우리 조직 정책상 호출 가능한지 어떻게 판단할 것인가”라는 문제가 생긴다. 레지스트리는 이 질문을 다루는 계층이다.

개발자와 운영자가 지금 준비할 것

1. 도구 인벤토리를 만든다. 사내 API, MCP 서버, 자동화 스크립트, 워크플로, 데이터 조회 기능을 “에이전트가 호출 가능한 리소스” 관점으로 정리한다.
2. 사람용 문서와 기계용 메타데이터를 분리한다. 블로그 글이나 README만으로는 부족하다. 대표 질의, capability, 입력/출력, 권한, 제한사항이 구조화되어야 한다.
3. 공개 리소스와 내부 리소스를 나눈다. 공개 웹에서 발견되어도 되는 도구와 사내 에이전트만 써야 하는 도구는 레지스트리 정책이 달라야 한다.
4. 신뢰 모델을 설계한다. 도메인 소유권, 게시자 검증, 승인된 엔드포인트, 버전 고정, 감사 로그가 필요하다.
5. LLM에게 모든 도구를 주지 않는 구조를 고려한다. 검색, 후보 축소, 정책 필터링, 최종 선택의 단계를 나누면 비용과 오류를 줄일 수 있다.

앱스토어 다음은 정말 Agent Registry인가

비유로는 그렇다. 사람 중심 컴퓨팅에서 앱스토어가 앱 발견과 유통의 중심이었다면, 에이전트 중심 컴퓨팅에서는 레지스트리가 도구 발견과 거버넌스의 중심이 될 가능성이 있다. 다만 수익 배분, 리뷰, 설치 같은 소비자 앱스토어 모델이 그대로 복제된다고 보기는 어렵다.

더 현실적인 모습은 세 가지가 공존하는 구조다. 공개 웹에는 여러 오픈 레지스트리가 생기고, 클라우드 플랫폼은 관리형 Agent Registry를 제공하며, 기업 내부에는 사내 도구만 색인하는 프라이빗 레지스트리가 생긴다. 에이전트는 작업에 따라 이 중 하나 또는 여러 발견 계층을 사용한다.

이 변화가 중요한 이유는 에이전트의 능력이 모델 크기만으로 결정되지 않기 때문이다. 어떤 도구를 찾을 수 있는지, 어떤 데이터를 안전하게 조회할 수 있는지, 어떤 워크플로를 신뢰하고 실행할 수 있는지가 실제 업무 성능을 좌우한다. 모델이 두뇌라면, 레지스트리는 외부 세계와 연결되는 주소록이자 검증된 도구 상자다.

짧은 결론

AI 에이전트 도구 레지스트리는 단순한 목록 서비스가 아니다. 에이전트가 사용할 수 있는 능력을 발견하고, 설명하고, 검증하고, 정책에 맞게 연결하는 인프라다. ARD, Agent Registry, MCP 서버 검색, 사내 도구 카탈로그는 모두 같은 방향을 가리킨다. 앞으로의 질문은 “어떤 모델을 쓰는가”뿐 아니라 “그 모델이 어떤 검증된 도구 생태계에 접근할 수 있는가”가 된다.

FAQ

AI 에이전트 도구 레지스트리는 무엇인가

AI 에이전트가 사용할 수 있는 도구, 스킬, MCP 서버, API, 워크플로, 다른 에이전트를 검색하고 검증하기 위한 카탈로그 또는 검색 계층이다.

Agent Registry는 앱스토어와 같은가

비유로는 비슷하지만 완전히 같지는 않다. 앱스토어는 사람이 앱을 찾고 설치하는 유통 채널이고, Agent Registry는 에이전트가 호출 가능한 리소스를 발견하고 신뢰 정보를 확인하는 기술 계층에 가깝다.

Agent Registry가 MCP를 대체하나

대체하지 않는다. MCP는 발견된 도구를 실제로 연결하고 호출하는 방식 중 하나다. 레지스트리는 MCP 서버를 어디서 찾고 어떻게 신뢰할지 다룬다.

기업은 왜 자체 레지스트리가 필요할 수 있나

기업 내부 도구와 데이터는 권한, 감사, 정책, 보안 요구사항이 강하다. 공개 레지스트리만으로는 부족하기 때문에 사내 도구를 색인하고 승인된 에이전트만 접근하게 하는 프라이빗 레지스트리가 필요할 수 있다.

공식 출처와 같이 읽을 글

• Google Developers Blog: Announcing the Agentic Resource Discovery specification
• Agentic Resource Discovery 공식 문서
• ARD How to publish 가이드
• Google Cloud Agent Registry overview
• Agentic Resource Discovery란? AI 에이전트가 도구를 직접 찾는 검색 표준
• llms.txt 작성 방법 Best Practice
• AI 검색 최적화 GEO란?

The post AI 에이전트 도구 레지스트리 시대: 앱스토어 다음은 Agent Registry인가 appeared first on .