[STUDY] Spring Batch 핵심 구조와 개념 정리

🧐 Spring Batch란?

배치(Batch) 처리란 대량의 데이터를 정해진 시점에 자동으로 일괄 처리하는 방식이다.

• 예시 
  • 매일 자정 주문 데이터 통계 저장
  • 매주 고객 대상 이메일 발송
  • DB 마이그레이션, 정산 처리 등
• 특징
  • 사람이 직접 요청하지 않아도 자동으로 주기적 실행
  • 실시간성보다 정확성과 안정성이 중요
  • 실패 시 재처리, 로그 추적이 중요

Spring Batch는 대용량 배치 작업을 쉽고 안전하게 처리할 수 있도록 도와주는 Spring 기반 프레임워크다.

• Job/Step 기반 구성 제공
• 예외, 로그. 재시작, 로깅 등의 기능 제공
• 청크 기반 처리, 병렬 처리 등 내장

💡 Spring Batch의 구조

Job과 Step

아래 그림은 Spring Batch의 전반적인 실행 흐름을 나타낸다.

• JobLauncher : 배치 실행을 트리거하는 컴포넌트. 배치 실행 시 JobRepository에 JobExecution을 생성해 기록
• Job : 하나의 배치 단위. 여러 Step으로 구성될 수 있음
• Step : 실제 데이터 처리가 수행되는 단위. 내부적으로 Reader → Processor → Writer 순서로 처리됨
• JobRepository : Job/Step의 실행 상태를 저장하며, 재시작/중단/성공 여부 등을 추적
• ItemReader : 데이터 소스로부터 입력 (CSV, DB, API 등)
• ItemProcessor : 읽은 데이터를 가공, 변환, 필터링
• ItemWriter : 최종 데이터를 외부로 출력 (DB 저장, 파일 기록 등)

🗣️ Spring Batch의 Job과 Step의 구조에 대해 설명해주세요.
Spring Batch는 Job과 Step이라는 실행 단위로 구성되어 있습니다. Job은 배치 작업의 전체 단위를 나타내며, 여러 개의 Step으로 구성될 수 있습니다. 각 Step은 Reader, Processor, Writer 구성 요소를 포함하며 실제 데이터 처리가 수행되는 단위입니다. Job을 실행하면 JobLauncher가 실행을 시작하고, JobRepository에 실행 정보가 저장되어 상태 추적이나 재시작이 가능하도록 관리됩니다. Step은 각각 독립적으로 트랜잭션을 가질 수 있고, 순차적으로 실행하거나 조건에 따라 분기할 수도 있습니다. 이러한 구조는 작업을 단계별로 나누고 실행 흐름과 상태를 명확히 관리할 수 있도록 해줍니다.
특히 실행 실패 시 특정 Step부터 다시 실행하는 구조를 지원해, 복구 가능성과 실행 제어를 용이하게 합니다.

Reader · Processor  ·  Writer

Spring Batch에서 하나의 Step은 크게 세 가지 구성 요소로 이루어진다.

각각 데이터를 읽고, 가공하고, 저장하는 역할을 담당하며, 책임이 명확하게 분리되어 있다.

• Reader (ItemReader) – 데이터를 읽는 구성 요소
  • 외부에서 데이터를 읽어오는 역할
  • 입력 소스는 CSV, DB, XML, API 등 다양하게 설정 가능
  • 한 번에 하나의 데이터를 반환, 더 이상 읽을 데이터가 없으면 null 반환
• Processor (ItemProcessor) – 데이터를 가공하는 구성 요소
  • Reader에서 읽어온 데이터를 가공하거나 변환하는 역할
  • 반환값이 null일 경우 해당 데이터는 writer에 전달되지 않음
  • 필수 구성 요소는 아니며, 필요 시에만 사용
• Writer (ItemWriter) – 데이터를 저장하는 구성 요소
  • 처리된 데이터를 최종적으로 어떤 형태로 저장할지 정하고, 외부에 출력하는 역할
  • DB에 저장하거나, 파일로 출력하거나, 외부 API로 전송하는 등의 작업을 수행
  • Reader와 달리 청크 단위로 데이터를 전달받아 처리

 

