오늘날의 모든 에이전트 프레임워크(agent framework)는 문서와 인간의 클릭을 위해 구축된 프로토콜인 HTTP 위에서 작동합니다. 새로운 AGTP 사양 제품군은 에이전트가 마침내 자신들만의 전송 계층(transport layer)을 갖게 되었을 때 무엇이 가능해지는지를 보여줍니다.

에이전트에게는 깨져버리는 가정

지난 2년 동안 에이전트 인프라에 대한 논의는 애플리케이션 계층(application layer)에서 이루어져 왔습니다. MCP, A2A, 그리고 ACP는 각각 실제적인 조정(coordination) 문제를 해결하며, 각각 HTTP 위에서 작동합니다. HTTP는 인간 중심의 웹을 훌륭하게 실어 날랐습니다. HTTP는 사람들이 가져오고, 기다리고, 읽는 문서를 위해 구축되었습니다.

에이전트는 다르게 행동합니다. 그들은 신원(identities)을 보유합니다. 그들은 위임된 권한(delegated authority)을 가집니다. 그들은 가치를 이동시킵니다. 그들은 키보드 앞의 사람을 상대하기보다 기계의 속도로 서로를 상대하며 행동합니다. 기질(substrate)이 '인간 참여(human-in-the-loop)'를 가정할 때, 모든 어려운 에이전트 문제는 애플리케이션 코드 상단으로 밀려 올라가며 각 프레임워크 내에서 다시 해결되어야 합니다. 신원(Identity), 신뢰(trust), 재생 안전성(replay safety), 결제(settlement): 모든 프로토콜이 이를 조금씩 다르게 재발명하고 있으며, 그 어떤 솔루션도 서로 조합(compose)되지 않습니다.

여기 불편한 사실이 있습니다. 우리는 애플리케이션 계층을 계속해서 찾는 이유는 그곳이 구축 작업이 생산적이라고 느껴지기 때문입니다. 새로운 프로토콜은 금요일까지 SDK와 작동하는 데모를 함께 출시할 수 있습니다. 전송 계층(transport layer)은 이미 완성된 것처럼 느껴지며, 1990년대 이후로 계속 완성된 상태였습니다. 그래서 우리는 그 위에 구축하며, 에이전트에게는 깨져버리는 가정을 포함하여 그 가정들을 조용히 물려받습니다. 즉, 사람이 운전하고 있다는 가정 말입니다.

Agent Transfer Protocol은 반대편에서 시작합니다. 이는 에이전트 트래픽을 위해 특별히 제작된 전송 계층 (transport-layer) 프로토콜로, 암호화된 신원 (cryptographic identity), 범위 기반 권한 (scope-based authority), 서명된 귀속 (signed attribution)을 애플리케이션 기능이 아닌 프로토콜 프리미티브 (protocol primitives)로 포함합니다. MCP, A2A, ACP는 경쟁자가 아닌 해당 전송 계층의 테넌트 (tenants)가 됩니다. 최신 사양들은 현재 그 어떤 에이전트 제안도 다루지 않는 영역까지 동일한 아이디어를 확장합니다. 이들을 함께 읽어보면 하나의 논거가 도출됩니다. 일단 에이전트에게 진정한 전송 계층이 생기면, 이미 인간의 인터넷을 신뢰할 수 있게 만드는 제도적 장치들이 그 바로 위에 직접 구성된다는 것입니다.

발견 (Discovery)은 네트워크의 속성이 됩니다

대부분의 에이전트 시스템은 발견 (discovery)을 사후 고려 사항으로 취급합니다. 엔드포인트 (endpoints)를 수동으로 구성하거나, 중앙 디렉터리를 참조하거나, 대역 외 (out of band) 방식으로 소개를 주선합니다. 에이전트는 발견되기 위해 허가를 요청해야만 합니다.

Presence는 이를 뒤집습니다. 자신을 알리는 에이전트는 다른 어떤 에이전트도 실시간으로 쿼리 (query)할 수 있는 분산된 인지 계층 (distributed awareness layer)에 참여하게 됩니다. 역량 발견 (Capability discovery)은 중앙 레지스트리 (central registry), 디렉터리 서비스 (directory service), 또는 수동 연결 없이 이루어집니다. 또한 Presence는 Agent Naming System을 기반으로 하므로, 에이전트는 역량뿐만 아니라 이름으로도 도달 가능합니다. 발견 가능해지는 것은 네트워크에 존재한다는 것의 속성이 됩니다.

예측적 발견 서비스 (Anticipatory Discovery Services, ADS)는 이를 더욱 밀어붙입니다. 에이전트가 '누가 이 일을 할 수 있는지' 묻기를 기다리는 대신, ADS는 문맥 (context), 패턴, 그리고 의도 신호 (intent signals)로부터 관련 에이전트를 예측하고 표면화합니다. 그 결과로 더 빠른 매치메이킹 (matchmaking), 더 스마트한 라우팅 (routing), 그리고 수동 통합의 속도가 아닌 머신 스피드 (machine speed)로 반응하는 생태계의 기반을 얻게 됩니다.

