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/죽음의 스프링 배치
java

죽음의 스프링 배치

들어가기에 앞서서 배치란 무엇인지부터 살펴보자. 배치(Batch) 처리는 대량의 데이터를 정해진 시간에 자동으로 일괄 처리하고 결과를 출력하는 작업을 말한다. 실제 예시를 들어보자면, 매일 새벽 4시, 서버 점검 시간이 되면 전날의 유저 로그를 분석하고, 랭킹을 업데이트하고, 불법 프로그램 사용자를 검출하는 작업 등이 있을 수 있다. 이걸 사람이 직접 처리...

2026.02.25·7 min read·67 views

들어가기에 앞서서 배치란 무엇인지부터 살펴보자.

배치 처리란?

배치(Batch) 처리는 대량의 데이터를 정해진 시간에 자동으로 일괄 처리하고 결과를 출력하는 작업을 말한다.

실제 예시를 들어보자면, 매일 새벽 4시, 서버 점검 시간이 되면 전날의 유저 로그를 분석하고, 랭킹을 업데이트하고, 불법 프로그램 사용자를 검출하는 작업 등이 있을 수 있다.

이걸 사람이 직접 처리는 불가능하다. 그건 자살 행위나 다름없다.


여기서 배치 처리가 등장한다. 정해진 시간이 되면 이 모든 작업이 자동으로 처리된다.

배치 처리의 특징을 더 자세히 보자

  • 대용량 데이터 처리
    • 배치는 대량의 데이터를 효율적으로 처리한다.
    • 웹 에플리케이션이 특정 ID의 데이터 하나를 조회하거나 수정한다면, 배치는 수천, 수만 개의 데이터를 한 번에 처리
  • 정기적 실행
    • 매일, 매주, 매달 등 정해진 시간에 실행된다.
  • 자동화
    • 한 번 만들고 설정해두면 알아서 모든 것을 처리한다.
    • 인간의 개입 없이 완벽하게 작동하는 자율 처리 시스템이다.
  • 무인 처리
    • 사람이 옆에서 지켜보지 않아도 된다.
    • 대부분의 처리는 심야에 이루어진다.
  • 유연한 양의 데이터 처리
    • 배치는 정해진 양의 데이터만 처리한다.
    • 오늘의 거래 데이터, 이번 주의 로그, 지난달의 매출 등 처리할 대상이 명확하다.
  • 예측 가능한 부하 처리
    • 배치는 시스템의 처리 능력에 맞게 설계된다.
    • 시스템이 감당할 수 있는 만큼의 데이터만 처리하도록 설계해야 한다.
    • CPU, 메모리, SSD... 이 모든 것을 신중하게 선택해야 한다.
    • 이러한 준비 과정을 거치면 시스템 다운은 없다.

실무 배치 사례들

  • 일일 정산 배치
    • 매일 밤 자정, 어김없이 실행된다.
    • 하루 동안의 거래 내역, 결제 정보, 사용자 활동 로그를 모두 정리하고 집계한다.
  • 대용량의 데이터 마이그레이션
    • 시스템 업그레이드나 DB 변경 시 수행되는 대규모 작업이다.
    • 수백만, 수천만 건의 데이터를 새로운 저장소로 안전하게 이동시켜야 한다.
    • 한 번의 실수가 전체 시스템을 마비시킬수 있는 고난도 처리 작업이다.
  • 리포트 생성 배치
    • 데이터를 모아 주기적으로 리포트를 만들어낸다.
    • 이 리포트는 보통 이메일, 알림 메시지 등의 형태로 전달된다.
  • 데이터 정제 배치
    • 중복된 데이터를 제거하거나 형식을 통일하여 데이터 품질을 개선하는 작업이다.
    • 이 배치는 오래된 데이터나 부정확한 데이터를 정리해 시스템의 신뢰성과 성능을 높이는 데 기여한다.
  • 백업 배치
    • 정기적으로 데이터를 백업하여 시스템 장애나 데이터 손실에 대비하는 작업이다.
    • 이 과정은 예기치 못한 문제 발생 시 데이터를 복구하고 서비스를 빠르게 정상화하기 위한 안전망 역할을 한다.
  • 데이터 통합 배치
    • 여러 데이터 저장소에서 데이터를 수집하여 하나의 일관된 데이터 싱태로 만드는 대규모 작업이다.
    • 이 과정은 데이터의 정합성을 유지하고, 다양한 서비스에서 통합된 최신 데이터를 활용할 수 있도록 한다.

여기까지 왔다면, 배치 처리의 세계가 낯설고 다르다는 것을 느꼈을 것이다.
보통 웹 애플리케이션 개발은 RESTful API를 만들고, 데이터베이스랑 통신하고, 사용자의 요청을 처리하는게 전부였다.
하지만 배치 처리는 다르다. 평소엔 보이지 않지만, 대규모의 데이터 처리와 자동화를 책임지며 시스템 전체를 움직인다.

웹과 배치를 비교해보자.

웹 vs 배치: 무엇이 다른가?

