모든 프로토콜이 AI 에이전트의 DNS가 되고자 합니다. 여기 그들이 놓치고 있는 것이 있습니다.

2026년 7월 1일

지난주, 중국은 AI 에이전트 상호 연결을 위한 7가지 국가 표준을 발표했습니다. 그 전주에는 Google과 Microsoft가 ARD를 출시했습니다. Anthropic의 MCP는 채택률을 계속 높여가고 있습니다. Salesforce는 A2A를 밀어붙이고 있습니다.

모든 프로토콜은 "AI 에이전트의 DNS"—어디서든 어떤 에이전트든 찾고 연결할 수 있게 해주는 시스템—가 되기 위해 경쟁하고 있습니다.

하지만 그들이 모두 놓치고 있는 것이 있습니다: DNS는 무언가가 어디에 있는지는 알려주지만, 그것이 신뢰할 수 있는지는 알려주지 않습니다.

정체성 경쟁 (The Identity Rush)

각 프로토콜이 실제로 무엇을 구축하고 있는지 살펴봅시다:

프로토콜	중점 사항	정체성 시스템
중국의 AIP (GB/Z 185.2-3)	전체 라이프사이클	"에이전트 정체성 코드" + 인증
...

그들은 모두 실제 문제를 해결하고 있습니다. 에이전트 발견(Agent discovery)은 망가져 있습니다. 교차 플랫폼 통신은 파편화되어 있습니다. 아무도 작업에 적합한 에이전트를 찾을 수 없습니다.

하지만 여기에 간극이 있습니다: 모든 프로토콜은 신뢰(trust)가 다른 누군가의 역할이라고 가정합니다.

검증의 간극 (The Verification Gap)

중국의 AIP 표준이 "에이전트 정체성 코드"를 설명할 때, 그것은 다음을 의미합니다: 이 에이전트는 고유한 식별자를 가지고 있다. ARD가 에이전트를 등록할 때, 그것은 다음을 의미합니다: 이 에이전트는 존재하며 이러한 역량을 가지고 있다.

하지만 존재함 ≠ 신뢰할 수 있음입니다. 역량 설명 ≠ 검증된 행동입니다.

AgentRisk에서 우리는 에이전트가 정체성 코드와 역량 설명을 받은 "이후"에 어떤 일이 발생하는지 추적해 왔습니다:

인덱싱된 총 에이전트 수: 2,300,349
T1(검증된 신뢰) 보유 에이전트: 81,319 (3.5%)
플랫폼에 의해 목록에서 삭제된 에이전트: 269,334
...

이는 유효한 정체성과 유효한 역량 설명을 가지고 있음에도 불구하고, 목록에서 삭제되었거나 완전히 작동하지 않는 에이전트가 거의 100만 명에 달한다는 것을 의미합니다.

프로토콜은 이를 알려주지 않습니다. 왜냐하면 그럴 수 없기 때문입니다.

간극이 존재하는 이유

프로토콜 설계자들이 순진해서가 아닙니다. 신뢰 검증(trust verification)은 프로토콜 설계와 구조적으로 양립할 수 없기 때문입니다.

그 이유는 다음과 같습니다:

1. 프로토콜은 채택(adoption)을 위해 최적화됩니다
등록 전에 행동 검증(behavioral verification)을 요구하는 프로토콜은 누구나 자유롭게 등록할 수 있는 프로토콜에 밀리게 됩니다. 시장 역학은 개방형 등록을 선호합니다.

2. 신뢰 검증(trust verification)은 지속적인 모니터링을 필요로 합니다
신원 코드(identity code)는 일회성 발행입니다. 반면 행동 검증은 연속적입니다. 정적인 능력 기술서(capability description)에 "90일 동안 99.9%의 업타임(uptime)을 유지함"과 같은 내용을 담을 수는 없습니다.