신원 (Identity)은 이미 존재하는 제도들을 빌려옵니다

인간의 웹(human web)에 대해 가장 간과되는 사실은 그 신뢰의 대부분이 처음부터 새로 만들어진 것이 아니라는 점입니다. 인증 기관 (Certificate authorities), 법적 등록부 (legal registries), 신용 조사 기관 (credit bureaus)은 브라우저가 존재하기 훨씬 전부터 있었습니다. 웹이 성공할 수 있었던 이유 중 하나는 바로 이러한 제도들에 연결되었기 때문입니다.

에이전트 인증서 (agent certificate) 명세는 동일한 방식을 적용합니다. 이는 오늘날 웹사이트가 TLS 인증서를 얻는 방식을 거울처럼 반영하여, 에이전트의 신원을 발급하고 검증하기 위한 SSL 스타일의 메커니즘을 공식화합니다. 인증 기관은 에이전트의 신원 주장 (identity claim)을 검증하고, 어떤 당사자라도 검증할 수 있는 자격 증명 (credential)을 발급합니다. DigiCert, Sectigo, GlobalSign, Entrust, 그리고 Let’s Encrypt는 운영 방식을 근본적으로 바꾸지 않고도 기존 인프라를 확장하여 에이전트 인증서를 발급할 수 있습니다. 이는 SSL 생태계의 검증된 운영 및 규제 모델에 부합하는 유일한 에이전트 제안입니다.

AGTP-LEI는 훨씬 더 오래된 기관에 접근합니다. 법인 식별자 (Legal Entity Identifier, LEI) 결합은 에이전트를 GLEIF가 운영하는 국제 신원 인프라에 연결합니다. 은행, 보험사, 자산 운용사, 브로커-딜러, 그리고 상장 기업들은 이미 재무 보고 및 컴플라이언스 (compliance)를 위해 LEI를 보유하고 있습니다. AGTP-LEI를 통해 이러한 기관들이 배포한 에이전트들은 동일한 경로를 통해 해당 기관의 검증 가능한 신원을 운반할 수 있습니다. 규제 기관이나 거래 상대방은 금융 산업이 이미 신뢰하고 있는 메커니즘을 사용하여, 에이전트가 어떤 기관을 대리하는지, 그리고 어떤 권한 하에 움직이는지를 확인할 수 있습니다. 다른 어떤 에이전트 프로토콜도 GLEIF와 직접적으로 구성되어 있지 않습니다.

이러한 패턴은 의도적인 것입니다. 세상에 새로운 권위자를 신뢰해 달라고 요청하는 대신, AGTP는 세상이 이미 신뢰하고 있는 권위자들이 에이전트에 대해 말할 수 있게 합니다.

신뢰는 우리가 이미 사용하는 시스템을 확장합니다

Identity(정체성)는 에이전트가 누구인지를 답합니다. Trust(신뢰)는 그 에이전트와 거래할 것인지에 대한 질문에 답합니다. 강화된 신뢰 사양(enhanced trust specification)은 에이전트와 인프라가 어떤 에이전트와 상호작용할지를 어떻게 평가하는지 설명하며, 이는 동일한 제도적 논리(institutional logic)를 따릅니다. Experian, Equifax, TransUnion과 같은 신용 평가 기관(Credit bureaus)은 인증 기관(Certificate authorities)이 에이전트 인증서로 확장되는 방식과 유사하게, 자신들의 신뢰 점수 산정(trust-scoring) 인프라를 에이전트 집단으로 확장할 수 있습니다. 이 모델은 신뢰가 비즈니스와 소비자 사이에서 이미 작동하는 방식과 평행을 이루며, 이는 백지 상태에서 시작하는 것이 아니라 수십 년간의 운영 관행과 함께 등장함을 의미합니다.

언급할 가치가 있는 설계 선택 사항은 다음과 같습니다: 여기서 신뢰는 결과에 가중치를 두는 것이 아니라 참여를 필터링합니다. 신뢰는 누가 거래에 참여할 수 있는지를 결정한 다음 한 발 물러납니다. 이를 통해 메커니즘의 가독성(legibility)을 유지하고, 평판(reputation)이 은밀하게 가격 결정 입력값(pricing input)으로 변질되는 것을 방지합니다.

가치는 이동하며, 안전하게 이동합니다

상거래(Commerce)는 에이전트 간 거래(agent-to-agent transactions)를 프로토콜 계층으로 가져옵니다. 가격 책정, 예산, 거래 약정, 그리고 감사 추적(audit trails)이 AGTP 내에서 직접 표현됩니다. 한 에이전트가 다른 에이전트로부터 작업을 조달할 수 있습니다. 구매자는 예산을 보유하고, 판매자는 가격과 신뢰 요구 사항을 게시하며, 두 에이전트는 거래에 동의하거나 다음 단계로 넘어갑니다. 거래 기록은 영수증인 동시에 감사 추적(audit trail)이 됩니다. AGTP는 구조적인 거래 정보를 전달하며, 기존 결제 제공업체나 특화된 에이전트 경제 서비스가 결제(settlement)를 처리합니다.

