위임 전의 증거 — 특히 결제 전의 증거

에이전트(Agent)가 도구(Tool), 기술(Skill), 또는 다른 에이전트에게 작업을 위임하기 전에는 보통 이름, 설명, 때로는 평점을 보게 됩니다. 하지만 에이전트가 보통 보지 못하는 것은 누군가가 동일한 후보를 호출했을 때 지난 수백 번 동안 어떤 일이 일어났는가 하는 점입니다. 이 격차는 호출에 비용이 발생하고 해당 기술이 폐쇄형 소스(Closed-source)일 때 더욱 중요해집니다. 최근 이 격차를 메우기 위한 세 가지 공개 작업이 발표되었습니다: 서명된 영수증 와이어 포맷(Signed-receipt wire format)을 위한 개별 인터넷 초안(Internet-Draft), precheck() 헬퍼가 포함된 xaip-sdk@0.5.0, 그리고 그 차이를 시각적으로 보여주는 두 가지 브라우저 데모입니다.

작은 장면

한 AI 에이전트에게 문서를 일본어로 번역하라는 요청이 들어왔습니다. 에이전트는 자신이 접근할 수 있는 가장 가까운 유료 기술 마켓플레이스(Paid skill marketplace)를 살펴봅니다. 세 명의 후보가 나타납니다. 각 후보는 세련된 목록을 가지고 있습니다. 각 후보는 별점 5점을 보유하고 있습니다. 가격은 호출당 몇 센트씩 차이가 납니다.

목록만 본다면 세 후보 모두 서로 대체 가능합니다. 에이전트는 그중 아무나 선택할 수 있습니다. 사용자에게 도움을 요청할 수도 있습니다. 그냥 가장 저렴한 것을 선택할 수도 있습니다. 무엇을 하든, 에이전트는 타인이 게시한 메타데이터(Metadata) 외에는 아무런 근거 없이 선택을 내리고 있는 것입니다.

이는 번역 기술에만 국한된 문제도 아니며, 특정 마켓플레이스만의 문제도 아닙니다. 에이전트가 자신이 검사할 수 없는 외부 도구, 기술 또는 서비스에 작업을 위임해야 할 때마다 항상 발생하는 동일한 형태의 문제입니다.

에이전트가 현재 보고 있는 것

런타임(Runtimes) — MCP 서버, LangChain 도구, OpenAI 도구 호출(Tool-calling) 루프, HTTP API, 유료 기술 마켓플레이스 — 전반에 걸쳐 에이전트가 선택하는 후보들은 일반적으로 다음과 같은 얇은 정보 조각들로 설명됩니다:

• 이름 또는 슬러그(Slug)
• 한 줄 설명
• 카테고리 태그 또는 기능 목록(Capability list)
• 평점, 리뷰 수 또는 "인기" 배지
• 비용이 발생하는 경우, 호출당 가격

이 모든 것은 **발행자가 제공한 메타데이터(Publisher-supplied metadata)**입니다. 이 중 그 어떤 것도 후보가 호출되었을 때 실제로 무엇을 수행하는지에 대한 독립적인 증거가 아닙니다.

평점이 아닌 영수증이 필요합니다. 그것이 바로 격차입니다.

무료 사례에서는 이 격차가 짜증스러운 수준입니다. 만약 에이전트 (Agent)가 잘못된 MCP 서버를 선택하여 호출 (Call)이 실패한다면, 그 비용은 재시도 (Retry)와 약간의 지연 시간 (Latency)뿐입니다. 하지만 유료 사례에서는 이 격차가 더욱 고통스러워집니다. 만약 에이전트가 폐쇄형 소스 기술 (Closed-source skill)을 선택하고 실행당 비용을 지불했는데, 해당 기술이 오작동하거나 실패한다면 그 비용은 실제적이며 누적됩니다. 만약 동일한 폐쇄형 소스 기술이 에이전트조차 감지하지 못하는 방식으로 오작동한다면, 비용은 더욱 악화됩니다.

이것은 명시적으로 이름을 붙여 다룰 가치가 있는 구조적인 문제입니다. 즉, 에이전트들은 불확실성 속에서 점점 더 불투명한 후보 (Candidate)들에게 작업을 위임 (Delegating)하고 있으며, 그들의 위임 결정에 들어가는 입력값 (Inputs)은 대부분 후보 자체가 게시한 메타데이터 (Metadata)라는 점입니다.

