Spring Batch 도입기!! - Tasklet vs Chunk, 뭐가 다른데? (#2)

2025.07.03 - [💪Backend/Spring] - Spring Batch 도입기!! - @Scheduled로는 부족했다(#1)

 

👀 들어가며

Spring Batch를 도입한 후, 처음 마주한 실질적인 고민은 바로 이것이었습니다:

Tasklet을 써야 할까, Chunk를 써야 할까?

 

문서에도, 블로그에도 많은 설명이 있지만, 직접 적용하려 하니 헷갈리는 부분이 많았습니다.

 

 

• 종목별로 API를 호출해 3년치 데이터를 수집하고 저장하는 작업
• 매일 주식 마감 후 하루치 데이터를 갱신하는 작업

저는 위와 같은 작업들을 리팩토링 중이었습니다.

 

이 작업들에 어떤 방식을 선택하는 게 맞을까요?
이번 글에서는 Tasklet과 Chunk의 구조적 차이와 적용 기준을 정리해보려 합니다..!!

 

 

---

 

🧱 기본 개념

 

✅ Tasklet 기반

 

stepBuilderFactory.get("step")
    .tasklet((contribution, chunkContext) -> { 
        // 한 번에 전체 작업 수행 
        return RepeatStatus.FINISHED; 
     }) 
    .build();

• 단일 메서드에서 전체 작업 수행
• 반복문, API 호출, 파일 삭제 등 명령형 로직에 적합
• 작업 흐름이 단순하고 명확할 때 사용

 

✅ Chunk 기반

stepBuilderFactory.get("step")
    .<Input, Output>chunk(100)
    .reader(reader)
    .processor(processor)
    .writer(writer)
    .build();

• 대량 데이터를 작은 덩어리(chunk)로 나눠서 처리
• Reader → Processor → Writer 구조로 역할 분리
• 트랜잭션 단위로 처리 가능
• 상태 저장, 실패 복구, 병렬 처리 등에서 강력함

 

 

---

 

 

🔍 언제 무엇을 선택해야 할까?

 

	Tasklet	Chunk
구조	단일 메서드	Reader-Processor-Writer
적합한 작업	반복문, 단발성 API 호출	대용량 데이터 처리
트랜잭션	전체 작업 단위	Chunk 단위 트랜잭션
상태 저장	없음	가능 (Restart 지원)
병렬 처리	어렵거나 수동 구현	내장 기능 있음
대표 예시	파일 삭제, 디렉토리 정리, for문 순회	DB → 가공 → DB 저장

 

 

---

 

✋ 저의 고민 사례

Spring Batch를 도입하면서, 저는 먼저 3년치 주식 데이터를 저장하는 초기화 작업과 시가총액 계산, 섹터별 수익률 계산과 같은 후처리 작업들을 리팩토링하게 되었습니다.

 

이 과정에서 가장 먼저 마주한 고민이 글의 도입부였던.. 어떤 방식을 적용할지!에 대한 고민이었습니다.

 

처음엔 “Chunk가 더 정석적인 구조니까 무조건 써야 하지 않을까?”라는 생각도 들었지만, 직접 적용해보며 느낀 건 작업의 특성과 처리 대상에 따라 각 방식의 장단점이 분명히 존재한다는 것이었습니다.

 

---

 

✅ 종목 데이터 저장: Chunk 기반

 

이 작업은 3년치 주식 데이터를 섹터별 종목 기준으로 API 호출 → 가공 → DB/Redis 저장하는 초기화 과정입니다.
처리 대상도 많고, 동일한 작업을 반복적으로 수행해야 하기 때문에 자연스럽게 Chunk 기반으로 설계했습니다.

 

• Reader: 섹터별 종목 목록을 하나씩 반환
• Processor: 각 종목별로 API를 호출하고 응답값을 가공
• Writer: 결과 데이터를 DB와 Redis에 저장

 

이 구조를 Chunk로 구현한 이유는 다음과 같습니다:

• 섹터 단위 트랜잭션 분리 → 하나의 섹터에서 문제가 생겨도 다른 섹터에는 영향 없음
• faultTolerant() 설정을 통해 API 실패 재시도, 일부 종목 Skip 처리 가능성 확보
• Reader/Writer 구조를 기반으로 추후 병렬 처리 또는 분산 처리로 전환하기 쉬움

Chunk의 구조적 확장성과 회복력 확보!

 

---

 

✅ 시가총액 계산: Tasklet 기반

 

시가총액 계산은 각 종목의 종가 × 유통주식수를 계산해 저장하는 작업입니다.
종목 수는 많지만, 전체 흐름은 단순 계산 반복에 가깝고, 트랜잭션을 나눌 필요도, 상태를 추적할 필요도 없었습니다.

 

게다가 이 로직은 이미 서비스 레이어에 하나의 메서드로 구현되어 있었기 때문에 Tasklet 내부에서 해당 서비스 메서드를 한 번 호출하는 방식으로 간단하게 처리했습니다.

 

만약 처음부터 배치 전용 구조를 만들었다면 Chunk로 구성할 수도 있었겠지만, 기존 검증된 로직을 안정적으로 재사용하면서 필요한 만큼만 배치화한 것이 이번 상황에서는 더 효율적일 거라는 판단을 했습니다.

 

 

---

 

🧠 Tasklet vs Chunk – 속도? 구조? 복구?

처음에는 "Tasklet이 더 빠르지 않을까?"라는 생각도 했지만, 실제로 중요한 건 속도 자체보다는 작업의 성격에 맞는 구조를 선택하는 것이었습니다.

 

	Tasklet	Chunk
구조	단순 메서드 → 빠르게 구현 가능	명확한 단계 분리 (Reader-Processor-Writer)
복구/재시도	직접 try-catch 필요	retry(), skip() 등 내장 기능
트랜잭션	전체 작업 1트랜잭션	Chunk 단위로 분할 처리
적합한 경우	단순 반복, 계산, 명령형 로직	대량 반복, 안정성, 상태 추적 필요
확장성	제한적	병렬 처리, 분산 처리 등 용이

 

 

---

 

✅ 결론

결과적으로,

• 대량 데이터를 반복 처리하고, 향후 확장 가능성이 있는 작업에는 Chunk 기반
• 처리량이 적고 계산 중심이며, 이미 작성된 로직을 활용할 수 있는 작업에는 Tasklet 기반

을 적용하는 것이 제 프로젝트에서는 가장 효율적인 선택이었습니다.

 

---

 

✍️ 다음 글 예고

다음 글에서는 제가 어떻게 기존 스케줄러 중심의 구조를 Job 단위로 나누고, 어떤 작업을 어떤 Step으로 분리했는지를 정리해보려고 합니다.

 

 

굿바이..~.~