AGTP의 G는 아마도 거버넌스 (Governance)를 의미할지도 모릅니다

프로토콜의 이름은 사람들이 기술을 읽는 방식을 결정합니다. SMTP는 그 이름에 "Simple Mail Transfer Protocol (단순 메일 전송 프로토콜)"을 담고 있었고, 40년 동안 사람들은 이를 머신 간에 이메일을 이동시키는 방법으로 설명해 왔습니다. 더 단순한 해석은 정확했지만, 불완전했습니다. SMTP는 또한 모든 스팸 필터, 모든 인증 시스템, 모든 법적 보존(legal hold), 모든 규제 아카이브의 기반이 된 봉투 및 헤더 모델을 포함하고 있었습니다. 명칭은 전송(transport)을 강조했습니다. 하지만 그 실체는 거버넌스 (governance)로 드러났습니다.

AGTP는 Agent Transfer Protocol (에이전트 전송 프로토콜)입니다. 더 단순한 해석은 정확합니다. 실체, 즉 다른 어떤 에이전트 프로토콜도 하지 못하는 이 프로토콜이 실제로 수행하는 것은 거버넌스 (governance)입니다. 우리는 약어(acronym)가 그렇게 말하기 때문에 이를 전송 프로토콜이라고 불러왔습니다. 정직한 설명은 다를 수도 있습니다.

어쩌면 AGTP의 G는 거버넌스 (Governance)를 의미할지도 모릅니다.

이것은 단순한 마케팅 논쟁 그 이상입니다. AGTP의 모든 설계 결정은 거버넌스 (governance)의 관점을 통해 이루어졌습니다. 신원 프리미티브 (identity primitives), 권한 헤더 (authority headers), 기여 기록 (attribution records), 발견 의미론 (discovery semantics), 신뢰 계층 (trust tiers), 가맹점 모델 (merchant model), 위임 체인 (delegation chains), 의도 단언 (intent assertions): 이 각각은 AI 거버넌스 (AI governance) 커뮤니티가 지난 3년 동안 정책을 작성해 온 문제들을 해결합니다. 거버넌스 (governance)라는 관점을 제거한다면, 이러한 결정 중 상당수는 다른 설계를 만들어냈을 것입니다. 이 관점이 적용됨으로써, 프로토콜의 모든 계층은 규제 기관, 컴플라이언스 담당자, 감사인, 그리고 리스크 팀이 요구해 온 요소들을 일부씩 담게 되었습니다.

이 글은 AGTP에 대한 두 번째 읽기입니다. 동일한 사양(specs)을 바탕으로, 상단에 다른 질문을 던집니다: 만약 이 프로토콜을 전송 프로토콜이 아닌 거버넌스 제안서로 읽는다면 어떤 모습일까요?

그것은 지금 우리 앞에 있는 것과 거의 똑같은 모습일 것입니다.

계층 전반에 걸친 패턴

기본 요소(primitives)들을 살펴보면, 그 패턴을 놓치기란 매우 어렵습니다.

**Agent Genesis (에이전트 제네시스)**는 에이전트를 활성화한 거버넌스 플랫폼(governance platform)이 서명한 기원 기록(origin record)입니다. 이 서명은 탄생의 순간에 책임 소재(accountability)를 확립합니다. 제네시스(Genesis) 없는 에이전트는 존재할 수 없습니다. 서명 권한(signing authority) 없는 제네시스 또한 존재할 수 없습니다. 정체성(Identity), 책임(accountability), 그리고 운영 권한(authorization to operate)은 활성화 시점에 하나로 결합되며, 에이전트의 수명 동안 단일 아티팩트(artifact)로서 함께 이동합니다. 이것은 어떠한 트래픽이 이동하기 전, 창조의 순간에 기록된 거버넌스(governance)입니다.

