번역본.
최근 데이터 엔지니어링 분야에서 “Zero ETL”이라는 개념이 빠르게 확산되고 있다. 이는 단순히 새로운 도구가 등장했다는 의미가 아니라, 데이터 플랫폼을 바라보는 근본적인 사고방식이 바뀌고 있음을 의미한다. 과거 데이터 엔지니어의 핵심 역량이 “데이터를 얼마나 안정적으로 이동시키는가”였다면, 이제는 “데이터를 얼마나 잘 구조화하여 공유 가능한 상태로 유지하는가”가 핵심 역량이 되고 있다.
이번 글에서는 기존 데이터 아키텍처의 진화 과정을 간단히 정리하고, Zero ETL이 왜 등장했으며 실제 엔지니어의 역할이 어떻게 바뀌는지 정리하고자 한다. 또한 이 변화가 단순한 유행이 아니라 장기적인 플랫폼 설계 패러다임 변화라는 점에 대해 개인적인 생각도 함께 정리한다.
초기 데이터 플랫폼에서는 저장소가 비싸고 시스템 간 연동이 어려웠기 때문에, 데이터를 분석 시스템으로 옮기기 전에 정제하고 변환하는 방식(ETL)이 표준이었다. 이 시기 데이터 엔지니어는 스키마 정의, 데이터 정합성 보장, 변환 로직 관리까지 모두 담당했다. 데이터 파이프라인은 사실상 하나의 작은 데이터베이스 엔진 역할을 했으며, 파이프라인이 실패하면 분석 데이터 자체가 존재하지 않는 구조였다.
이 구조는 강력한 통제력을 제공했지만, 스키마 변경이나 신규 데이터 소스 추가 시 전체 시스템을 수정해야 하는 높은 유지 비용을 만들었다. 결과적으로 데이터 플랫폼은 안정적이었지만 변화에 매우 느린 구조가 되었다.
클라우드 데이터 웨어하우스가 등장하면서 저장소 비용이 급격히 낮아졌고, 먼저 데이터를 적재한 뒤 웨어하우스 내부에서 변환을 수행하는 ELT 방식이 보편화되었다. 이 시기 데이터 엔지니어는 변환보다는 데이터 수집과 적재를 안정적으로 수행하는 “데이터 물류 운영자”에 가까운 역할을 맡게 되었다.
ELT의 가장 큰 문제는 데이터 복제의 증가였다. 동일한 데이터가 운영 DB, 데이터 레이크, 웨어하우스, BI 레이어 등 여러 곳에 복사되면서 정합성 문제와 관리 복잡도가 증가하였다. 확장성은 좋아졌지만 단일 소스의 진실(single source of truth)은 점점 사라지게 되었다.
CDC(Change Data Capture)와 스트리밍 기술은 데이터가 발생한 즉시 분석 환경으로 전달할 수 있게 만들었다. 그러나 이는 또 다른 복잡성을 가져왔다. 이벤트 순서 보장, 중복 처리, 시간 지연 처리, 상태 관리 등 분산 시스템 수준의 문제가 데이터 엔지니어의 일상적인 과제가 되었다.
많은 조직이 필요 이상의 실시간 처리를 도입하면서 운영 복잡도만 증가하는 사례도 나타났다. 즉, 기술적으로는 진보했지만 “왜 데이터를 이동해야 하는가”라는 질문 자체는 여전히 남아 있었다.
Zero ETL은 데이터를 더 잘 이동시키는 기술이 아니라, 가능하면 이동 자체를 줄이자는 접근이다. 핵심 개념은 다음과 같다.
데이터를 여러 시스템으로 복사하지 않는다
공유 가능한 스토리지와 오픈 테이블 포맷을 사용한다
여러 컴퓨트 엔진이 동일한 데이터를 직접 읽도록 한다
이 접근은 데이터 엔지니어의 역할을 크게 바꾼다. 더 이상 파이프라인을 많이 만드는 사람이 아니라, 여러 팀이 함께 사용할 수 있는 안정적인 데이터 테이블과 메타데이터 구조를 설계하는 사람이 된다. 즉, “Pipeline Engineer”에서 “Data Platform Designer”로 역할이 이동한다.