AI 답변을 하루 수천 개 모으는 법: 배치, 동시 작업 한도, 웹훅

ChatGPT, Gemini, Perplexity 프롬프트 수천 개를 매일 배치 요청 하나로 보내는 법입니다. 플랜의 동시 작업 한도와 크레딧에 맞춰 규모를 정하고, 중복 없이 다시 보내고, 답변을 24시간 안에 저장합니다.

작업 규모에 맞는 엔드포인트 고르기

요청 하나로 작업을 여러 개 만드는 엔드포인트는 셋입니다. 셋 다 일반 작업을 만들므로 폴링, 웹훅, 크레딧, 플랜 한도는 단건 작업과 같습니다. 다른 점은 담는 작업 수와, 플랜 한도를 넘는 작업을 누가 처리하느냐입니다. 전체 설명은 배치와 그리드 문서에 있습니다.

• 작업 500개까지, 재시도를 직접 짠다면 POST /v1/async/task/batch입니다. 응답에 모든 작업 id가 한 번에 옵니다.
• 하루 수천 개짜리 작업이나 동시 작업 한도보다 많은 작업은 POST /v1/batches입니다. 서버가 속도를 맞추므로 코드는 요청 하나를 보내고 결과를 받기만 합니다.
• 한 지역 주변 여러 지점에서 같은 프롬프트를 묻는다면 POST /v1/async/task/grid입니다. 최대 9 × 9 그리드입니다.

하루 작업을 배치 하나로 보내기

배치에는 items 배열, 모든 항목에 쓰는 webhook.url 하나, 선택 항목인 metadata, 그리고 배치 자체의 idempotencyKey가 들어갑니다. 항목 하나는 일반 작업 요청이고, 결과와 함께 돌아오는 customId도 붙입니다. 배치 키에 날짜를 넣으면 같은 날 배치를 두 번 보내도 첫 배치가 돌아옵니다.

curl -X POST https://api.querying.ai/v1/batches \
  -H "Authorization: Bearer $QUERYING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "idempotencyKey": "daily-2026-11-05",
    "webhook": { "url": "https://hooks.example.com/querying" },
    "metadata": { "run": "daily" },
    "items": [
      { "customId": "p0001-chatgpt", "idempotencyKey": "2026-11-05:p0001:chatgpt", "taskType": "CHATGPT", "payload": { "prompt": "best CRM for a small team", "country": "US" } },
      { "customId": "p0001-gemini", "idempotencyKey": "2026-11-05:p0001:gemini", "taskType": "GEMINI", "payload": { "prompt": "best CRM for a small team", "country": "US" } }
    ]
  }'

응답은 202이고 배치 id, 상태, 항목 상태별 개수가 옵니다. 저장 전에 모든 항목을 먼저 검사합니다. 항목 하나라도 잘못되면 400 VALIDATION_ERROR와 문제 항목 번호가 오므로, 잘못된 프롬프트 목록은 크레딧을 쓰기 전에 바로 걸러집니다.

처리량을 정하는 두 숫자

플랜이 모으는 양은 두 숫자로 정해집니다. 동시 작업 한도는 대기 중이거나 처리 중인 작업을 한 번에 몇 개 둘 수 있느냐이고, 서버는 앞 작업이 끝날 때마다 배치 항목을 그 자리에 넣습니다. 크레딧은 한 달에 담기는 답변 수를 정합니다. 아래 표는 플랜별 월 크레딧을 30으로 나눈 값입니다.

무료 플랜은 500크레딧과 동시 작업 2개로 시작하므로 배치를 처음부터 끝까지 시험하기에 충분합니다. 엣지는 API 키마다 분당 요청 1,200개를 받고, 500개짜리 배열은 요청 하나로 세므로 배치로 보내면 큰 작업도 요청 속도 한도 안에 넉넉히 들어갑니다. 한도와 코드는 크레딧과 한도 문서에 있습니다.

curl https://api.querying.ai/v1/async/status \
  -H "Authorization: Bearer $QUERYING_API_KEY"

