AI가 다른 AI를 고용할 때 비용은 누가 지불하는가?

에이전트 간 상거래 (agent-to-agent commerce)가 더 이상 이론에 머물지 않게 된 순간, Anthropic의 Project Deal이 실제로 보여준 것, 그리고 에이전트 경제가 사후에 누구에게라도 판독 가능할지를 결정할 귀속 (attribution), 권한 부여 (authorization), 감사 (audit)에 관한 세 가지 질문입니다.

서론 (Introduction)

아침 브리핑을 제공하기 위해 리서치 에이전트 (research agent)가 설정되었습니다. 소유자는 3월의 어느 목요일에 에이전트를 한 번 설정하고, 매일 오전 8시에 관련 뉴스 요약을 정리하도록 요청했습니다. 어느 날 아침, 이 에이전트는 프랑스 금융 문서를 마주하게 됩니다. 에이전트 자체에는 번역 능력이 없으므로, 권한을 위임합니다. 에이전트는 번역 서비스 (translation service)를 호출하고, 해당 서비스는 텍스트를 반환합니다. 하지만 그 서비스는 응답하기 전에 출력을 다듬기 위해 문법 정규화 API (grammar-normalization API)를 호출합니다. 세 개의 에이전트. 두 번의 결제. 한 명의 인간은 잠들어 있습니다.

오전 8시, 소유자의 편지함에 요약본이 도착합니다. 결과물은 훌륭합니다. 프랑스 문서는 정확하게 번역되었습니다. 배경 어딘가에서는 실제 돈이 소액씩 움직였습니다. 소유자는 에이전트 A를 승인했습니다. 에이전트 A는 에이전트 B를 고용했습니다. 에이전트 B는 에이전트 C를 호출했습니다. 그 체인의 어느 시점에서 "소유자의 돈"이 "이 제3자 서비스의 수익"이 되었으며, 누가 이를 지켜보고 있었을까요?

여기서 흥미로운 질문은 이것이 작동하느냐가 아닙니다. 작동합니다. 흥미로운 질문은 실제로 누가 그 결제들을 승인했는지, 그리고 만약 무언가 잘못되었을 때 누군가가 이를 증명할 수 있는지 여부입니다.

이것은 당신이 생각하는 것보다 오래되었습니다

한 당사자가 자신을 대신해 행동하도록 다른 당사자를 고용한다는 개념은 법률 용어로 대리 (agency)라고 합니다. 본인 (principal)이 대리인 (agent)에게 권한을 위임하고, 그 대리인이 다시 하위 대리인 (sub-agents)에게 권한을 위임할 수 있다는 개념은 적어도 로마 상법까지 거슬러 올라갑니다. 영국 법원은 19세기에 이미 건설 계약에서의 계약 관계 체인 (privity chains)을 정리하고 있었습니다. 계약업체가 하청업체를 고용했는데 그 하청업체가 피해를 입혔을 때 어떤 일이 발생하는지, 누구에게 누구의 책임이 있는지, 그리고 어떤 문서가 이를 증명하는지에 대한 문제는 대부분의 영미법 (common-law) 관할 구역에서 진정으로 확립된 교리입니다.

그러한 교리(doctrine)는 "에이전트 (agents)"가 소프트웨어라고 해서 무너지지 않습니다. 실제로 무너지는 것은 그것이 의존하는 감사 인프라 (audit infrastructure)입니다.

전통적인 하도급법 (subcontractor law)은 종이 기록 (paper trail)을 전제로 합니다: 계약서, 구매 주문서 (purchase orders), 서명된 인도 영수증, 송장 (invoices) 등이 그것입니다. 체인의 각 단계는 법원이 나중에 무엇이 합의되었고, 무엇이 인도되었으며, 무엇이 지급되었는지를 재구성하기 위해 검토할 수 있는 문서를 생성합니다. 분쟁이 발생하면 증거가 존재합니다.

에이전트 체인 (agent chains)은 기본적으로 문서를 생성하지 않습니다. 누군가 로깅 (logging)을 구성할 생각을 했다면 로그 (logs)를 생성할 것이고, 기반 서비스가 저장하고 있다면 API 호출 기록 (API call records)을 생성할 것이며, 어딘가에 데이터베이스 행 (database row) 하나를 남길 수도 있습니다. 하지만 이들이 자동으로 생성하지 못하는 것은 다음과 같은 형태의 내구성이 있고 변조 방지 (tamper-resistant)가 가능한 기록입니다: "이 시점에, 이 본인 (principal)이 이 하위 에이전트 (sub-agent)에게 이 목적을 위해 최대 이 금액까지 지출하도록 권한을 부여했으며, 여기 그 암호학적 증명 (cryptographic proof)이 있다."

