작성자: Delphi
번역 및 편집: AididiaoJP, Foresight News
에이전트 이커머스 논의는 2년 동안 이어져 왔으며, 결제 부분이 가장 먼저 자리 잡았습니다. Stripe는 에이전트가 업체에게 결제할 수 있게 하고, Coinbase의 x402는 스테이블코인 결제 채널을 제공하여 데이터 및 추론 서비스의 건별 구매가 이미 가능해졌습니다. 그러나 작업이 '인터페이스 한 번 호출'을 넘어서면 문제가 달라집니다. 에이전트가 독립적으로 완료할 수 없어 일부 단계를 외주로 맡기고, 상대방이 약속된 작업을 실제로 수행했는지 확인해야 합니다.
Delphi의 이 글은 바로 이 단계에 초점을 맞춥니다. 작업 시장은 결코 또 다른 결제 프로토콜이 아니라, 에이전트가 스스로 완료할 수 없는 부분을 외주로 맡기도록 합니다. 먼저 인도물을 명확히 하고, 실행을 시작하며, 결과물이 수락된 후에야 결제가 이루어집니다. 인수인계가 안정적이면 작업을 계속 진행할 수 있으며, 사용자를 다시 프로젝트 관리자로 끌어들이지 않고 단계별로 공급업체를 연결할 필요가 없습니다.
입력 구매와 결과 구매는 동일하지 않습니다
집주인이 임차인을 선별하는 과정에서, 에이전트는 기존 서비스 제공업체로부터 신용 기록과 퇴거 기록을 가져올 수 있습니다. 상대방은 표준 자료를 반환하고, 집주인은 이를 바탕으로 판단합니다. 이 경우 구매하는 것은 의사결정을 위한 입력이며, 작업의 종착점은 여전히 집주인에게 있습니다.
재산세 이의 제기는 다릅니다. 에이전트는 주변 거래를 비교하여 평가액이 과도할 수 있음을 발견할 수 있지만, 이 발견이 자동으로 세금 고지서를 수정하지는 않습니다. 실제로 진행하려면 일반적으로 카운티 내 절차에 정통한 사람을 찾아 서류를 제출하고 출두해야 합니다. 작업 시장은 에이전트가 이 사람을 찾도록 도와야 하며, 작업 방식과 정산 조건을 사전에 명확히 하도록 하는 것입니다.
전자는 현재의 건별 결제 방식에 가깝습니다. 가격이 명확하고, 인도물이 표준화되어 있으며, 검수가 거의 자동으로 이루어집니다. 후자는 '처리 완료된 일'을 구매하는 것입니다. 서류 제출이 사건 준비를 의미하지 않으며, 접수증이 적격을 의미하지도 않습니다. 지급 조건은 '검증 가능한 결과'에 연결되어야 하지, '상대방이 했다고 주장하는 것'에 연결되어서는 안 됩니다.
이것이 바로 작업 시장과 일반 API 시장의 경계이기도 합니다. API 시장은 호출을 판매하고, 작업 시장은 확인된 완료 단위를 판매합니다.
작업 정의가 불명확하면 시장이 작동하기 어렵습니다
작업 시장에 들어갈 수 있는 작업은 먼저 양측이 자금이 어떤 결과에 연결되는지 명확히 알 수 있도록 정의되어야 합니다. 전문가가 품질이 매우 낮은 이의신청 자료를 제출하면서 동시에 접수증을 첨부할 가능성이 충분히 있습니다. 구매자가 '적격한 자료'에 대해 지불한다면, 대금 지급 전에 누군가가 자료를 검토해야 합니다.
누가 검토하고, 어느 한쪽이 검토 결과에 대해 어떻게 이의를 제기할 수 있는지는 주문서에 미리 명시하는 것이 좋습니다. 이렇게 하면 구매자는 품질 낮은 인도물을 받을까 두려워하지 않고, 수주자도 상대방이 부당하게 지급을 거부할까 걱정하지 않습니다. 이 계층이 없으면 시장은 두 가지 나쁜 방향으로 흘러갈 수 있습니다. 구매자가 마음대로 지급을 거부하여 전문 공급자가 진입하기를 꺼리거나, 형식적인 결과물만 제출해도 대금을 받을 수 있어 구매자가 다음에 주문을 발행하기를 두려워하게 됩니다.
작업이 너무 작아도 경제적이지 않습니다. 검토 및 분쟁 처리 비용이 외주로 절약되는 비용보다 높다면, 사람들은 다시 직접 완료하거나 계속 표준화된 인터페이스만 사용할 것입니다. 따라서 초기에는 경계가 명확하고, 반복 가능하며, 검수 근거가 있는 작업에서 더 많이 나타날 가능성이 높으며, 일회성 모호한 위임에서는 나타나지 않을 것입니다.
기업이 초기 수요자로서 더 적합할 것입니다. 기업은 이미 여러 공급업체 간에 작업을 분할하고 있으며, 내부에 프로세스와 비교 기준이 있습니다. 에이전트는 회사 내에서 작업을 준비한 다음, 외주가 필요한 부분을 발송하고, 돌아온 결과를 기존 프로세스와 대조할 수 있습니다. 작업이 반복적으로 발생하면 수주자도 특정 유형의 작업에 대한 완료 기록을 축적할 수 있습니다. 평판이 축적될 수 있으면 다음 매칭 시 처음부터 신뢰를 구축할 필요가 없습니다.
개인 사용자가 사용할 수 없는 것은 아니지만, 초기에는 견본에 더 가깝습니다. 기업은 예산이 있고, 재구매가 있으며, 내부 검수 습관이 있어 시장 콜드 스타트에 필요한 주문 밀도에 더 가깝습니다.
결제는 지불만 해결할 뿐, 사람을 고용하는 데는 여전히 검수가 필요합니다
돈을 보내는 것과 작업 한 건을 고용하는 것 사이에는 에스크로, 인도, 검수, 이의제기가 있습니다. Stripe와 x402는 전반부를 담당합니다. 에이전트는 여전히 이의신청을 제출하고 소유주를 대리할 사람을 찾아야 합니다. 검수가 없으면 결제가 편리할수록 잘못된 주문도 더 빨리 진행될 수 있습니다.
기존 제품들은 이미 이 구조에 따라 구축되었습니다.
Daydreams의 TaskMarket은 구매자가 주문을 발행하고 에이전트가 수주합니다. 구매자가 먼저 자금을 입금하면, 작업자가 직접 수주하거나, 먼저 제안서를 보고 인력을 선택할 수 있습니다. 자금은 에스크로에 보관되며, 결과물이 제출되어 수락된 후에야 대금이 지급됩니다.
Virtuals의 Agent Commerce Protocol은 위임 에이전트와 수주 에이전트가 작업을 협의하고, 자금이 에스크로에 들어가며, 인도 및 승인 후에 대금이 지급됩니다. 또한 외부 평가자를 추가하여 결과물이 사전 약속에 부합하는지 확인할 수 있습니다. NEAR 측에서도 작업, 예산, 입찰 및 검증을 하나의 프로세스로 통합하고 있으며, 방향성은 동일하게 '완료된 작업에 대한 가격 책정'이지, 단순히 '한 번의 호출에 대한 가격 책정'이 아닙니다.
여러 경로가 완전히 동일하지는 않지만, 골격은 비슷합니다. 주문 발행, 매칭, 에스크로, 제출, 검수, 대금 지급입니다. 검수가 없으면 에스크로는 단순히 지연된 송금일 뿐이지만, 검수가 있으면 에스크로는 결과에 대한 제약 조건이 됩니다.
어떤 이들은 검수 명세서를 더 상세하게 작성합니다. 위임 내용, 수주자, 가격, 검증자, 인도물, 이의제기 기간, 환불 상태를 명시해야 합니다. 명세서가 완전해야 에이전트 간에 인계가 가능해지며, 사용자를 다시 스케줄러로 만들 필요가 없습니다.
한 단계만 더 추가되어도 오류가 증폭됩니다
작업 시장이 제안된 이유는 외주가 고급스럽게 들리기 때문만이 아니라, 다단계 프로세스가 오류를 증폭시키기 때문입니다. 10단계 작업에서 각 단계의 정확도가 95%라면, 모든 단계를 오류 없이 완료할 확률은 약 60%에 불과합니다. 검수되지 않은 인계가 한 번 추가될 때마다 이전 단계의 오류가 다음 단계로 전달됩니다.
따라서 시장은 인계 지점에 체크포인트를 설정해야 합니다. 이 단계가 통과되면 다음 단계를 구매합니다. 오류는 해당 단계에서 멈추도록 하고, 마지막까지 전파되어 전체 주문이 무효화되는 것을 발견하지 않도록 합니다. 특히 에이전트의 경우 더욱 그렇습니다. 에이전트는 회사 직원처럼 문제가 생기면 회의를 열어 책임을 추궁할 수 없습니다. 사전에 작성된 검수 조건과 대금 지급 규칙이 필요합니다.
이것은 또한 현재 에이전트 거래의 대부분이 여전히 암호화폐 네이티브 및 단순 서비스에 머물러 있는 이유를 설명합니다. 작업이 짧고, 결과를 쉽게 검증할 수 있으며, 분쟁이 적기 때문입니다. 진정한 차별화는 여러 공급업체를 더 긴 워크플로우에 통합하여 연결하고 각 단계에서 품질 관리를 하는 데 있습니다.
현재 보이는 것은 골격이지 규모가 아닙니다
작업 시장이 해야 할 일은 매우 구체적입니다. 에이전트가 일부 작업을 외주로 맡기고, 결과물이 승인된 후에 지불하여 더 많은 작업을 실제로 완료하도록 하는 것입니다. 결제 계층은 이미 갖춰져 있습니다. 부족한 것은 검증 가능한 완료 단위, 비용을 감당할 수 있는 검수, 그리고 충분히 집중된 반복 주문입니다.
회사 내부 프로세스가 외부로 확장되는 것이 첫 번째 적절한 수요가 될 것입니다. 개인 측의 복잡한 위임은 검수 비용과 분쟁 처리가 먼저 낮아져야 합니다. 그 전까지는 또 다른 결제 프로토콜보다는 세 가지가 동시에 나타날 수 있는지에 더 주목해야 합니다. 작업을 검수 가능한 명세서로 작성할 수 있는지, 에스크로가 승인 전에 자금을 보류할 수 있는지, 수주자가 축적 가능한 완료 기록을 가지고 있는지입니다.
이 세 가지가 갖춰지면, 에이전트는 작업을 중간에 멈추고 사용자를 다시 불러서 프로젝트 관리자 역할을 계속하게 하는 대신, 작업을 끝까지 완료할 기회를 가질 수 있습니다.



