226. ETL (Extract, Transform, Load)

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

본질: ETL(Extract, Transform, Load)은 소스 시스템에서 데이터를 추출(E)하고, 전용 서버에서 변환·정제(T)한 후, 타겟 DW에 적재(L)하는 전통적 데이터 통합 방식이다.

가치: 스테이징 서버에서 변환을 완료하므로 DW에는 정제된 데이터만 저장되어 데이터 품질이 높고, 소스 DB에 분석 쿼리 부하를 주지 않는다.

판단 포인트: 변환 서버 성능이 병목이 되고, 빅데이터 규모에서 비용·성능 한계가 드러나 클라우드 시대에는 ELT로 전환하는 추세다.

Ⅰ. 개요 및 필요성

ETL은 1990년대 데이터 웨어하우스 구축의 황금 표준으로 자리잡았다. 기업의 다양한 운영 DB(ERP, CRM, 제조 시스템)는 각기 다른 스키마·코드 체계·인코딩을 사용하므로, 이를 단일 DW에 통합하려면 중간 변환 단계가 필수였다.

[ETL 흐름]
┌──────────┐   Extract   ┌──────────────────┐   Load   ┌──────────┐
│ 소스 DB   │ ──────────▶│   ETL 서버        │ ────────▶│ DW/Target│
│ Oracle   │            │   (Staging Area)  │          │ Redshift │
│ SAP ERP  │            │                  │          │ Snowflake│
│ MySQL    │            │  ① 타입 변환       │          └──────────┘
│ 플랫파일  │            │  ② NULL 처리      │
└──────────┘            │  ③ 코드 매핑      │
                        │  ④ 중복 제거      │
                        │  ⑤ 비즈니스 규칙  │
                        └──────────────────┘
                           변환 서버가 병목

필요성:

이기종 DB의 데이터 통합 (Oracle + MySQL + Flat File)
코드 체계 통일 (A/B → 활성/비활성)
타입 변환 (VARCHAR → DATE)
비즈니스 규칙 적용 (순매출 = 총매출 - 반품)

📢 섹션 요약 비유: ETL은 주문받은 재료(Extract)를 주방(Transform 서버)에서 손질·조리한 뒤 식탁(DW)에 올리는 요식업 프로세스다. 식탁에는 항상 완성된 음식만 오르지만, 주방이 혼잡(병목)하면 전체 서비스가 느려진다.

Ⅱ. 아키텍처 및 핵심 원리

ETL 단계별 상세

[Extract (추출)]
┌──────────────────────────────────────────────┐
│ 방법:                                         │
│  - Full Extract: 전체 테이블 복사 (초기 적재)  │
│  - Incremental: 변경분만 (타임스탬프/CDC)      │
│                                              │
│ 도전:                                         │
│  - 소스 DB 부하 최소화 (야간 배치 선호)         │
│  - 데이터 일관성 (스냅샷 시점 통일)             │
└──────────────────────────────────────────────┘

[Transform (변환)]
┌──────────────────────────────────────────────┐
│  스테이징 영역 (ETL 서버 메모리/디스크)          │
│  ┌─────────────┬─────────────────────────┐   │
│  │ 데이터 품질  │ 중복 제거, NULL 대체      │   │
│  │ 타입 변환   │ YYYYMMDD → DATE           │   │
│  │ 코드 매핑   │ '01' → '활성'             │   │
│  │ 집계 계산   │ 일별 매출 합산             │   │
│  │ 비즈니스 룰 │ 순매출 계산               │   │
│  └─────────────┴─────────────────────────┘   │
└──────────────────────────────────────────────┘

[Load (적재)]
┌──────────────────────────────────────────────┐
│  Full Load: 기존 데이터 삭제 후 전체 재적재      │
│  Incremental Load: 신규/변경분만 UPSERT         │
│  Slowly Changing Dimension (SCD):             │
│    - Type 1: 덮어쓰기                          │
│    - Type 2: 이력 보존 (유효기간 컬럼 관리)      │
└──────────────────────────────────────────────┘

주요 ETL 도구

구분	도구	특징
온프레미스 상용	IBM DataStage, Informatica	강력한 GUI, 엔터프라이즈 기능
오픈소스	Apache Spark, Talend	무료, 대규모 처리
클라우드 관리형	AWS Glue, Azure Data Factory	서버리스, 클라우드 통합
Python 기반	Pandas, dbt	경량, 데이터 엔지니어 선호

📢 섹션 요약 비유: ETL 도구는 공장 라인의 기계다. 온프레미스 상용 도구는 대형 프레스기(고성능·고비용), 클라우드 서버리스는 필요할 때만 가동하는 임대 기계(유연성)이다.

Ⅲ. 비교 및 연결

ETL vs ELT 핵심 비교

비교 항목	ETL	ELT
변환 위치	전용 ETL 서버 (외부)	타겟 DW/레이크 내부
적재 데이터	정제 완료 데이터	원시(Raw) 데이터
처리 순서	Extract → Transform → Load	Extract → Load → Transform
병목 지점	ETL 서버 성능	DW/레이크 컴퓨팅 성능
DW 저장 내용	최종 정제 데이터만	원시+정제 데이터 모두
비용 구조	ETL 서버 비용	DW/레이크 컴퓨팅 비용
빅데이터 확장성	어려움 (ETL 서버 스케일)	용이 (DW 수평 확장)
적합 환경	온프레미스, 중소 규모	클라우드 DW, 대규모
대표 시나리오	SAP DW 구축, 금융 코어	Snowflake + dbt, BigQuery

