서빙 레이어 설계 — Materialized View, 사전 집계 테이블, Event Sourcing
40 Data Engineering System Design Interview Questions (2026) — DataVidhya (blog) Q13. Materialized view vs pre-computed aggregate table (pp.7-8); Q10. Event Sourcing vs state-based storage (pp.6-7)
이 모듈을 다 읽으면
- Materialized View와 파이프라인이 관리하는 사전 집계 테이블을 언제 각각 선택해야 하는지 설명할 수 있다
- Event Sourcing이 상태 기반 저장 방식과 어떻게 다르며 그 복잡성 비용이 정당화되는 상황을 판별할 수 있다
서빙 레이어에서 자동 갱신되는 Materialized View는 단순한 GROUP BY/필터 변환에 적합하고, 파이프라인이 명시적으로 관리하는 사전 집계 테이블은 복잡한 다중 소스 조인이나 버전 관리가 필요할 때 적합하다. 한편 현재 상태만 저장하는 대신 모든 변경 이벤트를 저장하는 Event Sourcing은 완전한 감사 추적과 임의 시점 상태 재구성을 제공하지만, 그 복잡성 비용은 회계·협업 편집·시간여행이 제품 요구사항인 경우에만 정당화된다.
Materialized View vs 사전 집계 테이블
Materialized View는 데이터베이스가 관리한다 — 기반 데이터가 바뀌면 엔진이 자동으로(또는 스케줄에 따라) 갱신한다. 사전 집계 테이블은 파이프라인이 관리한다 — Spark나 dbt 잡이 명시적으로 테이블을 써서 만든다. 데이터베이스가 증분 갱신을 지원하고 변환이 단순(GROUP BY, 필터 정도)할 때는 Materialized View를 쓰고, 변환이 복잡(다중 소스 조인, ML 피처 계산)하거나 여러 데이터베이스 간 이식성이 필요하거나 파이프라인 코드에서 명시적인 버전 관리와 테스트를 원할 때는 사전 집계 테이블을 쓴다.
Materialized View의 대표적 실패 모드는 갱신 폭풍(refresh storm)이다 — 같은 기반 테이블에 50개의 뷰가 의존하고 있다면, 그 테이블에 대한 적재 한 번이 50개의 동시 재구축을 촉발해 웨어하우스 컴퓨트를 포화시킬 수 있다.
핵심 포인트
- Materialized View=DB가 자동/스케줄 갱신, 단순 변환(GROUP BY/필터)에 적합. 사전 집계 테이블=파이프라인이 명시적 관리, 복잡한 다중 소스 조인·ML 피처·버전 관리가 필요할 때 적합.
- Materialized View의 대표 실패 모드는 갱신 폭풍 — 하나의 기반 테이블 변경이 다수의 의존 뷰를 동시에 재구축시켜 컴퓨트를 포화시킨다.
Event Sourcing — 상태 대신 사건을 저장한다
전통적인 시스템은 현재 상태를 저장한다 — '사용자 잔액 = 500달러' 식이다. Event Sourcing에서는 상태를 변화시키는 모든 사건을 저장한다 — '입금 200달러, 출금 50달러, 입금 350달러'처럼. 현재 상태는 모든 이벤트를 재생(replay)해서 도출한다. 이는 완전한 감사 추적, 임의 시점의 상태 재구성 능력, 스트리밍 아키텍처와의 자연스러운 호환성을 제공한다.
복잡성 비용도 실재한다 — 읽기 쿼리는 이벤트 로그로부터 뷰를 구체화(materialize)해야 하고, 스냅샷팅을 구현하지 않으면 스토리지가 무한정 늘어나며, 수백만 개의 과거 이벤트에 걸친 스키마 진화 처리가 까다롭다. Event Sourcing은 감사 가능성이 법적으로 요구되는 금융 시스템, 충돌 해결에 전체 이력이 필요한 협업 편집, '되돌리기'나 '시간여행'이 제품 기능 자체인 시스템에서 그 복잡성 비용을 감수할 가치가 있다. 반면 표준적인 이커머스 상품 카탈로그 같은 경우에는 단순한 CRUD 데이터베이스가 올바른 기본 선택이다.
핵심 포인트
- Event Sourcing=현재 상태 대신 모든 변경 이벤트를 저장하고, 현재 상태는 이벤트 재생으로 도출 — 완전한 감사 추적, 임의 시점 재구성, 스트리밍과의 자연스러운 결합을 제공한다.
- 복잡성 비용(읽기 시 뷰 구체화 필요, 스냅샷 없이는 무한 성장하는 스토리지, 까다로운 스키마 진화)은 금융 시스템·협업 편집·시간여행이 제품 요구사항인 경우에만 감수할 가치가 있다 — 일반 CRUD 상황에서는 단순 DB가 기본값이다.