배치 처리 vs 스트리밍 처리

이 문서는 데이터 기초 섹션의 일부입니다.

​

왜 이 개념을 알아야 하나요?

​

배치 처리 (Batch Processing)

​

개념

💡 배치 처리(Batch Processing) 란 일정 기간 동안 쌓인 데이터를 한꺼번에 모아서 처리하는 방식입니다. “모아서 한 번에 처리”가 핵심입니다.

​

동작 방식

​

대표적인 사례

​

장단점

​

스트리밍 처리 (Stream Processing)

​

개념

💡 스트리밍 처리(Stream Processing) 란 데이터가 발생하는 즉시 연속적으로 처리하는 방식입니다. “도착하는 대로 바로 처리”가 핵심입니다.

​

동작 방식

💡 이벤트(Event)란? 시스템에서 발생하는 하나하나의 데이터 포인트를 말합니다. 사용자가 버튼을 클릭하는 것, 센서가 온도를 측정하는 것, 결제가 완료되는 것 — 모두 이벤트입니다. 스트리밍 처리는 이 이벤트들을 하나씩 또는 작은 묶음(마이크로 배치)으로 처리합니다.

💡 메시지 큐(Message Queue)란? 이벤트를 일시적으로 저장했다가 순서대로 전달해 주는 중간 시스템입니다. Apache Kafka, Amazon Kinesis, Azure Event Hubs 등이 대표적입니다. 데이터를 보내는 쪽(Producer)과 받아서 처리하는 쪽(Consumer)을 느슨하게 연결하여, 한쪽이 느려지더라도 데이터가 유실되지 않도록 해 줍니다.

​

대표적인 사례

​

장단점

​

마이크로 배치 (Micro-Batch): 두 세계의 중간

💡 마이크로 배치(Micro-Batch)란? 데이터를 아주 짧은 간격(수 초~수 분)으로 작은 묶음 단위로 처리하는 방식입니다. 순수한 스트리밍(이벤트 단위 처리)과 배치(대량 일괄 처리)의 중간 지점에 해당합니다.

​

한눈에 비교

​

Databricks에서의 배치와 스트리밍 통합

​

동일한 코드, 다른 실행 모드

# 배치 처리: 한 번 실행하고 종료
df = spark.read.format("delta").load("/data/orders")
result = df.groupBy("category").agg(sum("amount"))
result.write.format("delta").mode("overwrite").save("/data/summary")

# 스트리밍 처리: 새 데이터가 올 때마다 자동으로 처리
df = spark.readStream.format("delta").load("/data/orders")
result = df.groupBy("category").agg(sum("amount"))
result.writeStream.format("delta").outputMode("complete") \
    .option("checkpointLocation", "/checkpoints/summary") \
    .start("/data/summary")

​

SDP에서의 통합

🆕 최신 기능: Databricks는 Serverless Streaming 을 통해 스트리밍 워크로드도 서버리스로 실행할 수 있게 되었습니다. 클러스터를 직접 관리할 필요 없이, 데이터가 들어올 때만 자동으로 리소스를 할당받아 처리합니다. 이를 통해 스트리밍의 “항상 실행” 비용 문제를 크게 완화할 수 있습니다.

​

어떤 방식을 선택해야 하나요?

​

현장에서 배운 것들: 배치와 스트리밍의 현실적 선택

​

”실시간이 정말 필요한 경우는 생각보다 적다”

💡 현업 판단 기준: “실시간”의 비용이 “니어 리얼타임(마이크로배치)“의 3~10배라는 것을 이해관계자에게 먼저 설명하세요. 대부분의 비즈니스 요건은 1~15분 마이크로배치 로 충족됩니다. 진정한 실시간이 필요한 것은 이상 거래 탐지, 자율 주행, 실시간 입찰 정도입니다.

​

마이크로배치의 달콤한 중간점: Structured Streaming의 실전

# 마이크로배치: 30초마다 새 데이터를 처리
df = spark.readStream \
    .format("delta") \
    .table("bronze.raw_events")

result = df.groupBy(
    window("event_time", "5 minutes"),  # 5분 윈도우 집계
    "category"
).agg(
    count("*").alias("event_count"),
    sum("amount").alias("total_amount")
)

result.writeStream \
    .format("delta") \
    .trigger(processingTime="30 seconds")  \
    .option("checkpointLocation", "/checkpoints/events_agg") \
    .outputMode("update") \
    .toTable("silver.events_aggregated")

