언제 ETL을 쓰고 언제 ELT를 선택해야 하는가

ETL보다 ELT가 대세가 된 가장 근본적인 이유는 ‘데이터 환경 전체의 경제 구조와 역할 분담이 바뀌었기 때문’입니다.
클라우드 기반 Compute/Storage 분리, Cloud economics(비용 구조), 그리고 SQL 기반 transformation 문화(dbt 등)가 한 번에 맞물리면서, “먼저 데이터를 제대로 변환해서 옮기는 ETL”이 아니라 “먼저 데이터를 쌓아 두고, 필요할 때마다 다시 변환하는 ELT”가 더 효율적이고 생산적인 패턴이 된 것입니다. 

 

아래 내용은 요청하신 키워드 3가지(Compute/Storage 분리, Cloud economics, SQL 기반 transformation 문화)를 중심轴으로, ELT가 대세가 된 배경·실제 아키텍처 변화·실무적 장단점까지 넓게 다루도록 구성했습니다. 모두 SEO 최적화 블로그 문장 수준으로 길고 자세하게 전개했습니다.

언제 ETL을 쓰고 언제 ELT를 선택해야 하는가

---

1. ETL과 ELT의 기본 개념과 차이점

ETL: 옛날 데이터 세상의 표준 패턴

전통적인 ETL(Extract‑Transform‑Load)은 데이터를 원천 시스템에서 추출 → 별도 ETL 서버/도구에서 변환 → 변환된 결과만 데이터 웨어하우스에 적재하는 방식입니다. 이는 온‑프레미스(On‑premises) 데이터베이스나 물리적 웨어하우스(Appliance) 시절에 최적화된 설계였습니다. 그 당시 웨어하우스 스토리지는 비싸고 컴퓨트(쿼리)는 한정적이었기 때문에, “필요한 데이터만 미리 잘 다듬어서 넣는 것”이 비용 효율적이었습니다. 

 

또한 ETL은 데이터 품질을 적재 전에 정리하는 장점이 있어, 데이터 마트나 BI 리포트 입장에서는 “안정적이고 깨끗한” 테이블을 얻을 수 있었습니다. 대신, 데이터 스키마나 요구사항이 바뀔 때마다 ETL 파이프라인을 다시 수정하고 재실행해야 해서, 유연성과 반복 사용성이 떨어졌습니다. 

ELT: “먼저 쌓고, 나중에 변환하라”

ELT(Extract‑Load‑Transform)는 순서를 뒤집습니다. 먼저 원시(raw) 데이터를 추출해 데이터 웨어하우스나 데이터 레이크에 적재한 뒤, 목적지 내부에서 SQL 등으로 변환합니다. 즉, 변환이 목표 저장소 안에서 일어나는 구조입니다. 이는 클라우드 네이티브 데이터 웨어하우스(Snowflake, BigQuery, Redshift, Synapse 등)와 빅데이터 환경에서 자연스럽게 발전한 패턴입니다. 

 

ELT는 특히 대용량 데이터(batch·stream 혼합), 다양한 스키마( semi‑structured, JSON, Parquet 등)를 다룰 때 빛이 나는 구조입니다. 스토리지에 원본을 보존해 두면, 분석 요구사항이 바뀌더라도 원본을 다시 변환할 수 있어 “일회성 정제”가 아닌 반복 가능한 변환 파이프라인을 만들 수 있습니다. 

---

2. Compute/Storage 분리가 만든 구조적 변화

클라우드 데이터 웨어하우스의 구조적 전환

클라우드 네이티브 데이터 웨어하우스는 Compute layer와 Storage layer를 분리 설계합니다. 예를 들어 Snowflake, BigQuery, Redshift Serverless 등은

• 스토리지는 객체 저장소(예: S3, GCS) 위에 구축되어 저렴하게 확장 가능
• 컴퓨트는 Cluster/Query Engine으로, 필요할 때만 올려서 쿼리 실행