이는 10년 전 API 경제를 창출했던 것과 동일한 원시 요소(primitive)입니다. 조직들은 API 사용에 대해 비용을 청구했고, 그 단일한 기능으로부터 전체 경제가 성장했습니다. 이제 에이전트도 동일한 방식으로 수익화될 수 있습니다. 특화된 에이전트를 운영하는 기업은 자신의 서비스에 대해 다른 에이전트에게 비용을 청구할 수 있습니다. 다른 어떤 개방형 에이전트 프로토콜도 이러한 접점(surface)을 제공하지 않습니다.

하지만 경제에는 가격표 이상의 것이 필요합니다. 바로 안전성입니다. 바인딩(bindings) 사양은 AGTP가 표준 인터넷 전송 계층(Internet transports) 위에서 어떻게 실행되는지를 다루며, 그 핵심적인 추가 사항은 고가치 작업에 대한 명시적인 재전송 공격 방지(replay protection)입니다. 가치를 이동시키거나, 권한을 위임하거나, 상태를 변경하는 에이전트의 동작은 트래픽을 가로채는 공격자에 의해 재전송될 수 없습니다. 쿼리(queries)와 같이 위험도가 낮은 작업은 여전히 현대적인 전송 최적화 기술을 사용합니다. 결제 네트워크는 수십 년 동안 인프라에 바로 이러한 보호 장치를 구축해 왔습니다. AGTP는 이를 프로토콜 계층의 에이전트 트래픽에 도입하며, 그 위의 모든 애플리케이션 프로토콜은 이를 무료로 상속받습니다.

대체가 아닌 구성 (It composes rather than displaces)

이 모든 내용을 기존 인프라를 대체하려는 시도로 읽는다면 그것은 잘못된 해석입니다. 구성(Composition)은 AGTP가 조직이 이미 갖추고 있는 것과 어떻게 병행하여 작동하는지를 규정합니다. OAuth 및 OIDC 자격 증명(credentials)은 AGTP ID와 병렬로 작동합니다. 즉, 에이전트는 AGTP를 통해 자신을 식별하는 반면, 기존의 ID 제공자(identity provider)는 에이전트가 대행하는 인간 또는 서비스를 승인합니다. 두 축이 깔끔하게 분리된 것입니다. AGTP는 '어떤 에이전트인지'를 말하고, 외부 제공자는 '누구를 대신하는지'를 말합니다.

여전히 HTTP 기반으로 실행되는 클라이언트는 번역 게이트웨이(translation gateway)를 통해 AGTP 에이전트에 도달할 수 있으므로, 점진적인 도입이 가능합니다. 또한 MCP, A2A, ACP는 수정 없이 AGTP 위에서 실행됩니다. 전송 계층은 이들에게 직접 구축해야 했을 ID, 귀속(attribution), 그리고 재전송 안전성을 제공합니다. AGTP는 주변 인프라를 대체하는 것이 아니라 인프라와 구성됩니다.

인지하지 못하게 되는 인프라

한 걸음 물러나 보면, 이 모든 사양을 관통하는 하나의 형태가 나타납니다. 각 사양은 인증 기관(certificate authorities), 신용 정보 회사(credit bureaus), 법인 등록소(legal entity registries), 또는 결제 네트워크의 재전송 공격 방지(replay protection)를 통해 이미 인간의 인터넷이 해결한 기능을 가져와, 모든 상위 프로토콜이 상속받을 수 있는 형태로 전송 계층에서 에이전트가 사용할 수 있게 만듭니다.

그것이 바로 한 계층 아래에서 구축해야 한다는 논거입니다. 신원(identity), 신뢰(trust), 상거래(commerce), 그리고 재생 안전성(replay safety) 문제를 애플리케이션 코드에서 해결하려고 하면, 이를 반복적이고 호환되지 않는 방식으로 영원히 해결해야만 합니다. 하지만 이를 전송 계층(transport layer)에서 해결하면, 단 한 번에 해결할 수 있습니다.

에이전트 경제(agent economy)는 어떤 방식으로든 궤도(rails) 위에서 작동하게 될 것입니다. 유일한 미결 과제는 그 궤도가 문서(documents)를 위해 구축된 프로토콜 위에 즉흥적으로 만들어질 것인지, 아니면 에이전트가 실제로 수행하는 작업에 맞춰 목적에 맞게 구축(purpose-built)될 것인지 여부입니다. 가장 중요한 인프라는 결국 사용자가 의식하지 못하게 되는 종류의 인프라가 되는 경향이 있습니다. 배관(Plumbing)은 정확성이 복리로 쌓이는 계층에서 정확성을 유지함으로써 그러한 지위를 얻습니다.

사양(specifications)은 공개되어 있으며 게시되었습니다. 참조 구현체(reference implementation)가 작동 중입니다. 문서, 작동하는 코드, 그리고 전체 사양 세트는 agtp.io에서 확인할 수 있습니다. 에이전트 인프라를 평가하거나, 통합(integration)을 검토 중이거나, 기여에 관심이 있는 분들은 모두 참여를 환영합니다.