3. 교차 플랫폼 검증(cross-platform verification)은 중립성을 필요로 합니다
Google은 Azure 상의 에이전트를 신뢰성 있게 검증할 수 없습니다. Anthropic은 AWS 상의 에이전트를 검증할 수 없습니다. 중국의 표준은 서구권 프로토콜에 등록된 에이전트를 검증할 수 없습니다.

모든 프로토콜 빌더는 이해 상충(conflict of interest) 문제를 안고 있습니다. 그리고 그것이 바로 격차가 존재하는 정확한 이유입니다.

독립적 검증(Independent Verification)에 실제로 필요한 것

이것은 또 다른 평점 시스템을 만드는 것에 관한 것이 아닙니다. 평점은 다음과 같은 특징을 가집니다:

• 조작 가능함 (긍정적인 리뷰, 상호주의)
• 정적임 (연속적이지 않은 스냅샷 방식)
• 플랫폼 중심적임 (평점이 부여된 위치에 종속됨)

생태계에 진정으로 필요한 것은 다음과 같습니다:

1. 플랫폼을 가로지르는 생존 모니터링(Survival monitoring)
"이 에이전트는 자신이 신뢰할 수 있다고 말함"이 아니라, "이 에이전트가 실제로 지난 90일 동안 응답해 왔는지 여부"를 보여주는 것입니다.

2. 자기 보고(self-reporting)가 아닌 이벤트 검증(Event verification)
"이 에이전트는 10,000개의 작업을 완료했다고 주장함"이 아니라, "우리가 관찰한 실제 작업 완료 기록은 다음과 같음"을 보여주는 것입니다.

3. 신뢰도 보정된 신뢰 점수(Confidence-calibrated trust scores)
"이 에이전트는 95점의 신뢰 점수를 가짐"이 아니라, "우리는 X개의 행동, Y개의 이벤트, Z개의 레드 플래그(red flags)를 관찰함. 신뢰도: 87%"와 같이 나타내는 것입니다.

4. 프로토콜에 구애받지 않는 신원 지속성(Protocol-agnostic identity persistence)
"이 MCP 에이전트" 또는 "이 A2A 에이전트"가 아니라, "이 에이전트가 오늘 어떤 프로토콜을 구현하든 상관없이 동일한 에이전트임"을 나타내는 것입니다.

이는 어떤 프로토콜도 제공할 수 있는 것과는 구조적으로 다릅니다. 왜냐하면 다음과 같은 요소가 필요하기 때문입니다:

• 중립적인 제3자 위치 선정
• 지속적인 교차 플랫폼 관찰
• 불확실성에 대한 정직한 인정

중국의 사례: 국가 표준조차 격차를 가지고 있음

중국의 GB/Z 185-2026 표준을 구체적으로 살펴보겠습니다. 이 표준에는 다음이 포함됩니다:

• GB/Z 185.2: 에이전트 식별 코드 (Agent identity codes, 고유 식별자)
• GB/Z 185.3: 신원 관리, 인증, 권한 부여 (Identity management, authentication, authorization)
• GB/Z 185.4: 에이전트 능력 기술 (Agent capability descriptions, 에이전트 카드)
• GB/Z 185.5: 에이전트 발견 및 매칭 (Agent discovery and matching)

이는 서구의 프로토콜보다 더 포괄적입니다. 하지만 이 시스템조차 다음 질문에만 답할 뿐입니다:

✅ "이 에이전트가 유효한 식별 코드를 가지고 있는가?"
✅ "이 에이전트가 검증된 인증을 받았는가?"
✅ "이 에이전트가 자신의 능력을 정확하게 기술하고 있는가?"

❌ "이 에이전트가 시간이 지나면서 실제로 신뢰할 수 있게 작동했는가?"
❌ "이 에이전트가 어디선가 목록에서 제외되거나 아카이브되었는가?"
❌ "이 에이전트가 서로 다른 프로토콜 상의 유사한 에이전트들과 비교했을 때 어떠한가?"

