데이터 파이프라인의 역사와 진화: ETL에서 Lakehouse까지
들어가며
오늘날의 데이터 스택은 어느 날 갑자기 완성된 모습으로 등장하지 않았습니다. Snowflake에 데이터를 적재하고 dbt로 변환하며 Airflow로 스케줄링하는 지금의 방식은, 지난 40여 년간 각 시대가 마주친 한계를 풀어 온 진화의 결과입니다. 왜 한때는 변환(Transform)을 적재(Load)보다 먼저 했는데 지금은 순서가 바뀌었을까요? 왜 데이터 레이크가 등장했고, 또 왜 레이크하우스로 다시 합쳐지고 있을까요?
이 글은 Data-Engineering-Essential 시리즈의 2단계로, 데이터 파이프라인의 역사를 따라가며 현재의 도구 선택이 왜 이렇게 생겼는지를 이해하는 것을 목표로 합니다. 역사를 알면 유행하는 도구에 휩쓸리지 않고, 그 도구가 풀려는 문제와 치르는 대가를 함께 볼 수 있습니다.
📌 이 글에서 다루는 내용
🔍 핵심 주제
- 데이터 웨어하우스의 탄생: OLTP와 분석의 분리, Inmon vs Kimball, ETL의 등장
- 빅데이터와 데이터 레이크: Hadoop·MapReduce, 스키마 온 리드, 그리고 “데이터 늪”
- ETL → ELT 전환: 비용 구조의 역전이 변환의 위치를 바꾼 과정
- Modern Data Stack과 레이크하우스: 클라우드 DW, dbt, 그리고 레이크+웨어하우스의 통합
- 배치 → 스트리밍: MapReduce에서 Spark, 그리고 실시간 처리로
🎯 왜 중요한가
각 시대는 이전의 한계를 풀면서 새로운 한계를 만들어 왔습니다. 이 진화의 패턴을 알면, 다음에 등장할 기술도 “무엇을 풀고 무엇을 포기하는가”의 관점으로 평가할 수 있습니다.
한눈에 보기 — 시대별 흐름
데이터 아키텍처는 크게 네 시대를 거쳐 왔습니다. 각 시대를 관통하는 한 줄의 변화를 먼저 그려 두면 세부가 자리를 잡습니다.
flowchart LR
E1["1980~90s<br/>데이터 웨어하우스<br/>ETL · 정형 중심"]
E2["2000s<br/>빅데이터 · Hadoop<br/>데이터 레이크 · 분산 배치"]
E3["2010s<br/>클라우드 · Modern Data Stack<br/>ELT · 매니지드 SaaS"]
E4["2020s<br/>레이크하우스 · 스트리밍<br/>통합 · 실시간"]
E1 -->|"비정형·규모의 폭증"| E2
E2 -->|"클라우드·비용 역전"| E3
E3 -->|"레이크/DW 분열 해소·실시간 요구"| E4
1. 데이터 웨어하우스의 시대 (1980~90s)
이야기는 하나의 깨달음에서 시작됩니다 — 운영 데이터베이스에서 직접 분석을 돌리면 안 된다. 주문을 처리하는 OLTP(Online Transaction Processing) 데이터베이스는 빠른 단건 읽기/쓰기에 최적화되어 있어, “지난 3년간 지역별 매출 추이” 같은 대규모 집계 쿼리를 돌리면 운영 시스템 전체가 느려졌습니다. 그래서 분석 전용 저장소, 데이터 웨어하우스(Data Warehouse)가 분리되어 나왔습니다. 이것이 OLAP(Online Analytical Processing)의 출발입니다.
웨어하우스를 어떻게 설계할 것인가를 두고 두 거장의 접근이 갈렸습니다.
- Bill Inmon (Top-down): 전사적 데이터 웨어하우스(EDW)를 정규화된(3NF) 단일 진실 공급원으로 먼저 구축하고, 부서별 데이터 마트를 그 아래에 둡니다. 일관성은 강하지만 초기 구축이 무겁습니다.
- Ralph Kimball (Bottom-up): 비즈니스 프로세스 단위의 차원 모델(Dimensional Model) — 사실 테이블(Fact)과 차원 테이블(Dimension)로 구성된 스타 스키마(Star Schema) — 을 먼저 만들고 점진적으로 통합합니다. 분석가가 이해하기 쉽고 빠르게 가치를 냅니다.
이 시대에 ETL(Extract → Transform → Load)이 표준으로 자리 잡았습니다. 웨어하우스의 스토리지와 컴퓨팅이 매우 비쌌기 때문에, 값비싼 웨어하우스에 넣기 전에 별도의 ETL 서버에서 데이터를 미리 정제·변환·집계해 깔끔한 형태로만 적재했습니다. Informatica, DataStage 같은 전용 ETL 도구가 이 시대를 대표합니다. 데이터는 적재 시점에 이미 스키마가 정해져 있어야 했는데, 이를 스키마 온 라이트(Schema-on-Write)라 부릅니다.
한계: 정형 데이터만 다룰 수 있었고, 스키마를 미리 고정해야 했으며, 규모를 키우려면 더 비싼 장비로 갈아타는 스케일 업(Scale-up)에 의존했습니다. 2000년대 들어 웹·로그·이미지 같은 비정형 데이터가 폭증하자 이 모델은 한계에 부딪힙니다.
2. 빅데이터와 Hadoop, 데이터 레이크 (2000s)
구글·야후 같은 기업이 웹 규모(web-scale) 데이터를 마주하면서 판이 바뀌었습니다. 단일 고가 장비로는 감당이 안 되는 양을, 구글은 값싼 범용 장비 수천 대로 나눠 처리하는 방식으로 풀었습니다. 그 설계를 담은 GFS와 MapReduce 논문이 공개되자, 이를 오픈소스로 구현한 Hadoop(HDFS + MapReduce)이 빅데이터 시대를 열었습니다.
핵심 전환은 두 가지였습니다.
- 스케일 아웃(Scale-out): 더 비싼 한 대가 아니라, 평범한 장비를 여러 대로 늘려 처리량을 키웁니다. 분산 시스템이 데이터 엔지니어링의 기본 전제가 됩니다.
- 스키마 온 리드(Schema-on-Read): 일단 원본을 형태 불문하고 값싸게 저장해 두고, 읽을 때 비로소 구조를 해석합니다. 미리 스키마를 정하지 않아도 되니 유연합니다.
이 사고에서 데이터 레이크(Data Lake)가 태어났습니다. 정형이든 비정형이든 원본 그대로 호수에 담아 두고, 나중에 필요할 때 꺼내 해석한다는 발상입니다. “버리지 말고 일단 다 저장하라”가 구호였습니다.
한계: Java로 MapReduce 잡을 짜는 일은 복잡하고 느렸으며(디스크 기반), 거버넌스·카탈로그 없이 데이터를 쌓기만 하다 보니 무엇이 어디 있는지 알 수 없는 데이터 늪(Data Swamp)으로 전락하기 일쑤였습니다. “저장은 쉬운데 쓸 수가 없다”는 문제가 남았습니다.
3. ETL에서 ELT로 — 변환을 어디서 하는가
가장 근본적인 전환은 변환을 어디서 수행하는가의 변화입니다. 이를 가능케 한 것은 기술이라기보다 비용 구조의 역전이었습니다.
과거 ETL이 “적재 전 변환”을 고집한 이유는 웨어하우스의 스토리지·컴퓨팅이 비쌌기 때문입니다. 그런데 클라우드 시대에 들어 스토리지가 거의 공짜에 가까워지고, 무엇보다 컴퓨팅과 스토리지가 분리(decoupled)되어 필요할 때만 강력한 연산을 탄력적으로 빌려 쓸 수 있게 되었습니다. 그러자 발상이 뒤집힙니다 — 원본을 먼저 값싸게 적재(Load)하고, 강력한 웨어하우스 안에서 SQL로 변환(Transform)하면 되지 않는가?
이것이 ELT(Extract → Load → Transform)입니다.
| 구분 | ETL | ELT |
|---|---|---|
| 변환 위치 | 적재 전, 별도 ETL 서버 | 적재 후, 웨어하우스 내부 |
| 저장 대상 | 정제된 데이터만 | 원본까지 모두 |
| 유연성 | 낮음 (변환 후엔 원본 소실) | 높음 (원본 보존, 재변환 자유) |
| 변환 언어 | 전용 ETL 도구 | SQL (분석가·애널리틱스 엔지니어) |
| 전제 조건 | 비싼 스토리지·컴퓨팅 | 값싼 스토리지, 분리된 탄력 컴퓨팅 |
ELT의 진짜 힘은 원본을 보존한다는 데 있습니다. 요구사항이 바뀌어도 원본에서 다시 변환하면 되고, 변환 로직을 SQL로 표현할 수 있어 데이터 엔지니어가 아닌 분석가도 변환에 참여할 수 있게 되었습니다. 이 흐름이 뒤에서 dbt와 애널리틱스 엔지니어(Analytics Engineer)라는 직무를 낳습니다.
4. 클라우드와 Modern Data Stack (2010s)
ELT를 현실로 만든 주역은 클라우드 데이터 웨어하우스입니다. Amazon Redshift(2012), Google BigQuery, 그리고 Snowflake가 컴퓨팅과 스토리지를 완전히 분리한 구조로 등장하면서, 누구나 클릭 몇 번으로 페타바이트급 분석 엔진을 빌려 쓸 수 있게 되었습니다.
그 위에서 Modern Data Stack(MDS)이라는 조합이 표준으로 자리 잡습니다.
- 수집: Fivetran·Airbyte 같은 매니지드 커넥터가 원천 → 웨어하우스 적재(EL)를 자동화
- 저장·연산: Snowflake/BigQuery/Redshift 등 클라우드 DW
- 변환: dbt가 SQL 기반 변환을 모델·테스트·문서화와 함께 관리
- 서빙: Looker·Tableau 등 BI 도구
핵심은 모듈형 SaaS 조합이라는 점입니다. 직접 인프라를 구축하던 시대에서, 잘 만들어진 매니지드 서비스를 레고처럼 조립하는 시대로 넘어왔습니다. 진입 장벽이 크게 낮아졌고, SQL만 잘 다루면 변환 계층을 책임지는 애널리틱스 엔지니어라는 새 역할이 생겨났습니다.
5. 레이크하우스와 스트리밍 (2020s)
2010년대를 거치며 많은 조직이 데이터 레이크와 데이터 웨어하우스를 둘 다 운영하게 되었습니다. 레이크에는 원본·비정형·ML 데이터를, 웨어하우스에는 정제된 분석 데이터를 두는 식이죠. 그러나 두 시스템을 동기화하고 이중으로 관리하는 비용이 만만치 않았습니다. 여기서 두 흐름이 동시에 일어납니다.
(1) 레이크하우스(Lakehouse) — 둘의 통합. 값싼 오브젝트 스토리지(레이크) 위에 테이블 포맷을 얹어, 웨어하우스의 핵심 기능을 레이크에서 직접 제공하려는 시도입니다. Delta Lake·Apache Iceberg·Apache Hudi 같은 테이블 포맷은 레이크의 파일들 위에 다음을 더합니다.
- ACID 트랜잭션: 동시 쓰기에도 일관성 보장
- 스키마 진화(Schema Evolution): 컬럼 추가/변경을 안전하게
- 시간여행(Time Travel): 과거 특정 시점의 데이터 조회·복원
이로써 “레이크의 유연성·저비용 + 웨어하우스의 신뢰성·성능”을 한 곳에서 얻는 레이크하우스 아키텍처가 부상했습니다. 데이터 늪 문제에 대한 구조적 해답이기도 합니다.
(2) 배치에서 스트리밍으로. 처리 엔진도 진화했습니다. 디스크 기반의 느린 MapReduce를 인메모리 처리의 Apache Spark가 대체하며 배치 처리를 훨씬 빠르게 만들었고, 이어 Apache Flink·Kafka Streams가 데이터를 발생 즉시 처리하는 스트림 처리를 주류로 끌어올렸습니다. “어제까지의 데이터”가 아니라 “지금 이 순간의 데이터”를 요구하는 실시간 분석·이상 탐지·추천이 늘면서, 배치와 스트림을 결합하는 Lambda·Kappa 같은 아키텍처 논의도 활발해졌습니다(7단계에서 다룹니다).
정리 — 반복되는 진자
데이터 파이프라인의 역사는 몇 개의 진자 운동으로 읽을 수 있습니다.
- 정형 ↔ 유연: 스키마 온 라이트(웨어하우스)에서 스키마 온 리드(레이크)로 갔다가, 레이크하우스에서 둘의 절충으로 수렴.
- 변환의 위치: 적재 전(ETL) → 적재 후(ELT). 이를 가른 것은 기술이 아니라 비용 구조의 역전이었습니다.
- 중앙집중 ↔ 분산: 단일 EDW에서 분산 레이크로, 다시 통합 레이크하우스와 (조직 차원에서는) Data Mesh로.
- 배치 ↔ 실시간: 야간 배치에서 인메모리 배치(Spark), 그리고 스트리밍으로.
가장 중요한 교훈은 두 가지입니다. 첫째, 각 시대는 이전의 한계를 풀면서 새로운 한계를 만든다 — 그래서 “은총알”은 없고, 도구마다 푸는 문제와 치르는 대가가 있습니다. 둘째, 아키텍처는 종종 비용 구조가 결정한다 — ELT로의 전환이 보여 주듯, 무엇이 싸지고 무엇이 비싸지는가가 설계를 바꿉니다. 다음에 새 기술을 만나면 “이것은 무엇을 풀고, 그 대가로 무엇을 포기하며, 어떤 비용 변화가 이를 가능케 했는가?”를 물어보세요.
다음 학습 (Next Learning)
- Data Engineering Essential Curriculum — 전체 로드맵으로 돌아가 진행 상황 확인하기
- 데이터 엔지니어링이란: 수명주기와 데이터 엔지니어의 역할 — 1단계: 수명주기라는 사고의 틀 복습
- 데이터 수집(Ingestion): 배치·스트리밍·CDC와 수집 도구 — 3단계: 배치 vs 스트리밍, CDC, Kafka, 커넥터