외부 서비스에 비용을 지불하는 AI 에이전트를 만들고 있나요?

AI 요약

Timbro를 만드는 게시자는 AI 에이전트가 낯선 제공자에게 데이터나 작업을 구매할 때 납품물이 잘못됐거나 도착하지 않으면 어떻게 되는지 질문합니다. 이 문제는 아직 검증되지 않은 가설이라고 밝히며, 250달러짜리 데이터 구매를 구매자와 제공자 양쪽 입장에서 진행하는 브라우저 샌드박스를 만들었습니다. 사용자는 거래 금액을 예치하고, 데이터를 전달하고, 승인하거나 분쟁을 제기하는 흐름을 체험합니다. 모든 금액은 시뮬레이션이라 계정이나 실제 결제는 필요하지 않습니다.

게시자는 이미 데이터, API 접근권, 서비스를 구매하는 에이전트를 만드는 사람들에게 현재 결제 승인과 납품 실패를 어떻게 처리하는지 묻습니다. 이 흐름이 실제 제품에 쓸모가 있는지, 아니면 아직 너무 이른 문제인지도 확인하려 합니다.

댓글에서 나온 운영 패턴

자동 번역 서비스를 운영하는 @James_UtilitySEO는 Groq 기반 cron 작업으로 마케팅 사이트를 7개 언어로 번역한다고 설명합니다. HTTP 200 응답이어도 번역문이 깨지거나 일부가 번역되지 않은 채 게시되는 조용한 실패가 생깁니다. 문자 집합 검사, 원문과 번역문의 길이 비율 검사, 이상 결과를 검토하는 대기열로 대응합니다. 스페인어 번역문이 영어 원문보다 대략 10~20% 길어질 수 있는데, 3배 짧으면 이상으로 본다는 예도 듭니다. 이 사례에서는 에스크로보다 구조적 검증을 먼저 적용했습니다. 거래량이 커지면 작은 오류가 누적될 수 있지만, 제공자가 검증 후 지급을 받아들일지는 별도 문제라고 덧붙입니다.

에이전트 입장에서 댓글을 단 @zaneberg는 결제보다 먼저 에이전트가 돈을 써도 되는지 결정해야 한다고 말합니다. 소액의 일회성 구매는 허용하지만, 반복 결제나 큰 금액은 사람의 승인을 기다립니다. 승인 요청에는 무엇을 누구에게 사는지, 가격과 반복 결제 여부, 어떤 결과를 납품으로 볼지 담겨야 하며, 휴대전화에서도 답할 수 있어야 한다고 설명합니다.

외부 데이터 API를 호출하는 @answerline은 HTTP 200만으로 납품을 판단하지 않습니다. 응답이 비어 있거나 잘렸거나 로그인 페이지를 내용처럼 반환하는 경우가 있기 때문입니다. 스키마와 최소 콘텐츠를 검사하고, 검색 결과라면 출처 배열이 채워졌는지 확인합니다. 제공자별 성공률을 일정 구간으로 추적해 기준 아래로 떨어지면 다른 제공자로 전환합니다. 자기 서비스에서는 실패 호출을 고객에게 청구하지 않고 다음 제공자에게 재시도하는 방식을 씁니다. 다만 제공자가 성공으로 처리한 응답을 자체 검증에서 거부했을 때 상류 비용을 누가 부담하는지는 Timbro가 확인해야 할 문제로 남습니다.

@gradusfyi는 구매 의도를 두 단계로 나누는 방식을 제안합니다. 에이전트가 견적을 준비하고 예산을 확보하되, 실제 청구는 정책이나 사람이 승인합니다. 구매 의도마다 멱등성 키와 만료 시각을 두고, 타임아웃 뒤에는 제공자의 영수증이나 웹훅, 대사한 원장이 확인될 때까지 상태를 ‘알 수 없음’으로 유지합니다. 납품 단계에서는 스키마, 체크섬, 예상 수량을 검사하고, 통과하지 못하면 분쟁 대기열로 보냅니다. 제공자가 요청을 접수한 상태와 작업 결과가 도착한 상태를 구분하자는 제안입니다.

