AI 에이전트는 필요한 다른 에이전트를 어떻게 찾을까? 에이전트 탐색, 에이전트 카드, DNS-AID로 이해하는 서비스 탐색 구조

Agent Discovery·Agent Card·DNS-AID로 이해하는 서비스 탐색 구조

AI Agent, Multi-Agent System, Agent Discovery, A2A Protocol 같은 기술이 빠르게 발전하면서 기업의 AI 자동화 전략도 새로운 단계로 넘어가고 있습니다. 이제 중요한 질문은 “AI 에이전트가 무엇을 할 수 있는가?”에서 끝나지 않습니다.

수많은 AI 에이전트 가운데 지금 필요한 일을 해줄 에이전트를 어떻게 찾아낼까요?

그리고 더 까다로운 질문이 이어집니다.

찾은 에이전트가 무엇을 할 수 있는지, 어디로 연결해야 하는지, 어떤 통신 방식을 지원하는지 AI가 어떻게 알아낼까요?

바로 이 문제를 다루는 개념이 Agent Discovery입니다.

이번 글에서는 AI 에이전트의 서비스 탐색을 Task → Required Capability → Agent Discovery → Agent Card → Endpoint → Trust Verification → Connection이라는 흐름으로 따라가 보겠습니다. 특히 A2A의 Agent Card와 Well-Known URI, Registry/Catalog, 그리고 2026년 주목받고 있는 DNS-AID까지 서로 어떤 역할을 담당하는지 구분해보겠습니다.

이전 글 콘텐츠 구조에서도 Agent Identity, Agent-to-Agent 인증·신뢰, Delegated Access, A2A와 MCP는 이미 각각 독립적으로 다뤄졌습니다. 이번 글은 그보다 앞단인 “통신하거나 신뢰하기 전에 상대 에이전트를 어떻게 발견하는가?”에 초점을 맞춥니다.

어느 날 AI에게 “출장 준비 전부 해줘”라고 말했다면

아래 이야기는 Agent Discovery의 동작을 쉽게 설명하기 위해 실무에서 접할 수 있는 상황을 재구성한 가상의 시뮬레이션입니다. 특정 기업이나 실제 AI 서비스가 아래와 똑같이 작동한다는 의미는 아닙니다.

금요일 오후 5시 40분입니다.

회의실에서는 의자를 미는 소리가 들리고 노트북을 덮는 직원들이 하나둘 자리에서 일어납니다. 그런데 직장인 A씨에게 갑자기 다음 주 해외 출장이 잡혔습니다.

A씨가 회사의 업무용 AI 에이전트에게 말합니다.

“다음 주 화요일 도쿄 출장 준비해줘. 오전 비행기 알아보고 회사 출장 규정에 맞는 호텔도 찾아줘.”

지금의 챗봇이라면 항공권 검색 방법과 호텔 목록을 보여줄 수 있습니다.

하지만 미래의 Multi-Agent 환경에서는 조금 다른 장면을 상상할 수 있습니다.

메인 에이전트가 직접 모든 일을 하는 것이 아니라 항공 검색 Agent, 호텔 Agent, 사내 출장규정 Agent 등 필요한 서비스를 찾아 협업하는 것입니다.

여기서 문제가 하나 생깁니다.

메인 Agent가 처음부터 모든 Agent의 이름과 주소를 알고 있을까요?

인터넷에서 우리가 모든 웹사이트의 IP 주소를 외우지 않는 것처럼, 확장된 Agent 생태계에서도 모든 서비스의 Endpoint를 하나하나 미리 하드코딩하는 방식은 관리가 어려워질 수 있습니다.

그래서 필요한 것이 Discovery, 즉 ‘발견’입니다.

이 글의 핵심도 여기에 있습니다.

Agent Discovery의 핵심은 Agent의 이름을 찾는 것보다 ‘내가 필요한 능력을 가진 Agent가 어디에 있으며 어떻게 연결할 수 있는가’를 알아내는 데 있습니다.

Agent Discovery란 무엇일까? AI 에이전트 서비스 탐색 가이드

Agent Discovery를 아주 쉽게 비유하면 AI 세계의 서비스 안내소라고 생각하면 됩니다.

