Google·Microsoft ARD 해설: AI 에이전트는 MCP를 더 붙이기보다 발견·검증·레지스트리 경계를 먼저 설계해야 하는 이유

발행일: 2026-06-20 | 카테고리: AI 뉴스

\n \n \n

1) 한 줄 문제 정의

핵심 요약: AI 에이전트가 많아질수록 문제는 “도구를 호출할 수 있느냐”보다 “어떤 도구를 믿고 찾아 쓸 수 있느냐”로 옮겨갑니다.

AI타임스는 2026년 6월 20일 Google, Microsoft, Salesforce, Snowflake, ServiceNow 등이 AI 에이전트 연결 표준인 Agentic Resource Discovery, 줄여서 ARD를 추진한다고 보도했습니다. 원문 발표 기준으로 ARD는 에이전트, MCP 서버, A2A 에이전트, API, 스킬 같은 외부 능력을 카탈로그에 등록하고 검색하게 만드는 공개 초안 규격입니다.

이 글의 대상 독자는 사내 AI 에이전트, MCP 서버, 업무 자동화 도구, Copilot형 제품을 만들거나 운영하는 개발자와 팀 리드입니다. 범위는 ARD 발표 요약이 아닙니다. ARD가 왜 나왔는지, MCP·A2A·OpenAPI와 무엇이 다른지, 기업이 작은 레지스트리부터 설계할 때 무엇을 먼저 고정해야 하는지까지 다룹니다.

반대로 ARD를 당장 모든 에이전트 통합의 완성형 표준처럼 보지는 않겠습니다. 공식 스펙은 2026년 5월 28일 기준 v0.9 Draft / Proposal 상태입니다. 지금 단계에서 필요한 태도는 전면 도입보다, “발견 계층”을 따로 설계해야 한다는 신호를 읽는 것입니다.

2) 먼저 결론

핵심 요약: ARD는 MCP의 대체재가 아니라, MCP 서버와 에이전트를 찾기 전에 거치는 검색·검증 계층입니다.

• 지금 검토할 팀: MCP 서버, 사내 API, 워크플로, 에이전트가 늘어나 어떤 기능이 어디 있는지 사람이 기억하기 어려운 팀
• 아직 관찰이 나은 팀: 단일 앱 안에서 도구 3~5개만 고정 호출하는 초기 PoC 팀
• 제 판단: ARD의 핵심은 “AI끼리 자동 연결”이라는 홍보 문구가 아닙니다. 진짜 의미는 에이전트 도구 선택을 프롬프트 컨텍스트에서 빼내 검색·정책·신뢰 계층으로 옮긴다는 점입니다.

쉽게 말하면 MCP가 전기 플러그라면, ARD는 “어느 건물의 어느 콘센트가 승인된 콘센트인지 찾아주는 주소록과 검색엔진”에 가깝습니다. 플러그 규격만 있어서는 충분하지 않습니다. 조직 안에 콘센트가 수백 개가 되면, 어떤 콘센트를 써도 되는지, 누가 관리하는지, 마지막으로 업데이트된 날짜가 언제인지 알아야 합니다.

따라서 저는 ARD를 모델 경쟁 뉴스가 아니라 에이전트 운영 인프라 뉴스로 봅니다. 2026년의 AI 에이전트 팀은 “도구를 많이 붙이는 능력”보다 “필요한 순간에 승인된 도구만 찾는 능력”을 먼저 갖춰야 합니다.

3) 핵심 구조 분해

핵심 요약: ARD는 카탈로그, 레지스트리, 검색 API, 신뢰 메타데이터, 네이티브 실행 프로토콜의 다섯 조각으로 나뉩니다.

3-1. ai-catalog.json: 조직이 공개하는 능력 목록

ARD에서 출발점은 /.well-known/ai-catalog.json 같은 잘 알려진 경로에 놓인 카탈로그입니다. 이 파일에는 조직이 제공하는 에이전트, MCP 서버, API, 스킬, 다른 카탈로그가 들어갑니다. 각 항목은 identifier, displayName, type, url 또는 data, 설명, 태그, 대표 질의, 신뢰 메타데이터를 가질 수 있습니다.

3-2. Registry: AI용 검색엔진

레지스트리는 여러 카탈로그를 크롤링하거나 내부 인벤토리를 받아 색인합니다. 사용자가 “매출 이상치를 분석해줘”라고 요청하면, 에이전트는 모든 도구 설명을 프롬프트에 넣는 대신 레지스트리에 검색을 보냅니다. 레지스트리는 관련된 재무 분석 에이전트, 데이터베이스 MCP 서버, 승인된 리포트 API를 순위화해 돌려줍니다.

3-3. Search API: 발견은 REST 기준으로 맞춤

