> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# 배치 처리 vs 스트리밍 처리

> 이 문서는 **[데이터 기초](/training/01-data-fundamentals/overview)** 섹션의 일부입니다.

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

데이터 파이프라인을 설계할 때 가장 먼저 결정해야 하는 것 중 하나가 바로 \*\*"데이터를 얼마나 자주, 얼마나 빠르게 처리할 것인가?"\*\*입니다. 이 질문에 대한 답이 바로 **배치(Batch) 처리** 와 **스트리밍(Streaming) 처리** 의 선택입니다.

***

## 배치 처리 (Batch Processing)

### 개념

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

비유하자면, **우편배달부** 와 같습니다. 편지가 도착할 때마다 바로 배달하는 것이 아니라, 아침에 한꺼번에 모아서 배달합니다.

### 동작 방식

| 단계                | 설명               |
| ----------------- | ---------------- |
| 데이터 축적 (6시간 동안)   | 데이터가 쌓임          |
| 정해진 시간 (매일 새벽 2시) | 한꺼번에 처리 (ETL 실행) |
| 결과 저장             | 웨어하우스/레이크하우스에 적재 |

### 대표적인 사례

| 사례        | 설명                              |
| --------- | ------------------------------- |
| 일별 매출 리포트 | 전날의 매출 데이터를 새벽에 집계하여 리포트를 생성합니다 |
| 월말 급여 계산  | 한 달간의 근태 데이터를 모아서 급여를 계산합니다     |
| 추천 모델 학습  | 일주일간의 사용자 행동 데이터로 추천 모델을 재학습합니다 |
| 데이터 백업    | 매일 특정 시간에 전체 데이터베이스를 백업합니다      |

### 장단점

| 장점                  | 단점                             |
| ------------------- | ------------------------------ |
| 구현이 비교적 간단함         | 데이터 반영까지 시간 지연(Latency)이 발생합니다 |
| 리소스를 효율적으로 사용할 수 있음 | 실시간 의사결정이 불가능합니다               |
| 대용량 데이터 처리에 비용 효율적  | 오류 발생 시 전체를 재처리해야 할 수 있습니다     |
| 디버깅과 모니터링이 쉬움       | 피크 시간에 리소스가 집중됩니다              |

***

## 스트리밍 처리 (Stream Processing)

### 개념

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

비유하자면, **컨베이어 벨트** 와 같습니다. 물건(데이터)이 도착하면 바로 컨베이어 벨트 위에서 처리되어 다음 단계로 넘어갑니다. 멈추지 않고 계속 흘러갑니다.

### 동작 방식

| 단계                  | 설명        |
| ------------------- | --------- |
| 이벤트 발생 (클릭, 주문, 센서) | 즉시 전달     |
| 스트림 처리 엔진 (연속 처리)   | 실시간 변환/집계 |
| 대시보드 갱신 / 알림 발송     | 즉각 반영     |

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

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

### 대표적인 사례

| 사례           | 설명                               |
| ------------ | -------------------------------- |
| 실시간 이상 거래 감지 | 신용카드 결제가 발생할 때마다 즉시 사기 여부를 판단합니다 |
| 실시간 대시보드     | 웹사이트 동시 접속자 수를 초 단위로 갱신합니다       |
| IoT 센서 모니터링  | 공장 설비의 온도가 임계치를 넘으면 즉시 알림을 발송합니다 |
| 실시간 추천       | 사용자의 최근 행동을 기반으로 실시간으로 상품을 추천합니다 |
| 로그 모니터링      | 서버 에러 로그가 급증하면 즉시 운영팀에 알림을 보냅니다  |

### 장단점

| 장점               | 단점                                  |
| ---------------- | ----------------------------------- |
| 데이터를 즉시 활용할 수 있음 | 구현이 상대적으로 복잡합니다                     |
| 실시간 의사결정 가능      | 컴퓨팅 리소스가 항상 실행되어야 하므로 비용이 높을 수 있습니다 |
| 점진적 처리로 안정적      | 순서 보장, 중복 처리 등 고려 사항이 많습니다          |
| 최신 데이터를 항상 반영    | 디버깅이 어려울 수 있습니다                     |

