Brain핵심 인사이트
- 본질: ETL(Extract-Transform-Load, 추출·변환·적재)은 변환을 별도 서버에서 수행 후 DW에 적재하는 전통 방식이고, ELT(Extract-Load-Transform, 추출·적재·변환)는 원시 데이터를 먼저 클라우드 DW/Lakehouse에 적재한 뒤 DW의 분산 연산 능력으로 변환하는 현대적 패턴이다.
- 가치: ELT는 클라우드 DW(Snowflake, BigQuery, Redshift)의 MPP(Massively Parallel Processing, 대규모 병렬 처리) 능력을 활용하여 ETL 전용 서버 비용을 제거하고, 원시 데이터를 보존하여 재처리·탐색적 분석을 가능케 한다.
- 판단 포인트: 온프레미스·레거시 DW 환경이거나 변환 로직이 복잡하고 데이터 보안·마스킹이 적재 전에 필수라면 ETL이 적합하며, 클라우드 DW 중심·빅데이터 규모·빠른 반복 개발이 필요하면 ELT가 우세하다.
Ⅰ. 개요 및 필요성
1.1 ETL의 탄생과 클라우드로의 전환
1990년대 데이터 웨어하우스 도입과 함께 탄생한 ETL은 Informatica, IBM DataStage, Talend 등 전용 서버에서 데이터를 추출·정제·변환한 뒤 DW에 적재했다. 이 방식은 DW의 저장·연산 비용이 높던 시대에 최적이었다.
2010년대 클라우드 DW(BigQuery, Snowflake, Redshift)의 등장으로 패러다임이 전환됐다. 클라우드 DW는 컴퓨팅 비용을 사용량 기반으로 지불하고, MPP로 페타바이트 규모 변환도 수분 내 처리한다. 이제 전용 변환 서버 없이도 DW 내부에서 강력한 변환이 가능해졌고, ELT가 주류로 부상했다.
1.2 현대 ELT 스택: dbt의 부상
dbt(data build tool)는 ELT 패러다임의 핵심 도구로, SQL 기반 변환 로직을 코드로 관리(version control), 테스트, 문서화할 수 있게 한다. 데이터 엔지니어가 아닌 **분석 엔지니어(Analytics Engineer)**라는 새로운 직군을 만들어냈다.
ELT with dbt 파이프라인:
Fivetran (Extract+Load) → Raw Layer (S3/Snowflake) → dbt (Transform) → Marts
📢 섹션 요약 비유: ETL은 식재료를 요리사(전용 변환 서버)가 미리 손질해 요리된 상태로 냉장고(DW)에 넣는 방식이고, ELT는 식재료를 날 것 그대로 냉장고에 넣고, 냉장고(클라우드 DW) 안의 강력한 로봇 요리사가 알아서 요리하는 방식이다.
Ⅱ. 아키텍처 및 핵심 원리
2.1 ETL vs ELT 처리 흐름 비교
┌─────────────────────────────────────────────────────────────┐
│ ETL vs ELT Architecture Comparison │
│ │
│ ── ETL (전통 방식) ────────────────────────────────────── │
│ │
│ ┌─────────┐ Extract ┌───────────┐ Load ┌─────────┐ │
│ │ Source │──────────►│ Staging / │────────►│ DW │ │
│ │ Systems │ │ Transform │ │(정제본만)│ │
│ └─────────┘ │ Server │ └─────────┘ │
│ │(Informatica│ │
│ │/DataStage) │ │
│ └───────────┘ │
│ │
│ ── ELT (현대 방식) ────────────────────────────────────── │
│ │
│ ┌─────────┐ Extract ┌─────────┐ Transform ┌────────┐ │
│ │ Source │──────────►│ Cloud │───────────►│ Data │ │
│ │ Systems │ +Load │ DW / │ (SQL/dbt) │ Marts │ │
│ └─────────┘ │Lakehouse│ └────────┘ │
│ (Fivetran/ │(Raw 원시│ │
│ Airbyte) │ 데이터) │ │
│ └─────────┘ │
│ │
│ Key Difference: 변환 위치 = ETL(적재 전) vs ELT(적재 후) │
└─────────────────────────────────────────────────────────────┘
2.2 ETL vs ELT 상세 비교
| 항목 | ETL | ELT |
|---|---|---|
| 변환 시점 | 적재 전 (외부 서버) | 적재 후 (DW 내부) |
| 원시 데이터 보존 | ❌ 변환 후 원시 데이터 손실 | ✅ Raw 데이터 항상 보존 |
| 재처리 용이성 | 낮음 (파이프라인 재실행) | 높음 (SQL 재실행) |
| 인프라 비용 | ETL 서버 고정 비용 | 클라우드 사용량 기반 |
| 처리 속도 | 배치 중심, 변환 서버 성능 한계 | MPP 활용, 대용량 고속 처리 |
| 데이터 보안 | 적재 전 마스킹 가능 | DW 내 마스킹 처리 |
| 도구 | Informatica, DataStage, SSIS | dbt, Spark SQL, BigQuery |
| 적합 환경 | 레거시 DW, 복잡한 사전 변환 | 클라우드 DW, 빠른 반복 개발 |
2.3 현대 ELT 도구 생태계
| 역할 | 도구 | 특징 |
|---|---|---|
| Extract + Load | Fivetran, Airbyte, Stitch | 커넥터 기반 자동화 수집 |
| Transform | dbt, Spark SQL, Google Dataform | SQL 기반 변환 코드화 |
| Orchestration | Apache Airflow, Prefect, Dagster | 파이프라인 스케줄링·모니터링 |
| Storage | Snowflake, BigQuery, Redshift | 클라우드 MPP DW |
📢 섹션 요약 비유: ETL은 공장 생산 라인처럼 원자재를 제품으로 가공해 창고에 넣는 방식이고, ELT는 원자재 창고(클라우드 DW)에 넣은 후 창고 내부의 자동화 기계(MPP)가 그 자리에서 가공하는 방식이다. 공장 설비(ETL 서버) 비용 없이도 창고가 스스로 생산한다.
Ⅲ. 비교 및 연결
3.1 배치(Batch) vs 스트리밍(Streaming) vs 마이크로배치(Micro-batch)
| 방식 | 처리 단위 | 지연 | 도구 | 활용 |
|---|---|---|---|---|
| 배치 (Batch) | 시간 단위 대량 처리 | 분~시간 | Spark, Hadoop | 일/주 리포트 |
| 마이크로배치 | 수초 단위 소규모 배치 | 초~분 | Spark Structured Streaming | 근실시간 알림 |
| 스트리밍 (Real-time) | 이벤트 단위 즉시 처리 | ms~초 | Flink, Kafka Streams | 실시간 사기 탐지 |
3.2 Lambda vs Kappa 아키텍처
데이터 파이프라인 아키텍처의 두 대표 패턴:
| 아키텍처 | 구성 | 장점 | 단점 |
|---|---|---|---|
| Lambda | 배치 레이어 + 스피드 레이어 | 정확성(배치) + 속도(스트리밍) | 두 레이어 유지 복잡도 |
| Kappa | 스트리밍 레이어만 | 단순한 아키텍처 | 대용량 리프로세싱 어려움 |
📢 섹션 요약 비유: Lambda 아키텍처는 낮 동안의 배달원(빠르지만 오류 가능)과 야간 정기 배송(느리지만 정확)을 동시 운영하는 방식이고, Kappa는 "빠른 배달원만으로도 충분히 정확하게 할 수 있다"는 단순화 전략이다.
Ⅳ. 실무 적용 및 기술사 판단
4.1 ETL/ELT 선택 판단 기준
| 조건 | ETL 선택 | ELT 선택 |
|---|---|---|
| DW 환경 | 온프레미스, 레거시 DW | 클라우드 DW (Snowflake, BQ) |
| 데이터 보안 | 적재 전 PII 마스킹 필수 | DW 내 접근 제어 충분 |
| 변환 복잡도 | 복잡한 비즈니스 로직, 외부 API 호출 | SQL 기반 집계·조인 중심 |
| 원시 데이터 | 보존 불필요, 용량 비용 민감 | 원시 데이터 보존·재처리 필요 |
| 팀 역량 | Java/Python ETL 개발 역량 | SQL/dbt 중심 분석 팀 |
| 데이터 규모 | GB~TB 수준 | TB~PB 수준 |
4.2 현대 데이터 스택 (Modern Data Stack) 예시
소스 → [Fivetran] → [Snowflake Raw] → [dbt Transform] → [Marts] → [Tableau/Looker]
Extract+Load ELT 1단계 ELT 2단계 소비 시각화
4.3 기술사 핵심 출제 포인트
- ETL vs ELT 처리 순서와 위치: 변환의 위치(외부 서버 vs DW 내부) 차이 명확 기술
- 클라우드 DW ELT 장점: 원시 데이터 보존, 재처리 용이성, MPP 활용
- Lambda vs Kappa 아키텍처: 배치+스트리밍 통합 방식 비교
- dbt의 역할: SQL 기반 ELT 변환 코드화, 테스트, 문서화 통합
📢 섹션 요약 비유: ETL 선택은 "요리된 음식만 받는 레스토랑(DW)"에 맞는 방식이고, ELT 선택은 "재료를 받아 내부 주방(MPP)에서 직접 요리하는 레스토랑"에 맞는 방식이다. 내부 주방이 강력해질수록 ELT가 유리해진다.
Ⅴ. 기대효과 및 결론
5.1 ELT 도입 효과
| 효과 | 내용 |
|---|---|
| 인프라 비용 절감 | ETL 전용 서버 제거, 클라우드 사용량 기반 과금 |
| 개발 속도 향상 | dbt 기반 SQL 변환 코드화로 반복 개발 사이클 단축 |
| 데이터 재처리 용이 | 원시 데이터 보존으로 로직 변경 시 전체 재처리 가능 |
| 탐색적 분석 지원 | Raw 데이터에 직접 쿼리하여 새로운 인사이트 발굴 |
| 팀 자율성 향상 | 분석 엔지니어가 ETL 엔지니어 없이 변환 로직 수정 |
5.2 미래 방향
ELT 패러다임은 **역방향 ETL(Reverse ETL)**로 진화하고 있다. 역방향 ETL은 DW에서 분석된 결과를 다시 운영 시스템(CRM, 광고 플랫폼, 이메일 도구)으로 전송하여 "데이터 기반 운영 자동화"를 실현한다. 또한 스트리밍 ELT(Kafka → Flink → DW)가 실시간 데이터 파이프라인의 표준이 되고 있다.
📢 섹션 요약 비유: ETL이 쿠리어 회사(변환 서버)를 고용해 짐을 정리해 집(DW)에 배달하는 방식이라면, ELT는 짐을 그대로 집에 넣고 집 안의 로봇(MPP)이 정리하는 방식이다. 역방향 ETL은 정리된 짐 일부를 다시 필요한 사람(CRM, 광고 시스템)에게 재배달하는 단계다.
📌 관련 개념 맵
| 개념 | 설명 | 연관 키워드 |
|---|---|---|
| ETL (Extract-Transform-Load) | 변환 후 적재하는 전통 파이프라인 | Informatica, DataStage |
| ELT (Extract-Load-Transform) | 적재 후 DW 내부 변환하는 현대 패턴 | dbt, BigQuery, Snowflake |
| dbt (data build tool) | SQL 기반 ELT 변환 코드화 도구 | 분석 엔지니어, 테스트 |
| MPP (Massively Parallel Processing) | 대규모 분산 병렬 쿼리 처리 | 클라우드 DW, 성능 |
| Lambda Architecture | 배치+스트리밍 이중 레이어 아키텍처 | Kappa, 실시간+배치 |
| Reverse ETL | DW → 운영 시스템 역방향 데이터 전송 | 운영 자동화, Census |
| Fivetran | 커넥터 기반 자동화 ELT 수집 서비스 | SaaS, 300+ 커넥터 |
| Micro-batch | 수초 단위 소규모 배치 처리 | Spark Streaming |
👶 어린이를 위한 3줄 비유 설명
- ETL은 마트에서 집으로 가져오기 전에 쇼핑 카트에서 미리 포장 정리하는 것이고, ELT는 물건 그대로 집에 가져와서 집 안의 정리 로봇이 알아서 분류하는 방식이야.
- dbt는 LEGO 조립 설명서야. SQL 레고 블록을 어떻게 조립하면 원하는 데이터 구조가 되는지 단계별로 기록하고, 테스트하고, 공유할 수 있어.
- Lambda 아키텍처는 속달 배송(스트리밍, 빠르지만 오류 가능)과 일반 배송(배치, 느리지만 정확)을 동시에 운영하다가, Kappa 아키텍처는 "속달 배송만으로도 충분해"라고 결정하는 단순화야.