Orc’s WIKI

Orc Hwang

들어가며
지금까지 이 시리즈에서 수집·저장·변환·오케스트레이션이라는 개별 부품을 하나씩 살펴봤다면, 이번 글은 그 부품들을 어떻게 조립할 것인가를 다룹니다. 같은 Kafka, 같은 Spark, 같은 레이크하우스를 쓰더라도, 그것들을 어떤 모양으로 엮느냐에 따라 시스템의 성격이 완전히 달라집니다. 실시간성을 위해 경로를 둘로 나눌 것인가 하나로 합칠 것인가, 데이터 품질을 어느 지점에서 끌어올릴 것인가, 데이터의 소유권을 중앙에 둘 것인가 도메인에 분산할 것인가 — 이런 큰 결정들이 곧 데이터 아키텍처 패턴입니다.
이 글은 Data-Engineering-Essential 시리즈의 7단계로, 현장에서 가장 자주 언급되는 네 가지 패턴을 다룹니다. Lambda와 Kappa는 배치와 스트림을 어떻게 조합할지를, Medallion은 데이터 품질을 어떻게 단계적으로 끌어올릴지를, Modern Data Stack과 Data Mesh는 시스템과 조직을 어떻게 구성할지를 푸는 패턴입니다. 중요한 것은 정답을 외우는 것이 아니라, 각 패턴이 무엇을 풀고 그 대가로 무엇을 포기하는지를 보는 눈입니다.
📌 이 글에서 다루는 내용
🔍 핵심 주제
Lambda vs Kappa: 배치+속도 이중 경로 vs 스트림 단일 경로, 그리고 각각의 트레이드오프
Medallion 아키텍처: Bronze→Silver→Gold로 품질을 끌어올리는 계층 구조와 레이크하우스
Modern Data Stack: 매니지드 SaaS를 레고처럼 조립하는 모듈형 클라우드 스택
Data Mesh: 도메인 중심 분산 데이터 오너십과 그 4가지 원칙
🎯 왜 중요한가
도구는 바뀌어도 시스템을 엮는 구조의 결정은 오래 남습니다. 패턴을 알면 “우리 요구(지연·규모·조직)에는 어떤 모양이 맞는가”를 트레이드오프 관점에서 판단할 수 있고, 유행하는 아키텍처를 무비판적으로 따라가지 않게 됩니다.
한눈에 보기 — 네 패턴의 자리
네 패턴은 서로 경쟁하는 대안이 아니라, 서로 다른 질문에 답하는 도구입니다. 먼저 전체 지도를 그려 두면 세부가 자리를 잡습니다. 처리 경로(Lambda/Kappa)는 “실시간을 어떻게 얻는가”를, Medallion은 “품질을 어디서 끌어올리는가”를, MDS/Data Mesh는 “시스템과 조직을 어떻게 구성하는가”를 묻습니다.
flowchart TB
 Q{"무엇을 결정하려는가?"}
 Q -->|"실시간 처리 경로"| PROC["처리 경로 패턴"]
 Q -->|"데이터 품질 계층"| QUAL["Medallion 아키텍처"]
 Q -->|"시스템·조직 구성"| ORG["구성 패턴"]
 PROC --> LAMBDA["Lambda 배치 + 속도 이중 경로 → 서빙에서 병합"]
 PROC --> KAPPA["Kappa 스트림 단일 경로 → 재처리도 스트림으로"]
 QUAL --> MED["Bronze(원본) → Silver(정제) → Gold(비즈니스)"]
 ORG --> MDS["Modern Data Stack 모듈형 매니지드 SaaS 중앙집중"]
 ORG --> MESH["Data Mesh 도메인 분산 오너십 데이터 = 제품"]