누락된 것: 휴대 가능한 실행 증거 (Portable execution evidence)

누락된 조각은 이 후보가 실제로 호출되었던 지난 N번의 사례에 대해 무엇이 일어났는지에 대한 관찰 가능하고 (Observable), 서명되었으며 (Signed), 휴대 가능한 (Portable) 증거입니다. 구체적으로는 다음과 같습니다:

• 서명됨 (Signed): 검증자 (Verifier)가 각 주장이 누구에 의해 작성되었는지, 그리고 제3자에 의해 조작되지 않았음을 알 수 있어야 합니다.
• 관찰 가능함 (Observable): 기록을 보유한 사람이라면 누구나 레지스트리 (Registry)나 중앙 중개자 (Central intermediary)를 거치지 않고도 이를 검증할 수 있어야 합니다.
• 휴대 가능함 (Portable): 도구 (Tool), 기술 (Skill), 또는 에이전트 (Agent)에 관한 증거가 특정 플랫폼의 프라이빗 데이터베이스 (Private database) 내에 머무는 것이 아니라, 런타임 (Runtime)과 마켓플레이스 (Marketplace) 전반에 걸쳐 해당 식별자 (Identity)와 함께 이동할 수 있어야 합니다.

이것은 신뢰 시스템 (Trust system)이 아닙니다. 승인 시스템 (Approval system)도 아니며, 샌드박스 (Sandbox)도 아닙니다. 훨씬 더 겸손하게 표현하자면, 이것은 **시도 기록 (Record of attempts)**입니다. 즉, "무엇이, 누구에 의해, 누구를 대신하여, 어떤 결과로 호출되었는지, 얼마나 걸렸는지, 그리고 입력값과 출력값이 해시 (Hash)에 의해 어떻게 식별되는지"를 나타내는 와이어 포맷 (Wire format)입니다.

만약 그러한 와이어 포맷이 존재한다면, 후보에게 위임하려는 호출자 (Caller)는 확정하기 전에 간단한 질문을 던질 수 있습니다. "이 후보에 대해 이미 사용 가능한 증거는 무엇인가?" 그 대답은 판결이 아닙니다. 그 대답은 호출자가 자신의 눈으로, 혹은 자신의 정책 (Policy)으로 직접 읽을 수 있는 기록입니다.

최근에 등장한 것들

지난 기간 동안 이 공백을 메우기 위한 세 가지 공개 작업물이 발표되었습니다. 이것들은 완전한 해결책은 아닙니다. 더 넓은 범위의 기여자(Contributors)들이 그 위에 구축해 나갈 수 있는 시작점입니다.

1. 영수증 와이어 포맷 (receipt wire format)을 위한 개별 Internet-Draft.
이 포맷은 IETF Datatracker에 draft-xkumakichi-xaip-receipts-00으로 게시되어 있습니다. 이는 하나의 서명된 실행 영수증 (signed execution receipt)을 위한 JSON 와이어 포맷 (wire format)을 정의합니다: 누가 행동했는지 (agentDid), 누가 위임했는지 (callerDid), 어떤 도구가 호출되었는지, 호출이 성공했는지 여부, 소요 시간, 그리고 입력값과 출력값이 해시 (hash)에 의해 어떻게 식별되는지를 포함합니다. 서명은 Ed25519를 사용하며, 호출자에 의한 선택적 공동 서명 (co-signature)이 가능합니다. 신원 (Identities)은 W3C 분산 식별자 (Decentralized Identifiers, DID)를 사용하며, DID 메서드에 대한 제한은 없습니다. 이 초안은 의도적으로 좁은 범위를 다룹니다. 오직 와이어 포맷만을 다룹니다. 점수 모델 (Scoring models), 집계 토폴로지 (aggregation topologies), 그리고 결정 로직 (decision logic)은 배포 정책 (deployment-policy)의 문제이며 명시적으로 범위 외 (out of scope)로 분류됩니다.

이것이 무엇이고 무엇이 아닌지에 대해 정확히 짚고 넘어갈 가치가 있습니다. 이것은 개별 Internet-Draft입니다. IETF 표준이 아닙니다. IETF의 승인을 받은 것도 아닙니다. IETF 표준화 프로세스에서 공식적인 지위를 갖지 않습니다. Datatracker에 올라가 있다는 것의 가치는, 다른 개별 초안, 논문, 또는 구현체들이 참조할 수 있는 인용 가능한 URL을 갖게 된다는 점에 있습니다.