***

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

실무에서는 순수한 실시간 처리보다 **마이크로 배치(Micro-Batch)** 방식을 많이 사용합니다.

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

| 처리 방식    | 처리 주기                     | 예시                               |
| -------- | ------------------------- | -------------------------------- |
| 배치 처리    | 매일 새벽 2시, 하루치 데이터를 한번에 처리 | 일 단위 정산                          |
| 마이크로 배치  | 매 10초\~1분 간격으로 소규모 배치 처리  | Spark Structured Streaming 기본 모드 |
| 실시간 스트리밍 | 이벤트 발생 즉시, 건건이 처리         | 이상 거래 탐지                         |

Databricks의 **Spark Structured Streaming** 은 기본적으로 마이크로 배치 방식으로 동작하며, 필요에 따라 Continuous Processing 모드로 더 낮은 지연시간을 달성할 수도 있습니다.

***

## 한눈에 비교

| 비교 항목             | 배치 처리            | 마이크로 배치              | 스트리밍 처리                           |
| ----------------- | ---------------- | -------------------- | --------------------------------- |
| **처리 단위**         | 대량 (시간/일 단위)     | 소량 (초/분 단위)          | 개별 이벤트                            |
| **지연 시간**         | 분~~시간~~일         | 초\~분                 | 밀리초\~초                            |
| **구현 복잡도**        | 낮음               | 중간                   | 높음                                |
| **비용**            | 낮음 (필요 시만 실행)    | 중간                   | 높음 (항상 실행)                        |
| **적합한 사례**        | 리포트, ML 학습       | 니어 리얼타임 대시보드         | 이상 감지, 실시간 알림                     |
| **Databricks 도구** | Jobs (Scheduled) | Structured Streaming | Structured Streaming (Continuous) |

***

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

Databricks의 큰 장점 중 하나는 **배치와 스트리밍을 동일한 코드로 처리** 할 수 있다는 것입니다.

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

```python theme={null}
# 배치 처리: 한 번 실행하고 종료
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")
```

위 예시에서 보시는 것처럼, `read` → `readStream`, `write` → `writeStream`으로 바꾸는 것만으로 배치 파이프라인을 스트리밍 파이프라인으로 전환할 수 있습니다.

### SDP에서의 통합

Spark Declarative Pipelines(SDP)를 사용하면, 배치와 스트리밍의 구분 자체가 더욱 단순해집니다.

| SDP 개념                | 처리 방식        | 설명                      |
| --------------------- | ------------ | ----------------------- |
| **Streaming Table**   | 스트리밍 (추가 전용) | 새로 도착한 데이터만 증분 처리합니다    |
| **Materialized View** | 배치 (전체 재계산)  | 전체 데이터를 기준으로 결과를 재계산합니다 |

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

***

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

다음 질문들에 답해 보시면 적합한 방식을 선택하는 데 도움이 됩니다.

| 질문                          | 답변                          | 추천 방식                                |
| --------------------------- | --------------------------- | ------------------------------------ |
| 데이터 도착 후 몇 분 이내에 결과가 필요한가요? | 시간\~일 단위 허용                 | 배치 처리                                |
| 데이터 도착 후 몇 분 이내에 결과가 필요한가요? | 초\~분 이내 + 순서/정확한 집계 중요      | Spark Structured Streaming (마이크로 배치) |
| 데이터 도착 후 몇 분 이내에 결과가 필요한가요? | 초\~분 이내 + 최저 지연 필요          | Apache Kafka + Flink                 |
| 데이터 도착 후 몇 분 이내에 결과가 필요한가요? | 초\~분 이내 + 순서/정확한 집계 중요하지 않음 | Spark Structured Streaming           |

실무에서는 **하나의 시스템 안에서 배치와 스트리밍을 혼합** 하여 사용하는 것이 일반적입니다. 예를 들어, 실시간 이상 거래 감지는 스트리밍으로, 일별 매출 리포트는 배치로 처리하는 식입니다. Databricks는 이 두 가지를 하나의 플랫폼에서 모두 지원하므로, 상황에 맞는 최적의 방식을 유연하게 선택하실 수 있습니다.