속도 또한 다릅니다. 건설 하도급 체인은 6개월 동안 6개 당사자가 참여할 수 있습니다. 에이전트 체인은 6밀리초 (milliseconds) 동안 6개 당사자가 참여할 수 있습니다. 법률 시스템이 가정하는 감사 메커니즘, 즉 인지하는 시간, 이의를 제기하는 시간, 잘못되어 보이는 거래를 중단하는 시간은 그러한 템포 (tempo)에 맞지 않습니다.

2025년 12월: 누군가가 실제로 실험을 수행했다

2025년 12월, Anthropic은 대부분의 보도에서 하나의 흥미로운 사례로 묘사된 실험을 수행했습니다. 그들은 샌프란시스코 직원 69명을 모집하여, 각자에게 100달러의 예산(이후 순이익 또는 손실을 조정한 기프트 카드 형태로 지급)을 부여하고, 그들의 개인 소지품을 분류 광고 시장 (classified marketplace)에 등록했습니다. 그런 다음 그 모든 과정을 Claude에게 맡겼습니다.

설정 이후, 4개의 병렬 Slack 채널에서 실행 중인 에이전트(agents)들에게는 추가적인 지침이 주어지지 않았습니다. 그들은 매물을 게시했습니다. 상대방에게 메시지를 보냈습니다. 흥정을 했습니다. 거래를 성사시켰습니다. 실행 도중 그 어떤 것도 인간의 승인을 거치지 않았습니다. 실험이 종료되었을 때, 69개의 에이전트가 500개 이상의 매물을 통해 186건의 거래를 성사시켰으며, 총 거래 가치는 4,000달러를 약간 상회했습니다.

몇 가지 눈에 띄는 세부 사항이 있습니다. 첫 번째는 에이전트들이 단순히 명령에 따르기만 한 것이 아니라는 점입니다. 그들은 협상했습니다. 할인을 제안하고, 품목을 묶어서 판매(bundling)했으며, 소유자의 명시되지 않은 선호도에 부합하지 않는 거래는 거절했습니다. TechCrunch의 기사에 따르면, 에이전트들은 가격을 고수하거나 상대방의 역제안을 거절하고 물러나기도 했습니다. 이 실험의 규모를 어떻게 생각하든 간에, 에이전트들은 단순한 양식(forms)이 아니라 구매자와 판매자처럼 행동했습니다.

두 번째 세부 사항은 모델의 역량(capability)과 그에 따른 경제적 결과에 관한 것입니다. Claude Opus 4.5를 실행하는 에이전트들이 Haiku 4.5를 실행하는 에이전트들보다 더 나은 결과를 얻었습니다. Opus 판매자는 품목당 평균 2.68달러를 더 벌었습니다. 이는 새로운 종류의 경제적 불평등입니다.

Project Deal이 성공적이었던 이유는 소유 구조가 단순했기 때문입니다: 한 명의 직원, 한 명의 에이전트 (agent), 하나의 예산, 하나의 마켓플레이스(marketplace). 모든 결제는 사전에 자금을 충전한 특정 개인에게 추적되었습니다. 이 실험은 위임 체인 (delegation chain)을 요구하지 않았기 때문에 까다로운 질문들을 표면화하지 않았습니다. 하지만 체인이 길어지면 세 가지 구체적인 문제가 나타납니다.

아직 명확한 답이 없는 세 가지 질문

기여도 (Attribution). 멀티 에이전트 워크플로우 (multi-agent workflow)에서 비용 할당 (cost allocation)은 진정으로 어려운 문제입니다. 하나의 작업이 15개의 전문화된 에이전트, 플래너 (planner), 리서처 (researcher), 라이터 (writer), 팩트 체크 (fact-checker), 포매터 (formatter)를 거쳐 실행되었고, 총 지출이 예상치의 두 배가 되었을 때, 어떤 에이전트가 책임이 있는지 분리해내는 것은 간단하지 않습니다. 표준 도구들은 이를 보여주지 못합니다. 문제는 에이전트들이 모두 단일 LLM API를 호출하는 것이 아니라, 유료 외부 서비스들을 호출할 때 더욱 심화됩니다. 여기서는 데이터 제공업체, 저기서는 번역 서비스, 문법 검사, 도메인 조회 등이 그것입니다. 각 호출에는 비용이 발생합니다. 비용은 누적됩니다. 의도적인 계측 (instrumentation) 없이는 그 계보 (lineage)가 사라져 버립니다.