이렇게 되면서 “원시 데이터를 저장하는 것” 자체가 비용 부담이 줄어들었습니다. 예전처럼 “저장 면적을 줄이기 위해 즉시 변환해서 버리는 방식”이 아니라, Raw zone → Staged/Enriched zone → Business zone으로 나누어 두는 Multi‑layer 레이크하우스 아키텍처가 보편화되었습니다. 

ELT가 가능해진 구조적 이유

이러한 분리 덕분에 아래와 같은 구조가 가능해졌습니다.

• Extract: 소스 데이터(ERP, CRM, SaaS 앱, 로그 파일 등)를 Low‑code ELT 도구(Fivetran, Stitch, Airbyte 등)로 바로 데이터 웨어하우스로 적재
• Load: 변환 없이 원시 데이터를 Raw 테이블에 적재
• Transform: 데이터 웨어하우스 내부에서 SQL로 Staging, Enrich, Aggregation, Modeling 수행

이 구조는

• 원본 데이터를 그대로 유지해 재처리와 애널리틱스 재설계가 쉬움
• 변환 단계를 데이터 웨어하우스의 컴퓨트 리소스에 분산시켜 성능을 끌어올리는 것

두 가지 이점을 동시에 줍니다. 

---

3. Cloud economics가 미친 결정적 영향

스토리지·컴퓨트의 비용 구조 변화

클라우드 상에서는 스토리지와 컴퓨트가 각각 다른 과금 모델로 분리됩니다. 예를 들어

• 스토리지: GB 단위의 저렴한 과금(예: BigQuery Coldline, S3 Standard)
• 컴퓨트: Query 단위 또는 vCPU/시간 단위 과금(예: Snowflake credit, BigQuery BQ slot)

이로 인해 다음 전략이 가능해졌습니다.

1. 원시 데이터를 대량으로 저비용 저장
2. 변환·집계는 필요할 때만 컴퓨트를 올려서 수행

즉, 데이터를 먼저 쌓아 두고, “쿼리 시점”이나 “스케줄된 배치 시점”에 컴퓨트를 쓰는 방식이 경제적으로 더 효율적인 셈입니다. 결과적으로 ETL처럼 전용 서버/VM에서 변환하는 것보다, 웨어하우스 내부에서 ELT로 변환하는 것이 운영 비용·인프라 관리 비용 면에서 우위에 서게 되었습니다. 

유연한 확장과 TCO 관점

또한, 클라우드는 컴퓨트를 탄력적으로 확장할 수 있어, ELT 작업이 증가할수록 “정지 상태의 서버를 미리 사두는 것” 대신 “필요할 때만 늘리는 것”으로 바뀌었습니다.

• 예전: ETL 전용 서버를 항상 켜 두어 비어 있는 time slot이 생김
• 지금: 웨어하우스 컴퓨트를 필요 시점에만 올려서 사용

이런 구조는 Capex(거액 선투자) 중심의 온‑프레미스 모델에서 OPEX(사용량 기반) 모델로 전환된 현대 데이터 스택의 핵심입니다. 

---

4. SQL 기반 transformation 문화의 등장

ETL 시대의 변환 방식 한계

전통적인 ETL은 대개 프로시저형 코드(Java, Python, Talend, Informatica 등)로 변환 로직을 작성했습니다. 이런 방식의 문제점은

• 분석가나 B Advanced SQL 사용자들이 직접 수정하기 어렵고
• 코드가 유지보수·공유·테스트에 취약하며
• 버전 관리와 테스트도 별도 관행이 필요해졌다

이는 결국 데이터 엔지니어와 분석가 사이에 “데이터 전처리 게이트” 역할을 만들고, 요구사항이 바뀔 때마다 파이프라인을 다시 만드는 번거로움을 초래했습니다. 

ELT와 SQL 모델링의 결합

