람다 아키텍처: 배치와 스트림을 나란히 돌리는 이유
배치 레이어와 스피드 레이어를 병행해 정확성과 속도를 동시에 확보하는 람다 아키텍처의 구조와 코드 중복이라는 대가, 카파·델타 같은 대안을 정리한다.
2026-08-13 · 최초 발행 2025-05-23
정확성과 속도, 둘 다 놓치지 않으려는 시도
람다 아키텍처(Lambda Architecture)는 배치 레이어와 스피드 레이어를 병행해 데이터의 정확성과 처리 속도를 모두 확보하려는 데이터 처리 아키텍처다. 2011년 네이션 마츠(Nathan Marz)가 Twitter에서 근무하며 대규모 분산 시스템의 문제를 해결하기 위해 제안했다. 빅데이터 환경에서 실시간 처리와 대용량 일괄 처리의 장점을 결합하려는 목적으로, 전통적인 배치 처리 방식의 정확성과 실시간 처리 방식의 신속성을 모두 충족시키는 하이브리드 접근법이다.
레이어가 나눠 맡는 일
람다 아키텍처는 세 개의 레이어로 구성된다.
**배치 레이어(Batch Layer)**는 원시 데이터(Master Dataset) 전체를 처리해 배치 뷰(Batch View)를 만든다. 처리 시간은 길지만 모든 데이터를 포괄적으로 분석해 높은 정확성과 완전성을 보장한다. Hadoop, Spark Batch Processing, MapReduce가 대표적인 기술이다.
**스피드 레이어(Speed Layer)**는 최근 데이터만 실시간으로 처리해 실시간 뷰(Real-time View)를 만든다. 배치 처리 사이의 시간 갭을 보완하는 역할로, 낮은 지연 시간과 고속 처리가 특징이다. Apache Storm, Kafka Streams, Spark Streaming, Flink를 쓴다.
**서빙 레이어(Serving Layer)**는 배치 뷰와 실시간 뷰를 병합해 최종 쿼리 결과를 제공한다. 사용자 쿼리에 응답하고 최종 결과 데이터를 인덱싱·최적화하는 역할이다. HBase, Cassandra, Redis, Elasticsearch가 여기 쓰인다.
데이터는 어떻게 흐르는가
모든 입력 데이터는 변경 불가능(immutable)한 방식으로 원시 데이터 저장소에 저장되고, 동일한 데이터가 배치 레이어와 스피드 레이어로 동시에 전달된다.
배치 레이어는 정기적으로(예: 매일, 매시간) 전체 데이터셋을 처리해 사전계산된 뷰(pre-computed views)를 생성한다. 정확성이 높은 결과를 만들지만 처리 시간이 길어 지연이 발생한다. 스피드 레이어는 가장 최근에 들어온 데이터, 즉 배치 레이어의 마지막 처리 이후 수집된 데이터만 실시간으로 처리한다. 근사치(approximation) 결과를 내놓지만 처리 지연은 최소화된다.
서빙 레이어는 이 두 뷰를 통합해 최종 쿼리 결과를 제공하고, 사용자에게 일관된 결과를 보여줄 수 있도록 뷰를 조정한다.
이 구조로 얻는 것
배치 레이어의 정확한 결과와 스피드 레이어의 빠른 처리를 동시에 확보할 수 있다는 것이 핵심 이점이다. 원시 데이터의 불변성(immutability)은 시스템 실패 시에도 데이터 손실을 최소화하고 복원·재처리를 쉽게 만들어 내결함성(Fault Tolerance)을 강화한다. 각 레이어를 독립적으로 확장할 수 있어 필요에 따라 배치 또는 스피드 레이어의 리소스를 조정할 수 있고, 정확성이 중요한 분석과 실시간성이 중요한 분석을 모두 지원해 금융·이커머스·IoT 등 다양한 산업 영역에 적용할 수 있다.
그 대가: 중복과 복잡성
배치 레이어와 스피드 레이어에서 동일한 비즈니스 로직을 서로 다른 기술로 각각 구현해야 하다 보니 두 레이어 간 결과가 어긋날 가능성이 있고, 개발·유지보수 부담이 늘어난다. 여러 기술 스택을 함께 관리해야 해서 운영 복잡도가 올라가고, 서빙 레이어에서 배치 뷰와 실시간 뷰를 통합하는 과정 자체도 복잡하다. 동일한 데이터가 여러 시스템에 중복 저장되고 계산 리소스도 중복 소비된다. 배치 처리와 실시간 처리 간의 데이터 일관성을 유지하기 어렵고, 배치 처리 주기에 따라 데이터 일관성이 영향을 받는다.
실제로 어디에 쓰였나
Twitter는 사용자 행동 분석과 트렌드 감지에 이 구조를 썼다 — 배치 레이어는 사용자 행동 패턴을 장기 분석하고, 스피드 레이어는 실시간 트렌드 감지와 콘텐츠 추천을 맡았다. 금융 거래 모니터링에서는 배치 레이어가 과거 거래 패턴을 분석해 사기 감지 모델을 구축하고, 스피드 레이어가 실시간 거래에 대한 즉각적인 사기 감지를 담당한다. 스마트 공장의 IoT 데이터 처리에서는 배치 레이어가 장기간 센서 데이터를 분석해 패턴을 파악하고, 스피드 레이어가 실시간 이상 감지와 경고를 맡는다. 전자상거래 플랫폼에서는 배치 레이어가 사용자 구매 패턴을 분석해 추천 모델을 만들고, 스피드 레이어가 실시간 재고 관리와 개인화된 추천을 처리한다.
복잡성을 줄이려는 후속 시도들
람다 아키텍처의 복잡성을 해결하려는 시도로 몇 가지 대안이 나왔다. Jay Kreps가 제안한 **카파 아키텍처(Kappa Architecture)**는 단일 스트림 처리 레이어만 사용해 배치 레이어를 아예 없앤다. 모든 데이터를 스트림으로 간주하고 동일한 처리 엔진을 쓰며, Apache Kafka를 중심으로 구성된다. **델타 아키텍처(Delta Architecture)**는 데이터 레이크 기반으로, 다양한 소스의 데이터를 델타 레이크에 저장해 필요에 따라 배치·스트림 처리를 선택한다. Databricks Delta Lake가 대표적이다. **유니파이드 아키텍처(Unified Architecture)**는 Apache Beam, Spark Structured Streaming 같은 통합 처리 엔진으로 동일한 코드로 배치와 스트림을 모두 처리해 코드 중복 문제를 해결한다.
레이어별로 조합되는 기술
배치 레이어는 HDFS·Amazon S3·Azure Data Lake 같은 저장 기술에 Hadoop MapReduce·Apache Spark·Hive 같은 처리 엔진을 얹고, Apache Airflow·Oozie·Azkaban으로 스케줄링한다. 스피드 레이어는 Apache Kafka·RabbitMQ 같은 메시징 시스템 위에서 Apache Storm·Spark Streaming·Flink·Kafka Streams로 스트림을 처리하고, Redis·Hazelcast 같은 인메모리 저장소를 함께 쓴다. 서빙 레이어는 HBase·Cassandra·MongoDB 같은 NoSQL 데이터베이스, Elasticsearch 같은 검색 엔진, BigQuery·Snowflake·Redshift 같은 데이터 웨어하우스로 최종 결과를 서빙한다.
설계할 때 놓치기 쉬운 것들
배치 뷰와 실시간 뷰의 데이터 모델 일관성을 확보하고 스키마 관리·버전 관리 전략을 세워야 한다. 두 레이어에 데이터를 전달하는 파이프라인을 효율적으로 구축하고, 데이터 유실을 막을 중복 처리 메커니즘도 필요하다. 배치 뷰와 실시간 뷰를 효과적으로 병합하는 방법과 데이터 불일치 해결 로직도 미리 정해둬야 한다. 레이어별 리소스 할당을 최적화하고 병목 현상을 식별해야 하며, 데이터 처리 상태를 모니터링하고 장애 상황에 대응·복구하는 체계도 갖춰야 한다.