Flink냐 Spark냐보다 먼저 정해야 하는 것 — 실시간 분석 파이프라인 설계
실시간 분석·스트림 처리·데이터 파이프라인 자동화를 엔진 선택 이전의 설계 원칙, 일관성·오류 처리 전략 중심으로 정리한다.
2026-08-12 · 최초 발행 2025-12-13
Flink를 쓸지 Spark Structured Streaming을 쓸지는 사실 나중 질문이다. 먼저 답해야 할 질문은 이벤트를 어떤 키로 파티셔닝할 것인지, 시간을 이벤트 타임 기준으로 볼 것인지, 그리고 정확히 한 번(exactly-once) 처리를 어디까지 보장할 것인지다. 이 결정이 틀리면 엔진을 아무리 잘 골라도 파이프라인은 흔들린다.
Real-Time Analytics는 이벤트 발생 직후 수 초 이내에 결과를 도출해 의사결정과 자동화 액션의 지연을 최소화하는 분석 방식이다. 스트리밍 데이터를 기반으로 지속적으로 계산하고 증분 업데이트하며, 최신 상태를 반영한 대시보드·알림을 구현한다. 이를 뒷받침하는 것이 Stream Processing — 끝없는 이벤트 스트림에 대한 지속적 계산 모델로, 윈도우·워터마크·상태(state) 기반 집계·조인·패턴 탐지를 수행한다. 배치 대비 낮은 지연과 높은 처리량, 상태 일관성 보장이 설계의 핵심이다. 그리고 이 모든 걸 운영 가능하게 만드는 것이 Data Pipeline Automation이다. 수집→처리→저장→서빙 전 단계를 스케줄링·의존성·재시도·관측성·스키마 관리까지 포함해 자동화하고, Airflow·Dagster 같은 오케스트레이션 도구와 이벤트 기반 트리거, CI/CD·IaC 연계로 운영을 표준화한다.
계층별로 무엇을 결정해야 하는가
수집 계층은 메시지 브로커 중심으로 설계한다. Kafka·Pulsar를 채택하고 파티셔닝·정렬 키 기준을 먼저 확립해야 하며, 변경 데이터 캡처(CDC)나 트랜잭셔널 아웃박스 패턴을 적용해 이중 쓰기 불일치를 제거한다. 스키마 레지스트리와 호환성 정책(Backward/Full)도 이 단계에서 정해둔다.
처리 계층에서는 Flink·Spark Structured Streaming·Kafka Streams 중 워크로드 특성에 맞는 엔진을 고른다. 상태 관리와 체크포인트 운영, exactly-once 시맨틱 구현, 백프레셔 관리가 필수이며, 이벤트 타임을 우선 기준으로 삼아 워터마크와 윈도우 전략을 세워야 한다.
저장·서빙 계층은 OLAP·TSDB·피처 스토어를 이중화해, 저지연이 필요한 핫패스와 심층 분석용 웜/콜드패스를 분리한다. Upsert·머지·디듀프 전략을 확립하고 Lakehouse(Iceberg·Delta)와 동기화하며, 인덱스·파티션·머터리얼라이즈드 뷰로 쿼리를 가속한다.
오케스트레이션은 DAG 기반 의존성 관리에 이벤트 트리거와 스케줄을 혼합 운용하고, 재시도·서킷브레이커·DLQ를 자동화해 실패를 분리하고 롤백 전략을 내재화한다. IaC·CI/CD를 통합해 스키마·잡·커넥터를 선언적으로 관리하는 것도 이 계층의 몫이다.
마지막으로 관측성·거버넌스 계층에서는 메트릭·로그·트레이스를 통합해 지연·처리량·컨슈머 랙·워터마크 지표를 표준화하고, 완전성·신선도·스키마 같은 데이터 품질 규칙을 자동 점검한다. 토픽 ACL, PII 마스킹, 감사 로그 유지도 여기 속한다.
엔진 선택 비교
| 기술 | 성능(지연/처리량) | 확장성 | 일관성 | 안정성/복구 | 운영 편의 |
|---|---|---|---|---|---|
| Apache Flink | ms~수백 ms, 고처리량 우수 | 매우 우수, 대규모 클러스터 안정 | Exactly-once 체크포인트/2PC 지원 | 잡/상태 복구 강력 | 러닝커브 높음, 튜닝 필요 |
| Spark Structured Streaming | 수백 ms~수 초, 마이크로배치 기반 | 우수, Spark 클러스터 활용 | 이벤트 타임·상태 일관성 양호 | 워터마크/상태 타임아웃 안정 | Spark 생태계 편의성 높음 |
| Kafka Streams | ms 단위, 앱 내 임베디드 | 토픽 파티션 수에 비례 확장 | EOS 트랜잭션 지원 | 로컬 상태+체인지로그 복구 | 배포 간단, JVM 앱 친화 |
| ksqlDB | 저지연(SQL 중심) | 브로커/서버 증설로 확장 | EOS 시맨틱 제공 | 서버 장애 자동 복구 | SQL 생산성 높음, 제한된 연산 |
파이프라인 구조
어디에 쓰이는가
금융권 이상거래 탐지(FDS)에서는 카드 승인 이벤트와 계정 로그인 로그를 입력으로 받아 CDC로 계정 속성을 동기화하고, 세션 조인·슬라이딩 윈도우로 피처를 추출해 모델 추론 서버에 넘긴다. 결과는 승인 차단 알림과 케이스 관리 시스템 적재로 이어지고, 회피 케이스는 DLQ에 축적된다.
커머스·미디어의 개인화 추천은 클릭·뷰·장바구니 스트림과 카탈로그 변경 CDC를 입력으로 유저-아이템 피처 스트림을 갱신하고 피처 스토어에 upsert한다. 랭킹 API 서빙과 캠페인 실시간 세그먼트 생성이 출력이다.
제조·에너지의 IoT 이상 감지는 센서 텔레메트리를 시계열로 압축 전송받아 고정·적응 임계값과 CEP(복합 이벤트 처리) 패턴 매칭, 다운샘플링을 거친다. 결과는 경보와 워크오더로 나가고 TSDB에 저장돼 대시보드에 반영된다.
SRE의 실시간 가시성은 애플리케이션 로그·메트릭·분산 트레이스를 입력으로 서비스 지연 상관분석과 에러 버짓 소진 감지를 수행해, 온콜 알림과 자동 확장·트래픽 전환 트리거로 이어진다.
설계에서 놓치면 안 되는 것들
이벤트 설계와 키 전략이 가장 먼저다. 파티션 키를 업데이트 키와 일치시키고 순서 보장을 설계해야 한다. 시간 처리는 이벤트 타임을 기준으로 삼고 워터마크의 허용 지연을 명확히 정의해야 하며, 상태 관리 비용도 고려 대상이다 — TTL·컴팩션·체인지로그 크기 관리, 핫키 분산까지 신경 써야 한다.
일관성은 소스·경로·싱크 세 구간이 함께 맞아야 완성된다. 소스는 트랜잭셔널 아웃박스나 CDC 스냅샷+증분 조합으로, 경로는 EOS(Exactly-once)를 활성화하고 체크포인트 주기·크기를 균형화하는 방식으로, 싱크는 2PC 싱크 커넥터나 Idempotent Upsert 키 설계로 보장한다.
신뢰성 측면에서는 일시 오류는 재시도, 영구 오류는 DLQ로 처리를 차등화하고, 스키마 진화는 호환성 정책과 Producer→Consumer 순서의 롤아웃 규칙을 지켜야 한다. 백프레셔는 입력 제한과 배출량 제어, 오토스케일링 연동으로 보호한다. 운영 측면에서는 P99 처리 지연, 컨슈머 랙, 워터마크 스큐, DLQ율을 대시보드로 표준화하고, 파티션·동시성·체크포인트 저장소 IOPS를 관리하며, ACL·토픽 레벨 암호화·PII 토큰화·감사 추적으로 보안을 갖춰야 한다.
이 모든 결정에는 트레이드오프가 따라붙는다. 지연을 낮게 잡을수록 늦게 도착하는 이벤트를 처리하지 못할 위험이 커지고, ksqlDB 같은 SQL 기반 도구는 운영이 단순한 대신 Flink 같은 엔진의 고급 연산 유연성을 포기해야 한다. EOS·2PC를 쓰면 일관성은 높아지지만 처리량과 지연이 늘어날 수 있다.
결과적으로 실시간 분석의 가치는 스트리밍 아키텍처·자동화·거버넌스가 함께 갖춰졌을 때 극대화된다. 지연·정확성에 대한 SLO를 먼저 명확히 정하고, 스키마·키 설계를 선행한 뒤 EOS·관측성·DLQ를 기본으로 탑재해 점진적으로 롤아웃하는 순서가 배치 대비 10~100배 수준의 레이턴시 단축을 실제로 얻어내는 길이다.