ETL이란 무엇인가 — Extract-Transform-Load의 원칙과 한계
ETL vs ELT vs Zero ETL: What's Actually Different (2026) — DataVidhya (blog) What Is ETL in Data Engineering? / When ETL Works Best / Limitations (pp.2-4); ETL vs ELT: The Real Difference — What is ETL? (pp.2-3)
이 모듈을 다 읽으면
- ETL에서 순서(Extract→Transform→Load)가 왜 의도적인지 설명할 수 있다
- ETL이 저장 비용이 비쌌던 시절의 제약에서 비롯된 접근임을 설명할 수 있다
- ETL이 유리한 상황과 구조적 한계를 구분할 수 있다
ETL은 데이터를 소스에서 추출한 뒤 정제·재구성을 마치고 나서야 웨어하우스에 적재하는, 순서 자체가 의도적인 접근이다. 스토리지가 비쌌던 시절 '필요한 것만 저장한다'는 제약에서 비롯되었으며, 규제·마스킹·엄격한 스키마가 필요한 상황에는 여전히 강력하지만, 비즈니스 로직이 자주 바뀌는 환경에서는 재처리가 소스 재추출을 요구해 유연성이 떨어진다.
Extract, Transform, Load — 순서가 의도적인 이유
ETL은 Extract, Transform, Load의 약자이며 이 순서는 의도적이다. 먼저 애플리케이션·운영 데이터베이스·서드파티 API 같은 소스 시스템에서 데이터를 추출한다. 그다음 분석 시스템에 적재되기 전에 정제·필터링·조인·재구성을 거친다 — 불필요한 레코드를 제거하고, 새 지표를 계산하고, 신용카드 번호 같은 민감 정보를 마스킹하는 작업이 이 단계에서 일어난다. 중요한 것은 이 변환 작업이 데이터가 웨어하우스에 도달하기 전에, 별도의 처리 서버에서 일어난다는 점이다. 마지막으로 정제되어 사용 준비가 끝난 데이터만 웨어하우스에 적재한다.
이 접근이 인기를 끈 이유는 데이터 웨어하우스가 비싸고 확장이 어려웠던 시절의 제약 때문이다. 20년 전에는 하드디스크와 서버가 매우 비쌌기 때문에 기업들은 쓸모없거나 지저분한 데이터(비유하자면 '감자 껍질')를 비싼 웨어하우스에 저장하는 비용을 감당하려 하지 않았다. 오직 리포트에 필요한 것만 정확히 저장하고 싶어했다 — 그래서 채소를 매장 주차장에서 미리 다듬어 껍질은 버리고 필요한 부분만 집으로 가져오는 방식에 비유할 수 있다.
핵심 포인트
- ETL은 소스에서 추출한 데이터를 웨어하우스에 도달하기 전, 별도의 처리 서버에서 정제·마스킹·재구성까지 마친 뒤에야 적재한다.
- ETL이 널리 쓰인 근본 이유는 과거 스토리지·서버 비용이 비싸 '필요한 정제된 데이터만' 저장해야 했던 제약 때문이다.
ETL이 유리한 상황과 한계
ETL은 저장 전에 데이터를 정제하거나 마스킹해야 하는 경우, 스키마가 엄격하고 거의 바뀌지 않는 경우, 규제·컴플라이언스 요구가 강한 경우, 스토리지 비용을 엄격히 통제해야 하는 경우에 유용하다. 은행·병원처럼 GDPR/HIPAA 같은 규제를 따라야 하거나 오래된 레거시 메인프레임에서 최신 시스템으로 데이터를 옮기는 상황이 대표적이다 — PII는 법적으로 클라우드에 그대로 저장할 수 없으므로 서버를 떠나기 전에 반드시 마스킹되어야 하고, 완전히 다른 데이터 구조를 새 시스템에 맞게 재구성해야 하기 때문이다.
반면 ETL 파이프라인은 비즈니스 로직이 자주 바뀔 때 어려움을 겪는다. 변환이 적재 이전에 일어나기 때문에, 데이터를 재처리하려면 대개 소스 시스템에서 다시 데이터를 가져와야 하며, 이는 느리고 위험하며 소스 데이터가 이미 바뀌었거나 삭제되었다면 아예 불가능할 수도 있다. 이 때문에 ETL은 빠르게 변화하는 분석 환경에서는 유연성이 떨어진다.
핵심 포인트
- ETL은 저장 전 정제/마스킹이 필요한 경우, 엄격하고 거의 안 바뀌는 스키마, 강한 규제·컴플라이언스 요구, 엄격한 스토리지 비용 통제가 필요한 상황(예: 은행/병원/레거시 마이그레이션)에 적합하다.
- ETL의 근본 한계는 재처리가 소스 재추출을 요구한다는 점 — 소스 데이터가 변경/삭제되었다면 재처리가 느리거나 아예 불가능할 수 있다.