실시간 vs 비대화식

  • 웹:
    • 사용자가 요청하면 즉각적으로 처리한다.
    • 클릭하거나 데이터를 입력하면, 그 순간 서버가 요청을 받아 JSON, HTML 등의 결과를 돌려준다.
    • 실시간 반응이 핵심이다.
  • 배치:
    • 배치는 사용자의 요청을 기다리지 않는다.
    • 정해진 스케줄에 따라 작업이 자동으로 실행된다.
    • 특정 시점에 대량 데이터를 처리하거나, 주기적으로 실행되는 작업에서 빛을 발한다.

결과의 속도

  • 웹:
    • 사용자의 요청에 즉각 응답하는 것이 생명이다.
    • 페이지 로딩이 1초만 느려져도 사용자는 떠난다.
    • 실시간 피드백이 가장 중요하다.
  • 배치:
    • 배치에서는 결과의 속도보다 정확성과 완결성이 우선이다.
    • 데이터 처리에 시간이 걸리더라도 대량 데이터를 완벽하게 처리하는 것이 목표다.

처리량의 차이

  • 웹:
    • 한 번에 한 사용자의 요청을 처리한다.
    • 한 명의 사용자가 상품을 검색하거나 주문을 할 떄, 그 요청만 처리하면 된다.
  • 배치:
    • 대량의 데이터를 효율적으로 처리한다.
    • 수백만 건의 데이터를 한 번에 처리하는 것이 기본이다.

오류 처리

  • 웹:
    • 잘못된 요청이 오면, 즉시 에러 코드를 반환하고 끝낸다.
    • 사용자에게 문제를 알리고, 서버는 다음 요청을 기다린다.
  • 배치:
    • 배치는 복구에 초점을 맞춘다.
    • 문제가 발생하면 재시도하고, 실패가 반복되면 중단한 뒤 로그와 알림으로 관리자를 호출한다.
    • 문제를 해결한 후 실패한 작업을 재시작하는 것이 일반적이다.

리소스 사용

  • 웹:
    • 서버는 상시 실행 중이다.
    • 사용자가 요청하지 않는 시간에도 대기 상태로 유지되며, 메모리와 CPU를 지속적으로 사용한다.
  • 배치:
    • 배치는 필요할 때만 실행된다.
    • 작업이 끝나면 리소스를 반환하고 종료된다.

두 셰계의 공존

웹은 실시간 상호작용의 최전선에서 사용자와의 연결을 담당한다.
배치는 시스템의 후방에서 대규모 데이터 처리를 책임진다


스프링 배치: 최강의 배치 처리 도구

배치 처리의 중요성을 이해했다면, 이제 스프링 배치를 살펴보자.
스프링 배치는 스프링 프레임워크를 기반으로 만들어진 배치 프레임워크다.
우리에게 익숙한 스프링의 기술로 배치 처리의 일반적인 패턴을 손쉽게 구현할 수 있게 해준다.

그럼 이제 스프링 배치가 제공하는 핵심 기능들을 살펴보자.


유지보수성

웹 애플리케이션은 비즈니스 요구사항에 따라 자주 수정되지만, 배치 처리는 한번 정립된 업무 프로세스를 수행하기 때문에 상대적으로 변경이 적다.

스프링은 이미 웹 개발에서 뛰어난 유지보수성을 입증했다. 스프링 배치는 이러한 스프링의 장점을 그대로 계승했다.

  • 의존성 주입(DI)으로 컴포넌트 간 결합도를 철저히 낮춘다. 코드 변경이 필요할 때 전체 시스템에 영향을 주지 않는다.
  • 관점 지향 프로그래밍(AOP)으로 횡단 관심사를 완벽하게 분리한다. 코드의 모듈화가 극대화된다.
  • 스프링의 추상화 계층이 특정 기술에 대한 종속성을 차단한다. 기술이 변해도 코드는 살아남는다.

이에 더해 스프링 배치는 일반적인 배치 처리패턴을 추상화한 컴포넌트들을 제공한다.
웹과 비슷하게, 배치 처리에도 데이터를 읽고, 가공하고, 저장하는 일반적인 패턴이 있다.


  • Job : 하나의 완전한 배치 처리 작업
  • Step : Job의 세부 실행 단계 (하나의 Job은 여러 Step으로 구성될 수 있다)
  • ItemReader : 데이터를 읽어오는 컴포넌트
  • ItemProcessor : 데이터를 가공하는 컴포넌트
  • ItemWriter : 데이터를 저장하는 컴포넌트

이런 명확한 구조 덕분에 팀원들은 배치 코드를 쉽게 이해하고 유지보수 할 수 있다.


유연한 데이터 처리

배치 처리의 핵심은 다양한 데이터 소스를 다루는 것이다. 스프링 배치는 이를 손쉽게 할 수 있게 해준다.
ItemReader와 ItemWriter라는 표준화된 인터페이스를 통해 어떤 데이터 소스든 일관된 방식으로 처리할 수 있다.

