484. ELT (Extract, Load, Transform) 파이프라인
⚠️ 이 문서는 "1억 건의 데이터를 중간 서버에서 예쁘게 깎느라 밤을 새운다(ETL)"는 고정관념을 버리고, **"일단 무식하게 크고 강한 클라우드 데이터 창고(DW)에 원본 데이터를 다 때려 부은(Load) 다음, 창고 안에서 그 강력한 CPU로 데이터를 깎고 다듬자(Transform)!"는 최신 데이터 파이프라인 패러다임인 'ELT'**를 다룹니다.
핵심 인사이트 (3줄 요약)
- 본질: 추출(Extract) $\rightarrow$ 적재(Load) $\rightarrow$ **변환(Transform)**의 순서로 진행되는 이사 작업이다. ETL(483번 문서)과 T와 L의 순서가 뒤바뀌었다.
- 배경: 과거와 달리 Snowflake, BigQuery 같은 클라우드 DW의 연산 능력(CPU)이 무시무시하게 강력해졌기 때문에 가능해진 아키텍처다.
- 가치: 중간에 병목(ETL 서버)이 없어서 원본 데이터의 수집 속도가 빛의 속도가 되며, 원본(Raw Data)이 그대로 보존되어 있어 데이터 과학자들이 다양한 각도로 다시 분석할 수 있다 (Schema-on-Read).
Ⅰ. 개요: 일단 다 싣고 가서 생각하자 (Context & Necessity)
"하루에 1억 건씩 쏟아지는 앱 클릭 로그를 분석해야 해!"
- 과거 (ETL 방식): 중간에 있는 허약한 ETL 서버가 이 1억 건의 로그를 예쁘게 다듬으려다가 과로사로 죽어버렸다. (Transform 병목)
- 현대 (ELT 방식): 일단 1억 건의 통나무(원목)를 클라우드의 초거대 제재소(BigQuery, Snowflake) 마당에 트럭으로 다 쏟아붓는다(Load). 제재소 안에는 슈퍼컴퓨터 급의 톱날(CPU)이 수천 개 돌아가고 있다. 거기서 무자비한 속도로 통나무를 깎아서 예쁜 가구(통계)로 만든다(Transform).
클라우드 DW의 막강한 병렬 처리 능력을 100% 활용하기 위해, "변환의 짐"을 중간 서버가 아닌 **'가장 힘센 목적지 서버(DW)'**로 떠넘겨버린 것이 ELT의 철학이다.
📢 섹션 요약 비유: ETL이 이삿짐 센터에서 **'뽁뽁이로 완벽하게 포장해서 트럭에 싣는 것(오래 걸림)'**이라면, ELT는 포장이 뭐고 간에 일단 물건들을 '포크레인으로 덤프트럭에 다 쓸어 담아서 새 집에 냅다 부어버리고(엄청 빠름)', 새 집의 넓은 거실에서 천천히 정리하는 방식입니다.
Ⅱ. ELT와 스키마 온 리드 (Schema-on-Read) ★
ELT는 데이터 레이크(482번 문서)의 등장과 궤를 같이한다.
- "일단 다 때려 부어라 (Load)":
- DW나 Data Lake(S3 등) 안의 임시 공간(Staging)에 텍스트, JSON 가리지 않고 원본 데이터를 쑤셔 넣는다.
- "읽을 때 맞춰라 (Schema-on-Read)":
- 데이터 분석가나 dbt 같은 변환 툴이, 창고 안에 쌓인 원본 데이터를 향해
SELECT쿼리를 날리면서 "이 JSON의 첫 번째 키는 이름으로 부르자!"라고 읽는 순간에 틀(스키마)을 씌운다.
- 데이터 분석가나 dbt 같은 변환 툴이, 창고 안에 쌓인 원본 데이터를 향해
가장 큰 장점: 원본 데이터(Raw Data)가 삭제되지 않고 창고 구석에 영원히 남아있다. 나중에 다른 팀에서 "우린 다른 방식으로 변환해서 분석할래요!"라고 할 때 언제든 원본을 꺼내 쓸 수 있는 무한한 유연성을 제공한다.
Ⅲ. ELT의 단점: 무서운 클라우드 청구서
"ELT가 짱이네요! 다 이걸로 바꾸죠?" 세상에 공짜는 없다. 치명적인 단점이 존재한다.
- 보안의 위험 (개인정보 노출)
- ETL은 창고에 넣기 '전'에 중간에서 주민번호를 다 지워버린다.
- ELT는 일단 창고에 '주민번호가 포함된 원본'을 다 부어버리고 나중에 지운다. 창고가 털리면 개인정보가 통째로 유출되는 끔찍한 사태가 발생할 수 있다. (마스킹 로직의 딜레마)
- 돈, 돈, 돈 (Cloud Cost)
- BigQuery나 Snowflake는 '데이터를 스캔한 양'이나 '컴퓨팅(CPU)을 쓴 시간'만큼 달러($)로 과금한다.
- 원본 데이터를 창고 안에서 무식하게 깎고 변환(Transform)하는 쿼리를 매일 밤 돌리면, 다음 달에 수천만 원짜리 클라우드 청구서가 날아오게 된다.
┌──────────────────────────────────────────────────────────────┐
│ ELT (Extract -> Load -> Transform) 파이프라인 시각화 │
├──────────────────────────────────────────────────────────────┤
│ │
│ [ 원천 시스템 (E) ] [ 클라우드 DW (L+T) ] │
│ │
│ 1️⃣ 앱 클릭 로그 ──┐ ┌────────────────┐ │
│ │ (아무 가공 없이 일단 부어!) │ 📦 Staging Area │ │
│ 2️⃣ MongoDB ┼─────────────────────▶ │ (원본 로그 저장) │ │
│ │ └───────┬────────┘ │
│ 3️⃣ 외부 API 데이터┘ │ (T: 내부 연산)│
│ ▼ │
│ ┌────────────────┐ │
│ │ 📊 Analytics │ │
│ │ (예쁘게 변환된 표) │ │
│ └────────────────┘ │
│ │
│ ★ 특징: 가장 힘든 변환(T) 작업을, 가장 돈 많고 힘센 서버(DW)에게 시켜버린다! │
└──────────────────────────────────────────────────────────────┘
Ⅳ. 결론
"컴퓨팅 파워의 진화가 아키텍처의 패러다임을 바꾼다." ELT는 기술의 발전이 만든 필연적인 결과다. 과거에는 데이터 웨어하우스(Oracle 등)의 하드디스크와 CPU가 너무 비싸서 거기에 쓰레기 데이터(원본)를 넣는 건 상상도 할 수 없었다. 하지만 클라우드 스토리지(S3) 가격이 껌값이 되고 클라우드 분산 연산 엔진(Snowflake)이 등장하면서, "중간 서버에서 낑낑대지 말고 그냥 무식하게 다 때려 박자!"라는 대담한 접근이 가능해진 것이다. 현대의 데이터 엔지니어는 개인정보나 정합성이 중요한 결제 데이터는 ETL로 통제하고, 무한히 쏟아지는 앱 사용 로그나 행동 데이터는 ELT(Data Lake)로 빨아들이는 하이브리드 전략을 구사해야 한다.
📌 관련 개념 맵
- 관련 시스템: Data Lake (482번 문서), Cloud Data Warehouse
- 대척점 파이프라인: ETL (Extract, Transform, Load - 483번 문서)
- 데이터 철학: Schema-on-Read (읽을 때 스키마 맞추기)
- 대표 도구: dbt (Data Build Tool - 창고 안에서 T 작업을 SQL로 기가 막히게 해주는 도구), Snowflake, BigQuery
👶 어린이를 위한 3줄 비유 설명
- ELT는 갯벌에서 주운 조개들을 일단 '집 앞마당(데이터 창고)'에 트럭으로 다 쏟아붓는 거예요 (Load).
- 그다음 집 앞마당에서 수돗물을 틀어놓고 진흙을 씻어내며 예쁜 조개만 골라내죠 (Transform).
- 밖에서 씻고 들어오지 않아서(ETL 아님) 마당은 좀 더러워지겠지만, 일단 집으로 빨리빨리 가져올 수 있어서 시간이 엄청 절약된답니다!