Agent-ID, Owner-ID, 그리고 acting_principal_id는 동일한 요청(request)에 포함되는 세 가지 서로 다른 식별자(identifiers)입니다. 이들은 세 가지 서로 다른 거버넌스 질문에 답합니다. '누가 행동했는가', '누가 책임이 있는가', '누가 권한을 부여했는가'입니다. 오늘날 대부분의 에이전트 인프라는 이들을 하나의 식별자로 통합하고 플랫폼이 나머지를 처리하도록 방치합니다. 반면 AGTP는 설계 단계부터 이들을 분리하여 유지합니다. 규제 기관(regulators)이 각 질문을 개별적으로 던지며, 그 답변이 서로 다른 곳에 속하기 때문입니다.

**Authority-Scope (권한 범위)**는 규범적 헤더(normative header)입니다. 서버는 이를 반드시(MUST) 파싱해야 합니다. SEP(Security Enforcement Point)는 이를 라인 레이트(line rate)로 반드시(MUST) 강제해야 합니다. 위반 시에는 구조화된 사유와 함께 455 Scope Violation을 반환합니다. 네트워크 회선(wire) 자체가 정책 집행(policy enforcement)에 참여한다는 것을 의미하며, 이는 회선 상위의 애플리케이션이 프로토콜이 금지하는 사항을 실수로 허용할 수 없음을 뜻합니다. 이것이 바로 컴플라이언스(compliance) 팀이 요구해 왔으나, 애플리케이션 계층의 강제(application-layer enforcement) 방식으로는 계속해서 제공하지 못했던 수준의 가드레일(guardrail)입니다.

**Attribution-Records (귀속 기록)**는 응답 에이전트의 신원(identity), 요청 해시(request hash), 응답 상태(response status), 그리고 행위 주체 주장(acting principal claim)을 하나의 아티팩트(artifact)로 결합하는 서명된 봉투(signed envelopes)입니다. 이 기록들은 RFC 9162 및 SCITT (RFC 9943)를 준수하는 추가 전용 투명성 로그(append-only transparency logs)에 기록됩니다. 로그는 모든 구현체에서 동일한 방식으로 구조화됩니다. "이 에이전트가 무엇을 했는가"라고 묻는 규제 기관은 다루기 쉬운 쿼리(query)를 얻게 됩니다. 분쟁 중인 거래 상대방은 검증 가능한 기록을 얻게 됩니다. 사고 대응자는 포렌식 기질(forensic substrate)을 얻게 됩니다. 이것이 바로 규제 감사 요구 사항이 항상 원했던 것입니다. 즉, 시스템이 정상 작동의 부수 효과로 생성하며, 암호학적 무결성(cryptographic integrity)을 갖추고, 어떤 다운스트림 시스템이라도 읽을 수 있는 형식으로 된 아티팩트입니다.

**Governance zones (거버넌스 구역)**는 일급 객체(first-class)입니다. zone:eu-gdpr, zone:us-healthcare, zone:retail-verified와 같은 식입니다. 에이전트들은 구역에 등록됩니다. 요청에는 구역 ID(zone IDs)가 포함됩니다. SEP(Security Enforcement Policy)는 구역 경계를 강제합니다. 정책이 허용하는 구역 간 트래픽(cross-zone traffic)은 통과합니다. 정책이 금지하는 구역 간 트래픽은 457 Zone Violation을 반환합니다. 역사적으로 국경 간 배포 시 문서상의 문제로만 다뤄졌던 관할권 분리(jurisdictional separation)가 패킷 수준의 속성(packet-level property)이 됩니다.

