오윤성 기자

구글과 마이크로소프트가 주도하고 세일즈포스·스노우플레이크·서비스나우·시스코·데이터브릭스·깃허브·고대디·허깅페이스·엔비디아까지 가세한 11개사가 지난 6월 17일 ‘에이전틱 리소스 디스커버리(ARD)’ 초안 스펙을 공개했다. AI 에이전트가 작업에 필요한 도구·API·MCP 서버를 어떻게 “찾아내는가”를 표준화하는 발견(discovery) 계층이다. 정작 MCP를 만든 앤스로픽과 챗GPT의 오픈AI는 이 연합에 이름을 올리지 않았다.

ARD의 구조는 두 축으로 이뤄진다. 조직이 자신의 도메인 내 정해진 경로에 ai-catalog.json 매니페스트를 올려 어떤 MCP 서버·A2A 에이전트·OpenAPI 도구를 제공하는지 공표하면, 별도의 레지스트리가 이 카탈로그들을 크롤링·인덱싱해 에이전트의 자연어 질의에 응답하는 방식이다. 구글은 발표문에서 이 과정을 발행-발견-암호화 검증-런타임 연결 4단계로 설명했다. 라이선스는 아파치 2.0이며, 리눅스 파운데이션 산하 AI Catalog 워킹그룹이 데이터 모델을 관리한다. 구글은 향후 몇 달 안에 구글 클라우드 Agent Registry에 ARD 네이티브 지원을 추가하고 인증 퍼블리셔 온보딩을 시작하겠다고 밝혔다. 구글의 스리니바스 크리슈난은 “문제 자체는 단순하지만, 특히 기업 환경에서는 보안과 신원 검증이 처음부터 내장돼야 한다”고 말했고, 마이크로소프트의 제니퍼 마스먼은 “단일 글로벌 카탈로그가 목표가 아니며 여러 발견 서비스가 공존할 것”이라고 밝혔다(출처: InfoQ, 2026년 7월).

ARD는 MCP를 대체하지 않는다. MCP가 에이전트와 도구가 “대화하는” 통신 규격이라면, ARD는 그 이전 단계 — 에이전트가 애초에 그 도구의 존재를 “찾아내는” 발견 계층이다. AI 마케팅 매체 리스토(Listo)는 이 관계를 MCP가 상호작용 문제(에이전트가 도구와 어떻게 통신하는가)를 풀었다면, ARD는 발견 문제(에이전트가 애초에 그 도구를 어떻게 찾아내는가)를 푸는 것이라고 정리했다(출처: Listo). 실제로 스펙 자체도 클로드·챗GPT·깃허브 코파일럿·마이크로소프트 코파일럿·제미나이를 ARD의 “저자”가 아니라 ARD를 소비하는 “클라이언트”로 취급한다.

바로 이 구도가 앤스로픽·오픈AI의 불참을 해석하는 열쇠다. ARD 연합에 이름을 올린 11개사는 대부분 모델을 직접 만드는 회사가 아니라, 에이전트가 결국 닿고 싶어하는 도구·데이터·엔터프라이즈 플랫폼을 이미 소유한 회사들이다. 세일즈포스의 CRM, 스노우플레이크·데이터브릭스의 데이터 웨어하우스, 서비스나우의 워크플로, 깃허브의 코드 저장소가 그 예다. 이들 입장에서 “발견 계층”을 자신들이 주도해 표준화하면, 어느 모델사의 에이전트가 붙든 자사 플랫폼이 검색되고 선택되는 관문 자리를 유지할 수 있다. 반대로 앤스로픽과 오픈AI는 모델과 에이전트 자체가 곧 제품이기 때문에, 도구 발견 경로를 외부 인프라 벤더 연합에 표준으로 넘겨줄 유인이 상대적으로 적다. AI 위클리는 이를 “구글·마이크로소프트가 앤스로픽의 MCP에 맞서 ARD를 지원한다”는 구도로 보도했는데, 정확히는 MCP를 무력화하려는 대체재라기보다 그 위에 올라타는 상위 계층을 누가 통제하느냐의 문제에 가깝다.

이 싸움의 승부처는 결국 “에이전트가 먼저 어디를 보는가”다. 검색엔진 시대에 색인·랭킹을 쥔 쪽이 웹 트래픽의 관문이 됐던 것처럼, 에이전트 시대에는 카탈로그 레지스트리를 쥔 쪽이 도구 호출 트래픽의 관문이 될 가능성이 있다. ARD는 아직 초안 단계(ARD 공식 스펙 문서에 따르면 버전 v0.9)이고, 앤스로픽·오픈AI가 앞으로도 계속 불참할지, 별도 발견 계층을 자체적으로 밀지는 확인되지 않았다. 다만 이번 참여사 명단만 보면 클라우드·SaaS 벤더들이 모델 경쟁이 아니라 “에이전트가 무엇을 먼저 보게 할 것인가”라는 인터페이스 경쟁으로 전선을 옮기고 있다는 신호로는 충분하다.

오윤성 기자