사람이 호텔에 들어가 프런트 직원에게 “근처에서 환전할 수 있는 곳이 어디예요?”라고 물으면 직원은 목적에 맞는 장소를 알려줍니다.

Agent 환경에서도 비슷한 문제가 생깁니다.

메인 Agent에게 필요한 작업이

Flight Search

라면 반드시 처음부터 특정한 TravelAgent123이라는 이름을 알고 있을 필요는 없습니다.

개념적으로는 다음과 같이 접근할 수 있습니다.

Task

↓

Required Capability

↓

Agent Discovery

↓

Candidate Agents

↓

Capability Matching

↓

적합한 Agent 선택

첨부 자료에서도 앞으로 Discovery가 단순한 Name-Based Discovery에서 필요한 능력을 기준으로 후보를 찾는 Capability-Based Discovery로 확장될 가능성을 중요한 차별화 포인트로 제시하고 있습니다.

이 차이는 생각보다 중요합니다.

“김 대리를 찾아주세요”와

“일본어 계약서를 번역할 수 있는 사람을 찾아주세요”

는 전혀 다른 검색이기 때문입니다.

후자가 바로 Capability 중심 탐색에 가깝습니다.

Agent Card란? AI 에이전트가 건네는 ‘디지털 명함’

상대 Agent를 발견했다고 가정해보겠습니다.

그러면 또 다른 문제가 생깁니다.

“너는 대체 뭘 할 수 있는데?”

여기에 답하기 위한 A2A의 핵심 객체가 Agent Card입니다.

현재 A2A 공식 사양은 Agent Card를 에이전트에 관한 자기 설명형 manifest로 정의하며, identity, capabilities, skills, 지원 통신 방식과 security requirements 같은 메타데이터를 제공합니다. A2A Server는 Agent Card를 제공하고 Client는 이를 통해 적합한 Agent인지 판단하고 상호작용을 구성합니다.

사람의 명함과 비교하면 이해하기 쉽습니다.

사람의 명함에는 이름, 회사, 직책, 연락처가 적혀 있습니다.

Agent Card에는 개념적으로 다음과 같은 정보가 담깁니다.

• Agent의 이름과 설명

• 제공하는 Skills

• 지원 Capabilities

• 서비스 Endpoint

• 지원하는 인터페이스와 프로토콜

• 필요한 인증·보안 조건

즉 Agent Card는 단순한 “AI 소개글”이 아닙니다.

다른 소프트웨어가 읽을 수 있는 machine-readable profile에 가깝습니다.

A2A 공식 Discovery 문서도 Agent Card를 디지털 ‘business card’에 비유하고 있으며, Client Agent가 이를 읽어 원격 Agent가 특정 작업에 적합한지 판단한다고 설명합니다.

좋은 Discovery는 주소를 찾는 데서 끝나지 않습니다. 상대가 무엇을 할 수 있는지 이해하는 순간부터 협업이 시작됩니다.

이 문장은 특정 인물의 명언을 인용한 것이 아니라 이번 글의 내용을 설명하기 위해 필자가 정리한 표현입니다.

Agent Discovery 비교 분석｜Well-Known URI·Registry·Direct Configuration·DNS

Agent Discovery라고 해서 한 가지 방법만 존재하는 것은 아닙니다.

현재 A2A 공식 사양에서는 Agent Card를 찾는 방식으로 Well-Known URI, Registries/Catalogs, Direct Configuration을 제시하고 있습니다.

탐색 방식	쉽게 말하면	특징	적합한 환경
Direct Configuration	주소를 미리 알고 있음	단순하지만 사전 설정 필요	고정된 Agent 관계
Well-Known URI	정해진 위치에서 명함 조회	도메인 기반 자동화에 유리	공개·도메인 중심 환경
Registry/Catalog	Agent 목록에서 검색	Skills·Tags 등으로 탐색 가능	기업·마켓플레이스
DNS 기반 Discovery	DNS를 탐색 기반으로 활용	분산형 발견 가능성	조직 간 Agent 생태계
Capability-Based Discovery	필요한 능력으로 후보 검색	이름보다 작업 목적 중심	대규모 Multi-Agent 환경

※ 모바일 화면에서는 표를 좌우로 밀어서(스크롤) 전체 내용을 확인하실 수 있습니다.

