ETL, ELT 데이터 파이프라인의 두 방식, 뭐가 다를까

ETL vs ELT. 데이터 파이프라인을 만들 때 가장 먼저 부딪히는 선택. "변환을 먼저 하느냐, 적재를 먼저 하느냐"의 차이가 전체 아키텍처를 바꾼다. 둘의 차이와 언제 무엇을 써야 하는지를 흐름도와 예제 코드로 정리한다.

---

들어가며

데이터 엔지니어링을 시작하면 가장 먼저 만나는 약어가 ETL과 ELT다. 글자 세 개의 순서만 다른데, 이게 데이터 파이프라인 전체의 모양을 바꾼다. 그리고 최근 몇 년 사이, 업계의 무게중심이 ETL에서 ELT로 옮겨가고 있다.

둘 다 데이터를 출처에서 가져와(Extract), 가공하고(Transform), 저장하는(Load) 과정이다. 차이는 단 하나, 변환(T)을 언제 하느냐다. 그런데 이 순서 하나가 비용·속도·유연성을 모두 좌우한다.

ETL은 "깨끗하게 가공한 뒤 저장"하고, ELT는 "일단 저장하고 나중에 가공"한다. 순서의 차이가 철학의 차이다.

이 글에서는 두 방식의 차이와 장단점, 그리고 언제 무엇을 골라야 하는지를 흐름도와 코드로 정리한다.

---

세 글자의 의미 — E, T, L

먼저 공통 재료부터 보자. 두 방식 모두 같은 세 단계로 이뤄진다.

단계	의미	하는 일
E (Extract)	추출	원본 소스(DB, API, 로그)에서 데이터를 가져온다
T (Transform)	변환	정제·가공·집계한다 (형식 통일, 중복 제거 등)
L (Load)	적재	목적지(DW, 데이터 레이크)에 저장한다

ETL과 ELT는 이 중 T와 L의 순서만 다르다. 그게 전부다. 그런데 그 결과는 꽤 다르다.

---

ETL — 변환 후 적재 (전통적 방식)

ETL은 데이터를 가공한 다음 저장한다. 추출 → 변환 → 적재 순서다.

ETL FLOW

원본에서 데이터를 꺼내, 별도의 처리 공간에서 깨끗하게 가공한 뒤, 최종 형태로 데이터 웨어하우스에 적재한다. 웨어하우스에는 이미 정제된 데이터만 들어간다.

# ETL: 변환을 먼저, 그 다음 적재 (개념 예시)
import pandas as pd

# 1. Extract — 원본에서 추출
raw = pd.read_csv("sales_raw.csv")

# 2. Transform — 적재 전에 가공
df = raw.dropna(subset=["amount"])           # 결측치 제거
df["amount"] = df["amount"].astype(int)       # 타입 변환
df["date"] = pd.to_datetime(df["date"])       # 날짜 파싱
df = df[df["amount"] > 0]                      # 이상치 제거
daily = df.groupby("date")["amount"].sum()     # 일별 집계

# 3. Load — 가공된 결과만 웨어하우스에 적재
daily.to_sql("daily_sales", warehouse_conn, if_exists="replace")

웨어하우스에는 daily_sales라는 이미 집계·정제된 테이블만 들어간다. 원본의 지저분한 데이터는 들어가지 않는다.

장점

• 웨어하우스에 깨끗한 데이터만 저장돼 조회가 빠르고 일관적이다.
• 민감 정보를 적재 전에 걸러낼 수 있어 규제·보안에 유리하다.
• 웨어하우스 저장 비용이 적다 (정제된 것만 넣으니까).

단점

• 변환 로직을 미리 다 정해야 한다. 나중에 "다른 형태로 보고 싶다"면 파이프라인을 다시 짜야 한다.
• 원본을 버리므로 나중에 다른 분석을 하기 어렵다.
• 별도 변환 서버·도구가 필요해 구조가 무겁다.

---

ELT — 적재 후 변환 (현대적 방식)

ELT는 순서를 뒤집는다. 일단 원본을 그대로 저장하고, 필요할 때 변환한다. 추출 → 적재 → 변환 순서다.

ELT FLOW

원본 데이터를 가공 없이 거의 그대로 데이터 웨어하우스(또는 레이크)에 먼저 쌓는다. 변환은 저장된 후에, 강력한 웨어하우스의 연산 능력을 이용해 SQL로 처리한다.

-- ELT: 원본을 먼저 적재한 뒤, 웨어하우스 안에서 SQL로 변환

-- 1. Extract + Load — 원본을 그대로 적재 (raw 테이블)
--    (적재는 Fivetran, Airbyte 같은 도구가 담당)