ELT가 본격적으로 확산된 계기는 SQL 중심의 transformation 도구(dbt 등)가 등장하면서부터입니다. dbt(Common acronym: data build tool)는

• SQL SELECT 문을 모델(Model)로 정의하고
• 의존성 그래프를 자동으로 관리하며
• 테스트, 문서화, Version Control 등 개발 관행을 SQL 층에 적용하는 도구입니다.

-- 예시: dbt 모델(Staging에서 Business 모델 생성)
SELECT
    user_id,
    first_name,
    last_name,
    COALESCE(email, '<anonymous>') AS email,
    created_at,
    DATE_TRUNC(created_at, 'month') AS signup_month
FROM raw.stg_users
WHERE is_deleted = FALSE

 

이처럼 ELT + SQL 모델링은

• 변환 코드를 plain SQL로 작성해 많은 분석가들이 직접 수정 가능하도록 하고
• CI/CD, Git, Testing, Documentation을 데이터 라이프 사이클에 통합함으로써
• 데이터 품질과 생산성을 동시에 끌어올리는 구조를 만들었습니다.

---

5. ELT가 대세가 된 또 다른 4가지 이유

5‑1. 데이터 레이크와 데이터 레이크하우스의 부상

• 온‑프레미스 시절에는 “데이터 레이크”가 단순히 빅데이터 저장소에 불과했지만, 클라우드에서는 Delta Lake, Iceberg, Hudi 같은 포맷과 결합해 데이터 레이크하우스 구조로 진화했습니다.
• 이 구조는 데이터를 원시 zone에 쌓아 두고, 필요에 따라 SQL 변환으로 비즈니스 모델을 생성하는 방식을 자연스럽게 지원합니다.
• 결과적으로 ELT는 이러한 아키텍처와 완전히 호환되는 표준 패턴이 되었습니다.

5‑2. Self‑service 분석과 데이터 팀의 권한 분산

• ELT는 데이터를 먼저 웨어하우스에 적재해 두기 때문에, 분석가나 마케터 등 “비 기술자”가 쿼리를 직접 작성하거나 프로토타입 모델을 만들 수 있습니다.
• 반대로 ETL은 변환 단계가 ETL 서버에 격리되어 있어, 분석가가 직접 수정하거나 실험하기 어렵습니다.
• 이로 인해 ELT는 Self‑service analytics, Data Democratization을 실현하는 데 유리한 구조로 자리 잡았습니다.

5‑3. 실시간·Near‑real‑time 분석 수요

• ELT는 변환을 쿼리 시점이나 배치 주기에 맞춰서 수행할 수 있어, 실시간·Near‑real‑time 분석에 더 잘 맞습니다.
• 예를 들어 스트리밍 데이터를 카프카/파이프라인으로 적재한 뒤, 데이터 웨어하우스에서 Incremental ELT 또는 dbt incremental 모델로 변환하는 패턴이 보편화되었습니다.
• 이는 전통적인 배치 ETL보다 latency를 줄이고, 데이터 freshness를 높이는 쪽으로 이어집니다.

5‑4. 공통 도구 생태계와 표준화

• Fivetran, Stitch, Airbyte, Matillion, dbt, Snowflake, BigQuery 등 여러 도구가 ELT 패턴을 기반으로 호환되도록 설계되었습니다.
• 이 결과, 새로운 팀이 데이터 파이프라인을 설계할 때 기본적으로 ELT를 선택하고, “왜 ELT를 쓰는가?” 보다는 “어떤 ELT 도구를 조합할 것인가?”에 더 집중합니다.
• 이렇게 표준화된 패턴은 ELT가 실제 업계 표준으로 자리 잡는 데 큰 역할을 했습니다.

---

6. ELT의 장단점과 언제 ELT를 선택해야 하는지

ELT의 장점

