0x01. 데이터 파이프라인 개론 - Batch에서 Streaming까지

데이터는 생성되는 순간부터 가치를 잃기 시작한다.

어제의 주식 시세는 오늘의 투자 판단에 쓸 수 없고, 1시간 전 사기 거래 탐지는 이미 돈이 빠져나간 뒤다. 그렇다고 모든 데이터를 실시간으로 처리하는 것이 항상 정답은 아니다. 월간 매출 리포트를 밀리초 단위로 갱신할 필요는 없기 때문이다.

데이터 파이프라인의 핵심 질문은 결국 하나다. "이 데이터를 얼마나 빨리 처리해야 하는가?" 이 글에서는 배치 처리와 스트림 처리의 차이에서 출발하여, 이 둘을 조합하는 아키텍처 패턴, 그리고 조직 차원의 데이터 관리 패러다임인 Data Mesh와 Data Fabric까지 데이터 파이프라인의 전체 그림을 그려본다.

Batch Processing: 모아서 한 번에

배치 처리(Batch Processing) 는 데이터를 일정 기간 동안 축적한 뒤 한꺼번에 처리하는 방식이다. 마치 우편물을 하루치 모아서 한 번에 분류하는 것과 같다.

전통적인 데이터 처리 방식이며, ETL(Extract, Transform, Load) 파이프라인의 근간이다. 매일 밤 전날의 거래 데이터를 집계하거나, 주 단위로 사용자 행동 패턴을 분석하는 것이 대표적인 예시다.

배치 처리의 특징

• 높은 처리량(Throughput): 대량의 데이터를 효율적으로 한 번에 처리할 수 있다. 개별 레코드에 대한 오버헤드가 낮다.
• 높은 지연(Latency): 데이터가 축적될 때까지 기다려야 하므로, 결과를 얻기까지 수 분에서 수 시간이 걸린다.
• 단순한 오류 처리: 작업이 실패하면 전체를 다시 실행하면 된다. 입력 데이터가 고정되어 있기 때문에 재현성(Reproducibility) 이 높다.
• 자원 효율성: 필요할 때만 대량의 컴퓨팅 자원을 할당하고, 작업이 끝나면 반환한다.

대표적인 배치 처리 프레임워크로는 Apache Hadoop의 MapReduce, **Apache Spark**의 배치 모드 등이 있다. Spark는 데이터를 메모리에 올려 처리하기 때문에 MapReduce보다 수십 배 빠르지만, 본질적으로 데이터를 모아서 처리한다는 점에서 배치 패러다임에 속한다.

배치 처리가 적합한 경우

• 일별/주별/월별 리포트 생성
• 대규모 데이터 마이그레이션
• 머신러닝 모델의 학습(Training)
• 이력(Historical) 데이터 분석

Real-time Processing: 도착하는 즉시

실시간 처리(Real-time Processing) 는 데이터가 생성되는 즉시 처리하는 방식이다. 우편물 비유를 이어가면, 편지가 도착할 때마다 바로 분류하고 배달하는 것이다.

여기서 "실시간"이라는 용어에 대해 짚고 넘어갈 필요가 있다. 엄밀히 말하면 대부분의 데이터 시스템에서 말하는 실시간은 준실시간(Near Real-time) 이다. 밀리초에서 수 초 단위의 지연이 존재하며, 이는 항공기 제어 시스템 같은 경성 실시간(Hard Real-time) 과는 구분된다.

데이터 엔지니어링에서 "실시간 처리"는 일반적으로 이벤트 발생 후 수 밀리초~수 초 이내에 처리 결과를 도출하는 것을 의미한다. 이를 스트림 처리(Stream Processing) 라고도 부른다.

실시간 처리의 특징

• 낮은 지연(Low Latency): 이벤트 발생 후 거의 즉시 결과를 얻을 수 있다.
• 연속적 처리: 데이터를 끊임없이 소비하고 처리한다. 시작과 끝이 명확한 배치와 달리, 스트림은 무한한 데이터(Unbounded Data) 를 다룬다.
• 복잡한 상태 관리: 이벤트 간의 관계를 추적하려면 처리 중 상태(State) 를 유지해야 하며, 이것이 스트림 처리의 가장 어려운 부분이다.
• 정확성 보장의 어려움: 네트워크 지연, 이벤트 순서 뒤바뀜, 중복 전달 등의 문제를 처리해야 한다.

