[Spring Batch] 1. 배치 처리란 무엇인가

사용자가 요청할 때 즉시 응답하는 API와 달리, 새벽 2시에 아무도 모르게 수만 건의 데이터를 처리하는 작업이 있다. 정산, 통계 집계, 대량 알림 발송 — 이런 작업은 실시간으로 처리할 필요도 없고, 실시간으로 처리할 수도 없다. 이런 대량 데이터의 일괄 처리를 배치 처리라고 부른다.

배치 처리란

배치 처리는 대량의 데이터를 모아서 한꺼번에 처리하는 방식이다. 사용자의 요청에 즉시 응답하는 실시간 처리와 대비되는 개념이다.

편의점 택배를 생각해보자. 고객이 택배를 맡길 때마다 배송 트럭이 출발하면 비효율적이다. 대신 하루 동안 모인 택배를 저녁에 한 번에 싣고 출발한다. 배치 처리도 이와 같다. 데이터를 모아두었다가, 정해진 시점에 일괄적으로 처리한다.

실시간 처리와 배치 처리의 차이를 비교하면 다음과 같다.

구분	실시간 처리	배치 처리
트리거	사용자 요청	스케줄 또는 수동 실행
처리 단위	건 by 건	수천~수백만 건
응답 시간	밀리초~초	분~시간
대표 예시	API 호출, 검색	정산, 통계, 데이터 마이그레이션

배치가 필요한 상황

모든 작업이 배치로 처리되어야 하는 건 아니다. 배치가 필요한 상황에는 공통된 패턴이 있다.

대량 데이터 처리

수만~수백만 건의 데이터를 한 번에 처리해야 할 때다. 하나씩 API로 처리하면 시간이 너무 오래 걸리거나 시스템에 과부하가 걸린다.

• 월말 정산 — 한 달치 주문 데이터를 집계해서 정산 금액을 계산
• 데이터 마이그레이션 — 레거시 DB에서 새 DB로 수백만 건의 레코드를 이관
• 대량 이메일/알림 발송 — 10만 명의 사용자에게 프로모션 알림을 전송

주기적 집계

일정 주기로 데이터를 모아 통계를 내야 할 때다.

• 일일 매출 리포트 — 하루 동안의 거래를 집계해서 대시보드에 반영
• 인기 피드 순위 — 24시간 동안의 좋아요 수를 집계해서 순위를 갱신
• 사용자 활동 통계 — 주간 활동 로그를 분석해서 리포트 생성

시스템 유지보수

서비스 운영에 필요하지만 사용자에게 직접 보이지 않는 관리 작업이다.

• 만료 데이터 정리 — 90일이 지난 임시 파일이나 만료된 토큰을 삭제
• 캐시 워밍 — 서비스 시작 전에 자주 조회되는 데이터를 미리 캐시에 적재
• 데이터 정합성 검증 — 두 시스템 간의 데이터가 일치하는지 주기적으로 확인

Spring Batch란

Spring Batch는 Java 진영의 표준 배치 프레임워크다. Spring 생태계의 일부로, 대량 데이터 처리에 필요한 구조와 기능을 제공한다.

배치를 직접 구현한다고 생각해보자. 데이터를 읽고, 가공하고, 저장하는 코드를 짜는 건 어렵지 않다. 하지만 실무에서는 단순한 로직 외에도 해결해야 할 문제가 많다.

• 10만 건 중 5만 건째에서 에러가 나면 처음부터 다시?
• 메모리에 100만 건을 한 번에 올릴 수 없으면?
• 어제 실행한 배치가 정상 완료되었는지 어떻게 확인하지?
• 실패한 배치를 이어서 다시 실행할 수 있을까?

Spring Batch는 이런 문제를 프레임워크 차원에서 해결한다.

Spring Batch의 핵심 특징

Chunk 기반 처리

데이터를 한 번에 전부 메모리에 올리지 않는다. 일정 크기(chunk)로 나눠서 읽기 → 가공 → 쓰기를 반복한다.

100만 건을 처리한다면, 1,000건씩 끊어서 1,000번 반복한다. 각 chunk 단위로 트랜잭션이 관리되므로, 중간에 실패해도 이미 처리된 chunk는 보존된다.

이 구조를 그림으로 보면 다음과 같다.

