01. ETL과 ELT 차이 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• ETL과 ELT는 변환 위치와 원천 보존 방식에서 어떻게 다른가?
• raw 데이터를 먼저 적재하면 재처리와 장애 대응이 어떻게 쉬워지는가?
• Java/Spring 백엔드 데이터가 pipeline으로 나갈 때 어떤 방식을 선택해야 하는가?
• 개인 프로젝트에서 ETL/ELT 차이를 작게 실습하려면 무엇을 남겨야 하는가?

개요

ETL은 Extract, Transform, Load 순서다.

원천에서 데이터를 뽑고, 중간 처리 계층에서 변환한 뒤, target 저장소에 적재한다.

ELT는 Extract, Load, Transform 순서다.

원천 데이터를 raw 또는 staging에 먼저 적재하고, warehouse 같은 저장소 안에서 변환한다.

둘의 차이는 단어 순서보다 원천 데이터를 어디까지 보존하고 어느 위치에서 계산할지의 차이다.

원리

ETL은 target에 들어가기 전에 데이터를 정리한다.

ELT는 원천을 먼저 보존한 뒤 여러 transform을 적용한다.

raw가 남아 있으면 transform 버그를 고친 뒤 과거 데이터를 다시 계산할 수 있다.

raw가 없으면 원천 DB에서 다시 추출해야 하고, 그 사이 source가 바뀌었을 수 있다.

비교

구분	ETL	ELT
순서	추출 → 변환 → 적재	추출 → 적재 → 변환
raw 보존	선택적	중요
계산 위치	애플리케이션, Spark, worker	warehouse, query engine
장점	target 정리 후 적재	재처리와 추적 쉬움
위험	transform 오류 시 원천 재추출 필요	raw 저장 비용과 governance 필요
적합	작은 target, 강한 정제 필요	분석, warehouse, 반복 mart

현대 분석 파이프라인은 ELT 성격이 강한 경우가 많다.

하지만 모든 상황에서 ELT가 정답은 아니다.

ETL 예시

orders table
  -> batch worker reads rows
  -> Java code converts status, amount, category
  -> fact_order_daily table insert

이 방식은 구조가 단순하다.

그러나 변환 코드에 버그가 있으면 이미 적재한 target을 어떻게 고칠지 고민해야 한다.

원천 raw를 남기지 않았다면 다시 운영 DB에서 같은 범위를 읽어야 한다.

ELT 예시

orders table
  -> extract by updated_at
  -> raw.orders/ds=2026-06-30 저장
  -> staging.orders 정규화
  -> fact_order_payment 생성
  -> mart_sales_daily 생성

ELT는 raw를 먼저 보존한다.

나중에 mart logic을 고쳐도 raw 또는 staging부터 다시 계산할 수 있다.

분석 요구가 자주 바뀌고 과거 재계산이 필요하면 ELT가 유리하다.

Spring 백엔드 관점

백엔드 서비스는 warehouse 도구를 직접 운영하지 않더라도 source 계약을 제공해야 한다.

• 어떤 table 또는 event가 원천인가
• 어떤 timestamp로 증분 추출할 것인가
• 삭제와 취소는 어떻게 표현되는가
• schema 변경은 언제 발생하는가
• 같은 row를 다시 추출하면 target이 안전한가

ETL/ELT 선택은 데이터 팀만의 문제가 아니다.

원천 의미를 모르면 어느 방식이든 잘못된 데이터를 빠르게 옮길 뿐이다.

판단 축

• 과거 재계산이 자주 필요하면 raw 보존을 우선한다.
• target 저장소가 작고 정제 결과만 필요하면 ETL도 충분하다.
• source가 자주 바뀌면 raw와 schema version을 남긴다.
• transform 비용이 warehouse에서 처리하기 적합하면 ELT를 검토한다.
• 개인정보와 보관 정책이 엄격하면 raw 보존 범위를 신중하게 정한다.

실패 모델

• ETL worker에서 금액 변환 버그가 났는데 raw가 없어 운영 DB를 다시 읽어야 한다.
• raw는 저장했지만 schema version이 없어 과거 파일을 해석하지 못한다.
• ELT로 raw를 모두 쌓았지만 개인정보 보관 정책을 정하지 않았다.
• transform 결과만 검증하고 extract 누락을 확인하지 않는다.
• target mart를 고친 뒤 같은 logic으로 다시 만들 수 없다.

운영 지표

• raw_ingest_count: raw에 적재한 row 수다.
• source_extract_count: source에서 추출한 row 수다.
• transform_failure_count: 변환 단계 실패 수다.
• raw_replay_count: raw부터 다시 계산한 횟수다.
• warehouse_compute_cost: ELT transform 비용이다.
• raw_retention_days: raw 보관 기간이다.

품질 검증

SELECT COUNT(*) AS source_count
FROM orders
WHERE updated_at >= TIMESTAMP '2026-06-30 00:00:00'
  AND updated_at < TIMESTAMP '2026-07-01 00:00:00';

SELECT COUNT(*) AS raw_count
FROM raw_orders
WHERE ds = DATE '2026-06-30';

ETL이든 ELT든 source와 raw 또는 target count 비교가 출발점이다.

개인 프로젝트 기준

개인 프로젝트에서는 같은 DB 안에 raw_orders, fact_order_payment, mart_sales_daily를 둬도 된다.

ELT를 흉내 내고 싶다면 운영 table에서 raw table로 먼저 복사하고, 그 raw table에서 fact를 만든다.

핵심은 transform 버그가 났을 때 운영 table이 아니라 raw부터 다시 만들 수 있는지다.

기업 운영 기준

기업 운영에서는 raw 보관 기간과 접근 권한이 중요하다.

raw에는 운영 데이터가 거의 그대로 들어올 수 있다.

개인정보, 암호화, 마스킹, 삭제 요청 대응을 함께 설계해야 한다.

또한 raw부터 mart까지 lineage를 남겨야 장애 영향 범위를 추적할 수 있다.

실전 팁

• ETL/ELT 선택 전에 재계산 요구와 raw 보관 정책을 묻는다.
• raw를 저장한다면 source schema version과 extract time을 함께 남긴다.
• transform 결과만 저장하지 말고 입력 범위와 output count를 기록한다.
• 개인정보가 많은 raw는 접근 권한을 target mart보다 좁힌다.
• 작은 프로젝트도 raw 또는 staging table을 하나 두면 학습 효과가 크다.

위험 신호!

• ETL과 ELT를 도구 브랜드 차이로만 설명한다.
• transform 버그가 나면 운영 DB를 다시 긁는 방법뿐이다.
• raw 저장소는 있지만 누가 볼 수 있는지 정해져 있지 않다.
• source count와 target count를 비교하지 않는다.
• mart logic이 바뀌었는데 과거 데이터를 다시 계산할 방법이 없다.

확인 질문

확인 질문

• ETL과 ELT의 핵심 차이는 무엇인가?
  • 변환을 target 적재 전에 할지, raw를 먼저 저장한 뒤 저장소 안에서 변환할지의 차이다.
• raw 데이터를 보존하면 어떤 운영 이점이 있는가?
  • transform 버그 수정 후 과거 데이터를 같은 원천으로 다시 계산할 수 있다.
• ELT가 항상 정답이 아닌 이유는 무엇인가?
  • raw 저장 비용, 개인정보 보관, 접근 권한, warehouse 계산 비용이 함께 생기기 때문이다.

참고 문서

• AWS Analytics Guidance
• Google Cloud Architecture Center, Data warehouse
• dbt Documentation
• Martin Kleppmann, Designing Data-Intensive Applications