{ "queuedTasks": 19, "processingTasks": 6, "concurrency": { "used": 25, "max": 200 } }

GET /v1/async/status는 무료로 부릅니다. concurrency.max - concurrency.used가 새 작업을 넣을 남은 자리라서, 배치가 도는 동안 단건 작업을 얼마나 빨리 보낼지 스케줄러가 이 값으로 정합니다.

계산 예시: 프롬프트 1,000개를 엔진 4곳에 매일

한 나라에서 프롬프트 1,000개를 ChatGPT, Perplexity, Gemini, Google AI Overviews에 하루 한 번 묻는다고 합시다. 작업은 4,000개로 배치 하나의 한도 10,000개 안에 넉넉히 들어갑니다. 엔진 4곳은 프롬프트 하나에 4.5크레딧이라서 하루 4,500크레딧, 한 달 135,000크레딧입니다. 월 $200인 Pro는 170,000크레딧과 동시 작업 200개를 줍니다.

• 프롬프트 표에서 항목을 만듭니다. 프롬프트와 엔진 조합마다 항목 하나이고, customId에는 우리 프롬프트 id와 엔진을 넣습니다.
• 항목 키는 날짜, 프롬프트, 엔진으로 만듭니다. 예: 2026-11-05:p0001:chatgpt.
• 날짜를 넣은 배치 키와 웹훅 주소로 POST /v1/batches를 한 번 보냅니다.
• 작업 웹훅이 올 때마다 저장하고, batch.completed가 오면 그날 실행을 닫습니다.
• GET /v1/batches/{id}/items?status=failed로 실패 항목을 모아 다음 날 다시 보낼 프롬프트를 정합니다.

규모를 키울 때는 반복보다 프롬프트를 먼저 늘립니다. 월 비용은 프롬프트 수 × 엔진 수 × 나라 수 × 실행 횟수로 늘어나고, 계산은 AI 노출 추적 비용은 얼마일까에 정리했습니다.

중복 없이 다시 보내기

• 작업마다 idempotencyKey를 붙입니다. 같은 키로 다시 보내면 기존 작업이 돌아오므로, 타임아웃이나 장애 뒤에 다시 보내도 답변과 과금이 한 번만 생깁니다. 키는 최소 30일 동안 유지됩니다.
• 제출 엔드포인트에서 429나 503이 오면 Retry-After의 초만큼 기다렸다가 같은 키로 다시 보냅니다.
• 엣지의 429 응답에는 JSON 본문이 없습니다. 지수적으로 늘어나는 간격을 두고 다시 보냅니다.
• POST /v1/batches 안에서 자리가 없어 밀린 항목은 PENDING으로 남고 서버가 다시 시도합니다. INSUFFICIENT_CREDITS는 항목을 거절하므로 큰 실행 전에 크레딧을 채웁니다.

만료 전에 답변 저장하기

작업이 끝나면 결과를 담은 웹훅이 오고, 배치는 모든 항목이 끝났을 때 batch.completed 이벤트를 한 번 보냅니다. 웹훅은 최소 한 번 전달되므로 querying-webhook-id 헤더로 중복을 거르고 저장을 멱등하게 만듭니다. 서명과 재전송 간격은 웹훅 문서에 있습니다.

curl https://api.querying.ai/v1/batches/3f6b2a10-... \
  -H "Authorization: Bearer $QUERYING_API_KEY"

curl "https://api.querying.ai/v1/batches/3f6b2a10-.../items?status=completed&include=response&limit=100" \
  -H "Authorization: Bearer $QUERYING_API_KEY"

폴링은 안전망입니다. GET /v1/batches/{id}는 항목 상태별 개수를 주고, 항목 엔드포인트는 include=response와 함께 결과를 100개씩 넘겨 줍니다. 결과 본문은 작업이 끝난 뒤 24시간, 배치 자체는 30일 동안 읽히므로 답변은 오는 대로 저장하고 실패 항목 점검은 그날 안에 돌립니다.