배치 처리 vs 스트림 처리

배치 처리 vs 스트림 처리. 쌓아서 한 번에 처리할까, 들어오는 즉시 처리할까. 데이터를 다루는 두 가지 방식을 Spring Batch와 Kafka라는 대표 도구로 살펴보고, 언제 무엇을 써야 하는지 실제 코드와 함께 정리한다.

---

들어가며

대량의 데이터를 처리하는 방법은 크게 두 갈래다. 하나는 데이터를 모아뒀다가 정해진 시점에 한꺼번에 처리하는 배치(Batch), 다른 하나는 데이터가 들어오는 즉시 흘려보내며 처리하는 스트림(Stream)이다.

"매일 새벽 2시에 어제 매출을 집계한다"면 배치, "결제가 일어나는 순간 실시간으로 이상 거래를 탐지한다"면 스트림이다. 같은 데이터라도 언제 처리하느냐에 따라 접근이 완전히 달라진다.

배치는 "쌓아서 한 번에", 스트림은 "들어오는 즉시". 이 타이밍의 차이가 도구 선택을 가른다.

이 글에서는 두 방식의 개념을 잡고, 각각의 대표 도구인 Spring Batch(배치)와 Kafka(스트림)를 실제 코드로 살펴본다. 그리고 언제 무엇을 써야 하는지 정리한다.

---

배치 처리란

배치 처리는 데이터를 일정 기간 모았다가, 정해진 시점에 묶음(batch)으로 한 번에 처리하는 방식이다. 전통적이고 가장 오래된 데이터 처리 방식이다.

특징은 이렇다.

• 정해진 시점에 실행된다 (매일 새벽, 매시 정각 등)
• 한 번에 대량의 데이터를 처리한다
• 실시간일 필요가 없다 (몇 시간 늦어도 되는 작업)
• 처리량(throughput)이 중요하고, 지연시간(latency)은 덜 중요하다

대표적인 예가 정산, 통계 집계, 대량 메일 발송, 데이터 마이그레이션이다. "어제 하루치를 오늘 새벽에 정리"하는 식의 작업이 전형적이다.

---

Spring Batch — 배치의 대표 도구

자바 진영에서 배치 처리의 사실상 표준은 Spring Batch다. "요즘도 쓰나?" 싶지만, 금융·보험·정산처럼 대량의 정형 데이터를 안정적으로 처리해야 하는 영역에서는 여전히 현역이다. 청크 단위 처리, 실패 시 재시작, skip/retry 같은 기능을 직접 만들면 끔찍한데, Spring Batch가 다 제공하기 때문이다.

핵심 구조는 Job → Step → (Reader-Processor-Writer) 다.

Job (배치 작업 전체)
 └ Step (하나의 처리 단계)
    ├ ItemReader    : 데이터를 읽어온다 (DB, 파일)
    ├ ItemProcessor : 한 건씩 가공한다
    └ ItemWriter    : 결과를 저장한다

회원들의 어제 주문을 집계하는 배치를 예로 보자.

@Configuration
public class OrderSummaryBatch {

    // 1. Reader — DB에서 주문을 한 건씩 읽는다 (커서 기반: 메모리 효율적)
    @Bean
    public JdbcCursorItemReader<Order> reader(DataSource dataSource) {
        return new JdbcCursorItemReaderBuilder<Order>()
                .name("orderReader")
                .dataSource(dataSource)
                .sql("SELECT id, user_id, amount FROM orders " +
                     "WHERE created_at >= CURRENT_DATE - 1")
                .rowMapper((rs, n) -> new Order(
                        rs.getLong("id"),
                        rs.getLong("user_id"),
                        rs.getInt("amount")))
                .build();
    }

    // 2. Processor — 한 건씩 가공 (예: 집계용 객체로 변환)
    @Bean
    public ItemProcessor<Order, OrderSummary> processor() {
        return order -> new OrderSummary(order.userId(), order.amount());
    }