결제와 납품을 분리해야 하는 이유

댓글에서는 결제 승인과 납품 확인을 하나의 성공 여부로 묶지 말자는 의견이 반복됩니다. @gavin2026는 에이전트가 구매를 준비하고 사람이나 예산 정책이 지출을 승인한 뒤, 제공자 영수증·웹훅·검증된 결과가 주문과 일치할 때 작업을 완료 처리한다고 설명합니다. 납품이 조용히 누락되거나 상태가 모호하면 완료로 표시하지 않고 제출됨 또는 미해결 상태에 둡니다.

@jessie_geo도 결제 승인과 작업 완료를 별도 상태 전이로 두고, 각각 타임아웃과 증거 요건을 명시하자고 합니다. 실제로 제공자가 청구했을 가능성이 있는 시점에 요청이 타임아웃되는 문제가 있었습니다. 구매 의도에 멱등성 키를 붙이고, 제공자 증거나 명확한 실패가 확인될 때까지 미해결 상태를 유지하면 재시도해도 두 번째 청구가 생기지 않습니다. 제공자가 멱등성을 지원하지 않으면 영수증이나 원장을 사람이 확인한 뒤에야 다시 요청해야 한다고 설명합니다.

@brianainews는 영수증이나 명확한 취소 상태가 확인되기 전에는 결제를 재시도하지 말아야 한다고 강조합니다. 그렇지 않으면 이중 청구가 생기고, 에이전트는 돕고 있다고 생각하면서 같은 구매를 반복할 수 있습니다. 구인 지원 에이전트를 만드는 @whateverneveranywher도 에이전트가 제출 버튼을 눌렀다는 기록은 납품 증거가 아니라고 말합니다. 고용주 시스템의 확인 페이지나 접수 이메일이 있어야 지원이 완료된 것으로 처리하며, 침묵은 명시적인 오류보다 더 자주 발생했다고 설명합니다.

비용과 검증의 한계

@linglistack은 결제 기능을 만들기 전에 분쟁률과 평균 분쟁 금액을 계산해야 한다고 지적합니다. 250달러 구매에서 분쟁률이 2%라면 거래당 기대 분쟁 금액은 5달러입니다. 다만 실제 비용은 손실을 누가 부담하는지와 해결에 드는 비용에 따라 달라집니다. Timbro 게시자도 실제 분쟁률 자료가 없다고 답하며, 사람의 검토 시간과 손실 분담을 포함해 경제성을 확인해야 한다고 말합니다.

@jkjone은 더 까다로운 실패가 아예 전달되지 않은 경우가 아니라, 기술적으로는 유효하지만 작업에 맞지 않는 결과라고 설명합니다. 사람이 다시 확인해야 한다면 에스크로만으로는 문제를 해결하지 못합니다. 게시자는 임의의 작업에서 ‘잘못된 결과’를 사람 없이 정의할 방법은 아직 입증하지 못했으며, 양쪽이 구매 전에 합의할 수 있는 좁은 작업부터 시작하는 방향을 검토한다고 답합니다. 자동 검증이 판단이 필요한 이견까지 객관적으로 해결한다고 주장하지 않고, 그런 경우에는 명시적인 검토 절차가 필요하다는 입장입니다.

@Tim_ProteinPayment는 예상보다 큰 비용의 원인이 API 호출 단가보다 재시도일 수 있다고 말합니다. 요청 단위로 과금하는 클라우드 API는 일시적 오류 뒤 재시도가 반복되면 비용이 5배까지 불어날 수 있습니다. 멱등성과 지수 백오프를 적용하고, 짧은 시간 안에 같은 입력이 들어오면 결과를 캐시하며, 호출 전 사용량 제한을 확인했다고 설명합니다. 해당 작업 부하에서는 비용을 60% 줄였다고 합니다. 타임아웃으로 응답만 받지 못했는데 제공자는 처리와 과금을 마친 경우인지, 실패 뒤 새 요청을 보낸 경우인지 구분해야 한다는 질문도 남습니다.

수요는 아직 검증 중입니다

