fos-blog/study
01 / 홈02 / 카테고리
01 / 홈02 / 카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • langgraph 페이지로 이동
    • agents.md
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code를 5주 더 쓴 결과 — 스킬·CLAUDE.md를 키워가는 방식
    • Claude Code를 11일 동안 쓴 결과 — 데이터로 본 나의 사용 패턴
    • Claude Code 멀티 에이전트 — Teams
    • AI 에이전트와 디자인의 새 컨벤션 — DESIGN.md, Google Stitch, Claude Design
    • 하네스 엔지니어링 실전 — 4인 에이전트 팀으로 코딩 파이프라인 구축하기
    • 하네스 엔지니어링 — 오래 실행되는 AI 에이전트를 위한 설계
    • 멀티모달 LLM (Multimodal Large Language Model)
    • AI 에이전트와 함께 MVP 만들기 — dooray-cli 사례
  • ai 페이지로 이동
    • agent 페이지로 이동
  • algorithm 페이지로 이동
    • live-coding 페이지로 이동
    • 분산 계산을 위한 알고리즘
  • architecture 페이지로 이동
    • [초안] 시니어 백엔드를 위한 API 설계 실전 스터디 팩 — REST · 멱등성 · 페이지네이션 · 버전 전략
    • [초안] API Versioning과 Backward Compatibility: 시니어 백엔드 관점 정리
    • 캐시 설계 전략 총정리
    • [초안] CJ푸드빌 커머스/F&B 도메인 설계 면접 대비 — 슬롯 경험을 주문·결제·쿠폰·매장 상태 설계로 번역하기
    • [초안] 커머스 Spring 서비스에 Clean/Hexagonal Architecture를 실용적으로 적용하기
    • [초안] 커머스 주문 상태와 데이터 정합성 기본기 — CJ푸드빌 면접 대비
    • [초안] 쿠폰/프로모션 동시성과 정합성 기본기 — 선착순·중복 사용 방지·발급/사용/복구
    • [초안] DDD와 도메인 모델링: 시니어 백엔드 관점의 전술/전략 패턴 실전 가이드
    • [초안] Decorator & Chain of Responsibility — 행동을 체인으로 조립하는 두 가지 방식
    • 디자인 패턴
    • [초안] 분산 아키텍처 완전 정복: Java 백엔드 시니어 인터뷰 대비 실전 가이드
    • [초안] 분산 트랜잭션과 Outbox 패턴 — 왜 2PC를 피하고 어떻게 대신할 것인가
    • 분산 트랜잭션
    • [초안] e-Commerce 주문·결제 도메인 모델링: 상태머신, 멱등성, Outbox/Saga 실전 정리
    • [초안] F&B 쿠폰·프로모션·멤버십·포인트 설계
    • [초안] F&B · e-Commerce 디지털 채널 도메인 한 장 정리 — CJ푸드빌 디지털 채널 백엔드 면접 대비
    • [초안] F&B 주문/매장/픽업 상태머신 설계 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] F&B 이커머스 결제·환불·정산 운영 가이드
    • [초안] Hexagonal / Clean Architecture를 Spring 백엔드에 적용하기
    • [초안] 대규모 커머스 트래픽 처리 패턴 — 1,600만 고객과 올영세일을 버티는 설계
    • [초안] 레거시 JSP/jQuery 화면과 신규 API가 공존하는 백엔드 운영 전략
    • [초안] MSA 서비스 간 통신: Redis [Cache-Aside](../database/redis/cache-aside.md) × Kafka 이벤트 하이브리드 설계
    • [초안] Observability 입문: 시니어 백엔드가 장애를 탐지하고 대응하는 방식
    • [초안] Outbox / Inbox Pattern 심화 — 분산 메시징의 정합성 문제를 DB 트랜잭션으로 풀어내기
    • [초안] 결제 도메인 멱등성과 트랜잭션 재시도 기본기
    • [초안] 시니어 백엔드를 위한 Resilience 패턴 실전 가이드 — Timeout, Retry, Circuit Breaker, Bulkhead, Backpressure
    • [초안] REST API 버저닝과 모바일 앱 하위 호환성 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] Strategy Pattern — 분기문을 없애는 설계, 시니어 백엔드 인터뷰 핵심 패턴
    • [초안] 시니어 백엔드를 위한 시스템 설계 입문 스터디 팩
    • [초안] 템플릿 메서드 패턴 - 백엔드 처리 골격을 강제하는 가장 오래되고 가장 위험한 패턴
    • [초안] 대규모 트래픽 중 무중단 마이그레이션 — Feature Flag + Shadow Mode 실전
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야 할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • [초안] JPA N+1과 커머스 조회 모델: 주문/메뉴/쿠폰 도메인에서 살아남기
    • [초안] MyBatis 기본기 — XML Mapper, resultMap, 동적 SQL, 운영 패턴 정리
    • [초안] MyBatis와 JPA/Hibernate 트레이드오프 — 레거시 백엔드를 다루는 시니어 관점
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • observability 페이지로 이동
    • [초안] 커머스/F&B 채널 장애 첫 5분과 관측성 기본기
    • Envoy Proxy
    • [초안] F&B / e-Commerce 운영 장애 대응과 모니터링 — 백엔드 관점 정리
    • Graceful Shutdown
  • finance 페이지로 이동
    • industry-cycle 페이지로 이동
    • investing 페이지로 이동
    • stock-notes 페이지로 이동
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • [초안] AI 서비스 팀 경험 기반 시니어 백엔드 면접 질문 뱅크 — Spring Batch RAG / gRPC graceful shutdown / 전략 패턴 / 12일 AI 웹툰 MVP
    • [초안] CJ푸드빌 디지털 채널 Back-end 개발자 직무 분석
    • [초안] CJ푸드빌 디지털 채널 Back-end 면접 답변집 — 슬롯 도메인 경험을 커머스/F&B 설계로 번역하기
    • [초안] F&B / e-Commerce 운영 모니터링과 장애 대응 인터뷰 정리
    • Observability — 면접 답변 프레임
    • [초안] 시니어 Java 백엔드 면접 마스터 플레이북 — 김병태
    • [초안] NSC 슬롯팀 경험 기반 질문 은행 — 도메인 모델링·동시성·성능·AI 협업
  • java 페이지로 이동
    • concurrency 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • [초안] Java 동시성 락 정리 — 커머스 메뉴/프로모션 정책 캐시 갱신 관점
    • [초안] JVM 튜닝 실전: 메모리 구조부터 Virtual Threads, GC 튜닝, 프로파일링까지
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node 백엔드 운영 패턴 — Streams 백프레셔, pipe/pipeline, 멱등성 vs 분산 락
    • Node.js
    • npm vs pnpm — 어떤 기준으로 선택했나
    • `setImmediate()`
  • kafka 페이지로 이동
    • [초안] Kafka 기본 개념 — 토픽, 파티션, 오프셋, 복제
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • [초안] Kafka 실전 설계: 파티션 전략, 컨슈머 그룹, 전달 보장, 재시도, 순서 보장 트레이드오프
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • rabbitmq 페이지로 이동
    • [초안] RabbitMQ Basics — 실전 백엔드 관점에서 정리하는 메시지 브로커 기본기
    • [초안] RabbitMQ vs Kafka — 백엔드 메시징 선택 기준과 실전 운영 관점
  • security 페이지로 이동
    • [초안] 시니어 백엔드를 위한 보안 / 인증 스터디 팩 — Spring Security, JWT, OAuth2, OWASP Top 10
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • sb-dev-team 페이지로 이동
    • the-future-company 페이지로 이동
  • testing 페이지로 이동
    • [초안] 시니어 Java 백엔드를 위한 테스트 전략 완전 정리 — 피라미드부터 TestContainers, 마이크로벤치, Contract까지
  • travel 페이지로 이동
    • 오사카 3박 4일 일정표: 우메다 쇼핑, USJ, 난바·도톤보리, 오사카성
  • web 페이지로 이동
    • [초안] HTTP / Cookie / Session / Token 인증 기본기 — 레거시 JSP와 모바일 API가 공존하는 백엔드 관점