    // 3. Writer — 결과를 집계 테이블에 저장
    @Bean
    public JdbcBatchItemWriter<OrderSummary> writer(DataSource dataSource) {
        return new JdbcBatchItemWriterBuilder<OrderSummary>()
                .dataSource(dataSource)
                .sql("INSERT INTO order_summary (user_id, total) " +
                     "VALUES (:userId, :total)")
                .beanMapped()
                .build();
    }

    // 4. Step — Reader-Processor-Writer를 묶고, chunk(10)로 처리
    @Bean
    public Step step(JobRepository repo, PlatformTransactionManager tm,
                     JdbcCursorItemReader<Order> reader,
                     ItemProcessor<Order, OrderSummary> processor,
                     JdbcBatchItemWriter<OrderSummary> writer) {
        return new StepBuilder("summaryStep", repo)
                .<Order, OrderSummary>chunk(10, tm)  // 10건씩 묶어 트랜잭션 처리
                .reader(reader)
                .processor(processor)
                .writer(writer)
                .build();
    }

    // 5. Job — 전체 배치 작업
    @Bean
    public Job orderSummaryJob(JobRepository repo, Step step) {
        return new JobBuilder("orderSummaryJob", repo)
                .start(step)
                .build();
    }
}

여기서 chunk(10) 가 핵심이다. 10건씩 묶어서 읽고-가공하고-쓰고를 한 트랜잭션으로 처리한다. 100만 건을 한 번에 메모리에 올리지 않고 10건씩 나눠 처리하니, 대용량에도 메모리가 터지지 않는다. 그리고 중간에 실패하면 그 지점부터 재시작할 수 있다. 이게 직접 짜면 고통스러운, Spring Batch의 가치다.

보통 이 Job을 스케줄러(@Scheduled나 Quartz)로 매일 새벽에 돌린다.

---

스트림 처리란

스트림 처리는 정반대다. 데이터를 모으지 않고, 들어오는 즉시 하나씩(또는 작은 묶음으로) 실시간 처리한다.

특징은 이렇다.

• 데이터가 발생하는 즉시 처리한다
• 지연시간(latency) 이 중요하다 (밀리초~초 단위 반응)
• 데이터가 끊임없이 흐른다 (끝이 정해지지 않음)
• 실시간 반응이 필요한 작업에 적합하다

대표적인 예가 실시간 이상 거래 탐지, 실시간 알림, 로그 모니터링, 실시간 추천이다. "지금 이 순간 일어나는 일에 즉시 반응"해야 하는 작업이다.

---

Kafka — 스트림의 대표 도구

스트림 처리의 중심에는 Apache Kafka가 있다. 정확히는 Kafka는 데이터가 흐르는 통로(메시지 큐/이벤트 스트리밍 플랫폼) 이고, 그 위에서 실시간 처리가 일어난다.

핵심 개념은 셋이다.

개념	역할
Producer	데이터를 보내는 쪽 (이벤트 발행)
Topic	데이터가 쌓이는 카테고리별 통로
Consumer	데이터를 받아 처리하는 쪽 (이벤트 구독)

생산자가 토픽에 이벤트를 던지면, 소비자가 그걸 실시간으로 받아 처리한다. 주문이 발생할 때마다 이벤트를 흘려보내는 예를 보자.

Producer — 이벤트 발행

@Service
public class OrderEventProducer {

    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public OrderEventProducer(KafkaTemplate<String, OrderEvent> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    // 주문이 생길 때마다 'orders' 토픽으로 이벤트를 흘려보낸다
    public void publish(Order order) {
        OrderEvent event = new OrderEvent(
                order.getId(), order.getUserId(), order.getAmount());
        kafkaTemplate.send("orders", event);
        // 배치처럼 모으지 않는다. 발생 즉시 전송.
    }
}

Consumer — 실시간 처리

@Service
public class FraudDetectionConsumer {

