ETL/ELT 선택 기준, 툴 지형, 그리고 Reverse ETL
ETL vs ELT vs Zero ETL: What's Actually Different (2026) — DataVidhya (blog) How to Choose (pp.12-13); The Real Difference — Real-World Guide & Tools You Will See (pp.8-9); 40 System Design Q12 Reverse ETL (pp.7-8)
이 모듈을 다 읽으면
- 규제·레거시 환경과 스타트업·스케일업 환경에서 ETL/ELT 선택이 왜 갈리는지 사례로 설명할 수 있다
- Reverse ETL이 파이프라인의 어느 지점에 위치하며 어떤 설계 고려사항(동기화 빈도, 충돌 해결, 증분 감지)이 필요한지 설명할 수 있다
ETL·ELT·Zero ETL 중 어느 것도 항상 옳은 정답은 아니며, 선택은 제약 조건이 무엇인지 인식하는 데서 시작된다. 규제·레거시 환경은 ETL을, 원본 데이터가 많고 빠른 접근이 필요한 스타트업/스케일업은 ELT를 택하는 경향이 있다. 웨어하우스에서 다시 운영 툴로 데이터를 밀어 넣는 Reverse ETL은 이 흐름의 마지막 단계로, Gold 계층 이후 서빙 경계에 위치한다.
제약 조건으로 선택하기 — 두 가지 실전 시나리오
엔터프라이즈급 데이터 엔지니어링 프로젝트에는 모든 상황에 맞는 단일 정답이 거의 없다. 각 접근은 서로 다른 종류의 제약에 최적화되어 있다 — ETL은 통제와 예측 가능성이 가장 중요할 때, ELT는 변화와 반복이 예상될 때, Zero ETL은 속도와 신선도가 우선일 때 강점을 낸다. 진짜 실력은 이 패턴들을 암기하는 것이 아니라, 눈앞의 문제에서 어떤 제약이 가장 중요한지 알아보고 그 선택이 미래의 변경에 어떤 영향을 줄지 예측하는 능력이다.
이를 구체화하면 두 시나리오로 나뉜다. 첫째, 현대적 스타트업/스케일업(예: BigQuery 사용, 50개 광고 플랫폼의 데이터를 즉시 봐야 하고 JSON 로그 같은 비정형 데이터가 많은 경우)은 ELT가 낫다 — 접근 속도가 핵심이며 파이프라인을 몇 주씩 기다려 만들 여유가 없기 때문이다. 둘째, 은행·병원처럼 GDPR/HIPAA 규제를 받거나 30년 된 레거시 메인프레임을 새 시스템으로 옮기는 경우는 ETL이 낫다 — PII는 법적으로 클라우드에 원본 그대로 저장할 수 없어 서버를 떠나기 전에 반드시 마스킹해야 하고, 완전히 다른 데이터 구조를 새 시스템에 맞게 재구성해야 하기 때문이다.
핵심 포인트
- ETL=통제·예측가능성 우선, ELT=변화·반복 예상, Zero ETL=속도·신선도 우선 — 선택은 암기가 아니라 눈앞 문제의 제약을 인식하는 능력에 달려 있다.
- 현대적 클라우드 스타트업/스케일업(빠른 접근, 비정형 데이터 다수)은 ELT를, 규제 산업·레거시 마이그레이션(PII 마스킹, 구조 재구성 필요)은 ETL을 택하는 경향이 뚜렷하다.
툴 지형과 Reverse ETL
실무에서 마주치는 툴은 계보를 따라 나뉜다. 전통적/엔터프라이즈 ETL 툴로는 Informatica, Talend, SSIS(Microsoft)가 있고, 현대적 ELT 스택은 Fivetran/Airbyte(데이터 이동) + dbt(웨어하우스 내 변환) 조합이 대표적이다. Databricks 같은 하이브리드 플랫폼은 무거운 스트리밍 ETL을 위한 '선언적 파이프라인(Declarative Pipelines)'과, 레이크하우스 위에서 현대적 ELT 워크플로를 구성하는 'Lakeflow' 계열 도구를 함께 제공해 두 방식을 넘나들 수 있게 한다.
Reverse ETL은 이 흐름의 마지막 단계에서 방향을 뒤집는다 — 웨어하우스에서 변환이 끝난 데이터를 다시 Salesforce, Braze 같은 운영 툴로 밀어 넣는 것이다(예: Snowflake의 고객 헬스 스코어를 Salesforce로, 이탈 위험 세그먼트를 Braze 이메일 캠페인으로 동기화). 아키텍처상으로는 Gold 계층 변환이 끝난 뒤의 '서빙' 경계에 위치한다. 설계 시 핵심 고려사항은 동기화 빈도와 충돌 해결이다 — 웨어하우스가 스코어를 매시간 갱신하는데 CRM에서 담당자가 수동으로 값을 덮어쓸 수 있다면 병합 전략이 필요하다. 시간당 1000만 건 이상을 동기화하는 규모에서는 해싱이나 웨어하우스 쪽 CDC를 이용한 증분 변경 감지가 필수인데, 그렇지 않으면 매번 전체 데이터셋을 SaaS API로 다시 써야 해 API 레이트 리밋을 소진하고 비용이 급증한다.
핵심 포인트
- 전통 ETL 툴(Informatica/Talend/SSIS), 현대 ELT 스택(Fivetran/Airbyte + dbt), 하이브리드(Databricks Lakeflow 등 레이크하우스 기반 도구)로 툴 지형이 나뉜다.
- Reverse ETL은 웨어하우스의 Gold 계층 데이터를 다시 운영 툴(CRM/마케팅 자동화)로 동기화하는 서빙 경계의 마지막 단계이며, 동기화 빈도·충돌 해결·증분 변경 감지(해싱/CDC)가 핵심 설계 고려사항이다.