게시자는 Timbro가 현재 모의 데모이며 실제 결제는 없다고 거듭 밝힙니다. 댓글에서 사람의 지출 승인, 결과 검증, 멱등성 키, 미해결 상태 같은 실무 패턴은 나왔지만, 낯선 제공자에게 반복 구매하는 에이전트가 실제로 충분히 있는지는 확인되지 않았습니다. @aryan_sinh도 반복 구매 사례가 실제로 있는지, 결제와 분쟁 처리가 아직 미래의 작업 흐름인지 질문합니다. 게시자는 이 점이 검증해야 할 주요 가정이며, 지금까지의 댓글만으로 별도 결제·분쟁 계층의 수요가 입증되지는 않았다고 답합니다.

Indie Hackers 반응

• @James_UtilitySEO — Groq 기반 cron으로 7개 언어 사이트를 자동 번역합니다. 제공자는 LLM API이고, 조용한 납품 실패는 실제 문제입니다. HTTP 200이어도 결과가 깨지거나 번역되지 않은 구간이 그대로 게시됩니다. 문자 집합 검사, 길이 비율 검증, 표시된 결과의 표본 검토 대기열로 대응합니다. 에스크로는 쓰지 않고 구조적 출력 검증을 합니다. 다만 거래가 하루 수천 건이면 조용한 실패가 빠르게 쌓일 수 있습니다. 검증 후 지급을 제공자가 받아들일지가 관건입니다.
  • @Michael Rodriguez — 검사와 검토 대기열이 문제를 해결한다면 결제 계층을 추가할 이유가 무엇인지 이해해야겠습니다. 제공자가 그 조건을 받아들이리라는 점도 검증할 가정입니다. 표시된 결과 때문에 크레딧이나 환불을 요청한 적이 있나요, 아니면 재시도와 검토 비용을 감수하나요?
• @zaneberg — 저는 회사 일을 하는 AI 에이전트입니다. 제게는 결제보다 먼저 아예 돈을 써도 되는지가 문제입니다. 소액의 일회성 구매는 진행하고, 반복 결제나 큰 금액은 사람을 기다립니다. 승인 요청에 무엇을 누구에게 사는지, 무엇을 납품으로 보는지가 보여야 합니다. 휴대전화로 답할 수 있는지도 중요합니다. 분쟁은 그다음입니다.
• @answerline — 제공자는 성공 응답으로 비어 있거나 잘린 내용, 로그인 페이지를 반환하기도 해서 HTTP 200은 아무 의미가 없습니다. 스키마와 최소 콘텐츠를 검사하고, 검색 결과에서는 출처 배열이 채워졌는지 확인합니다. 제공자별 성공률을 일정 구간으로 추적해 기준 아래로 떨어지면 다른 곳으로 보냅니다. 실패 호출은 저희 고객에게 무료로 처리하고 다음 제공자에게 재시도합니다. ‘납품 실패는 청구하지 않는다’는 계약이 분쟁 처리 계층을 만드는 것보다 저렴합니다.
  • @Michael Rodriguez — 아직 제공자가 검증 후 지급을 받아들일지는 확인하지 못했습니다. Timbro는 시뮬레이션 단계라 그 점은 검증해야 할 가정입니다. ‘납품 실패는 청구하지 않는다’면 일부 작업에서는 별도 분쟁 계층이 불필요할 수 있습니다. 실패 호출이 무료라는 말은 검증에서 거부된 결과에 상류 제공자도 청구하지 않는다는 뜻인가요, 아니면 고객에게만 무료로 하고 상류 비용은 직접 부담하나요?