1. Lambda vs Kappa — 배치와 스트림을 어떻게 엮는가
실시간 분석이 필요해지면 가장 먼저 부딪히는 설계 문제가 있습니다. 배치 처리는 정확하지만 느리고, 스트림 처리는 빠르지만 다루기 까다롭다. 어제까지의 매출은 야간 배치로 정확하게 집계할 수 있지만, “지금 이 순간의 거래량”은 배치로는 얻을 수 없습니다. 반대로 스트림만으로 모든 것을 처리하자니 과거 데이터 전체를 다시 계산(재처리)하거나 복잡한 집계를 정확히 맞추는 일이 부담스럽습니다. Lambda와 Kappa는 이 긴장을 서로 다르게 푼 두 아키텍처입니다.
Lambda 아키텍처 — 두 경로를 병렬로
Nathan Marz가 제안한 Lambda 아키텍처는 “정확성과 속도를 둘 다 갖자”는 발상에서 출발해, 데이터를 두 개의 경로로 동시에 흘려보냅니다.
배치 레이어(Batch Layer): 전체 원본 데이터를 보관하고, 주기적으로 처음부터 다시 계산해 정확한 배치 뷰를 만듭니다. 느리지만 신뢰할 수 있고, 코드 버그가 있어도 재계산으로 바로잡을 수 있습니다.
속도 레이어(Speed Layer): 방금 도착해 배치가 아직 반영하지 못한 데이터만 스트림으로 처리해 실시간 뷰를 만듭니다. 근사치여도 좋으니 지연을 메우는 역할입니다.
서빙 레이어(Serving Layer): 쿼리가 들어오면 배치 뷰(과거)와 실시간 뷰(최근)를 합쳐서 응답합니다.
핵심 아이디어는 “정확한 배치가 따라잡는 동안, 그 빈틈을 속도 레이어가 임시로 메운다”는 것입니다. 배치가 한 바퀴 돌면 속도 레이어가 만든 근사치는 정확한 값으로 덮어쓰여 사라집니다.
Lambda의 대가: 같은 비즈니스 로직을 배치용과 스트림용으로 두 번 구현·유지해야 합니다. 두 코드베이스가 미묘하게 어긋나면 같은 질문에 다른 답이 나오고, 디버깅·테스트·운영 부담이 두 배가 됩니다. 이 “이중 구현”이 Lambda의 가장 큰 비판점입니다.
Kappa 아키텍처 — 스트림 하나로 통일
Jay Kreps(Kafka 창시자)가 제안한 Kappa 아키텍처는 Lambda의 이중 구현을 정면으로 겨냥합니다. 발상은 단순합니다 — 배치 레이어를 없애고, 모든 것을 스트림 처리 하나로 처리하자.
비결은 로그(log)를 진실의 원천으로 삼는 데 있습니다. Kafka 같은 로그에 이벤트를 충분히 길게(또는 영구히) 보관해 두면, “과거 데이터 재처리”는 별도의 배치 시스템이 아니라 같은 스트림 처리 코드를 로그의 처음부터 다시 돌리는 것으로 해결됩니다. 로직을 고치고 싶으면, 새 버전의 스트림 잡을 로그 시작점부터 재생(replay)시켜 새 결과 뷰를 만든 뒤 전환하면 됩니다.
구분
 Lambda
 Kappa
 
경로
 배치 + 속도, 이중
 스트림, 단일
 
코드
 배치용·스트림용 두 벌
 한 벌
 
재처리
 배치 레이어가 처음부터 재계산
 로그를 재생(replay)
 
정확성
 배치가 최종 정답 보장
 스트림 정확성에 의존
 
복잡도
 두 시스템 동기화 부담
 단순하나 로그 보관·스트림 정확성이 관건
 
적합
 무겁고 정확한 배치 집계가 핵심
 실시간이 일급 시민, 로직이 스트림에 적합
 
