한 줄 정의

Batch API는 모델 요청을 한 건씩 바로 응답받는 대신, 큰 묶음으로 제출하고 나중에 결과를 한꺼번에 돌려받는 비동기 추론 인터페이스야. 그래서 이름만 보면 단순 할인 요금제처럼 들리지만, 실제로는 API 호출 방식을 실시간 요청에서 배치 작업 관리로 바꾸는 쪽에 더 가까워.

이 말이 보이면 “지금 바로 답을 받는 경로인가”보다 “밤에 한꺼번에 돌리는 평가, 대량 분류, 대규모 생성 작업을 파일이나 작업 단위로 처리하는 경로인가”부터 보는 편이 맞아.

실제로 무엇을 하나

실무에서 Batch API는 보통 같은 종류의 요청 수천~수만 건을 묶어 돌릴 때 써. 첫 번째 장면은 밤에 한꺼번에 돌리는 평가 작업이야. 모델 프롬프트 실험이나 회귀 테스트를 낮 동안 일반 인터랙티브 API로 돌리면 분당 호출 한도와 비용이 금방 커지는데, Batch API로 넘기면 결과를 다음날 한꺼번에 받아 비교하기 쉬워. 두 번째 장면은 카탈로그 정리나 문서 후처리야. 상품 설명 생성, 리뷰 분류, 대규모 임베딩 작업처럼 즉답이 필요 없는 흐름에 잘 맞아.

  • Gemini API의 Batch API는 작은 요청 묶음이면 inline 방식으로 바로 넣을 수 있어. 문서 기준으로 이 방식은 총 요청 크기가 20MB 미만일 때 적합해.
  • Gemini에서 더 큰 배치는 JSONL 입력 파일로 넘겨. JSONL은 한 줄에 요청 하나씩 적는 텍스트 파일이고, File API로 올리는 입력 파일 최대 크기는 2GB야.
  • OpenAI API 쪽은 미리 업로드한 JSONL 파일을 기준으로 배치를 만들고, completion_window는 현재 24h만 지원해. 입력 파일 제한도 최대 50,000 requests와 200 MB야.
  • 결과를 가져오는 방식도 달라. OpenAI는 output file과 error file로 결과를 돌려주고, Gemini는 batch job 상태를 주기적으로 다시 조회해 JOB_STATE_SUCCEEDED 같은 완료 상태를 확인한 뒤 결과를 읽어 가.

이 흐름은 “파일 업로드 → batch 생성 → 완료됐는지 다시 확인 → 결과 회수”에 가깝지, Responses API처럼 요청 하나를 보내고 바로 답을 받는 감각과는 다르다고 보면 돼.

왜 중요한가

Batch API가 중요한 이유는 모델 선택보다 작업 처리 전략을 바꾸기 때문이야. 두 제공자 모두 공식 문서에서 표준 인터랙티브 호출 대비 50% 할인과 24시간 안팎 처리 목표를 내세우는데, 이건 “싸다”보다 “실시간 UX를 버리는 대신 처리량과 비용을 바꾼다”는 신호로 읽는 게 더 정확해.

이 차이는 Batch를 다른 호출 방식과 비교할 때 더 분명해져. Google은 2026년 5월 3일 기준 Priority inference를 premium 동기 tier로 설명하고, 공식 블로그에서는 Flex와 Priority가 표준 동기 endpoint 위에서 백그라운드 작업과 즉시 응답 작업을 나눠 받는다고 적어. OpenAI도 같은 날짜 기준 가격표와 GPT-5.5 공개 글에서 Batch와 Flex를 standard보다 낮은 가격 구간으로, Priority processing을 더 비싼 premium 구간으로 설명해. 즉 각 제공자 문서 기준으로 보면 Batch는 “느리지만 싸고 많이 처리하는 경로”, Priority는 “비싸지만 바로 처리하는 경로”라는 대비가 꽤 선명해.

이걸 알고 있으면 기사나 제품 문서를 읽을 때 덜 헷갈려. 어떤 팀이 Batch API를 붙인다고 할 때 핵심은 모델이 더 똑똑해졌다는 얘기보다, 사용자 요청을 실시간으로 받는지 아니면 뒤에서 순서대로 처리하는 작업 대기열로 넘기는지, 실패와 만료를 어떻게 처리하는지 같은 실제 운영 방식이 바뀐다는 데 있어.

주의해서 볼 점

Batch API는 사용자가 화면에서 바로 기다리는 대화에 넣는 기본 경로가 아니야. OpenAI FAQ는 Batch API에서 streaming을 지원하지 않는다고 적고, Gemini 문서는 job이 48시간 넘게 pending 또는 running 상태면 JOB_STATE_EXPIRED로 끝날 수 있다고 적어. 이 말은 결과가 느려도 괜찮고, 일부 실패를 재처리할 준비가 있는 업무에 더 잘 맞는다는 뜻이야.

또 “Batch API를 쓴다”만으로는 충분하지 않아. 어떤 endpoint와 모델이 배치를 지원하는지, 입력이 JSONL 파일인지 inline 요청인지, 결과를 파일로 받는지 응답 필드로 받는지, 실패한 개별 요청을 어떻게 다시 돌릴지까지 같이 설계해야 해. 특히 대량 추론은 모델 품질보다 작업을 어떻게 나눴는지, 완료 여부를 얼마나 자주 다시 조회하는지, 결과가 빠진 줄은 없는지 확인하는 절차가 더 크게 문제를 만들기도 해.

결국 Batch API는 더 싼 채팅 API가 아니라, 파일 업로드, 완료 확인, 결과 회수 절차가 따로 붙는 대량 처리 도구라고 보는 편이 맞아.