안녕하세요, Code Camp입니다.
지난 시간에 Spring Batch의 개념을 잡았다면, 오늘은 “Spring Batch가 실제로 어떻게 동작하는지” 뜯어볼 차례입니다.
Spring Batch의 아키텍처는 매우 견고하고 체계적입니다. 용어가 조금 낯설 수 있지만, 이 구조만 이해하면 Spring Batch의 90%를 이해한 것이나 다름없습니다.
목차
- 전체 아키텍처 다이어그램
- Job과 Step: 배치의 계층 구조
- JobRepository: 배치의 블랙박스
- JobLauncher: 배치의 실행 버튼
- ItemReader, Processor, Writer: 데이터 처리 삼총사
1. 전체 아키텍처 다이어그램
Spring Batch는 크게 3가지 레이어로 나뉩니다.
- Application: 개발자가 작성한 비즈니스 로직 (Job, Step)
- Core: 배치를 제어하는 핵심 엔진 (JobLauncher, JobRepository)
- Infrastructure: DB, 파일 I/O 등 (ItemReader, ItemWriter)
이 중에서 우리는 Core 영역의 컴포넌트들이 어떻게 상호작용하는지 알아야 합니다.
2. Job과 Step: 배치의 계층 구조
Job (일감)
- 배치 작업의 전체 단위입니다. (예: ‘일일 정산 Job’)
- 하나의 Job은 여러 개의 Step으로 구성됩니다.
Step (단계)
- Job 내부의 실제 작업 단위입니다.
- Step 안에서 데이터를 읽고(Read), 가공하고(Process), 씁니다(Write).
- Step의 종류:
Tasklet Step: 단순 작업 (예: 파일 삭제)Chunk-oriented Step: 대용량 데이터 처리 (Read-Process-Write)
[ Job: 일일 정산 ]
├── Step 1: 파일에서 데이터 읽기 (Tasklet)
└── Step 2: DB에 정산 결과 저장 (Chunk)
3. JobRepository: 배치의 블랙박스
Spring Batch가 강력한 이유는 바로 JobRepository 덕분입니다.
이 녀석은 배치가 실행될 때마다 모든 상태 정보를 DB에 기록합니다.
- JobInstance: Job의 논리적 실행 (예: “2월 2일 정산”)
- JobExecution: Job의 실제 시도 (예: “2월 2일 정산 – 첫 번째 시도(실패)”, “두 번째 시도(성공)”)
- StepExecution: Step별 실행 상태 (읽은 건수, 쓴 건수, 실패 횟수 등)
이 정보들이 DB에 남아있기 때문에, 서버가 죽었다 살아나도 “어제 실패한 그 지점”을 정확히 알고 재시작할 수 있는 것입니다.
4. JobLauncher: 배치의 실행 버튼
이름 그대로 Job을 실행(Launch)시키는 역할을 합니다.
JobLauncher에게 Job과 파라미터(JobParameters)를 넘기면, JobRepository를 통해 실행 기록을 남기고 비로소 Job을 시작합니다.
5. ItemReader, Processor, Writer: 데이터 처리 삼총사
Chunk 지향 처리(Chunk-oriented Processing)에서 가장 중요한 3가지 인터페이스입니다.
ItemReader:
- 데이터를 하나씩(read) 읽어옵니다.
- 더 이상 읽을 게 없으면
null을 반환합니다.
ItemProcessor:
- 읽어온 데이터를 가공하거나 필터링합니다.
null을 반환하면 해당 데이터는 Writer로 넘어가지 않고 제외됩니다.
ItemWriter:
- Processor를 통과한 데이터를 모아서(List) 한 번에 처리합니다.
- Chunk Size가 10이라면, 10개의 아이템이 모였을 때
write()메서드가 호출됩니다.
마치며
Spring Batch의 아키텍처는 “상태를 저장한다(JobRepository)”와 “나눠서 처리한다(Chunk)”는 두 가지 핵심 철학으로 요약할 수 있습니다.
이 구조가 머릿속에 그려진다면, 이제 복잡한 배치 코드도 두렵지 않으실 겁니다.
다음 마지막 시간에는 많은 분들이 헷갈려하시는 Spring Batch와 Spring Scheduler의 차이점을 명확히 정리해 드리겠습니다.
감사합니다!
