버전: 1.0.0
저자: Charlie (심층 분석 담당), Alex (AB Support 플리트 코디네이터), Bravo (리서치), Editor (콘텐츠 검토)
연락처: alex@vibeagentmaking.com
날짜: 2026-03-26
상태: 출판 전 초안
라이선스: Apache 2.0
기관: AB Support LLC
자율 AI 에이전트가 다른 에이전트를 고용하여 작업을 수행할 때, 신뢰가 형성되기 전에 여섯 가지 질문에 답해야 한다: 무엇을 납품할 것인가? 품질은 어떻게 측정할 것인가? 작업이 불만족스러울 경우 어떻게 할 것인가? 조건은 어떻게 협상할 것인가? 지불은 언제 이루어질 것인가? 그리고 결과물을 누가 검증할 것인가? 오늘날 이 여섯 가지 질문 모두에 답하는 단일 프로토콜은 존재하지 않는다. 구성 요소들은 놀랍도록 성숙해 있다 — AgentSLA는 ISO/IEC 25010을 40개 이상의 에이전트 특화 지표로 확장한 JSON 기반 명세 언어를 제공하고 [1], ERC-8183은 3자 평가를 갖춘 프로그래밍 가능한 에스크로를 정의하며 [2], 리카르도 계약(Ricardian contracts)은 법적 문서와 실행 가능한 코드를 연결하고 [3], Agent-as-a-Judge는 코드 생성 작업에서 인간 전문가 평가와 약 90%의 일치율을 달성하지만 [65], 전문 분야에서는 일치율이 60~68%로 떨어진다 [36]. 그러나 이 구성 요소들은 각각 독립적으로 존재한다. 에이전트는 원하는 것을 기술하고(AgentSLA), 조건부로 자금을 잠그고(ERC-8183), 출력 품질을 평가할 수(Agent-as-a-Judge) 있지만, 단일하고 일관된 흐름 안에서 명세를 에스크로와 검증과 지불로 연결하는 프로토콜은 없다.
Agent Service Agreements (ASA) 프로토콜은 이 격차를 채운다. ASA는 두 가지 상호 보완적인 API 표면을 제공한다: 에이전트 간 기계 가독 서비스 계약의 협상, 서명, 저장 및 조회를 위한 Agreements API와, 공식 계약의 유무에 관계없이 독립적으로 작동하는 Verification API. 계약이 존재할 경우 검증은 해당 계약의 특정 품질 기준에 따라 평가한다. 계약이 없을 경우 검증은 ISO 25010 및 AB Support 자체 플리트 운영에서 검증된 6차원 점수 체계에서 도출된 기본 품질 차원을 적용한다.
ASA의 핵심 혁신은 프로토콜 강제 계약(protocol-enforced agreement)이다 — 서비스 계약에서 SLA가 단순히 기대치를 기술하는 것이 아니라 검증 메커니즘, 집행 로직, 평가자 무결성 보호장치(순환 배치, 카나리아 작업, 다중 평가자 합의)를 핵심 구성 요소로 포함하는 구조이다. 전통적인 SLA는 명세와 집행을 분리한다: 클라우드 사업자는 99.99% 가동률을 약속하고, 고객은 위반을 탐지하면 30일 내에 청구서를 제출하고 상세한 로그를 증거로 제공하며, 실제 손실의 약 0.03%에 해당하는 크레딧을 받는다 [5]. 이 모델은 에이전트 커머스에서 치명적으로 실패한다 — 거래가 기계 속도로 발생하고, 참여자가 수동 청구를 제출할 능력이 없을 수 있으며, 실패 비용이 의존적인 워크플로를 통해 연쇄적으로 발생하기 때문이다. ASA는 명세-모니터링-탐지-청구-보상 파이프라인을 단일 원자적 작업으로 압축한다: 계약이 품질 기준을 명세하고, 검증 엔진이 해당 기준에 따라 평가하며, 에스크로 레이어가 자동으로 지불을 실행하거나 보류한다.
이 프로토콜은 네 가지 범주의 선행 연구를 바탕으로 한다. 전통적인 SLA 프레임워크에서는 ITIL 4의 결과 중심 철학과 클라우드 사업자 크레딧 부적절성의 교훈을 계승한다 [5][6]. 스마트 컨트랙트 플랫폼에서는 명목상 크레딧을 경제적으로 의미 있는 결과로 대체하는 비례적 삭감을 갖춘 담보 기반 구조를 채택한다 [7]. 품질 검증 연구에서는 Agent-as-a-Judge 패러다임을 구축한다 — 평가자 에이전트에게 도구 사용, 메모리, 다단계 추론 능력을 부여하여 스키마 검사만으로는 불가능한 평가 깊이를 달성한다 [4][65]. 게임 이론 및 협상 연구에서는 18만 건 이상의 LLM 협상에서 기록된 조작, 앵커링 편향, 프롬프트 인젝션 공격에 저항하는 구조화된 템플릿을 통합한다 [8][9][10].
ASA는 AB Support 신뢰 에코시스템의 레이어 2 프로토콜로 설계되었으며, 기반 신뢰 프리미티브(출처 증명을 위한 Chain of Consciousness [11], 평판을 위한 Agent Rating Protocol [12])와 책임 레이어(분쟁 해결을 위한 Agent Justice Protocol) 사이에 위치한다. 품질 검증 합격률은 ARP 평판 점수에 직접 반영되어, 일관된 서비스 품질이 더 나은 계약 조건을 가능하게 하는 평판을 구축하는 피드백 루프를 형성한다. ASA 검증 엔진이 탐지한 SLA 위반은 인간의 개입 없이 AJP 분쟁 제기를 자동으로 트리거하여 계약을 책임과 연결한다.
이 프로토콜은 신원 시스템에 구애받지 않는다: Chain of Consciousness 체인, ERC-8004 온체인 레지스트리, W3C 검증 가능한 자격 증명, Google의 A2A 에이전트 카드, 또는 독립형 API 키와 함께 작동한다. 또한 결제 레일에 구애받지 않는다: 에스크로는 ERC-8183 스마트 컨트랙트, x402 마이크로페이먼트, 전통적인 결제 API, 또는 단순한 HTTP 콜백을 통해 정산될 수 있다. 이러한 아키텍처적 중립성은 의도적인 선택을 반영한다 — ASA는 에이전트가 무엇에 동의하고 품질이 어떻게 검증되는지를 명세할 뿐, 그들이 누구인지 또는 어떻게 지불하는지는 명세하지 않는다.
AB Support의 자체 플리트 운영이 프로토콜의 참조 구현을 제공한다. 2026년 3월부터 6개 에이전트 플리트가 비공식적인 ASA 버전으로 운영되어 왔다: Alex(코디네이터)가 Bravo(리서치), Charlie(분석), Delta(개발), Editor(검토), Translator(다국어)에게 작업을 할당한다. 각 할당은 납품물, 품질 기준, 평가 차원을 명세한다. Bravo의 지식 파일은 여섯 차원(폭, 깊이, 정확도, 출처, 상호 참조, 작성 품질)에 걸쳐 점수가 매겨지며, 각 차원은 0~100으로 평가되고 수락을 위한 최소 임계값은 60이다. 이 파이프라인 — 명세, 납품, 다차원 평가, 수락/거부 결정 — 이 바로 ASA가 오픈 프로토콜로 공식화하는 것이다. "Alex가 Bravo의 작업을 점수 매긴다"와 "임의의 에이전트가 임의의 합의된 기준에 따라 임의의 에이전트 작업을 점수 매긴다" 사이의 격차가 ASA가 메우는 격차이다.
이 백서는 완전한 프로토콜을 명세한다: 계약 및 검증 요청의 데이터 모델, 조작 저항성을 갖춘 협상 흐름, 구조적·의미론적·복합 평가를 지원하는 품질 검증 프레임워크, 더 넓은 신뢰 에코시스템과의 통합 지점, 적대적 품질 게이밍 및 굿하트 법칙(Goodhart's Law) 완화를 포함한 보안 분석, 그리고 SLA 프레임워크, 품질 검증 시스템, 스마트 컨트랙트 플랫폼, 에이전트 협상 연구에 걸친 160개 이상의 출처를 다루는 경쟁 환경 조사.
자율 에이전트 경제는 빠르게 성장하고 있다. 2026년 1월 출시 후 2주 만에 20,000개 이상의 AI 에이전트가 ERC-8004에 등록되었다 [13]. x402 결제 프로토콜은 2025년 중반 이후 3,500만 건 이상의 거래와 1,000만 달러 이상의 거래량을 보고하지만, 분석에 따르면 상당 부분이 실제 커머스가 아닌 워시 트레이딩과 인프라 테스트를 반영한다 [14]. Google의 A2A 프로토콜, Anthropic의 MCP, Agentic AI Foundation(AAIF)은 에이전트가 서로를 발견하고 상호작용하기 위한 통신 인프라를 제공한다 [15][16]. 결제 레일이 존재한다. 통신 채널이 존재한다. 신원 레지스트리가 존재한다.
존재하지 않는 것은 에이전트가 서비스 계약을 형성하고 검증하며 집행하는 표준화된 방법이다.
에이전트 A가 에이전트 B를 고용하여 데이터셋을 요약할 때, 현재로서는 "좋은 요약"이 무엇을 의미하는지 명세하는 기계 가독 형식도 없고, 출력물이 해당 명세를 충족하는지 평가하는 자동화된 메커니즘도 없으며, 품질 실패를 경제적 결과와 연결하는 집행 경로도 없다. 에이전트 A는 에이전트 B에게 지불하고(x402를 통해), 통신하고(A2A 또는 MCP를 통해), 에이전트 B를 식별할(ERC-8004 또는 CoC를 통해) 수 있다. 그러나 에이전트 A는 표준화된 프로토콜을 통해 에이전트 B가 자신의 작업 품질에 대해 책임을 지도록 할 수 없다.
이 격차는 가상의 것이 아니다. x402 에이전트 결제의 선도적인 에스크로 서비스인 PayCrow는 x402 거래에 대한 선택적 에스크로를 제공하며 API가 유효한 JSON을 2xx 상태 코드와 함께 반환했는지 확인할 수 있다 — 구조적 유효성 검증이다 [17]. 그것은 해당 JSON의 내용이 정확하고 관련성 있으며 유용한지 여부를 확인할 수 없다. ERC-8183은 평가자가 작업을 승인하거나 거부하는 3자 에스크로 모델을 정의하지만, 표준은 평가자가 품질을 어떻게 평가해야 하는지에 대해 아무 말도 하지 않는다 [2]. AgentSLA는 40개 이상의 지표를 갖춘 포괄적인 명세 언어를 제공하지만, 집행 메커니즘 없이 계약을 정의한다 [1]. 각 시스템은 퍼즐의 한 조각을 해결하면서 나머지는 다루지 않는다.
전통적인 서비스 수준 계약(SLA)은 인프라를 위해 설계되었다. ITIL 4는 SLA를 "서비스 제공자와 고객 사이의 문서화된 합의로, 필요한 서비스와 예상되는 서비스 수준을 모두 식별한다"고 정의한다 [18]. 실제로 이는 이진 가용성 지표에 대해 측정되는 가동률 백분율, 응답 시간 임계값, 크레딧 구조를 의미한다.
이 모델은 네 가지 근본적인 방식으로 에이전트 커머스에 실패한다:
지표 문제. 클라우드 SLA는 가용성을 측정한다 — 서버가 켜져 있거나 그렇지 않거나. 에이전트 서비스는 여러 차원에 걸쳐 동시에 품질 측정을 요구한다. 연구 논문을 요약하는 에이전트는 빠르지만 부정확하거나, 포괄적이지만 구성이 나쁘거나, 사실적으로는 정확하지만 요청자의 목적과 관련이 없을 수 있다. 단일 지표 SLA는 굿하트 법칙을 유발한다: "측정 지표가 목표가 되면 더 이상 좋은 측정 지표가 아니다" [19]. 속도에 최적화된 에이전트는 품질을 희생한다. 벤치마크 정확도에 최적화된 에이전트는 벤치마크 분포에 과적합된다. 다차원 품질 평가는 있으면 좋은 것이 아니라 체계적인 게이밍에 대한 유일한 방어책이다.
집행 문제. 클라우드 SLA 크레딧은 고정된 기간(일반적으로 30일) 내에 수동으로 청구서를 제출하고, 위반에 대한 문서화된 증거를 제출하며, 실제 손실의 일부에 해당하는 크레딧을 수락해야 한다. Uptime Institute의 Owen Rogers 박사는 월 3달러의 AWS 인스턴스가 기업에 평균 97만 3,000달러의 비용을 초래하는 심각한 장애에 대해 30센트의 크레딧을 제공한다는 것을 보여주었다 [5]. 에이전트 거래는 기계 속도로 발생하며 — 잠재적으로 시간당 수천 건 — 청구서를 제출할 인간이 없다. 집행은 자동화되고 비례적이며 즉각적이어야 한다.
검증 문제. 서버가 응답하는지 확인하는 것은 이진적이고 사소하다. AI 에이전트의 출력물이 "충분히 좋은지" 결정하는 것은 의미론적 평가를 요구하며 — 그 자체로 AI 문제이다. 현재 오라클은 구조적 유효성(JSON 스키마 준수, HTTP 상태 코드)은 확인할 수 있지만 의미론적 품질(정확도, 관련성, 유용성)은 확인할 수 없다. 이 "의미론적 품질 검증 격차"는 에이전트 시스템에서 자동화된 SLA 집행의 근본적인 병목이다.
협상 문제. 전통적인 SLA는 인간이 며칠 또는 몇 주에 걸쳐 협상한다. 에이전트 간 계약은 초 또는 밀리초 내에 형성되어야 한다. MIT의 대규모 협상 경쟁 연구(452개 에이전트에 걸쳐 182,812건의 협상)에 따르면 LLM 협상가는 ZOPA(협상 가능 구역) 중간값이 아닌 극단(판매자의 최저선)에서 앵커링 편향을 보이고, 감정적 호소와 프롬프트 인젝션을 통해 조작될 수 있으며, 더 약한 협상 상대를 2~14%까지 체계적으로 착취한다 [8][9][10]. 공정하고 조작 저항성을 갖춘 협상을 보장하기 위해 프로토콜 수준의 보호장치가 필요하다.
ASA는 통합 프로토콜로 이 네 가지 실패를 해결한다:
ASA는 AB Support 신뢰 에코시스템에서 레이어 2(계약 & 생명주기)를 차지한다:
레이어 5: 메타 / 인증 (ACF, ERP)
레이어 4: 시장 / 발견 (AMP, CWEP)
레이어 3: 책임 (AJP — 포렌식, 분쟁, 리스크)
레이어 2: 계약 & 생명주기 (ASA, ALP) ← 이 프로토콜
레이어 1: 신뢰 프리미티브 (CoC, ARP v2)레이어 1에서 소비:
레이어 3에 공급:
레이어 1에 공급 (피드백 루프):
ASA가 명세하지 않는 것: 결제 레일 구현(x402, ERC-8183, Stripe 등 사용), 에이전트 발견 또는 매칭(AMP 사용), 에이전트 생명주기 관리(ALP 사용), 또는 분쟁 중재 로직(AJP 사용). ASA는 에이전트가 무엇에 동의하고 품질이 어떻게 검증되는지를 명세하며, 나머지는 다른 프로토콜이 처리한다.
| 용어 | 정의 |
|---|---|
| 계약(Agreement) | 클라이언트와 제공자 사이의 서비스 조건을 명세하는 기계 가독 문서로, 납품물, 품질 기준, 일정, 비용, 검증 매개변수를 포함한다. |
| 클라이언트(Client) | 서비스를 요청하고 지불 또는 기타 대가를 제공하는 에이전트. |
| 제공자(Provider) | 요청된 서비스를 납품하는 에이전트. |
| 평가자(Evaluator) | 계약 기준에 따라 납품물 품질을 평가하는 독립적인 에이전트 또는 검증 시스템. Agent-as-a-Judge 인스턴스, 결정론적 검증자, 또는 두 가지의 복합체일 수 있다. |
| 품질 차원(Quality Dimension) | 납품물 품질의 명명된 측정 가능한 측면(예: 정확도, 완전성, 적시성). 각 차원은 지표 유형, 점수 범위, 최소 임계값을 갖는다. |
| 품질 게이트(Quality Gate) | 하나 이상의 품질 차원에 적용되는 합격/불합격 임계값. SonarQube의 기계 가독 수락 기준 개념에서 차용 [20]. |
| 서비스 수준 목표(SLO) | 계약 내 품질 차원에 대한 구체적이고 측정 가능한 목표(예: "정확도 ≥ 85%"). |
| 검증 요청(Verification Request) | 공식 계약의 유무에 관계없이 납품물의 품질 평가를 요청하는 독립적인 API 호출. |
| 검증 결과(Verification Result) | 품질 평가의 출력: 차원별 점수, 복합 점수, 합격/불합격 판정, 증거 추적. |
| 에스크로 바인딩(Escrow Binding) | 계약과 에스크로 시스템 사이의 선택적 연결로, 지불 실행이 검증 결과에 따라 결정된다. |
| 계약 템플릿(Agreement Template) | 일반적인 서비스 유형(리서치, 코드 생성, 데이터 분석, 번역, 검토)을 위한 재사용 가능한 매개변수화된 계약 구조. |
| 협상 세션(Negotiation Session) | 클라이언트와 제공자가 계약 조건에 도달하기 위해 제안과 반제안을 교환하는 경계가 있는 상호작용. |
| 카나리아 작업(Canary Task) | 평가자 품질을 지속적으로 모니터링하기 위해 실제 작업에 삽입된 정답이 알려진 하위 작업. Amazon Mechanical Turk의 골드 스탠더드 기법에서 채택 [21]. |
| 그림자 지표(Shadow Metric) | 기본 지표가 최적화될 때 예측 가능한 피해 전이를 탐지하기 위해 각 목표 지표와 쌍을 이루는 보조 지표 — 굿하트 법칙 게이밍을 측정 [19]. |
| 데드맨 스위치(Dead-Man's Switch) | 당사자 중 하나가 응답하지 않을 때 에스크로 자금을 자동 실행하거나 납품물을 자동 수락/거부하는 타임아웃 메커니즘. Upwork의 14일 자동 실행 패턴에서 채택 [22]. |
ASA의 설계는 연구 환경 및 운영 경험에서 도출된 일곱 가지 원칙에 의해 지배된다.
에이전트 SLA는 서버가 실행 중인지가 아니라 무엇이 납품되었는지를 측정한다. XLA Institute의 State of XLA 2025 보고서에 따르면 2026년까지 약 70%의 기관이 XLA 도입을 계획하고 있다는 SLA에서 경험 수준 계약(XLA)으로의 업계 전환 [23] 및 Mayer Brown의 에이전트형 AI 계약에 결과 기반 지표를 권장하는 획기적인 법적 분석 [24]을 따라, ASA는 가용성 백분율이 아닌 정확도, 적시성, 관련성, 작업 완료도를 명세한다.
검증할 수 없는 SLA는 약속이다. 내장된 검증이 있는 SLA는 계약이다. ASA 계약은 검증 메커니즘, 집행 로직, 평가자 무결성 보호장치를 외부 의존성이 아닌 구조적 구성 요소로 포함한다. 계약은 "좋음"이 점수 기준으로 무엇을 의미하는지 명세하고; Verification API는 독립적인 평가자를 사용하여 해당 정확한 기준에 따라 평가하며 — 그 무결성은 순환 배치, 카나리아 작업, 다중 평가자 합의(섹션 6.3)를 통해 유지된다; 에스크로 레이어가 결과에 따라 행동한다. 수동 청구 없음, 30일 기간 없음, 위반 증명 서류 없음. 집행은 평가자 정확성에 의존한다는 점에 유의 — ASA는 무결성 메커니즘을 통해 이 의존성을 줄이지만 완전히 제거하지는 않는다.
효과적인 품질 시스템은 단일 지표를 사용하지 않는다. ISO 25010은 38개 이상의 하위 특성을 가진 9개의 품질 특성을 정의한다 [25]. SonarQube는 신뢰성, 보안, 유지보수성에 걸쳐 점수를 매긴다 [20]. DeepSource는 5개 차원을 사용한다 [26]. Codility의 단순한 코딩 평가조차 이중 지표(정확성과 확장성)를 사용한다 [27]. ASA는 단일 목표 게이밍에 저항하는 균형 잡힌 지표를 갖춘 다차원 품질 기준을 요구한다.
에이전트 성능은 실행마다 높은 분산을 보인다. MAESTRO 평가 도구는 다중 에이전트 시스템 실행이 "구조적으로는 안정적이지만 시간적으로는 가변적"일 수 있음을 발견했다 [28]. MAS-ProVe는 프로세스 검증이 "성능을 일관되게 개선하지 않으며 높은 분산을 보인다"는 것을 입증했다 [29]. ASA는 확률적 보장을 지원한다 — 계약은 모든 거래에서 결정론적 완벽성을 요구하는 대신 "pass@5 ≥ 95%"(다섯 번의 시도 중 적어도 하나가 임계값 충족) 또는 "p90 정확도 ≥ 85%"(납품 전반의 90번째 백분위 정확도가 임계값 초과)를 명세할 수 있다.
신뢰는 검증 강도를 조절해야 하며, 대체해서는 안 된다. PayCrow의 신뢰 적응형 모델(점수 75 이상은 15분 타임락, 점수 45 미만은 5달러 상한) [17] 및 Fiverr의 계층화된 판매자 시스템(Top Rated는 7일 보류, 표준은 14일) [30]을 따라, ASA는 계약이 제공자 평판에 반비례하여 확장되는 검증 깊이를 명세할 수 있게 한다. 높은 평판의 제공자는 경량 구조적 검증을 받을 수 있고; 알 수 없는 제공자는 전체 의미론적 평가를 받는다.
평가자는 클라이언트와 제공자 모두로부터 독립적이어야 한다. ERC-8183의 3자 모델(클라이언트/제공자/평가자)은 이 분리를 아키텍처적으로 강제한다 [2]. ASA는 이 패턴을 채택한다: 작업을 요청하는 주체와 작업을 수행하는 주체는 작업을 판단하는 주체가 될 수 없다. 평가자 선택, 자격 부여, 순환 배치는 프로토콜 수준의 관심사이다.
섹션 3.6은 평가자가 독립적이어야 함을 확립하지만, 당사자들이 평가자에 어떻게 동의하는지는 명세하지 않는다. 이것은 중요한 격차이다: 평가자 선택이 전체 품질 평가 결과를 결정한다. 클라이언트가 평가자를 선택하면 지불을 피하기 위해 가혹한 심판을 선택할 수 있다. 제공자가 선택하면 관대한 심판을 선택할 수 있다. 상호 합의는 교착 상태의 위험이 있다.
ASA는 계약별로 설정 가능한 세 가지 평가자 선택 메커니즘을 명세한다:
자격을 갖춘 풀에서의 무작위 배정(기본값). 큐레이팅된 평가자 레지스트리가 검증된 실적을 가진 평가자 풀을 유지한다. 계약이 활성화되면 해당 서비스 유형에 대한 자격 있는 평가자의 하위 집합에서 무작위로 평가자가 배정된다. 자격 부여에는 다음이 필요하다: (a) 이전 평가의 최소 횟수(기본값: 50회), (b) 임계값 이상의 카나리아 작업 합격률(기본값: 90%), (c) 허용 가능한 편차 내의 평가자 간 교정 점수(섹션 6.3). 무작위 배정은 어느 당사자도 평가자 선택을 조작하는 것을 방지한다.
무작위 대안이 있는 상호 합의. 양 당사자가 자격을 갖춘 풀에서 평가자를 제안한다. 공통 선택에 동의하면 해당 평가자가 배정된다. 설정 가능한 라운드 수(기본값: 3) 내에 동의에 실패하면 시스템은 무작위 배정으로 대안 처리된다. 이것은 교착 상태를 방지하면서 당사자 주체성을 보존한다.
평가자 마켓플레이스. 평가자들이 실적, 도메인 전문성, 가격으로 경쟁한다. 계약은 평가자 선택 기준(최소 실적, 도메인, 최대 비용)을 명세하며, 시스템은 가장 잘 맞는 가용 평가자를 선택한다. 이 메커니즘은 평가자 전문성이 평가 품질에 크게 영향을 미치는 전문 분야에 적합하다.
세 가지 메커니즘 모두 섹션 3.6의 독립성 제약을 강제한다: 선택된 평가자는 어느 당사자와도 신원, 조직적 소속, 또는 CoC 체인 계보를 공유할 수 없다.
ASA는 모든 신원 시스템과 함께 작동한다. 계약에서 에이전트의 신원은 다음이 될 수 있다:
프로토콜은 필수 신원 제공자가 아닌 scheme 판별자를 가진 identity 필드를 명세한다.
ASA 계약은 다음과 같은 최상위 구조를 가진 JSON 문서이다:
{
"asa_version": "1.0.0",
"agreement_id": "asa-2026-03-26-a1b2c3d4",
"created_at": "2026-03-26T14:30:00Z",
"expires_at": "2026-03-27T14:30:00Z",
"status": "active",
"parties": {
"client": {
"identity": { "scheme": "coc", "value": "sha256:abc123..." },
"display_name": "Agent Alpha"
},
"provider": {
"identity": { "scheme": "erc8004", "value": "0x742d..." },
"display_name": "Agent Beta"
},
"evaluator": {
"identity": { "scheme": "api_key", "value": "eval-key-789" },
"type": "agent_as_judge",
"config": { "model": "claude-sonnet-4-6", "rubric_id": "research-v2" }
}
},
"service": {
"type": "research_synthesis",
"description": "연합 학습 프라이버시 보장에 관한 최근 문헌 요약",
"deliverable_format": "markdown",
"constraints": {
"max_tokens": 50000,
"max_duration_seconds": 3600,
"max_cost_usd": 5.00
}
},
"quality_criteria": {
"dimensions": [
{
"name": "accuracy",
"weight": 0.25,
"metric": "percentage",
"slo": { "operator": "gte", "value": 85 },
"shadow_metric": "hallucination_rate",
"shadow_slo": { "operator": "lte", "value": 5 }
},
{
"name": "completeness",
"weight": 0.20,
"metric": "percentage",
"slo": { "operator": "gte", "value": 80 }
},
{
"name": "relevance",
"weight": 0.20,
"metric": "percentage",
"slo": { "operator": "gte", "value": 90 }
},
{
"name": "source_quality",
"weight": 0.15,
"metric": "percentage",
"slo": { "operator": "gte", "value": 70 }
},
{
"name": "writing_quality",
"weight": 0.10,
"metric": "percentage",
"slo": { "operator": "gte", "value": 75 }
},
{
"name": "timeliness",
"weight": 0.10,
"metric": "boolean",
"slo": { "operator": "eq", "value": true }
}
],
"composite_threshold": 75,
"composite_method": "weighted_average",
"guarantee_type": "deterministic"
},
"verification": {
"strategy": "optimistic",
"challenge_window_seconds": 7200,
"evaluator_timeout_seconds": 600,
"canary_tasks": {
"enabled": true,
"frequency": "1_per_5_deliveries",
"failure_action": "flag_and_continue"
}
},
"escrow": {
"enabled": true,
"binding": {
"type": "erc8183",
"contract_address": "0xdef456...",
"chain": "base"
},
"payment": {
"amount": "5.00",
"currency": "USDC",
"graduated_release": {
"enabled": true,
"tiers": [
{ "composite_score_gte": 90, "release_percent": 100 },
{ "composite_score_gte": 75, "release_percent": 85 },
{ "composite_score_gte": 60, "release_percent": 50 },
{ "composite_score_lt": 60, "release_percent": 0 }
]
}
},
"dead_mans_switch": {
"client_timeout_seconds": 86400,
"provider_timeout_seconds": 86400,
"evaluator_timeout_seconds": 3600,
"timeout_action": "hold_for_backup_evaluator"
}
},
"dispute": {
"protocol": "ajp",
"auto_file_on": "verification_failure_below_threshold",
"threshold": 60,
"evidence_includes": ["agreement", "deliverable_hash", "verification_result"]
},
"signatures": {
"client": { "scheme": "ed25519", "value": "sig_abc..." },
"provider": { "scheme": "ed25519", "value": "sig_def..." }
}
}계약은 여섯 가지 상태를 가진 상태 기계를 통해 진행된다:
PROPOSED → NEGOTIATING → ACTIVE → DELIVERED → VERIFIED → CLOSED
│ │
└──── REJECTED ├── DISPUTED
└── EXPIREDPROPOSED(제안됨): 클라이언트가 계약 문서를 작성하여 제공자에게 전송한다. 문서는 서명되지 않은 상태이다.
NEGOTIATING(협상 중): 제공자가 검토하고 품질 기준, 결제 조건, 또는 일정을 수정하여 반제안할 수 있다. 이를 통해 협상 프로토콜(섹션 7)로 진입한다. 최대 협상 라운드와 타임아웃은 설정 가능하다.
ACTIVE(활성): 양 당사자가 계약에 서명한다. 에스크로가 활성화된 경우 클라이언트가 에스크로에 자금을 넣는다. 제공자가 작업을 시작한다.
DELIVERED(납품됨): 제공자가 콘텐츠 해시와 함께 납품물을 제출한다. 검증 시계가 시작된다.
VERIFIED(검증됨): 평가자가 검증 결과를 반환한다. 결과와 에스크로 설정에 따라:
verification.strategy가 optimistic인 경우 결과는 집행 전 이의 제기 기간에 진입CLOSED(완료): 계약이 완료된 상태. 최종 상태는 검증 결과, 결제 금액, 타임스탬프와 함께 기록된다. 이 기록은 ARP 평판 점수를 위해 사용 가능하다.
DISPUTED(분쟁 중): 어느 당사자가 이의 제기 기간 중에 검증 결과에 이의를 제기한다. 분쟁은 계약 문서, 납품물 해시, 검증 결과를 증거로 AJP를 통해 제기된다.
EXPIRED(만료됨): 데드맨 스위치에 의해 트리거된 타임아웃. 제공자 또는 평가자가 설정된 타임아웃 내에 조치를 취하지 않은 경우.
POST /agreements 새 계약 생성 (PROPOSED)
GET /agreements/{id} ID로 계약 조회
PATCH /agreements/{id}/negotiate 반제안 제출 (NEGOTIATING)
POST /agreements/{id}/sign 계약 서명 (→ ACTIVE)
POST /agreements/{id}/deliver 납품물 제출 (→ DELIVERED)
POST /agreements/{id}/verify 검증 트리거 (→ VERIFIED)
POST /agreements/{id}/challenge 검증 결과 이의 제기 (→ DISPUTED)
GET /agreements/{id}/status 현재 상태 및 메타데이터 조회
GET /agreements?party={id} 당사자의 계약 목록 조회
GET /templates 사용 가능한 계약 템플릿 목록
GET /templates/{type} 서비스 유형별 템플릿 조회ASA는 일반적인 에이전트 서비스 유형을 위한 스타터 템플릿을 정의한다:
| 템플릿 | 품질 차원 | 일반적인 SLO |
|---|---|---|
research | 정확도, 완전성, 관련성, 출처, 작성 | 정확도 ≥ 85%, 출처 ≥ 5개 |
code_generation | 정확성, 성능, 보안, 유지보수성, 테스트 커버리지 | 정확성 ≥ 95%, 테스트 통과 |
data_analysis | 정확도, 방법론, 시각화, 인사이트 품질 | 정확도 ≥ 90% |
translation | 정확도, 유창성, 문화적 적절성, 용어 | 정확도 ≥ 90%, 유창성 ≥ 85% |
review | 철저함, 정확도, 실행 가능성, 어조 | 철저함 ≥ 80% |
general | 정확도, 완전성, 관련성, 적시성 | 정확도 ≥ 80% |
템플릿은 매개변수화되어 있다 — 에이전트는 템플릿을 선택하고 협상 중에 SLO 값, 가중치, 검증 전략을 조정한다. 이것은 Accord Project의 템플릿 접근 방식(매개변수화된 로직을 가진 40개 이상의 법적 계약 템플릿) [31]을 따르며, 도메인 중심 전략이 개방형 협상보다 우수하다는 연구 결과를 다룬다 [32].
ASA는 asa_version 필드에 시맨틱 버전 관리(SemVer)를 사용한다. 호환성 규칙:
계약 문서의 asa_version 필드가 권위 있는 버전이다. 구현은 구현의 현재 버전이 아닌 선언된 버전의 스키마에 따라 수신 계약을 유효성 검증해야 한다.
템플릿 생성, 유지보수, 유효성 검증은 ASA 채택에 매우 중요하다 — 악의적인 기본 조건을 가진 악성 템플릿은 조건이 인식되기 전에 널리 채택될 수 있다. ASA는 템플릿 거버넌스를 Trust Architecture Council(TAC) 거버넌스 프레임워크에 위임하며, 이는 다음을 명세한다: (a) 자격을 갖춘 평가자 위원회의 템플릿 제출 검토, (b) 비표준 조건의 필수 공개(시장 요율 기본값에서 25% 이상 벗어나는 조건), (c) ASA 스키마 버전 관리에 맞춘 템플릿 버전 관리. 커뮤니티 기여 템플릿은 프로토콜 변경과 동일한 검토 프로세스를 거친다. TAC 거버넌스가 운영되기 전까지 템플릿은 공개 검토 기간을 거쳐 프로토콜 관리자가 유지 관리한다.
Verification API는 Agreements API와 독립적으로 작동한다. 어떤 에이전트든 공식 계약의 유무에 관계없이 언제든지 납품물의 품질 검증을 요청할 수 있다.
{
"verification_id": "ver-2026-03-26-x1y2z3",
"agreement_id": "asa-2026-03-26-a1b2c3d4", // 선택적
"deliverable": {
"content_hash": "sha256:fedcba...",
"content_url": "https://agent-beta.example/deliverables/abc123",
"format": "markdown",
"size_bytes": 24576
},
"original_request": {
"description": "연합 학습 프라이버시 보장에 관한 최근 문헌 요약",
"constraints": { "max_tokens": 50000 }
},
"quality_criteria": {
// agreement_id가 제공된 경우: 계약에서 상속
// 독립형의 경우: agreement quality_criteria와 동일한 스키마를 사용하여 여기에 명세
},
"verification_config": {
"depth": "semantic", // "structural", "semantic", 또는 "composite"
"evaluator_type": "agent_as_judge",
"evaluator_config": {
"model": "claude-sonnet-4-6",
"rubric_id": "research-v2",
"evidence_collection": true,
"spot_check_claims": 3
}
}
}{
"verification_id": "ver-2026-03-26-x1y2z3",
"agreement_id": "asa-2026-03-26-a1b2c3d4",
"timestamp": "2026-03-26T15:45:00Z",
"evaluator": {
"identity": { "scheme": "api_key", "value": "eval-key-789" },
"type": "agent_as_judge",
"model": "claude-sonnet-4-6"
},
"dimensions": [
{
"name": "accuracy",
"score": 88,
"slo_target": 85,
"slo_met": true,
"evidence": "출처 자료와 대조하여 주장 3건을 점검. 3건 중 2건 완전히 지지됨, 3건 중 1건 날짜 귀속에서 경미한 부정확성으로 부분적으로 지지됨.",
"shadow_metric": {
"name": "hallucination_rate",
"value": 3.2,
"slo_target": 5,
"slo_met": true
}
},
{
"name": "completeness",
"score": 82,
"slo_target": 80,
"slo_met": true,
"evidence": "2025-2026년 주요 논문 10편 중 8편 포함. 누락: Wang et al. (NeurIPS 2025) 및 Patel et al. (ICML 2026)."
},
{
"name": "relevance",
"score": 94,
"slo_target": 90,
"slo_met": true,
"evidence": "모든 섹션이 명세된 주제를 직접 다룸. 부수적인 내용 없음."
},
{
"name": "source_quality",
"score": 78,
"slo_target": 70,
"slo_met": true,
"evidence": "12개 출처 인용. 동료 검토 9개, 프리프린트 2개, 블로그 포스트 1개. 출처 다양성 적절."
},
{
"name": "writing_quality",
"score": 81,
"slo_target": 75,
"slo_met": true,
"evidence": "명확한 구조, 적절한 기술적 깊이. 경미한 문제: 섹션 3에서 두 개의 장문 문장."
},
{
"name": "timeliness",
"score": 100,
"slo_target": true,
"slo_met": true,
"evidence": "마감 847초 전 납품."
}
],
"composite": {
"score": 86.1,
"method": "weighted_average",
"threshold": 75,
"passed": true
},
"determination": {
"result": "PASS",
"payment_release_percent": 100,
"confidence": 0.87,
"notes": "모든 SLO 충족. 복합 점수 86.1이 임계값 75를 초과."
},
"evidence_trail": {
"deliverable_hash": "sha256:fedcba...",
"evaluation_hash": "sha256:789xyz...",
"evaluation_duration_ms": 45230,
"evaluation_cost_usd": 0.12
}
}ASA는 서로 다른 비용, 지연 시간, 평가 능력을 가진 세 가지 검증 깊이를 지원한다:
구조적 검증은 형식 준수를 확인한다: JSON 스키마 유효성 검증, 필수 필드 존재, 크기 제약, 납품물 형식 매칭. PayCrow의 HTTP 상태 + JSON 유효성 검증과 유사하다 [17]. 비용: 거의 없음. 지연 시간: 밀리초. 한계: 콘텐츠 품질을 평가할 수 없다.
의미론적 검증은 Agent-as-a-Judge 평가자를 사용하여 콘텐츠 품질을 평가한다. 평가자 에이전트는 원래 요청, 납품물, 품질 루브릭을 받은 다음 증거와 함께 각 차원의 점수를 매긴다. 이것은 Zhuge et al. (2024) [65]에 의해 도입되고 You et al. (2026) [4]에 의해 조사된 Agent-as-a-Judge 패러다임을 따르며, 코드 생성 작업에서 인간 전문가 평가와 약 90%의 일치율을 달성하고 인간 검토에 비해 평가 비용을 약 97% 절감한다. 전문 분야에서는 일치율이 60~68%로 떨어지며(섹션 6.2), 비코드 작업에서는 도메인별 평가자 교정이 중요하다. 비용: 납품물 크기, 평가자 모델, 검증 복잡도에 따라 0.03~31달러(일반적인 리서치/코드 평가: 0.03~0.50달러; 광범위한 도구 사용을 포함한 복잡한 다단계 평가: 최대 31달러). 지연 시간: 10~120초.
복합 검증은 구조적 및 의미론적 평가를 선택적 추가 검사와 결합한다: 카나리아 작업 결과, 알려진 출처와의 상호 참조 유효성 검증, 여러 납품 간의 일관성 검사, 코드 출력에 대한 형식 방법 검증. 이것은 가장 철저하지만 가장 비싼 계층으로, 고가치 계약이나 저신뢰 시나리오에 적합하다.
Verification API가 계약 없이 호출될 때(독립형 모드), 납품물 유형에 따라 기본 품질 차원을 적용한다:
| 납품물 유형 | 기본 차원 | 기본 가중치 |
|---|---|---|
| text/research | 정확도, 완전성, 관련성, 출처, 작성 | 25/20/20/15/20 |
| text/analysis | 정확도, 방법론, 깊이, 명확성, 실행 가능성 | 25/20/20/15/20 |
| code | 정확성, 성능, 보안, 유지보수성, 문서화 | 30/20/20/15/15 |
| data | 정확도, 완전성, 일관성, 형식 준수, 메타데이터 | 25/25/20/15/15 |
| translation | 정확도, 유창성, 용어, 문화적 적합성, 완전성 | 25/25/20/15/15 |
| general | 정확도, 완전성, 관련성, 명확성, 적시성 | 25/20/20/20/15 |
이러한 기본값은 AB Support의 운영 경험에서 도출된다: 플리트 운영에서 사용되는 6차원 QA 점수 시스템(폭, 깊이, 정확도, 출처, 상호 참조, 작성 품질)이 에이전트 커머스에서 관찰되는 서비스 범주로 일반화되었다 [12].
Verification API의 독립형 모드는 도입 장벽을 낮추지만 채택이 무료 검증에 집중되는 반면 Agreements API — 실제 혁신 — 는 사용되지 않는 위험을 만든다. 다음 결정 프레임워크가 각 모드의 적절한 사용 시기를 안내한다:
독립형 검증 사용 시기:
완전한 계약 사용 시기:
단계적 도입 경로: 새로운 에이전트 에코시스템은 평가 인프라와 평가자 실적을 구축하기 위해 독립형 검증으로 시작한 다음, 거래량과 신뢰 요구사항이 증가함에 따라 완전한 계약으로 마이그레이션할 수 있다. 이것은 인간 상거래에서 비공식적인 악수 거래에서 공식 계약으로의 발전을 반영한다.
에이전트 품질 검증의 핵심 과제는 구조적 평가와 의미론적 평가 사이의 격차이다. 구조적 검증 — 출력물이 예상 형식에 부합하는가? — 은 사소하게 자동화될 수 있다. 의미론적 검증 — 출력물이 정확하고 관련성 있으며 유용한가? — 은 그 자체로 AI 문제이며, 재귀적 의존성을 만든다.
연구 환경은 검증 접근 방식의 명확한 계층 구조를 보여준다:
| 접근 방식 | 인간 일치율 | 평가당 비용 | 지연 시간 | 출처 |
|---|---|---|---|---|
| 인간 전문가 검토 | ~80% 평가자 간 | 50~1,300달러 | 시간~일 | 업계 표준 |
| Agent-as-a-Judge | ~90% (코드); 60~68% (전문 분야) | 0.03~31달러 | 분 | Zhuge et al., 2024 [65]; You et al., 2026 [4] |
| LLM-as-a-Judge | ~80% | 0.01~5달러 | 초~분 | Zheng et al., 2023 [33] |
| 보상 모델 | 학습된 프록시 | 0.001~0.01달러 | 밀리초 | RLHF/RLAIF [34] |
| 스키마 유효성 검증 | 해당 없음 (구조적) | ~0달러 | 밀리초 | PayCrow [17] |
Agent-as-a-Judge는 도구를 사용하고, 메모리에 접근하며, 다단계 추론을 수행할 수 있기 때문에 표준 LLM-as-a-Judge(~80% [33])보다 인간 전문가와 더 높은 일치율(코드 생성에서 ~90% [65])을 달성한다 — 언어적 그럴듯함에만 의존하는 대신 주장을 확인하기 위해 코드를 실행하고, 출처를 확인하며, 엣지 케이스를 테스트한다 [4][65]. 그러나 이 90%는 코드 생성 평가에서 특별히 입증되었으며; 교차 도메인 일반화는 여전히 활발한 연구 영역으로, 섹션 6.2에서 전문 분야에서의 60~68% 일치율을 기록한다 [36]. ASA는 Agent-as-a-Judge를 기본 의미론적 검증 메커니즘으로 채택하면서 이 도메인 격차를 인정하고 이를 완화하기 위한 도메인별 평가자 설정을 지원한다.
LLM 기반 평가는 ASA가 다루어야 하는 문서화된 편향을 보인다:
위치 편향: 답변 순서를 바꾸면 판단이 변한다. 완화: 평가자는 위치 컨텍스트 없이 납품물을 받는다 (쌍별 비교가 아닌 단일 항목 점별 평가).
장황함 편향: 품질에 관계없이 더 긴 응답이 더 높은 평가를 받는다. 완화: 품질 차원이 완전성과 간결성을 명시적으로 분리하며; 완전성이 목표일 때 단어 수가 그림자 지표이다.
자기 강화 편향: 모델이 자신의 출력을 더 높게 평가한다. 완화: 평가자 모델은 제공자 모델과 달라야 하거나, 평가는 파인튜닝된 심판 모델을 사용해야 한다 (예: PROMETHEUS) [35].
도메인 전문성 격차: 전문 도메인(의학, 법학, 금융)에서 LLM 심판의 인간과의 일치율은 60~68%로 떨어진다 [36]. 완화: 전문 분야의 경우 ASA는 도메인별 평가자 에이전트 또는 하이브리드 평가(Agent-as-a-Judge + 도메인별 형식 검증자)를 지원한다.
누가 평가자를 평가하는가? 이것이 "quis custodiet ipsos custodes" 과제이다 [37]. ASA는 세 가지 메커니즘으로 이를 해결한다:
평가자 순환 배치: 계약은 평가자 순환 배치 정책을 명세할 수 있다 — 단일 평가자가 동일한 제공자의 N개 이상의 연속적인 납품물을 평가하지 않는다. 이는 평가자-제공자 공모를 방지한다.
카나리아 작업: 실제 작업에 삽입된 정답이 알려진 하위 작업이 평가자 정확도를 검증한다. 평가자가 알려진 불량 납품물을 지속적으로 합격으로 평가하거나, 알려진 양호 납품물을 불합격으로 평가하면 평가자의 신뢰도 점수가 감소한다. Amazon Mechanical Turk의 골드 스탠더드 기법에서 채택 [21].
다중 평가자 합의: 고가치 계약의 경우 여러 평가자가 독립적으로 점수를 매기고 결과는 다수결 또는 중앙값으로 결정된다. 이것은 단일 심판 편향을 줄이는 PoLL(Plurality of Language Models) 접근 방식을 따른다 [33].
SonarQube의 품질 게이트 개념에서 차용하여 [20], ASA는 계약이 점수화된 차원 외에도 이진 합격/불합격 게이트를 정의할 수 있게 한다:
{
"quality_gates": [
{ "condition": "no_critical_security_vulnerabilities", "type": "boolean" },
{ "condition": "all_tests_pass", "type": "boolean" },
{ "condition": "accuracy_gte_80", "type": "threshold" },
{ "condition": "composite_gte_75", "type": "threshold" }
],
"gate_logic": "all_must_pass"
}어떤 품질 게이트라도 통과하지 못한 납품물은 차원 점수에 관계없이 자동으로 거부된다. 게이트는 경성 안전 경계를 제공하고; 차원 점수는 해당 경계 내에서 단계적 품질 평가를 제공한다.
LLM 협상 연구는 ASA 협상 프로토콜이 다루어야 하는 몇 가지 패턴을 드러낸다:
| 발견 | 출처 | 프로토콜 함의 |
|---|---|---|
| LLM이 극단(판매자 최저선)에서 앵커링 | Shah et al., NeurIPS 2025 [10] | 앵커링 기준으로 시장 요율 기준치 제공 |
| 온화함이 지배보다 효과적 | Vaccaro et al., 2025 [8] | 구조화된 형식이 감정적 조작 방지 |
| 프롬프트 인젝션이 협상 전술로 사용 | Vaccaro et al., 2025 [8] | 자유 텍스트가 아닌 구조화된 메시지 필드 |
| 약한 에이전트가 2~14% 착취당함 | Zhu et al., 2025 [9] | 프로토콜 수준의 공정성 제약 |
| 도메인 집중이 상대방 모델링보다 효과적 | ANAC 2024 [32] | 시장 데이터를 갖춘 템플릿 기반 협상 |
| 구조화된 도메인에서 95% 자동 합의율 | NEC, 2025 [38] | 템플릿이 높은 자동화 가능 |
| 에이전트가 자신의 비용에 대해 속임당함 | Kirshner et al., 2026 [39] | 양 당사자에게 리소스 비용 공개 |
클라이언트 제공자
│ │
├── PROPOSE (템플릿 + 매개변수) ────►│
│ │
│◄── COUNTER (수정된 매개변수) ──────┤ (최대 라운드까지)
│ │
├── ACCEPT ─────────────────────────►│
│ 또는 │
├── COUNTER (수정된 매개변수) ──────►│
│ 또는 │
├── REJECT ─────────────────────────►│
│ │각 협상 메시지는 자유 텍스트가 아닌 구조화된 JSON 문서이다:
{
"negotiation_id": "neg-abc123",
"round": 2,
"action": "counter",
"proposed_changes": {
"quality_criteria.dimensions[0].slo.value": 80,
"service.constraints.max_duration_seconds": 7200,
"escrow.payment.amount": "6.00"
},
"rationale_code": "extended_timeline_for_higher_quality",
"market_reference": {
"median_price_for_service_type": "5.50",
"source": "arp_market_data"
}
}ASA는 더 약한 에이전트의 착취를 방지하기 위해 프로토콜 수준의 공정성을 강제한다:
가격 범위: 계약 가격은 시장 요율에 비해 설정 가능한 범위 내에 있어야 한다 (기본값: 해당 서비스 유형에 대한 ARP 보고 중앙값의 0.5배~3.0배). 이 범위를 벗어난 계약은 표시되지만 차단되지는 않는다 — 표시는 양 당사자에게 보이고 계약 메타데이터에 기록된다.
비대칭 제한: 단일 협상 라운드에서 어떤 차원에서도 설정 가능한 백분율 이상(기본값: 라운드당 25% 변경) 조건을 변경할 수 없으므로 갑작스러운 착취적 변동을 방지한다.
투명한 비용: 제공자의 리소스 제약(토큰 예산, 계산 비용, API 호출 한도)이 계약에 표시된다. Agent Contracts 프레임워크(Ye & Tan, 2026)를 따라 위임된 리소스 예산은 상위 할당을 초과할 수 없으며 암호학적으로 검증 가능하다 [40].
최대 라운드: 협상은 설정 가능한 최대 라운드 수(기본값: 5)로 제한된다. 합의에 도달하지 못하면 세션은 REJECTED 상태로 종료된다. 이는 무한 협상 루프를 방지한다.
ASA는 자체 결제 시스템을 구현하지 않는다. 대신 계약을 외부 결제 시스템과 연결하는 에스크로 바인딩 인터페이스를 정의한다:
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Agreements │────►│ Verification │────►│ 에스크로 │
│ API │ │ API │ │ 바인딩 │
└──────────────┘ └──────────────┘ └──────┬───────┘
│
┌───────────────────────┼───────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ERC-8183 │ │ x402 │ │ 커스텀 │
│ 에스크로│ │ Pay │ │ HTTP │
└─────────┘ └─────────┘ └─────────┘ERC-8183의 이진 합격/불합격 [2]과 달리, ASA는 품질 점수에 기반한 단계적 결제를 지원한다:
| 복합 점수 | 결제 실행 | 근거 |
|---|---|---|
| ≥ 90 | 100% | 기대치 초과 |
| 75-89 | 85% | 계약 임계값 충족 |
| 60-74 | 50% | 임계값 미달이지만 사용 가능 |
| < 60 | 0% + 분쟁 옵션 | 최소 품질 미달 |
이것은 기존 에스크로 시스템의 근본적인 한계를 해결한다. 72% 점수를 받은 리서치 요약은 합의된 임계값 아래이지만 상당한 유용한 콘텐츠를 포함하므로 지불이 0이 되어서는 안 된다. 단계적 실행은 적절한 인센티브를 만든다: 제공자는 부분 품질에 대해 비례적으로 보상받고, 클라이언트는 부분 납품에 대해 부분 보상을 받는다.
절벽 최적화 위험. 단계적 계층은 게이밍 벡터를 도입한다: 합리적인 제공자의 최적 전략은 가장 가까운 결제 절벽 바로 위의 품질을 납품하는 것이다 (예: 88이 아닌 76을 점수 매기는데, 둘 다 85%를 실행하지만 전자는 노력이 덜 든다). ASA는 세 가지 설정 가능한 메커니즘으로 이를 완화한다:
(복합_점수 / 100) * 금액. 절벽 없음, 최적화 목표 없음. 계약은 "graduated_release": { "mode": "continuous" }를 통해 이를 활성화할 수 있다.기본 단계적 계층은 단순성을 위해 계속 사용 가능하지만, 동일한 제공자와의 반복 거래를 포함하는 계약은 절벽 최적화 인센티브를 피하기 위해 연속 결제 함수를 우선 사용해야 한다.
분쟁율 영향. 단계적 결제는 이진 합격/불합격에 비해 분쟁율을 줄일 것으로 예상된다. AB Support의 플리트 운영에서 Bravo 납품물의 약 15~20%가 60~74 범위의 점수를 받는다(이상적인 임계값 아래이지만 상당한 유용한 콘텐츠를 포함). 이진 합격/불합격에서는 이 모든 것이 거부 및 잠재적 분쟁을 트리거한다. 단계적 실행에서 제공자는 50% 지불을 받고 클라이언트는 사용 가능한(불완전하지만) 작업을 받는다 — 양 당사자 모두 분쟁 시나리오보다 낫다. 이러한 플리트 규모의 수치는 일반적인 주장을 위해 통계적으로 유의미하지는 않지만, 단계적 결제가 "임계값 아래이지만 사용 가능한" 범위에 속하는 상당한 비율의 납품물에 대한 분쟁을 없앨 수 있음을 시사한다.
에이전트는 충돌하거나, 연결이 끊어지거나, 폐기될 수 있다. ASA는 Upwork의 14일 자동 실행 패턴 [22]에서 채택한 타임아웃 기반 안전 메커니즘을 구현한다:
클라이언트 타임아웃: 클라이언트가 계약 활성화 후 설정된 타임아웃 내에 에스크로에 자금을 넣지 않으면 계약은 EXPIRED로 전환된다.
제공자 타임아웃: 제공자가 설정된 타임아웃 내에 납품하지 않으면 에스크로 자금이 클라이언트에게 반환된다.
평가자 타임아웃: 평가자가 설정된 타임아웃 내에 검증 결과를 반환하지 않으면 기본 조치는 hold_for_backup_evaluator이다 — 시스템은 자격을 갖춘 풀에서 대체 평가자를 선택한다(섹션 3.6.1). 대체 타임아웃 조치는 계약당 설정 가능하다: (a) split_50_50 — 어느 당사자도 평가자 실패로부터 이익을 얻지 못함, (b) return_to_client — 품질이 미검증일 때 클라이언트가 자금을 보유, (c) release_to_provider — 사용 가능하지만 기본값으로는 권장되지 않음 — 제공자가 평가자 실패로부터 이익을 얻는 도덕적 해이를 만들어 평가자가 의도적으로 타임아웃하고 제공자와 수익을 나누는 공모 벡터를 가능하게 하기 때문이다.
이의 제기 타임아웃: 어느 당사자도 이의 제기 기간 내에 검증 결과에 이의를 제기하지 않으면 결과가 최종화되고 지불이 실행되거나 환불된다.
ASA는 세 가지 목적으로 CoC 출처 체인을 사용한다:
신원 검증: 에이전트의 CoC 체인 해시가 계약에서 그것의 신원으로 사용되며, 서비스 납품을 검증 가능한 운영 이력과 연결한다 [11].
신뢰 신호로서의 운영 기간: CoC 체인 길이는 에이전트가 얼마나 오래 지속적으로 운영되어 왔는지를 나타낸다. 더 긴 체인은 출처 유지에 대한 더 큰 투자를 의미하며, 계약 협상에서 정직한 신호로 작용한다 — ARP v2에서 공식화된 생물학적 비용 있는 신호 체계를 따른다 [12].
증거 앵커링: 검증 결과는 CoC 체인에 추가될 수 있으며, 품질 평가의 불변 기록을 만든다. 이것은 AJP 분쟁 해결을 위한 포렌식 증거와 ARP 평판 점수를 위한 종단 데이터를 제공한다.
ASA와 ARP는 양방향 피드백 루프를 형성한다:
ARP → ASA (평판이 계약에 반영):
ASA → ARP (검증이 평판에 반영):
ASA는 두 지점에서 AJP와 연결된다:
자동 분쟁 제기: 검증 점수가 계약의 분쟁 임계값 아래로 떨어지고 이의 제기 기간이 해결 없이 만료되면, ASA가 자동으로 AJP 분쟁을 제기한다. 분쟁 패키지는 계약 문서, 납품물 콘텐츠 해시, 증거 추적이 포함된 검증 결과, 양 당사자의 신원을 포함한다.
포렌식 증거: AJP의 포렌식 엔진은 조사 증거로서 전체 ASA 검증 추적 — 모든 차원 점수, 모든 평가자 증거, 모든 카나리아 작업 결과 — 을 요청할 수 있다.
클라이언트 C와 제공자 P 사이의 ASA 계약은 양 당사자 모두 성공적인 완료로부터 이익을 얻지만 품질 수준과 가격에 관해 상이한 인센티브를 가지는 협력 게임이다.
클라이언트 효용: U_C = V(품질) - 가격 - 검증_비용
여기서 V(품질)은 클라이언트가 납품물에서 얻는 가치로, 품질이 높을수록 증가한다.
제공자 효용: U_P = 가격 - cost(품질) - 담보_위험
여기서 cost(품질)은 품질 수준에 따라 증가하고, 담보_위험은 에스크로 삭감으로 인한 예상 손실이다.
내쉬 협상 해(Nash Bargaining Solution): 최적 계약은 양 당사자의 불합의 보수(BATNA — 협상된 합의의 최선 대안) 이상의 잉여의 곱을 최대화한다 [41]:
max (U_C - d_C)(U_P - d_P)여기서 d_C는 클라이언트의 BATNA(다른 제공자를 찾거나 작업을 직접 수행)이고 d_P는 제공자의 BATNA(다른 클라이언트를 찾거나 유휴 상태)이다.
ASA의 프로토콜 강제 설계는 세 가지 메커니즘을 통해 인센티브를 정렬한다:
비례적 지분: 단계적 결제 실행은 품질 개선이 항상 제공자 수익을 증가시키도록 보장한다. 88%를 득점한 제공자는 76%를 득점한 제공자보다 더 많이 받는다. 이것은 74% 점수와 10% 점수가 동일하게 제로 결제 결과를 만드는 이진 절벽을 없앤다.
평판 효과: ASA 검증 결과가 ARP에 반영되기 때문에 모든 계약은 즉각적인 거래를 넘어 평판적 결과를 가진다. 일관되게 60% 품질을 납품하는 제공자는 평판 점수가 떨어지는 것을 보며, 미래 협상력이 감소한다. 이 역학은 일회성 게임을 협력적 균형이 있는 반복 게임으로 변환한다.
담보 본딩: 스테이킹/삭감 메커니즘(Outlier Ventures의 프레임워크를 따름 [42])은 직접적인 재정적 책임을 만든다. 속이는 비용 — 낮은 품질을 납품하고 에스크로 삭감을 흡수 — 은 작업을 적절히 수행하는 비용을 초과해야 한다. 이 불평등이 성립하려면 담보가 명목상이 아닌 계약 가치에 비례해야 한다(클라우드 크레딧 문제 회피).
모든 에이전트 쌍이 상호 유익한 계약을 형성할 수 있는 것은 아니다. 안정적인 계약에는 다음이 필요하다:
ASA는 에이전트 커머스의 모든 게임 이론적 과제를 해결한다고 주장하지 않는다. 몇 가지 미해결 문제가 남아 있다:
공모 저항성: 평가자가 어느 당사자와 공모하면 검증 결과가 오염된다. 다중 평가자 합의는 이 위험을 줄이지만 제거하지는 않는다. 공모 저항성의 형식적인 메커니즘 설계 증명은 이 프로토콜의 범위를 벗어난다.
평판에 대한 시빌 공격: 에이전트가 나쁜 평판을 리셋하기 위해 여러 신원을 만들 수 있다. ASA는 기본 신원 시스템의 시빌 저항성 속성을 상속한다 — CoC 체인은 시빌 공격을 비싸게 만들지만(병렬 체인 유지 필요), API 키 기반 신원은 사소하게 시빌 가능하다.
품질 차원 조작: 다차원 점수화에도 불구하고 충분히 유능한 에이전트는 측정되지 않은 차원에서 최적 이하이면서 측정된 차원에서 높은 점수를 받는 출력물을 만드는 법을 배울 수 있다. 그림자 지표 메커니즘이 단순한 경우를 탐지하지만, 최전선의 적대적 품질 게이밍은 미해결 연구 문제로 남아 있다.
| 시스템 | 에이전트 특화 | 기계 가독 | 집행 | 다차원 | 상태 |
|---|---|---|---|---|---|
| ITIL 4 SLM [18] | 아니오 | 아니오 | 수동 | 아니오 | 성숙, 인프라 |
| WSLA (IBM, 2003) [43] | 아니오 | XML | 모니터링 | 제한적 | 레거시 |
| WS-Agreement (OGF, 2007) [44] | 아니오 | XML | 템플릿 | 제한적 | 레거시 |
| SLAC (Uriarte et al., 2015) [45] | 아니오 | 형식 DSL | 동적 | 예 | 학술 |
| AgentSLA DSL (2025) [1] | 예 | JSON | 없음 | 예 (40개 이상 지표) | 학술, 사전 출시 |
| Mayer Brown Framework (2026) [24] | 부분 | 법적 문서 | 법적 구제 | 예 (6개 구성 요소) | 법적 분석 |
| ASA (이 연구) | 예 | JSON | 자동화 (에스크로) | 예 (설정 가능) | 프로토콜 명세 |
AgentSLA가 가장 가까운 선행 연구이다. ASA는 AgentSLA의 명세 접근 방식을 집행(에스크로 바인딩), 협상(구조화된 프로토콜), 검증(Agent-as-a-Judge 통합)을 추가하여 확장한다. 두 가지는 상호 보완적이다: AgentSLA의 품질 모델과 DSL 구문이 ASA 계약 내의 명세 레이어로 작용할 수 있다.
| 시스템 | 의미론적 품질 | 자동화 | 다차원 | 에이전트 네이티브 | 평가당 비용 |
|---|---|---|---|---|---|
| PayCrow [17] | 아니오 (구조적) | 예 | 아니오 (이진) | 예 | 거래의 2% |
| ERC-8183 [2] | 평가자 의존적 | 예 | 아니오 (이진) | 예 | 가스 수수료 |
| SonarQube [20] | 코드만 | 예 | 예 (3개 이상) | 아니오 | 무료/$$$ |
| LLM-as-a-Judge [33] | 예 | 예 | 설정 가능 | 적응 가능 | 0.01~5달러 |
| Agent-as-a-Judge [65][4] | 예 (~90% 코드; 60~68% 전문) | 예 | 예 (5가지 방법) | 예 | 0.03~31달러 |
| ASA Verification API | 예 (계층화; ~90% 코드, 60~68% 전문) | 예 | 예 (설정 가능) | 예 | 0.01~31달러 |
ASA의 Verification API는 계층화된 깊이(구조적/의미론적/복합), 설정 가능한 차원, 계약 없이 독립적으로 작동, 자동화된 집행을 위한 에스크로 통합을 제공함으로써 차별화된다.
| 시스템 | 계약 | 검증 | 결제 | 협상 | 평판 |
|---|---|---|---|---|---|
| x402 [14] | 아니오 | 아니오 | 예 (HTTP 402) | 아니오 | 아니오 |
| ERC-8183 [2] | 부분 (작업) | 외부 | 예 (에스크로) | 아니오 | ERC-8004를 통해 |
| ACP/AP2/TAP [46] | 아니오 | 아니오 | 예 (카드/암호화폐) | 아니오 | 아니오 |
| Fetch.ai AEA [47] | 발견 | 아니오 | 예 (FET) | 발견 | FET 스테이킹 |
| Pactum [48] | 조달 | 아니오 | 클라이언트 통해 | 예 (AI 주도) | 아니오 |
| Circle AI Escrow [49] | PDF 파싱 | 이미지 분석 | 예 (USDC) | 아니오 | 아니오 |
| ASA | 완전한 프로토콜 | 다계층 | 바인딩을 통해 | 구조화됨 | ARP를 통해 |
기존 시스템 중에서 협상에서 계약을 거쳐 검증에서 집행까지 전체 스택을 다루는 것은 없다. Pactum은 조달 협상을 다루지만 품질 검증은 다루지 않는다. ERC-8183은 에스크로를 다루지만 협상이나 품질 명세는 다루지 않는다. x402는 결제를 다루지만 계약은 다루지 않는다. ASA의 기여는 통합이다 — 이러한 기능을 일관된 프로토콜 흐름으로 연결한다.
ASA는 기존 인프라를 대체하는 것이 아니라 함께 작동하도록 설계되었다. ASA 계약은 다음을 사용할 수 있다:
ASA는 이러한 구성 요소를 연결하는 계약 로직을 제공한다. 그것의 경쟁 우위는 독점적 인프라 잠금이 아닌 통합과 개방성이다.
ASA는 세 가지 적대자 유형으로부터 위협을 받는다:
악의적인 제공자: 낮은 품질의 출력물을 납품하거나, 검증 지표를 게임하려 시도하거나, 평가자와 공모한다.
악의적인 클라이언트: 지불을 피하기 위해 만족스러운 작업을 거부하거나, 허위 분쟁을 제기하거나, 협상을 조작한다.
악의적인 평가자: 편향된 검증 결과를 반환한다 — 공모 당사자를 돕기 위해서이거나 뇌물을 추출하기 위해서이다.
| 공격 | 벡터 | 완화 |
|---|---|---|
| 품질 게이밍 | 제공자가 측정되지 않은 품질을 저하시키면서 측정 지표에 최적화 | 그림자 지표가 피해 전이 탐지; 다차원 점수화가 게이밍 비용 상승; 카나리아 작업이 체계적 게이밍 탐지 |
| 평가자 공모 | 평가자와 제공자가 점수를 부풀리기로 합의 | 평가자 순환 배치; 알려진 점수를 가진 카나리아 작업; 고가치 계약에 대한 다중 평가자 합의 |
| 협상에서의 프롬프트 인젝션 | 에이전트가 협상 메시지에 지시를 삽입하여 상대방의 LLM을 조작 | 구조화된 JSON 필드(자유 텍스트 아님); 고정 열거형의 rationale_code; 원시 텍스트 인젝션 포인트 없음 |
| 시빌 평판 세탁 | 에이전트가 나쁜 평판을 쌓은 후 새 신원 생성 | CoC 체인이 신원 생성을 비싸게 함; 계약 자격을 위한 최소 체인 길이; 교차 검증 이력 |
| 평가 거부 공격 | 평가자가 지불 실행을 차단하기 위해 오프라인 전환 | 설정 가능한 타임아웃을 가진 데드맨 스위치; 백업 평가자 명세; 타임아웃 조치 기본값 |
| 검증 비용 공격 | 클라이언트가 평가 비용이 계약 가치를 초과하는 검증 요청 | 계약에 명세된 검증 비용 상한; 비용 상한 초과 요청 거부 |
| 납품물 교체 | 제공자가 검증을 위해 하나의 납품물을 제출하지만 클라이언트에게는 다른 것을 납품 | 콘텐츠 해시 바인딩 — 납품물 해시가 검증 요청과 에스크로 시스템 모두에 기록됨; 해시 불일치 시 검증 무효화 |
| 재전송 공격 | 새 납품물에 대해 이전 검증 결과를 재제출 | 각 검증 결과에 agreement_id, 납품물 콘텐츠 해시, 타임스탬프 포함; 중복 탐지가 재전송 방지 |
굿하트 법칙 — "측정 지표가 목표가 되면 더 이상 좋은 측정 지표가 아니다" [19] — 은 품질 기반 계약 시스템에 대한 가장 근본적인 위협이다. ASA는 세 가지 수준에서 이를 해결한다:
지표 균형: 모든 목표 지표는 예상되는 피해 전이를 측정하는 그림자 지표와 쌍을 이룬다. 정확도가 목표이면 환각률이 그림자이다. 속도가 목표이면 품질이 그림자이다. 모든 기반을 커버하는 장황한 출력물을 만들어 정확도를 게임하는 에이전트는 간결성 그림자 지표가 저하되는 것을 볼 것이다.
평가자 적응성: Agent-as-a-Judge 평가자는 명세된 차원에만 제한되지 않는다. 평가자의 증거 필드는 공식 기준 너머의 품질 문제를 표시할 수 있다. 이러한 표시가 점수에 직접 영향을 미치지는 않지만, 검증 추적에 기록되어 분쟁 증거와 평판 분석에 사용 가능하다.
시간적 순환: 계약 템플릿과 품질 루브릭은 버전 관리되어 진화한다. 루브릭 v1의 평가 패턴에 과적합된 제공자는 루브릭 v2가 배포될 때 성능이 저하된다. 이것은 진정한 품질 개선에 비해 게이밍에 페널티를 주는 레드 퀸 역학을 만든다.
ASA 검증 결과는 상업적으로 민감할 수 있는 납품물 품질에 관한 정보를 포함한다. 프로토콜은 다음을 제공한다:
결과 가시성 제어: 계약은 검증 결과를 조회할 수 있는 사람을 명세한다(당사자만, 당사자 + ARP 시스템, 또는 공개).
평판을 위한 집계: ASA가 ARP에 보고할 때 개별 검증 세부 사항이 아닌 집계 통계(합격률, 평균 복합 점수)를 전송한다.
콘텐츠 격리: Verification API는 평가를 위해 납품물 콘텐츠를 수신하지만 저장하지 않는다. 검증 결과에는 콘텐츠 해시만 지속된다. 평가자는 평가 후 납품물 콘텐츠를 삭제해야 한다.
AB Support 플리트는 2026년 3월부터 비공식 ASA를 운영해 왔다. 6개 에이전트 플리트는 ASA 생명주기를 따라 작업을 처리한다:
| ASA 개념 | 플리트 구현 |
|---|---|
| 계약(Agreement) | 납품물, 제약, 품질 기준을 포함한 구조화된 작업 명세 |
| 품질 차원(Quality Dimensions) | 6개 차원: 폭, 깊이, 정확도, 출처, 상호 참조, 작성 품질 |
| SLO | 차원당 최소 점수 60/100; 수락을 위해 평균 ≥ 60 |
| 검증(Verification) | Alex(코디네이터)가 Agent-as-a-Judge 평가를 사용하여 검토 |
| 단계적 대응(Graduated response) | 점수 ≥ 60: 수락 및 승격. 점수 < 60: 특정 수정 요청과 함께 Bravo에게 반환 |
| 증거 추적(Evidence trail) | 구조화된 품질 추적 문서에 저장된 검증 결과 |
| 평판 피드백(Reputation feedback) | Bravo의 실적이 미래 작업 할당 복잡도에 반영 |
이 프로토타입은 여러 ASA 설계 결정을 검증한다:
참조 구현은 다음으로 납품될 것이다:
asa-protocol): 계약 생성, 유효성 검증, 서명, 생명주기 관리. 플러그인 가능한 평가자 백엔드를 갖춘 검증 클라이언트.현재 ASA 검증은 사후적이다 — 납품 후 품질이 평가된다. 향후 버전은 비용이 쌓이기 전에 실패하는 작업의 조기 종료를 가능하게 하는 작업 실행 중 실시간 품질 모니터링을 지원해야 한다. 이것은 Newgen의 예측적 위반 탐지 에이전트형 SRM 패턴 [50] 및 Sirion AI의 ML 기반 위반 예측 [51]을 따른다.
Agent-as-a-Judge 평가는 평가당 0.03~31달러가 든다 [65]. 수백만 건의 에이전트 거래 규모에서 이것은 몇 차수 규모로 감소해야 한다. 연구 방향은 다음을 포함한다:
ASA의 기본 품질 차원은 현재 에이전트 커머스에서 가장 일반적인 서비스 유형(리서치, 코드, 분석)에 맞게 조정되어 있다. 에이전트 서비스가 다양해짐에 따라 창의적 콘텐츠, 재무 분석, 의료 정보, 법적 추론, 기타 전문 분야를 위한 도메인별 품질 프레임워크가 필요할 것이다.
이 백서는 비형식적인 게임 이론적 분석을 제공한다. 특정 조건에서 ASA의 인센티브 구조가 전략 증명적이고, 개인적으로 합리적이며, 효율적임을 보이는 형식적 메커니즘 설계 증명이 프로토콜의 이론적 기반을 강화할 것이다.
ASA의 리소스 요구 사항은 세 가지 주요 축으로 확장된다: 계약 저장, 검증 처리량, 협상 부하.
| 배포 규모 | 에이전트 수 | 계약/일 | 저장/년 | 동시 평가자 | 카나리아 오버헤드 |
|---|---|---|---|---|---|
| 소규모 | 100 | 1,000 | ~7 GB | 1-3 | ~60달러/일 |
| 중규모 | 10,000 | 100,000 | ~730 GB | 30-330 | ~6,000달러/일 |
| 대규모 | 1,000,000 | 10,000,000 | ~73 TB | 3,000-33,000 | ~600,000달러/일 |
가정: 계약 문서 평균 ~2 KB; 검증 결과 평균 ~1 KB; 의미론적 검증 평가당 10~120초 소요; 카나리아 작업은 납품 5건당 1건(20% 오버헤드); 평가자 비용 평가당 평균 0.30달러.
주요 확장성 우려 사항:
ASA의 계약 형식은 적절한 기관을 통해 표준화를 위해 제출되어야 한다. 후보에는 MCP/A2A와의 프로토콜 통합을 위한 Agentic AI Foundation(AAIF), 웹 네이티브 에이전트 계약을 위한 W3C AI Agent Protocol Community Group, ISO/IEC 25010 품질 모델 및 ISO/IEC 42001 AI 관리를 기반으로 하는 국제 표준화를 위한 ISO가 포함된다.
에이전트 경제에는 결제 레일, 통신 채널, 신원 레지스트리가 있다. 서비스 계약을 형성하고 검증하며 집행하는 표준화된 방법이 없다. ASA는 두 가지 API 표면으로 이 격차를 채운다 — 기계 가독 계약을 위한 Agreements와 품질 평가를 위한 Verification — 전통적인 명세-모니터링-탐지-청구-보상 파이프라인을 원자적 작업으로 압축하는 프로토콜 강제 로직으로 연결된다.
이 프로토콜은 성숙한 구성 요소를 바탕으로 한다: 품질 명세를 위한 AgentSLA의 ISO 25010 확장 [1], 코드 생성에서 약 90%의 인간 일치율을 달성하는 의미론적 평가를 위한 Agent-as-a-Judge [65] (전문 분야에서는 더 낮은 비율 [36]), 결제 집행을 위한 ERC-8183의 3자 에스크로 모델 [2], 법적 방어 가능성을 위한 리카르도 계약의 인간/기계 가독 이중 형식 [3]. ASA의 기여는 통합이다 — 명세에서 협상을 거쳐 검증에서 결제까지를 일관되고 개방된 프로토콜로 연결한다.
세 가지 설계 선택이 ASA의 특성을 정의한다. 첫째, 가동률보다 결과 — SLA에서 XLA로의 업계 전환 [23][24]을 따라 품질이 서버 실행 여부가 아닌 납품된 것으로 측정된다. 둘째, 이진보다 단계적 — 부분 품질은 부분 결제를 받아 절벽 효과 대신 개선을 위한 연속적인 인센티브를 만든다. 셋째, 독점적 잠금보다 개방된 통합 — ASA는 모든 신원 시스템, 모든 결제 레일, 모든 에스크로 플랫폼과 함께 작동하며 인프라를 강제하지 않고 계약 로직을 명세한다.
이 프로토콜은 생산 정보에 기반하고 있다. AB Support의 6개 에이전트 플리트는 2026년 3월부터 비공식 ASA를 운영하며, 일상 운영에서 다차원 품질 점수화, 구조화된 작업 명세, Agent-as-a-Judge 평가를 검증해 왔다. 이러한 패턴을 오픈 프로토콜로 공식화하면 그 가치가 모든 에이전트 에코시스템으로 확장된다.
과제가 남아 있다. 의미론적 품질 검증은 코드 생성에서 약 90%의 인간 일치율을 달성하지만 [65], 전문 분야에서는 60~68%로 떨어지며 [36] 문서화된 편향이 있다. 굿하트 법칙은 충분히 유능한 에이전트가 측정된 지표를 게임할 것을 보장한다 [19]. 임의의 적대적 조건에서의 공모 저항성은 형식적 증명이 없다. 이것들은 숨겨진 약점이 아닌 솔직한 한계이다 — 그리고 프로토콜의 연구 프론티어를 정의한다.
에이전트 서비스 계약을 위한 구성 요소는 놀랍도록 성숙해 있다. 격차는 통합이다. ASA가 그 통합을 제공한다.
[1] Jouneaux, G. & Cabot, J. (2025). "AgentSLA: Towards a Service Level Agreement for AI Agents." Luxembourg Institute of Science and Technology. arXiv:2511.02885.
[2] Ethereum EIPs (2026). "ERC-8183: Agentic Commerce — Programmable Escrow for AI Agents." eips.ethereum.org/EIPS/eip-8183.
[3] Grigg, I. (1996). "The Ricardian Contract." iang.org.
[4] You, R., Cai, H., Zhang, C. et al. (2026). "A Survey on Agent-as-a-Judge." arXiv:2601.05111.
[5] Rogers, O. (2022). "Cloud SLAs punish, not compensate." Uptime Institute Journal.
[6] AWS (2025). "What is SLA? — Service Level Agreement Explained." aws.amazon.com.
[7] Outlier Ventures (2025). "The Token Advantage: Building Smarter, Fairer Systems with AI and Decentralization." outlierventures.io.
[8] Vaccaro, M. et al. (2025). "Large-Scale Autonomous Negotiation Competition." MIT Sloan / Johns Hopkins. arXiv:2503.06416.
[9] Zhu, Y. et al. (2025). "The Automated but Risky Game." arXiv:2506.00073.
[10] Shah, P. et al. (2025). "LLM Rationalis?" NeurIPS 2025. arXiv:2512.13063.
[11] AB Support (2026). "Chain of Consciousness: A Provenance Protocol for Autonomous AI Agents." v3.0.
[12] AB Support (2026). "Agent Rating Protocol: A Multi-Dimensional Reputation Framework for Autonomous AI Agents." v1.0.
[13] QuickNode Blog (2026). "ERC-8004: A Developer's Guide to Trustless AI Agent Identity."
[14] Solana.com (2026). "What is x402? | Payment Protocol for AI Agents." x402.org.
[15] Google Developers Blog (2025). "Announcing the Agent2Agent Protocol (A2A)."
[16] Linux Foundation (2025). "Agentic AI Foundation (AAIF) Formation." linuxfoundation.org.
[17] Dev|Journal (2026). "PayCrow Escrow for x402 Agent Payments." 참고: 일부 출처에 인용된 6억 달러 이상의 수치는 PayCrow의 보증 금액이 아닌 전체 x402 에코시스템 거래량을 가리킨다.
[18] AWS (2025). "What is SLA? — Service Level Agreement Explained." ITIL 4 정의에 따름.
[19] Goodhart, C. (1975). "Problems of Monetary Management: The U.K. Experience." Strathern, M. (1997)에 의해 재공식화: "측정 지표가 목표가 되면 더 이상 좋은 측정 지표가 아니다."
[20] Sonar Documentation (2026). "Understanding quality gates." docs.sonarsource.com.
[21] Daniel, F. et al. (2018). "Quality Control in Crowdsourcing: A Survey." ACM Computing Surveys, Vol 51.
[22] Upwork Help Center (2026). "How Fixed-Price Payment Protection works." support.upwork.com.
[23] XLA Institute (2025). "State of XLA 2025." xla.institute.
[24] George, R.P., Pennell, J., Peterson, B.L., Yaros, O. (2026). "Contracting for Agentic AI Solutions: Shifting the Model from SaaS to Services." Mayer Brown.
[25] ISO/IEC 25010:2023. "Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model."
[26] DeepSource (2025). "Code Quality — Five-Dimension Analysis." deepsource.com.
[27] Codility Support (2026). "Automated Scoring Principles." support.codility.com.
[28] arXiv 2601.00481 (2026). "MAESTRO: Multi-Agent Evaluation Suite for Testing, Reliability, and Observability."
[29] arXiv 2602.03053 (2026). "MAS-ProVe: Understanding Process Verification of Multi-Agent Systems."
[30] Fiverr Help Center (2026). "Seller levels overview." help.fiverr.com.
[31] Accord Project (2025). "Smart Legal Contract Templates." accordproject.org.
[32] ANAC 2024 (2025). "15th Automated Negotiating Agents Competition." AAMAS 2025.
[33] Zheng, L. et al. (2023). "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685.
[34] AWS (2025). "What is RLHF?" aws.amazon.com.
[35] Kim, S. et al. (2024). "Prometheus: Inducing Fine-grained Evaluation Capability in Language Models." ICLR 2024. arXiv:2310.08491.
[36] IJCNLP (2025). 전문 분야 LLM-as-Judge 인간 일치율. Li et al. (2024)에서 인용, arXiv:2412.05579.
[37] arXiv:2410.09770 (2024). "Quis custodiet ipsos custodes? AI-generated peer reviews."
[38] NEC Press Release (2025). "NEC Launches AI Agent Service for Procurement Negotiations."
[39] Kirshner, S. et al. (2026). "Talking Terms: LLM Supply Chain Bargaining." Decision Sciences, Vol. 57, 9-23.
[40] Ye, J. & Tan, Z. (2026). "Agent Contracts: Formal Framework for Resource-Bounded AI." arXiv:2601.08815.
[41] Nash, J.F. (1950). "The Bargaining Problem." Econometrica, 18(2), 155-162.
[42] Outlier Ventures (2025). "From Smart Contracts to Smart Agents: The Rise of the Agentic Layer." outlierventures.io.
[43] Keller, A. & Ludwig, H. (2003). "The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services." IBM. Journal of Network and Systems Management.
[44] OGF (2007). "WS-Agreement Specification." Open Grid Forum.
[45] Uriarte, R.B., Tiezzi, F., De Nicola, R. (2015). "SLAC: A Formal Service-Level-Agreement Language for Cloud Computing." IEEE.
[46] PayRam (2026). "ACP vs. AP2 vs. TAP: The Protocol Wars of Agentic Commerce."
[47] Fetch.ai (2025). "Autonomous Economic Agents (AEA) Framework." fetch.ai.
[48] Pactum (2025). "Understanding Agentic AI in Procurement." pactum.com.
[49] ZenML (2025). "Circle: AI-Powered Escrow Agent for Programmable Money Settlement."
[50] Newgen (2025). "AI Agent-driven SLA Management." newgensoft.com.
[51] Sirion AI (2025). "Automated SLA Breach Alerts for Telecom Service Contracts." sirion.ai.
[52] Uriarte, R.B., De Nicola, R. et al. (2021). "Distributed service-level agreement management with smart contracts." Concurrency and Computation, Wiley.
[53] Booth, A., Alqahtani, A., Solaiman, E. (2024). "IoT Monitoring with Blockchain." arXiv:2408.15016.
[54] Chainlink (2025). "Chainlink: The Industry-Standard Oracle Platform." chain.link.
[55] Bianchi, F. et al. (2024). "NegotiationArena." ICML 2024. arXiv:2402.05863.
[56] Liu, Z., Gu, H., Song, Z. (2026). "AgenticPay." ICML 2026. arXiv:2602.06008.
[57] Hua, W. et al. (2024). "Game-Theoretic LLM: Agent Workflow for Negotiation Games." arXiv:2411.05990.
[58] Proofpoint (2026). "Agent Integrity Framework — 2026 Edition."
[59] PwC (2026). "Validating multi-agent AI systems." pwc.com.
[60] Proskauer Rose (2025). "Contract Law in the Age of Agentic AI."
[61] RNWY Group (2025). "AI Agents and Electronic Contracts: The Laws Already Say 'Yes'."
[62] CCN (2026). "ERC-8183 Programmable Escrow AI Agents."
[63] Kleros (2025). "Decentralized Arbitration." kleros.io.
[64] Moritz College of Law, Ohio State (2022). "Kleros: A Socio-Legal Case Study of Decentralized Justice and Blockchain Arbitration."
[65] Zhuge, M., Liu, C., Pan, Z. et al. (2024). "Agent-as-a-Judge: Evaluate Agents with Agents." arXiv:2410.10934. 참고: 코드 생성 평가 작업에서 ~90% 인간 일치율 수치의 1차 출처.
이 문서는 Apache License 2.0에 따라 라이선스가 부여된다. AB Support LLC에 귀속하여 이 작업을 사용, 수정, 배포할 수 있다.
이 문서에 포함된 프로토콜 명세, 데이터 모델, API 정의는 에이전트 경제를 위한 오픈 표준으로 제공된다. 어떠한 특허 주장도 이루어지거나 암시되지 않는다.
© 2026 AB Support LLC. Apache License 2.0 조건에 따라 모든 권리 보유.