ETL과 ELT의 핵심 차이는 데이터 변환이 저장 전인지 저장 후인지에 있습니다. 단순히 최신 방식이라는 이유로 ELT를 선택하기보다 데이터 민감도, 목표 저장소의 처리 능력, 재처리 필요성, 운영 복잡도를 기준으로 설계해야 합니다.
📌 핵심 5줄 요약
1. ETL은 추출한 데이터를 별도 엔진에서 변환한 뒤 정제된 결과를 적재하는 방식입니다.
2. ELT는 원천 데이터를 먼저 저장하고 목표 웨어하우스나 레이크하우스에서 변환하는 방식입니다.
3. ETL은 사전 품질 통제와 민감정보 필터링에 유리하고, ELT는 원천 보존과 확장성에 유리합니다.
4. ELT는 목표 저장소의 컴퓨팅 성능과 비용 구조가 충분할 때 효과가 큽니다.
5. 실무에서는 개인정보 제거는 ETL로 처리하고 분석 모델링은 ELT로 수행하는 하이브리드 구조도 많이 사용합니다.
📌 목차
01 | ETL과 ELT의 기본 개념
02 | ETL 처리 흐름
03 | ELT 처리 흐름
04 | 두 방식의 핵심 차이
05 | 데이터 품질과 스키마 설계
06 | 성능과 확장성 비교
07 | 비용과 운영 복잡도
08 | 보안과 규제 대응
09 | 데이터 레이크와 웨어하우스의 역할
10 | 배치 처리와 실시간 처리
11 | ETL이 적합한 상황
12 | ELT가 적합한 상황
13 | 하이브리드 파이프라인 설계
14 | 도입 전 점검 절차
01 | ETL과 ELT의 기본 개념
ETL은 Extract, Transform, Load의 약자로 데이터를 원천 시스템에서 추출하고, 정제·표준화·집계한 뒤 목표 저장소에 적재합니다. 변환이 저장보다 먼저 일어나므로 목적지에는 분석에 필요한 형태의 데이터가 들어가는 경우가 많습니다.
ELT는 Extract, Load, Transform의 순서입니다. 원천 데이터를 비교적 가공하지 않은 상태로 데이터 웨어하우스나 데이터 레이크에 저장한 뒤, 목표 저장소의 SQL 엔진이나 분산 처리 엔진을 사용해 분석용 데이터로 변환합니다. Microsoft와 Google Cloud의 공식 문서도 두 방식의 차이를 변환 위치와 목표 저장소의 처리 능력으로 설명합니다.
02 | ETL 처리 흐름
ETL의 일반적인 흐름은 원천 연결, 데이터 추출, 정제와 변환, 검증, 최종 적재 순서입니다. 예를 들어 여러 판매 시스템에서 주문 데이터를 가져온 뒤 날짜 형식을 통일하고 중복 주문을 제거하며 고객 식별자를 매핑한 다음 분석용 테이블에 저장할 수 있습니다.
변환 엔진은 필터링, 정렬, 조인, 집계, 중복 제거, 데이터 형식 변경, 유효성 검사 등을 담당합니다. 따라서 목표 데이터베이스의 성능이 제한적이거나 복잡한 변환을 별도 컴퓨팅 환경에서 처리해야 할 때 유리합니다.
03 | ELT 처리 흐름
ELT는 원천 시스템에서 데이터를 추출한 뒤 원본 또는 원본에 가까운 형태로 저장합니다. 이후 SQL, Spark, 노트북, 데이터 변환 도구 등을 이용해 스테이징 데이터와 분석용 모델을 단계적으로 생성합니다.
이 구조에서는 원천 데이터가 남아 있기 때문에 새로운 분석 요구가 생겼을 때 처음부터 다시 수집하지 않고 변환 로직만 수정해 재처리할 수 있습니다. 다만 저장소가 데이터를 빠르게 읽고 변환할 수 있어야 하며, 원천 데이터의 보안·보존 정책도 함께 설계해야 합니다.
04 | 두 방식의 핵심 차이
| 구분 | ETL | ELT |
|---|---|---|
| 변환 시점 | 목표 저장소에 넣기 전 | 목표 저장소에 넣은 후 |
| 원천 데이터 보존 | 정제 과정에서 일부 손실될 수 있음 | 원천 데이터를 보존하기 쉬움 |
| 주요 연산 위치 | 별도 ETL 엔진 | 웨어하우스·레이크하우스·분산 엔진 |
| 품질 통제 | 적재 전 통제가 쉬움 | 저장 후 규칙과 검증 체계가 필요함 |
| 확장 방식 | 변환 엔진을 별도로 확장 | 목표 저장소의 컴퓨팅 자원을 확장 |
| 적합한 환경 | 규제가 강하거나 목적지가 제한적인 환경 | 클라우드 기반 분석·탐색 환경 |
두 방식은 우열 관계가 아니라 변환 위치와 책임 분배가 다른 설계 패턴입니다. 실제 플랫폼은 ETL과 ELT를 모두 지원하며, 업무별로 다른 흐름을 구성할 수 있습니다.
05 | 데이터 품질과 스키마 설계
ETL에서는 적재 전에 필수값, 자료형, 중복, 참조 관계를 검사할 수 있습니다. 잘못된 레코드를 별도 오류 영역으로 보내면 목표 저장소에 들어가는 데이터의 품질을 일정하게 유지하기 쉽습니다.
ELT에서는 원천 데이터와 정제 데이터를 분리하는 계층 설계가 중요합니다. 일반적으로 원천 보관 영역, 정제·표준화 영역, 업무별 모델 영역을 나누고 각 단계의 입력·출력 규칙을 문서화합니다. 원천 데이터를 그대로 보존하더라도 분석 테이블에는 명확한 품질 규칙과 테스트가 필요합니다.
스키마 온 라이트와 스키마 온 리드
ETL은 저장 전에 스키마를 정하는 스키마 온 라이트에 가까운 경우가 많습니다. ELT는 저장 후 사용 목적에 따라 구조를 해석하는 스키마 온 리드와 잘 맞지만, 무계획으로 운영하면 컬럼 의미가 달라지거나 동일한 지표가 여러 방식으로 계산될 수 있습니다.
06 | 성능과 확장성 비교
ETL의 성능은 추출 속도, 변환 엔진의 처리량, 네트워크 전송, 목표 시스템의 적재 속도에 영향을 받습니다. 변환을 적재 전에 끝내므로 목표 시스템에 부담을 줄일 수 있지만, 변환 서버가 병목이 되면 전체 파이프라인이 느려질 수 있습니다.
ELT는 대규모 병렬 처리와 탄력적인 클라우드 컴퓨팅 자원을 활용하기 쉽습니다. 반면 변환 작업이 조회 작업과 같은 저장소 자원을 사용하면 대시보드나 운영 쿼리의 성능에 영향을 줄 수 있습니다. 따라서 작업 시간대 분리, 자원 등급 분리, 파티션 설계, 증분 처리 전략을 함께 검토해야 합니다.
07 | 비용과 운영 복잡도
ETL은 별도 변환 엔진, 실행 환경, 라이선스, 모니터링 체계를 운영해야 할 수 있습니다. 대신 목적지에 불필요한 데이터가 들어가는 것을 줄이고 제한된 데이터베이스 자원을 보호할 수 있습니다.
ELT는 별도 변환 서버를 줄이고 저장소 내부 기능을 활용할 수 있지만, 원천 데이터 보관량과 변환 쿼리 실행량이 늘어날 수 있습니다. 클라우드에서는 저장 비용과 컴퓨팅 비용이 분리되는 경우가 많으므로 단순히 ELT가 항상 저렴하다고 판단해서는 안 됩니다. 실제 비용은 데이터 보존 기간, 재처리 빈도, 쿼리 스캔량, 동시 사용자 수에 따라 달라집니다.
08 | 보안과 규제 대응
개인정보, 결제정보, 의료정보처럼 원천 보관 자체가 제한되는 데이터는 ELT 도입 전에 법적·조직적 보존 기준을 확인해야 합니다. 원천 데이터를 무조건 장기 보관하면 접근 권한과 삭제 요청 대응이 복잡해질 수 있습니다.
민감정보를 적재 전에 마스킹하거나 토큰화해야 한다면 ETL이 더 적합할 수 있습니다. 반대로 원천 데이터 보존이 허용되고 세분화된 접근 제어, 컬럼 마스킹, 감사 로그를 적용할 수 있다면 ELT도 사용할 수 있습니다. 중요한 것은 방식보다 데이터 분류와 권한 설계입니다.
09 | 데이터 레이크와 웨어하우스의 역할
데이터 웨어하우스는 정형화된 분석과 보고에 적합하고, 데이터 레이크는 다양한 형식의 원천 데이터와 대규모 파일을 보관하는 데 유리합니다. 레이크하우스는 저장소의 유연성과 분석 엔진의 구조화 기능을 함께 활용하려는 접근입니다.
ELT는 원천 데이터를 레이크나 클라우드 웨어하우스에 저장한 뒤 분석 모델을 만드는 구조와 잘 맞습니다. 데이터 레이크를 원천 보관 영역으로 사용하고 웨어하우스에 정제 결과를 제공하는 방식도 가능합니다. Microsoft 문서 역시 데이터 레이크를 웨어하우스의 상위 원천으로 사용하고 ELT 방식으로 구조화할 수 있다고 설명합니다.
10 | 배치 처리와 실시간 처리
ETL과 ELT는 모두 일정한 간격으로 실행하는 배치 처리에 자주 사용됩니다. 하루 한 번 매출 데이터를 집계하거나 일정 시간마다 변경된 고객 정보를 적재하는 방식이 대표적입니다.
실시간 또는 준실시간 처리는 별도의 스트리밍 아키텍처가 필요할 수 있습니다. 메시지 큐, 이벤트 스트림, 스트리밍 처리 엔진, 짧은 주기의 증분 적재 등을 조합하며, 단순히 ETL을 ELT로 바꾸는 것만으로 지연 시간이 해결되지는 않습니다. Microsoft의 데이터 아키텍처 가이드도 배치 ETL·ELT와 이벤트가 도착하는 스트리밍 처리를 구분합니다.
11 | ETL이 적합한 상황
다음 조건이 많다면 ETL을 우선 검토할 수 있습니다.
- 목표 데이터베이스의 처리 자원이 제한적이다.
- 적재 전에 개인정보 제거, 마스킹, 필터링이 필요하다.
- 복잡한 변환을 전용 엔진이나 분산 처리 환경에서 수행해야 한다.
- 정해진 스키마와 정제 데이터만 목적지에 제공해야 한다.
- 규제나 감사 요구로 적재 전 검증 결과를 남겨야 한다.
다만 ETL을 선택하더라도 오류 데이터, 원천 파일, 변환 로그를 어느 기간까지 보존할지 결정해야 합니다. 적재 전에 정제한다는 이유로 원천과 처리 이력을 모두 폐기하면 장애 분석과 재처리가 어려워집니다.
12 | ELT가 적합한 상황
다음 조건에서는 ELT가 효율적일 가능성이 높습니다.
- 클라우드 웨어하우스나 레이크하우스의 컴퓨팅 자원을 확장할 수 있다.
- 원천 데이터를 보존하고 다양한 분석 요구에 재사용해야 한다.
- SQL 중심으로 변환 로직을 관리하고 분석가의 참여를 높이고 싶다.
- 새로운 컬럼이나 데이터 형식이 자주 추가된다.
- 대규모 데이터를 병렬 처리하고 저장과 변환을 분리하고 싶다.
ELT에서는 원천 영역을 그대로 분석에 노출하지 않는 것이 좋습니다. 원천 테이블과 업무용 모델 사이에 표준화 계층을 두고, 변환 실패·중복·지연 데이터를 확인할 수 있는 품질 검사를 운영해야 합니다.
13 | 하이브리드 파이프라인 설계
실무에서는 ETL 또는 ELT 하나만 고집하기보다 단계별로 역할을 나누는 하이브리드 구성이 현실적입니다. 예를 들어 수집 단계에서 개인정보를 제거하고, 원천 데이터를 저장한 뒤, 분석용 집계와 차원 모델은 웨어하우스 안에서 ELT로 처리할 수 있습니다.
예시 구조
원천 시스템 → 민감정보 필터링·형식 검증 → 원천 보관 영역 → 정제 모델 → 업무별 데이터마트 → 대시보드와 분석 도구
이 구조의 장점은 보안상 필요한 최소 변환은 앞단에서 수행하고, 변경이 잦은 비즈니스 로직은 저장소 안에서 관리할 수 있다는 점입니다. 또한 원천 보관 영역과 분석 모델을 분리하면 동일한 데이터를 여러 목적에 재사용하기 쉽습니다.
14 | 도입 전 점검 절차
ETL과 ELT를 선택하기 전에 다음 순서로 요구사항을 정리하면 도구 중심의 잘못된 결정을 줄일 수 있습니다.
- 원천 데이터의 형식, 크기, 증가 속도, 변경 주기를 확인합니다.
- 개인정보와 규제 대상 데이터의 보존·삭제·마스킹 조건을 분류합니다.
- 목표 저장소가 변환 작업과 분석 쿼리를 동시에 감당할 수 있는지 점검합니다.
- 전체 적재가 아닌 증분 적재와 변경 데이터 캡처가 가능한지 확인합니다.
- 실패 시 어느 단계부터 재시작할지와 중복 적재 방지 기준을 정의합니다.
- 원천 데이터, 변환 결과, 오류 레코드, 실행 로그의 보존 기간을 정합니다.
- 데이터 품질 지표와 파이프라인 성공 기준을 운영 대시보드에 연결합니다.
특히 재실행 설계가 중요합니다. 같은 작업을 다시 실행해도 중복 데이터가 생기지 않도록 고유 키, 처리 시각, 배치 식별자, 병합 규칙을 미리 정해야 합니다.
☑ 체크리스트
- 원천 데이터를 저장해도 되는지 보안·규제 기준을 확인했는가
- 목표 저장소의 변환 성능과 동시 조회 부하를 측정했는가
- ETL 엔진 또는 ELT 쿼리의 실패 지점을 추적할 수 있는가
- 증분 적재와 재실행 시 중복 방지 규칙이 있는가
- 원천·정제·업무 모델 계층의 책임이 분리되어 있는가
- 데이터 품질 검사와 오류 데이터 처리 방법이 정의되어 있는가
- 저장 비용과 컴퓨팅 비용을 함께 계산했는가
📖 자주하는 질문 Q&A
ETL과 ELT 중 무엇이 더 최신 방식인가요?
ELT가 클라우드 웨어하우스와 레이크하우스 환경에서 널리 활용되지만, ETL이 구식이라는 뜻은 아닙니다. 민감정보 제거, 제한된 목적지, 복잡한 사전 검증이 필요한 경우에는 ETL이 더 적합할 수 있습니다.
ELT를 사용하면 원천 데이터를 반드시 모두 보관해야 하나요?
반드시 그런 것은 아닙니다. 다만 ELT의 장점인 재처리와 탐색성을 활용하려면 보존 정책에 맞는 범위에서 원천 데이터 또는 재현 가능한 원본을 남기는 것이 유리합니다.
데이터 레이크를 사용하면 ELT가 자동으로 되는 건가요?
아닙니다. 데이터 레이크는 저장 구조이고, ETL·ELT는 변환이 언제 어디서 수행되는지를 설명하는 처리 방식입니다. 레이크에 저장하기 전에 변환하면 ETL에 가깝고, 저장 후 변환하면 ELT에 가깝습니다.
작은 팀도 ETL과 ELT를 구분해야 하나요?
구분해야 합니다. 규모가 작더라도 개인정보 처리, 재처리, 장애 복구, 비용 통제에 영향을 주기 때문입니다. 다만 처음부터 복잡한 플랫폼을 도입하기보다 데이터 흐름과 책임을 문서화하는 것부터 시작하면 됩니다.
📝 마무리
ETL은 변환과 품질 통제를 앞단에 두고, ELT는 원천 보존과 저장소의 연산 능력을 활용합니다. 선택 기준은 유행이 아니라 데이터 민감도, 저장소 성능, 재처리 요구, 운영 비용입니다. 보안상 필요한 전처리는 ETL로 처리하고 분석 모델링은 ELT로 수행하는 하이브리드 설계도 충분히 실용적인 대안입니다.