대표적인 스트림 처리 프레임워크로는 Apache Kafka Streams, Apache Flink, Apache Spark Structured Streaming 등이 있다.

실시간 처리가 적합한 경우

• 실시간 사기 거래 탐지
• IoT 센서 데이터 모니터링
• 실시간 추천 시스템
• 주식 거래 시스템
• 실시간 대시보드

Batch vs. Stream: 무엇을 선택할 것인가

둘 중 하나만 고르는 것이 아니다. 대부분의 현실 시스템은 배치와 스트림을 함께 사용한다. 핵심은 각각의 트레이드오프를 이해하고, 요구사항에 맞게 조합하는 것이다.

이 두 가지를 어떻게 조합할 것인가에 대한 대표적인 아키텍처 패턴이 바로 Lambda 아키텍처와 Kappa 아키텍처다.

Lambda Architecture

Lambda 아키텍처는 Nathan Marz가 제안한 패턴으로, 배치 레이어와 스피드 레이어를 병렬로 운영한다.

                    ┌─────────────────┐
                    │   Batch Layer   │ ── 정확한 결과 (높은 지연)
                    │  (MapReduce,    │
  Data Source ──┬──>│   Spark 등)     │──┐
                │   └─────────────────┘  │   ┌──────────────┐
                │                        ├──>│ Serving Layer │──> Query
                │   ┌─────────────────┐  │   └──────────────┘
                └──>│   Speed Layer   │──┘
                    │  (Storm, Flink  │
                    │   등)           │ ── 빠른 근사치 (낮은 지연)
                    └─────────────────┘

• Batch Layer: 전체 데이터를 대상으로 정확한 결과를 계산한다. 시간이 걸리지만 신뢰할 수 있다.
• Speed Layer: 최근 데이터만 실시간으로 처리하여 빠른 근사치를 제공한다. Batch Layer의 결과가 준비되면 대체된다.
• Serving Layer: 두 레이어의 결과를 합쳐서 최종 뷰를 제공한다.

Lambda의 장점은 정확성과 속도를 모두 확보할 수 있다는 것이다. 하지만 치명적인 단점이 있다. 동일한 비즈니스 로직을 배치와 스트림 두 곳에서 중복 구현해야 한다는 점이다. 코드베이스가 두 벌이 되고, 유지보수 비용이 두 배로 증가한다.

Kappa Architecture

Kappa 아키텍처는 Jay Kreps(LinkedIn, Apache Kafka 공동 창시자)가 Lambda의 복잡성을 해결하기 위해 제안했다. 핵심 아이디어는 단순하다. 모든 데이터를 스트림으로 처리한다.

  Data Source ──> Event Log (Kafka) ──> Stream Processor ──> Serving Layer ──> Query

• 모든 데이터는 이벤트 로그(Event Log) 에 순서대로 기록된다.
• 스트림 프로세서가 이 로그를 소비하여 결과를 생성한다.
• 로직을 변경하거나 재처리가 필요하면, 로그의 처음부터 다시 재생(replay) 하면 된다.

배치 처리가 필요 없는 것이 아니라, 배치 처리를 스트림의 특수한 경우로 취급하는 것이다. Kafka 같은 이벤트 로그가 과거 데이터를 충분히 보관하고 있으면, 로그를 처음부터 재생하는 것이 곧 배치 처리가 된다.

Kappa는 단일 코드베이스로 배치와 스트림을 모두 처리할 수 있어 유지보수가 간결하다. 다만, 대량의 히스토리 데이터를 재처리할 때 스트림 프로세서의 성능이 충분하지 않을 수 있다는 한계가 있다.

Lambda vs. Kappa는 "어느 쪽이 더 좋은가"의 문제가 아니다. 시스템의 데이터 볼륨, 지연 요구사항, 팀의 운영 역량에 따라 적합한 패턴이 달라진다. 최근에는 Apache Flink, Spark Structured Streaming 등이 배치와 스트림을 통합 처리하는 기능을 제공하면서, 두 아키텍처의 경계가 점차 흐려지고 있다.

Streaming Architecture: 핵심 구성 요소

