배치 프로세싱(Batch API)을 활용한 비실시간 작업 비용 최적화

처음에는 비실시간 작업을 그냥 기존 API 흐름에 얹어서 처리했습니다. 요약 리포트 만들고, 오래된 로그를 분류하고, 실패한 작업을 다시 태우는 정도라서 큰 문제는 없어 보였기 때문입니다. 그런데 이런 작업이 쌓이기 시작하면, 어느 순간부터 배치 프로세싱 자체가 비용 최적화의 핵심 주제가 되더군요. 결국 중요한 것은 작업을 빨리 처리하는 것이 아니라, 늦어도 되는 작업을 왜 비싼 방식으로 처리하고 있었는지를 먼저 보는 일이었습니다.

배치프로세싱 비용최적화, 왜 따로 봐야 하는가

배치프로세싱 비용최적화는 단순히 백그라운드 작업을 돌리는 이야기가 아닙니다. 실시간 처리가 필요 없는 업무를 실시간 방식으로 계속 호출하면, 호출 단가와 재시도 비용, 시스템 자원 사용량이 함께 올라갑니다. 원문도 이 지점을 짚고 있었는데, 중간부터 운영 장애와 인프라 수치가 너무 길어지면서 정작 주제인 배치프로세싱 비용최적화 자체가 흐려졌습니다.

이 글에서 중심이 되어야 하는 질문은 단순합니다. 지금 처리 중인 작업이 정말 즉시 응답이 필요한가, 아니면 묶어서 처리해도 되는가입니다. 이 기준만 명확해져도 어떤 작업을 배치로 빼야 하는지 보이기 시작합니다. 

 

배치 후보로 자주 올라오는 작업

실무에서 배치 전환 후보로 자주 나오는 것은 이런 것들입니다. 오래된 문서 요약, 로그 분류, 검색 인덱스 보강, 상품 태그 생성, 일일 리포트 생성, 실패 작업 재처리 같은 것들입니다. 결과가 몇 초 늦거나 몇 분 늦는다고 서비스 경험이 직접 무너지지 않는 작업들입니다.

이런 작업은 실시간 API에 태우기보다 모아서 처리하는 편이 더 자연스럽습니다. 그런데 구현 초기에는 보통 제일 익숙한 HTTP 동기 호출부터 붙이게 됩니다. 

 

배치프로세싱 비용최적화가 안 되던 진짜 이유

배치프로세싱 비용최적화가 안 되는 이유는 기술이 없어서가 아닙니다. 작업 성격을 구분하지 않고, 일단 기존 요청 흐름에 얹어버리기 때문입니다. 당장 결과를 받아보는 것이 편하고 디버깅도 쉽기 때문에, 비실시간 작업도 계속 실시간처럼 붙습니다.

문제는 여기서부터 시작됩니다. 같은 내용을 여러 번 요청하게 되고, 실패한 건을 다시 태우면서 중복 호출이 쌓입니다. 작업 자체는 늦어도 괜찮은데, 처리 방식은 가장 비싼 경로를 타게 됩니다. 생각보다 자주 발생합니다.

즉 이 주제의 핵심 Pain Point는 서버 CPU가 아니라 구조 선택입니다. 늦어도 되는 작업을 왜 항상 즉시 처리하려고 했는지, 왜 묶을 수 있는 요청을 한 건씩 계속 보내고 있었는지를 먼저 봐야 합니다.

 

비용이 새는 대표적인 패턴

대표적인 패턴은 세 가지입니다. 첫째, 같은 종류의 작업을 요청 단위로 계속 호출하는 경우입니다. 둘째, 재시도 로직이 붙으면서 동일 작업이 여러 번 외부 API에 전달되는 경우입니다. 셋째, 운영자가 다시 돌리기 쉽게 해두지 않아서 실패 건 전체를 통째로 재처리하는 경우입니다.

이 세 가지가 겹치면 작업량 자체보다 방식 때문에 비용이 커집니다. 결국 배치프로세싱 비용최적화는 단가 절감 이전에, 낭비되는 호출 구조를 줄이는 일이라고 보는 게 맞습니다.

 

배치프로세싱 비용최적화를 위한 의사결정

