Agentic Resource Discovery 설계법: MCP·OpenAPI 도구를 안전하게 찾고 검증하기

에이전트가 많아질수록 다음 문제가 커진다. 필요한 도구가 어디에 있는지, 그 도구가 정말 신뢰할 수 있는지, 연결해도 안전한지 어떻게 알 수 있을까. Google이 공개한 Agentic Resource Discovery, 줄여서 ARD는 이 문제를 웹 수준의 발견·검증 레이어로 풀려는 공개 사양이다.

ARD는 MCP 서버, A2A 에이전트, OpenAPI 도구, nested catalog 같은 AI capability를 조직의 도메인 아래 catalog로 공개하고, registry가 이를 색인하게 하는 구조를 제안한다. 에이전트는 자연어 의도나 알려진 파트너 도메인을 통해 capability를 찾고, trust metadata를 검증한 뒤 native protocol로 직접 연결한다.

핵심 키워드는 Agentic Resource Discovery, ARD, MCP 보안, AI 도구 검색, 에이전트 검증이다. 이 글은 표준 소개에 그치지 않고, 사내 에이전트 플랫폼에서 비슷한 구조를 설계할 때 필요한 보안 기준과 운영 절차를 정리한다.

왜 도구 발견 표준이 필요한가

지금의 에이전트 도구 생태계는 파편화되어 있다. 팀마다 MCP 서버를 만들고, 부서마다 내부 API를 감싸고, SaaS마다 별도 tool registry를 제공한다. 문제는 에이전트가 조직 경계를 넘을 때 생긴다. 어느 도구가 최신인지, 누가 운영하는지, 어떤 권한이 필요한지, 안전한 endpoint인지 확인하기 어렵다.

예를 들어 운영 에이전트가 장애를 분석한다고 하자. 로그 시스템, 배포 이력, 문서 검색, 티켓 시스템, 알림 채널, 전문 진단 에이전트가 필요할 수 있다. 이 capability들이 서로 다른 플랫폼에 흩어져 있다면 에이전트는 사전에 하드코딩된 목록만 쓸 수 있다. 새로운 도구가 생겨도 자동으로 발견하기 어렵다.

ARD가 제안하는 방향은 “capability를 웹처럼 발견 가능하게 만들자”는 것이다. 조직은 자기 도메인 아래 catalog를 공개하고, registry는 이를 검색 가능하게 만들며, 클라이언트 에이전트는 연결 전 검증을 수행한다.

ARD의 기본 구성: catalog와 registry

ARD는 두 가지 기본 단위를 사용한다. Catalog는 조직이 자기 도메인에 공개하는 capability 목록이다. 여기에 MCP 서버, A2A 에이전트, OpenAPI 도구, 다른 catalog 링크가 들어갈 수 있다. 중요한 점은 catalog가 조직의 도메인 아래에 있다는 것이다. 도메인 소유권이 identity와 trust의 출발점이 된다.

Registry는 agentic web의 검색 엔진 역할을 한다. catalog를 크롤링하고 색인하며, 에이전트가 “프로덕션 로그를 검색할 수 있는 도구” 같은 의도를 보내면 관련 capability와 검증 metadata를 반환한다. 이후 에이전트는 registry를 통해서만 실행하는 것이 아니라, 필요한 trust 정보를 확인한 뒤 해당 도구의 native protocol로 직접 연결할 수 있다.

이 구조는 중앙 통제와 분산 운영의 절충안이다. 각 조직은 자기 capability를 자기 도메인에서 관리하고, registry는 발견성을 높인다. 다만 발견 가능하다는 것과 실행 허용은 다르다. 실제 사용에는 별도 인증, 권한, 정책 검증이 필요하다.

MCP 서버를 공개할 때 필요한 보안 기준

MCP 서버를 ARD catalog에 넣는다면 가장 먼저 범위를 좁혀야 한다. “사내 모든 도구”를 하나의 서버에 붙이는 방식은 위험하다. 읽기 전용 문서 검색, 로그 조회, 이슈 생성, 배포 실행처럼 권한 수준이 다른 capability는 분리하는 편이 안전하다.