스트리밍 아키텍처를 제대로 이해하려면, 그 내부를 구성하는 핵심 개념들을 하나씩 살펴봐야 한다.

Event Sourcing: 상태가 아닌 이벤트를 저장한다

전통적인 시스템은 현재 상태를 데이터베이스에 저장한다. 은행 계좌의 잔액이 50만 원이면, 데이터베이스에는 balance = 500000이 기록된다. 이전에 얼마였는지, 왜 바뀌었는지는 알 수 없다.

이벤트 소싱(Event Sourcing) 은 발상을 뒤집는다. 상태 대신 상태를 변화시킨 이벤트들의 시퀀스를 저장한다.

[이벤트 1] 계좌 개설 → 초기 잔액 0원
[이벤트 2] 입금 100만 원 → 잔액 100만 원
[이벤트 3] 출금 30만 원 → 잔액 70만 원
[이벤트 4] 이체 수신 20만 원 → 잔액 90만 원

현재 잔액은 이벤트들을 순서대로 재생(replay)하면 언제든 계산할 수 있다. 이 방식의 장점은 명확하다.

• 완전한 감사 추적(Audit Trail): 모든 변경 이력이 남는다.
• 시간 여행 쿼리: 특정 시점의 상태를 복원할 수 있다.
• 이벤트 재생: 버그 수정 후 이벤트를 다시 처리하여 올바른 상태를 재계산할 수 있다.

반면, 이벤트가 계속 쌓이므로 저장 공간이 많이 필요하고, 현재 상태를 조회하려면 이벤트를 처음부터 재생해야 하므로 읽기 성능이 떨어질 수 있다. 이를 보완하기 위해 특정 시점의 상태를 스냅샷(Snapshot) 으로 저장해두는 기법을 함께 사용한다.

Message Queue: 생산자와 소비자를 분리한다

메시지 큐(Message Queue) 는 데이터를 생산하는 쪽(Producer)과 소비하는 쪽(Consumer)을 분리(Decoupling) 하는 중간 버퍼다. 식당의 주문 전표 시스템과 비슷하다. 웨이터(Producer)가 전표를 꽂아두면, 주방(Consumer)이 자기 속도에 맞춰 전표를 가져가 요리한다. 웨이터는 주방이 바쁜지 아닌지 신경 쓸 필요가 없다.

메시지 큐의 두 가지 주요 모델이 있다.

Point-to-Point: 하나의 메시지를 하나의 Consumer만 소비한다. 작업 분배에 적합하다. 대표적으로 RabbitMQ, Amazon SQS 등이 있다.

Publish-Subscribe(Pub/Sub): 하나의 메시지를 여러 Consumer가 구독하여 소비한다. 이벤트 브로드캐스팅에 적합하다. 대표적으로 Apache Kafka, Amazon SNS, Google Pub/Sub 등이 있다.

특히 Apache Kafka는 단순한 메시지 큐를 넘어 분산 이벤트 로그 역할을 한다. 메시지를 소비한 뒤에도 설정된 보존 기간 동안 삭제하지 않기 때문에, 여러 Consumer가 각자의 속도로 같은 데이터를 독립적으로 소비할 수 있고, 필요하면 과거 시점부터 다시 읽을 수 있다. 이 특성이 Kappa 아키텍처를 가능하게 하는 핵심이다.

Stream Processor: 흐르는 데이터를 가공한다

스트림 프로세서(Stream Processor) 는 메시지 큐에서 데이터를 받아 실시간으로 변환, 집계, 분석하는 엔진이다.

스트림 처리에서 가장 까다로운 개념 중 하나가 윈도우(Window) 다. 무한히 흐르는 데이터에서 "최근 5분간의 평균"이나 "지난 1시간 동안의 합계"를 계산하려면, 데이터를 시간 기준으로 잘라야 한다.

주요 윈도우 유형은 다음과 같다.

• Tumbling Window(텀블링 윈도우): 고정 크기의 겹치지 않는 구간. 예를 들어, 매 5분마다 집계.
• Sliding Window(슬라이딩 윈도우): 고정 크기지만 일정 간격으로 슬라이드하며 겹침이 발생. 예를 들어, 5분 윈도우가 1분마다 이동.
• Session Window(세션 윈도우): 이벤트 간 비활성 간격(gap)을 기준으로 동적으로 구간을 결정. 사용자 세션 분석에 유용.