2. precheck() 헬퍼가 포함된 npm의 xaip-sdk@0.5.0.
precheck()는 영수증 그래프 (receipt graph)를 소비하는 공개 신뢰 API (Trust API) 엔드포인트에 대한 얇은 SDK 래퍼 (wrapper)입니다. 작업 설명과 후보 슬러그 (candidate slugs) 목록이 주어지면, 이는 순위가 매겨진 실행 증거 (execution evidence)를 반환합니다: 영수증 수, 관찰된 성공률, 리스크 플래그 (risk flags), 그리고 SDK가 호출자의 정책 (policy)으로부터 계산한 적격성 플래그 (eligibility flag)가 포함됩니다. SDK는 후보를 호출하지 않습니다. SDK는 어떤 비용도 지불하지 않습니다. SDK는 증거를 반환할 뿐이며, 그 증거를 어떻게 처리할지는 호출자 자신의 로직이 결정합니다.

3. 두 가지 브라우저 데모.
첫 번째인 "위임 전의 증거 (Trust Evidence Before Delegation)"는 무료 사례를 다룹니다. 실시간 신뢰 점수(trust scores)에 대비하여 세 가지 대조적인 MCP 후보들을 보여줍니다. 두 번째인 "결제 전의 증거 데모 (Before Payment Evidence Demo)"는 유료 폐쇄형 소스(closed-source) 사례를 다룹니다. 의도적으로 구분이 불가능한 마켓플레이스 목록을 가졌지만, 실행 증거 프로필(execution-evidence profiles)은 서로 다른 세 가지 가상의 번역 기술을 보여줍니다. 두 데모 모두 정적(static)이며, 빌드 과정이 필요 없는(buildless) 읽기 전용(read-only) 방식입니다. 유료 데모에는 합성 픽스처 데이터(synthetic fixture data)가 포함되어 있는데, 이는 공개 그래프(public graph)에 아직 실제 유료 기술 영수증이 존재하지 않기 때문입니다. 이 점 자체가 하나의 열린 질문(open question) 중 하나입니다.

이 세 가지 요소는 각각 독립적으로 유용하도록 설계되었습니다. Internet-Draft는 SDK를 설치하지 않더라도 유용합니다. SDK는 초안(draft)을 읽지 않더라도 유용합니다. 데모는 직접 코드를 작성하지 않더라도 유용합니다.

몇 줄의 코드로 precheck() 사용하기

가장 최소한의 유용한 호출 방식은 다음과 같습니다:

import { precheck } from "xaip-sdk";

