현대 데이터 플랫폼에서 ETL 비용-성능 평가의 한계와 실제 업무 패턴을 반영한 벤치마킹 방법론, 오픈소스 도구(Lake Loader)를 통한 실용적 측정법, 대표적 벤치마크의 비교와 한계, 실무에 적용하는 총소유비용(TCO) 산정법을 소개합니다.
수천 곳의 기업에서 수십억 달러를 지출하는 오늘날, 비용-성능은 데이터 레이크하우스든 데이터 웨어하우스든 클라우드 데이터 플랫폼의 평가 및 선택 시 매우 중요한 요소입니다. 데이터 모델(스노우플레이크 스키마, 스타 스키마 등)로 데이터를 수집·가공·변환하기 위한 추출/변환/적재(ETL) 작업은 클라우드 지출의 50% 이상을 차지합니다. 팀이 클라우드 데이터 플랫폼의 비용 관리에 깊이 관여하고 있든, 이제 막 관심을 두기 시작했든, ETL 비용-성능의 이해는 성공의 필수 조건입니다.
이 글에서는 오늘날의 표준 벤치마킹 스펙과 도구가 기업이 자신의 ETL 워크로드를 정확히 모델링하고 플랫폼 또는 벤더별 총소유비용(TCO)을 측정하는 데 얼마나 한계가 있는지 짚어봅니다. 특히 현 벤치마크는 데이터 레이크하우스, 오픈 테이블 포맷, 스트리밍 데이터 증가 등 클라우드 환경 변화에 따라가지 못하고 있으며, 그 결과 적재(L) 비용을 심각하게 과소평가하게 됩니다. 이 블로그에서는 이러한 워크로드 패턴을 깊이 있게 분석하고, 시장 내 다양한 데이터 플랫폼 비용 산출을 위한 실용적 도구와 측정법을 제시합니다. 또한 AWS EMR, Databricks, Snowflake 같은 대형 ETL 데이터 플랫폼에 대한 TCO 모델링이 가능한 계산기도 제공합니다.
최근 몇 년간 클라우드 데이터 생태계는 인프라, 기술, 아키텍처 측면에서 큰 변화를 겪었습니다. 이로 인해 플랫폼 간 경계가 흐려졌고, 데이터 저장(오픈 파일/테이블 포맷), 데이터 관리(오픈/폐쇄 형 테이블 관리 서비스), 데이터 활용(쿼리 엔진, 데이터사이언스 노트북, BI 플랫폼) 방식이 독립적으로 선택 가능해졌습니다.
더 자세한 비교 분석은 다음 블로그에서도 확인할 수 있습니다: 분석 엔진 비교, 데이터 사이언스/머신러닝 엔진 비교, 스트림 처리 엔진 비교.
클라우드 비용 제어의 양날의 검(인프라): 혁신과 데이터 폭증으로 인해 클라우드는 데이터 플랫폼의 표준 인프라가 되었습니다. 최대 65%에 이르는 기업이 온프레미스+클라우드 하이브리드 사용 중이지요. 클라우드는 탄력적 확장, 사용량 기반 과금, 컴퓨트-스토리지 분리, 저렴한 저장공간 등 많은 이점을 주지만, 엔진 선정이 매우 어렵고 1020%의 과잉 프로비저닝만으로도 수백수천만 달러가 낭비될 수 있습니다.
데이터 레이크하우스, 전통 레이크의 세대교체(기술): Apache Hudi™, Delta Lake 등의 레이크하우스 프레임워크는 파일 기반 레이크를 관리된 테이블(ACID 트랜잭션, 업데이트, 삭제, 타임트래블, CDC 지원 등)로 발전시켰지만, 이런 기능에는 상당한 컴퓨트 자원이 필요합니다. 예를 들어, 델타 병합은 단순 INSERT보다 10배 이상의 비용이 소요될 수 있습니다. 적절한 워크로드 모델링 없이 진행하면 예산 초과로 이어질 수 있습니다.
오픈 테이블 포맷, 데이터 웨어하우스에 오픈 데이터 확산(아키텍처): Apache Iceberg 같은 오픈 포맷은 2020년대 데이터웨어하우스에서 가장 주목받는 변화 중 하나입니다. 하지만 대부분의 클라우드 웨어하우스는 이러한 오픈 포맷을 단순 '메타데이터용'으로만 취급합니다. 웨어하우스는 대규모 스트리밍 데이터 처리는 처음으로 맞이하는 것이며, 여전히 업데이트가 드물다는 가정 하에 동작하는 경우가 많아 실제 ETL 비용 산정 시 한계를 드러냅니다.
결국 현실적인 ETL 비용 측정법 없이는 PoC, 스펙상의 성능과 실제 비용이 현저히 다를 수밖에 없습니다.
이상적 ETL 벤치마크를 설계하려면 추출(Extract), 변환(Transform), 적재(Load) 세 단계를 분해해 각 워크로드 특성을 살펴야 합니다. E 단계는 주로 오브젝트스토어에서 파일을 읽는 I/O 바운드 작업, T 단계는 조인·집계 등 CPU 및 네트워크 바운드, L은 대상 테이블 사이즈·업데이트 패턴에 따라 I/O 집중적입니다.
그림: 테이블 간 조인, 집계 등 전형적 ETL 파이프라인 예시
대부분의 경우 ETL 성능을 단순 쿼리(SQL) 성능으로 간주하는데, 이는 ETL 특유의 성능 특성을 전혀 반영하지 못합니다. 효과적인 벤치마크는 아래 기준을 충족해야 실무와 괴리 없는 결과를 제공합니다.
실시간 또는 준실시간 데이터 통합(Change Data Capture, CDC)이 확산되며 대부분의 대규모 ETL 작업이 일괄 배치에서 점진적 증분 처리로 변했습니다. 이상적 벤치마크는 각 ETL 실행 사이 얼마만큼의 데이터가 중복(재처리) 되는지도 시험해야 하며, 컬럼 통계나 존맵 같은 스캔 최적화 기술로 데이터 프루닝 효율성도 고려해야 합니다.
일반 쿼리 기반 변환 속도의 측정은 ET 단계에서 여전히 중요합니다(조인, 집계 등 다양한 변환/쿼리 경로를 테스트해야 함).
GDPR, CCPA 등의 규제에 따른 신속·대량 삭제는 점점 중요해지고 있습니다. 이런 대량 삭제(증분 LOAD과 별개로 테스트 되어야 함)가 실제 워크로드에 미치는 영향도 측정해야 합니다.
테이블 상태 변경마다 북키핑(스냅샷 만료 등)·최적화(머지, 압축 등)가 필요합니다. 특히 레이크하우스의 머지-온-리드 등은 이러한 유지 비용이 규칙적으로 발생하므로 반드시 측정에 포함되어야 합니다.
오늘날 데이터는 잦은 업데이트와 삭제가 필수입니다. 웨어하우스, 레이크하우스 모두 이러한 패턴을 제대로 벤치마크에 반영하지 않으면 추정 TCO와 실제가 크게 다릅니다. Iceberg, Hudi, Delta Lake 등 오픈레이크 스토리지는 이러한 패턴 처리까지 내장하며, 두드러진 성능차이가 발생합니다.
마이크로서비스 기반의 이벤트 테이블은 웨어하우스의 대표적 FACT 테이블보다 10배 이상 큽니다. 실시간 분석 요구가 커짐에 따라 배치/스트림 분리 없이 이벤트 데이터까지 엔드투엔드로 처리하는 효율성도 숙지해야 합니다. 벤치마크는 EVENT 테이블이 FACT/DIMENSION 테이블 대비 어느 정도 스케일을 가지는지도 반드시 반영해야 합니다.
증분 적재뿐 아니라, 기록 삭제·백필·컬럼 추가 등 다양한 병렬 작업이 빈번히 백그라운드에서 발생합니다. 현재 대부분의 데이터 플랫폼이 낙관적으로 무경합까지 가정하는데, 실제론 경쟁 상태가 빈번하므로 동시성 하의 처리량까지 평가 대상이 되어야 합니다.
공식 TPC-DS 스펙은 OLAP 플랫품의 표준 벤치마크로 가장 널리 쓰입니다. 복잡한 스노우플레이크 스키마, 많은 테이블·컬럼, 현실적인 비선형 확장, 다양한 쿼리 유형(스캔/조인/집계 등) 덕분에 쿼리플래너 및 엔진 최적화를 폭넓게 테스트할 수 있습니다. 쿼리 성능 측정에는 탁월하지만, 실질적 적재(L)나 증분(Incremental Load) 성능, 혹은 다양한 업데이트 패턴 측정에 심각한 한계가 있습니다.
데이터 유지 러닝은 26개 테이블 중 20개에 대해 증분적 데이터 적재, SCD(Slowly Changing Dimension) 관리, 기록 삭제까지 지원합니다. 하지만 실제 워크로드와는 다르게 Fact 테이블은 업데이트 없이 삭제만 가능, Dimension만 랜덤 업데이트가 발생한다는 강력한 제한이 있습니다.
마이크로소프트가 제안한 LST-Bench는 Hudi, Delta Lake, Iceberg 등 로그-구조 테이블의 수명, 내구성, 동시성, 타임트래블 쿼리를 더 현실적으로 측정하도록 설계되었습니다. 각 페이즈마다 병렬 작업, 백그라운드 작업, 데이터 상태 반복 변화 등 최신 데이터 레이크의 특성을 반영합니다.
TPC-DS 기반이기에 기본 데이터 유지 패턴(업데이트, 삭제 패턴이 단순/제한적, 이벤트성 테이블 없음)이라는 근본적 한계가 남아 있습니다.
TPC-DI는 ETL/DI 시장 최초로 공식 히스토리·증분 데이터를 포함하며, 실제 입력 이력에 맞춘 업데이트/삭제 모델, 다양한 집계/변환 조합까지 제공합니다. 그러나 현실에서 FACT/DIM 관계, 각 테이블별 배포/스케일 패턴, 복잡성 등에서 여전히 단순화 문제가 큽니다. 특히 업데이트/삭제 패턴의 유연성 결여, 최신 분산/이벤트 워크로드 부족, 실 사용 사례 부재 등이 단점입니다.
| 벤치마킹 요구사항 | 현존 도구의 한계 |
|---|---|
| 증분 추출 | TPC-DS, TPC-DI 모두 변화 데이터 기반 지능적 추출이 아님 |
| 변환 속도 | TPC-DS는 ET 성능 측정에 매우 적합 |
| 레코드 삭제 | 일부 삭제 지원하나 GDPR 등 동시/백그라운드 성능 측정은 불가 |
| 테이블 최적화 | LST-Bench로 일부 자동화 가능, 모형·스토리지 선택 신중 필수 |
| 현실적 업데이트/삭제 | 현실 반영 불가. 일상적 ETL 성능에 가장 큰 영향 |
| 이벤트 스트리밍 | EVENT 테이블 없음. 사용자 직접 고용량 스케일 전제 측정 필요 |
| 동시성 처리량 | LST-bench 활용 가능, but 실 경합/증분 병렬 로드 테스트 추가 필요 |
요약하면, 현실에 가까운 ETL 벤치마크를 위해서는 이벤트/대용량, 다종 업데이트·삭제 패턴, 다중 동시 증분/삭제 작업 등 현실 기반 조합이 필수입니다.
실제 OSS 사용자와 고객에서 L(쓰는) 작업이 ETL 전체의 20-50%를 차지한다는 인식 자체가 낮습니다. 예를 들어, TPC-DS 벤치마크 기준 약 2,300초에 한 번의 전체 적재, 99개 쿼리 수행 시 4,000초 내외가 소요됩니다. 실제 ETL 파이프라인에서 MERGE INTO 등 복합 작업이 빈번할수록 L 단의 비용과 시간이 눈에 띄게 커집니다.
그림: ETL 파이프라인 모델별 ET/L 분할 비용 추이
대규모 오픈소스 레이크 프로젝트(Delta, Hudi, Iceberg) 이슈 및 실제 테이블 스냅샷 분석 결과, 단순 INSERT뿐 아니라 MERGE/DELETE/UPDATE 빈도가 매우 높습니다. 각 테이블(FACT, DIM, EVENT)별 특성이 명확히 드러납니다.
OSS 이슈, Onehouse 관리 중인 1PB 규모 테이블 분석에서도 인서트/머지가 반반 가깝고, 구조별로 타이밍이나 분포, 백필, 병렬 프로세스 등이 성능에 큰 영향을 줍니다.
그림: Hudi, Delta Lake, Iceberg 주요 OSS SQL 관련 이슈 유형 위주 분석
업데이트/삭제 분포 역시 각 테이블 별로 극명히 달라집니다.
Reference data(사용자, 상품 등) 역할, 전체 데이터 범위에 걸쳐 랜덤·균등 업데이트 반복. 작은 크기일 가능성이 높으나, MERGE 작업의 I/O 비용이 폭증할 수 있음.
규모가 큰 테이블, 이벤트 시간(날짜) 파티셔닝, 대부분의 업데이트·쓰기 작업은 최근 파티션에 몰림(늦은 데이터, 네트워크 지연 등으로 트리클성 랜덤 업데이트도 일부 존재).
많은 양의 이벤트/로그 데이터, 거의 append-only, 일부 GDPR 등으로 랜덤/희소 삭제 요구. 동시성, 초대형 스케일, 초저지연 인서트가 필수.
우리는 수년간 내부적으로 사용해온 Lake Loader™를 오픈소스로 공개합니다!
입출력 분리 덕분에 동일 패턴 반복 재생, 여러 플랫폼 간 성능·비용 정밀 비교 가능, 장기적 증분 테스트도 수월합니다.
직접 체험 가능한 계산기/코드도 제공되니 사용해보실 것을 추천합니다.
엔지니어라면 측정하지 않으면 최적화도, 개선도 불가하다는 점을 새겨야 합니다. ETL 파이프라인의 현실(잦은 업데이트, 대용량 이벤트, 편향된 변이, 동시 백필·삭제·GDPR 처리 등)을 벤치마크 도구가 제대로 반영해야 진짜 TCO를 산출할 수 있습니다.
우리는 Lake Loader™라는, 시간 경과에 따라 증분 데이터 변화를 사실적으로 시뮬레이션하는 벤치마킹 툴을 오픈소스화했습니다. Spark/Hudi/Iceberg/Delta Lake와 호환되며, 손쉽게 실전 패턴을 측정·비교할 수 있습니다. 이제 시간대별, 일별 등 실제 운영 패턴으로 효과를 실질적으로 확인할 수 있습니다.
앞으로도
을 추구합니다. MERGE INTO 튜닝에 애를 먹거나, GDPR 삭제가 느린 원인을 찾거나, 실전 workload 벤치마크를 원하셨다면 지금이 참여할 기회입니다.
👉 레포 포크/사용/이슈 등록/패턴 기여 환영: https://github.com/onehouseinc/lake-loader