FOS-BLOG · FOOTERall systems normal·v0.1 · 2026.04.27·seoul, kr
Ffos-blog/study

개발 학습 기록을 정리하는 블로그입니다. 공부하면서 기록하고, 기록하면서 다시 배웁니다.

visitors
01site
  • Home↗
  • Posts↗
  • Categories↗
  • About↗
02policy
  • 소개/about
  • 개인정보처리방침/privacy
  • 연락처/contact
03categories
  • AI↗
  • Algorithm↗
  • DB↗
  • DevOps↗
  • Java/Spring↗
  • JS/TS↗
  • React↗
  • Next.js↗
  • System↗
04connect
  • GitHub@jon890↗
  • Source repositoryjon890/fos-study↗
  • RSS feed/rss.xml↗
  • Newsletter매주 1 회 · 한 편의 글→
© 2026 FOS Study. All posts MIT-licensed.
built with·Next.js·Tailwind v4·Geist·Pretendard·oklch
fos-blog/java/Spring Batch Listener
java

Spring Batch Listener

- 리스너는 배치 처리의 주요 순간들을 관찰하고, 각 시점에 필요한 동작을 정의할 수 있는 도구 - 배치 처리 중 발생하는 특정 이벤트를 감지하고 원하는 로직을 실행 할 수 있게 해줌 - Job 시작 전후, Step 실행 전후는 물론, 청크 단위 또는 아이템 단위 처리 시점까지 모든 과정에 개입할 수 있음 - 이를 통해 로깅, 모니터링, 에러 처리등 우리가...