원문에서도 비교 구조는 좋았습니다. 다만 운영 성능 이야기보다, 왜 실시간 유지 방식과 배치 전환 방식을 비교해야 하는지가 더 앞에 나와야 했습니다. 실제로는 보통 두 가지 선택지가 놓입니다.

 

방법 A. 기존 실시간 API 흐름 유지

장점은 단순합니다. 지금 있는 API 흐름을 거의 그대로 쓸 수 있습니다. 개발 속도도 빠르고, 결과도 바로 확인할 수 있습니다. 초기에는 이 방식이 가장 편합니다.

하지만 단점은 분명합니다. 즉시 응답이 필요 없는 작업까지 계속 요청 단위로 처리하게 됩니다. 작업량이 늘수록 요청 수, 재시도 수, 중복 처리량이 같이 늘어납니다. 

 

방법 B. 비실시간 작업 분리 후 배치 전환

이 방식은 응답이 당장 필요 없는 요청을 내부에 적재했다가, 일정량씩 모아서 처리하는 구조입니다. 배치프로세싱 비용최적화라는 주제에는 이 방식이 훨씬 더 직접적입니다. 요청을 묶을 수 있고, 중복을 줄일 수 있고, 재처리 단위도 통제할 수 있기 때문입니다.

물론 구현은 더 번거롭습니다. 상태 관리, 중복 방지, 실패 라인 추적, 재처리 정책 같은 운영 코드가 필요합니다. 그런데 이 복잡도는 납득 가능한 복잡도입니다. 비용을 줄이려면 결국 작업 단위를 묶어야 하고, 묶은 작업을 안전하게 다시 돌릴 수 있어야 합니다.

 

최종 선택 기준

저는 보통 세 가지 기준으로 배치 전환 여부를 봅니다. 첫째, 결과가 몇 초 또는 몇 분 늦어져도 괜찮은가입니다. 둘째, 실패했을 때 다시 처리해도 업무상 문제가 없는가입니다. 셋째, 여러 요청을 모아서 제출했을 때 중복 제거와 비용 절감 효과가 있는가입니다.

이 세 조건에 맞으면 배치 후보입니다. 반대로 결제 승인, 사용자 즉시 응답, 트랜잭션이 물려 있는 처리처럼 즉시성이 중요한 것은 괜히 배치로 빼지 않는 편이 낫습니다.

 

배치프로세싱 비용최적화 구현은 무엇이 중요했나

이 주제에서 구현은 인프라 튜닝보다 처리 단위 설계가 더 중요합니다. 요청을 어디에 적재할지, 어떤 기준으로 묶을지, 어떤 키로 중복을 막을지, 실패한 건은 어디서 다시 살릴지를 먼저 정해야 합니다. 원문에 있던 DB 테이블, JSONL 파일 생성, 상태 폴링 구조는 그 방향으로는 괜찮았습니다.

1. 먼저 내부 요청 적재가 있어야 한다

외부 API에 바로 보내지 않고 내부 저장소에 한 번 적재하는 구조가 좋습니다. 그래야 어떤 요청이 대기 중인지, 어떤 요청이 제출됐는지, 어떤 요청이 실패했는지 추적할 수 있습니다. 이력 없이 바로 호출하는 구조는 비용최적화와 잘 맞지 않습니다.

 CREATE TABLE batch_job_request ( id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY, job_type VARCHAR(50) NOT NULL, idempotency_key VARCHAR(120) NOT NULL, payload_json JSON NOT NULL, status VARCHAR(20) NOT NULL, batch_id VARCHAR(80) NULL, error_message VARCHAR(500) NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, UNIQUE KEY uk_batch_job_request_01 (job_type, idempotency_key), KEY idx_batch_job_request_01 (status, created_at) ); 

여기서 핵심은 idempotency_key입니다. 같은 작업이 여러 번 들어와도 한 번만 처리되게 해야 합니다. 이 부분을 빼면 배치로 옮겨도 비용 낭비는 그대로 남습니다.

 

2. 배치 파일은 크게 만드는 것보다 다시 돌리기 쉽게 만드는 편이 낫다

