SQL

비즈니스 로직이 사는 곳 & 재처리 난이도

ETL에서는 비즈니스 로직이 파이프라인 내부에 산다 — 데이터가 웨어하우스에 도달하기 전에 정제·필터링·재구성되므로, 그 로직을 바꾸려면 대개 파이프라인 코드를 다시 건드려야 한다. ELT에서는 로직이 웨어하우스 안으로 옮겨간다 — 원본이 먼저 적재되고 SQL 기반 모델로 나중에 변환이 적용되어, 로직을 읽고 테스트하고 발전시키기가 더 쉬워진다. Zero ETL에서는 로직이 소비자에 더 가깝게, 즉 소스를 직접 읽는 쿼리·대시보드·애플리케이션 코드 안에 산다. 파이프라인 초반에 사는 로직일수록 바꾸기 어렵고, 분석에 가까이 사는 로직일수록 반복(iterate)하기는 쉽지만 명확한 가드레일이 있을 때만 그렇다.

재처리 관점에서 '이걸 다시 계산할 수 있는가?'라는 질문은 모든 프로젝트가 결국 마주하게 된다. ETL은 재처리를 위해 대개 소스 시스템으로 돌아가 파이프라인을 다시 돌려야 하므로 느리고 위험할 수 있으며, 소스 데이터가 바뀌었거나 삭제됐다면 아예 불가능할 수도 있다. ELT는 원본이 이미 웨어하우스에 있어 재처리가 재추출이 아니라 변환 재실행으로 끝나므로 새 정의 반영이나 과거 실수 수정이 훨씬 안전하다. Zero ETL은 재처리 능력이 소스 시스템의 데이터 보존 기간에 크게 좌우된다 — 히스토리가 제한적이면 재계산 능력도 그만큼 제한된다.

소스 시스템 부하, 지연시간 vs 유연성, 팀 소유권

ETL은 잦은 재처리·백필이 반복적으로 프로덕션 데이터베이스를 때릴 수 있어 시간이 지나면 분석 팀과 운영 팀 사이에 긴장을 만든다. ELT는 소스 시스템을 대개 수집 시점에 한 번만 건드리고 이후 변경은 웨어하우스 다운스트림에서 일어나 프로덕션 시스템을 더 격리시킨다. Zero ETL은 소스를 지속적으로 읽거나 준실시간으로 복제할 수 있어 효율적이지만, 소스 시스템이 항상 분석 경로의 일부가 된다는 뜻이기도 하다 — 프로덕션 시스템은 분석의 고통을 느껴서는 안 되며, 격리는 다이어그램에 보이지 않아도 중요한 아키텍처 속성이다.

지연시간과 유연성 축에서 ETL은 대개 배치 지향이라 지연시간은 높지만 변환이 더 통제되어 있고, ELT는 그 중간에서 데이터가 비교적 빠르게 도착하면서도 변환을 필요에 따라 조정할 수 있으며, Zero ETL은 가장 낮은 지연시간을 제공하지만 복잡한 변환은 깔끔하게 관리하기 어려워진다. 팀 소유권 측면에서 ETL 파이프라인은 대개 데이터 엔지니어가 소유·유지보수해 통제는 강하지만 반복 속도는 느리고, ELT는 소유권을 나눠 엔지니어는 수집/모델링 기반을, 분석가는 변환/지표를 맡게 하며, Zero ETL은 데이터를 소비자 손에 직접 쥐어줘 강력할 수 있지만 구조가 없으면 지표 정의가 제각각이 될 수 있다.

'The Real Difference' 블로그의 비교표도 같은 결론을 재확인한다: 속도(ETL=적재 느림·조회 즉시 vs ELT=적재 즉시·조회 시 정제 필요), 유연성(ETL=경직 vs ELT=유연), 확장성(ETL=대형 서버 필요 vs ELT=클라우드 자동 확장), 접근 주체(ETL=IT/엔지니어 전용 vs ELT=분석가/사이언티스트도 직접 탐색), 프라이버시(ETL=기본적으로 더 안전 vs ELT=원본을 적재하므로 엄격한 권한 관리 필요).