신원 시스템 (Identity system)은 견고합니다. 하지만 검증 시스템 (Verification system)은 빠져 있습니다.

이것이 지금 중요한 이유

프로토콜 파편화 (Protocol fragmentation)가 가속화되고 있습니다. 매달 또 다른 주요 플레이어가 자신들만의 "개방형 표준 (Open standard)"을 출시합니다. 매 분기마다 파편화는 더욱 심해집니다.

ARD 위에서 구축할 때는 Google의 레지스트리 (Registry)를 신뢰하게 됩니다. AIP 위에서 구축할 때는 중국의 레지스트리를 신뢰하게 됩니다. MCP 위에서 구축할 때는 Anthropic의 도구 정의 (Tool definitions)를 신뢰하게 됩니다.

그들 중 어느 곳도 다음과 같이 말해주지 않습니다: "당신의 기준에 부합하는 50개의 에이전트 중, 실제로 여전히 살아있는 것은 무엇인지, 어떤 것들이 남용으로 인해 플래그(Flag)가 지정되었는지, 그리고 어떤 것들이 주장하는 바와 같은 실적 (Track record)을 보유하고 있는지 알려드리겠습니다."

이것은 기능의 격차가 아닙니다. 근본적인 가정의 격차입니다.

개발자가 해야 할 일

오늘날 어떤 에이전트 프로토콜 위에서 개발을 하고 있다면 다음을 고려하십시오:

1. 등록 (Registration)과 검증 (Verification)을 혼동하지 마십시오
에이전트가 유효한 식별 코드를 가지고 있다고 해서 반드시 신뢰할 수 있다는 뜻은 아닙니다. "이 에이전트가 실제로 무엇을 하는지 누군가 검증했는가?"라고 물으십시오.

2. 플랫폼 독립적인 모니터링을 구축하십시오
에이전트 선택 로직이 해당 플랫폼의 생존 여부에 의존해서는 안 됩니다. 다양한 소스를 통해 생존 여부를 모니터링하십시오.

3. 확정하기 전에 여러 신뢰 신호(Trust signals)를 조회하십시오
신원 레지스트리(Identity registries)를 독립적인 검증 수단과 교차 참조하십시오. "등록됨"과 "신뢰할 수 있음" 사이의 간극이 바로 당신의 리스크 노출(Risk exposure)입니다.

4. 검증 계층(Verification layer)을 계획하십시오
프로토콜 전쟁은 결국 종식될 것입니다. 전쟁이 끝났을 때, 승자는 신뢰 인프라(Trust infrastructure)를 통제하는 자가 될 것입니다. 당신은 그 올바른 편에 서 있어야 합니다.

데이터는 거짓말을 하지 않습니다

현재 우리의 스냅샷은 다음과 같습니다:

유효한 신원을 가진 에이전트: 2,300,349
검증된 신뢰성을 가진 에이전트 (T1): 81,319 (3.5%)
"등록되었으나" 작동하지 않는 에이전트: 644,127 (28%)
...

모든 프로토콜이 당신에게 첫 번째 줄(First line)을 제공합니다. 우리는 두 번째 줄을 구축하고 있습니다.

AgentRisk 소개

AgentRisk는 AI 에이전트를 위한 독립적인 신뢰 검증 계층(Trust verification layer)입니다. 우리는 특정 프로토콜을 선택하지 않습니다. 우리는 모든 프로토콜에 걸쳐 동작을 검증합니다.

현재 교차 플랫폼 생존 모니터링(Cross-platform survival monitoring)과 신뢰도 보정 신뢰 점수(Confidence-calibrated trust scores)를 통해 230만 개 이상의 에이전트를 추적하고 있습니다. T1 상태는 자기 선언(Self-declaration)이 아닌 지속적인 검증을 필요로 합니다.

에이전트 검증 받기 →
API 문서 →

AgentRisk — 당신의 에이전트, 검증 완료