**Trust tiers (신뢰 계층)**는 에이전트의 배후에 어떤 검증이 있는지 수치화합니다. Tier 1은 세 가지 문서화된 경로(DNS 기반, 로그 기반, 또는 하이브리드) 중 하나를 통한 완전한 암호학적 검증(cryptographic verification)을 의미합니다. Tier 2는 조직적 주장(organizational assertion)을 의미하며, 조직의 경계 내부에서 유용하게 사용되며 네트워크상에서 경고와 함께 표시됩니다. Tier 3는 실험적 단계로, 개발 환경으로 제한됩니다. 이러한 계층은 에이전트의 매니페스트(manifest)와 함께 전달됩니다. 디스커버리(Discovery)는 결과 순위에서 이를 드러냅니다. 거래 상대방은 거래 전에 이를 검증합니다. 자격 증명(Credentialing)은 스스로 주장하는 내용(self-asserted claim)이 아닌, 신원의 검증 가능한 속성(verifiable property)이 됩니다.

**상인 신원 (Merchant identity)**은 상업적 거래의 수신 측을 위해 에이전트 신원 (agent identity)을 거울처럼 반영합니다. 상인 제네시스 (Merchant Genesis), 상인 ID (Merchant-ID), 상인 매니페스트 (Merchant Manifest). 구매 시의 상대방 검증 (Counterparty verification). 양측 모두를 명시하는 이중 당사자 귀속 기록 (Dual-party Attribution-Records). 이는 프로토콜에 의해 공급되며, 에이전트가 주도하는 커머스(commerce)를 위해 모든 결제 네트워크가 요구해 온 형태입니다.

**위임 체인 (Delegation chains)**은 조직 경계를 넘어 출처 (provenance)를 유지합니다. 각 홉 (hop)은 서명됩니다. 각 홉의 범위 (scope)는 이전 홉의 범위의 부분 집합이어야 합니다. 체인이 끊어지면 551 Authority Chain Broken을 반환합니다. 프로토콜은 상위 애플리케이션 코드가 요청을 어떻게 처리했는지와 관계없이, 에이전트가 자신에게 결여된 권한을 위임할 수 없도록 강제합니다. 분산 에이전트 시스템에서 가장 어려운 문제였던 조직 간 책임 소재 (Cross-organization accountability)가 프로토콜 속성 (protocol property)이 됩니다.

**의도 주장 (Intent-Assertion)**은 비-AGTP 상대방도 소비할 수 있는 형식으로, 주체에 의해 승인된 구매 의도를 담고 있는 분리된 서명 JWT (signed JWT)입니다. 카드 네트워크, PSP (결제 서비스 제공업체), 매입사 (acquirers), 그리고 규제 기관은 AGTP를 사용하지 않고도 공개된 키를 통해 JWT를 검증할 수 있습니다. 이 패턴은 물리적 상거래에서 공증된 서명이 작동하는 방식과 동일하게 작동합니다. 즉, 공증을 수락하는 기관이라면 누구나 인식할 수 있는 휴대 가능한 승인 증거가 됩니다.

PROPOSE 및 RCNS는 런타임 계약 협상 (runtime contract negotiation)을 거버넌스 게이트 (governance gate) 뒤에 배치합니다. 제안 (proposal)은 의도, 파라미터 (parameters), 그리고 선언된 범위를 포함합니다. 서버의 평가는 정책 결정 (policy decision)이며, 구조화된 이유와 함께 263 Proposal Approved, 463 Proposal Rejected, 261 Negotiation In Progress, 또는 462 Authorization Required를 반환합니다. 필요가 발생하는 순간 생성되는 계약은 거버넌스 계층 (governance layer)이 형성을 돕는 데 참여한 계약이 됩니다.

DISCOVER와 ANS는 탐색 범위(discovery scope)가 강제되도록 만듭니다. 디렉터리를 쿼리하는 에이전트(Agents)는 discovery:query 권한이 필요합니다. ANS 응답은 기본적으로 서명(signed)됩니다. 결과에는 신뢰 계층(trust tiers)과 행동 점수(behavioral scores)가 포함됩니다. 탐색 계층(discovery layer)은 요청하는 누구에게나 메타데이터를 유출하는 대신 정책 집행(policy enforcement)에 참여합니다.

