데이터베이스, 데이터 웨어하우스, 데이터 레이크
비개발자를 위한 데이터 저장소 역할 비교. 운영 데이터베이스(OLTP), 데이터 웨어하우스(OLAP), 데이터 레이크와 레이크하우스가 비슷해 보여도 왜 역할이 다른지 설명합니다.
비슷해 보여도 역할은 다르다
"비개발자가 알아야 할 데이터베이스 이야기" 12부작 중 4편입니다. '데이터 저장소'라고 통칭되는 세 가지 — 운영 데이터베이스, 데이터 웨어하우스, 데이터 레이크 — 의 역할 차이를 정리합니다.
마트 계산대에서 고객이 기다리고 있는데, 직원이 지난 5년간의 매출 분석을 같은 계산대에서 시작한다면 어떻게 될까? 계산이 느려지고 줄이 길어질 것이다. 디지털 서비스에서도 오늘의 주문을 처리하는 일과 수년치 주문을 분석하는 일은 성격이 다르다.
이 차이가 세 가지 저장소가 존재하는 이유다.
운영 데이터베이스: 지금 일어나는 일을 처리한다
**운영 데이터베이스(operational database)**는 회원 가입, 주문, 결제, 예약, 재고 변경처럼 현재의 업무를 빠르고 정확하게 처리한다. 한 번에 비교적 적은 수의 기록을 자주 읽고 바꾼다.
고객이 주소를 고치면 해당 고객의 주소 한 건을 빠르게 수정해야 한다. 이런 처리를 **온라인 트랜잭션 처리(OLTP)**라고도 부른다. 3편의 관계형 데이터베이스가 대표적이다.
핵심 특성:
- 소량의 기록을 초고속으로, 수많은 사용자가 동시에
- 지금 이 순간의 정확한 값이 중요 (현재 재고, 현재 잔액)
- 멈추면 곧바로 매출과 서비스가 멈춘다
데이터 웨어하우스: 여러 자료를 모아 분석한다
**데이터 웨어하우스(data warehouse)**는 여러 업무 시스템의 데이터를 모아 보고서와 분석에 맞게 정리한 저장소다. "지난 3년 동안 지역별 매출과 반품률은 어떻게 변했는가?"처럼 많은 데이터를 한꺼번에 읽는 질문에 적합하다. 이런 처리를 온라인 분석 처리(OLAP)라고 부른다.
운영 시스템마다 고객이나 상품을 부르는 방식이 다를 수 있기 때문에, 웨어하우스로 옮기면서 형식을 맞추고 의미를 정리하는 과정이 중요하다. 이 변환 작업을 ETL(추출·변환·적재)이라고 부른다. 잘 정리된 웨어하우스는 조직이 같은 숫자를 보고 대화하게 돕는다.
대표 예: Snowflake, Google BigQuery, Amazon Redshift, Microsoft Fabric 계열
데이터 레이크: 원래 형태에 가까운 자료를 넓게 담는다
**데이터 레이크(data lake)**는 표로 정리된 데이터뿐 아니라 로그, 이미지, 음성, 문서 같은 다양한 자료를 비교적 원래 형태에 가깝게 보관한다. "나중에 어떤 분석에 쓸지 아직 모르지만 일단 담아 두는" 유연함이 장점이다. 머신러닝 학습용 원자료를 모으는 데 자주 쓰인다.
호수처럼 많이 담을 수 있다는 장점이 있지만, **설명과 책임자 없이 자료만 쌓으면 무엇인지 알 수 없는 '데이터 늪(data swamp)'**이 된다. 데이터 목록, 출처, 품질, 보관 기간을 함께 관리하지 않으면, 쌓인 데이터는 자산이 아니라 보안 위험이자 비용이 된다.
레이크하우스: 두 접근을 결합하려는 시도
**레이크하우스(data lakehouse)**는 데이터 레이크의 유연한 저장 방식에 웨어하우스의 관리·분석 기능을 더하려는 접근이다. 다만 경계는 제품과 설계에 따라 달라지므로 이름만 보고 판단해서는 안 된다. "레이크하우스입니다"라는 소개를 들으면 "구체적으로 어떤 관리 기능이 있나요?"라고 물어보는 것이 좋다.
세 저장소 비교
| 구분 | 운영 데이터베이스 | 데이터 웨어하우스 | 데이터 레이크 |
|---|---|---|---|
| 목적 | 지금의 업무 처리 | 정제된 데이터의 분석 | 원자료의 대량 보관 |
| 비유 | 계산대 | 회계·분석 사무실 | 원자재 창고 |
| 질문 예 | "이 고객의 주문 상태는?" | "지난 3년 지역별 매출 추이는?" | "일단 다 담아 두고 나중에 분석" |
| 데이터 상태 | 현재값, 실시간 변경 | 정제·통합된 이력 | 원형에 가까운 상태 |
| 대표 기술 | PostgreSQL, MySQL 등 | Snowflake, BigQuery 등 | S3 기반 스토리지, Hadoop 계열 |
대시보드의 숫자가 서로 다른 이유
영업팀 보고서에는 고객이 10만 명인데 마케팅팀 화면에는 12만 명일 수 있다. 한쪽이 반드시 틀렸다고 단정할 수는 없다. '고객'을 구매한 사람으로 정의했는지, 이메일을 등록한 사람까지 포함했는지에 따라 달라진다. 취소 주문을 매출에서 언제 제외하는지도 차이를 만든다.
분석 시스템을 잘 만든다는 것은 데이터를 한곳에 복사하는 데서 끝나지 않는다. 지표의 뜻, 계산 방법, 갱신 시점, 책임자를 합의해야 한다. 이것이 7편의 주제인 데이터 거버넌스로 이어지는 지점이다.
운영과 분석을 무조건 분리해야 할까?
작은 서비스에서는 하나의 관계형 데이터베이스로 운영과 간단한 보고서를 함께 처리해도 충분할 수 있다. 데이터가 늘고 복잡한 분석이 서비스 속도를 방해하기 시작할 때 별도의 분석 저장소를 검토하면 된다.
처음부터 거대한 데이터 플랫폼을 만들면 비용과 관리 부담이 사업 가치보다 커질 수 있다. 반대로 중요한 보고서를 운영 데이터베이스에서 무겁게 실행해 고객 서비스가 느려진다면, 분리를 늦춘 대가를 치르게 된다. 분리의 시점은 "분석 때문에 서비스가 느려지기 시작했는가"가 실용적인 신호다.
핵심 정리 운영 데이터베이스는 지금의 거래를 처리하고, 데이터 웨어하우스는 여러 시스템의 데이터를 정리해 분석하며, 데이터 레이크는 다양한 원자료를 넓게 담는다. 어떤 저장소를 쓰든 지표의 의미와 책임자가 정해져 있지 않으면, 조직은 같은 데이터를 보고도 다른 결론을 낸다. 그리고 관리 없이 쌓인 레이크는 호수가 아니라 늪이 된다.
생각해 볼 질문
- 우리 대시보드의 '활성 사용자', '고객', '매출'은 정확히 무엇을 뜻하는가?
- 그 정의를 누가 승인하며 어디에 기록해 두었는가?
- 분석 작업 때문에 고객 서비스가 느려진 적은 없는가?
- 쌓아 둔 데이터 중에 출처와 책임자를 아무도 모르는 것이 있는가?
다음 글: 데이터베이스 제품을 고를 때 성능보다 먼저 물어야 할 질문을 정리한다.
시리즈 목차
- 데이터베이스란 무엇인가 — 엑셀 파일과 무엇이 다를까?
- 데이터베이스는 어떻게 정확성을 지킬까
- 데이터베이스에는 어떤 종류가 있을까
- 데이터베이스, 데이터 웨어하우스, 데이터 레이크 ← 현재 글
- 올바른 데이터베이스 선택이 중요한 이유
- 데이터 모델과 데이터 품질
- 데이터 거버넌스란 무엇인가
- 개인정보는 적게, 필요한 만큼만
- 데이터 보안의 기본
- 데이터 침해는 왜 일어나며, 발생하면 무엇을 해야 할까
- 클라우드와 서버리스 데이터베이스
- AI 시대의 데이터베이스