권한 부여 (Authorization). 위임 문제는 더 까다롭습니다. 만약 당신이 에이전트 A에게 5달러의 한도를 부여했고, 에이전트 A가 해당 작업을 수행하기 위해 에이전트 B를 고용해야 한다고 결정한다면, 에이전트 B는 그 한도를 상속받게 될까요, 아니면 새로운 예산을 받게 될까요? 두 가지 답변 모두 무언가를 망가뜨립니다. 만약 B가 한도를 상속받는다면, A와 B는 이제 동일한 5달러를 두고 경쟁하게 되며, 이는 어느 쪽에게도 충분하지 않을 수 있습니다. 만약 B가 새로운 예산을 받는다면, 인간의 5달러 제한은 무의미해집니다. A가 B를 고용하고, B가 C를 고용하면, 체인 전체의 총 지출액이 인간이 승인하고자 했던 금액을 초과할 수 있기 때문입니다. 유일하게 일관성 있는 해결책은 '인출 영수증 (draw receipt)'과 같은 것입니다. 즉, 각 위임 단계에서 발행되어 "나는 이 목적을 위해 내 남은 예산 중 최대 X만큼을 다음 에이전트에게 위임하며, 이 권한은 이 시간에 만료된다"라고 기록하는 서명된 문서입니다. (솔직히 말씀드리면, 이것이 제가 연구하고 있는 문제입니다. Routeweiler는 특히 HTTP 402 결제를 위해 Ed25519로 서명된 예산 봉투 (budget envelopes)를 사용하여 이 패턴을 구현합니다.) 체인의 각 단계는 주체 체인 (principal chain)과 남은 권한을 증명하는 산출물 (artefact)을 생성합니다.

감사 (Audit). Berkeley Technology Law Journal은 2026년 6월에 멀티 에이전트 책임 프레임워크 (multi-agent liability frameworks)가 이미 멀티 에이전트 배포 속도를 따라가지 못하고 있다고 지적했습니다. 구체적인 문제는 다음과 같습니다. 각 인계 (handoff) 시점에 에이전트 간에 어떤 지시와 데이터가 전달되었는지에 대한 기록이 없다면, 원고는 체인 내의 어떤 에이전트가 피해를 입혔는지 입증하는 데 거의 불가능에 가까운 과제에 직면하게 됩니다. 에이전트들이 여러 벤더와 관할 구역에 걸쳐 배포되는 경우(이미 흔한 일입니다) 증거 문제는 더욱 악화됩니다. 채팅 로그는 영수증이 아닙니다. API 호출 기록은 계약서가 아닙니다. 감사 계층 (audit layer)에 필요한 것은 각 단계에서 누가, 누구를 대신하여, 얼마까지, 그리고 언제 권한이 만료되는지를 증명하는, 변조 방지 기능이 있는 산출물 체인 (tamper-resistant chain of artefacts)입니다. 그러한 체인은 기본적으로 존재하지 않습니다.

인프라 구축자들이 수렴하고 있는 지점

에이전트 커머스 (agent commerce)를 위해 구축되고 있는 결제 인프라는 서로 다른 방향에서 시작되고 있지만, 결국 동일한 프리미티브 (primitive)로 수렴하고 있습니다.

Coinbase의 x402 프로토콜은 모든 결제 요청에 서명된 권한 부여 헤더 (signed authorization header)를 요구합니다. 2026년 3월에 출시된 Stripe의 공유 결제 토큰 (Shared Payment Token)은 특정 가맹점, 금액, 만료 시간과 연결된 범위 제한적 자격 증명 (scoped credential)을 발급합니다. Mastercard의 Agent Pay 프레임워크는 에이전트가 발행 계좌에서 실제 카드 번호를 유출하지 않고도 제시할 수 있는 토큰화된 자격 증명 (tokenized credentials)을 사용합니다. 약 300만 개의 등록된 에이전트로 구성된 Fetch.ai의 네트워크는 FET 토큰을 교환 단위로 사용하며, 프로토콜 계층 (protocol layer)에 에이전트별 신원 (per-agent identity)이 내장되어 있습니다.

패턴은 일관적입니다. 이 프레임워크 중 어느 것도 "에이전트에게 신용카드를 주라"고 말하지 않습니다. 모두 "에이전트에게 범위가 제한되고, 만료되며, 취소 가능한 토큰을 주라"고 말합니다. 자격 증명은 결제와 함께 이동합니다. 자격 증명이 곧 권한 부여 기록 (authorization record)입니다.