Tumbling Window (5분):
|  0-5분  |  5-10분 | 10-15분 |  ...

Sliding Window (5분 크기, 1분 간격):
|  0-5분  |
  |  1-6분  |
    |  2-7분  |
      ...

Session Window (gap = 3분):
| 이벤트 A, B | ──3분 이상 공백── | 이벤트 C, D, E |

또 하나의 핵심 개념은 이벤트 시간(Event Time) 과 처리 시간(Processing Time) 의 구분이다. 이벤트 시간은 데이터가 실제로 발생한 시점이고, 처리 시간은 시스템에 도착하여 처리되는 시점이다. 네트워크 지연이나 시스템 장애로 둘 사이에 차이가 생기며, 이를 제대로 처리하지 않으면 집계 결과가 부정확해진다.

예를 들어, 오후 2:59에 발생한 결제 이벤트가 네트워크 지연으로 오후 3:01에 도착했다면, 이 이벤트는 "오후 2시-3시 매출"에 포함되어야 할까, "오후 3시-4시 매출"에 포함되어야 할까? Apache Flink 같은 프레임워크는 워터마크(Watermark) 라는 메커니즘을 사용하여 "이벤트 시간 기준으로 여기까지의 데이터는 모두 도착했다"고 판단하는 기준점을 제공한다.

대표적인 스트림 프로세서를 비교하면 다음과 같다.

Data Mesh: 데이터도 도메인이 소유한다

지금까지 다룬 기술적 요소를 넘어, 조직 차원에서 데이터를 어떻게 관리할 것인가에 대한 패러다임도 변화하고 있다.

전통적인 데이터 아키텍처는 중앙 집중형이다. 하나의 데이터 팀이 전사의 데이터를 수집하고, 정제하고, 제공한다. 데이터 웨어하우스(Data Warehouse)든 데이터 레이크(Data Lake)든, 핵심은 하나의 중앙 저장소에 모든 데이터를 모은다는 것이다.

이 방식은 소규모 조직에서는 잘 작동하지만, 조직이 성장하면 병목이 발생한다.

• 중앙 데이터 팀이 모든 도메인의 비즈니스 로직을 이해해야 한다.
• 데이터 요청이 몰리면 중앙 팀이 병목(Bottleneck) 이 된다.
• 데이터 품질 문제의 책임 소재가 불명확해진다.
• 데이터 파이프라인이 거대한 모놀리스(Monolith) 가 되어 변경이 어려워진다.

Data Mesh는 Zhamak Dehghani가 2019년에 제안한 패러다임으로, 마이크로서비스가 모놀리식 애플리케이션을 분해한 것처럼, 중앙 집중형 데이터 아키텍처를 분산형으로 전환한다.

Data Mesh의 4가지 원칙

1. Domain Ownership (도메인 소유권)

데이터의 소유권과 책임을 해당 데이터를 가장 잘 이해하는 도메인 팀에게 부여한다. 주문 데이터는 주문 팀이, 결제 데이터는 결제 팀이 소유하고 관리한다. 중앙 데이터 팀에게 "이 필드가 뭔가요?"라고 물어볼 필요가 없다.

2. Data as a Product (데이터를 제품처럼)

각 도메인이 제공하는 데이터를 제품(Product) 으로 취급한다. 제품에는 품질 기준이 있고, 사용자(소비자)가 있으며, SLA(Service Level Agreement)가 있다.

좋은 데이터 제품이 갖춰야 할 요건은 다음과 같다.

• 발견 가능(Discoverable): 다른 팀이 어떤 데이터가 있는지 쉽게 찾을 수 있다.
• 주소 지정 가능(Addressable): 표준화된 방식으로 접근할 수 있다.
• 신뢰 가능(Trustworthy): 품질이 보장되고, SLA가 명시되어 있다.
• 자기 설명적(Self-describing): 스키마, 의미, 변경 이력이 문서화되어 있다.
• 상호 운용 가능(Interoperable): 다른 도메인의 데이터와 결합하여 사용할 수 있다.

3. Self-serve Data Platform (셀프 서비스 플랫폼)