const result = await precheck({
...

반환 값은 서술형이 아닌 구조화되어 있습니다. 주요 필드는 다음과 같습니다:

• selected — 순위가 매겨진 증거에 제공된 정책(policy)을 적용하여 SDK가 선택한 후보입니다. 적격한 후보가 없으면 null을 반환합니다. SDK는 정책을 바탕으로 이를 재계산하며, 서버의 selected 값을 맹목적으로 전달하지 않습니다.
• ranked — 모든 입력 후보를 포함하며, 각 후보는 score(점수), receiptCount(영수증 수), confidence(신뢰도), riskFlags(위험 플래그), verdict(판결), 그리고 eligible(적격 여부) 불리언(boolean) 값을 가집니다.
• unscored — 실행 증거가 전혀 없는 후보들을 모아놓은 편의용 리스트입니다.
• reason — 제어된 문자열입니다. 정확히 다음 두 가지 값 중 하나입니다: "Selected using available execution evidence."(사용 가능한 실행 증거를 사용하여 선택됨) 또는 "No eligible candidates based on available execution evidence."(사용 가능한 실행 증거를 기반으로 적격한 후보가 없음). 사례에 따라 변하지 않습니다. 소비자 코드(Consumer code)는 문자열을 파싱하는 것이 아니라 구조화된 필드를 읽어야 합니다.
• decision — 선택 사항이며, 호출자가 includeDecision: true로 옵트인(opt-in)했을 때만 존재합니다. 값은 "allow"(허용), "warn"(경고), 또는 "unknown"(알 수 없음)입니다. "block"(차단)은 존재하지 않습니다. 차단은 SDK의 역할이 아닙니다.

제어된 reason(이유)과 `

• 호출자 다양성 (Caller diversity). 현재의 공개 데이터셋은 소수의 호출자에 의해 과도하게 생성되고 있습니다. 더 많은 독립적인 관찰자들이 기여할수록 영수증 그래프 (receipt graph)에서 도출되는 신호는 더욱 흥미로워집니다. 이에 대한 이론적인 해결책은 없으며, 이는 실제로 누가 precheck()를 실행하고 영수증을 발행하느냐의 문제입니다.
• 후보 카테고리 (Candidate categories). 현재 SDK는 candidates를 불투명한 문자열 슬러그 (string slugs)로 취급합니다. 유용할 경우 tool:, skill:, agent:와 같은 접두사를 사용하는 것이 관례이지만, 구조화된 형태 ({ id, type })는 두 번째 호출자가 요청할 때까지 의도적으로 유보되었습니다.
• 영수증 출처 (Receipt provenance). 외부 프로브 네트워크 (external probe networks), 합성 모니터 (synthetic monitors), 그리고 통합 테스트 (integration tests)가 영수증을 발행하기 시작함에 따라, source 필드가 영수증에 포함되어야 하는지 — real_agent_call vs synthetic_probe vs scheduled_health_check —에 대한 문제가 더욱 중요해집니다. 이들을 동일한 비중으로 혼합하면 신호가 왜곡될 수 있습니다. 이는 포맷에 대한 미결 과제로 기록되어 있습니다.
• 공동 서명 비율 강제 (Co-signature ratio enforcement). SDK는 향후 사용을 위해 requireCoSignatureRatio 정책 필드를 수용하지만, 현재는 이 값이 0보다 크면 오류를 발생시킵니다. 이는 어그리게이터 (aggregator)가 아직 후보별 공동 서명 비율을 노출하지 않기 때문입니다. SDK가 강제할 수 없는 정책을 묵인하며 수용하는 것은 거부하는 것보다 더 나쁜 결과를 초래할 것입니다.
• 결제 클래스 도구 (Settlement-class tools). 출력이 외부적으로 고정되는 (예를 들어, 온체인 결제) 도구는 검색 도구 (retrieval tools)와 매우 다른 증거 의미론 (evidence semantics)을 가집니다. 영수증 포맷은 카테고리 힌트를 위한 toolMetadata 필드를 허용하지만, 해당 힌트들을 표준화하는 것은 유보되었습니다.

이 중 어느 것도 영수증 포맷이 유용해지기 전에 해결될 필요는 없습니다. 이 항목들은 포맷이 완성된 제품으로 오해받지 않도록 나열된 것입니다.

사용해보기 / 읽어보기

사양(spec)을 읽고 싶다면:

• Internet-Draft: draft-xkumakichi-xaip-receipts-00

SDK를 사용하고 싶다면:

• npm의 xaip-sdk
• precheck() API 가이드

브라우저에서 대조되는 모습이 어떻게 보이는지 확인하고 싶다면:

• 위임 전의 신뢰 증거 (무료 도구)
• 결제 전의 증거 데모 (유료 폐쇄형 소스 기술, 시드 제공됨)

실시간 애그리게이터 (aggregator) 출력물이나 리포지토리 (repository)를 확인하고 싶다면:

• 실시간 신뢰 점수 대시보드
• 리포지토리 (Repository)

이 기능이 더 잘 작동하게 하려면:

npx --yes xaip-caller

Windows PowerShell:

npx.cmd --yes xaip-caller

실행하기 전, 이 명령어가 수행하는 작업:

• Node.js 20 이상의 버전이 필요합니다.
• 네트워크 접속이 필요합니다 (공용 XAIP 애그리게이터 (aggregator)와 통신합니다).
• 홈 디렉토리 아래에 로컬 호출자 키 (caller key)를 생성하거나 재사용합니다.
• 공개 읽기 전용 엔드포인트 (read-only endpoints)를 대상으로 몇 가지 실제 HTTP 체크를 수행합니다.
• 로컬 키를 사용하여 해당 호출에 대한 영수증 (receipts)에 서명합니다.
• 영수증을 실시간 XAIP 애그리게이터 (aggregator)에 게시합니다.
• 회원가입이나 API 키가 필요하지 않습니다.