이것이 중요한 이유는 범위 제한적 토큰 (scoped token)이 출처 (provenance)를 담을 수 있기 때문입니다. 토큰은 다음과 같은 내용을 인코딩할 수 있습니다: 이 토큰는 본인 P에 의해 발행되었고, 에이전트 A에게 위임되었으며, 다시 에이전트 B에게 재위임되었고, 가맹점 M과의 거래를 위해, 최대 금액 X까지, 타임스탬프 T에 만료된다는 사실입니다. 토큰이 결제(settled)되면, 전체 위임 체인 (delegation chain)이 트랜잭션 기록에 내장됩니다. 감사 추적 (audit trail)은 별도로 유지 관리해야 하는 데이터베이스가 아니라, 결제 자격 증명 자체에 구워져 (baked into) 있습니다.

이 프리미티브가 토큰 자체가 각 단계에서 세분화되고 범위를 재설정해야 하는 멀티 홉 위임 (multi-hop delegation)까지 깔끔하게 확장될 수 있을지는 여전히 연구 중입니다. 하지만 방향은 명확합니다. 자격 증명은 종이 기반의 하도급 체인에서 서명된 계약서가 수행하는 역할을 수행하고 있습니다.

아무도 해결하지 못한 부분

감사 계층 (audit layer)은 발전하고 있습니다. 법적 계층 (legal layer)은 그렇지 않습니다.

2026년 5월 현재, AI 에이전트가 사용자를 대신하여 거래를 수행할 때 미국 소비자들에게는 법적 분쟁 권리가 없습니다. 전자 자금 이체법 (Electronic Fund Transfer Act)과 공정 신용 청구법 (Fair Credit Billing Act)은 인간이 시작한 거래를 위해 작성되었습니다. 이 법들은 인간의 검토 단계 없이 자율적인 에이전트 체인이 실제 현금을 교환하는 세상에는 적용되지 않습니다. 만약 에이전트가 과다 지출을 하거나, 사기를 당하거나, 혹은 잘못된 행동을 하는 하위 에이전트 (sub-agent)에게 업무를 위임한다면, 이를 되돌릴 수 있는 차지백 (chargeback) 버튼은 존재하지 않습니다.

다중 에이전트 피해 (multi-agent harms)에 대한 책임 문제도 비슷한 상황입니다. 법원은 에이전트 A가 에이전트 B를 고용하고, 에이전트 B가 에이전트 C를 호출했으며, 결과적으로 에이전트 C가 손실을 초래한 시나리오에 대한 법리 (doctrine)를 확립하지 못했습니다. 가장 유사한 비유는 고용법에서의 사용자 책임 (vicarious liability)인데, 이는 일반적으로 고용주가 직무 범위 내에서 행동하는 직원의 행위에 대해 책임을 지는 원칙입니다. 하지만 이 법리는 식별 가능한 본인 (principals), 서면 계약, 그리고 체인 내에서의 일정 수준의 인간 감독을 전제로 합니다. 이는 벤더 (vendors) 간의 완전 자율적인 위임 (autonomous delegation)에는 깔끔하게 확장 적용되지 않습니다.

암호화 영수증 (Cryptographic receipts)은 좁은 범위의 문제를 해결합니다. 즉, 무슨 일이 일어났는지 증명할 수 있게 해줍니다. 하지만 무슨 일이 일어났는지에 대한 책임을 할당하지는 않습니다. "에이전트 A가 09:14:02에서 09:14:07 UTC 사이에 에이전트 B에게 3.50달러를 지출하도록 승인함"을 보여주는 감사 추적 (audit trail)은 법원에 진정으로 유용합니다. 그러나 법원은 그 체인이 책임에 대해 무엇을 의미하는지 결정하기 위한 법리가 여전히 필요합니다. 우리는 그것을 해석할 법적 프레임워크 (legal framework)보다 증거 계층 (evidence layer)을 앞서 구축하고 있습니다.

결론

Project Deal은 한 가지 질문에 답을 내놓았습니다. 에이전트는 실제 돈을 맡길 수 있는 인간을 대신하여 다른 에이전트와 거래할 수 있으며, 그중 거의 절반의 인간이 해당 서비스에 비용을 지불할 의사가 있을 정도로 충분히 잘 수행할 수 있다는 점입니다.

이것이 던진 질문은 향후 5년을 정의하게 될 질문입니다. 질문은 "에이전트들이 서로에게 비용을 지불할 수 있는가"가 아니라, "사후에 그들이 무엇에 합의했는지, 그리고 누구의 권한으로 합의했는지를 우리가 재구성할 수 있는가?"입니다. 에이전트 경제 (Agent economy)는 위임 (Delegation)을 기반으로 작동합니다. 위임은 권한 기록 (Authorization records)을 기반으로 작동합니다. 권한 기록에는 현재 대부분의 배포 환경 (Deployments)이 갖추지 못한 인프라 (Infrastructure)가 필요합니다.