1 이 포스트의 목적
Reis Ch.3 §3.5는 데이터 아키텍처의 주요 유형을 사례로 제시하고, §3.6은 결론과 추가 리소스를 정리한다. 추상적인 원칙과 개념이 실제로 어떤 형태를 취하는가를 이해하는 것이 이 포스트의 목표이다. 각 아키텍처 패턴이 어떤 문제를 해결하려 했고, 어떤 트레이드오프를 수반하며, 현재 어떤 위치에 있는지를 비교한다.
2 데이터 웨어하우스
데이터 웨어하우스는 리포팅과 분석에 사용되는 중앙 데이터 허브이다. 데이터는 분석 유스케이스를 위해 고도로 포맷되고 구조화된다. 가장 오래되고 가장 확고한 데이터 아키텍처 중 하나이다. (Reis, 2022, Ch.3)
Bill Inmon이 1989년에 데이터 웨어하우스를 “경영 의사결정을 지원하기 위한, 주제 지향적(subject-oriented)·통합적(integrated)·비휘발성(nonvolatile)·시변적(time-variant) 데이터 컬렉션”으로 정의했다. 기술적 측면은 크게 발전했지만, 이 원래 정의는 여전히 유효하다.
2.1 조직적 아키텍처 vs 기술적 아키텍처
데이터 웨어하우스 아키텍처에는 두 가지 유형이 있다.
| 유형 | 초점 | 예시 |
|---|---|---|
| 조직적 DW 아키텍처 | 비즈니스 팀 구조와 프로세스에 연관된 데이터 조직 | 영업 데이터 마트, 재무 데이터 마트 |
| 기술적 DW 아키텍처 | DW의 기술적 특성 (MPP 등) | 컬럼나 스토리지, 분산 쿼리 처리 |
조직적 DW 아키텍처의 두 가지 핵심 특성:
첫째, OLAP과 프로덕션 DB(OLTP)의 분리이다. 이 분리는 비즈니스 성장에 따라 필수적이다. 데이터를 별도의 물리적 시스템으로 이동시키면 프로덕션 시스템에서 부하를 제거하고 분석 성능을 향상시킨다.
둘째, 데이터의 중앙화와 조직화이다. 전통적으로 DW는 ETL을 사용하여 애플리케이션 시스템에서 데이터를 가져온다. 추출 단계에서 소스 시스템의 데이터를 가져오고, 변환 단계에서 데이터를 정제·표준화하고, 적재 단계에서 DW 대상 DB에 데이터를 넣는다.
2.2 ETL vs ELT
| 패턴 | 변환 위치 | 장점 | 적합한 상황 |
|---|---|---|---|
| ETL | 외부 시스템에서 변환 후 적재 | 정제된 데이터만 DW에 들어감 | 전통적 DW, 데이터 품질 엄격 관리 |
| ELT | 원본을 먼저 적재, DW 내에서 변환 | 클라우드 DW의 대규모 연산 능력 활용 | 클라우드 DW, 스트리밍 CDC |
ELT의 부상은 클라우드 데이터 웨어하우스의 대규모 연산 능력 덕분이다. 원본 데이터를 스테이징 영역에 먼저 적재하고, DW 내에서 변환을 처리한다. 배치와 스트리밍 모두에서 ELT 패턴이 사용된다.
2.3 클라우드 데이터 웨어하우스
Amazon Redshift가 클라우드 DW 혁명을 시작했다. 수년간의 용량을 미리 예측하고 수백만 달러 계약을 맺는 대신, 주문형(on-demand)으로 클러스터를 가동하고 필요에 따라 확장할 수 있게 되었다.
Google BigQuery, Snowflake 등이 연산과 스토리지의 분리(separation of compute and storage)를 대중화했다. 데이터는 오브젝트 스토리지에 저장되어 사실상 무제한 스토리지가 가능하고, 연산 능력은 주문형으로 가동하여 ad hoc 빅데이터 처리가 가능하다.
클라우드 DW가 가져온 변화는 너무 커서, “데이터 웨어하우스”라는 용어 자체를 폐기하고 데이터 플랫폼으로 부르는 것이 적절할 수 있다. 전통적 MPP 시스템보다 훨씬 넓은 범위의 기능을 제공하며, 페타바이트 규모 데이터를 단일 쿼리로 처리하고, 행당 수십 MB의 원문 데이터나 복잡한 JSON 문서를 저장할 수 있다.
2.4 데이터 마트
데이터 마트는 단일 하위 조직·부서·사업 라인에 초점을 맞춘 DW의 정제된 하위 집합이다. 전체 조직을 서빙하는 DW와 달리, 각 부서가 자체 필요에 맞는 데이터 마트를 가진다.
데이터 마트의 존재 이유: (1) 분석가와 리포트 개발자에게 데이터 접근을 용이하게 한다. (2) 초기 ETL/ELT 파이프라인 이후 추가적인 변환 단계를 제공하여, 복잡한 조인과 집계가 필요한 리포트/분석 쿼리의 성능을 크게 개선한다.
3 데이터 레이크
데이터 레이크는 구조화·비구조화 데이터를 모두 중앙 위치에 원본 그대로 저장하는 아키텍처이다. 데이터를 민주화하는 힘이 될 것이라 약속했지만, 1세대 데이터 레이크(“데이터 레이크 1.0”)는 그 약속을 대체로 이행하지 못했다.
3.1 데이터 레이크 1.0: 약속과 실패
데이터 레이크 1.0은 HDFS에서 시작하여 클라우드 오브젝트 스토리지로 이동했다. 이론적으로는 매력적이다: 모놀리식 DW의 밀결합된 스토리지와 연산 대신, 어떤 크기와 유형의 데이터든 저장하고, 필요할 때 주문형 클러스터를 가동하여 원하는 처리 기술(MapReduce, Spark, Ray, Presto, Hive 등)로 쿼리한다.
하지만 현실의 문제가 심각했다.
| 문제 영역 | 구체적 문제 |
|---|---|
| 데이터 관리 | 스키마 관리, 데이터 카탈로깅, 검색 도구 부재 → “데이터 늪(data swamp)” |
| 데이터 품질 | 쓰기 전용(write-only) 특성, GDPR 등 규정에 따른 대상 삭제 불가 |
| 처리 복잡성 | 단순한 조인도 MapReduce 코드로 작성해야 하는 고통 |
| DML 부재 | SQL의 DELETE/UPDATE 같은 기본 조작이 극히 어려움 (전체 테이블 재생성) |
| 비용 | 오픈소스가 비용 절감을 약속했지만, Hadoop 클러스터 관리에 대규모 인력 필요 |
데이터 레이크 1.0의 역설: 대형 기술 기업(Netflix, Facebook)은 커스텀 Hadoop 기반 도구를 구축할 자원이 있어 데이터 레이크에서 큰 가치를 찾았다. 하지만 대다수 조직에게 데이터 레이크는 “폐기물, 실망, 급증하는 비용의 내부 수퍼펀드 사이트”가 되었다. 도구의 문제가 아니라 자원과 역량의 문제였다.
4 수렴: 레이크하우스와 데이터 플랫폼
1세대 데이터 레이크의 한계에 대응하여 다양한 시도가 이루어졌다.
4.1 데이터 레이크하우스
Databricks가 도입한 데이터 레이크하우스(data lakehouse)는 DW의 제어·데이터 관리·데이터 구조를 데이터 레이크에 통합한다. 특히 ACID 트랜잭션을 지원하는 것이 원래 데이터 레이크(데이터를 부어 넣고 업데이트/삭제하지 않는)와의 큰 차이이다. “데이터 레이크하우스”라는 용어 자체가 데이터 레이크와 데이터 웨어하우스의 수렴(convergence)을 시사한다.
클라우드 DW의 기술 아키텍처도 데이터 레이크와 매우 유사하게 진화했다. 연산과 스토리지를 분리하고, 페타바이트 규모 쿼리를 지원하며, 비구조화·반구조화 데이터를 저장하고, Spark/Beam 같은 고급 처리 기술과 통합한다.
| 비교 축 | 데이터 웨어하우스 | 데이터 레이크 | 데이터 레이크하우스 |
|---|---|---|---|
| 스토리지 | 전용 MPP | 오브젝트 스토리지 | 오브젝트 스토리지 + 테이블 포맷 |
| 데이터 구조 | 고도로 구조화 | 원본 그대로 | 구조화 + 비구조화 |
| ACID 트랜잭션 | 지원 | 미지원 | 지원 |
| 스키마 관리 | 강제 | 부재 | 선택적 강제 |
| 비용 모델 | 연산+스토리지 묶음 → 분리 | 저비용 스토리지 + 주문형 연산 | 저비용 스토리지 + 주문형 연산 |
Reis는 수렴 추세가 계속될 것으로 예측한다. 데이터 레이크와 DW는 별도의 아키텍처로 존재하지만, 실무에서 그 경계를 인지하는 사용자는 점점 줄어들 것이다. AWS, Azure, Google Cloud, Snowflake, Databricks 같은 벤더가 레이크와 DW 기능을 통합한 데이터 플랫폼을 제공하고 있다.
5 모던 데이터 스택
모던 데이터 스택은 클라우드 기반의 플러그앤플레이, 사용하기 쉬운, 기성품 컴포넌트를 사용하여 모듈화되고 비용 효율적인 데이터 아키텍처를 구성하는 분석 아키텍처이다.
핵심 컴포넌트: 데이터 파이프라인, 스토리지, 변환, 데이터 관리/거버넌스, 모니터링, 시각화, 탐색.
과거의 비싸고 모놀리식한 도구셋과 대비되는 주요 성과:
- 셀프 서비스: 분석과 파이프라인
- 애자일 데이터 관리: 빠른 반복
- 명확한 가격 구조: 오픈소스 또는 투명한 가격의 프로프라이어터리 도구
- 커뮤니티 중심: 사용자가 기능 제안, PR 제출 등에 참여
교재의 핵심 판단: 플러그앤플레이 모듈화와 명확한 가격·구현이 미래의 방향이다. 분석 엔지니어링에서 모던 데이터 스택은 데이터 아키텍처의 기본 선택이 되었고, 계속 그럴 것이다.
6 Lambda 아키텍처
2010년대 초중반, Kafka가 대규모 메시지 큐로, Apache Storm과 Samza가 스트리밍/실시간 분석 프레임워크로 등장하면서 배치와 스트리밍 데이터를 하나의 아키텍처로 조화시키는 과제가 부상했다. Lambda 아키텍처는 이에 대한 초기 대응이다.
소스 시스템 (불변, append-only)
├── Speed Layer (스트리밍) → NoSQL DB (최저 지연)
├── Batch Layer (배치) → DW (사전 계산된 집계 뷰)
└── Serving Layer → 두 레이어의 쿼리 결과 통합Lambda 아키텍처의 문제: 서로 다른 코드베이스를 가진 여러 시스템을 관리하는 것은 매우 어렵다. 오류 발생이 쉽고, 코드와 데이터를 조화시키기 극히 어렵다.
교재는 Lambda 아키텍처가 여전히 검색 엔진 결과에서 인기 있지만, 배치와 스트리밍 데이터를 결합하려는 경우 첫 번째 권장 사항은 아니라고 명시한다.
7 Kappa 아키텍처
Jay Kreps가 2014년에 Lambda의 한계에 대한 대안으로 제안했다. 핵심 논지: 스트림 처리 플랫폼을 모든 데이터 처리 — 수집, 저장, 서빙 — 의 백본으로 사용하면 어떨까?
실시간과 배치 처리를 동일한 데이터에 원활하게 적용할 수 있다. 라이브 이벤트 스트림을 직접 읽어 실시간 처리하고, 대규모 데이터 청크를 재생(replay)하여 배치 처리한다.
하지만 Kappa 아키텍처는 원래 기사 발표(2014년) 이후에도 널리 채택되지 않았다. 이유는 두 가지이다: (1) 스트리밍 자체가 많은 기업에게 여전히 어렵다. (2) 실무에서 Kappa는 복잡하고 비싸다. 스트리밍 시스템이 대규모 데이터 볼륨으로 확장 가능하지만, 배치 스토리지와 처리가 방대한 히스토리 데이터셋에 훨씬 효율적이고 비용 효과적이다.
8 Dataflow 모델: 배치와 스트리밍의 통합
Lambda와 Kappa 모두 2010년대 Hadoop 생태계의 한계를 극복하려는 시도였지만, 자연스럽게 맞지 않는 도구들을 억지로 결합한 면이 있다. 배치와 스트리밍의 통합이라는 핵심 과제는 남아 있었다.
Google이 Dataflow 모델을 개발하고 이를 구현한 Apache Beam 프레임워크를 공개했다.
핵심 아이디어: 모든 데이터를 이벤트로 본다. 집계는 다양한 유형의 윈도우 위에서 수행된다.
| 개념 | 설명 |
|---|---|
| 비유한 데이터 (Unbounded data) | 지속적인 실시간 이벤트 스트림 |
| 유한 데이터 (Bounded data) | 배치 = 경계가 있는 이벤트 스트림, 경계가 자연스러운 윈도우를 제공 |
| 윈도우 | 슬라이딩, 텀블링 등 실시간 집계를 위한 시간 프레임 |
“배치는 스트리밍의 특수 케이스”라는 철학이 이제 더 넓게 퍼져 있다. Flink, Spark 등 다양한 프레임워크가 유사한 접근법을 채택했다.
9 IoT 아키텍처
IoT(Internet of Things)는 인터넷에 연결된 디바이스의 분산 컬렉션이다. 직접적인 인간 입력이 아니라 환경에서 데이터를 수집하여 전송하는 디바이스가 데이터를 생성한다. 스마트폰 혁명이 거대한 IoT 스웜을 하룻밤 사이에 만들어냈다.
IoT 아키텍처의 핵심 컴포넌트:
| 컴포넌트 | 역할 | 고려사항 |
|---|---|---|
| 디바이스 | 환경 데이터 수집·전송 | 에지 컴퓨팅/ML, 전송 빈도, 장애 영향 |
| IoT 게이트웨이 | 디바이스를 인터넷 목적지로 라우팅하는 허브 | 저전력 연결, 데이터 보존 |
| 수집 | 게이트웨이에서 이벤트 수집 아키텍처로 흐름 | 늦게 도착하는 데이터, 스키마 불일치, 연결 중단 |
| 저장 | 레이턴시 요구에 따라 결정 | 배치 → 오브젝트 스토리지, 실시간 → 메시지 큐/시계열 DB |
| 서빙 | 분석·알림·디바이스 재구성 | 역방향 ETL 패턴: 분석 결과를 디바이스에 피드백 |
IoT 서빙의 특징적 패턴은 역방향 ETL과 유사한 피드백 루프이다. 제조 장비의 센서 데이터를 분석하여 최적화 결과를 디바이스에 전송하여 재구성한다.
10 데이터 메시
데이터 메시는 중앙화된 데이터 레이크와 DW 같은 모놀리식 데이터 플랫폼과 “데이터의 대분단(운영 데이터 vs 분석 데이터)”에 대한 최근의 대응이다. 도메인 주도 설계(DDD)의 개념을 소프트웨어 아키텍처에서 데이터 아키텍처로 가져온다. (Reis, 2022, Ch.3)
Zhamak Dehghani가 식별한 데이터 메시의 4대 구성 요소:
| 구성 요소 | 의미 |
|---|---|
| 도메인 지향 분산 데이터 소유 | 중앙 데이터 팀 대신 각 도메인이 자체 데이터를 소유·제공 |
| 데이터를 제품으로 | 데이터셋을 내부 제품처럼 품질 관리·문서화·서빙 |
| 셀프 서비스 데이터 인프라 플랫폼 | 각 도메인 팀이 자율적으로 데이터를 발행할 수 있는 플랫폼 |
| 연합 연산 거버넌스 | 글로벌 표준과 도메인 자율성의 균형 |
데이터 메시의 핵심 아이디어: 데이터를 도메인에서 중앙 소유 레이크/플랫폼으로 흘려보내는 대신, 도메인이 자체 데이터셋을 호스팅하고 쉽게 소비 가능한 형태로 서빙한다.
11 아키텍처 유형 비교 요약
| 아키텍처 | 등장 시기 | 핵심 문제 해결 | 주요 트레이드오프 | 현재 상태 |
|---|---|---|---|---|
| DW | 1980s | OLTP/OLAP 분리, 구조화된 분석 | 비용, 유연성 제한 | 클라우드 DW로 재탄생 |
| 데이터 레이크 | 2010s | 모든 유형의 데이터를 저비용 저장 | 관리 부재 → 데이터 늪 | 2.0으로 진화 |
| 레이크하우스 | 2020s | 레이크 + DW 장점 통합 | 새로운 테이블 포맷 학습 곡선 | 수렴 추세의 최전선 |
| 모던 데이터 스택 | 2020s | 모듈화, 셀프 서비스, 투명 비용 | 도구 파편화 가능성 | 분석 엔지니어링 기본 선택 |
| Lambda | 2010s | 배치 + 스트리밍 병렬 처리 | 이중 코드베이스 관리 | 레거시, 권장하지 않음 |
| Kappa | 2014 | 스트리밍 단일 백본 | 복잡하고 비쌈 | 아이디어 유효, 채택 제한 |
| Dataflow | 2015+ | 배치 = 유한 스트림으로 통합 | 프레임워크 학습 곡선 | Beam/Flink/Spark 채택 |
| 데이터 메시 | 2019 | 도메인별 분산 소유 | 조직적 변화 필요 | 주목받으나 실행 어려움 |
12 누가 아키텍처를 설계하는가
큰 기업은 여전히 데이터 아키텍트를 고용하지만, 그 아키텍트는 기술과 데이터의 현재 상태에 깊이 정통해야 한다. 상아탑 데이터 아키텍처의 시대는 끝났다. 과거에 아키텍처는 엔지니어링과 대체로 직교(orthogonal)했지만, 엔지니어링이 더 민첩해지면서 이 구분은 사라질 것이다.
소규모 기업이나 데이터 성숙도가 낮은 기업에서는 데이터 엔지니어가 아키텍트 역할을 겸한다. 데이터 아키텍처가 수명주기의 저류이므로, 데이터 엔지니어는 “좋은” 아키텍처와 다양한 유형의 데이터 아키텍처를 이해해야 한다.
13 핵심 요약
Ch.3 전체의 결론적 메시지는 다음과 같다.
첫째, 아키텍처 유형은 상호 배타적이지 않다. 실무에서는 하이브리드가 표준이다. 레이크하우스 위에 모던 데이터 스택을 구축하고, 일부 도메인에 데이터 메시 원칙을 적용하는 것이 일반적이다.
둘째, 모든 아키텍처 선택은 트레이드오프이다. “최고의 아키텍처”는 없다. “이 조직의 현재 상황에서 가장 덜 나쁜 아키텍처”가 있을 뿐이다.
셋째, 아키텍처는 기술적 행위이면서 동시에 조직적 행위이다. 데이터 메시가 보여주듯, 아키텍처 변경은 종종 팀 구조와 소유권의 변경을 수반한다.
14 참고 문헌
- Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.3 §3.5-3.6.
- Inmon, H. W. (2005). Building the Data Warehouse. Wiley.
- Dehghani, Z. (2022). Data Mesh. O’Reilly.
- Kreps, J. (2014). “Questioning the Lambda Architecture.” O’Reilly Radar.
- Kleppmann, M. (2017). Designing Data-Intensive Applications. O’Reilly.