데이터 플랫폼 큰 그림
이 세션의 목표
데이터 플랫폼 용어는 처음 들으면 전부 비슷하게 들린다. Data Lake, Data Warehouse, Data Mart, Lakehouse, Medallion Architecture가 모두 “데이터를 모아두는 곳”처럼 보이기 때문이다. 하지만 DBA나 DB 플랫폼 엔지니어 입장에서는 질문을 다르게 잡아야 한다.
이 데이터는 왜 저장하는가, 언제 가공하는가, 누가 소비하는가, 장애가 나면 어디서 다시 시작하는가.
이 네 가지 질문으로 보면 용어가 훨씬 쉽게 정리된다.
데이터 플랫폼을 한 문장으로 보기
데이터 플랫폼은 여러 시스템에서 나온 데이터를 모아, 정리하고, 검증하고, 다시 사용할 수 있게 만드는 운영 체계다.
서비스 DB는 주문, 결제, 회원 같은 현재 상태를 안전하게 처리하는 데 집중한다. 데이터 플랫폼은 그 서비스 DB와 로그, 파일, 외부 API, 이벤트 스트림에서 나온 데이터를 가져와 분석, 리포트, ML, 고객사 배포, 감사 추적에 쓸 수 있게 만든다.
운영 DB · 로그 · 파일 · API → Ingestion
batch · streaming · CDC → Storage
lake · warehouse · lakehouse → Transform
clean · join · aggregate → Serving
BI · mart · API · ML
DBA가 특히 봐야 하는 지점
DBA는 단순히 “저장소가 뭐냐”보다 데이터가 이동하면서 생기는 운영 리스크를 봐야 한다.
| 질문 | DBA 관점의 의미 |
|---|---|
| 원본은 어디인가 | 장애 복구, 재처리, 감사 기준이 되는 source of truth 확인 |
| 언제 변환하는가 | schema-on-write인지 schema-on-read인지, 실패 시 어느 단계부터 재시작할지 결정 |
| 누가 읽는가 | BI, 데이터 과학자, 서비스 API, 고객사 배포 등 소비자별 SLA 차이 이해 |
| 얼마나 오래 보관하는가 | 비용, 개인정보, 백업, retention, purge 정책과 연결 |
| 품질은 어디서 보장하는가 | NOT NULL, FK 같은 DB 제약만으로 충분한지, 별도 data quality gate가 필요한지 판단 |
핵심 용어 한 번에 보기
| 용어 | 아주 짧은 정의 | 비유 |
|---|---|---|
| OLTP | 서비스 트랜잭션을 빠르고 안전하게 처리하는 DB | 계산대 |
| OLAP | 대량 데이터를 집계·분석하는 시스템 | 분석실 |
| Data Lake | 원본에 가까운 데이터를 대량 저장하는 공간 | 창고 |
| Data Warehouse | 정리된 분석용 데이터를 SQL로 빠르게 조회하는 공간 | 회계 장부 |
| Data Mart | 특정 팀/업무를 위한 작은 분석 데이터셋 | 부서별 보고서 폴더 |
| Lakehouse | Lake 위에 Warehouse식 관리 기능을 얹은 구조 | 창고에 재고 관리 시스템을 붙인 형태 |
| Medallion Architecture | Bronze → Silver → Gold로 데이터 품질을 단계적으로 높이는 패턴 | 원재료 → 손질 → 완제품 |
| ETL/ELT | 데이터를 추출·적재·변환하는 방식 | 택배 입고와 포장 방식 |
| CDC | DB 변경분을 로그 기반으로 전달하는 방식 | 변경 내역 장부 구독 |
| Data Catalog | 데이터셋의 위치, 의미, 소유자, 품질 정보를 찾는 목록 | 도서관 catalog |
| Lineage | 데이터가 어디서 와서 어디로 갔는지의 흐름 | 생산 이력 추적 |
흔한 오해
오해 1. Data Lake가 있으면 Warehouse는 필요 없다
Lake는 원본과 다양한 형식을 싸게 저장하는 데 강하다. Warehouse는 정리된 데이터를 반복적으로 빠르게 조회하고 BI 사용자에게 안정된 스키마를 제공하는 데 강하다. 둘은 대체 관계라기보다 역할이 다르다.
오해 2. Gold가 항상 Data Mart다
Medallion의 Gold는 비즈니스 소비에 가까운 refined layer다. Data Mart는 특정 부서나 use case를 위한 serving dataset이다. Gold 테이블이 Mart로 쓰일 수는 있지만, 둘은 같은 말이 아니다.
오해 3. DBA는 Data Lake를 몰라도 된다
현대 데이터 플랫폼에서는 운영 DB의 binlog, snapshot, backup, schema drift, retention, 개인정보 삭제 요청이 Lake/Warehouse까지 이어진다. DBA가 원본 DB만 보면 downstream 장애 원인을 놓치기 쉽다.
오늘의 체크 질문
- 우리 회사의 source of truth는 운영 DB인가, lake의 raw layer인가, warehouse의 curated table인가?
- 장애가 나면 재처리는 source system부터 하는가, raw layer부터 하는가?
- 분석 쿼리가 운영 DB를 직접 때리고 있지는 않은가?
- “정리된 데이터”의 기준은 DB 제약조건인가, pipeline 검증인가, 비즈니스 룰인가?
세션 과제
현재 운영 중인 데이터 흐름 하나를 골라 다음 표를 채워보자.
| 항목 | 답 |
|---|---|
| Source system | |
| 수집 방식 | batch / streaming / CDC / manual |
| 원본 보관 위치 | |
| 변환 위치 | DB / Spark / Airflow / dbt / application |
| 최종 소비자 | BI / API / 고객사 / ML / 내부 운영 |
| 장애 시 재처리 시작점 |
References
- https://www.ibm.com/think/topics/data-warehouse
- https://www.databricks.com/glossary/data-lakehouse
- https://www.databricks.com/glossary/medallion-architecture
- https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture