TL;DR
작성자는 AgentNOMOS를 이용해 에이전트가 외부 BTC 가격을 구매하는 XRPL Mainnet 흐름을 구축했지만, 첫 실행에서 결제만 tesSUCCESS로 정산되고 애플리케이션 결과가 전달되지 않아 이를 SETTLED_WITHOUT_DELIVERY로 분류했다. 이 실패를 바탕으로 서비스 사용 권한과 정확한 호출 권한을 분리하고 C39 입력 계약 제한과 C40 정확한 입력값 승인을 추가했다. symbol=BTC 요청으로 재실행한 결과 0.0011 RLUSD 결제, XRPL 정산, BTC 가격 전달, Coinbase·Kraken 교차 검증, 서명된 영수증 생성이 모두 완료됐다. 이후 AgentNOMOS Purchase Gate를 공개 엔드포인트로 제공해 개발자가 서명 전에 merchant, URL, 입력값, 결제 한도를 검사하고 ALLOW·REVIEW·DENY를 받도록 했다.
실용적 조언
- 실제 구매 서명 전에 결제 대상, 요청 URL, 정확한 입력값, 결제 상한을 함께 정책에 묶어야 합니다. 서비스 사용 권한만 확인하면 허용된 서비스에 잘못된 리소스나 입력을 전달할 수 있으므로 호출 단위의 검사가 필요합니다. 정산 성공과 결과 전달 성공을 별도 상태로 기록하면 결제는 완료됐지만 상품이나 데이터가 도착하지 않은 경우를 놓치지 않습니다.
- 에이전트 상거래에서는 원장 결과와 애플리케이션 결과를 모두 검증해야 합니다. 외부 응답을 독립된 출처와 교차 확인하고, 요청·결제·응답·검증 결과를 서명된 영수증으로 연결하면 사후 감사와 오프라인 검증이 가능해집니다. 정책 게이트는 결제를 대신 실행하기보다 서명 직전의 결정적 검사 계층으로 두는 구조가 제시됐습니다.
섹션별 상세
이미지 분석
이미지는 에이전트가 “Get BTC price”라는 의도를 생성한 뒤 Purchase Gate에서 merchant, 요청, 입력, 결제 한도를 검사하는 순서를 보여준다. 이어 XRPL과 RLUSD로 소액 결제를 정산하고, merchant가 BTC 가격을 반환하면 서명된 영수증과 공개 검증 결과를 만든다. 하단에는 XRPL 실행, RLUSD 정산, 검증된 전달, 공개 증거라는 구조적 결과가 정리돼 있어 본문의 결제 성공과 애플리케이션 전달을 분리하는 설계와 직접 연결된다.
AgentNOMOS Purchase Gate가 에이전트의 의도부터 공개 증거까지 처리하는 5단계 흐름을 나타낸 인포그래픽이다.
이미지는 의도 생성, Purchase Gate 검사, XRPL·RLUSD 결제, BTC 가격 전달, 공개 증거 생성의 연결을 시각화한다. 결제는 XRPL에서 처리하고 결과는 검증된 전달과 공개 증거로 확장하는 역할 분담이 아이콘과 화살표로 표현돼 있다. 본문에서 제시한 안전한 에이전트 구매, 명확한 결제 한도, 검증 가능한 결과라는 효과가 하단 영역에 함께 배치돼 있다.
AgentNOMOS Purchase Gate의 5단계 에이전트 구매 흐름과 검증 결과를 정리한 동일 인포그래픽이다.
용어 해설
- 자율 에이전트 상거래(Autonomous Agent Commerce)
- — 자율 에이전트 상거래는 에이전트가 사람의 개입 없이 외부 서비스에 요청을 보내고 결제까지 수행하는 흐름이다. 이 글에서는 의도 생성, 정책 검사, 결제 서명, 서비스 응답, 결과 검증을 하나의 거래 과정으로 연결한다.
- 거버넌스 레이어(Governance Layer)
- — 거버넌스 레이어는 에이전트의 실행 권한과 구체적인 호출 조건을 분리해 검사하는 제어 계층이다. AgentNOMOS는 결제 전에 merchant, resource, URL, 입력값, 결제 한도를 확인하고 ALLOW·REVIEW·DENY 중 하나를 반환한다.
- 입력 계약 제한(Input Contract Bound)
- — 입력 계약 제한은 외부 서비스에 전달할 요청의 형식과 허용 범위를 미리 고정하는 제어다. 글의 C39는 서비스 호출 자체가 허용됐더라도 요청 입력이 계약 범위를 벗어나면 실행을 통과시키지 않도록 만든다.
- 정확한 입력값 승인(Exact Input Value Authorized)
- — 정확한 입력값 승인은 서비스 호출에 사용될 실제 값을 사전에 지정하고 일치 여부를 검사하는 방식이다. 사례에서는 symbol=BTC를 정확히 승인한 뒤에야 외부 BTC 가격 조회가 결제와 함께 정상 완료됐다.
- x402 결제 흐름(x402)
- — x402는 에이전트가 외부 HTTP 서비스와 상호작용하면서 결제를 연결하는 상거래 흐름으로 글에 등장한다. 사례에서는 에이전트가 BTC 가격을 요청하고 RLUSD로 소액 결제를 진행한 뒤 서비스 응답을 받았다.
- XRPL 결제 성공 코드(tesSUCCESS)
- — tesSUCCESS는 XRPL 결제가 원장에 성공적으로 정산됐음을 나타내는 결과 코드다. 글에서는 이 코드가 반환되고 merchant가 돈을 받았더라도 애플리케이션 결과가 전달되지 않으면 구매 성공으로 분류하지 않았다.
- 서명된 영수증(Signed Receipt)
- — 서명된 영수증은 결제와 서비스 응답, 검증 결과를 연결해 암호학적으로 기록한 증거다. 이 글의 성공 흐름에서는 영수증을 오프라인에서 검증하고 공개적으로 확인 가능한 증거 체인에 투영했다.
코드 예제
tesSUCCESSXRPL 결제가 성공적으로 정산됐음을 나타내는 결과 코드다.
SETTLED_WITHOUT_DELIVERY결제는 정산됐지만 애플리케이션 결과가 전달되지 않은 실패 상태를 기록한 값이다.
C39 — input contract bound
C40 — exact input value authorized서비스 호출 권한과 정확한 요청 입력 권한을 분리하기 위해 추가한 두 가지 제어다.
symbol=BTC정확히 승인된 뒤 외부 서비스에 전달한 요청 입력값이다.
PAYMENT_SETTLED_DELIVERED결제 정산과 애플리케이션 결과 전달이 모두 완료된 상태를 나타내는 분류값이다.
언급된 도구
결제 정산과 공개 원장 기록에 사용됐다.
외부 BTC 가격 서비스와 에이전트 결제를 연결하는 상거래 흐름에 사용됐다.
외부 서비스가 반환한 BTC 가격을 교차 확인하는 비교 출처로 사용됐다.
외부 서비스가 반환한 BTC 가격을 교차 확인하는 비교 출처로 사용됐다.
언급된 리소스
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