2026.02.25·6 min read·70 views
  • 리스너는 배치 처리의 주요 순간들을 관찰하고, 각 시점에 필요한 동작을 정의할 수 있는 도구
  • 배치 처리 중 발생하는 특정 이벤트를 감지하고 원하는 로직을 실행 할 수 있게 해줌
  • Job 시작 전후, Step 실행 전후는 물론, 청크 단위 또는 아이템 단위 처리 시점까지 모든 과정에 개입할 수 있음
  • 이를 통해 로깅, 모니터링, 에러 처리등 우리가 원하는 로직을 자유롭게 추가 가능

JobExecutionListener

  • Job 실행의 시작과 종료 시점에 호출되는 리스너 인터페이스
java
public interface JobExecutionListener {
    default void beforeJob(JobExecution jobExecution) { }
    default void afterJob(JobExecution jobExecution) { }
}
  • beforeJob()
    • Job 실행 직전 호출
    • 필요한 리소스 준비등의 초기화 작업을 수행할 수 있음
  • afterJob()
    • Job 실행 후에 호출
    • Job 실행 결과를 이메일로 전송, 리소스를 정리하는 등의 후처리 작업을 수행할 수 있음
    • Job의 성공/실패 여부와 관계없이 무조건 호출

StepExecutionListener

  • Step의 실행 시작과 종료 시점에 호출되는 리스너 인터페이스
  • Step의 시작 시간, 종료 시간, 처리된 데이터 수를 로그로 기록하는 등의 사용자 정의 작업 추가 가능
java
public interface StepExecutionListener extends StepListener {
    default void beforeStep(StepExecution stepExecution) {}
 
    @Nullable
    default ExitStatus afterStep(StepExecution stepExecution) {
        return null;
    }
}
  • beforeStep()
    • Step의 시작 시점, 정확히는 StepScope가 활성화된 직후에 호출
  • afterStep() – Step의 종료 시점에 호출
    • JobExecutionListener의 afterJob()과 마찬가지로 Step의 성공/실패 여부와 관계없이 무조건 호출

ChunkListener

  • 청크 단위 처리가 시작되기 전, 완료된 후, 실행 도중 에러가 발생했을 때 호출되는 리스너 인터페이스
java
public interface ChunkListener extends StepListener {
    default void beforeChunk(ChunkContext context) { }
    default void afterChunk(ChunkContext context) { }
    default void afterChunkError(ChunkContext context) { }
}
  • afterChunk()
    • 트랜잭션이 커밋된 후에 호출
  • afterChunkError()
    • 청크 트랜잭션이 롤백된 이후에 호출