Reader가 데이터를 읽고, Processor가 가공하고, Writer가 저장한다. 이 3단계가 chunk 단위로 반복되며, 각 chunk마다 트랜잭션이 걸린다. 5번째 chunk에서 실패하면 1~4번째 chunk의 결과는 이미 커밋되어 있으므로 안전하다.

재시작과 재시도

배치 작업이 중간에 실패하면, 실패한 지점부터 이어서 재시작할 수 있다. Spring Batch는 각 Step의 실행 상태를 DB에 기록해두기 때문에, 어디까지 처리했는지 정확히 알고 있다.

특정 레코드에서 일시적 오류가 발생하면, 해당 레코드만 재시도하거나 건너뛸 수도 있다. 네트워크 타임아웃 같은 일시적 문제에 유용하다.

실행 이력 관리

모든 배치 실행은 메타데이터 테이블에 기록된다. 언제 실행했는지, 성공했는지, 몇 건을 처리했는지, 얼마나 걸렸는지가 자동으로 저장된다.

운영팀에서 "어제 정산 배치가 정상적으로 돌았나?"라고 물으면, 메타데이터 테이블을 조회해서 바로 확인할 수 있다.

Spring Batch 아키텍처 개요

Spring Batch의 전체 구조를 큰 그림으로 먼저 잡아두자. 세부 내용은 이후 편에서 하나씩 파고든다.

세 개의 레이어로 나뉜다.

• 애플리케이션 레이어 : 개발자가 직접 작성하는 배치 Job과 Step이다. 비즈니스 로직을 담는다.
• 코어 레이어 : Spring Batch의 핵심 런타임이다. Job을 실행하고(JobLauncher), 실행 이력을 기록하고(JobRepository), Step의 상태를 관리한다.
• 인프라 레이어 : 데이터를 읽고(ItemReader), 가공하고(ItemProcessor), 저장하는(ItemWriter) 구현체들이다. DB, 파일, 메시지 큐 등 다양한 데이터 소스를 지원한다.

개발자가 집중하는 영역은 애플리케이션 레이어와 인프라 레이어다. 코어 레이어는 Spring Batch가 자동으로 관리한다.

실제 사용 사례

배치 처리가 실제로 어떻게 활용되는지 몇 가지 사례를 살펴보자.

이커머스 정산

매일 자정에 전날의 주문 데이터를 집계해서 판매자별 정산 금액을 계산한다. 수십만 건의 주문을 한 건씩 API로 처리하면 몇 시간이 걸리지만, Spring Batch의 chunk 기반 처리로 수 분 내에 완료할 수 있다.

SNS 피드 랭킹

24시간 동안의 좋아요, 댓글, 조회수를 집계해서 인기 피드 순위를 갱신한다. 실시간으로 매번 집계 쿼리를 돌리면 DB에 과부하가 걸리므로, 주기적으로 배치로 집계한 결과를 캐시에 올린다.

데이터 마이그레이션

레거시 시스템에서 신규 시스템으로 수백만 건의 데이터를 이관한다. 단순 INSERT가 아니라 데이터 형식 변환, 유효성 검증, 중복 제거 등의 가공이 필요하다. Spring Batch의 Reader → Processor → Writer 구조가 이 패턴에 정확히 맞는다.

Spring Batch 프로젝트 설정

Spring Boot에서 Spring Batch를 시작하려면 의존성을 추가하고 기본 설정을 한다.

의존성 추가

// build.gradle
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-batch'
    runtimeOnly 'com.h2database:h2' // 메타데이터 테이블용 DB (개발용)
}

spring-boot-starter-batch가 Spring Batch의 핵심 모듈을 포함한다. 메타데이터 테이블을 저장할 DB가 필요하므로, 개발 환경에서는 H2를 함께 추가한다. 운영 환경에서는 MySQL이나 PostgreSQL을 사용한다.

application.yml 설정

spring:
  batch:
    jdbc:
      initialize-schema: always  # 메타데이터 테이블 자동 생성
    job:
      enabled: false  # 애플리케이션 시작 시 자동 실행 방지

initialize-schema: always는 Spring Batch가 필요로 하는 메타데이터 테이블을 자동으로 생성한다. job.enabled: false는 애플리케이션 시작 시 모든 Job이 자동 실행되는 것을 방지한다. 이 설정이 없으면 서버를 띄울 때마다 배치가 돌아간다.

자주 하는 실수

---