여기서 주의할 부분이 있습니다.

표의 앞 세 방식은 현재 A2A 공식 Discovery 문서에서 직접 설명하는 방식입니다. 반면 DNS-AID는 A2A Discovery 방식과 동일한 하나의 완성된 표준이라고 단정하면 안 됩니다.

둘은 서로 연결될 가능성이 있지만 출발점과 표준화 상태를 구분해서 봐야 합니다.

Well-Known URI는 왜 필요할까? Agent Card 찾는 방법

웹사이트를 운영하다 보면 robots.txt처럼 “정해진 위치에 파일을 놓는 방식”을 접하게 됩니다.

Agent Card에도 비슷한 아이디어가 있습니다.

현재 A2A 1.0 사양에서 Well-Known 방식의 경로는 다음과 같습니다.

https://{server_domain}/.well-known/agent-card.json

Client가 특정 도메인을 알고 있다면 이 표준 위치를 조회하여 Agent Card를 찾을 수 있습니다.

여기에는 버전 변화도 하나 알아둘 만합니다.

A2A 초기 사양에서는 .well-known/agent.json 경로가 사용됐지만 현재 최신 사양에서는 .well-known/agent-card.json이 사용됩니다. 따라서 오래된 기술 문서나 예제를 볼 때 경로가 다르다고 해서 반드시 어느 한쪽이 오류라고 판단하기보다 문서가 어느 A2A 버전을 기준으로 작성됐는지 확인해야 합니다.

이런 작은 버전 차이를 확인하는 습관이 기술 콘텐츠에서는 특히 중요합니다.

기술을 이해하는 것만큼 중요한 일은 ‘어느 시점의 기술을 설명하고 있는가’를 확인하는 것입니다.

역시 특정 인물의 말을 인용한 것이 아니라 이번 글의 관점을 압축한 필자의 표현입니다.

Agent Registry·Catalog는 AI 세계의 ‘서비스 디렉터리’가 될까?

Agent가 수십 개가 아니라 수천 개로 늘어난다면 도메인을 하나씩 알고 찾아가는 것만으로 충분하지 않을 수 있습니다.

그래서 등장하는 방식이 Registry 또는 Catalog 기반 Discovery입니다.

A2A 공식 Discovery 가이드에서는 중앙 Registry가 Agent Card 모음을 관리하고 Client가 Skill, Tag, Provider, Capability 등의 기준으로 검색할 수 있는 방식을 설명합니다. 기업 내부 환경이나 공개 Marketplace 같은 구조에서 활용할 수 있는 접근입니다.

비유하면 앱스토어 검색창과 비슷합니다.

우리는 앱 이름을 몰라도

“사진 편집”

“번역”

“회계”

같은 기능을 검색해 적절한 앱을 찾습니다.

Agent Registry도 궁극적으로는

Agent 이름 → Agent 검색

보다

업무 목적 → Capability 검색 → 후보 Agent 발견

방향으로 발전할 가능성을 생각해볼 수 있습니다.

다만 여기서 ‘가능성’이라는 표현이 중요합니다.

모든 AI Agent 생태계가 하나의 글로벌 Registry로 통합됐다는 의미도 아니고, Capability-Based Discovery가 이미 인터넷 전체에 보편적으로 배포됐다는 의미도 아닙니다.

현재 기술과 제안들을 기반으로 향후 구조를 이해하는 관점입니다.

DNS-AID란? DNS로 AI Agent를 찾으려는 새로운 접근

여기서 이번 글의 반전이 등장합니다.

Agent를 찾기 위해 완전히 새로운 인터넷 주소 체계를 만들어야 할까요?

꼭 그렇지만은 않습니다.

이미 인터넷에는 전 세계적으로 널리 사용되는 거대한 분산형 이름 체계가 있습니다.

바로 **DNS(Domain Name System)**입니다.

2026년 5월 Linux Foundation은 DNS-AID(DNS AI agent Discovery) 프로젝트 출범을 발표했습니다. 이 프로젝트는 기존 DNS 인프라를 활용해 AI Agent와 MCP Server를 게시·발견·검증할 수 있는 개방형·분산형 접근을 개발하는 것을 목표로 합니다.

쉽게 비유하면 이렇습니다.