Tasklet 지향 Step에서도 동작한다.

  • 이름과 달리 ChunkListener는 청크 지향 Step뿐만 아니라 Tasklet 지향 Step에서도 동작
  • Tasklet의 execute() 호출 전후, 그리고 execute() 실행 중 오류 발생 시에도 실행 됨
  • Tasklet 지향 Step에서도 ChunkListener를 활용한 모니터링이 가능
  • execute()에서 RepeatStatus.CONTINUABLE을 반환하면 execute() 실행이 반복되므로, 해당 범위로 동작

Item[Read|Process|Write]Listener

  • 아이템 읽기, 처리, 쓰기 작업이 수행되는 시점에 호출되는 리스너 인터페이스
java
public interface ItemReadListener<T> extends StepListener {
    default void beforeRead() { }
    default void afterRead() { }
    default void onReadError(Exception ex) { }
}
 
public interface ItemProcessListener<T, S> extends StepListener {
    default void beforeProcess(T item) { }
    default void afterProcess(T item, @Nullable S result) { }
    default void onProcessError(T item, Exception e) { }
}
 
public interface ItemWriteListener<S> extends StepListener {
    default void beforeWrite(Chunk<? extends S> items) { }
    default void afterWrite(Chunk<? extends S> items) { }
    default void onWriteError(Exception exception, Chunk<? extends S> items) { }
}
  • 눈여겨봐야 할 포인트
    • ItemReadListener.afterRead()는 ItemReader.read() 호출 후에 호출되지만, ItemReader.read() 메서드가 더 이상 읽을 데이터가 없어 null을 반환할 떄는 호출되지 않음
    • ItemProcessListener.afterProcess는 ItemProcessor.process() 메서드가 null을 반환하더라도 호출된다.
      • 참고로 ItemProcessor에서 null을 반환하는 것은 해당 데이터를 필터링하겠다는 의미
    • ItemWriteListener.afterWrite()는 트랜잭션이 커밋되기 전, 그리고 ChunkListener.afterChunk()가 호출되기 전에 호출된다

여기까지의 흐름도

전체 Job / Step 실행 흐름

text
            +----------------+
            |  JobLauncher   |
            +----------------+
                    |
                    | beforeJob()
                    v
              +-------------+
              |     Job     |
              +-------------+
                    |
                    | beforeStep()
                    v
              +-------------+
              |    Step     |
              +-------------+
                    |
                    | beforeChunk()
                    v
        ==================================
        ||        Chunk #N              ||
        ==================================
                    |
                    v
              [ Item Processing ]
                    |
                    ^
                    | afterChunk()
              +-------------+
              |    Step     |
              +-------------+
                    |
                    | afterStep()
                    v
              +-------------+
              |     Job     |
              +-------------+

Chunk 내부 상세 흐름 (Reader -> Processor -> Writer)

text
+--------------------------------------------------+
|                    Chunk #N                      |
|                                                  |
|   beforeRead()                                   |
|        |                                         |
|        v                                         |
|      read()      --- 반복 ---                    |
|        |                                         |
|   afterRead()                                    |
|                                                  |
|   beforeProcess()                                |
|        |                                         |
|        v                                         |
|     process()   --- 반복 ---                     |
|        |                                         |
|   afterProcess()                                 |
|                                                  |
|   beforeWrite()                                  |
|        |                                         |
|        v                                         |
|      write()    (List 단위)                      |
|        |                                         |
|   afterWrite()                                   |
|                                                  |
+--------------------------------------------------+

리스너 활용

  • 단계별 모니터링과 추적
    • Job과 Step 실행 전후에 로그를 남길 수 있음
    • Step이 언제 시작하고, 언제 끝났는지, 몇 개의 데이터를 처리했는지를 기록하고 추적 가능
  • 실행 결과에 따른 후속 처리
    • 예를 들어, Job의 종료 상태를 확인하고 종료 상태에 따른 후속 조치를 취할 수 있음
  • 데이터 가공과 전달
    • 예를 들어, Step 간에 데이터를 전달하거나, 다음 처리에 필요한 정보를 미리 준비할 수 있음
  • 부가 기능 분리
    • 예를 들어, 오류가 발생한 경우 메서드에서 관리자에게 알림 메일 보내는 등의 부가적인 일을 분리할 수 있음