각 도메인 팀이 데이터 제품을 쉽게 만들고 관리할 수 있도록 플랫폼을 제공한다. 모든 도메인 팀이 Kafka 클러스터를 직접 운영하거나 Spark 파이프라인을 밑바닥부터 구축할 필요는 없다. 플랫폼 팀이 공통 인프라, 도구, 템플릿을 제공하고, 도메인 팀은 이를 활용하여 비즈니스 로직에 집중한다.

4. Federated Computational Governance (연합 거버넌스)

분산이 혼돈을 의미하지는 않는다. 도메인 간 상호 운용성을 보장하기 위한 전사적 표준과 정책이 필요하다. 데이터 형식, 네이밍 규칙, 보안 정책, 품질 기준 등을 자동화된 방식으로 적용한다. 중앙에서 일일이 검토하는 것이 아니라, 정책을 코드로 정의하고 플랫폼에서 자동 적용하는 것이 핵심이다.

Data Mesh는 기술이 아니라 조직 원칙이다. 특정 도구나 프레임워크가 아니라, 데이터에 대한 소유권, 책임, 거버넌스를 재설계하는 접근 방식이다.

Data Fabric: 메타데이터로 연결한다

Data Fabric은 Data Mesh와 자주 비교되지만, 접근 방식이 근본적으로 다르다. Data Mesh가 조직 구조의 변화를 통해 문제를 해결한다면, Data Fabric은 기술 중심의 통합 레이어를 통해 문제를 해결한다.

Data Fabric의 핵심은 메타데이터(Metadata) 의 활용이다. 조직 전체에 흩어져 있는 데이터의 위치, 형식, 관계, 품질, 사용 패턴 등의 메타데이터를 수집하고 분석하여, 데이터 통합과 관리를 자동화한다.

Data Fabric의 핵심 구성 요소

• Knowledge Graph: 데이터 자산 간의 관계를 그래프 형태로 모델링한다. "이 테이블은 저 API의 데이터를 기반으로 만들어졌다" 같은 데이터 리니지(Data Lineage) 를 추적한다.
• Active Metadata Management: 메타데이터를 단순히 기록하는 것을 넘어, 실시간으로 분석하여 데이터 파이프라인을 자동 최적화한다. 예를 들어, 자주 함께 조회되는 데이터셋을 자동으로 사전 조인(pre-join)하거나, 품질 이상을 자동으로 감지한다.
• Unified Data Access: 데이터가 온프레미스에 있든, 클라우드에 있든, 어떤 포맷이든 상관없이 단일 인터페이스로 접근할 수 있게 한다.

Data Mesh vs. Data Fabric

두 패러다임은 상호 배타적이지 않다. Data Mesh의 조직 원칙을 따르면서, 각 도메인의 데이터를 Data Fabric의 기술 레이어로 연결하는 하이브리드 접근도 가능하다. 실제로 많은 조직이 이 두 가지를 결합하여 사용하고 있다.

정리

데이터 파이프라인은 단일 기술이 아니라, 여러 계층의 의사결정이 쌓인 아키텍처다. 이 글에서 다룬 핵심 개념을 정리하면 다음과 같다.

• Batch Processing: 데이터를 모아서 한 번에 처리한다. 높은 처리량과 정확성이 강점이지만, 지연이 크다.
• Stream Processing: 데이터를 도착 즉시 처리한다. 낮은 지연이 강점이지만, 상태 관리와 정확성 보장이 어렵다.
• Lambda / Kappa Architecture: 배치와 스트림을 조합하는 패턴이다. Lambda는 두 레이어를 병렬로 운영하고, Kappa는 스트림 하나로 통합한다.
• Streaming Architecture: 이벤트 소싱, 메시지 큐, 스트림 프로세서가 핵심 구성 요소이며, 윈도우와 이벤트 시간 처리가 핵심 난제다.
• Data Mesh: 도메인 중심의 분산 데이터 소유권을 통해 중앙 집중형의 병목을 해소한다.
• Data Fabric: 메타데이터 기반의 기술 레이어로 데이터 통합과 관리를 자동화한다.

"어떤 기술을 쓸까?"보다 중요한 질문은 "이 데이터의 가치는 시간에 얼마나 민감한가?" 다. 그 답에 따라 배치, 스트림, 또는 둘의 조합이 결정되고, 조직의 규모와 성숙도에 따라 Data Mesh나 Data Fabric 같은 관리 패러다임이 선택된다.