인터넷에서

example.com

이라는 사람이 읽기 쉬운 이름을 실제 네트워크의 위치와 연결하는 데 DNS가 중요한 역할을 해왔듯,

Agent 시대에는

“이 조직에는 어떤 Agent가 있는가?”

“어떤 방식으로 해당 Agent의 정보를 얻을 수 있는가?”

를 DNS 인프라와 연결해보자는 접근입니다.

이 아이디어가 흥미로운 이유는 중앙의 거대한 Agent Directory 하나에 모든 것을 의존하지 않고 각 조직이 자신의 DNS namespace에서 Agent 정보를 게시하는 분산형 구조를 생각할 수 있기 때문입니다.

DNS-AID를 ‘완성된 인터넷 표준’이라고 쓰면 안 되는 이유

이 부분은 E-E-A-T 관점에서도 특히 중요합니다.

2026년 10월 현재 DNS-AID를 “이미 인터넷의 공식 표준이 됐다”고 표현하는 것은 적절하지 않습니다.

IETF Datatracker에서 확인되는 DNS for AI Discovery 문서는 Internet-Draft 형태로 논의되고 있습니다. 2026년 5월 공개된 -02 문서는 DNS-AID가 조직의 Agent를 DNS에 게시해 다른 Agent가 발견할 수 있도록 하는 접근을 설명하며 SVCB, DNS-SD, 선택적으로 DNSSEC와 DANE TLSA 등을 활용하는 구조를 제안합니다.

따라서 현재 상태는 이렇게 표현하는 것이 더 정확합니다.

“DNS-AID는 DNS를 활용한 AI Agent Discovery를 위해 개발·표준화 논의가 진행되는 접근이다.”

이 한 문장이 중요합니다.

기술 콘텐츠에서 신뢰를 무너뜨리는 가장 빠른 방법 가운데 하나가 proposal을 standard라고 부르고, 실험 단계를 상용화 완료라고 표현하는 것이기 때문입니다.

새로운 기술일수록 ‘무엇이 가능한가’보다 ‘지금 어디까지 와 있는가’를 함께 적어야 독자의 판단력이 생깁니다.

Capability Discovery가 중요한 이유｜Agent 이름보다 ‘할 수 있는 일’을 찾는다.

출장 시뮬레이션으로 돌아가보겠습니다.

메인 Agent에게 필요한 것은 특정 회사의 특정 Agent가 아닐 수도 있습니다.

필요한 것은

“항공편을 검색할 능력”

입니다.

그러면 구조가 달라집니다.

Task

출장 항공편 찾기

↓

Required Capability

Flight Search

↓

Discovery

해당 Capability를 제공하는 Agent 후보 탐색

↓

Agent Card

각 후보의 Skill·Endpoint·보안 요구사항 확인

↓

Candidate Agents

A / B / C

이 단계에서 중요한 변화가 일어납니다.

사람이 Agent 이름을 미리 지정하는 방식에서 기계가 필요한 능력을 기술하고 그 능력을 가진 서비스를 찾는 방식으로 이동할 수 있기 때문입니다.

하지만 여기서 끝내면 안 됩니다.

Agent A, B, C를 발견했다고 해서 셋 중 누가 가장 적합한지는 아직 모릅니다.

첨부 자료에서도 Discovery ≠ Selection을 분명히 구분하고 있으며, 후보 발견 이후에는 Capability Match뿐 아니라 Trust, Cost, Latency, Availability, Policy 같은 요소를 고려한 Agent Selection 문제가 별도로 남는다고 정리합니다.

이것이 이번 주제에서 놓치기 쉬운 핵심입니다.

찾는 것과 고르는 것은 다른 문제입니다.

Discovery ≠ Trust｜찾았다고 바로 믿어서는 안 됩니다.

여기서 한 번 더 경계선을 그어야 합니다.

Agent를 발견했다.

Agent Card도 읽었다.

그 Agent가 “나는 결제를 처리할 수 있습니다”라고 자신을 소개했다.

그렇다면 바로 결제를 맡겨도 될까요?

아닙니다.

Discovery는 Trust가 아닙니다.