스프링 배치는 다음과 같은 다양한 데이터 소스를 기본적으로 지원한다.

  • 플랫 파일(CSV, TXT) : FlatFileItemReader, FlatFileItemWriter를 사용해 간단히 처리
  • XML/JSON : StaxEventItemReader, JsonItemReader, JsonFileItemWriter 등을 사용한 구조화된 데이터 처리
  • 관계형 데이터베이스 : JdbcCursorItemReader, JdbcBatchItemWriter 등으로 DB 접근. JPA와 같은 ORM 프레임워크도 지원한다.
  • NoSQL : MongoDB, Redis 등을 위한 전용 Reader/Writer 제공
  • 메시징 시스템 : Kafka, AMQP 등 메시지 큐 시스템과의 연동 지원

여기서 가장 중요한 점은 이 모든 데이터 소스를 동일한 방식으로 다룰 수 있다는 것이다.
파일에서 DB로, DB에서 NoSQL로 데이터를 옮기는 작업도 단순히 ItemReader와 ItemWriter 구현체만 교체하면 된다.
이것이 스프링 배치가 제공하는 진정한 유연성이다.


견고한 트랜잭션 관리

스프링 배치는 다음과 같은 트랜잭션 관리 기능을 제공한다.

  • 체크포인트 기능
    • 긴 배치 작업 중간에 안전 지점을 설정
    • 문제 발생 시 처음이 아닌 마지막 체크포인트부터 재시작 가능
  • 유연한 트랜잭션 범위 설정
    • 처리할 데이터 양과 특성에 따라 트랜잭션 범위 조절 가능
    • 작은 단위의 커밋으로 메모리 사용량 조절 가능

재시작 기능과 유연한 실행 제어

스프링 배치는 작업 실행을 세밀하게 제어할 수 있는 기능을 제공한다. 다음과 같은 핵심 기능들이 있다.

  • 재시작 기능 : 대용량 데이터 처리 중 실패해도 처음부터 다시 시작할 필요가 없다
    • 오류 발생 시 마지막으로 성공한 Step부터 재시작 가능
    • Step 내에서도 마지막 처리 항목 이후부터 작업 재개 가능
  • 유연한 실행 제어
    • 특정 Step만 선택적으로 실행 가능
    • 파라미터를 통한 동적 작업 제어
    • Step의 조건부 실행 : 이전 Step의 결과에 따라 다음 작업 결정 가능
  • 작업 상태 추적
    • 모든 Job과 Step의 실행 상태를 메타데이터로 관리
    • 작업의 실행 시점과 결과를 정확하게 추적 가능

이러한 기능들 덕분에 복잡하고 장시간 실행되는 배치 작업도 안정적으로 관리하고 제어할 수 있다.


대용량 데이터 처리와 확장성


스프링 배치는 대용량 데이터를 효율적으로 처리하면서도 다양한 규모의 작업에 유연하게 대응할 수 있다. 다음과 같은 핵심 기능들을 제공한다

  • Chunk 지향 처리
    • 대량의 데이터를 지정된 크기로 나누어 순차적으로 처리
    • 한 번에 처리하는 데이터 양을 제한하여 메모리 사용 최적화
  • 효율적인 데이터 읽기
    • 페이징 방식 : 일정 크기만큼 데이터를 조회하여 처리
    • 커서 방식 : 데이터베이스 커서를 사용한 효율적인 데이터 스트리밍
  • 확장성 기법(Scalability Techniques)
    • 멀티스레드 Step : 하나의 Step을 여러 스레드로 처리
    • 병렬 Step : 여러 Step을 동시에 실행
    • 분산 처리 : 여러 서버에서 배치 처리 분산 실행

이러한 특성들 덕분에 스프링 배치는 소규모 데이터 처리부터 대규모 엔터프라이즈급 배치 처리까지 다양한 규모의 데이터를 효율적으로 수행할 수 있다.


테스트 용이성


스프링 배치는 배치 애플리케이션을 쉽게 테스트할 수 있는 다양한 도구들을 제공한다.

  • 전용 테스트 도구
    • 배치 작업의 실행과 결과를 손쉽게 검증할 수 있는 도구들 제공
    • 테스트 환경에서 실행하고 검증 가능
  • 스프링의 테스트 지원
    • 우리에게 익숙한 스프링의 테스트 도구들을 배치에서도 그대로 사용
    • 독립된 테스트 환경 제공
  • 단위 테스트
    • 복잡한 배치 작업을 작은 단위로 나누어 테스트 가능
on this page
  • 01배치 처리란?
  • 배치 처리의 특징을 더 자세히 보자
  • 실무 배치 사례들
  • 02웹 vs 배치: 무엇이 다른가?
  • 실시간 vs 비대화식
  • 결과의 속도
  • 처리량의 차이
  • 오류 처리
  • 리소스 사용
  • 두 셰계의 공존
  • 03스프링 배치: 최강의 배치 처리 도구
  • 유지보수성
  • 유연한 데이터 처리
  • 견고한 트랜잭션 관리
  • 재시작 기능과 유연한 실행 제어
  • 대용량 데이터 처리와 확장성
  • 테스트 용이성

댓글 (0)