ELT vs ETL 언제 사용하면 좋을까?

ETL vs ELT

https://yandex.cloud/en/blog/posts/2025/03/etl-vs-elt?utm_source=chatgpt.com&utm_referrer=https%3A%2F%2Fchatgpt.com%2F

 

ETL (Extract - Transform - Load)

소스에서 데이터를 추출하고 사전에 데이터를 변환한 후, 데이터베이스에 로드하는 프로세스

• Extract (HTTP 요청 등..)
• Transform (python 스크립트 등을 활용해 로컬에서 데이터 변환)
• Load (로컬 DB 등에 로드)

 

ETL은 어떤 상황에 쓰기 좋을까?

적합한 상황	예시
✔ 레거시 환경 또는 규제/컴플라이언스가 중요한 경우 ✔ 데이터 품질과 일관성을 사전에 엄격하게 관리해야 할 때 ✔ 데이터가 주로 **정형(structured)**이고, 스키마가 자주 변경되지 않을 때 ✔ 변환 로직이 복잡하고 미리 정제된 데이터를 필요로 할 때	- 금융/헬스케어 업계처럼 민감 데이터 사전 검증이 중요한 경우 - 데이터 웨어하우스로 보고용 정제 데이터를 꾸준히 공급해야 할 때

 

 

ELT (Extract - Load - Transform)

소스에서 데이터를 추출하고 먼저 타겟 DB에 로드한 후에 타겟 저장소내에서 변환하는 프로세스

- Extract (HTTP 요청 등..)

- Load (Google Cloud Storage 등에 로드)

- Transform (Bigquery 등 데이터 웨어하우스에서 클라우드 성능을 활용해 변환)

 

 

 

ELT는 어떤 상황에 쓰기 좋을까?

적합한 상황	예시
✔ 클라우드 기반의 빅데이터 아키텍처 ✔ 대용량 데이터, 반정형/비정형 데이터를 빠르게 적재해야 하는 경우 ✔ 실시간 또는 거의 실시간 데이터 분석이 필요한 환경 ✔ 데이터 사이언티스트나 분석팀이 raw 데이터를 기반으로 다양한 분석을 진행할 때	- Snowflake, BigQuery, Redshift 같은 MPP 기반 저장소 활용 - 데이터 레이크에 raw 데이터를 저장 후 필요 시 변환하여 분석

 

 

 

정리하면 ..

항목	ETL	ELT
데이터 품질 관리	우수 – 사전 변환으로 error/정합성 보장	낮음 – raw 상태로 로드되므로 품질 제어는 나중에
처리 속도 & 로딩 대기 시간	느림 – 변환 후 로딩 → 지연 발생 가능	빠름 – 데이터 바로 로딩 → on-demand 변환 가능
데이터 형식 지원	mostly structured only	structured / semi-structured / unstructured
스케일 & 비용	사전 처리 서버 필요 → 비용 증가 가능	클라우드 MPP 활용 → 확장성과 비용 효율성 유리
유연성	낮음 – 사전 결정된 스키마 중심	높음 – 필요 시 다양한 변환 적용 가능
복잡성	높음 - ETL tool 관리 및 transformation process로 인한 복잡성 증가	낮음 - transformation이 타겟 DB에서 이뤄지므로 상대적으로 단순함

 

 

---

Kestra에서 실행속도 비교하기 (ETL : pgdatabase / ELT : bigquery)

아래 영상에선 Kestra workflow orchestration을 통해 같은 일을 수행하는 task를 ETL, ELT로 각각 수행하는 실험을 수행함.

> 실행 속도 측면에서 ELT 가 승!

> ETL의 경우 transform을 로컬에서 하는 반면, ELT는 Bigquery에서 하기에 효율적으로 처리가 가능하기 때문.

https://www.youtube.com/watch?v=VxOmetLBTxE

 

ETL - 2m 15s 소요

 

 

ELT - 1m 40 s 소요

 

 

---

참고자료

ETL vs ELT: Choosing the right approach for your data integration needs

https://www.youtube.com/watch?v=VxOmetLBTxE