데이터 통합 전략을 논할 때 가장 먼저 마주치는 갈림길이 ETL과 ELT입니다. 글자 순서만 바뀐 듯 보이지만, 변환을 적재 전에 하느냐 후에 하느냐는 아키텍처 전체, 비용 구조, 팀 역할 분담까지 바꿉니다. 클라우드 웨어하우스의 등장으로 무게중심이 ELT로 옮겨갔지만, ETL이 여전히 우월한 영역도 분명히 있습니다.
이 글은 두 방식의 동작 원리를 비교하고, 비용과 거버넌스 관점에서 어떤 상황에 무엇을 골라야 하는지 정리합니다.
두 방식의 기본 흐름
ETL은 추출(Extract) 후 별도의 처리 엔진에서 변환(Transform)을 마친 뒤 정제된 데이터만 웨어하우스에 적재(Load)합니다. ELT는 원본을 먼저 웨어하우스에 그대로 적재한 다음, 웨어하우스의 연산 능력으로 그 안에서 변환합니다.
이 차이의 핵심은 변환이 일어나는 장소입니다. ETL은 외부 처리 클러스터에서, ELT는 웨어하우스 내부에서 변환합니다. 클라우드 웨어하우스의 연산이 저렴하고 탄력적이 되면서 ELT가 부상한 배경이 여기 있습니다.
정면 비교
| 기준 | ETL | ELT |
|---|---|---|
| 변환 위치 | 외부 처리 엔진 | 웨어하우스 내부 |
| 원본 보존 | 적재 안 됨 | 그대로 보존 |
| 유연성 | 스키마 사전 고정 | 나중에 재변환 용이 |
| 민감정보 | 적재 전 마스킹 가능 | 적재 후 처리 필요 |
| 적합 환경 | 온프레미스, 규제 | 클라우드 웨어하우스 |
ELT가 유리한 경우
대부분의 클라우드 네이티브 분석 환경에서는 ELT가 기본 선택입니다. 원본을 먼저 보존하므로 비즈니스 로직이 바뀌어도 재추출 없이 다시 변환만 하면 됩니다. dbt 같은 도구가 웨어하우스 내부 변환을 SQL로 관리해주면서 분석가도 직접 변환을 다룰 수 있게 되었습니다.
또한 변환 로직을 추가하거나 새 지표를 만들 때 파이프라인을 다시 짤 필요 없이 SQL 모델만 더하면 됩니다. 이 민첩성이 ELT의 가장 큰 매력입니다.
ETL이 여전히 옳은 경우
반면 개인정보나 결제 정보처럼 원본을 웨어하우스에 그대로 두면 안 되는 규제 환경에서는 ETL이 필요합니다. 적재 전에 마스킹이나 토큰화를 끝내야 하기 때문입니다. 또한 웨어하우스 연산 비용이 비싼 환경이라면, 적재 전 변환으로 데이터 양을 줄여 비용을 통제하는 편이 낫습니다.
- 규제·컴플라이언스: 적재 전 PII 제거 필요 시 ETL
- 복잡한 비정형 변환: 웨어하우스 SQL로 표현하기 어려운 로직은 ETL
- 비용 통제: 적재량을 줄여야 할 때 ETL 사전 필터링
실무에서는 둘을 섞은 하이브리드도 흔합니다. 민감정보는 ETL로 사전 처리하고 나머지는 ELT로 유연하게 다루는 식입니다. 정답은 하나가 아니라 데이터 성격과 규제 요건에 달려 있습니다.
정리
ETL과 ELT의 차이는 변환의 시점과 장소입니다. 클라우드 웨어하우스 환경에서 유연성과 민첩성이 중요하면 ELT, 규제·민감정보·비용 통제가 우선이면 ETL이 적합합니다. 많은 조직은 두 방식을 상황에 맞게 혼합합니다. 데이터의 민감도와 변환 복잡성을 기준으로 선택하세요.
