에이전트가 미터링 데이터 API를 무인으로 실행할 때 보이는 것: 103개 병렬 실행, 35,342회 속도 제한 도달, 1,021개 결과

이번 주 dev.to에는 세 개의 게시물이 세 가지 관점에서 같은 점을 지적했습니다. 에이전트의 계획은 권한이 아니다: 예산이 소비를 제한하고, 감사 기록은 에이전트의 통제 밖에 있습니다. 당신의 에이전트가 지불했다고 해서 그것이 맞는 것은 아니다: 확정된 결제가 올바른 것을 의미하지는 않습니다. 그리고 제가 계속 인용하는 문구가 있는 DigitalOcean [추론(inference) 청구량 제한에 대한 노트](https://dev.to/digitalocean/how-do-i-cap-inference-billing-to-avoid-surprise-costs-from-idle-gpus-or-runaway-agents-1cbd]는 속도 제한이 지출을 늦추지만, 그것을 제한하지는 않습니다.

세 가지 모두 구매자(buyer)의 입장에서 작성되었습니다. 저는 에이전트에게 데이터를 판매하므로, 여기서는 소켓의 다른 쪽에서 같은 이야기를 들려드리겠습니다. 한 미터링 API의 로그에 기록된 내용으로, 구매자의 자동화가 이를 무인으로 실행한 하루였습니다.

공개 고지: 저는 Apify에서 b2bsearch Actor를 구축했습니다. 아래 로그는 그중 하나인 LinkedIn 전화번호 찾기의 것입니다. 이 도구는 프로필 URL 목록을 받아 기록된 경우 휴대폰 번호를 반환합니다. 발견된 번호당 미터링됩니다. 번호가 기록되지 않은 프로필은 그러하다고 표시되는 무료 행입니다.

그날

10월 9일, UTC 기준 오전 8시부터 11시 5분에 걸쳐 한 구매자의 API 키가 해당 Actor를 103회 실행했습니다. 각 실행은 약 1,000개의 프로필 URL을 포함했습니다. 이 실행들은 대기열에 쌓이지 않았습니다. 최고점에서는 열 개 또는 열한 개가 동시에 진행 중이었고, 가장 바쁜 분당 서비스는 그 하나의 키로부터 1,402개의 요청에 응답했습니다.

그 아침의 114,967개 요청이 반환한 내용은 다음과 같습니다:

실행당 발견된 공유(share)는 0.5%에서 1.6% 사이였습니다. 3일 전 같은 Actor와 동일한 키를 사용했을 때, 다른 구매자가 1,000개의 US 프로필을 보내 107초 만에 257개의 번호를 얻었습니다. 그 주에 받은 다른 목록들은 14%에서 26% 사이였습니다. 10월 9일자 목록은 미국 목록이 아니었습니다. 데이터가 단순히 번호를 가지고 있지 않은 사람들의 목록이었고, 처음 백 줄만 봐도 알 수 있었을 것입니다.

청구서에 명시된 것과 그렇지 않은 것

청구서는 정확했습니다. Pay-per-found는 구매자가 1,021개의 번호에 대해서만 지불하고 아무것도 반환하지 않은 113,946개 요청에 대해서는 비용을 지불하지 않았다는 의미입니다. '성공적인 결제가 올바른 결제는 아니다(a successful payment is not a correct one)'라는 x402 표준에 따라, 이 모든 결제는 적절했습니다.

세 가지 비용은 청구서에 포함되지 않았습니다.

시간. 조용한 키에서 1,000줄을 처리하는 작업이 2분도 채 걸리지 않아야 했지만, 폭풍 속에서는 요청의 3분의 1이 거부되어 기다리고 재시도해야 했기 때문에 16~17분이 걸렸습니다. 16분 동안 진행된 백세 번의 실행은 대략 천 개의 번호를 얻는 데 약 27시간의 실행 시간을 의미합니다. 플랫폼은 작업이 기다리는 동안에도 컴퓨팅 자원을 측정(meters)합니다. 그 비용은 실제이며, 단지 다른 청구서의 다른 항목에 적혀 있을 뿐이고, Actor 자체 로그에는 합계가 표시되지 않습니다.

손실된 행(Lost rows). Actor 내부의 클라이언트는 429 오류를 고정된 2초 대기 시간으로 여섯 번 재시도한 후 포기하고 해당 행을 무료 error 행으로 전송했습니다. 백 개 중 약 두 개의 행이 이런 식으로 남겨졌습니다: 조회에 실패하여 거부된 것이 아니라, 단순히 손실된 것입니다. 데이터셋을 읽는 구매자는

속도 제한(rate limit)은 DigitalOcean의 설명대로 작동했습니다. 구매자의 속도를 3분의 1로 늦추고 일부 행을 놓쳤을 뿐, 아무것도 멈추지는 않았습니다. 아침에 일이 중단된 것은 목록이 11:05에 소진되었기 때문입니다.

제가 바꾼 것들

판매자가 구매자의 판단을 막을 수는 없지만, 스로틀링(throttling)을 손실로 만드는 것은 막을 수 있습니다. 10월 14일 이후부터는:

• 429 에러가 발생한 후의 대기 시간이 거절할 때마다 증가합니다 (2초, 4초, 8초, 16초, 그리고 30초까지). 이 모든 과정이 실행 자체의 시간 예산 내에서 이루어집니다. 이제 폭풍우는 손실적이지 않고 느려졌습니다. 서비스가 바쁘다는 이유로 어떤 행도 error 상태로 남지 않습니다.
• 한 번의 실행은 최대 20,000개의 항목을 처리합니다. 20,000개 목록을 순차적으로 읽는 한 번의 실행이 1,000개짜리 목록으로 키 하나를 얻기 위해 싸우는 스무 번의 실행보다 구매자에게 적은 대기 시간을 소비하며, 9월 10일자의 로그가 그 수치를 증명합니다.
• 키당 허용량(per-key allowance)이 증가했는데, 이는 누구나 가장 먼저 시도하는 지루한 해결책이었고, 이것만으로는 충분하지 않았을 것입니다.

티어별 가격 책정은 Actor 페이지에 있습니다. 아무것도 바뀌지 않았습니다. 바뀐 것은 실행의 형태였습니다.

구매자의 하네스(harness)가 했어야 할 일

구매자는 아마도 사람이 아니라 에이전트나 스크립트였을 것입니다. 사람은 3시간 동안 '시작' 버튼을 103번 누르지 않습니다. 따라서 이것은 하네스의 문제입니다. 그리고 이 하네스는 가장 간단한 두 단계를 건너뛰었습니다.

대량 처리 전 샘플. 조회(lookup)는 검색(search)처럼 무료 카운트 모드가 없지만, 무료 샘플 기능이 있습니다: 100개 행, 2분, 그리고 발견된 공유 데이터와 함께 제공됩니다. 1% 지점에서 올바른 조치는 멈춰서 이 목록의 천 개의 숫자가 아침에 가치가 있는지 물어보는 것입니다. 25% 지점에서는 목록을 실행합니다. 샘플이 예산입니다. 이번 시리즈 초반에 spend-gate post에서 저는 이를 Claude Code hook으로 연결했습니다: 카운트(count), 다음은 적중률이 있는 무작위 샘플(random sample), 그리고 인간이 샘플을 본 후에만 전체 실행(full run)을 강제합니다. 이 훅은 검색 Actor를 위해 작성되었지만, 동일한 세 줄의 코드가 조회에도 적용됩니다.

한 번 실행하고, 백 번 실행하지 마세요. 하나의 미터링 키에 대해 병렬로 여러 번 실행한다고 해서 더 빨리 끝나지 않습니다. 그저 속도 제한(rate limit)에 도달할 때까지 계속되고, 기다리는 비용을 지불하게 됩니다. 만약 입력이 20,000개의 행을 수용한다면, 한 번에 20,000개 행을 보내세요. Actor가 Retry-After를 보고하면, 타이머로 재시도하는 대신 그것을 준수하세요.

예산(budget)이 아니라 적중률(hit rate)에서 중단하세요. 예산 제한(budget cap)이었다면 오늘 아침 실행이 그 한도까지 진행되었을 것입니다. 하지만 적중률 규칙은 100번째 행에서 멈춥니다. 제가 이제 에이전트의 지침에 추가한 미터링 조회에 대한 규칙입니다:

Before a paid lookup over a list:
1. Run the first 100 rows alone. Report found / no_phone / profile_removed / error.
2. If found is under 5 %, stop and ask the user whether the found rows
...

단 네 줄로, 10월 9일 아침은 2분짜리 샘플이자 질문이 되고, 아마도

• LinkedIn Phone Number Finder, 이 로그가 기록된 Actor입니다.
• 메터링 데이터 API를 사용하는 AI 에이전트를 위한 지출 게이트 (A spend gate for AI agents on metered data APIs), 카운트, 샘플, 승인 후크입니다.
• 지불 기반으로 찾은 전화번호를 조회하는 6가지 콜 리스트 레시피 (Six call-list recipes with pay-per-found phone lookups), 적합한 리스트에서 찾은 내용이 어떻게 보이는지 보여줍니다.
• b2bsearch/skills, b2bsearch/workflows.

메터링 API를 운영해 본 사람이라면, 자신의 로그에서 하나의 숫자를 공유해 주세요: 최악의 날에 거부된 요청 비율입니다. 저는 31%가 비정상적이지 않다고 의심하며, 이런 아침을 경험한 누구도 이쪽(운영자 측)에서 그런 수치를 본 적이 없을 것이라고 생각합니다.