Delphi Digital: 결제 이후, 에이전트 경제의 다음 전장은 태스크 마켓

작성자: Delphi

편집: AididiaoJP, Foresight News

에이전트 커머스 논의는 2년째 이어지고 있으며, 결제 단계가 가장 먼저 현실화되었다. Stripe는 에이전트가 판매자에게 결제할 수 있게 했고, Coinbase의 x402는 스테이블코인 결제 채널을 제공하여 데이터 및 추론 서비스를 건당 구매하는 방식이 이미 작동하고 있다. 그러나 작업이 '인터페이스 한 번 호출'을 넘어서면 문제가 달라진다. 에이전트가 독립적으로 완료할 수 없어 일부 과정을 외주화해야 하고, 상대방이 합의된 작업을 실제로 완료했는지 확인해야 한다.

Delphi의 이 글은 바로 이 단계에 초점을 맞춘다. 태스크 마켓은 또 다른 결제 프로토콜이 아니라, 에이전트가 완료할 수 없는 부분을 외주화하는 곳이다. 먼저 결과물을 명확히 정의하고 실행을 시작하며, 결과물이 승인된 후에만 대금이 지급된다. 인계가 신뢰할 수 있다면 작업은 계속 진행될 수 있으며, 사용자를 프로젝트 매니저로 되돌려 공급업체를 단계별로 연결할 필요가 없다.

입력값 구매와 결과 구매는 다르다

집주인이 세입자를 선별할 때, 에이전트는 기존 서비스 제공업체에서 신용 기록과 퇴거 기록을 조회할 수 있다. 상대방은 표준 자료를 반환하고 집주인은 이를 바탕으로 판단한다. 이때 구매하는 것은 의사결정 입력값이며, 작업의 종착점은 여전히 집주인에게 있다.

재산세 이의신청은 다르다. 에이전트는 주변 거래 사례를 비교하여 평가액이 과도할 수 있음을 발견할 수 있지만, 이 발견이 자동으로 세금 고지서를 수정하지는 않는다. 실제로 진행하려면 보통 카운티 내 절차에 정통한 사람을 찾아 서류를 제출하고 출석해야 한다. 태스크 마켓은 에이전트가 이 사람을 찾도록 돕고, 작업 방식과 정산 조건을 사전에 명확히 해야 한다.

전자는 현재의 건당 결제 방식에 가깝다. 가격이 명확하고 결과물이 표준화되어 있으며 검수가 거의 자동으로 이루어진다. 후자는 완결된 일 자체를 구매하는 것이다. 서류 제출이 사건 준비 완료를 의미하지 않으며, 접수증이 합격을 의미하지도 않는다. 결제 조건은 '상대방이 했다고 주장하는 것'이 아니라 '검수 가능한 결과'에 연동되어야 한다.

이것이 태스크 마켓과 일반 API(애플리케이션 프로그래밍 인터페이스) 마켓의 경계이기도 하다. API(애플리케이션 프로그래밍 인터페이스) 마켓은 호출을 판매하고, 태스크 마켓은 확인된 완료 단위를 판매한다.

태스크 정의가 불명확하면 시장이 작동하기 어렵다

태스크 마켓에 진입할 수 있는 작업은 자금이 어떤 결과와 연동되는지 양측 모두 명확히 알 수 있도록 먼저 정의되어야 한다. 전문가는 품질이 매우 낮은 이의신청 자료를 제출하면서 접수증을 첨부할 수 있다. 구매자가 '합격 자료'에 대해 지불한다면, 대금 지급 전에 누군가 자료를 검토해야 한다.

누가 검토하고, 어느 쪽이 검토 결과에 이의를 제기할 수 있는지는 사전에 주문서에 명시하는 것이 좋다. 그래야 구매자는 불량 결과물을 받을까 봐 두려워하지 않고, 수주자는 부당한 지급 거절을 당할까 봐 두려워하지 않는다. 이 계층이 없으면 시장은 두 가지 나쁜 방향으로 흘러간다. 구매자가 임의로 지급을 거절하여 전문 공급자가 진입하지 않거나, 표면적인 결과물만 제출해도 돈을 받을 수 있어 구매자가 다음에 주문을 내지 않게 된다.

작업이 너무 작아도 효율적이지 않다. 검토 및 분쟁 처리 비용이 외주로 절약되는 비용보다 높으면 사람들은 다시 직접 처리하거나 표준화된 인터페이스만 계속 사용할 것이다. 따라서 초기에는 일회성 모호한 위임보다 경계가 명확하고 반복 가능하며 검수 근거가 있는 작업에서 나타날 가능성이 높다.

기업이 더 적합한 초기 구매자가 될 것이다. 기업은 이미 여러 공급업체 간에 작업을 분할하고 있으며, 내부적으로 프로세스와 대조 기준을 갖추고 있다. 에이전트는 회사 내에서 작업을 준비한 후 외주해야 할 부분을 발주하고, 돌아온 결과를 기존 프로세스와 대조할 수 있다. 작업이 반복적으로 발생하면 수주자도 특정 유형의 작업 완료 기록을 축적할 수 있다. 평판이 축적되면 다음 매칭에서 신뢰를 처음부터 구축할 필요가 없다.

