배치와 스트림을 따로 둘 것인가 — Lambda·Kappa Architecture와 Data Lakehouse의 선택지
Lambda·Kappa Architecture의 구조적 차이부터 Delta Lake·Iceberg·Hudi 같은 Lakehouse 포맷, Bronze-Silver-Gold 통합까지 빅데이터 아키텍처를 정리한다
2026-08-12 · 최초 발행 2026-01-25
실시간 스트림과 배치 처리를 동시에 지원해야 하는 데이터 인프라에서, 가장 먼저 부딪히는 질문은 "이 둘을 같은 파이프라인에 태울 것인가, 따로 둘 것인가"다. Lambda Architecture와 Kappa Architecture는 이 질문에 정반대로 답했고, Data Lakehouse는 그 답 위에 저장 계층을 다시 얹는 방식으로 등장했다.
Lambda: 배치와 스트림을 나란히 둔다
Lambda Architecture는 2011년 Nathan Marz가 Twitter에서 제안한 하이브리드 처리 모델이다. 원본 데이터를 변경하지 않고 누적 저장하는 불변성을 전제로, 배치(Batch)와 스트림(Speed) 레이어를 병행해 CAP 정리가 요구하는 일관성과 가용성의 균형을 맞춘다.
Batch Layer는 모든 원본 데이터를 불변 형태로 저장하고 주기적으로 전체 데이터셋에 대한 뷰를 만든다 — 정확도는 높지만 응답이 느리다. Speed Layer는 최근 데이터만 처리해 실시간 뷰를 제공하고, 지연시간이 낮은 대신 근사치를 허용하며, 배치 레이어가 따라잡으면 그 결과는 폐기된다. Serving Layer는 배치 뷰와 실시간 뷰를 병합해 사용자 요청에 단일 인터페이스로 응답한다.
이 구조의 장점은 명확하다. 모든 데이터가 배치 레이어에 보존돼 재계산으로 오류를 복구할 수 있고, 배치와 스트림을 독립적으로 수평 확장할 수 있으며, 장애가 나도 배치 레이어에서 재생성이 가능하다. 대가도 그만큼 크다 — 배치와 스트림 로직을 따로 구현해야 해 유지보수가 복잡해지고, 두 개의 파이프라인을 운영하는 만큼 인프라 비용이 늘며, 배치 뷰와 실시간 뷰 사이에 일시적 불일치가 생겨 병합 로직이 복잡해진다.
Kappa: 파이프라인을 하나로 줄인다
Kappa Architecture는 Jay Kreps가 LinkedIn에서 Lambda의 단순화 버전으로 제안했다. 모든 데이터를 스트림 하나로 처리하고, 재계산이 필요하면 로그를 재생해 같은 파이프라인을 다시 돌리는 방식으로 배치 레이어를 대체한다.
| 구분 | Lambda | Kappa |
|---|---|---|
| 처리 레이어 | 배치 + 스트림 | 스트림만 |
| 코드 복잡도 | 높음 (중복) | 낮음 (단일) |
| 지연시간 | 혼합 (배치는 느림) | 일관되게 낮음 |
| 재계산 | 배치 레이어 사용 | 스트림 재생 |
| 적합 사례 | 복잡한 배치 분석 필요 | 실시간 중심 워크로드 |
클라우드에 종속되지 않는 컴포넌트를 고른다
Lambda든 Kappa든 클라우드 중립적으로 구성하려면 계층마다 오픈소스 대안이 갖춰져 있어야 한다. 데이터 수집은 분산 메시지 큐이자 로그 보존을 담당하는 Apache Kafka, 멀티 테넌시와 지리적 복제를 지원하는 Apache Pulsar, 복잡한 라우팅에 강한 RabbitMQ가 맡는다. 스트림 처리 엔진으로는 정확히 한 번(Exactly-Once) 처리를 보장하는 Apache Flink, 마이크로 배치 방식의 Spark Streaming, 낮은 지연시간의 Apache Storm, Kafka 네이티브 처리인 Kafka Streams가 있다. 배치 처리는 통합 배치/스트림 API를 제공하는 Apache Spark, 전통적인 Hadoop MapReduce, SQL 기반 대화형 쿼리인 Presto/Trino가 담당하고, 저장소는 HDFS·Cassandra·Elasticsearch, 그리고 MinIO·Ceph 같은 S3 호환 오브젝트 스토리지로 구성한다.
온프레미스와 여러 클라우드에 흩어진 Kafka 클러스터를 미러링하고, 각 환경의 Flink가 로컬에서 처리한 뒤 각자의 오브젝트 스토리지에 쓰고, 마지막에 Presto 하나로 쿼리를 통합하는 패턴이다.
Data Lakehouse: 레이크와 웨어하우스를 합친다
Data Lakehouse는 저비용 저장이라는 Data Lake의 장점과 구조화된 쿼리 성능이라는 Data Warehouse의 장점을 융합한 구조다. Delta Lake·Apache Iceberg·Apache Hudi가 ACID 트랜잭션을 지원하고, 스키마 진화로 유연한 메타데이터 관리를 하며, 과거 버전 데이터에 접근하는 시간 여행 기능을 제공한다.
이걸 가능하게 하는 세 가지 핵심 기술이 있다. 메타데이터 레이어는 파일 기반 저장소 위에 테이블 추상화를 제공하고 파티션 프루닝·통계 정보로 쿼리를 최적화한다. 트랜잭션 로그는 낙관적 동시성 제어와 로그 기반 커밋으로 ACID를 보장하고 충돌을 검출·재시도한다. 쿼리 최적화는 Parquet·ORC 같은 컬럼형 저장, Z-ordering과 Data Skipping, 캐싱·인덱싱으로 이뤄진다.
세 포맷은 각자 무게 중심이 다르다.
| 포맷 | 주도 | 특징 |
|---|---|---|
| Delta Lake | Databricks | Spark 생태계에 최적화, 스트리밍·배치 통합 처리, 간단한 API |
| Apache Iceberg | Netflix | 엔진 중립적 설계(Spark, Flink, Presto 등), 숨겨진 파티셔닝, 스냅샷 기반 시간 여행 |
| Apache Hudi | Uber | 증분 데이터 처리에 강점, Copy-on-Write·Merge-on-Read 모드, 레코드 레벨 업데이트/삭제 |
Bronze-Silver-Gold로 Lambda/Kappa와 Lakehouse를 잇는다
Bronze Layer는 원본 데이터를 있는 그대로 수집한다 — 스트림과 배치 모두 Delta Lake에 저장되고 불변성이 유지돼 재처리가 가능하다. Silver Layer는 중복 제거·스키마 정합성 검증 같은 정제와 표준화, 조인·변환을 거친 데이터가 쌓이는 곳이다. Gold Layer는 비즈니스 메트릭을 집계하고 부서별 특화 뷰를 만들어 성능 최적화된 쿼리의 대상이 된다.
이 구조를 클라우드 중립적으로 가져가면 얻는 이점도 뚜렷하다. 오픈소스 기반 스택으로 벤더 종속성을 피하고 마이그레이션이 쉬워지며, 저렴한 오브젝트 스토리지와 탄력적 컴퓨팅으로 비용을 최적화하고, 통합된 메타데이터 카탈로그와 접근 제어로 거버넌스를 강화할 수 있다. 접근 제어는 Apache Ranger가 컬럼 레벨 마스킹까지 포함한 세밀한 정책과 감사 로그를 담당하고, 데이터 계보는 Apache Atlas가 데이터 흐름을 추적해 규정 준수 보고를 뒷받침한다.
실제로 쓰이는 곳
Netflix의 Keystone은 Iceberg 기반 Lakehouse로 S3를 주 스토리지로 삼고 Spark·Presto·Flink 등 다양한 쿼리 엔진을 지원한다. Uber는 Hudi로 실시간 데이터 Upsert 처리와 증분 ETL 파이프라인을 구성하고, GDPR 준수를 위한 레코드 삭제에도 이를 활용한다. Databricks의 Delta Lake는 통합 배치/스트림 처리에 Photon 엔진으로 쿼리를 가속하고, Unity Catalog로 거버넌스를 통합한다.
클라우드 중립 환경을 구축할 때 실무적으로 챙기는 것들
컨테이너 기반 배포에서는 Flink·Spark 클러스터를 Pod로 배포하고 Helm 차트로 표준화하며 HPA로 자동 확장한다. Flink Kubernetes Operator, Spark on Kubernetes Operator, Strimzi Kafka Operator 같은 Operator 패턴이 이 배포를 선언적으로 관리한다. 스토리지 추상화는 MinIO·Ceph RGW 같은 온프레미스 오브젝트 스토리지가 클라우드와 동일한 S3 API를 제공해 투명한 마이그레이션을 가능하게 하고, 핫 데이터는 SSD에 콜드 데이터는 HDD·아카이브 스토리지에 자동 수명 주기 정책으로 옮기는 데이터 티어링이 따라붙는다. 메타데이터 관리는 Apache Hive Metastore가 테이블 스키마를 중앙에서 관리해 Spark·Presto·Flink가 공유하고, AWS Glue Data Catalog와 호환되도록 구성하면 하이브리드 환경에서도 메타데이터를 동기화할 수 있다.
성능 최적화
쿼리 성능은 시간 기반·비즈니스 키 기반 파티셔닝으로 스캔 범위를 줄이는 파티션 프루닝, 작은 파일 문제를 해결하는 주기적 Compaction(최적 파일 크기 128MB~1GB), Parquet·ORC 컬럼형 저장에 스키마 투영과 술어 푸시다운을 더하는 방식으로 끌어올린다. 스트림 처리 최적화는 Out-of-Order 이벤트를 다루는 Watermark 전략과 지연 허용 범위 설정, Flink의 RocksDB 기반 상태 백엔드와 체크포인트 간격 최적화·증분 체크포인트가 핵심이다.
앞으로의 과제는 스트림 네이티브 Lakehouse로 밀리초 단위 지연시간과 실시간 ACID 트랜잭션을 지원하는 방향, Feature Store와 Lakehouse를 통합해 모델 훈련 데이터 버전 관리와 MLOps 파이프라인을 자동화하는 방향, 엣지에서 실시간 처리하고 클라우드로 집계 데이터만 보내는 엣지-클라우드 연속체, 그리고 도메인별 Lakehouse와 분산 데이터 소유권을 전제로 한 데이터 메시(Data Mesh)로 향하고 있다.