본문으로 건너뛰기
yutils

ETL 과 ELT 는 어떻게 다를까?

Extract-Transform-Load (전통) vs Extract-Load-Transform (modern default), 클라우드 warehouse (BigQuery / Snowflake / Redshift) 가 순서를 뒤집은 이유, compute vs storage cost 전환, schema-on-write vs schema-on-read, ETL 이 여전히 승리하는 경우.

약 9분 읽기

"ETL" — 1980 년대부터 data warehouse 의 표준어. 2015 년쯤 클라우드 warehouse (BigQuery / Snowflake / Redshift) 가 mainstream 되며 세 letter 의 순서가 뒤집힘 → "ELT". 단순 letter 순서 변경이 아니라 compute vs storage cost 의 패러다임 전환. 이 가이드는 두 모델의 정확한 차이와 ETL 이 여전히 승리하는 경우를 정리한다.

ETL — 전통 (1980s~2010s)

Extract → Transform → Load

1. Extract: source 시스템 (OLTP DB, SaaS API, CSV) 에서 데이터 추출
2. Transform: 별도 ETL server (Informatica, Talend) 가 가공
   - clean / join / aggregate / type 변환 / business logic
3. Load: 가공된 데이터를 warehouse (Teradata, Oracle DW) 에 적재

특징:
- transform 이 warehouse 외부 (cost 비싼 ETL server)
- warehouse 에는 final 형태만 (storage 비쌌으니까)
- schema-on-write — load 전 schema 확정
- batch 위주 (nightly job)

문제:
- transform 로직 변경 시 source 데이터 다시 가져와야 (이미 transform 됨)
- ETL server bottleneck (한 server 의 capacity)
- "이 column 도 필요했는데 transform 단계에서 drop 됨" → 다시 빌드
- ETL 도구의 vendor lock-in (Informatica 등 commercial)

ELT — Modern (2015+)

Extract → Load → Transform

1. Extract: source 에서 raw 데이터 추출
2. Load: 거의 그대로 warehouse 에 적재 (raw / staging schema)
3. Transform: warehouse 안에서 SQL 로 가공 (BigQuery / Snowflake / Redshift)

특징:
- transform 이 warehouse 내부 (cloud 의 elastic compute)
- raw 데이터 보존 — 나중에 다른 transform 가능
- schema-on-read 친화 (raw 는 자유 형식 OK)
- streaming / micro-batch 가능

가능해진 이유:
- 클라우드 warehouse 의 storage 매우 저렴 ($23 / TB / month, S3)
- compute 가 분리 (warehouse 의 query 가 storage 와 별도 scale)
- SQL 의 power 가 ETL 도구 대체 가능
- ELT 전용 도구 (dbt, Dataform) ecosystem

왜 ELT 가 mainstream

전통 가정:
- storage 비쌈 → 가공된 데이터만 보존
- compute 도 비쌈 → ETL server 에서 한 번에 처리
- warehouse 의 compute = SQL query 만 (transform 무거움)

클라우드 변화:
- storage 매우 저렴 (Parquet 압축 후 더더욱)
- compute 가 elastic (큰 transform job 도 5분 안에 끝)
- warehouse SQL 의 표현력 ↑ (window function, JSON 처리, UDF)
- compute 와 storage 분리 → 별도 scale

→ "데이터 일단 다 적재 후 SQL 로 transform" 이 cost-effective + 유연.

dbt (data build tool, 2016+):
- SQL + Jinja template + dependency graph
- "transform 만의 도구" — Extract/Load 는 Fivetran/Airbyte
- modern data stack 의 표준

Schema-on-Write vs Schema-on-Read

Schema-on-Write (ETL 시대):
- 데이터 load 전에 schema 확정
- type 안 맞으면 reject 또는 transform
- 장점: 데이터 quality 보장 + 빠른 query
- 단점: schema 변경 시 backfill 필요 + 새 field 추가 어려움

Schema-on-Read (data lake / ELT):
- 데이터 raw 그대로 저장 (JSON, CSV, Parquet)
- query 시점에 schema 해석
- 장점: 유연성 ↑, 새 field 도 자동 사용 가능
- 단점: query 가 느려질 수 있음, 데이터 quality 안전망 X

→ ELT 가 자주 schema-on-read.
   다만 dbt 의 model 이 schema 명시 + test → 어느 정도 best of both.

각 단계의 cost

단계ETLELT
Extract같음 (source 부담)같음
TransformETL server compute (수십~수백만/년)Warehouse compute (사용량 기반, 더 저렴)
Loadfinal 만 (storage ↓)raw + final (storage ↑, 그러나 $)
Re-transformExtract 다시 (비쌈)warehouse 안 SQL re-run (저렴)

ETL 이 여전히 승리하는 경우

  • compliance / PII — sensitive 데이터를 warehouse 에 raw 로 두기 위험. extract 시점에 masking 필요.
  • warehouse 에 source 데이터 못 보내는 환경 — on-prem / air-gapped / 외부 SaaS warehouse 금지 정책.
  • 실시간 streaming — Kafka Streams / Flink 가 stream 안에서 transform. ELT 의 batch 와 다른 path.
  • 전용 ETL ecosystem 이 이미 박힘 — Informatica / Talend 같은 enterprise ETL 도구 + 운영 인력 있는 곳.
  • raw data 너무 큼 — selective extract 필요 — warehouse 에 다 적재하면 cost 폭발. ETL 에서 column / row 미리 선택.

Modern Data Stack

정형 stack (2020+):

  Source (Postgres, MongoDB, Salesforce, Stripe, ...)
       ↓
  Extract + Load (Fivetran, Airbyte, Stitch)  ← schema 자동 + incremental
       ↓
  Warehouse (Snowflake / BigQuery / Redshift / Databricks)
       ↓
  Transform (dbt)  ← SQL + lineage + test + docs
       ↓
  Reverse ETL (Hightouch, Census) — warehouse → operational tool
  BI (Looker, Tableau, Metabase) — analyst / business
  ML (Snowpark, BigQuery ML) — 데이터 그 자리에서

→ "ELT" 가 stack 의 중심. ETL/ELT 도구가 commodity 된 상태.

흔한 함정

  • 모든 source 를 그대로 적재 — raw 가 너무 크면 warehouse cost 폭발. selective extract.
  • dbt 로 모든 logic — 단순 reporting 은 OK, 복잡 ML feature 는 별도 (Spark, dbt-fal).
  • schema-on-read 의 swamp — raw 무한 적재 + 누구도 관리 안 함 → "data swamp". metadata / catalog 필수.
  • ELT 의 cost 무시 — warehouse 의 compute 가 사용량 기반. transform job 의 cost / month 모니터링.
  • PII 그대로 적재 — GDPR 위반. extract 시점 masking 또는 separate audit.

마무리

ETL → ELT 의 전환은 단순 letter 순서 X — 클라우드의 cost 패러다임 (storage 저렴 + compute elastic) 이 가능하게 한 새 접근. modern data stack 의 standard.

실용 — 새 프로젝트 default: Fivetran/Airbyte (Extract+Load) + Snowflake/BigQuery (Warehouse) + dbt (Transform). 큰 enterprise 의 PII / compliance 영역만 ETL 일부 유지.

← 가이드 목록으로