Agentic Resource Discovery란? ai-catalog.json과 폰 에이전트 신뢰 경계
Agentic Resource Discovery, ai-catalog.json, 카탈로그와 레지스트리, 게시자 검증, MCP·A2A·OpenAPI 연결을 설명하고 폰 에이전트에서 검색과 권한 부여를 분리해야 하는 이유를 정리합니다.
- Agentic Resource Discovery는 웹 전반의 도구, 스킬, 에이전트를 게시하고 찾고 검증하기 위한 공개 사양이며, ai-catalog.json은 그런 리소스의 위치와 인터페이스를 설명하는 카탈로그 역할을 합니다.
- ARD는 MCP, A2A, OpenAPI 같은 실행 프로토콜을 대체하지 않고, 어떤 리소스가 어디에 있고 어떤 방식으로 연결되는지 알려 준 뒤 네이티브 인터페이스로 넘깁니다.
- 게시자 검증은 도구의 출처와 메타데이터 신뢰를 높여 주지만, 그 도구가 사용자에게 안전하거나 Android 작업 권한을 가진다는 뜻은 아닙니다.
- 폰 에이전트 런타임은 검색 이후에도 도구 활성화, 엔드포인트 검증, Android 권한, 대상 확인, 위험도 기반 승인, 실행 기록, 철회를 별도로 처리해야 합니다.
목차
Agentic Resource Discovery가 해결하려는 문제
Agentic Resource Discovery, 줄여서 ARD는 AI 에이전트가 웹에서 사용할 수 있는 도구, 스킬, 에이전트를 찾고 검증하기 위한 공개 사양입니다. 핵심은 단순합니다. 사람이 웹사이트 주소를 보고 서비스를 찾듯이, 에이전트도 조직이 공개한 카탈로그를 통해 “어떤 기능이 있고, 누가 게시했으며, 어떤 프로토콜로 연결해야 하는지”를 읽을 수 있어야 합니다.
Google은 2026년 6월 17일 Agentic Resource Discovery 사양 발표에서 ARD를 도구, 스킬, 에이전트를 웹 전반에서 게시하고 발견하고 검증하는 방식으로 설명했습니다. 여기서 ai-catalog.json은 리소스의 안내판에 가깝습니다. 카탈로그 파일은 기능 이름만 나열하는 목록이 아니라, 게시자, 설명, 연결 방식, 지원 인터페이스, 신뢰 메타데이터를 에이전트가 읽을 수 있는 형태로 정리합니다.
이 사양이 필요한 이유는 에이전트 생태계가 빠르게 흩어지고 있기 때문입니다. 어떤 도구는 MCP 서버로 제공되고, 어떤 서비스는 OpenAPI로 열려 있으며, 어떤 에이전트는 A2A 방식으로 상호작용합니다. 개별 공급자마다 사설 등록 절차를 만들면 검색은 폐쇄적이 되고, 에이전트는 매번 별도 통합을 배워야 합니다. ARD는 기능을 실행하는 표준이 아니라, 기능을 찾고 신뢰할 출발점을 확인하는 공통 검색 계층입니다.
카탈로그와 레지스트리가 기능을 게시하고 찾는 방식
ARD 흐름은 게시, 발견, 검증, 연결로 나눠 보면 가장 이해하기 쉽습니다. 먼저 공급자는 자기 도메인 아래에 ai-catalog.json 같은 카탈로그를 둡니다. 그 카탈로그는 사용할 수 있는 도구, 스킬, 에이전트, 중첩 카탈로그, 지원 프로토콜을 설명합니다. 입력은 공급자가 관리하는 도메인과 리소스 메타데이터이고, 출력은 에이전트가 읽을 수 있는 도구 카탈로그입니다.
다음 단계는 발견입니다. 에이전트 클라이언트는 이미 아는 파트너 도메인의 카탈로그를 직접 가져올 수도 있고, 레지스트리에 의도 기반 질의를 보낼 수도 있습니다. 예를 들어 “영수증을 읽어 비용 보고서 초안을 만들 수 있는 도구”를 찾는 경우, 레지스트리는 인덱싱한 여러 카탈로그에서 조건에 맞는 후보를 돌려줄 수 있습니다. 이때 레지스트리는 실행 대행자가 아니라 검색 색인입니다. 어떤 후보가 유용해 보이는지 알려 줄 뿐, 사용자의 계정으로 작업을 수행하지 않습니다.
공개된 ARD 사양 저장소는 스키마, 신뢰 구조, 참조 작업을 공개적으로 발전시키는 공간입니다. 사양상 카탈로그 항목은 MCP 서버, A2A 에이전트, OpenAPI 도구, 다른 카탈로그를 광고할 수 있습니다. 따라서 ai-catalog.json 도구 카탈로그를 볼 때는 “여기에 실행 코드가 들어 있나”가 아니라 “어떤 네이티브 인터페이스로 연결해야 하나”를 확인해야 합니다.
| 단계 | 입력 | 출력 | 폰 에이전트 관점 |
|---|---|---|---|
| 게시 | 공급자 도메인과 리소스 설명 | ai-catalog.json 카탈로그 | 출처를 확인할 후보 목록이 생김 |
| 발견 | 의도 질의 또는 직접 도메인 요청 | 관련 리소스 후보 | 연결 전 검증 대상을 좁힘 |
| 검증 | 게시자 메타데이터와 카탈로그 무결성 | 출처 신뢰 판단 | 정책 심사의 재료가 됨 |
| 연결 | 광고된 MCP, A2A, OpenAPI 등 | 네이티브 프로토콜 세션 | 실행 전 로컬 권한 검사가 필요함 |
게시자 검증이 증명하는 것과 남겨 두는 위험
신뢰 가능한 에이전트 도구 목록을 만들려면 “누가 게시했는지”부터 확인해야 합니다. ARD가 말하는 검증의 장점은 여기에 있습니다. 에이전트가 어떤 도구 설명을 보았을 때, 그 설명이 실제 공급자 도메인에서 왔는지, 카탈로그 메타데이터가 의도한 게시자와 연결되는지, 연결 전 확인할 신뢰 신호가 있는지 판단할 수 있습니다.
하지만 게시자 검증은 안전 판정 전체가 아닙니다. 올바른 회사가 게시한 도구라도 현재 사용자에게 적합하지 않을 수 있고, 엔드포인트가 바뀌었을 수 있으며, 도구 설명이 넓어서 실제 권한 범위를 따로 제한해야 할 수도 있습니다. 도메인 소유권은 출처를 설명합니다. 사용자 승인, Android 권한, 비즈니스 결과, 데이터 최소화는 다른 문제입니다.
따라서 검증 단계의 출력은 “연결을 검토할 만한 신뢰 신호”로 보는 편이 정확합니다. 출처가 확인되면 다음 질문으로 넘어갈 수 있습니다. 이 인터페이스는 우리가 지원하는 프로토콜인가, 요청할 범위가 사용자 목적에 맞는가, 데이터가 어디로 이동하는가, 실패했을 때 중단과 철회가 가능한가. 폰 에이전트에서는 특히 마지막 질문이 중요합니다. 화면 위의 한 번의 탭이 메시지 전송, 위치 공유, 계정 변경 같은 외부 결과로 이어질 수 있기 때문입니다.
ARD가 MCP, A2A, OpenAPI, 앱 계약으로 넘기는 지점
ARD가 MCP, A2A, OpenAPI를 대체한다고 이해하면 설계가 흐려집니다. ARD는 “무엇을 어디서 찾을 수 있는가”를 해결하고, 실제 연결은 카탈로그가 광고한 네이티브 인터페이스를 따릅니다. MCP 서버라면 MCP 계약을 검증해야 하고, A2A 에이전트라면 그 에이전트의 대화와 작업 계약을 확인해야 하며, OpenAPI 도구라면 스키마, 인증, 오류 응답, 범위를 따져야 합니다.
모바일 앱 작업은 여기에 별도 현실을 더합니다. 앱이 머신 호출 가능한 계약을 제공해야 에이전트가 안정적으로 호출할 수 있고, 단순히 앱 이름이 카탈로그에 보인다고 해서 Android에서 버튼을 누를 권한이 생기는 것은 아닙니다. 앱 호출 계약을 더 깊게 보고 싶다면 App Intents와 머신 호출 가능 앱: AI 에이전트가 앱 작업을 실행하는 방식에서 발견 이후의 앱 실행 구조를 이어서 확인할 수 있습니다.
좋은 연결 흐름은 세 문장으로 정리됩니다. ARD는 후보를 찾고 출처를 검증합니다. 네이티브 프로토콜은 그 후보와 어떻게 대화할지 정합니다. 폰 에이전트 런타임은 그 대화가 실제 Android 작업으로 넘어가기 전에 권한, 대상, 승인, 결과 표시를 통제합니다. 이 세 단계를 합쳐 말하면 편해 보이지만, 문제가 생겼을 때 어느 계층에서 막아야 하는지 알 수 없습니다.
폰에서는 검색이 권한 부여가 아닌 이유
ai-catalog.json 도구 카탈로그에서 어떤 기능을 발견했다는 사실은 “이 도구를 실행해도 된다”는 허가가 아닙니다. 특히 폰에서는 검색과 권한 부여를 강하게 분리해야 합니다. Android 권한은 기능이 필요한 시점에 맥락 안에서 요청하는 것이 기본이며, Android 런타임 권한 가이드도 권한 요청과 거부 처리 책임이 앱에 남아 있음을 전제로 설명합니다.
예를 들어 카탈로그가 “지도 경로를 만들 수 있는 도구”를 광고한다고 합시다. 검색 계층은 그 도구가 존재함을 알려 줍니다. 게시자 검증은 출처가 맞는지 확인합니다. 하지만 사용자의 현재 위치 접근, 목적지 확인, 지도 앱 실행, 공유 여부, 최종 전송은 별도의 결정입니다. Android 위치 권한이 허용되어 있어도 “이 위치를 누구에게 보내도 된다”는 의미는 아닙니다. 앱 권한과 업무 결과는 서로 다른 판단입니다.
| 판단 항목 | 확인하는 것 | 증명하지 않는 것 |
|---|---|---|
| 게시자 identity | 리소스가 어느 공급자에게서 왔는지 | 모든 동작이 사용자에게 안전하다는 점 |
| 메타데이터 무결성 | 카탈로그 설명이 변조되지 않았는지 | 실제 엔드포인트가 항상 기대대로 응답한다는 점 |
| 엔드포인트 호환성 | MCP, A2A, OpenAPI 등으로 연결 가능한지 | 폰에서 해당 앱 작업을 실행할 권한 |
| 도구 활성화 | 런타임에서 해당 도구 사용을 허용했는지 | 특정 대상에게 실행해도 된다는 승인 |
| Android 권한 | 기능 수행에 필요한 기기 접근이 허용됐는지 | 외부 결과나 비즈니스 행동의 승인 |
| 작업 승인 | 사용자가 이번 실행의 대상과 결과를 확인했는지 | 다음 실행까지 자동으로 허용된다는 점 |
| 철회와 기록 | 무엇을 했고 어떻게 멈출 수 있는지 | 처음 발견한 리소스가 계속 유효하다는 점 |
스킬과 권한의 실행 중 검사를 더 깊게 보려면 AI 에이전트 스킬 보안: 검사 통과보다 실행 중 권한 확인이 중요한 이유가 도움이 됩니다. 신원, 권한, 활동 기록을 더 넓게 설계해야 하는 팀은 AI 에이전트 신원, 권한, 감사 추적: 폰 에이전트에 필요한 안전 스택에서 감사 추적과 책임 경계를 이어서 볼 수 있습니다.
발견한 리소스를 연결하고 실행하기 전 체크리스트
ARD로 찾은 리소스를 폰 에이전트에 붙이기 전에는 연결 전 검사와 실행 전 검사를 나눠야 합니다. 연결 전 검사는 “이 리소스를 후보로 받아들일 수 있는가”를 묻고, 실행 전 검사는 “이번 사용자 작업에 이 기능을 써도 되는가”를 묻습니다. 두 질문을 하나로 합치면 카탈로그 신뢰가 사용자 권한처럼 오해됩니다.
- 게시자 확인: 도메인, 메타데이터, 신뢰 신호가 기대한 공급자와 맞는지 확인합니다.
- 카탈로그 최신성 확인: 오래된 설명, 중첩 카탈로그 오류, 사라진 엔드포인트가 없는지 봅니다.
- 인터페이스 검증: 광고된 MCP, A2A, OpenAPI, 앱 계약이 실제 런타임에서 지원되는지 테스트합니다.
- 범위 제한: 필요한 기능만 켜고, 넓은 읽기나 외부 효과가 있는 도구는 별도 정책에 둡니다.
- 낮은 위험 작업부터 시작: 화면 읽기나 상태 확인처럼 되돌리기 쉬운 작업으로 연결 품질을 봅니다.
- 대상과 결과 확인: 메시지 수신자, 위치 공유 대상, 파일 삭제 범위처럼 바뀌면 위험해지는 값을 실행 직전에 보여 줍니다.
- 승인과 중단: 위험도에 맞는 승인 흐름, 즉시 중단, 재시도 제한을 둡니다.
- 기록과 철회: 어떤 리소스가 어떤 도구를 호출했고 어떤 결과를 만들었는지 남기며, 비활성화와 권한 철회 경로를 유지합니다.
이 체크리스트의 목적은 도입을 늦추는 것이 아니라 실패 위치를 명확히 하는 것입니다. 검색이 잘못됐는지, 검증이 실패했는지, 프로토콜이 맞지 않는지, Android 권한이 부족한지, 사용자가 승인하지 않은 결과인지 구분할 수 있어야 복구도 정확해집니다. 조용히 다른 엔드포인트로 우회하는 방식은 폰 작업에서 특히 위험합니다. 사용자가 보고 승인한 리소스와 실제 호출된 리소스가 달라지기 때문입니다.
FoneClaw가 카탈로그 표시와 폰 권한을 분리하는 방식
FoneClaw에서 우리는 카탈로그에 보이는 기능과 휴대폰에서 실행할 권한을 별도로 다룹니다. FoneClaw는 Android 폰 에이전트 런타임이며, 구성된 호환 모델이 이해와 계획을 맡고 FoneClaw가 지원되는 Android 도구를 호출합니다. 이 글의 맥락에서 중요한 점은 FoneClaw가 ARD 구현을 주장하는 것이 아니라, 폰 런타임에서 카탈로그 표시와 실행 권한을 분리하는 실제 운영 원칙을 보여 준다는 점입니다.
2026년 8월 1일 기준 FoneClaw 공개 도구 카탈로그의 dated snapshot에는 11개 범주의 118개 built-in tools가 있으며, durable copy에서는 100+ built-in tools라고 표현하는 편이 더 정확합니다. 항목에는 화면, 기기, 커뮤니케이션, 위치, 워크플로, 스킬, 플러그인 관련 표면의 위험도와 승인 라벨이 포함됩니다. 이 카탈로그는 사용자가 어떤 기능을 기대할 수 있는지 보여 주지만, 모든 작업을 자동 승인한다는 뜻은 아닙니다.
FoneClaw 0.1.0 release data는 per-tool management, safer contracts, permission recovery, trusted plugin continuation 같은 흐름을 포함합니다. 플러그인 설치도 보이는 제안에서 출발해야 하며, 조용히 발견하고 설치하고 실행하는 방식으로 설명하지 않습니다. 권한은 필요한 맥락에서 안내되고, 도구는 켜짐 상태와 승인 정책을 통해 다뤄집니다.
FoneClaw의 전체 Android 의도-실행 구조가 필요하다면 AI 에이전트 폰 제어란 무엇인가: 안드로이드 폰 에이전트가 실제로 해야 할 일에서 지원 작업, 권한, 확인 흐름을 더 넓게 볼 수 있습니다. 여기서는 ARD와 같은 검색 계층이 유용해질수록, 폰 런타임 내부의 도구 정책과 승인 흐름이 더 중요해진다는 점을 분명히 두고 싶습니다. 좋은 모델은 계획을 만들고, 좋은 카탈로그는 후보를 보여 주며, FoneClaw 같은 런타임은 지원되는 Android 작업을 보이는 결과와 통제 가능한 권한 안에서 수행합니다.
에이전트 리소스 레지스트리 도입 전 테스트할 것
팀이 ARD나 유사한 에이전트 리소스 레지스트리를 도입하려면 “잘 찾는가”만 테스트하면 부족합니다. 검색 품질, 신뢰 메타데이터, 프로토콜 호환성, 정책 집행, 실행 복구를 독립적으로 관찰해야 합니다. 특히 폰 에이전트에서는 잘못된 후보 하나가 화면 작업, 연락처, 위치, 메시지, 시스템 설정과 연결될 수 있습니다.
| 테스트 항목 | 측정할 신호 | 실패 시 조치 |
|---|---|---|
| 검색 정확도 | 의도와 맞지 않는 후보 비율 | 질의 해석과 카탈로그 설명을 조정 |
| 카탈로그 신선도 | 사라진 엔드포인트, 오래된 스키마 | 캐시 만료와 재검증 주기를 단축 |
| 검증 실패 | 게시자 불일치, 무결성 오류 | 연결을 중단하고 사용자에게 후보 제외를 표시 |
| 정책 거부 | 도구 비활성화, 위험도 초과, 승인 누락 | 더 낮은 위험 경로 또는 수동 처리로 전환 |
| 복구 가능성 | 중단, 철회, 기록 확인 가능 여부 | 실행 전 대상 표시와 활동 기록을 강화 |
도입 결론은 위험도에 따라 달라져야 합니다. 읽기 중심의 내부 도구 검색은 비교적 낮은 범위에서 시작할 수 있지만, 메시지 전송, 위치 공유, 파일 변경, 계정 설정 같은 폰 작업은 더 엄격한 실행 전 확인이 필요합니다. ARD는 에이전트가 웹의 기능을 찾는 방식을 표준화할 수 있는 중요한 시도입니다. 폰 에이전트가 신뢰를 얻으려면 그 다음 단계, 즉 발견한 기능을 언제 연결하고 언제 실행하며 언제 멈출지까지 별도로 보여 줘야 합니다.