첨부 기획에서도 이 구분을 명확하게 두고 있습니다. Discovery는 Agent가 존재한다는 사실과 Metadata를 얻는 과정이고, 그 이후 Identity Verification, Authorization, Delegation 등의 단계가 이어져야 합니다.

쉽게 풀면 다음과 같습니다.

Discovery
“누가 있지?”

Agent Card
“무슨 일을 할 수 있다고 하지?”

Identity Verification
“정말 그 Agent가 맞나?”

Authentication
“신원을 증명할 수 있나?”

Authorization
“어디까지 허용할까?”

Delegation
“내 권한 중 무엇을 넘길까?”

이 구분이 없으면 Agent Discovery를 지나치게 단순하게 이해하게 됩니다.

새로운 AI Agent 생태계의 핵심은 Agent끼리 무조건 많이 연결되는 것이 아니라 발견과 신뢰를 분리한 상태에서 필요한 연결만 안전하게 허용하는 것에 더 가깝습니다.

Agent Discovery와 Agent Identity는 무엇이 다를까?

이 둘도 자주 혼동될 수 있습니다.

Agent Identity의 질문은

“Who are you?”

입니다.

Agent Discovery는

“Where are you, and what can you do?”

에 가깝습니다.

그리고 Authentication은

“Can you prove who you are?”

입니다.

따라서 세 개념은 경쟁 관계가 아니라 연결 관계입니다.

Discovery → Identity 확인 → Authentication → Authorization → Connection

이라는 흐름으로 보면 훨씬 쉽게 이해됩니다.

기존 WSF 포스팅에서도 Agent Identity는 공유 API Key와 서비스 계정을 넘어 Agent 자체의 신원을 어떻게 설계할지를 다뤘고, 다음 글에서는 Agent-to-Agent 인증·위임 체인·신뢰 검증을 별도로 다뤘습니다.

이번 포스팅이 두 글 사이의 빈 공간을 메워주는 이유입니다.

A2A와 MCP까지 연결하면 전체 그림이 보입니다.

A2A와 MCP를 같은 것으로 이해하면 구조가 다시 꼬입니다.

기존 WSF 콘텐츠에서는 A2A를 AI Agent 간 협업, MCP를 Tool·데이터 연결 구조라는 관점에서 비교했습니다. 해당 포스팅도 첨부된 기존 목록에서 확인됩니다.

이번 글에서는 A2A 자체를 반복 설명할 필요가 없습니다.

대신 순서를 이렇게 보면 됩니다.

Agent A

↓

필요한 Capability 판단

↓

Agent Discovery

↓

Agent Card 확인

↓

Endpoint·Skills 확인

↓

Identity / Trust Verification

↓

A2A Communication

즉 A2A가

“Agent끼리 어떻게 협업하고 통신하는가?”

를 다룬다면 Discovery는 그보다 앞선

“통신할 상대를 어떻게 찾아내는가?”

를 다룹니다.

이렇게 각각의 기술을 ‘단어’가 아니라 과정의 위치로 기억하면 훨씬 오래 남습니다.

기업이 Agent Discovery를 설계할 때 확인할 체크리스트

기업용 AI Agent Platform이나 Multi-Agent System을 검토한다면 화려한 데모보다 다음 질문을 던져보는 편이 실용적입니다.

① Agent는 어떻게 발견되는가?
Hardcoded URL인지, Registry인지, Well-Known URI인지 확인합니다.

② Agent Card나 이에 준하는 Metadata가 있는가?
Agent의 Capability와 Endpoint를 기계가 읽을 수 있는 형태로 표현할 수 있는지 살펴봅니다.

③ Capability와 Skill을 구분해 검색할 수 있는가?
Agent 이름을 미리 알아야만 동작하는 구조라면 규모가 커질수록 관리가 복잡해질 수 있습니다.

④ Discovery 이후 Identity Verification이 존재하는가?
‘찾았다’와 ‘신뢰한다’를 분리해야 합니다.

⑤ Agent Card에 민감정보가 노출되지 않는가?
A2A 공식 문서도 Agent Card가 내부 Agent URL이나 민감한 Skill 정보를 포함할 수 있으므로 필요하면 인증된 Extended Agent Card나 접근제어를 고려하도록 안내합니다.

⑥ Registry의 갱신과 폐기 정책이 있는가?
이미 폐기된 Agent가 계속 검색되는 상황도 운영 리스크가 될 수 있습니다.

