Spring Batch 도입기!! - @Scheduled로는 부족했다(#1)

저는 스프링 기반 백엔드 프로젝트에서 주기적인 작업을 @Scheduled 어노테이션으로 처리해왔습니다.

매일 주식 데이터를 수집하고, 경제지표 발표일에는 민감도 분석을 재실행하는 등, 배치성 작업이 하나둘 늘어나게 되었습니다.

그 당시에는 @Scheduled만으로도 충분하다고 생각했으나, 시간이 지나면서 작업이 점점 많아지고, 실패 복구나 실행 이력 관리가 필요해지면서 한계에 부딪히게 되었습니다.

 

위의 문제를 해결하고자, Spring Batch를 찾아보고 도입을 결정하게 되었습니다!

 

 

제가 리팩토링하고 있는 기존 프로젝트의 배치 작업들은 아래와 같습니다.

 

1. 초기 세팅

• 종목별 3년치 주식 데이터 저장 (차트/민감도 분석용)
• 주요 경제지표 3년치 이력 저장 (지표 일정 캘린더 및 분석용)

2. 매일 반복

• 매일 주식 마감 후 당일 데이터 수집 및 저장

3. 주기적 반복

• 지표 발표 이벤트 발생 시, 민감도 분석 재계산 로직 실행

 

 

왜 @Scheduled로는 부족했을까요?

1. 실행 이력 추적이 불가능했습니다

• 어떤 작업이 언제 실행되었고, 성공/실패했는지를 확인하기 위해 매번 로그를 뒤져야 했습니다.
• 에러가 발생하면 정확히 어느 지점에서 멈췄는지, 어떤 데이터가 문제였는지 파악하기가 쉽지 않았습니다.
  로그를 뒤지며 원인을 일일이 추적하기보다는, 더 명확하고 체계적인 추적 시스템이 필요하다고 느꼈습니다.

2. 실패 시 복구가 까다로웠습니다

• 중간에 실패하면 처음부터 전체 로직을 다시 실행해야 했고,
• 특정 종목 하나만 실패해도 전체 반복문에 영향을 주는 구조였습니다.

3. 작업 흐름 관리가 직관적이지 않았습니다

• 어떤 작업이 먼저 실행되어야 하고, 어떤 순서로 처리되는지 흐름을 눈으로 보기 어려웠습니다.
• 모든 제어가 메서드 레벨에서 수동으로 이뤄졌습니다.

4. 확장성과 안정성이 부족했습니다

• 점점 복잡해지는 작업 조건 (예: 조건부 실행, 병렬 처리 등)을 @Scheduled로는 관리하기 어렵다고 느꼈습니다.

 

 

🧠 그렇다면 Spring Batch는 뭐가 다를까요?

Spring Batch는 단순히 스케줄러를 대체하는 도구가 아닙니다.
대용량 데이터 처리, 작업 상태 저장, 실패 복구, 트랜잭션 관리, 실행 이력 추적 등
복잡한 배치 작업을 체계적으로 처리할 수 있는 프레임워크입니다.

• 실행 이력은 자동으로 DB에 저장됩니다 (BATCH_JOB_EXECUTION, BATCH_STEP_EXECUTION 등)
• 실패한 Step만 따로 재실행할 수 있습니다
• Job → Step → Reader/Processor/Writer 구조로 작업을 명확히 분리할 수 있습니다
• 상태 기반 트랜잭션 관리, 병렬 처리, 재시작 전략 등을 기본 제공합니다.

 

 

 

✅ 그래서 Spring Batch를 도입했습니다

사실 처음에는 단순히 주기적인 작업을 실행하는 데 초점이 있었습니다.
Spring Batch의 "대용량 데이터 처리"나 "복잡한 다단계 Step 구성"이 꼭 필요한 상황은 아니었어서 그 상황에선 적합한 판단이었다고 생각합니다.

하지만 점점 작업이 늘어나면서, 단순히 스케줄링만으로는 해결되지 않는 문제들이 생기기 시작했습니다.
- 언제 어떤 작업이 실행됐는지 확인하고 싶고,
- 중간에 실패했을 때 이어서 실행할 수 있어야 하고,
- 작업의 흐름을 더 구조화하고 싶다는 필요성이 생겼습니다.

 

그래서 Spring Batch를 기반으로 하나씩 리팩토링을 시작하게 되었습니다.

 

 

 

✍️ 다음 글 예고

다음 글에서는 제가 Spring Batch를 적용하면서 마주한 구조적 고민,,,
즉 Tasklet 방식과 Chunk 방식의 차이를 어떻게 이해하고 적용했는지를 중심으로 정리해보려고 합니다!

 

그럼 안뇽...