***

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

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

20년간 데이터 파이프라인을 구축하면서 배운 가장 값진 교훈입니다. 고객이 "실시간으로 해주세요"라고 요청하면, 저는 항상 이 질문을 먼저 합니다.

**"데이터가 5분 늦게 도착하면 비즈니스에 어떤 손실이 발생하나요?**"놀랍게도, 80% 이상의 경우 답은"**사실 5분이면 충분해요**"또는"\*\*글쎄요, 딱히..."\*\*입니다.

| 고객 요청                | 실제 필요             | 적합한 방식          | 비용 차이                 |
| -------------------- | ----------------- | --------------- | --------------------- |
| "실시간 대시보드가 필요해요"     | 15분 이내 갱신이면 충분    | 마이크로배치 (5\~15분) | 스트리밍 대비 **70% 절감**    |
| "실시간 재고 현황이 필요해요"    | 5분 지연까지 허용        | 마이크로배치 (1\~5분)  | 스트리밍 대비 **50% 절감**    |
| "이상 거래를 실시간 탐지해야 해요" | 1초 이내 판단 필요 (규제)  | 실시간 스트리밍 필수     | 비용이 높지만 **규제 요건**     |
| "실시간 추천이 필요해요"       | 세션 중 반응하면 됨 (수 초) | 마이크로배치 + 캐시     | 순수 스트리밍 대비 **60% 절감** |

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

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

Databricks에서 마이크로배치는 **Spark Structured Streaming의 기본 모드** 입니다. 이것이 "달콤한 중간점"인 이유를 실전 숫자로 보여드리겠습니다.

```python theme={null}
# 마이크로배치: 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")
```

| 처리 모드               | trigger 설정                    | 지연 시간   | 리소스 사용     | 적합한 상황       |
| ------------------- | ----------------------------- | ------- | ---------- | ------------ |
| **마이크로배치 (짧은 간격)**  | `processingTime="10 seconds"` | 10\~20초 | 높음 (거의 상시) | 니어 리얼타임 대시보드 |
| **마이크로배치 (적당한 간격)** | `processingTime="1 minute"`   | 1\~2분   | 중간         | 대부분의 운영 분석   |
| **마이크로배치 (긴 간격)**   | `processingTime="5 minutes"`  | 5\~7분   | 낮음         | 비용 민감한 집계    |
| **트리거 원스**          | `availableNow=True`           | 배치와 동일  | 최소         | 증분 배치 (권장!)  |

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

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

이건 2019년에 목격한 사례입니다. 한 이커머스 회사의 데이터 팀(5명)이 "실시간 분석"을 위해 Apache Kafka를 도입했습니다.

#### 도입 전 기대

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

#### 도입 후 현실 (6개월 뒤)

| 항목                | 예상              | 현실                                         |
| ----------------- | --------------- | ------------------------------------------ |
| **Kafka 클러스터 관리** | "관리형 서비스 쓰면 되지" | 관리형도 토픽 설계, 파티션 리밸런싱, 컨슈머 그룹 관리 필요         |
| **스키마 관리**        | "JSON으로 보내면 되지" | 스키마 레지스트리 없이 시작 → 3개월 뒤 필드명 불일치 카오스        |
| **Flink 개발**      | "Spark랑 비슷하겠지"  | 다른 프로그래밍 모델, Flink 전문가 채용 필요               |
| **장애 대응**         | "알아서 복구되겠지"     | 컨슈머 랙(Consumer Lag) 급증 시 새벽 3시 호출          |
| **비용**            | 월 \$2,000 예상    | Kafka 클러스터 + Flink 클러스터 + 모니터링 = 월 \$8,000 |
| **팀 부담**          | 5명 중 0.5명       | 5명 중 2명이 Kafka/Flink 인프라 관리에 투입            |

#### 교훈과 대안

이 팀은 결국 Kafka를 유지하되, Flink를 **Databricks Structured Streaming으로 교체** 했습니다.

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