스펙은 레지스트리가 표준 HTTP REST 검색 인터페이스를 제공해야 한다고 봅니다. 실행은 MCP, A2A, REST, 워크플로 엔진 등 각자의 방식으로 해도 됩니다. 하지만 발견 단계만큼은 어떤 클라이언트도 접근 가능한 공통 기준이 필요하다는 설계입니다.

3-4. Trust metadata: “찾았다”와 “믿는다”는 다릅니다

ARD는 도메인 기반 식별자, DID, SPIFFE 같은 신뢰 정보를 담을 수 있게 합니다. 중요한 이유는 간단합니다. 에이전트가 검색 결과에서 도구를 찾았다고 해서 바로 연결하면 위험합니다. 누가 게시했는지, 어떤 도메인에 묶였는지, 어떤 인증·감사 정보를 갖는지 확인해야 합니다.

3-5. Native protocol: 발견 후에는 원래 방식으로 실행

ARD는 실행 런타임이 아닙니다. 공식 문서도 ARD가 MCP, A2A, Skills, API runtime을 대체하지 않는다고 명시합니다. ARD는 호출 전에 “무엇을 쓸지”를 찾는 계층이고, 실제 호출은 해당 리소스의 네이티브 프로토콜로 이뤄집니다.

4) 설계 의도 해설

핵심 요약: ARD의 설계 의도는 컨텍스트 창에 도구 설명을 무한히 넣는 방식을 끝내려는 것입니다.

지금 많은 에이전트 앱은 도구 선택을 프롬프트 컨텍스트에 의존합니다. 사용할 수 있는 도구 목록과 설명을 모델에게 통째로 넣고, 모델이 그중 하나를 고르게 합니다. 도구가 5개일 때는 괜찮습니다. 하지만 사내 API, MCP 서버, 자동화 워크플로, 외부 SaaS 에이전트가 수백 개로 늘어나면 이 방식은 곧 한계에 닿습니다.

ARD 스펙은 이 문제를 명확히 짚습니다. 도구 설명을 모두 컨텍스트 창에 넣는 방식은 스케일하지 않으며, 발견 문제를 LLM 바깥의 전용 검색 서비스로 옮겨야 한다는 것입니다. 검색 서비스는 대표 질의, 게시자 신원, 컴플라이언스 메타데이터, 사용 패턴 같은 신호를 활용할 수 있고, 이 정보는 모델 컨텍스트 토큰을 계속 소모하지 않습니다.

여기서 얻는 것은 세 가지입니다. 첫째, 도구 목록이 커져도 모델 컨텍스트를 덜 오염시킵니다. 둘째, 조직은 어떤 도구를 검색 결과에 노출할지 정책으로 관리할 수 있습니다. 셋째, 에이전트는 설치된 도구만 쓰는 앱스토어식 구조에서 벗어나 필요한 순간에 승인된 기능을 찾을 수 있습니다.

대신 포기하는 것도 있습니다. 발견 레지스트리가 결과를 통제하기 때문에, 누가 레지스트리를 운영하는지와 어떤 랭킹 정책을 쓰는지가 새로운 권력 지점이 됩니다. ARD가 열린 생태계를 지향하더라도, 기업 내부에서는 “우리 레지스트리가 어떤 공용·사설 리소스를 색인할 것인가”가 보안과 생산성을 동시에 좌우합니다.

5) 근거 및 비교

핵심 요약: ARD의 경쟁 상대는 MCP가 아니라, 수동 설치·사내 위키·각 플랫폼별 폐쇄형 도구 목록입니다.

Google Developers Blog는 ARD가 조직 도메인 아래 카탈로그를 게시하고, 연합 레지스트리가 이를 색인하며, 검색 결과에는 검증 가능한 신뢰 메타데이터가 포함된다고 설명합니다. Microsoft는 같은 맥락에서 GitHub의 agent finder가 ARD 위에서 MCP 서버, 스킬, 도구, 에이전트를 런타임에 찾고 필요한 때만 컨텍스트에 넣는다고 설명했습니다.

Snowflake는 기업 관점의 장점을 더 구체적으로 말합니다. 데이터 팀이 만든 Cortex Agent가 등록되면, 직원은 Snowflake CoWork, Microsoft Copilot, 자체 앱 같은 여러 인터페이스에서 이름을 몰라도 해당 에이전트를 찾을 수 있습니다. 다만 Snowflake 설명에서도 중요한 선은 같습니다. discovery service는 실행 경로에 끼지 않고, 인증과 데이터 접근은 클라이언트와 에이전트 사이에서 처리됩니다.

6) 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 작은 팀은 전사 표준보다 “승인된 사내 MCP 서버 5개를 찾는 내부 카탈로그”부터 시작하면 됩니다.

