상품 설명 1,000개를 분류하는 일과 사용자의 질문에 바로 답하는 일은 같은 AI 모델을 쓰더라도 운영 방식이 달라야 합니다. 전자는 결과를 조금 늦게 받아도 될 수 있고, 후자는 대화 중에 응답이 필요합니다. Batch API는 즉시 응답이 필요 없는 여러 요청을 묶어 비동기로 처리하는 개발용 방식입니다.
여기서 비동기란 요청을 접수한 뒤 별도로 진행 상태와 결과를 확인하는 흐름을 뜻합니다. ChatGPT 채팅창에서 “한꺼번에 처리해 줘”라고 말하는 기능이나, 유료 ChatGPT 구독에 포함된 할인 옵션과 혼동하지 않아야 합니다. 이 글은 구현 전 업무 설계와 운영 확인에 초점을 맞춥니다.
실시간 호출과 Batch를 가르는 첫 질문
사용자가 화면 앞에서 결과를 기다리는가, 아니면 결과가 다음 작업 시점 전까지 나오면 되는가를 먼저 묻습니다. 상담 응답, 대화형 편집, 즉석 번역처럼 바로 이어지는 상호작용은 일반 호출이 적합할 수 있습니다. 독립적인 자료 여러 건을 분류하거나 다음 날 검토할 초안을 준비하는 작업은 배치 방식을 검토할 여지가 있습니다.
| 판단 항목 | 일반 호출을 먼저 검토 | Batch를 검토 |
|---|---|---|
| 기다릴 수 있는 시간 | 지금 답을 받아야 함 | 비동기 완료를 기다릴 수 있음 |
| 요청 사이의 관계 | 앞 답을 보고 다음 질문을 결정 | 각 요청을 독립적으로 준비 가능 |
| 결과 전달 | 대화나 화면에 바로 표시 | 결과 파일을 모아서 검토 |
| 실패 처리 | 현재 요청의 오류를 처리 | 항목별 성공·실패를 맞춰 봐야 함 |
각 요청이 앞 요청의 결과를 꼭 알아야 한다면 한 배치에 넣기 전에 의존 관계를 풀어야 합니다. 예를 들어 첫 단계에서 분류를 끝낸 뒤 그 분류에 따라 두 번째 작업을 정해야 한다면, 단계별로 결과를 확인하는 설계가 더 명확합니다.
‘24시간’과 ‘50% 할인’을 읽는 법
2026년 10월 11일 공식 가이드 기준으로 Batch는 동기식 API 대비 50% 비용 할인을 안내하며 완료 창은 24시간입니다. FAQ는 스트리밍을 지원하지 않는다고 설명합니다. 모델별 지원과 실제 과금 조건은 적용할 모델 및 최신 문서에서 확인해야 합니다. Batch API 가이드 · Batch FAQ
24시간이라는 안내를 ‘내일 출근 전에는 모든 행이 반드시 성공한다’는 업무 보장으로 바꾸면 곤란합니다. 완료 창 안에 끝내지 못한 요청은 만료될 수 있고, 이미 완료된 요청의 결과는 받을 수 있습니다. 따라서 제출 마감 직전에 전량을 보내기보다 실패 확인과 재처리에 필요한 시간을 별도로 남겨야 합니다.
50% 할인도 전체 프로젝트 비용이 절반이 된다는 뜻은 아닙니다. 가령 비교 가능한 API 사용료를 가상의 10단위로 잡으면 할인 적용분은 5단위가 되는 계산입니다. 하지만 파일 정리, 재처리, 저장, 사람이 검토하는 비용은 별도입니다. 이 숫자는 실제 요금 견적이 아닌 할인 구조를 설명하기 위한 예시입니다.
행 순서 대신 식별자로 결과를 맞추기
공식 가이드는 각 요청에 고유한 custom_id를 넣도록 안내하며 출력 순서가 입력 순서와 다를 수 있다고 명시합니다. 따라서 첫 번째 출력 행을 첫 번째 원본 자료에 붙이는 식으로 처리하면 다른 자료의 답이 섞일 수 있습니다. 요청 식별자와 결과 수집 안내
원본 자료의 관리 번호를 바탕으로 요청 식별자를 만들고, 결과를 그 식별자로 연결합니다. 사람이 볼 관리표에는 원본 번호, 요청 식별자, 작업 버전, 제출 배치, 처리 상태, 검토 상태를 따로 남기는 방식을 제안합니다. 처리 성공과 내용 검토 통과를 한 칸으로 합치지 않는 것이 좋습니다.
1,000건을 맡겼다면 합계부터 대조하기
다음은 실제 실행 결과가 아닌 가상의 운영 예시입니다. 1,000건을 제출했고 성공 결과 970건, 오류 20건, 만료 10건이 확인됐다면 970+20+10=1,000으로 제출 수와 맞습니다. 이어 성공 결과의 식별자가 모두 고유한지, 원본과 연결되는지, 필수 결과가 비어 있지 않은지 확인합니다.
만약 결과가 995건만 설명된다면 나머지 5건을 단순히 실패로 단정하지 말고 출력 파일, 오류 파일, 상태 집계를 확인해야 합니다. 반대로 같은 식별자가 중복 반영돼 1,005행이 됐어도 완료율이 높아진 것은 아닙니다. 행 수와 고유 식별자 수를 따로 확인하세요.
오류가 나면 전량 재실행보다 원인을 구분하기
- 입력 형식 문제: 수정하지 않고 다시 보내면 같은 문제가 반복될 수 있습니다.
- 항목별 실패: 해당 요청의 오류를 읽고 재시도 가능한지 판단합니다.
- 시간 만료: 완료된 결과를 먼저 보존하고 미완료 항목을 분리합니다.
- 내용 품질 문제: API 처리는 성공했어도 사람이 쓸 수 없는 답이면 검토 상태에서 별도로 관리합니다.
재시도할 때는 어떤 원본의 어떤 작업 버전을 다시 보냈는지 남깁니다. 성공한 항목까지 무심코 다시 보내면 중복 비용과 중복 반영이 생길 수 있습니다. 공식 안내상 완료된 작업은 배치가 만료되는 경우에도 과금될 수 있으므로 완료분과 미완료분을 먼저 나누는 편이 중요합니다. 상태와 과금 관련 FAQ
작게 시작할 때의 완료 조건
첫 도입은 전체 자료가 아닌 작은 시험 묶음으로 입력, 결과 수집, 원본 연결, 오류 처리를 확인하는 것이 실용적입니다. 목표는 단순히 상태가 완료로 바뀌는 것을 보는 데 있지 않습니다. 제출한 모든 원본이 어느 상태인지 설명되고, 성공 결과가 올바른 원본에 연결되며, 사람이 검토할 결과와 다시 처리할 결과가 구분돼야 합니다.
Batch를 선택할 이유는 기다림을 허용하는 업무의 처리 방식을 맞추기 위해서입니다. 할인율만 보고 도입하기보다 마감 여유, 항목의 독립성, 실패를 추적할 준비가 있는지 먼저 확인해 보세요.