483. ETL (Extract, Transform, Load) 파이프라인

⚠️ 이 문서는 매일 밤 쇼핑몰 데이터, 카카오톡 상담 데이터, 물류 데이터를 싹 다 긁어모아 사장님이 보기 좋은 하나의 데이터 창고(DW)에 넣기 위해, **데이터를 뽑아내고(E), 예쁘게 가공하고(T), 창고에 쏟아붓는(L) 가장 전통적인 데이터 파이프라인 기술인 'ETL'**을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 서로 다른 모양을 가진 여러 원천 시스템(운영 DB)의 데이터를 중앙의 데이터 웨어하우스(DW)로 옮겨 담는 3단계(추출 $\rightarrow$ 변환 $\rightarrow$ 적재) 이사 작업이다.
  2. 변환(Transform)의 병목: 데이터를 창고에 넣기 '전'에, 중간에 있는 ETL 전용 서버에서 데이터를 깎고 다듬는 작업(T)을 모두 끝내야 하므로 여기서 속도가 가장 느려진다.
  3. 보안성: 창고(DW)에 넣기 전에 주민번호 같은 민감 정보를 중간에 있는 ETL 서버에서 다 지워버리고 깨끗한 정보만 넣을 수 있으므로 보안에 아주 유리하다.

Ⅰ. 개요: 밤 12시의 대이동 (Context & Necessity)

데이터 웨어하우스(473번 문서)를 텅 빈 창고로 지어놨다 치자. 이제 이 창고에 짐(데이터)을 넣어야 한다.

  • Extract (추출): 영업팀 MySQL, 마케팅팀 Oracle, 물류팀 엑셀 파일에서 오늘 하루 발생한 1,000만 건의 데이터를 싹 다 긁어온다.
  • Transform (변환): 영업팀은 남자를 M, 마케팅팀은 1이라고 써놨다. 이걸 중간에 있는 마법의 공장(ETL 서버)에서 전부 남으로 통일시킨다. 잘못된 이메일 주소도 지운다.
  • Load (적재): 예쁘게 화장을 마친 데이터를 창고(DW)에 쏟아붓는다.

이 작업은 너무 무거워서 주로 사람들이 다 자는 매일 밤 12시에 배치(Batch) 프로그램으로 돌아간다. 이것이 데이터 엔지니어링의 시초인 ETL이다.

📢 섹션 요약 비유: ETL은 **'이삿짐 센터의 꼼꼼한 포장 이사'**와 같습니다. 원래 집에 있는 물건을 꺼내서(E), 안 쓰는 물건은 버리고 뽁뽁이로 예쁘게 각 잡아 포장한 뒤(T), 새 집에 차곡차곡 예쁘게 정리해서 넣는(L) 방식입니다. 짐 정리는 완벽하지만 이사 시간이 아주 오래 걸리죠.

Ⅱ. ETL의 영원한 숙제: Transform 병목 ★

ETL 시스템의 가장 큰 특징은 **"적재(Load)하기 전에 변환(Transform)을 끝낸다"**는 것이다.

  • 원리: 중간에 별도의 **'ETL 전용 서버(Staging Area)'**를 둔다.
  • 문제점: 1억 건의 데이터가 쏟아져 들어오면, 이 중간 서버가 데이터를 정제하고 깎아내느라 CPU가 터져버린다.
  • 결과: "아침 9시에 사장님이 어제 통계를 보셔야 하는데, ETL이 아직도 안 끝나서 10시에 출근하셔야 합니다..."라는 대참사가 발생한다. 이를 ETL 병목 현상이라고 부른다.

Ⅲ. 스키마 온 라이트 (Schema-on-Write)

ETL은 굉장히 깐깐한 수문장이다. DW에 "이름은 글자 10개, 나이는 숫자"라는 틀(Schema)을 미리 꽉 짜둔다.

  • 데이터가 ETL 서버를 통과할 때, 이 틀에 안 맞는 쓰레기 데이터(예: 나이에 '이십살'이라고 적힌 문자열)가 들어오면 어떻게 될까?
  • ETL 서버는 가차 없이 그 데이터를 튕겨내 버리거나(Drop) 멈춰버린다.
  • 이렇게 "쓸 때(Write) 틀에 맞는지 깐깐하게 검사하는 방식"을 **스키마 온 라이트(Schema-on-Write)**라고 부르며, 데이터의 품질(Data Quality)을 100% 보장하는 핵심 철학이다.
┌──────────────────────────────────────────────────────────────┐
│           ETL (Extract -> Transform -> Load) 파이프라인 시각화      │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 원천 시스템 (E) ]       [ ⚙️ ETL 중간 서버 (T) ]     [ 창고 (L) ]     │
│                         ★ 병목 발생 구간!                            │
│                                                              │
│ 1️⃣ MySQL (영업) ──┐                                         │
│                 │   ┌────────────────────┐   ┌────────────┐  │
│ 2️⃣ Oracle (인사) ┼─▶ │ 변환/정제/포맷 통일  │ ─▶ │ Data       │  │
│                 │   │ (주민번호 마스킹)    │   │ Warehouse  │  │
│ 3️⃣ CSV 파일     ──┘   └────────────────────┘   └────────────┘  │
│                                                              │
│ ★ 특징: 창고(DW)에 들어가기 전에 모든 검사와 가공이 중간에서 완료된다!          │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"완벽한 데이터를 얻기 위해 기꺼이 속도를 희생하다." 빅데이터 시대가 오면서 "데이터가 너무 많아서 ETL 중간 서버가 감당을 못해요!"라는 불만이 터져 나왔다. 그래서 요새는 일단 창고에 때려 박고 나중에 변환하는 ELT(484번 문서)가 유행하고 있다. 하지만 주민등록번호나 카드번호 같은 민감한 개인정보를 클라우드 데이터 창고에 함부로 부어버릴 수는 없다. 중간(ETL 서버)에서 민감 정보를 완벽하게 지워버리고(마스킹) 깨끗한 데이터만 창고로 들여보낼 수 있는 강력한 통제력, 이것이 무겁고 느린 ETL이 아직도 금융권과 대기업 파이프라인의 핵심으로 살아남아 있는 이유다.

📌 관련 개념 맵

  • 관련 시스템: Data Warehouse (473번 문서)
  • 대척점 파이프라인: ELT (Extract, Load, Transform - 484번 문서)
  • 데이터 철학: Schema-on-Write (저장할 때 스키마 맞추기)
  • 대표 도구: Apache Airflow (스케줄러), Talend, Informatica

👶 어린이를 위한 3줄 비유 설명

  1. ETL은 내가 주워 온 돌멩이들 중에서 '진짜 예쁜 보석'만 골라서 내 보석함에 넣는 과정이에요.
  2. 밖에서 돌멩이를 주워 오고(Extract), 수돗가에서 흙을 빡빡 씻어서 예쁜 돌만 고른 다음에(Transform), 마지막에 내 보석함에 예쁘게 진열하죠(Load).
  3. 씻는 데 시간이 너무 오래 걸려서(병목) 힘들긴 하지만, 내 보석함 안에는 항상 반짝거리고 깨끗한 진짜 보석들만 있게 된답니다!