💡 프로 팁 — availableNow=True: 이것은 “지금 시점까지 도착한 새 데이터만 처리하고 종료”하는 모드입니다. 스트리밍의 증분 처리(체크포인트 기반 exactly-once) 장점과 배치의 비용 효율성(사용 후 종료) 을 모두 가집니다. 시간별/일별 스케줄 잡에서 이 모드를 사용하면 전통적 배치보다 훨씬 안정적입니다.

​

카프카 도입 후 운영 부담에 시달린 팀 이야기

​

도입 전 기대

"Kafka로 실시간 이벤트를 수집하고, Flink로 처리하고,
실시간 대시보드를 만들자! 2개월이면 되겠지?"

​

도입 후 현실 (6개월 뒤)

​

교훈과 대안

변경 전: Kafka → Flink → S3 → Databricks (배치 분석)
변경 후: Kafka → Databricks Structured Streaming → Delta Lake (통합)

• Flink 클러스터 폐기 → 월 $3,000 절감
• 운영 인력 2명 → 0.5명으로 감소
• 데이터 지연: 5초 → 30초 (비즈니스에 영향 없음)
• 배치와 스트리밍 코드 통합 → 유지보수 복잡도 50% 감소

⚠️ Kafka 자체는 훌륭한 도구입니다. 문제는 “5명짜리 팀이 Kafka + Flink + Spark + 모니터링을 모두 운영하려 한 것”입니다. 팀 규모와 운영 역량을 고려하지 않은 기술 선택이 실패의 원인이었습니다.

​

스트리밍 파이프라인 운영에서 가장 흔한 장애 패턴

⚠️ 많은 팀이 이 실수를 합니다: 스트리밍 파이프라인을 배포하고 “잘 돌아가니까 됐다”고 방치합니다. 스트리밍은 항상 돌아가는 시스템 이므로, 반드시 (1) 처리 지연시간 모니터링, (2) 처리량 알림, (3) 체크포인트 상태 확인을 설정해야 합니다. Databricks의 Structured Streaming UI에서 이 지표를 확인할 수 있습니다.

​

실전 아키텍처: Lambda vs Kappa vs Medallion

💡 현업에서의 선택: Databricks를 사용한다면 Medallion 아키텍처가 가장 현실적 입니다. Bronze에서 Auto Loader로 수집하고, Silver에서 Structured Streaming으로 정제하고, Gold에서 배치로 집계하는 혼합 패턴이 가장 많습니다. “순수한 Lambda”나 “순수한 Kappa”를 고집하는 것보다 비즈니스 요건에 맞게 레이어별로 처리 방식을 선택 하는 것이 실용적입니다.

​

배치 vs 스트리밍 선택: 현실적 의사결정 체크리스트

💡 20년 경험의 결론: 가장 단순하고 비용 효율적인 방식에서 시작하고, 비즈니스가 요구할 때만 복잡도를 올리세요. **“나중에 필요하면 스트리밍으로 바꿀 수 있다”**가 Databricks의 최대 장점입니다. spark.read → spark.readStream으로 바꾸는 것은 1시간이면 됩니다. 하지만 Kafka + Flink를 걷어내는 것은 3개월이 걸립니다.

​

실무 비용 비교: 같은 워크로드, 다른 처리 방식

⚠️ 이 표를 이해관계자에게 보여주세요: “실시간”이라는 단어의 비용이 얼마인지를 숫자로 보여주면, 대부분 “5분이면 충분합니다”라고 말을 바꿉니다. 실시간이 진짜 필요한 비즈니스(이상 거래 탐지, 실시간 입찰)가 아니라면, 마이크로배치가 비용 대비 최고의 선택 입니다.

​

배치에서 스트리밍으로 점진 전환하는 실전 전략

💡 핵심 인사이트: 2단계에서 3단계로, 3단계에서 4단계로 넘어가는 것은 코드 한 줄 변경 입니다. 이것이 Spark Structured Streaming의 진짜 힘입니다. 비즈니스 요건이 변할 때, 아키텍처를 처음부터 다시 설계할 필요가 없습니다.

​

업종별 배치/스트리밍 선택 가이드

💡 트레이드오프의 핵심: 같은 회사 안에서도 워크로드마다 적합한 방식이 다릅니다. “전사적으로 실시간”이 아니라, **“이 워크로드에는 배치, 저 워크로드에는 마이크로배치”**로 개별 판단하는 것이 비용과 복잡도를 최적화하는 길입니다.

​

정리

​

참고 링크

• Databricks: Structured Streaming
• Azure Databricks: Stream processing
• Databricks Blog: Streaming