1. 원시 데이터 보존과 재처리 가능성
   • 원본을 유지해 두면 요구사항 변경 시 다시 변환(model 재구성)이 쉽고, 레거시 모델과 새 모델을 병행할 수 있다.
2. 개발 및 운영 효율성
   • SQL 기반 모델링, dbt 같은 도구로 인해 버전 관리, 테스트, 문서화가 단순해지고, 코드 품질이 높아집니다.
3. 클라우드 경제성과 확장성
   • 컴퓨트를 필요할 때만 사용해 전체 TCO(총 소유 비용)를 줄일 수 있고, 데이터 규모가 커져도 구조를 쉽게 확장할 수 있습니다.
4. Self‑service 분석 촉진
   • 데이터를 먼저 적재해 두면 분석가가 직접 쿼리·모델을 만들 수 있어, 데이터 팀의 생산성과 의사결정 속도를 높입니다.

ELT의 단점

1. 초기 데이터 품질 관리
   • 원본을 그대로 저장하기 때문에, 필터링·cleansing이 제대로 되지 않으면 찌꺼기 데이터가 웨어하우스에 쌓일 수 있습니다.
2. 변환 책임의 이동
   • 변환이 웨어하우스 안으로 이동하면서, 데이터 웨어하우스 쿼리 비용과 성능 관리가 더 중요해집니다. 잘못 설계된 모델은 비용 폭등을 유발할 수 있습니다.

어느 경우에 ELT를 선택하는 것이 좋은가

• 대용량 데이터, 여러 스키마, 분석 목적
  • 웹 로그, IoT, 앱 이벤트, CRM/ERP 데이터를 분석 목적 중심으로 모으는 경우 ELT가 자연스럽게 적합합니다.
• 빠른 요구사항 변경
  • 마케팅, 제품, BI 팀이 자주 요구사항을 바꾸는 환경이라면, ELT + SQL 모델링이 반복 사용과 재구성을 용이하게 합니다.
• 클라우드 기반 Modern Data Stack을 채택하는 팀
  • Snowflake/BigQuery/Redshift + Fivetran/Airbyte + dbt 구조를 사용하는 팀은 ELT가 기본 선택지입니다.

반대로

• 실시간·저지연 트랜잭션 처리, 고정 스키마, 중앙 집중형 데이터 마트처럼 구조가 매우 안정적이고, 데이터 품질이 가장 중요한 상황에서는 ETL이나 ETL/ELT 혼합이 더 적합할 수 있습니다.

---

7. 실제 사례와 실무 팁

Modern Data Stack 사례 구조

• Extract & Load: Fivetran 또는 Airbyte로 SaaS 앱, 데이터베이스 데이터를 Snowflake/BigQuery에 적재
• Raw Layer: 각 소스를 원시 형태로 테이블로 저장
• Transform Layer: dbt로 스테이징, 중간 테이블, 집계 테이블을 정의
• Orchestration: Airflow 또는 Prefect로 ELT 파이프라인을 스케줄링

이 구조는 ETL과 ELT를 섞어 쓰는 Hybrid 아키텍처로도 확장 가능합니다. 예를 들어

• 실시간 이벤트는 Kafka/Spark로 중간 처리 후,
• 그 결과는 ELT로 웨어하우스에 적재하는 방식이 대표적입니다. 

ELT 도입 시 실무 팁

1. 데이터 레이어링 정책 수립
   • Raw → Staged → Business 또는 Data Vault → Star Schema 등으로 레이어를 명확히 정의
2. 데이터 품질 관리 강화
   • dbt 테스트, 데이터 카탈로그(예: Atlan, DataHub)를 사용해 스키마 변경·데이터 품질을 모니터링
3. 비용 관리
   • 쿼리 비용을 모니터링하고, 불필요한 중복 모델이나 상시 실행 배치를 최적화

이러한 관행은 ELT가 단순히 “ETL 대체”가 아니라, 데이터 문화 자체를 바꾸는 수준의 변화임을 보여줍니다.