Batch API vs 실시간 호출: 워크로드별 올바른 채널 선택 방법

먼저 두 가지 시간 척도를 구분하기

LLM 호출의 시간 민감도는 매우 다양합니다. 채팅창에서 답변을 기다리는 사용자의 허용 범위는 초 단위이고, 팀의 일일 보고서 생성 작업의 허용 범위는 시간 단위일 수 있습니다. Batch 채널은 바로 후자를 위해 설계되었습니다: 요청을 대기열에 넣고 집중 처리하여 더 긴 완료 시간을 더 낮은 토큰당 가격과 맞바꿉니다.

Anthropic의 [batch processing 문서](https://platform.claude.com/docs/en/build-with-claude/batch-processing)와 [pricing 페이지](https://claude.com/pricing)는 batch 등급 가격을 별도로 명시하고 있으며, OpenAI 측에도 대응하는 batch 및 배치 처리 할인이 있습니다. 두 곳의 공통점은 표준가 대비 할인이고, 차이는 제출 방식과 완료 기간에 있습니다.

판단 프레임워크: 네 가지 질문

1. 이 결과를 동기적으로 기다리는 사람이 있는가? 예 → 실시간. 아니오 → 계속.
2. 결과가 몇 시간 늦어도 되는가? 가능 → batch 후보. 반드시 분 단위 → 실시간.
3. 요청이 오프라인으로 열거 가능한 집합인가? 예(문서 묶음, 티켓 묶음, 평가 샘플 묶음) → batch가 매우 적합.
4. 실패 후 재실행 비용이 높은가? 높음 → 실시간으로 즉시 피드백; 낮음 → batch 일괄 재시도가 더 경제적.

전형적인 batch 시나리오 목록

• 콘텐츠 분류 및 태깅: 수십만 건의 상품, 리뷰, 티켓에 대한 통일된 태그 체계.
• 오프라인 데이터 정제: 비정형 텍스트를 구조화된 필드로 일괄 추출.
• 회귀 평가: 프롬프트 변경 전 고정 평가 세트로 비교 실행.
• 배치 요약 / 번역: 문서 라이브러리, 고객 상담 기록, 회의록의 오프라인 정리.
• 합성 데이터 생성: 학습 또는 평가용 샘플 일괄 생성.

Batch의 함정: 부분 성공과 재시도

Batch 작업은 '전부 성공 아니면 전부 실패'가 아닙니다. 수백 건의 요청이 있는 작업에서는 보통 매개변수 오류, 초과 입력, 콘텐츠 정책 등의 이유로 몇 건이 실패합니다. 엔지니어링 측면에서 반드시 해야 할 일:

• 건별로 결과 기록, 전체 배치의 성패를 하나의 불리언으로 취급하지 말 것.
• 재시도 가능과 불가능 구분: 429 / 5xx는 재시도 가능, 400 매개변수 오류는 재시도해도 무의미.
• 멱등 키: 동일한 비즈니스 데이터의 중복 제출이 중복 과금이나 중복 쓰기를 일으키지 않도록.
• 비용 사전 시뮬레이션: 제출 전 토큰 기준 상한 추정으로 예상치 못한 청구서 방지.

하나의 게이트웨이로 두 채널 동시 관리

실시간과 batch를 두 개의 독립 계정, 키, 청구서로 분리하는 것은 가장 흔한 아키텍처 부채입니다: 가격이 바뀌면 두 곳을 맞춰야 하고, 실패 조사 시 두 개의 백엔드를 뒤져야 합니다.

Admesh의 방식은 하나의 Base URL, 하나의 Key, 하나의 청구서입니다: 비즈니스 측에서 작업 유형으로 어느 채널을 탈지 결정하고, 모델 카탈로그와 단가는 항상 동일한 백엔드 설정에서 오며, 마진과 사용량을 한 곳에서 조회할 수 있습니다.

속도 제한 및 동시성 설명 보기 →