03. Spring Scheduler와 Spring Batch 기본 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• Spring Scheduler와 Spring Batch는 어떤 문제를 각각 해결하는가?
• 단순 반복 작업과 재시작 가능한 대량 작업을 어떻게 구분하는가?
• chunk, reader, processor, writer, job repository가 필요한 상황은 언제인가?
• 개인 프로젝트에서 Spring Batch 없이도 어떤 운영 흔적을 남겨야 하는가?

개요

Spring Scheduler는 정해진 시각이나 주기마다 method를 호출하는 기능이다.

Spring Batch는 대량 데이터를 읽고, 처리하고, 쓰는 작업을 job과 step으로 관리하는 프레임워크다.

둘은 경쟁 관계가 아니다.

Scheduler는 trigger에 가깝고, Batch는 처리 모델에 가깝다.

단순한 점검 작업은 Scheduler만으로 충분할 수 있다.

재시작, chunk transaction, reader/writer, 처리 이력, skip/retry가 필요하면 Spring Batch를 검토한다.

선택 기준

질문	Spring Scheduler	Spring Batch
주 목적	주기적 실행	대량 처리 모델
처리량	작음	큼
상태 관리	직접 구현	JobRepository 제공
재시작	직접 구현	Step/Execution metadata
transaction	method 단위	chunk 단위
예시	만료 플래그 정리	일별 정산, backfill

도구 선택은 팀 규모보다 작업 성격으로 판단한다.

Spring Scheduler 예시

@Scheduled(fixedDelayString = "PT5M")
public void expireCoupons() {
    int affected = couponRepository.expireBefore(Instant.now());
    log.info("expired coupons={}", affected);
}

이 작업은 짧고 단순하다.

실패해도 다음 주기에 다시 처리할 수 있고, 별도 chunk 상태가 크게 필요하지 않을 수 있다.

하지만 처리 건수가 많아지고 실행 시간이 길어지면 Batch 모델이 필요해진다.

Spring Batch 예시

@Bean
Job settlementJob(JobRepository jobRepository, Step settlementStep) {
    return new JobBuilder("settlementJob", jobRepository)
        .start(settlementStep)
        .build();
}
 
@Bean
Step settlementStep(JobRepository jobRepository,
                    PlatformTransactionManager transactionManager,
                    ItemReader<PaymentRow> reader,
                    ItemProcessor<PaymentRow, SettlementRow> processor,
                    ItemWriter<SettlementRow> writer) {
    return new StepBuilder("settlementStep", jobRepository)
        .<PaymentRow, SettlementRow>chunk(1000, transactionManager)
        .reader(reader)
        .processor(processor)
        .writer(writer)
        .build();
}

Spring Batch는 처리 범위를 chunk로 나눈다.

chunk마다 transaction을 나눌 수 있고, job execution과 step execution metadata를 남긴다.

대량 처리 중 실패했을 때 운영자가 어느 job execution에서 실패했는지 확인할 수 있다.

Job Parameter

batch는 실행 parameter가 중요하다.

jobName=settlementJob
targetDate=2026-06-30
requestedBy=scheduler

같은 job이라도 targetDate가 다르면 다른 실행이다.

parameter를 기록하지 않으면 재실행 범위가 기억에 의존한다.

처리 이력

Spring Batch는 기본적으로 job metadata table을 사용한다.

대표적으로 다음 정보가 남는다.

• job instance
• job execution
• step execution
• status
• start time
• end time
• exit message

이 metadata는 장애 대응의 출발점이다.

다만 business 검증 결과는 별도 table이나 로그로 남기는 편이 좋다.

판단 축

• 작업이 짧고 idempotent하면 Scheduler만으로 시작한다.
• 대량 처리, chunk, restart, skip/retry가 필요하면 Spring Batch를 검토한다.
• Scheduler method 안에 대량 loop가 커지면 Batch 전환 신호다.
• Batch job parameter는 target range를 명확히 담아야 한다.
• JobRepository 성공과 데이터 품질 성공을 분리한다.

실패 모델

• Scheduler method가 30분 이상 실행되어 다음 실행과 겹친다.
• 대량 update를 한 transaction으로 처리해 lock과 rollback 비용이 커진다.
• Spring Batch를 쓰지만 job parameter가 없어 어떤 날짜를 처리했는지 모른다.
• JobRepository는 성공인데 target table count가 맞지 않는다.
• skip 정책이 과해 실패 데이터를 조용히 버린다.

운영 지표

• scheduled_method_duration: Scheduler 작업 실행 시간이다.
• batch_job_execution_status: Spring Batch job 상태다.
• step_read_count: reader가 읽은 건수다.
• step_write_count: writer가 쓴 건수다.
• step_skip_count: skip된 건수다.
• business_validation_failed_count: job 성공 후 품질 검증 실패 수다.

개인 프로젝트 기준

처음에는 Spring Scheduler와 직접 만든 job_run_history table로 충분할 수 있다.

하지만 처리 건수가 많아지고 실패 후 재시작이 복잡해지면 Spring Batch를 도입할 근거가 생긴다.

도입 전에도 target range, processed count, error message는 남긴다.

기업 운영 기준

기업 운영에서는 Spring Batch metadata table만 믿으면 부족하다.

운영자는 business key, target partition, 검증 SQL, 재처리 권한을 함께 알아야 한다.

Batch job 변경은 DB 부하, chunk size, lock 범위, retry 정책까지 리뷰한다.

실전 팁

• @Scheduled는 trigger로만 두고 대량 처리 로직은 service나 job으로 분리한다.
• Spring Batch job parameter에는 날짜 범위나 id 범위를 명시한다.
• chunk size는 처리량과 lock 시간을 함께 보고 정한다.
• skip을 허용하면 skip된 row를 별도 저장소에 남긴다.
• Batch 성공 후 count/sum/freshness 검증을 따로 실행한다.

위험 신호!

• Scheduler method 하나가 reader, transform, writer, alert를 모두 직접 처리한다.
• 실패하면 운영자가 로그를 보고 수동 SQL로 이어서 처리한다.
• Batch job이 매번 같은 parameter로 실행되어 재실행 구분이 안 된다.
• skip count가 늘어도 알림이 없다.
• Spring Batch를 쓴다는 이유로 멱등 writer를 생략한다.

확인 질문

확인 질문

• Spring Scheduler와 Spring Batch의 가장 큰 차이는 무엇인가?
  • Scheduler는 실행 trigger이고, Spring Batch는 대량 처리와 재시작을 위한 job/step 모델이다.
• Spring Batch를 검토해야 하는 신호는 무엇인가?
  • 대량 처리, 긴 실행 시간, chunk transaction, 실패 재시작, skip/retry, 처리 이력이 필요할 때다.
• JobRepository 성공만으로 충분하지 않은 이유는 무엇인가?
  • job 실행은 끝났어도 target row count, 금액 합계, freshness 같은 business 검증이 실패할 수 있기 때문이다.

참고 문서

• Spring Batch Reference
• Spring Framework Reference, Task Execution and Scheduling
• Spring Boot Actuator Metrics
• Martin Kleppmann, Designing Data-Intensive Applications