결과:

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

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

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

스트리밍을 도입하기로 결정했다면, 이 장애 패턴들을 미리 알고 대비해야 합니다.

| 장애             | 증상                    | 원인                    | 해결법                                                              |
| -------------- | --------------------- | --------------------- | ---------------------------------------------------------------- |
| **컨슈머 랙 급증**   | 처리 속도가 유입 속도를 따라가지 못함 | 데이터 볼륨 급증 또는 처리 로직 병목 | 오토스케일링, 마이크로배치 간격 조정, 처리 로직 최적화                                  |
| **체크포인트 손상**   | 스트리밍 재시작 시 에러         | 비정상 종료, 스토리지 이슈       | 체크포인트 백업, 장애 시 offset 수동 리셋                                      |
| **스키마 불일치**    | 갑자기 파싱 에러 발생          | 소스에서 필드 추가/변경         | Schema Registry 사용, `mergeSchema` 옵션 활용                          |
| **워터마크 이슈**    | Late data가 누락됨        | 워터마크 설정이 너무 짧음        | 비즈니스 요건에 맞는 워터마크 설정 (예: `withWatermark("event_time", "1 hour")`) |
| **상태 저장소 비대화** | 메모리 부족, GC 폭증         | 상태 있는 집계에서 키가 계속 증가   | 상태 만료(state timeout) 설정, 윈도우 기반 집계로 전환                           |

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

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

스트리밍과 배치를 어떻게 조합하느냐에 따라 대표적인 3가지 아키텍처 패턴이 있습니다.

| 아키텍처                          | 핵심 아이디어                        | 장점                       | 단점                                   |
| ----------------------------- | ------------------------------ | ------------------------ | ------------------------------------ |
| **Lambda**                    | 배치 레이어 + 스피드 레이어를 별도 운영        | 정확성(배치) + 속도(스트리밍) 모두 확보 | 동일 로직을 두 번 작성, 운영 복잡도 높음             |
| **Kappa**                     | 스트리밍만으로 모든 것을 처리               | 단일 코드베이스, 단순한 아키텍처       | 재처리(backfill)가 어려움, 모든 워크로드에 적합하지 않음 |
| **Medallion (Databricks 권장)** | Bronze→Silver→Gold 레이어로 점진적 정제 | 배치와 스트리밍 혼합 가능, 재처리 용이   | 레이어간 지연 발생 가능                        |

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

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

| 질문                      | Yes →                              | No →        |
| ----------------------- | ---------------------------------- | ----------- |
| 1초 이내 반응이 법적/안전상 필수인가?  | 실시간 스트리밍 (Kafka + Flink 또는 전용 시스템) | 다음 질문       |
| 5분 이내 반영이 비즈니스에 의미 있는가? | Structured Streaming (마이크로배치)      | 다음 질문       |
| 1시간 이내면 충분한가?           | `availableNow=True` 트리거 (시간별 스케줄)  | 다음 질문       |
| 하루 1회면 충분한가?            | 전통 배치 (가장 저렴, 가장 단순)               | 여기까지 왔으면 배치 |

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

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

같은 이커머스 주문 분석 워크로드를 세 가지 방식으로 구현했을 때의 실제 월간 비용 비교입니다.

| 비용 항목      | 일 1회 배치                   | 마이크로배치 (5분)                    | 실시간 스트리밍 (Kafka+Flink)     |
| ---------- | ------------------------- | ------------------------------ | -------------------------- |
| **컴퓨트**    | \$300 (일 2시간 Job Cluster) | \$1,200 (상시 Streaming Cluster) | \$3,500 (Kafka + Flink 상시) |
| **스토리지**   | \$50 (Delta Table)        | \$50 (Delta Table)             | \$200 (Kafka + Delta)      |
| **운영**     | 0.1 FTE                   | 0.3 FTE                        | 1.0 FTE                    |
| **데이터 지연** | 최대 24시간                   | 최대 5분                          | 최대 5초                      |
| **구현 복잡도** | 낮음 (SQL만으로 가능)            | 중간 (Streaming API)             | 높음 (Kafka+Flink+모니터링)      |
| **장애 복구**  | 재실행 1번이면 끝                | 체크포인트에서 자동 복구                  | 전문가 필요 (Consumer Lag 분석)   |

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

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