⑦ Cost·Latency·Trust를 Discovery와 혼합하지 않았는가?
Discovery와 Selection은 분리해서 설계하는 편이 개념적으로 명확합니다.

이 체크리스트는 특정 제품의 도입을 권유하는 것이 아니라 Agent Discovery 아키텍처를 검토할 때 생각해볼 수 있는 일반적인 설계 관점입니다.

AI Agent Discovery의 진짜 가치는 ‘검색’이 아니라 상호운용성에 있습니다.

처음에는 Agent Discovery가 단순한 검색 기술처럼 보입니다.

그런데 끝까지 따라오면 관점이 달라집니다.

Agent가 다른 Agent를 자동으로 찾을 수 있다는 것은 결국 서로 다른 기업, 플랫폼, 프레임워크에서 만들어진 서비스가 상대방의 존재와 Capability를 기계적으로 이해할 수 있는가라는 문제로 이어집니다.

즉 Discovery의 장기적인 가치는

Search

보다

Interoperability

에 더 가깝습니다.

서로 다른 Agent가 상대의 이름을 사람이 일일이 등록해야만 협업할 수 있다면 Agent 생태계가 커질수록 연결 비용도 커집니다.

반대로 Discovery, Agent Card, Registry, 표준화된 Endpoint 표현 등이 발전한다면 Agent 간 연결을 자동화할 여지가 커집니다.

그래서 Agent Discovery는 눈에 잘 띄는 생성형 AI 기능은 아니지만 Enterprise AI Infrastructure에서는 상당히 중요한 기반 계층이 될 수 있습니다.

FAQ｜Agent Discovery를 검색할 때 가장 헷갈리는 질문

Q. Agent Discovery와 AI 검색엔진은 같은 것인가요?

다릅니다. 이번 글의 Agent Discovery는 일반 사용자가 웹 정보를 검색하는 AI Search가 아니라 AI Agent가 협업할 다른 Agent의 존재·Capability·Endpoint 등을 발견하는 서비스 탐색 문제를 의미합니다.

Q. Agent Card는 AI 모델의 Model Card와 같은 것인가요?

목적이 다릅니다. A2A의 Agent Card는 원격 Agent의 Identity, Skills, Capability, Endpoint, 통신·보안 요구사항 등을 다른 Agent가 이해하도록 제공하는 자기 설명형 정보입니다.

Q. Agent Card 주소는 어디인가요?

현재 A2A 1.0 공식 사양의 Well-Known 방식에서는 /.well-known/agent-card.json을 사용합니다. 과거 A2A 버전 문서에는 /.well-known/agent.json이 사용된 적이 있으므로 참고 자료의 버전을 확인하는 것이 좋습니다.

Q. DNS-AID는 이미 국제표준인가요?

현재 그렇게 단정해서는 안 됩니다. Linux Foundation의 오픈소스 프로젝트가 출범했고 IETF에서는 DNS 기반 AI Discovery가 Internet-Draft로 논의되어 왔습니다. 따라서 ‘개발·표준화가 진행되는 기술’ 정도로 표현하는 편이 정확합니다.

Q. Agent를 발견하면 바로 연결해도 되나요?

Discovery와 Trust는 별개입니다. 상대를 발견한 뒤에도 Identity, Authentication, Authorization 및 필요한 경우 Delegation과 같은 보안 단계가 필요합니다.

Q. Agent Registry와 DNS-AID의 가장 큰 차이는 무엇인가요?

개념적으로 Registry는 Agent 정보를 모아 검색하는 중앙 또는 관리형 Catalog에 가깝고, DNS-AID는 기존 DNS 인프라를 이용한 보다 분산된 Discovery 접근을 지향합니다. 실제 시스템에서는 어느 하나만 사용해야 한다고 단정하기보다 환경과 보안 요구에 따라 설계를 검토해야 합니다.

★ 필자의 주관적인 마무리 의견

AI Agent 시대를 바라볼 때 저는 ‘얼마나 똑똑한 Agent가 등장할 것인가’보다 그 Agent들이 서로를 어떤 규칙으로 찾고, 이해하고, 신뢰하게 될 것인가가 더 흥미로운 질문이라고 생각합니다.