왜 JobParameters가 아닌 ExecutionContext를 사용할까?

  • 한 번 생성된 JobParameters는 변경할 수 없기 때문
  • Spring Batch의 핵심 철학 중 하나는 배치 작업의 재현 가능성(Repeatability)과 일관성(Consistency)을 보장하는 것

  • 이를 위해 JobParameters는 불변(immutable)하게 설계되었음
    • 재현 가능성 : 동일한 JobParameters로 실행한 Job은 항상 돌일한 결과를 생성해야 함
      • 실행 중간에 JobParameters가 변경되면 이를 보장할 수 없음
    • 추적 가능성 : 배치 작업의 실행 기록(JobInstance, JobExecution)과 JobParamteres는 메타데이터 저장소에 저장
      • JobParamteres가 변경 가능하다면 기록과 실제 작업의 불일치가 발생할 수 있음
  • 따라서 Job 실행 중에 동적으로 생성되거나 변경되어야 하는 데이터는 ExecutionContext를 통해 관리하는 것이 좋음
    • 주의할점은 JobParameters만으로 충분히 처리할 수 있는 경우에도 JobExecution으로 처리하는 경우가 있는데 이렇게는 하지 말자
    • 예를 들어, 타겟 날짜를 JobExecution으로 관리해버리면, 재 처리가 불가능하다.
    • 하드 코딩된 방식은 배치의 유연성을 떨어뜨리고, 필요한 순간에 원하는 데이터를 처리할 수 없게 만듬

ExecutionContextPromotionListener를 활용한 Step 간 데이터 공유

  • ExecutionContextPromotionListener는 Step 수준 ExecutionContext의 데이터를 Job 수준 ExecutionContext로 등록시켜주는 StepExecutionListener의 구현체
java
@Bean
public ExecutionContextPromotionListener promotionListener() {
    ExecutionContextPromotionListener listener = new ExecutionContextPromotionListener();
    listener.setKeys(new String[]{"data"});  // data 키를 승격 대상으로 지정
    return listener;
}
  • 불가피한 경우가 아니라면 Step 간 데이터 의존성은 최소화하는 것이 좋다

Listener와 @JobScope, @StepScope 통합

  • 리스너와 Spring Batch Scope를 통합하면 리스너에서 잡 파라미터를 매우 쉽게 다룰 수 있음
  • 실행 시점에 결정되는 값들을 리스너내에서도 활용할 수 있다

Listener 마지막 훈련 : 성능과 모범 사례

어떤 리스너를 선택해야 하는가?

  • JobExecutionListener : 전체 Job의 시작과 종료를 통제
  • StepExecutionListener : 각 Step의 단계 실행을 감시
  • ChunkListener : 시스템을 청크단위로 처리할 때, 반복의 시작과 종료 시점을 통제
  • Item[Read|Process|Write]Listener : 개별 아이템 식별 통제

예외 처리는 신중하게

  • JobExecutionListener의 beforeJob()과 StepExecutionListener의 beforeStep()에서 예외가 발생하면 Job과 Ste이 실패한 것으로 판단 됨

단일 책임 원칙 준수

  • 리스너는 감시와 통제만 담당
  • 실제 비즈니스 로직은 분리하자
  • 리스너가 너무 많은 로직을 담당하면 유지보수가 어려워짐
on this page
  • 01JobExecutionListener
  • 02StepExecutionListener
  • 03ChunkListener
  • Tasklet 지향 Step에서도 동작한다.
  • 04Item[Read|Process|Write]Listener
  • 05여기까지의 흐름도
  • 전체 Job / Step 실행 흐름
  • Chunk 내부 상세 흐름 (Reader -> Processor -> Writer)
  • 06리스너 활용
  • 07왜 JobParameters가 아닌 ExecutionContext를 사용할까?
  • 08ExecutionContextPromotionListener를 활용한 Step 간 데이터 공유
  • 09Listener와 @JobScope, [@StepScope](step-scope.md) 통합
  • 10Listener 마지막 훈련 : 성능과 모범 사례
  • 어떤 리스너를 선택해야 하는가?
  • 예외 처리는 신중하게
  • 단일 책임 원칙 준수

댓글 (0)