데이터 아키텍처 패턴 — Lambda, Kappa, Data Mesh
40 Data Engineering System Design Interview Questions (2026) — DataVidhya (blog) Q6. Lambda Architecture (pp.4-5); Q7. Kappa Architecture (p.5); Q11. Data Mesh (pp.6-7); FAQ 'Lambda vs Kappa' (p.20)
이 모듈을 다 읽으면
- Lambda와 Kappa 아키텍처의 구조적 차이와 각각의 핵심 실패 모드를 설명할 수 있다
- Data Mesh가 중앙집중형 웨어하우스 모델의 병목을 어떻게 재구조화하는지 설명할 수 있다
Lambda 아키텍처는 정확성을 위한 배치 계층과 저지연을 위한 스피드 계층을 병렬로 운영하지만 두 코드베이스가 어긋나는 '코드 발산'이 치명적 실패 모드다. Kappa 아키텍처는 배치 계층을 없애고 모든 것을 스트림으로 다루어 이 문제를 해결하지만 극단적 규모에서 재처리 비용이 발목을 잡는다. Data Mesh는 데이터 소유권 자체를 중앙 팀에서 도메인 팀으로 분산시켜 아키텍처의 병목을 근본적으로 재구조화한다.
Lambda 아키텍처와 그 실패 모드
Lambda 아키텍처는 두 개의 파이프라인을 병렬로 운영한다 — 정확성을 위해 전체 과거 데이터를 재처리하는 배치 계층과, 저지연을 위해 최근 데이터를 실시간으로 처리하는 스피드 계층이다. 서빙 계층이 두 출력을 병합한다. 과거 재처리(백필, 정정)와 초 미만의 신선도가 모두 진짜로 필요하고, 두 코드베이스를 유지할 엔지니어링 여력이 있을 때 추천할 만하다.
결정적인 실패 모드는 코드 발산(code divergence)이다 — 배치용 Spark 잡과 스트리밍용 Flink 잡이 같은 로직을 서로 다르게 구현해 서로 다른 숫자를 만들어낸다. 규모가 커질수록 이 이중 유지보수 부담 때문에 많은 팀이 Lambda를 버리고 Kappa나 통합 배치-스트리밍 엔진으로 옮겨갔다.
핵심 포인트
- Lambda 아키텍처=배치 계층(정확성, 전체 재처리)+스피드 계층(저지연, 최근 데이터)을 서빙 계층에서 병합하는 구조.
- 핵심 실패 모드는 코드 발산 — 배치(Spark)와 스트리밍(Flink) 코드가 같은 로직을 다르게 구현해 서로 다른 숫자를 내는 것이며, 이 때문에 많은 팀이 Lambda를 포기했다.
Kappa 아키텍처와 Data Mesh
Kappa 아키텍처는 배치 계층을 아예 없애고 모든 것을 스트림으로 취급한다. 과거 재처리는 이벤트 로그를 처음부터 같은 스트리밍 파이프라인으로 재생(replay)해서 수행하며, 이는 Lambda의 코드 발산 문제를 해결한다 — 코드베이스와 로직 경로가 하나이기 때문이다. 한계는 극단적 규모에서의 비용과 실현 가능성이다 — 수백 페타바이트에 달하는 2년치 이벤트를 스트리밍 엔진으로 재생하는 것은 Parquet 파일 위에서 배치 Spark 잡을 도는 것보다 흔히 더 느리고 비싸다. Kappa는 보존 기간이 제한적이고(30~90일) 재처리가 드물게 필요하며, 이벤트 로그(티어드 스토리지를 쓰는 Kafka나 Redpanda)가 재생 볼륨을 감당할 수 있을 때 가장 잘 작동한다. 2026년 기준 대부분의 팀은 유지보수가 단순한 Kappa를 선호하지만, Lambda는 레거시 시스템이나 스트림 재처리 비용이 너무 큰 경우에 여전히 남아 있다.
Data Mesh는 데이터 소유권을 중앙 데이터 엔지니어링 팀에서 결제·검색·물류 같은 도메인 팀으로 분산시킨다. 각 도메인이 자체 파이프라인·스토리지·품질 보증을 갖춘 '데이터 제품(data product)'으로서 자신의 데이터를 소유하고, 중앙 플랫폼 팀은 모두를 위한 파이프라인을 만드는 대신 셀프서비스 인프라(컴퓨트, 카탈로그, 거버넌스)를 제공한다. 이는 중앙 ETL 팀이 병목이 되는 단일 모놀리식 웨어하우스 구조를, 공유 메타데이터 카탈로그와 표준화된 데이터 계약(스키마+SLA+품질 테스트), 탐색 레이어를 갖춘 연합형(federated) 스토리지 구조로 근본적으로 재구성한다. 실패 모드는 비일관성이다 — 강한 거버넌스와 상호운용성 표준이 없으면 각 도메인이 저마다 포맷과 품질 기준을 재발명해 도메인 간 쿼리를 신뢰할 수 없게 된다.
핵심 포인트
- Kappa 아키텍처=배치 계층 제거, 재처리는 이벤트 로그 재생으로 수행 — 코드 발산 문제는 해결하지만 극단적 규모(수백 PB, 다년치 이력)에서는 재생 비용이 배치보다 비싸질 수 있다.
- Data Mesh는 데이터 소유권을 도메인 팀에 분산시키고 중앙 팀은 셀프서비스 인프라(컴퓨트/카탈로그/거버넌스)만 제공한다 — 강한 거버넌스와 데이터 계약 없이는 도메인마다 포맷이 갈려 비일관성이라는 실패 모드에 빠진다.