아래 코드는 팀 프로젝트에서 사용된 정산 처리 Step의 예시다. Settlement 데이터를 읽고, 상태를 변경한 뒤 DB에 반영하는 단일 Step으로, chunk(100)으로 설정된 만큼 데이터를 모아 한 번에 처리하고 커밋한다.

 

Step은 Reader → Processor → Writer 구조로 이루어져 있으며, 각 구성 요소는 다음과 같은 역할을 한다.

• Reader : status가 'READY'인 정산 데이터를 조회(커서 기반)
• Processor : 상태를 'COMPLETED'로 변경
• Writer : 변경된 상태를 DB에 반영 (UPDATE)

 

Spring Batch는 청크 단위로 트랜잭션을 관리하기 때문에, 하나의 청크가 실패하면 해당 청크만 롤백되고, Job은 중단되거나 재시작된다.

커서 기반 vs 페이징 기반 Reader

Spring Batch에서 데이터베이스로부터 대량의 데이터를 읽어올 때는 Reader 전략을 신중하게 선택해야 한다.
대표적으로 사용되는 방식은 커서 기반(Cursor-based) 과 페이징 기반(Paging-based) 두 가지다.
두 방식 모두 대량 처리에 사용되지만, 기술 스택과 데이터 특성, 트랜잭션 전략에 따라 적합한 상황이 다르다.

 

실무에서는 보통...

• 커서 기반은 JdbcCursorItemReader와 같은 JDBC 기반 방식
• 페이징 기반은 JpaPagingItemReader와 같은 JPA 기반 방식으로 구현된다.

아래는 두 방식의 차이를 정리한 표다.

항목	커서 기반(Cursor-based)	페이징 기반(Paging-based)
처리 방식	커서를 열고 전체 데이터를 순차적으로 읽음	일정 크기로 나누어 반복 쿼리로 읽음
쿼리 실행	1번 실행 후 커서 유지	여러 번 쿼리 실행(page 수만큼)
메모리 사용	전체 데이터를 가져와 메모리 부담 많음	매 페이지마다 작게 나누어 가져와 메모리 부담 적음
속도	커넥션 유지로 속도 빠름	다수의 쿼리로 인해 상대적으로 느림
데이터 정합성	처리 중 데이터 변경 없음	처리 중 데이터 변경 시 중복/누락 가능성 존재
트랜잭션 처리	트랜잭션 전체 유지	각 페이지 단위로 트랜잭션 분리 가능
커넥션 점유	전체 작업 동안 커넥션 점유	각 페이지마다 커넥션 연결/해제 가능
적합한 상황	정적인 대량 데이터 처리, 빠른 일괄 처리	변동 가능한 데이터, 병렬성/복원력 필요 시

 

JPA 기반 페이징은 엔티티 관리와 연관 관계 처리 등 ORM의 이점을 활용할 수 있지만, 대량 데이터를 처리할 때는 성능 저하나 메모리 부담이 발생할 수 있다. 반면, 커서 기반은 ResultSet을 열어 한 줄씩 데이터를 스트리밍 방식으로 처리하므로 메모리 사용이 효율적이고 처리 속도도 빠르다. 하지만 커넥션을 오래 점유하게 되므로, 병렬 처리나 재시작이 필요한 경우에는 제약이 크다. 결국, 어떤 방식이 더 낫다고 단정하기보다는 배치 잡의 특성과 시스템 구조에 맞게 전략을 선택하는 것이 중요하다.

청크(Chunk) 기반 처리

• 청크(Chunk) : 일정한 개수로 묶인 데이터 단위.
• 청크 기반 처리 방식 : 지정한 개수만큼 모아서(청크 단위로) 처리하고 한 번에 커밋하는 방식. 청크 단위로 트랜잭션을 관리하면 데이터 부하를 최소화하면서 대용량 데이터 처리가 가능하고 실패 시 롤백을 효과적으로 수행할 수 있음.

Spring Batch에서는 chunk(10)처럼 청크 크기를 지정해 설정하며, 각 청크는 다음 순서로 처리된다.