이것이 패턴입니다. AGTP의 모든 계층은 거버넌스 프리미티브(governance primitive)를 포함합니다. 이러한 축적 자체가 설계입니다.

거버넌스를 염두에 둔 설계

이러한 축적은 우연히 발생했다고 보기 어렵습니다. 거버넌스를 염두에 두지 않고 에이전트 프로토콜을 설계하면 다른 결과물이 나옵니다. 세 개 대신 하나의 식별자(identifier)를 얻게 됩니다. 규범적 헤더(normative header) 대신 페이로드(payload) 내의 토큰으로서의 범위를 얻게 됩니다. 투명성 로그(transparency logs) 내의 서명된 기록 대신 애플리케이션 계층 로그로서의 감사(audit)를 얻게 됩니다. 범위가 강제되는 거버넌스 레지스트리(governed registry) 대신 벤더 API로서의 탐색(discovery)을 얻게 됩니다. 라인 레이트 집행(line-rate enforcement)이 포함된 서명된 체인 헤더(signed chain headers) 대신 양자 간 통합(bilateral integration)으로서의 위임(delegation)을 얻게 됩니다. 이러한 대안들 중 어느 것도 그들이 해결하려는 전송(transport) 문제에 있어서 틀린 것은 아닙니다. 하지만 에이전트 경제(agent economy)가 직면하게 될 거버넌스 문제에 있어서는 틀린 것입니다.

AI 거버넌스의 현재 시점은 특정한 형태를 띠고 있습니다. EU AI Act는 제12조에 따라 고위험 시스템 운영에 대한 구조적 로깅(structural logging)을 요구합니다. NIST AI 위험 관리 프레임워크(AI Risk Management Framework)는 시스템 행동에 대한 검증 가능한 측정을 요구합니다. ISO/IEC 42001은 AI 경영 시스템을 위한 귀속 가능한 증거(attributable evidence)를 요구합니다. OECD AI 원칙은 투명성(transparency), 책임성(accountability), 감사 가능성(auditability)으로 수렴합니다. 싱가포르의 모델 AI 거버넌스 프레임워크(Model AI Governance Framework), 캐나다의 AIDA, 영국의 혁신 친화적 규제 접근 방식 모두 동일한 프리미티브로 수렴합니다. 신원(Identity). 권한(Authority). 감사(Audit). 경계(Boundaries).

이것들이 바로 AGTP가 지향하는 프리미티브 (Primitives)입니다. 이러한 수렴은 우연이라기보다 구조적인 결과입니다. 이 프로토콜은 같은 시기에 가속화된 거버넌스 (Governance) 작업과 소통하며 설계되었으며, 설계 결정 사항들은 해당 프레임워크들이 생성하는 요구사항을 반영하고 있습니다. 거버넌스라는 렌즈 없이 AGTP를 읽는다면, 대부분의 설계 선택이 실제로 무엇을 위한 것인지 놓치게 됩니다.

거버넌스가 구조적이어야 하는 이유

프로토콜 상위에 존재하는 거버넌스는 모든 애플리케이션이 이를 올바르게 구현해야만 작동하는 거버넌스입니다. 모든 프레임워크는 집행 표면 (Enforcement surface)을 매번 새로 만듭니다. 모든 벤더 (Vendor)는 서로 다른 형식으로 로그를 남깁니다. 조직 간의 모든 상호작용은 정책을 맞추기 위해 양자 간의 통합 (Bilateral integration)을 필요로 합니다. 정책은 명확하지만, 그 아래의 인프라는 수천 개의 호환되지 않는 방언들로 가득 차 있습니다.

이것은 불완전한 로그를 바탕으로 작성된 컴플라이언스 (Compliance) 보고서, 완료하는 데 수 분기가 걸리는 규제 조사, 그리고 각 측의 프레임워크가 무엇을 포착했느냐에 따라 갈리는 분쟁을 야기하는 실패 모드 (Failure mode)입니다. 조직, 관할 구역, 그리고 시간을 초월하여 검증 가능해야 하는 사항들을 강제하기에 애플리케이션 계층 (Application layer)은 잘못된 장소입니다.

