ETL vs ELT
데이터 처리 방식의 두 가지 방법인 ETL(추출, 변환, 적재)과 ELT(추출, 적재, 변환)은 단순히 작업 순서가 바뀐 것이라고 생각하기 쉽습니다.
하지만 이 차이는 데이터 아키텍처, 비용 구조, 데이터 처리 유연성, 그리고 미래 확장성까지 광범위한 영향을 미치며, 데이터 활용 전략 관점에서 근본적인 차이가 있습니다.
이 글에서는 ETL과 ELT이 어떻게 다른지, 각 방식의 장단점, 적합한 사용 사례 등에 대해 알아보았습니다.
ETL (Extract, Transform, Load)이란?
Section titled “ETL (Extract, Transform, Load)이란?”ETL은 다양한 데이터 소스에서 필요한 데이터를 추출(Extract) 하고, 별도의 준비 환경(Staging Area)에서 정해진 규칙에 따라 데이터를 변환(Transform) 한 후, 최종적으로 데이터 웨어하우스(Data Warehouse)에 적재(Load) 하는 방식입니다.
1970년대부터 사용된 이 방식은 온프레미스(On-premise) 환경에서 표준으로 자리 잡았는데요, 당시에는 스토리지 비용이 지금에 비해 상대적으로 높았기 때문에 필요한 데이터만 정제하고 가공하여 저장하는 ETL 방식이 효율적이었기 때문입니다.
ETL의 장점
Section titled “ETL의 장점”ETL 방식은 데이터를 적재하기 전에 변환 과정을 거치는 방식입니다.
따라서 데이터 품질을 표준화하고, 오류를 수정하며, 개인 식별 정보(PII) 를 마스킹하는 등 보안 및 규제 요구사항을 사전에 충족하기 유리하다는 장점이 있습니다.
예를 들어 내부 정책 상 사용자의 이메일 번호는 개인정보에 해당해 데이터 웨어하우스에 적재할 수 없는 경우, 데이터 웨어하우스에 적재하기 전에 이메일 번호를 마스킹하여 보안 및 규제 요구사항을 충족할 수 있습니다.
또한 이미 변환 및 정재가 되어있는 데이터가 데이터 웨어하우스에 저장되므로, 분석 쿼리 실행 시 비교적 빠른 성능을 기대할 수 있습니다.
ETL의 한계점
Section titled “ETL의 한계점”하지만 ETL 방식은 유연성이 부족하다는 한계점이 있습니다.
예를 들어 웹사이트 로그 데이터에서 사용자 행동 분석을 위해 페이지 URL, 방문 시간, 사용자 ID만을 추출하여 데이터 웨어하우스에 적재했다고 가정해 봅시다.
당시에는 사용자 접속 IP 주소가 불필요하다고 판단하여 변환 과정에서 제외했었습니다. 그런데 얼마 후, 특정 지역별 사용자 접속 패턴을 분석해야 하는 새로운 비즈니스 요구사항이 생겼습니다!
이런 경우 ETL 방식에서는 이미 IP 주소 정보가 변환 과정에서 유실되었기 때문에, 원본 로그 데이터부터 다시 추출하고, 변환 로직을 수정하여 전체 파이프라인을 재구성해야 하는 번거로움이 발생합니다.
또한 데이터를 적재하기 전에 변환 과정을 거쳐야 하므로, 추후 후술할 ELT 방식에 비해 초기 데이터 적재 시간이 상대적으로 오래 걸릴 수 있습니다.
ELT (Extract, Load, Transform)이란?
Section titled “ELT (Extract, Load, Transform)이란?”ELT 방식은 데이터 소스에서 데이터를 추출(Extract) 한 후, 원본 형태 그대로 데이터 레이크(Data Lake) 나 클라우드 데이터 웨어하우스에 적재(Load) 하여 이후 필요에 따라 다양한 분석 목적에 맞게 데이터를 변환(Transform) 하여 사용하는 최신 접근 방식입니다.
이러한 ELT의 등장은 클라우드 기술 발전과 밀접한 관련이 있습니다.
현대에 들어 클라우드 기술이 발전하며 스토리지 비용이 점차 저렴해졌고, 클라우드 내에서 강력한 병렬 처리 및 컴퓨팅 성능을 제공하기 시작했습니다.
이러한 환경이 만들어지자 대량의 원본 데이터를 일단 저장하고 필요할 때 빠르게 변환하여 사용하자는 ELT 방식이 등장하게 되었습니다.
ELT의 장점
Section titled “ELT의 장점”ELT 방식은 데이터를 적재하기 전에 변환 과정을 거치지 않고 데이터를 우선 적재하므로 데이터를 훨씬 유연하게 사용할 수 있습니다.
ETL 방식에서 예를 들었던 상황이라면, 다시 데이터 파이프라인을 재구성하지 않아도 되죠.
또한 정형 데이터 처리에 주로 초점을 맞춰 발전한 ETL 방식과 달리, ELT 방식은 JSON, XML과 같은 반정형 데이터도 쉽게 저장할 수 있습니다.
이미지나 텍스트 파일 같은 비정형 데이터도 원본 형태 그대로 데이터 레이크나 스테이징 영역에 우선 적재 한 후, 데이터 웨어하우스의 기능을 활용해 필요시 변환하여 분석에 활용할 수 있습니다.
ELT의 고려사항
Section titled “ELT의 고려사항”하지만 ELT 방식 역시 꼭 고려해야하는 몇 가지 사항이 있습니다.
ELT 방식은 원본 데이터를 바로 적재하기 때문에 개인정보에 해당하는 정보를 적절하게 처리해줘야하는데요, 데이터 웨어하우스 내 접근 제어, 동적 데이터 마스킹(DDM), 컬럼 레벨 보안 등의 기능을 적절히 활용하여 데이터 품질, 거버넌스 및 개인정보보호 규정을 철저히 관리해야 합니다.
또한 일반적으로 데이터 웨어하우스 내부에서 변환 작업이 수행되므로, 사용한 컴퓨팅 자원에 따라 비용이 발생할 수 있습니다.
따라서 변환 로직이 복잡하거나 처리하는 데이터 양이 매우 클 경우 데이터 웨어하우스의 비용이 증가할 수 있습니다.
주요 항목별 비교: ETL vs ELT
Section titled “주요 항목별 비교: ETL vs ELT”ETL vs ELT 핵심 비교
SQL 기반dbt 등 데이터 모델링 도구 활용 능력 중요어떤 방식을 선택해야 할까요?
Section titled “어떤 방식을 선택해야 할까요?”아래의 시나리오를 참고하여 어떤 방식이 우리 서비스에 적합한지 고민해 보세요.
ETL을 고려할 수 있는 경우
- 데이터 스키마 변경이 거의 없는 레거시 시스템 또는 관계형 데이터베이스와 연동해야 할 때
- 최종 목적지에 적재하기 전, 매우 복잡하거나 컴퓨팅 자원 소모가 큰 변환 작업이 반드시 필요할 때
- 데이터가 중앙 저장소에 저장되기 전, 개인 식별 정보(PII) 제거·마스킹 등 엄격한 보안 및 규정 준수 요구사항을 반드시 충족해야 할 때
- 처리해야 할 데이터 양이 많지 않아 클라우드 데이터 웨어하우스의 강력한 변환 성능을 활용할 필요가 없을 때
ELT를 고려할 수 있는 경우
스노우플레이크(Snowflake),빅쿼리(BigQuery),레드쉬프트(Redshift)등 클라우드 기반 데이터 플랫폼을 중심으로 아키텍처를 구축할 때- 정형, 비정형, 반정형 등 다양한 형태의 데이터를 모두 통합하고 분석하고자 할 때
- 미래의 예측 불가능한 분석 요구에 신속하게 대응하기 위한 유연성이 매우 중요할 때
- 클라우드의 확장 가능하고 탄력적인 스토리지 및 컴퓨팅 자원을 최대한 활용하고자 할 때
현실의 데이터 파이프라인은 무조건 ETL 또는 ELT 중 하나의 방식만을 고수하기보단, 두 가지를 혼합한 하이브리드 형태로 구성되는 경우가 많습니다.
예를 들어, 초기 데이터가 저장되는 속도가 중요함과 동시에 개인정보 처리를 꼭 선행해야한다면 기본적인 정제만 거친 뒤 최대한 빠르게 적재하고, 나중에 특정 분석 요건에 맞춰 복잡한 데이터 모델링이나 집계를 수행하는 ETL-T 방법을 채택할 수도 있습니다.
중요한 것은 특정 용어나 기술에 얽매이지 않고, 비즈니스 목표, 데이터 특성, 사용 가능한 기술 스택 및 예산 등 구체적인 상황과 요구사항을 종합적으로 고려하여 가장 적합한 데이터 처리 전략을 유연하게 설계하고 발전시켜 나가는 것이 아닐까 싶습니다.