Step 1. 리소스 인벤토리를 세 종류로 나눕니다

먼저 사내에서 에이전트가 호출할 수 있는 대상을 나눕니다. 읽기 전용 MCP 서버, 쓰기 가능한 업무 API, 다른 에이전트 또는 워크플로 세 가지면 충분합니다. 이때 “있다/없다”가 아니라 소유자, 권한, 위험도, 업데이트 날짜를 함께 적어야 합니다.

Step 2. 최소 ai-catalog.json을 만듭니다

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Acme Internal AI Resources",
    "identifier": "did:web:ai.acme.com"
  },
  "entries": [
    {
      "identifier": "urn:air:acme.com:mcp:sales-readonly",
      "displayName": "Sales Readonly MCP Server",
      "type": "application/mcp-server-card+json",
      "url": "/mcp/sales-readonly.json",
      "description": "Read-only access to approved sales metrics and dashboards.",
      "capabilities": ["sales_metrics", "dashboard_lookup"],
      "representativeQueries": [
        "이번 주 매출 이상치를 찾아줘",
        "고객 세그먼트별 전환율을 확인해줘"
      ],
      "updatedAt": "2026-06-20T00:00:00Z"
    }
  ]
}

Step 3. 검색 전에 정책 필터를 둡니다

모든 리소스를 한 레지스트리에 넣더라도, 모든 사용자에게 같은 결과를 보여주면 안 됩니다. 부서, 역할, 데이터 등급, 쓰기 권한 여부를 기준으로 검색 결과를 필터링해야 합니다. “검색 가능”은 “호출 가능”과 다릅니다.

Step 4. 실행 직전 검증을 분리합니다

검색 결과가 나왔다고 바로 도구를 호출하지 마십시오. 실행 직전에는 도메인, 서명 또는 신뢰 메타데이터, 권한 범위, 위험도를 다시 확인해야 합니다. 특히 쓰기, 삭제, 결제, 배포, 외부 발송 기능은 사람 승인 게이트를 둬야 합니다.

Step 5. 선택 로그를 남깁니다

에이전트가 어떤 질의로 어떤 레지스트리에 검색했고, 어떤 결과를 받았고, 왜 특정 리소스를 선택했는지 로그로 남겨야 합니다. 장애가 났을 때 “모델이 이상하게 골랐다”로 끝나면 운영할 수 없습니다.

7) 실수/함정(Pitfalls)

핵심 요약: ARD 도입 실패는 보통 스펙 구현보다 운영 경계 부재에서 나옵니다.

• 실수 1: ARD를 MCP 대체재로 오해한다
  예방: 팀 문서에서 ARD는 discovery, MCP/A2A/REST는 invocation이라고 분리합니다.
  복구: 카탈로그 항목마다 실제 실행 프로토콜과 책임자를 명시합니다.
• 실수 2: 공개 카탈로그를 그대로 신뢰한다
  예방: 외부 레지스트리 결과는 기본적으로 후보일 뿐이며, 내부 승인 목록과 신뢰 메타데이터를 통과해야 합니다.
  복구: 외부 리소스 호출 로그를 점검하고, 미승인 리소스는 레지스트리 필터에서 차단합니다.
• 실수 3: 설명만 예쁘고 대표 질의가 없다
  예방: 각 항목에 2~5개의 실제 업무 질의를 넣어 검색 품질을 올립니다.
  복구: 에이전트 실패 로그에서 실제 사용자 질문을 뽑아 representativeQueries를 보강합니다.
• 실수 4: 레지스트리 랭킹 정책을 블랙박스로 둔다
  예방: 내부 레지스트리는 승인 상태, 최신성, 위험도, 소유자 신뢰도, 사용 성공률을 랭킹 신호로 문서화합니다.
  복구: 잘못 선택된 도구 사례를 postmortem으로 남기고 랭킹 규칙을 조정합니다.
• 실수 5: 검색 결과와 실행 권한을 한 번에 묶는다
  예방: discovery ACL과 execution ACL을 분리합니다.
  복구: 검색 노출은 유지하되 실행 시 권한 부족을 안전하게 설명하는 응답 경로를 만듭니다.

8) 강점과 한계

핵심 요약: ARD는 에이전트 생태계가 커질 때 꼭 필요한 층이지만, 아직 초안이고 보안·평가·운영은 팀 몫입니다.

강점

• 컨텍스트 절약: 도구 설명을 전부 모델에 넣지 않고, 필요할 때 검색할 수 있습니다.
• 분산 소유권: 조직 도메인 아래 카탈로그를 두기 때문에 중앙 플랫폼 하나에 모든 도구를 밀어 넣지 않아도 됩니다.
• 프로토콜 중립성: MCP, A2A, REST, 스킬, 워크플로를 하나의 discovery envelope 안에 넣을 수 있습니다.
• 기업 거버넌스: 내부 레지스트리가 승인된 리소스, 선택된 벤더 리소스, 공용 리소스를 섞어 보여줄 수 있습니다.