현실에서는 레이크하우스의 테이블 포맷(Delta·Iceberg·Hudi)이 배치와 스트림을 한 저장소에서 다루게 해 주면서, Lambda의 이중 구현 부담은 점점 줄어드는 추세입니다. 그럼에도 “정확성을 보장하는 무거운 배치가 반드시 필요한가, 아니면 스트림 하나로 충분한가”라는 근본 질문은 여전히 유효하고, 그 답에 따라 Lambda와 Kappa 사이에서 자리를 잡게 됩니다.
2. Medallion 아키텍처 — 품질을 계단처럼 끌어올리기
Lambda/Kappa가 “어떤 경로로 처리할 것인가”의 패턴이라면, Medallion 아키텍처는 “데이터 품질을 어디서 어떻게 끌어올릴 것인가”의 패턴입니다. Databricks가 레이크하우스 위에서의 모범 사례로 대중화한 이 패턴은, 데이터를 한 번에 완성하려 하지 않고 세 개의 계층(layer)을 거치며 한 단씩 정제합니다. 메달 색깔(동·은·금)에서 이름을 따왔습니다.
Bronze — 원본 그대로 (Raw)
원천에서 들어온 데이터를 거의 손대지 않고 그대로 적재하는 계층입니다. 형태 불문, 스키마 강제 없이 일단 받아 두는 것이 핵심입니다. 수집 메타데이터(적재 시각, 원천 식별자 등)만 덧붙입니다. Bronze가 원본을 보존하므로, 하류 로직이 바뀌어도 여기서부터 다시 변환할 수 있습니다. ELT의 “원본 보존” 철학이 그대로 녹아 있습니다.
Silver — 정제·정합 (Cleansed/Conformed)
Bronze의 원본을 정제하고 정합시키는 계층입니다. 타입 정리, 중복 제거, 결측·이상치 처리, 여러 원천의 통합(조인), 공통 키 정합 등이 여기서 일어납니다. Silver는 “신뢰할 수 있는, 분석 가능한 형태”의 데이터로, 데이터 사이언티스트나 엔지니어가 직접 다루기 좋은 계층입니다. 엔터프라이즈 차원의 일관된 뷰가 이 단계에서 만들어집니다.
Gold — 비즈니스용 (Curated)
특정 비즈니스 목적에 맞게 집계·가공된 최종 계층입니다. 부서별 매출 마트, BI 대시보드용 집계 테이블, ML 피처 테이블처럼 바로 소비되는 형태입니다. 스타 스키마 같은 차원 모델이 흔히 이 단계에 자리합니다. Gold는 “누가 봐도 의미가 명확한, 의사결정에 바로 쓰는” 데이터입니다.
이 패턴이 강력한 이유는 단계적 신뢰에 있습니다. 각 계층이 명확한 책임을 가지므로, “이 테이블은 어느 정도 믿어도 되는가”가 계층 이름만으로 드러납니다. 또 각 계층이 입력을 보존하므로 변환을 재현·디버깅하기 쉽고, 문제가 생기면 어느 계층에서 잘못됐는지 추적하기 쉽습니다.
레이크하우스와의 결합이 특히 자연스럽습니다. 세 계층을 모두 값싼 오브젝트 스토리지 위의 테이블 포맷(Delta·Iceberg·Hudi)으로 두면, ACID 트랜잭션·스키마 진화·시간여행의 신뢰성을 누리면서도 레이크의 저비용·유연성을 유지할 수 있습니다. Bronze→Silver→Gold 변환을 dbt나 Spark로 표현하고 오케스트레이터로 묶으면, 앞 글들에서 본 부품들이 하나의 품질 파이프라인으로 정렬됩니다.
💡 계층 수는 절대적이지 않습니다. 작은 조직은 Silver와 Gold를 합치기도 하고, 큰 조직은 Gold 위에 도메인별 마트를 더 두기도 합니다. 핵심은 “품질을 한 번에 완성하지 말고 단계로 나눠 책임을 분리하라”는 원칙입니다.
3. Modern Data Stack & Data Mesh — 시스템과 조직을 어떻게 구성하는가
마지막 축은 처리나 품질이 아니라 시스템 전체와 조직을 어떻게 구성하는가입니다. 여기서 두 흐름이 대비됩니다. 하나는 좋은 매니지드 서비스를 조립하는 기술적 구성(Modern Data Stack)이고, 다른 하나는 데이터의 소유권 자체를 재배치하는 조직적 구성(Data Mesh)입니다.
Modern Data Stack — 매니지드 SaaS의 조립
Modern Data Stack(MDS)은 2단계 글에서 본 것처럼, 클라우드 데이터 웨어하우스를 중심에 두고 모듈형 매니지드 SaaS를 레고처럼 조립하는 구성입니다. 직접 인프라를 구축하는 대신, 각 계층마다 잘 만들어진 전문 서비스를 골라 끼웁니다.
수집: Fivetran·Airbyte 같은 매니지드 커넥터
저장·연산: Snowflake·BigQuery·Redshift 같은 클라우드 DW(또는 레이크하우스)
변환: dbt — SQL 기반 변환을 모델·테스트·문서와 함께 관리
서빙: Looker·Tableau 등 BI, 그리고 역 ETL
MDS의 강점은 낮은 진입 장벽과 빠른 구축입니다. 작은 팀도 SQL만 잘 다루면 견고한 분석 스택을 며칠 안에 세울 수 있습니다. 다만 데이터의 소유권과 책임은 여전히 중앙의 데이터 팀에 모입니다. 이 중앙집중이 조직이 커질수록 병목이 됩니다 — 모든 도메인의 데이터 요청이 한 팀의 백로그로 몰리기 때문입니다.
Data Mesh — 도메인 중심 분산 오너십
Data Mesh는 Zhamak Dehghani가 제안한, 기술보다 조직과 책임 구조에 관한 패턴입니다. 출발점은 중앙집중 데이터 팀의 한계입니다. 회사가 커지면 중앙 팀은 모든 도메인의 맥락을 알 수도 없고, 모든 요청을 처리할 수도 없어 거대한 병목이 됩니다. Data Mesh의 답은 마이크로서비스가 백엔드에 했던 일을 데이터에 하는 것입니다 — 데이터의 소유권을 그 데이터를 가장 잘 아는 도메인 팀에 분산하는 것. 이를 떠받치는 네 가지 원칙이 있습니다.
도메인 오너십(Domain Ownership): 데이터의 소유와 책임을 중앙 팀이 아니라 각 도메인 팀(주문·결제·물류 등)에 둡니다. 그 데이터를 만들고 가장 잘 아는 사람이 책임집니다.
데이터 as a 프로덕트(Data as a Product): 도메인이 내놓는 데이터를 내부 부산물이 아니라 하나의 제품으로 다룹니다. 소비자가 발견·이해·신뢰하기 쉽도록 문서·SLA·품질 보증을 갖춥니다. “소비자가 있는 제품”이라는 관점이 핵심입니다.
셀프서비스 데이터 플랫폼(Self-serve Platform): 모든 도메인이 데이터 제품을 만들 때 인프라를 매번 새로 짜지 않도록, 공유 플랫폼이 저장·파이프라인·카탈로그·관측 같은 공통 기능을 셀프서비스로 제공합니다. 도메인은 인프라가 아닌 도메인 로직에 집중합니다.
연합 거버넌스(Federated Computational Governance): 분산이 무정부가 되지 않도록, 도메인 대표들이 모여 공통 표준(상호운용 규칙, 보안, 품질 기준)을 정하고 이를 가능한 한 플랫폼에 자동화해 강제합니다. 자율과 일관성의 균형입니다.
Data Mesh는 만능이 아닙니다. 분산은 자율과 확장성을 주지만, 도메인마다 데이터 엔지니어링 역량을 갖춰야 하고 거버넌스를 잘못 잡으면 사일로(silo)와 중복이 늘 수 있습니다. 그래서 Data Mesh는 도메인 수가 많고 중앙 팀이 명백한 병목인 충분히 큰 조직에서 빛납니다. 작은 조직에는 중앙집중형 MDS가 거의 항상 더 단순하고 효율적입니다.
MDS와 Data Mesh는 대립한다기보다 조직 규모의 다른 지점에 놓입니다. 많은 조직이 중앙집중형 MDS로 시작해, 도메인이 늘고 중앙 팀이 병목이 될 때 비로소 Data Mesh의 분산 원칙을 부분적으로 도입합니다. 1단계 글에서 본 데이터 성숙도가 다시 등장하는 셈입니다 — 조직의 성숙도와 규모에 맞는 구성이 정답입니다.
정리
데이터 아키텍처 패턴은 외워야 할 정답표가 아니라, 각기 다른 축의 트레이드오프를 정리한 사고의 도구입니다. 이 글에서 본 네 패턴을 한 줄씩 요약하면 다음과 같습니다.
Lambda vs Kappa: 배치+속도의 이중 경로(정확하지만 코드 두 벌)냐, 스트림 단일 경로(단순하지만 스트림 정확성·로그 보관에 의존)냐. 무거운 배치가 꼭 필요한지가 갈림길.
Medallion: 품질을 한 번에 완성하지 말고 Bronze→Silver→Gold로 단계적으로 끌어올려 책임을 분리하라. 레이크하우스와 결합하면 자연스럽다.
Modern Data Stack: 매니지드 SaaS를 레고처럼 조립하는 중앙집중 구성 — 빠르고 쉽지만 중앙 팀이 병목이 될 수 있다.
Data Mesh: 데이터 소유권을 도메인에 분산하고 데이터를 제품으로 다루며, 셀프서비스 플랫폼과 연합 거버넌스로 묶는다 — 충분히 큰 조직에서 빛난다.
관통하는 두 교훈이 있습니다. 첫째, 모든 패턴은 무언가를 풀고 그 대가로 무언가를 포기한다 — Lambda는 정확성을 위해 복잡도를, Kappa는 단순함을 위해 스트림 정확성을, Data Mesh는 확장성을 위해 거버넌스 부담을 치릅니다. 둘째, 올바른 패턴은 조직의 규모·성숙도·요구에 달려 있다 — 화려한 패턴을 따라가기 전에 “우리의 지연·규모·조직 요구가 무엇인가”를 먼저 물어야 합니다. 다음 글에서는 이 패턴들을 실제 시나리오에 적용해, 사례별로 파이프라인을 어떻게 설계하는지 살펴봅니다.
다음 학습 (Next Learning)
Data Engineering Essential Curriculum — 전체 로드맵으로 돌아가 진행 상황 확인하기
오케스트레이션(Orchestration): DAG·스케줄링과 견고한 파이프라인 — 6단계: 패턴을 떠받치는 실행 조율의 두뇌 복습
사례별 파이프라인 설계: 실시간 분석·이벤트·ML 피처·CDC — 8단계: 이 패턴들을 실제 시나리오에 적용하기

데이터 아키텍처 패턴: Lambda·Kappa·Medallion·Data Mesh

댓글