개인 사용자가 사용할 수 없는 것은 아니지만, 초기에는 템플릿에 가깝다. 기업은 예산, 재구매, 내부 검수 습관을 갖추고 있어 시장 콜드 스타트에 필요한 주문 밀도에 더 가깝다.

결제는 지불만 해결할 뿐, 고용에는 검수가 빠져 있다

돈을 보내는 것과 작업 한 건을 외주하는 것 사이에는 에스크로, 전달, 검수, 이의 제기가 있다. Stripe와 x402는 전반부를 담당한다. 에이전트는 여전히 이의신청을 제출하고 소유자를 대리할 사람을 찾아야 한다. 검수가 없으면 결제가 편리해질수록 잘못된 주문도 더 빨리 진행될 수 있다.

기존 제품들은 이미 이 구조로 구축되어 있다.

Daydreams의 TaskMarket(태스크 마켓)은 구매자가 주문을 내고 에이전트가 수주한다. 구매자가 먼저 자금을 입금하면 작업자가 직접 청구하거나, 먼저 제안서를 검토한 후 사람을 선택할 수 있다. 자금은 에스크로에 보관되며, 결과물이 제출되고 승인된 후에만 지급된다.

Virtuals의 에이전트 Commerce Protocol은 위임자 에이전트와 수주자 에이전트가 작업을 협상하고, 자금이 에스크로에 들어가며, 전달 및 승인을 거친 후 지급된다. 외부 평가자를 추가하여 결과물이 사전 합의에 부합하는지 확인할 수도 있다. NEAR(블록체인 플랫폼) 측에서도 작업, 예산, 입찰, 검증을 하나의 프로세스로 통합하고 있으며, 방향은 동일하게 '완료된 작업에 대한 가격 책정'이지 단순 호출에 대한 가격 책정이 아니다.

몇몇 경로는 완전히 동일하지 않지만 골격은 비슷하다. 발주, 매칭, 에스크로, 제출, 검수, 지급. 검수가 없으면 에스크로는 단지 지연 이체일 뿐이고, 검수가 있어야 에스크로가 결과에 대한 구속력이 된다.

어떤 이들은 검수 문서를 더 상세히 작성한다. 위임 내용, 수주자, 가격, 검증자, 결과물, 이의 제기 기간, 환불 상태를 명시해야 한다. 문서가 완전할수록 에이전트 간 인계가 가능해지고, 사용자를 다시 조정자로 만들 필요가 없다.

한 단계만 더 거쳐도 오류는 증폭된다

태스크 마켓이 제안된 것은 단지 외주가 고급스럽게 들려서가 아니라, 다단계 프로세스가 오류를 증폭시키기 때문이다. 10단계 작업에서 각 단계의 정확도가 95%라면, 전체를 오류 없이 완료할 확률은 약 60%에 불과하다. 검수 없는 인계가 하나 늘어날 때마다 앞선 오류가 다음 단계로 이어진다.

따라서 시장은 인계 지점에 체크포인트를 설치해야 한다. 이 단계가 통과되면 다음 단계를 구매한다. 오류는 해당 단계에서 멈추고, 끝까지 굴러가 전체 주문이 무효가 되는 것을 방지한다. 특히 에이전트에게 중요하다. 회사 직원과 달리 문제가 생기면 회의를 열어 책임을 추궁할 수 없다. 사전에 작성된 검수 조건과 지급 규칙이 필요하다.

이는 현재 에이전트 거래가 대부분 암호화폐 네이티브 및 단순 서비스에 머물러 있는 이유도 설명한다. 작업이 짧고 결과 검증이 쉬우며 분쟁이 적다. 진정한 격차는 여러 공급업체를 더 긴 워크플로에 연결하고 각 단계에서 품질을 관리하는 데서 발생한다.

현재 보이는 것은 골격이지 규모가 아니다

태스크 마켓이 해야 할 일은 구체적이다. 에이전트가 일부 작업을 외주화하고, 결과물이 인정된 후에만 지불하여 더 많은 작업을 실제로 완료하게 하는 것이다. 결제 계층은 이미 갖추어져 있다. 부족한 것은 검증 가능한 완료 단위, 비용 효율적인 검수, 그리고 충분히 밀집된 반복 주문이다.

회사 내부 프로세스가 외부로 확장되는 것이 첫 번째 제대로 된 수요가 될 것이다. 개인 측의 복잡한 위임은 검수 비용과 분쟁 처리가 먼저 낮아지기를 기다려야 한다. 그 전에 주목할 것은 또 다른 결제 프로토콜이 아니라, 세 가지가 동시에 나타날 수 있는지 여부다. 작업이 검수 가능한 문서로 작성될 수 있는지, 에스크로가 승인 전에 자금을 보류할 수 있는지, 수주자가 축적 가능한 완료 기록을 가질 수 있는지.

이 세 가지가 갖추어져야 에이전트가 작업을 끝까지 완료할 기회를 얻을 수 있으며, 절반만 하고 사용자를 다시 불러 프로젝트 매니저 역할을 계속하게 하지 않을 수 있다.