"처음부터 스트리밍으로 만들자"는 위험합니다. 검증된 점진 전환 전략을 공유합니다.

| 단계      | 방식                                   | 코드 변경                         | 소요 기간 |
| ------- | ------------------------------------ | ----------------------------- | ----- |
| **1단계** | 일 1회 배치 (spark.read + overwrite)     | 기준 코드                         | 1주    |
| **2단계** | 증분 배치 (availableNow=True + append)   | read → readStream, trigger 추가 | 1일    |
| **3단계** | 시간별 스케줄 (availableNow=True, 1시간마다)   | Job 스케줄 변경만                   | 30분   |
| **4단계** | 마이크로배치 (processingTime="1 minute")   | trigger 변경만                   | 30분   |
| **5단계** | 니어리얼타임 (processingTime="10 seconds") | trigger 변경만                   | 30분   |

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

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

업종에 따라 "적절한 데이터 지연"이 다릅니다. 20년간 다양한 업종을 지원하면서 정리한 가이드입니다.

| 업종            | 대표 워크로드    | 권장 처리 방식         | 허용 지연     | 근거               |
| ------------- | ---------- | ---------------- | --------- | ---------------- |
| **금융 (트레이딩)** | 이상 거래 탐지   | 실시간 스트리밍         | \< 1초     | 규제 요건 + 금전 손실 방지 |
| **금융 (리포팅)**  | 일일 포지션 리포트 | 배치 (일 1회)        | 다음 영업일 오전 | 규제 보고 마감 기준      |
| **이커머스**      | 실시간 추천     | 마이크로배치 (1\~5분)   | 5분        | 세션 내 반응이면 충분     |
| **이커머스**      | 일별 매출 분석   | 배치 (일 1회)        | 다음 날 오전   | 일 단위 의사결정        |
| **제조/IoT**    | 설비 이상 감지   | 마이크로배치 (10초\~1분) | 1분        | 장비 손상 방지         |
| **미디어**       | 시청률 대시보드   | 마이크로배치 (5분)      | 5분        | 편성 의사결정 보조       |
| **물류**        | 배송 추적      | 마이크로배치 (1\~5분)   | 5분        | 고객 조회 시 최신 상태 표시 |
| **헬스케어**      | 환자 모니터링    | 실시간 스트리밍         | \< 5초     | 생명 안전            |
| **게임**        | 인게임 이벤트 분석 | 마이크로배치 (30초\~5분) | 5분        | 실시간 A/B 테스트      |

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

***

## 정리

| 핵심 개념                    | 설명                                              |
| ------------------------ | ----------------------------------------------- |
| **배치 처리**                | 데이터를 모아서 한꺼번에 처리하는 방식. 비용 효율적이지만 지연이 있습니다       |
| **스트리밍 처리**              | 데이터가 도착하는 즉시 처리하는 방식. 실시간이지만 복잡하고 비용이 높습니다      |
| **마이크로 배치**              | 짧은 간격(초\~분)으로 작은 묶음을 처리하는 실용적인 중간 방식입니다         |
| **메시지 큐**                | 이벤트를 임시 저장하여 Producer와 Consumer를 연결하는 중간 시스템입니다 |
| **Structured Streaming** | Spark의 스트리밍 엔진으로, 배치와 동일한 API로 스트리밍 처리를 지원합니다   |

다음 문서에서는 데이터의 **유형**(정형, 반정형, 비정형)에 따른 특징과 처리 방법을 살펴보겠습니다.

***

## 참고 링크

* [Databricks: Structured Streaming](https://docs.databricks.com/aws/en/structured-streaming/)
* [Azure Databricks: Stream processing](https://learn.microsoft.com/en-us/azure/databricks/structured-streaming/)
* [Databricks Blog: Streaming](https://www.databricks.com/blog/category/engineering-blog)