각 capability에는 최소한 다음 정보가 필요하다. 제공자 도메인, 소유 팀, 설명, 입력 스키마, 출력 스키마, 인증 방식, 권한 범위, rate limit, 데이터 민감도, 감사 로그 위치, 연락 채널이다. 사람이 읽는 설명만으로는 부족하다. 에이전트가 기계적으로 판단할 수 있는 metadata가 있어야 한다.

또한 prompt injection 방어가 필수다. MCP나 OpenAPI 도구가 외부 문서를 읽어오는 경우, 도구 결과는 신뢰할 수 없는 데이터다. 에이전트는 그 내용을 시스템 지시로 취급하면 안 된다. catalog metadata에도 “output_trust_level”, “requires_human_approval”, “side_effects” 같은 필드를 두는 것이 좋다.

검증 흐름: 찾기 전에 정책, 연결 전에 신원 확인

안전한 discovery 흐름은 네 단계로 나눌 수 있다. 첫째, intent를 기반으로 후보 capability를 찾는다. 둘째, 조직 정책으로 후보를 필터링한다. 예를 들어 외부 SaaS 도구는 개인정보 작업에 사용할 수 없게 한다. 셋째, publisher identity와 endpoint를 검증한다. 도메인 소유권, 서명, 인증서, trust metadata를 확인한다. 넷째, 실제 연결 시 사용자·에이전트·작업 단위 권한을 적용한다.

여기서 중요한 점은 registry 결과를 곧바로 신뢰하지 않는 것이다. 검색 결과는 후보일 뿐이다. registry가 공격당하거나 잘못 색인할 수 있고, 비슷한 이름의 악성 capability가 등장할 수도 있다. 따라서 클라이언트 에이전트 또는 게이트웨이는 연결 직전에 독립적인 검증을 해야 한다.

사내 플랫폼에서는 allowlist와 risk tier를 함께 쓰는 것이 현실적이다. low-risk 읽기 도구는 자동 discovery를 허용하되, 쓰기 작업이나 외부 전송이 있는 도구는 승인된 catalog에서만 고르게 한다. 고위험 도구는 인간 승인 없이는 실행하지 않는다.

사내 에이전트 플랫폼에 적용하는 방법

ARD가 아직 생태계 표준으로 자리 잡기 전이라도 사내에서 비슷한 원칙을 적용할 수 있다. 먼저 내부 capability catalog를 만든다. 모든 MCP 서버와 OpenAPI 도구를 한 곳에 등록하고, 도구 설명뿐 아니라 소유자, 권한, 데이터 등급, 부작용 여부를 구조화한다.

다음으로 에이전트 런타임 앞에 tool gateway를 둔다. 에이전트가 직접 모든 도구에 연결하지 않고, gateway가 discovery, 인증, 권한, rate limit, 감사 로그를 처리한다. 이렇게 하면 모델이 바뀌거나 에이전트 프레임워크가 바뀌어도 정책은 한곳에 남는다.

마지막으로 운영 지표를 본다. 어떤 capability가 자주 검색되는지, 실패율이 높은 도구는 무엇인지, 승인 거절이 많은 작업은 무엇인지, prompt injection으로 차단된 출력은 얼마나 되는지 추적한다. 도구 발견은 개발 편의 기능이 아니라 보안·운영 기능으로 봐야 한다.

실행 체크리스트

• 사내 MCP·OpenAPI 도구 목록을 catalog 형태로 정리한다.
• 각 capability에 소유 팀, 권한 범위, 데이터 민감도, 부작용 여부를 적는다.
• registry 검색 결과를 곧바로 실행하지 말고 연결 전 검증을 넣는다.
• 읽기 도구와 쓰기 도구를 분리하고, 고위험 도구는 human approval을 요구한다.
• 도구 출력은 untrusted data로 취급하고 시스템 지시와 분리한다.
• tool gateway를 둬 인증, rate limit, 감사 로그를 중앙화한다.
• 검색·실행·차단·승인 로그를 남겨 정책을 계속 조정한다.

참고한 공개 자료

• Google Developers Blog, “Announcing the Agentic Resource Discovery specification” https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/