배치프로세싱 비용최적화에서는 한 번에 많이 보내는 것이 무조건 정답은 아닙니다. 너무 크게 묶으면 일부 실패가 났을 때 재처리 범위가 커집니다. 저는 크게 몰아보내는 것보다, 적당한 청크로 나눠서 실패 건만 다시 태울 수 있는 구조가 더 낫다고 봅니다.

 batch: submit: chunk-size: 5000 poll-interval-minutes: 5 retry-limit: 3 

3. 결과보다 실패 건 처리 방식이 더 중요하다

배치는 성공 흐름보다 실패 흐름이 더 중요합니다. 성공은 대체로 잘 흘러갑니다. 문제는 일부 요청만 실패했을 때입니다. 이때 실패 라인만 다시 READY 상태로 되돌릴 수 있어야 합니다.

 UPDATE batch_job_request SET status = 'READY', batch_id = NULL, error_message = 'RETRY_FROM_ERROR_FILE', updated_at = NOW() WHERE id IN (1012, 1018, 1044); 

이런 구조가 있어야 전체 재처리를 막을 수 있습니다. 전체를 다시 돌리면 결국 비용최적화는 실패합니다.

 

배치프로세싱 비용최적화는 결국 숫자로 판단해야 한다

배치프로세싱 비용최적화는 감으로 하면 안 됩니다. 작업량과 호출량, 중복 비율, 재시도 비율, 재처리 비율을 숫자로 봐야 합니다. 원문에 있던 비용 계산 예시는 주제와 잘 맞는 편이었습니다.

예를 들어 월 입력 2억 토큰, 출력 4천만 토큰 규모의 비실시간 작업이 있다고 가정해보겠습니다. 이 작업을 표준 실시간 호출로 계속 처리할지, 배치 방식으로 묶어 보낼지를 계산해 보면 절감 폭이 명확하게 보입니다. 

 예시 - 비실시간 작업 입력: 200M tokens - 비실시간 작업 출력: 40M tokens - 요청 중복률: 7% - 실패 후 전체 재처리 비율: 4% 배치 전환 후 기대 효과 - 요청 묶음 제출 - 중복 제거 - 실패 라인만 재처리 - 단가 절감 구조 적용 

결국 중요한 것은 단순 할인율이 아니라 구조 개선입니다. 비싼 API를 싸게 쓰는 것도 맞지만, 더 중요한 것은 쓸데없이 여러 번 부르지 않게 만드는 것입니다.

 

배치프로세싱 비용최적화 후 예상과 달랐던 점

배치를 도입하면 비용만 줄어들 것 같지만, 실제로는 작업 경계가 더 또렷해지는 효과가 있습니다. 어떤 것은 실시간으로 남기고, 어떤 것은 묶어서 보내는지 기준이 생기기 때문입니다. 이 기준이 생기면 시스템도 덜 복잡해집니다.

반대로 예상보다 번거로운 점도 있습니다. 결과가 즉시 오지 않기 때문에 기획이나 운영팀과 반영 시점을 맞춰야 합니다. 실패 건을 어떻게 보여줄지, 언제 다시 돌릴지, 최대 지연 시간을 어디까지 허용할지도 정해야 합니다. 배치가 싸다고 해서 자동으로 쉬워지는 것은 아닙니다.

 

배치프로세싱 비용최적화의 냉정한 결론

배치프로세싱 비용최적화는 분명 효과가 있습니다. 특히 결과가 당장 필요 없는 작업이 많고, 같은 유형의 요청을 반복해서 처리하는 서비스라면 더 그렇습니다. 다만 이걸 단순히 비용 절감 기능 정도로 보면 아쉽습니다.

본질은 작업 특성 분리입니다. 지금 이 작업이 정말 즉시 처리되어야 하는지, 아니면 모아서 처리해도 되는지를 먼저 구분해야 합니다. 그다음에야 배치가 의미를 가집니다.

배치프로세싱은 단가를 낮추는 기술이기도 하지만, 더 정확히는 비실시간 작업을 제자리에 옮겨 놓는 방식입니다. 비용은 그 결과로 따라오는 경우가 많습니다. 결국 중요한 것은 배치 API 자체보다, 무엇을 배치로 보내야 하는지를 구분하는 기준입니다.