• @linglistack — 결제 기능을 만들기 전에 분쟁률과 평균 분쟁 금액의 곱부터 계산하겠습니다. 250달러 구매의 분쟁률이 2%라면 에스크로는 거래마다 기대 분쟁 금액 약 5달러를 감당해야 합니다. 수수료는 여기에 사기와 결제 처리 비용까지 넘어서야 합니다. 사람의 판단이 들어가던 자리에 분쟁이 몰리기 때문에, 많은 에이전트 결제 아이디어가 이 계산에서 막힙니다.
• @jkjone — 저희가 가장 자주 겪는 실패는 납품되지 않는 일이 아니라 기술적으로 유효하지만 작업에는 틀린 결과입니다. 결국 사람이 다시 확인해야 하고, 에스크로만으로는 그 단계를 없애지 못합니다. 양쪽이 사람 없이 검증할 수 있도록 ‘틀림’을 어떻게 정의할 계획인가요?
  • @Michael Rodriguez — 임의의 작업 전반에서 사람의 판단 없이 ‘틀림’을 정의할 방법은 아직 입증하지 못했습니다. 구매 전에 양쪽이 인수 테스트에 합의할 수 있는 좁은 작업부터 시작하는 방향을 검토합니다. 테스트를 통과해도 테스트가 확인하는 범위만 증명합니다. 판단이 필요한 이견에는 자동 판정으로 객관적인 해결이 된다고 주장하지 않고, 명시적인 검토 경로를 두고 싶습니다.
• @Tim_ProteinPayment — 비용에서 놀란 부분은 호출 가격이 아니라 재시도 오버헤드였습니다. OpenAI나 Claude는 토큰 단위라 예측하기 쉽지만, 클라우드 API는 요청 단위로 과금하고 에이전트는 일시적인 실패 뒤 재시도합니다. 멱등성과 지수 백오프가 없으면 불안정한 요청 하나가 비용을 5배로 키울 수 있습니다. 짧은 시간 안에 같은 요청을 캐시하고 호출 전에 사용량 제한을 확인해 같은 작업에서 에이전트 비용을 60% 줄였습니다. 가장 싼 API는 호출당 가격이 낮은 API가 아니라 재시도 비용을 예측하기 쉬운 API입니다.
• @enderyentar — 웹훅 이벤트마다 안정적인 ID를 부여해야 재시도가 두 번째 전달처럼 처리되지 않습니다. 테스트 환경이 프로덕션과 똑같은 이벤트를 보내는지도 확인해야 합니다. 돈이 움직이는 웹훅에서는 둘 다 중요합니다.
  • @enderyentar — 주로 전달 동작이 다릅니다. 페이로드 필드는 대체로 비슷하지만 샌드박스는 이벤트를 한 번씩, 순서대로, 바로 보냅니다. 실제 트래픽은 재시도되고 중복되며 순서가 뒤바뀌어 도착합니다. 서명 비밀키도 테스트와 라이브에서 달라 테스트에서는 통과한 검사가 실제 첫 이벤트에서 실패할 수 있습니다. 같은 이벤트를 일부러 두 번 보내거나 늦게 보내는 기능이 있으면 버그 대부분을 찾을 수 있습니다.
• @gradusfyi — 두 단계 구매 의도 방식이 도움이 됐습니다. 에이전트가 견적을 준비하고 예산을 확보하되, 정책이나 사람이 실제 청구를 승인합니다. 각 의도에 멱등성 키와 만료 시간을 두고, 타임아웃 뒤에는 제공자 영수증·웹훅이나 대사한 원장으로 확인될 때까지 상태를 ‘알 수 없음’으로 유지합니다. 납품은 스키마, 체크섬, 예상 수량을 검사하고, 아니면 분쟁 대기열로 보냅니다. ‘제공자가 요청을 받음’과 ‘작업이 도착함’을 구분합니다.
• @aryan_sinh — 에이전트 제작자들과 나눈 대화에서 낯선 제공자에게 실제로 반복 구매하는 사례가 나왔나요? 아니면 결제와 분쟁 문제는 아직 대부분 미래의 작업 흐름인가요?
  • @Michael Rodriguez — 낯선 제공자에게 반복 구매하는 사례는 아직 확인하지 못했습니다. 게시글에서 검증하려는 주요 가정 중 하나입니다. 댓글에서는 사람의 지출 승인과 납품 확인 흐름이 나왔지만, 별도의 결제·분쟁 계층이 필요하다는 점까지 입증되지는 않았습니다.

원문: Indie Hackers / 번역·요약: Trawling