-- 2. Transform — 웨어하우스 안에서 SQL로 변환 (필요할 때)
CREATE TABLE daily_sales AS
SELECT
    DATE(created_at) AS date,
    SUM(amount) AS total
FROM raw_sales              -- 원본 그대로 쌓인 테이블
WHERE amount > 0
GROUP BY DATE(created_at);

원본(raw_sales)이 웨어하우스에 그대로 남아 있다. 그래서 나중에 "일별이 아니라 시간별로 보고 싶다"면, 파이프라인을 다시 짤 필요 없이 SQL만 새로 쓰면 된다.

장점

• 원본이 그대로 남아, 나중에 어떤 분석이든 다시 할 수 있다. (유연성)
• 적재가 단순해 파이프라인 구축이 빠르다.
• 변환을 웨어하우스의 강력한 연산으로 처리 → 대용량에 강하다.

단점

• 원본까지 다 저장하므로 저장 비용이 크다.
• 가공 전 데이터가 웨어하우스에 있어 거버넌스·보안 관리가 필요하다.
• 변환 안 된 데이터가 섞여 있어 정리 안 하면 혼란스러울 수 있다.

---

한눈에 비교

	ETL	ELT
순서	추출 → 변환 → 적재	추출 → 적재 → 변환
변환 위치	별도 처리 공간	웨어하우스 내부
저장 데이터	정제된 데이터만	원본 + 정제 데이터
유연성	낮음 (미리 정의)	높음 (나중에 변환)
저장 비용	적음	많음
구축 속도	느림	빠름
적합한 경우	정제·보안 우선, 정형 데이터	대용량, 유연한 분석, 클라우드 DW

---

왜 요즘은 ELT로 기우나

예전엔 ETL이 표준이었다. 저장 공간이 비쌌기 때문이다. 그래서 "꼭 필요한 정제된 데이터만" 저장하는 ETL이 합리적이었다.

그런데 클라우드 데이터 웨어하우스(Snowflake, BigQuery, Redshift)가 등장하며 판이 바뀌었다.

• 저장 비용이 싸졌다 → 원본을 다 쌓아도 부담이 적다.
• 웨어하우스 연산이 강력해졌다 → 변환을 굳이 밖에서 안 하고 안에서 SQL로 처리하면 된다.
• 분석 요구가 빨리 바뀐다 → 원본을 남겨두면 새 요구에 SQL만 바꿔 대응할 수 있다.

이 세 가지 변화가 ELT를 현대 데이터 스택의 기본값으로 만들었다. dbt 같은 도구가 "웨어하우스 안에서의 변환(T)"을 전담하며 ELT 생태계가 커졌다.

한 줄 요약: 저장이 싸지고 연산이 강해지자, "일단 다 쌓고 나중에 가공"하는 ELT가 합리적이 됐다.

---

그래서, 무엇을 써야 하나

현실적인 선택 기준은 이렇다.

ETL이 맞는 경우

• 민감 정보를 적재 전에 반드시 걸러야 할 때 (의료·금융 규제)
• 데이터 형태가 명확하고 변환 규칙이 안정적일 때
• 온프레미스 환경이거나 저장 비용을 빡빡하게 관리해야 할 때

ELT가 맞는 경우

• 클라우드 데이터 웨어하우스를 쓸 때 (대부분의 신규 프로젝트)
• 분석 요구가 자주 바뀌고 유연성이 중요할 때
• 데이터가 대용량이고 비정형이 섞여 있을 때

대부분의 새 프로젝트는 클라우드 DW 위에서 ELT로 시작하는 게 요즘 흐름이다. 다만 "무조건 ELT"가 아니라, 규제나 보안 때문에 적재 전 정제가 필요하면 ETL이 여전히 답이다. 둘을 섞어 쓰기도 한다.

---

마치며

ETL과 ELT는 우열의 문제가 아니라 순서의 선택이고, 그 선택은 환경에 따라 달라진다. 저장이 비싸고 정제가 우선이면 ETL, 저장이 싸고 유연성이 우선이면 ELT다. 그리고 클라우드가 보편화된 지금은 그 무게중심이 ELT로 기울어 있다.

핵심은 약어를 외우는 게 아니라, "변환을 언제 하는가"가 비용·유연성·보안을 어떻게 바꾸는지 이해하는 것이다. 그걸 알면 "우리 상황엔 뭐가 맞지?"라는 질문에 스스로 답할 수 있다. 데이터 파이프라인 설계의 첫 단추가 바로 이 선택이다.

---

참고 출처

• AWS: ETL vs ELT — https://aws.amazon.com/compare/the-difference-between-etl-and-elt/
• dbt: What is ELT? — https://www.getdbt.com/blog/etl-vs-elt
• Fivetran: ETL vs ELT — https://www.fivetran.com/blog/etl-vs-elt