1. ItemReader가 데이터를 하나씩 읽는다.
2. 지정된 청크 크기만큼 모은다.
3. ItemProcessor로 데이터를 가공한다.
4. ItemWriter가 가공된 데이터를 한 번에 저장하고 커밋한다.

🗣️ Spring Batch의 Chunk와 Chunk 기반 방식에 대해 설명해주세요.
Spring Batch는 기본적으로 Chunk 기반 처리 방식을 사용합니다. Chunk는 데이터를 일정 개수로 묶은 단위이며, 이 단위로 트랜잭션을 커밋합니다. 예를 들어 chunk 크기를 100으로 설정하면, 데이터를 한 건씩 읽고 가공하되 100건이 모일 때까지는 커밋하지 않고, 100건이 쌓인 시점에 한 번에 저장하고 트랜잭션을 커밋하게 됩니다. 이 방식은 매 건마다 커밋하지 않기 때문에 트랜잭션 부하를 줄일 수 있고, 중간에 예외가 발생하더라도 청크 단위로만 롤백되기 때문에 전체 작업을 처음부터 다시 실행할 필요가 없습니다. Chunk 기반 구조는 트랜잭션 범위를 적절히 나눌 수 있고, 데이터를 일괄 처리하면서도 실패 복구가 가능한 실행 구조를 제공합니다.

멱등성 (Idempotency)

• 멱등성(Idempotency) : 같은 작업을 여러 번 수행해도 결과가 변하지 않는 성질.
• Spring Batch처럼 대량의 데이터를 청크 단위로 처리하고, 중간 실패 시 재시작이 가능한 구조에서는 멱등성을 보장하는 것이 데이터 정합성과 안정성을 유지하는 핵심 요소가 된다.

멱등성이 보장되지 않는다면?

• DB에 중복된 레코드가 insert됨(DB에 별도의 Unique 제약조건이 없는 경우)
• 이미 처리된 상태의 데이터를 다시 덮어씀
• 외부 시스템(API, 메시지 큐 등)에 중복 요청이 발생함

실제로는 ItemWriter 단계에서의 멱등성 보장이 가장 중요하다. Writer는 트랜잭션의 커밋 지점이기 때문에, 이 단계에서의 중복/불일치는 곧 데이터 정합성 문제로 직결된다. Writer뿐만 아니라 Reader와 Processor에서도 방어적으로 멱등성을 고려해두면 더 안정적인 설계가 가능하다.

 

아래는 SettlementRegisterJobConfig 클래스의 일부이다.

Reader와 Writer 각 단계에서 다음과 같은 방법으로 멱등성이 보장된다.

• Reader : 이미 settlement가 존재하는 payment는 조회되지 않음
• Writer : 별도의 중복 처리 로직 없이도 안전하게 INSERT 가능

🗣️ Spring Batch에서 멱등성은 어떻게 보장했나요?
Spring Batch는 청크 단위로 트랜잭션을 커밋하기 때문에 Step 도중 예외가 발생하거나 재시작되는 경우 동일한 데이터가 중복 처리될 수 있는 구조입니다. 그래서 멱등성을 보장하기 위해 Reader 단계에서부터 중복 가능성을 차단하는 조건을 명확히 설정했습니다. 예를 들어 정산 등록 Job에서는 payment 테이블에서 상태가 'DONE'이면서, 이미 settlement에 등록되지 않은 건만 조회하도록 LEFT JOIN + IS NULL 조건을 사용해 처리 대상을 선별했습니다. 정산 완료 Job에서는 settlement 테이블에서 status가 'READY'인 건만 조회해 상태를 'COMPLETED'로 업데이트하 하도록 구성했습니다. 이처럼 Reader에서 중복 대상을 제거하고, Writer는 ID 기반 처리를 통해 이미 처리된 데이터에 대해 다시 커밋되지 않도록 설계했습니다. 덕분에 Job이 재시작되더라도 데이터가 중복 저장되거나 상태가 반복 변경되는 문제 없이, 멱등성이 자연스럽게 보장되는 구조가 됩니다.