한계

• 초안 상태: v0.9 Proposal이므로 타입 등록, 도구 생태계, 상호운용성 검증은 더 성숙해야 합니다.
• 보안 자동 해결 아님: ARD가 신뢰 메타데이터를 담을 수는 있어도, 실제 인증·권한·감사 체계는 별도로 구현해야 합니다.
• 랭킹 책임: 어떤 리소스가 위에 뜨는지에 따라 에이전트 행동이 바뀌므로, 레지스트리 운영자가 큰 책임을 집니다.
• 품질 평가 필요: 검색 결과가 업무 의도에 맞는지, 선택된 도구가 성공적으로 실행됐는지 지속 평가해야 합니다.

반례: 단일 제품 안에서 고정된 도구만 호출하고, 사용자별 권한 차이도 작고, 도구 수가 적다면 ARD는 과합니다. 반대로 여러 팀이 MCP 서버를 만들고, Copilot·ChatGPT·Gemini·자체 에이전트가 같은 사내 기능을 찾아야 한다면 ARD식 discovery layer를 지금부터 설계해야 합니다.

9) 더 깊게 공부할 포인트

핵심 요약: ARD를 제대로 이해하려면 MCP 사용법보다 discovery, registry, trust, ranking을 함께 봐야 합니다.

• ARD Specification: ai-catalog.json, POST /search, federation, trust manifest 구조를 확인합니다.
• AI Catalog Standard: 카탈로그 항목을 어떤 media type과 필드로 표현하는지 살펴봅니다.
• MCP와 A2A: ARD가 찾은 뒤 실제 실행이 어떤 프로토콜에서 일어나는지 이해해야 합니다.
• GitHub agent finder: 도구를 미리 전부 넣지 않고 런타임에 찾아 컨텍스트에 주입하는 흐름을 봅니다.
• 엔터프라이즈 검색 평가: 검색 결과 적중률, 승인 리소스 비율, 실행 성공률, 잘못된 도구 선택률을 측정해야 합니다.

10) 실행 체크리스트 + 작성자 관점

핵심 요약: 저는 ARD를 “새 표준이 나왔으니 붙이자”가 아니라 “우리 조직의 에이전트 주소록을 코드와 정책으로 관리하자”는 신호로 봅니다.

• 사내 에이전트, MCP 서버, API, 워크플로 목록이 한 곳에 정리되어 있는가?
• 각 리소스에 소유자, 실행 프로토콜, 위험도, 최신 업데이트 날짜가 있는가?
• 검색 가능 여부와 실제 실행 권한이 분리되어 있는가?
• 각 리소스에 실제 업무 질의 2~5개가 대표 질의로 들어가 있는가?
• 외부 리소스는 도메인, 게시자, 신뢰 메타데이터를 확인한 뒤 후보로만 다루는가?
• 쓰기·삭제·배포·결제·외부 발송 도구에는 실행 전 승인 게이트가 있는가?
• 에이전트가 어떤 검색 결과를 왜 선택했는지 로그로 재현할 수 있는가?
• 레지스트리 랭킹 기준에 승인 상태, 최신성, 위험도, 성공률이 반영되는가?

Definition of Done: 대표 업무 질의 20개에서 내부 레지스트리가 승인된 리소스를 80% 이상 상위 3개 안에 반환하고, 에이전트가 선택 이유와 실행 권한 검사를 로그로 남기면 1차 도입은 성공으로 볼 수 있습니다.

제 추천: ARD를 기다리며 아무것도 하지 않는 선택은 좋지 않습니다. 지금 당장 할 일은 전사 표준 선언이 아니라, 팀 안의 MCP 서버와 에이전트 5개를 ai-catalog.json 형태로 정리해 보는 것입니다. 이 작은 실험에서 “검색, 승인, 실행 로그”가 분리되면, 나중에 GitHub Copilot, Microsoft Copilot, 자체 에이전트, 외부 레지스트리가 들어와도 흔들리지 않습니다.

참고자료

• AI타임스 - 구글·MS, AI 에이전트 연결 표준 'ARD' 발표 (2026-06-20)
• Google Developers Blog - Announcing the Agentic Resource Discovery specification (2026-06-17)
• Microsoft Command Line - Introducing the Agentic Resource Discovery specification (2026-06-18)
• Agentic Resource Discovery Specification v0.9 Draft (2026-05-28)
• Snowflake - Exploring Agent Discovery and ARD (2026-06-17)