이 문서는 데이터 기초 섹션의 일부입니다.
왜 이 개념을 알아야 하나요?
데이터를 수집했다면, 어딘가에 저장해야 합니다. 그런데 데이터를 저장하는 방식은 30년 동안 계속 진화해 왔고, 그 과정에서 수많은 기업이 비싼 수업료를 냈습니다. 데이터 웨어하우스의 비용 문제, 데이터 레이크의 거버넌스 문제 — 양쪽의 실패를 모두 경험한 끝에 나온 것이 레이크하우스(Lakehouse) 입니다. 이 역사를 모르고 레이크하우스를 배우면, “왜 굳이 이렇게 하는 거지?”라는 의문이 풀리지 않습니다. 각 접근법이 어떤 문제를 해결하려 했고, 어디서 실패했는지 이해하면, Databricks의 아키텍처가 자연스럽게 이해됩니다.데이터 웨어하우스 (Data Warehouse) — 30년간 살아남은 이유
개념
💡 데이터 웨어하우스(Data Warehouse) 란 비즈니스 의사결정을 위해 다양한 소스의 데이터를 구조화된 형태 로 통합·저장하는 중앙 저장소입니다.
왜 30년간 살아남았는가
1990년대에 Bill Inmon이 데이터 웨어하우스 개념을 정립하고, Ralph Kimball이 차원 모델링 방법론을 체계화한 이후, DW는 기업 분석의 중심이었습니다. Teradata, Oracle, Netezza, IBM DB2— 이 이름들은 한 시대를 지배했습니다. DW가 30년간 살아남은 핵심 이유는 “비즈니스 사용자가 바로 쓸 수 있다” 는 것입니다:- SQL만 알면 누구나 분석할 수 있습니다
- 데이터가 깨끗하고 일관됩니다 (Schema-on-Write 덕분)
- 성능이 빠릅니다 (분석에 최적화된 구조)
- 권한 관리가 체계적입니다 (누가 무엇을 볼 수 있는지 명확)
핵심 특징
💡 Schema-on-Write란? 데이터를 저장소에 쓰는(Write) 시점에 스키마를 강제하는 방식입니다. 엑셀 시트의 열 제목을 먼저 정하고, 그 규칙에 맞는 데이터만 입력하는 것과 같습니다. 장점은 데이터 품질이 보장된다는 것이고, 단점은 유연성이 떨어진다는 것입니다.
💡 컬럼 기반 저장(Columnar Storage)이란? 일반적인 RDBMS는 행(Row) 단위로 디스크에 데이터를 저장합니다. 하지만 분석용 DW는 열(Column) 단위로 저장합니다. “전체 고객의 매출 합계”를 구할 때, 행 기반이면 모든 컬럼을 읽어야 하지만, 컬럼 기반이면 amount 컬럼만 읽으면 됩니다. 100개 컬럼 중 1개만 읽으니 100배 빠른 것입니다. Databricks의 Delta Lake도 내부적으로 Parquet(컬럼 기반 포맷)을 사용합니다.
DW의 한계 — 왜 이것만으로는 안 되는가
2010년대에 들어서면서 DW의 한계가 뚜렷해졌습니다:⚠️ 실무에서 가장 큰 고통: “DW 저장 비용이 너무 비싸서, 3년 이상 된 데이터를 삭제해야 하는데, 규정상 5년 보관이 필수”라는 딜레마. 많은 기업이 이 비용 문제 하나 때문에 클라우드 전환을 결심했습니다.
대표적인 제품
데이터 레이크 (Data Lake) — 거대한 약속과 쓰라린 현실
개념
💡 데이터 레이크(Data Lake) 란 정형·반정형·비정형 데이터를 원본 형태 그대로 저장할 수 있는 대규모 저장소입니다.
데이터 레이크의 약속
2010년대 초반, Hadoop 생태계와 함께 데이터 레이크 개념이 떠올랐습니다. 그 약속은 매력적이었습니다:- 어떤 데이터든 저장 가능— 정형, JSON, 로그, 이미지, 동영상
- 저렴한 비용— S3에 저장하면 TB당 월 23달러. DW의 1/100
- 유연한 스키마— 먼저 넣고 나중에 구조를 정하면 됨 (Schema-on-Read)
- ML/AI에 적합— Python, Spark로 자유롭게 데이터 처리
💡 Schema-on-Read란? Schema-on-Write와 반대로, 데이터를 읽을 때 비로소 구조를 정하는 방식입니다. 원본 데이터를 그대로 저장해 두고, 분석할 때 “이 파일의 3번째 필드가 이름이고, 5번째 필드가 금액이야”라고 해석합니다. 유연하지만, 읽을 때마다 해석이 필요하고, 데이터 품질을 보장하기 어렵습니다.
💡 오브젝트 스토리지(Object Storage)란? AWS S3, Azure Blob Storage(ADLS), Google Cloud Storage 같은 클라우드 저장소입니다. 파일을 키(Key) 구조로 저장하며, 거의 무제한에 가까운 용량을 저렴하게 사용할 수 있습니다. 전통적인 파일 시스템과 달리 HTTP API로 접근합니다.
”Data Swamp” — 데이터 레이크의 쓰라린 현실
데이터 레이크의 약속은 아름다웠지만, 현실은 달랐습니다. 제대로 관리하지 않은 데이터 레이크는 “데이터 늪(Data Swamp)“이 됩니다. 이것은 비유가 아니라, 실제로 수많은 기업이 겪은 일입니다. 실제로 벌어지는 일:⚠️ 이것은 과장이 아닙니다. Gartner의 2020년 보고서에 따르면, 데이터 레이크 프로젝트의 85%가 실패 했습니다. 실패의 핵심 원인은 기술이 아니라 거버넌스(데이터 관리 체계)의 부재 였습니다.
데이터 레이크가 실패하는 구체적인 이유
대표적인 기술
- 1세대: Hadoop HDFS + MapReduce (2006~2015)
- 2세대: AWS S3 / Azure ADLS + Apache Spark (2015~현재)
- 3세대: S3/ADLS + Delta Lake + Unity Catalog = Lakehouse(2020~현재)
한눈에 비교
”우리 회사는 아직 DW를 쓰고 있는데, 전환해야 하나요?”
이 질문을 정말 많이 받습니다. 솔직한 답변을 드리겠습니다.전환이 필요한 신호
다음 중 3개 이상 해당 하면 레이크하우스 전환을 심각하게 고려해야 합니다:- DW 라이선스/하드웨어 비용이 연간 수억 원을 초과 하고 계속 증가하고 있다
- 비정형 데이터(로그, JSON, 이미지)가 급증하는데 DW에 넣을 수 없다
- ML/AI 프로젝트 를 시작하려는데, DW에서 데이터를 빼서 별도 환경으로 복사해야 한다
- 스키마 변경 에 2주 이상 걸려서 비즈니스 변화에 대응이 느리다
- DW의 3년 이상 데이터를 삭제 해야 하는 비용 압박을 받고 있다
- 실시간 데이터 처리 가 필요한데 DW로는 한계가 있다
전환이 아직 불필요한 경우
- 데이터 규모가 수 TB 이하이고, 정형 데이터만 분석한다
- 현재 DW 비용이 적정 수준이고, ML/AI 요구사항이 없다
- 조직 내 Spark/Python 역량이 전무하고, SQL만 사용한다
- 규정/보안 요건으로 클라우드 전환 자체가 제한된다
💡 핵심 조언: “무조건 레이크하우스로 가야 한다”는 것이 아닙니다. DW가 현재 니즈를 충족하고, 비용이 관리 가능하며, 향후 3년간 ML/AI 니즈가 없다면 — 지금 당장 전환할 이유가 없습니다. 하지만 대부분의 기업은 위 체크리스트의 3개 이상에 해당합니다. 그리고 전환은 빨리 시작할수록 비용이 적게 듭니다. 데이터가 10TB일 때 전환하는 것과 100TB일 때 전환하는 것은 복잡도가 10배가 아니라 100배 차이입니다.
전환 시 가장 흔한 실수
- “DW를 끄고 레이크하우스를 켜자” (빅뱅 전환)— 절대 하지 마세요. 6개월~1년 이중 운영을 각오해야 합니다
- “데이터 레이크를 먼저 만들고, 나중에 거버넌스를 추가하자” — Data Swamp의 지름길입니다. Unity Catalog부터 설정하세요
- “기존 ETL 로직을 그대로 Spark로 포팅하자” — ETL 패턴을 ELT로 전환해야 합니다. 1:1 변환은 의미가 없습니다
그래서, 레이크하우스란?
양쪽의 한계를 모두 겪은 끝에 나온 것이 레이크하우스(Lakehouse) 아키텍처입니다.
쉽게 말해, 데이터 레이크의 저렴함과 유연성+ 데이터 웨어하우스의 성능과 거버넌스= 레이크하우스 입니다.
현업 사례: Data Lake를 도입했는데 3년 만에 Data Swamp가 된 팀
현업에서는 이런 일이 정말 자주 벌어집니다. 실제 패턴을 구체적으로 공유합니다.사례: 대형 유통사의 Data Lake 프로젝트
어느 대형 유통사가 2019년에 “빅데이터 플랫폼”이라는 이름으로 AWS S3 기반 데이터 레이크를 구축했습니다. 초기 계획은 야심찼습니다.Data Swamp의 핵심 원인 5가지
현업에서 20년간 수많은 Data Lake 프로젝트를 지켜본 결과, 실패 원인은 기술이 아니라 거버넌스 입니다.⚠️ 현업에서는 이렇게 합니다: Data Lake를 시작하기 전에 반드시 거버넌스 프레임워크를 먼저 수립 합니다. Databricks로 전환한다면 Unity Catalog를 첫 번째로 설정하세요. “데이터를 넣고 나중에 정리하자”는 접근은 100% 실패합니다. 이것을 안 하면 3년 후 1PB의 쓰레기 더미를 갖게 됩니다.
현업 가이드: DW에서 Lakehouse로의 데이터 마이그레이션 실전 전략
DW에서 레이크하우스로 전환하는 것은 기술적 도전이면서 동시에 조직적 도전 입니다. 수년간의 마이그레이션 프로젝트 경험에서 얻은 실전 전략을 공유합니다.마이그레이션의 현실적 타임라인
마이그레이션에서 가장 많이 실패하는 3가지
전환 비용의 현실적 규모
현업에서 DW→Lakehouse 전환 프로젝트의 비용을 투명하게 공유합니다.💡 비용 절감 팁: 전환 비용의 50% 이상은 “이중 운영”과 “정합성 검증”에서 발생합니다. 이 기간을 줄이려면 (1) 영향도가 낮은 테이블부터 시작하고, (2) 자동화된 정합성 비교 도구를 초기에 구축하고, (3) DW 테이블 사용 빈도를 분석하여 안 쓰는 테이블은 전환 대상에서 제외하세요. 대부분의 기업에서 전체 테이블의 20~30%는 아무도 사용하지 않는 “좀비 테이블”입니다.
DW를 유지하면서 Lakehouse를 병행하는 전략
모든 기업이 DW를 완전히 버릴 수 있는 것은 아닙니다. 현실적으로 가장 많이 채택하는 하이브리드 전략입니다.⚠️ 현업에서는 이렇게 합니다: “DW를 없앨 거야”라고 선언하면 기존 DW 팀의 저항이 시작됩니다. “Lakehouse는 DW를 대체하는 것이 아니라 보완하는 것”이라고 포지셔닝하고, 신규 요구사항을 Lakehouse에서 처리하면서 자연스럽게 DW 사용량을 줄이는 것이 현실적입니다. 1~2년 후 DW 쿼리가 거의 없어지면, 그때 DW 해지를 논의합니다.
데이터 이관 시 꼭 확인할 체크리스트
💡 현업 팁: 마이그레이션 비용의 70%는 “데이터 정합성 검증”에 들어갑니다. 이 단계를 줄이려고 하면 나중에 10배의 비용으로 돌아옵니다. Oracle과 Spark는 NULL 처리, 문자열 비교, 소수점 연산에서 미묘한 차이가 있으므로, 반드시 샘플이 아닌 전수 검증 을 하세요.