배치와 실시간 처리의 차이, 이벤트 드리븐 아키텍처, Lambda/Kappa 아키텍처, 핵심 구성요소를 살펴보며 실시간 데이터 파이프라인의 전체 그림을 이해합니다.
전통적인 데이터 처리 방식은 **Batch Processing(배치 처리)**이었습니다. 하루에 한 번, 혹은 몇 시간 간격으로 축적된 데이터를 한꺼번에 처리하는 방식입니다. ETL 작업을 야간에 돌리고, 아침에 갱신된 대시보드를 확인하는 것이 전형적인 패턴이었습니다.
그러나 비즈니스의 속도가 빨라지면서 이런 지연은 더 이상 허용되지 않게 되었습니다. 이커머스 플랫폼에서 결제 사기를 탐지하려면 몇 시간 후가 아니라 밀리초 단위의 판단이 필요합니다. 추천 엔진은 사용자의 실시간 행동을 즉시 반영해야 합니다. IoT 센서 데이터는 수집 즉시 이상 징후를 감지해야 합니다.
| 관점 | 배치 처리 | 실시간 처리 |
|---|---|---|
| 지연 시간 | 분~시간 | 밀리초~초 |
| 처리 단위 | 대량 데이터 묶음 | 개별 이벤트 또는 소규모 묶음 |
| 트리거 | 스케줄(cron 등) | 이벤트 발생 시 즉시 |
| 인프라 | 유한한 작업 후 종료 | 항상 실행(long-running) |
| 복잡도 | 상대적으로 단순 | 상태 관리, 순서 보장 등 복잡 |
| 비용 | 필요 시에만 리소스 사용 | 상시 리소스 확보 필요 |
배치 처리가 나쁜 것은 아닙니다. 월별 정산, 대규모 모델 학습, 히스토리 분석 등에는 여전히 배치가 적합합니다. 핵심은 데이터의 가치가 시간에 얼마나 민감한가입니다. 사기 탐지처럼 즉각적 조치가 필요한 경우 실시간이 필수이고, 월간 리포트처럼 시간에 둔감한 경우 배치가 효율적입니다.
실시간 파이프라인의 근간은 **Event-Driven Architecture(이벤트 드리븐 아키텍처)**입니다. 시스템의 모든 변화를 **Event(이벤트)**라는 불변의 사실로 기록하고, 이 이벤트를 중심으로 시스템을 설계합니다.
이벤트는 특정 시점에 발생한 사실의 기록입니다. "사용자 A가 상품 B를 장바구니에 담았다", "센서 C의 온도가 85도를 기록했다"처럼 과거에 일어난 변경 불가능한 사실을 나타냅니다.
이벤트는 보통 다음과 같은 구조를 갖습니다.
{
"eventId": "evt-20260316-001",
"eventType": "order.placed",
"timestamp": "2026-03-16T09:30:00Z",
"source": "checkout-service",
"data": {
"orderId": "ORD-12345",
"userId": "USR-67890",
"totalAmount": 59000,
"currency": "KRW"
}
}이벤트 드리븐 아키텍처에는 세 가지 주요 패턴이 있습니다.
1. Event Notification(이벤트 알림)
가장 단순한 형태입니다. "주문이 생성되었습니다"라는 알림만 보내고, 수신 측이 필요한 데이터를 직접 조회합니다. 결합도는 낮지만, 추가 조회로 인한 지연이 발생할 수 있습니다.
2. Event-Carried State Transfer(이벤트 기반 상태 전달)
이벤트 자체에 필요한 데이터를 모두 포함합니다. 수신 측이 별도 조회 없이 이벤트만으로 처리할 수 있어 지연이 줄어들지만, 이벤트 크기가 커집니다.
3. Event Sourcing(이벤트 소싱)
모든 상태 변경을 이벤트로 저장하고, 이벤트 시퀀스를 재생하여 현재 상태를 도출합니다. 완전한 감사 추적이 가능하지만 구현 복잡도가 높습니다.
이 시리즈에서 다루는 실시간 파이프라인은 주로 두 번째 패턴인 Event-Carried State Transfer를 기반으로 합니다. Kafka와 같은 메시지 브로커를 통해 풍부한 이벤트를 전달하고, Flink와 같은 스트림 처리 엔진이 이를 실시간으로 처리합니다.
실시간 데이터 처리 아키텍처를 논할 때 빠지지 않는 두 가지 접근법이 있습니다.
Nathan Marz가 제안한 **Lambda Architecture(람다 아키텍처)**는 배치 레이어와 스피드 레이어를 동시에 운영합니다.
Lambda 아키텍처의 장점은 배치 레이어가 최종적으로 정확한 결과를 보장한다는 점입니다. 그러나 동일한 로직을 배치와 스트리밍 두 곳에서 구현하고 유지해야 하는 이중 부담이 가장 큰 단점입니다.
Jay Kreps가 제안한 **Kappa Architecture(카파 아키텍처)**는 스트리밍 레이어 하나로 모든 처리를 통합합니다.
모든 데이터를 이벤트 스트림으로 취급하고, 단일 스트림 처리 파이프라인으로 실시간과 재처리를 모두 수행합니다. 재처리가 필요하면 새 파이프라인 인스턴스를 배포하고 이벤트 로그를 처음부터 다시 소비합니다.
| 고려 사항 | Lambda | Kappa |
|---|---|---|
| 코드 중복 | 배치 + 스트리밍 이중 유지 | 단일 코드베이스 |
| 정확성 보장 | 배치가 최종 보정 | Exactly-once 시맨틱스에 의존 |
| 재처리 | 배치 레이어로 전체 재처리 | 이벤트 로그 재소비 |
| 운영 복잡도 | 높음 (두 시스템 운영) | 상대적으로 낮음 |
| 적합한 경우 | 레거시 배치 시스템 병행 | 신규 구축, 스트리밍 우선 |
2026년 현재, Kafka와 Flink의 성숙도가 높아지면서 Kappa 아키텍처를 채택하는 조직이 늘고 있습니다. 특히 **Exactly-once Semantics(정확히 한 번 처리)**가 안정적으로 지원되면서, 스트리밍만으로도 충분한 정확성을 확보할 수 있게 되었습니다.
실시간 데이터 파이프라인은 크게 네 단계로 구성됩니다.
다양한 소스에서 데이터를 실시간으로 수집합니다. 웹/모바일 이벤트, IoT 센서, 데이터베이스 변경 로그, 외부 API 등이 대표적인 소스입니다.
주요 도구: Kafka Producer, Kafka Connect, Debezium(CDC), Fluentd, AWS Kinesis Data Firehose
수집된 이벤트를 실시간으로 변환, 필터링, 집계, 조인합니다. 이 단계에서 비즈니스 로직이 적용됩니다.
주요 도구: Apache Flink, Spark Structured Streaming, Kafka Streams, Apache Beam
처리된 결과를 목적에 맞는 저장소에 적재합니다. 실시간 분석용 OLAP, 검색용 인덱스, 캐시, 데이터 레이크 등 다양한 싱크가 될 수 있습니다.
주요 도구: Apache Kafka(이벤트 로그), Apache Iceberg/Delta Lake(레이크하우스), ClickHouse/Apache Druid(실시간 OLAP), Elasticsearch(검색), Redis(캐시)
최종 사용자나 하위 시스템에 처리된 데이터를 제공합니다. REST API, GraphQL, 대시보드, 알림 등의 형태로 서빙됩니다.
파이프라인 설계 시 각 단계를 독립적으로 확장할 수 있도록 **느슨한 결합(loose coupling)**을 유지하는 것이 중요합니다. Kafka와 같은 메시지 브로커가 각 단계 사이의 버퍼 역할을 하며, 처리 속도 차이를 흡수합니다.
실시간 데이터 처리 생태계는 빠르게 성숙하고 있습니다. 주요 흐름을 살펴보겠습니다.
Apache Kafka는 여전히 이벤트 스트리밍의 사실상 표준입니다. 가장 큰 변화는 KRaft 모드의 안정화입니다. ZooKeeper에 대한 의존을 완전히 제거하고, Kafka 자체의 Raft 기반 합의 프로토콜로 메타데이터를 관리합니다. 이로써 운영 복잡도가 크게 줄었습니다.
Apache Flink는 스트림 처리 엔진으로서의 입지를 더욱 강화했습니다. Flink SQL을 통한 선언적 스트림 처리, Flink CDC 3.6의 네이티브 CDC 커넥터, 그리고 Confluent Cloud와의 통합이 주목할 만합니다.
Apache Iceberg, Delta Lake 같은 레이크하우스 포맷이 스트리밍 데이터의 목적지로 자리잡고 있습니다. 배치와 스트리밍 데이터를 동일한 테이블에서 관리할 수 있어, 아키텍처가 한층 단순해졌습니다.
Confluent Cloud, Amazon MSK, Azure Event Hubs 같은 관리형 서비스가 진입 장벽을 낮추고 있습니다. 특히 Confluent Cloud는 Flink 기반 스트림 처리, 거버넌스 기능이 포함된 스키마 레지스트리, 커넥터 마켓플레이스를 통합 플랫폼으로 제공합니다.
이 시리즈는 총 11장에 걸쳐 실시간 데이터 파이프라인의 이론과 실전을 모두 다룹니다.
각 장은 독립적으로 읽을 수 있지만, 순서대로 읽으면 개념이 점진적으로 쌓이도록 구성했습니다. 코드 예제는 Python과 Java를 병행하며, 모든 예제는 로컬 환경에서 재현 가능합니다.
이번 장에서는 실시간 데이터 파이프라인의 필요성과 핵심 개념을 살펴보았습니다.
2장에서는 이벤트 스트리밍 아키텍처의 기초 개념을 깊이 있게 다룹니다. 토픽, 파티션, 오프셋의 개념부터 이벤트 시간과 처리 시간의 차이, 워터마크, 윈도우 연산까지 스트림 처리의 핵심 용어와 원리를 학습합니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
이벤트 로그, 토픽과 파티션, 오프셋 관리, 이벤트 시간과 처리 시간의 차이, 워터마크, 윈도우 연산 등 스트림 처리의 핵심 개념을 체계적으로 학습합니다.
Kafka의 핵심 아키텍처를 심층적으로 분석합니다. KRaft 모드, 브로커와 파티션 레플리케이션, 프로듀서 전송 보장, 컨슈머 그룹과 리밸런싱까지 Kafka의 내부를 이해합니다.
Idempotent 프로듀서, 트랜잭셔널 프로듀서, Exactly-once 시맨틱스, 수동 오프셋 관리, 배치 최적화, Dead Letter Queue 등 프로덕션 수준의 Kafka 활용 패턴을 학습합니다.