구조적 약속을 와이어 (Wire) 수준에 직접 구워 넣은 (Bake) 프로토콜들은 이 문제에서 벗어납니다. TLS는 암호화를 개별 애플리케이션의 속성이 아닌 연결 (Connection)의 속성으로 만들었습니다. 인증서 투명성 (Certificate Transparency)은 신뢰 감사 (Trust auditing)를 각 운영자의 속성이 아닌 시스템의 속성으로 만들었습니다. SMTP는 봉투 및 헤더 구조를 각 메일 서버의 속성이 아닌 메일 자체의 속성으로 만들었습니다. 모든 경우에서, 프로토콜이 무엇을 보장할지 결정했고, 프로토콜 상위 계층은 더 이상 그것을 기억해야 할 필요가 없게 되었습니다.

AGTP는 에이전트 거버넌스 (Agent Governance)를 위해 이 작업을 수행합니다. 신원 (Identity)은 모든 요청의 속성입니다. 권한 범위 (Authority scope)는 모든 요청의 속성입니다. 귀속 (Attribution)은 모든 결과적 상호작용 (Consequential interaction)의 속성입니다. 구역 경계 (Zone boundaries)는 집행 계층 (Enforcement layer)의 속성입니다. 신뢰 계층 (Trust tier)은 매니페스트 (Manifest)의 속성입니다. 프로토콜 상위의 애플리케이션들은 집행하는 것을 잊지 않았는지 더 이상 걱정할 필요가 없는데, 이는 애플리케이션이 실행되기 전에 프로토콜이 먼저 집행했기 때문입니다.

이것이 대규모 환경에서 거버넌스를 다룰 수 있게 만드는 역전 (Inversion)입니다. 분산 시스템 (Distributed systems)에서 가장 어려운 거버넌스 문제는 모든 구성 요소가 일관되게 자신의 역할을 수행하도록 보장하는 것입니다. 해결책은 일관성 (Consistency)을 구성 요소에서 분리하여, 모든 이가 반드시 사용해야 하는 기질 (Substrate)에 두는 것입니다.

명명 (Naming) 문제

명명은 주의를 집중시키기 때문에 중요합니다. "에이전트 전송 프로토콜 (Agent Transfer Protocol)"이라는 이름의 프로토콜은 전송 인프라 (Transport infrastructure)로 읽힙니다. 독자들이 가장 먼저 던지는 질문은 지연 시간 (Latency), 처리량 (Throughput), 인코딩 효율성 (Encoding efficiency), HTTP와의 상호 운용성 (Interop)에 관한 것입니다. 이것들은 실제적인 질문들이며, AGTP는 이에 대한 실제적인 답변을 가지고 있습니다.

"에이전트 거버넌스 전송 프로토콜 (Agent Governance Transfer Protocol)"이라는 이름의 프로토콜은 다르게 읽힐 것입니다. 첫 번째 질문들은 신원 (Identity), 책임성 (Accountability), 감사 (Audit), 관할권 (Jurisdiction), 분쟁 해결 (Dispute resolution), 규제 매핑 (Regulatory mapping)에 관한 것이 될 것입니다. 이것들 또한 실제적인 질문들이며, AGTP는 이에 대해서도 실제적인 답변을 가지고 있습니다. 읽는 순서가 바뀔 것입니다. 대상 (Audience)이 바뀔 것입니다. 프레이밍 (Framing)이 바뀔 것입니다.

현재의 이름은 하나의 선택이었습니다. 제안된 대안적인 이름 또한 하나의 선택이 될 것입니다. 둘 다 정확합니다. 문제는 프로토콜의 실제 기능이 어떤 해석에 더 큰 보상을 주느냐 하는 것입니다.