SCD (Slowly Changing Dimension) 유형

유형	처리 방식	적용 예시
SCD Type 1	현재 값으로 덮어쓰기	고객 주소 변경 (이력 불필요)
SCD Type 2	새 행 추가 + 유효기간 관리	직원 부서 이동 (이력 필요)
SCD Type 3	이전 값 별도 컬럼 보관	제품 카테고리 변경 (1회 이력)

📢 섹션 요약 비유: ETL과 ELT의 차이는 세탁 방식 차이다. ETL은 세탁기(ETL 서버)에서 완전히 빨고 나서 옷장(DW)에 넣는 것, ELT는 세탁 전 옷을 일단 옷장에 집어넣고 나중에 옷장 안에서 정리하는 것이다.

Ⅳ. 실무 적용 및 기술사 판단

ETL 파이프라인 설계 원칙

[ETL 설계 체크리스트]
□ 멱등성(Idempotency): 재실행해도 동일한 결과 보장
□ 증분 처리: 타임스탬프 기반 또는 CDC로 변경분만 처리
□ 에러 처리: 실패 데이터 격리(DLQ), 알림, 재처리
□ 모니터링: 처리 건수, 실행 시간, 오류율 대시보드
□ 데이터 계보(Lineage): 어떤 소스가 어떤 타겟으로 흘렀는지 추적
□ 재처리 가능성: 특정 날짜 재실행(Backfill) 지원

실무 주의사항

주의사항	내용
소스 부하 최소화	야간 배치, 읽기 전용 레플리카 사용
스테이징 테이블	실패 시 DW 직접 오염 방지
형 변환 안전성	암묵적 타입 변환 피하고 명시적 CAST 사용
인코딩 통일	UTF-8로 표준화하여 한글 데이터 손상 방지

기술사 핵심 판단: ETL은 온프레미스·레거시 환경에서는 여전히 유효하지만, 클라우드 전환 프로젝트에서는 ELT 전환을 제안하고 변환 서버 병목 해소 효과를 논리적으로 서술한다.

📢 섹션 요약 비유: ETL의 변환 서버 병목은 12차선 고속도로가 2차선 터널로 합쳐지는 상황이다. 데이터는 빠르게 추출되지만, 변환 서버라는 좁은 터널을 통과해야만 DW에 들어갈 수 있어 병목이 발생한다.

Ⅴ. 기대효과 및 결론

기대효과

효과	내용
데이터 품질 보장	변환 서버의 철저한 검증으로 DW 품질 최상 유지
소스 DB 보호	추출 이후 변환이 별도 서버에서 수행
다양한 소스 통합	이기종 DB, 플랫파일, API 모두 통합 가능
감사 추적	스테이징 테이블에 변환 전·후 데이터 보관

한계 및 주의점

한계	내용
변환 서버 병목	빅데이터 규모에서 ETL 서버가 전체 처리 속도 제한
원시 데이터 미보존	변환 후 DW 적재, 원시 재분석 불가
스키마 경직성	소스 스키마 변경 시 ETL 파이프라인 전체 수정
ELT 대비 고비용	클라우드 환경에서 ETL 서버 유지 비용

📢 섹션 요약 비유: ETL은 장인 요리사가 모든 음식을 직접 손질하는 고급 레스토랑이다. 품질은 최고지만, 한 명의 요리사(ETL 서버)가 모든 주문을 처리해야 하므로 손님(데이터)이 많아지면 대기 시간이 길어진다.

📌 관련 개념 맵

개념	연결 포인트
ELT	ETL의 현대적 대안, 변환 위치를 DW로 이동
데이터 웨어하우스	ETL의 주요 타겟 저장소
Schema-on-Write	ETL이 강제하는 데이터 저장 전 스키마 검증 전략
SCD (천천히 변하는 차원)	ETL Load 단계의 핵심 설계 패턴
Apache Airflow	ETL 파이프라인 스케줄링·오케스트레이션 도구
CDC	ETL의 증분 추출을 대체하는 실시간 변경 캡처 기술
dbt	ELT 패러다임에서 Transform 단계를 담당하는 도구

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

ETL은 밭(소스 DB)에서 채소를 캐와(Extract), 주방(ETL 서버)에서 씻고 썰어(Transform), 식탁(DW)에 차려내는(Load) 요리 과정이다.

📈 관련 키워드 및 발전 흐름도

ETL: Extract → Transform → Load (DW 외부에서 변환)
    │
    ▼
ELT: Extract → Load → Transform (DW 내부에서 변환)
    │
    ▼
실시간 ETL: Kafka + Flink/Spark Streaming + CDC

식탁에는 항상 깨끗이 손질된 음식만 올라오지만, 주방이 작으면 손님이 몰릴 때 음식이 늦게 나오는 것처럼, 데이터가 많아지면 ETL 서버가 느려질 수 있다.
ELT는 재료를 일단 식탁 위(DW)에 가져다 놓고, 먹을 사람이 직접 손질하는 방식이다. 주방이 필요 없지만, 식탁이 커야(DW 성능이 좋아야) 한다.