ETL vs ELT: 어떤 상황에서 무엇을 선택해야 할까

🎯 들어가며

데이터를 다루다 보면 “ETL이 좋다”, “ELT가 요즘 표준이다” 같은 말을 자주 듣습니다.
하지만 중요한 건 복잡한 기술용어보다,
“우리 상황에서 어떤 방식을 써야 할까?” 라는 현실적인 관점입니다.

 

ETL과 ELT는 결국

데이터를 어디에서 가공하느냐의 차이일 뿐이다.

---

ETL: 가져오기 전에 ‘가공’부터 하는 방식

Extract → Transform → Load

• 데이터를 가져와서(Extract)
• 변환하고(Transform)
• 정제된 상태로 저장소에 넣는 방식(Load)

ETL의 특징

• 변환을 서버(중간 레이어)에서 수행
• 스키마가 명확하고 구조화된 데이터에 유리
• 데이터 정합성을 강하게 보장

이런 경우 ETL이 적합

• 운영 DB(OLTP)처럼 구조가 엄격해야 하는 환경
• 데이터가 많지 않아서 중간 처리로도 충분할 때
• 변환 로직을 엄격히 통제해야 할 때

---

ELT: 일단 ‘모아서’ 처리하는 방식

Extract → Load → Transform

• 데이터를 먼저 저장소에 넣고(Load)
• 그 안에서 필요한 변환을 수행(Transform).

ELT의 특징

• 변환을 데이터 웨어하우스(BigQuery, Snowflake 등) 내에서 처리
• 계산 성능을 클라우드가 대신 맡아 효율적
• 반복적 변환·분석에 최적화

이런 경우 ELT가 적합

• 데이터가 많고, 변환 비용이 큰 경우
• 분석 DB(OLAP) 중심으로 운영되는 팀
• dbt 같은 변환 도구를 활용할 때

---

스타트업의 현실적인 선택 기준

✔ 데이터가 적다 → ETL도 충분

초기 회사에서는 데이터가 많지 않고,
변환 로직도 단순한 경우가 많습니다.
이때는 가볍게 ETL만으로도 모든 작업이 가능합니다.

✔ 데이터가 늘어나고 분석이 중요해진다 → ELT가 더 자연스러움

데이터가 쌓이면

• 대시보드
• 지표
• 퍼널
• 리텐션 분석 등이 필요해지고,
  이때부터는 데이터를 ‘창고(BigQuery)’에 몰아넣고 변환하는 ELT 구조가 훨씬 유리합니다.

✔ 정답은 혼합(Hybrid)

초기: ETL (간단한 전처리)
후기: ELT (dbt로 변환·모델링)

대부분의 회사는 결국 이렇게 혼합 구조를 사용하게 됩니다.

---

ETL/ELT와 잘 어울리는 대표 기술 스택

기술명만 나열해도 실무 감각이 확 살아나는 부분이고, 독자도 “아 이런 구조로 연결되는구나”를 이해할 수 있습니다.

 

ETL에 많이 쓰는 도구

• Airflow
• AWS Glue
• Talend
• Apache NiFi

ELT에 많이 쓰는 도구

• dbt (가장 대표적)
• BigQuery/Snowflake 내부 SQL 변환
• Databricks Lakehouse

---

결국 중요한 건 ‘도구’보다 ‘흐름’

ETL이든 ELT든 중요한 건 하나입니다.

데이터가 어떻게 들어오고, 어떻게 변화하고, 어떻게 활용되는지 흐름이 정리돼 있는가?

도구는 바뀌어도
흐름(파이프라인)이 명확하면 분석·자동화·대시보드 구축이 모두 쉬워집니다.

---

☕ 마무리하며

ETL과 ELT는 경쟁 개념이 아니라,
데이터의 양과 목적에 따라 선택하는 처리 전략입니다.

• 적을 때는 ETL이 단순하고 빠르고,
• 많아지면 ELT가 안정적이고 확장된다.

그리고 대부분의 회사는 둘을 적절히 섞어 사용합니다.