데이터 웨어하우스 · 레이크
Data Warehouse / Data Lake
데이터 웨어하우스란?
- 웨어하우스=정리된 분석용 창고
- 레이크=원본 그대로 담는 호수
- 목적에 따라 선택
저장소를 고르는 일은 사실 데이터를 언제 정리할 것인가를 정하는 일입니다. 웨어하우스는 집어넣기 전에 표 구조를 맞춰야 하고, 레이크는 일단 부어 넣고 꺼낼 때 해석합니다. 그래서 현업이 '이 지표 하나만 더 봐 주세요'라고 할 때 반응 속도가 갈립니다. 웨어하우스는 모델을 손보고 다시 적재하느라 2~3주가 걸리는 대신 숫자가 흔들리지 않고, 레이크는 오늘 당장 열어볼 수 있지만 그 숫자를 누가 보증하느냐를 매번 다시 묻게 됩니다.
둘을 가르는 실무 기준은 세 가지입니다. 첫째는 형태로, 주문·회계처럼 행과 열이 정해진 자료는 웨어하우스, 앱 로그·상담 녹취·이미지처럼 제각각인 자료는 레이크에 맞습니다. 둘째는 비용으로, 원본을 쌓아만 두는 객체 스토리지와 분석 엔진까지 포함된 웨어하우스는 1TB 보관 단가의 자릿수 자체가 다릅니다. 셋째는 순서로, 정제한 뒤 적재(ETL)하느냐 적재한 뒤 정제(ELT)하느냐입니다. 레이크하우스는 레이크의 저장 방식 위에 표 형식과 트랜잭션을 얹어 이 경계를 좁힌 구조이고, 데이터 마트는 웨어하우스에서 특정 부서용으로 잘라낸 하위 집합이라 별개의 선택지가 아닙니다.
현장에서 가장 자주 무너지는 지점은 '일단 다 담아두면 언젠가 쓴다'는 믿음입니다. 카탈로그도 담당자도 없이 3년을 쌓으면 테이블 800개 중 컬럼 의미를 설명할 사람이 아무도 남지 않고, 레이크는 아무도 쓰지 못하는 늪이 됩니다. 반대 오해도 흔합니다. 레이크를 깔았으니 웨어하우스는 필요 없다며 경영 대시보드를 원본에 직접 붙였다가, 임원이 조회할 때마다 수 TB를 스캔해 클라우드 청구서가 월 단위로 튀는 일이 벌어집니다. 적재 전에 정해야 할 것은 도구가 아니라 이 데이터의 주인이 누구인가입니다.
| 구분 | 데이터 웨어하우스 | 데이터 레이크 |
|---|---|---|
| 저장 형태 | 정리·구조화된 데이터 | 원본 그대로(비정형 포함) |
| 용도 | 바로 분석·리포트 | 일단 담고 나중 활용 |
| 비유 | 정돈된 창고 | 온갖 원료의 호수 |
데이터 웨어하우스는 1990년대 빌 인먼 등이 정립했고, 데이터 레이크는 빅데이터 시대(2010년경)에 비정형 원본까지 담기 위해 등장했습니다.
가상의 사례로 살펴보겠습니다. 임직원 410명, 연매출 2,100억 원 규모의 생활용품 유통사 A사는 주문·회원 데이터는 웨어하우스에 잘 담아 두고도 앱 로그와 상담 녹취는 파일 서버에 방치해 두고 있었습니다. 마케팅팀이 요청한 이탈 예측 모델은 '학습할 원본이 없다'는 이유로 두 번 무산됐고, 신규 지표 하나 추가에 평균 18일이 걸렸습니다.
- 데이터플랫폼팀 김 팀장은 흩어져 있던 3개월치 앱 로그 4.2TB를 객체 스토리지에 그대로 옮기고, 적재 시점·소스·담당자 세 항목만 적은 카탈로그를 함께 붙였습니다.
- CFO가 '스토리지 비용이 얼마나 늘어나느냐'고 묻자 김 팀장은 원본은 레이크에, 정제본만 웨어하우스에 올리는 구조로 바꿔 웨어하우스 적재량을 기존의 3분의 1로 줄였습니다.
- 마케팅 분석 담당 이 과장은 레이크의 로그에 주문 이력을 붙여 이탈 예측 모델을 학습시키되, 검증 라벨은 웨어하우스의 확정 매출 테이블에서만 가져오도록 기준을 고정했습니다.
- 현업 요청이 몰리자 테이블별로 데이터 오너를 지정해 주문은 영업관리팀, 로그는 개발팀이 정의를 책임지게 했고, 주인 없는 테이블은 카탈로그에 올리지 않는다가 원칙이 됐습니다.
- 6개월 뒤 신규 지표 추가 소요는 18일에서 4일로 줄었고, 이탈 예측 모델은 3개월 내 해지 고객의 61%를 미리 걸러내 재구매 쿠폰 발송 대상 선정에 쓰이고 있습니다.