    // 'orders' 토픽에 이벤트가 들어오는 즉시 호출된다
    @KafkaListener(topics = "orders", groupId = "fraud-detection")
    public void handle(OrderEvent event) {
        // 실시간 이상 거래 탐지 — 들어오자마자 검사
        if (event.amount() > 10_000_000) {
            alertService.notify("고액 결제 감지: " + event.orderId());
        }
        // 새벽까지 기다리지 않는다. 지금 즉시 반응.
    }
}

배치 코드와 비교하면 차이가 분명하다. Spring Batch는 "어제치를 모아서 새벽에 한 번에" 처리했지만, Kafka는 "주문이 생기는 매 순간 즉시" 처리한다. 같은 주문 데이터인데 처리 타이밍이 정반대다.

Kafka의 또 다른 강점은 하나의 토픽을 여러 소비자가 각자 구독할 수 있다는 점이다. orders 토픽 하나를 이상탐지 소비자, 알림 소비자, 통계 소비자가 동시에 받아 각자 처리한다. 이벤트 기반 아키텍처의 토대가 된다.

---

한눈에 비교

배치 VS 스트림

	배치 처리 (Spring Batch)	스트림 처리 (Kafka)
처리 시점	정해진 시점에 한 번에	데이터 발생 즉시
데이터	모아둔 유한한 묶음	끊임없이 흐르는 데이터
중요 지표	처리량(throughput)	지연시간(latency)
지연	허용됨 (몇 시간 OK)	최소화 (밀리초~초)
대표 예	정산, 통계, 마이그레이션	실시간 탐지, 알림, 모니터링
복잡도	상대적으로 단순	인프라 운영 복잡

---

그래서, 무엇을 써야 하나

선택 기준은 결국 "얼마나 빨리 반응해야 하는가" 다.

배치가 맞는 경우

• 실시간일 필요가 없다 (일/시간 단위로 충분)
• 대량의 데이터를 안정적으로, 정확하게 처리해야 한다
• 정산·통계·리포트처럼 정해진 주기의 작업
• 실패 시 재시작·정합성이 중요하다 → Spring Batch

스트림이 맞는 경우

• 즉각적인 반응이 필요하다 (이상 탐지, 실시간 알림)
• 데이터가 끊임없이 발생한다
• 여러 시스템이 같은 이벤트에 반응해야 한다 → Kafka

그리고 중요한 점 — 둘은 양자택일이 아니다. 실무에서는 자주 함께 쓴다. 예를 들어 Kafka로 실시간 이벤트를 받아 처리하면서, 동시에 그 데이터를 쌓아뒀다가 새벽 배치로 일별 집계를 돌린다. "실시간 반응은 스트림, 대량 집계는 배치"로 역할을 나누는 것이다.

스트림이 배치를 완전히 대체하는 게 아니다. 빠른 반응이 필요한 곳엔 스트림, 정확한 대량 처리가 필요한 곳엔 배치. 둘은 공존한다.

---

마치며

배치와 스트림은 "데이터를 언제 처리하느냐"에 대한 두 가지 답이다. 쌓아서 한 번에 처리하는 배치(Spring Batch)는 정산·집계처럼 정확성과 처리량이 중요한 곳에서 여전히 강력하고, 들어오는 즉시 처리하는 스트림(Kafka)은 실시간 반응이 필요한 곳에서 빛난다.

"요즘은 다 실시간 아니야?"라고 생각하기 쉽지만, 현실은 그렇지 않다. 새벽에 한 번 돌리면 되는 일을 굳이 실시간으로 만들면 인프라만 복잡해진다. 반대로 즉각 반응해야 할 일을 배치로 처리하면 너무 늦는다. 핵심은 풀려는 문제가 실시간을 요구하는지 먼저 묻는 것이다.

좋은 백엔드 개발자는 둘 다 이해하고, 문제에 맞게 고르거나 조합한다. 배치냐 스트림이냐가 아니라, 어디에 무엇을 쓸지가 진짜 실력이다.

---

참고 출처

• Spring Batch 공식 문서 — https://docs.spring.io/spring-batch/reference/
• Apache Kafka 공식 문서 — https://kafka.apache.org/documentation/
• Spring for Apache Kafka — https://docs.spring.io/spring-kafka/reference/
• Confluent: Batch vs Stream Processing — https://www.confluent.io/learn/batch-vs-stream-processing/