사람의 사회도 마찬가지입니다. 능력 있는 사람이 많다고 조직이 저절로 움직이지는 않습니다. 누가 어떤 일을 할 수 있는지 알고, 연락할 방법이 있고, 상대를 신뢰할 근거가 있어야 비로소 협업이 시작됩니다. AI Agent 생태계도 점점 이와 닮은 기반 구조를 필요로 하고 있습니다.

특히 Discovery와 Trust를 같은 것으로 취급해서는 안 된다고 봅니다. ‘찾을 수 있다’는 것은 ‘믿을 수 있다’는 뜻이 아니며, ‘할 수 있다’는 것은 ‘하도록 허용받았다’는 의미도 아닙니다. 이 세 문장을 기억하면 앞으로 등장할 Agent 기술을 훨씬 선명하게 구분할 수 있습니다.

DNS-AID 역시 흥미로운 방향이지만 새로운 기술이라는 이유만으로 미래의 표준이라고 미리 확정하기보다는 현재의 프로젝트 상태와 IETF 논의 과정을 계속 확인하는 태도가 필요합니다. 기술이 빠르게 움직일수록 독자에게 필요한 것은 더 큰 확신이 아니라 확인 가능한 근거와 상태를 구분하는 습관이라고 생각합니다.

결국 Agent Discovery의 미래는 ‘AI 검색 기능 하나’의 문제가 아닙니다. Agent Card, Registry, DNS, Identity, Authentication, Authorization, A2A가 차곡차곡 연결되면서 서로 다른 AI 서비스가 안전하게 협업할 수 있는 Agent Infrastructure를 어떻게 만들 것인가라는 문제입니다. 기업의 AI 투자 역시 개별 모델의 성능만 비교하기보다 이런 기반 구조와 운영비용, 보안, 상호운용성을 함께 살펴보는 장기적인 기술 포트폴리오 관점이 점점 중요해질 것입니다.

함께 보면 좋은 추천 포스팅

이번 글의 Discovery → Identity → Trust → Communication 흐름을 이어서 읽고 싶다면 아래 세 글을 함께 보는 것이 좋습니다. 첨부된 WSF 게시물 목록에서 실제 제목과 URL을 확인해 선별했습니다.

AI 에이전트도 고유한 신원이 필요할까?｜공유 API Key·서비스 계정을 넘어 Agent Identity를 설계하는 방법

Agent Discovery가 “어디에 있고 무엇을 할 수 있는가?”를 찾는 과정이라면 이 글은 그다음 질문인 **“그 Agent는 누구인가?”**를 다룹니다. Discovery와 Identity를 함께 이해하면 Agent Infrastructure의 기본 구조가 훨씬 선명해집니다.

AI 에이전트도 고유한 신원이 필요할까?

AI 에이전트는 다른 에이전트를 어떻게 신뢰할까?｜Agent-to-Agent 인증·위임 체인·신뢰 검증 구조 이해하기

Agent를 찾았다고 바로 믿을 수는 없습니다. Discovery 이후 Authentication과 Trust, Delegation이 왜 필요한지 연결해서 읽기 좋은 후속 콘텐츠입니다.

AI 에이전트는 다른 에이전트를 어떻게 신뢰할까?

A2A와 MCP는 무엇이 다를까?｜AI 에이전트 간 협업과 Tool·데이터 연결 구조 비교

Agent를 발견하고 신뢰할 수 있게 되었다면 다음 질문은 **“실제로 무엇과 어떻게 연결되는가?”**입니다. Agent 간 협업을 다루는 A2A와 Tool·데이터 연결을 다루는 MCP의 역할 차이를 비교해보세요.

A2A와 MCP는 무엇이 다를까?

공식 자료 및 추가 참고

A2A Protocol — Agent Discovery / Agent Card 공식 문서
Agent Discovery / Agent Card 공식 문서

A2A Protocol Specification
A2A Protocol Specification

Linux Foundation — DNS-AID Project 발표 자료
Linux Foundation

IETF Datatracker — DNS for AI Discovery Internet-Draft
IETF Datatracker

Google Search Central — 유용하고 신뢰할 수 있는 사용자 중심 콘텐츠 제작하기
Google Search Central