Season 5 Ep 3 — Ep 1이 저장, Ep 2가 흐름이었다면 Ep 3은 쿼리. "하나의 엔진이 모든 걸 한다"는 시대는 끝났고, 엔진 배치(Engine placement)가 새로운 설계 영역이 됐다.
- Prologue — "엔진은 도구, 문제는 워크로드"
- 1장 · OLAP 엔진 분류
- 2장 · DuckDB — "단일 노드 OLAP의 혁명"
- 3장 · ClickHouse — "실시간 OLAP의 왕"
- 4장 · Snowflake·BigQuery — "관리형 거인"
- 5장 · StarRocks·Doris — "MPP 실시간 BI"
- 6장 · Apache Pinot·Druid — "초저지연 OLAP"
- 7장 · Trino·Presto — "연합 쿼리(Federated Query)"
- 8장 · Databricks SQL·Redshift
- 9장 · 벤치마크의 함정
- 10장 · 엔진 배치(Engine Placement) 패턴
- 11장 · 한국 기업 선택 가이드
- 12장 · 성능 튜닝 범용 원칙
- 13장 · 안티패턴 10선
- 14장 · 체크리스트 — OLAP 엔진 도입 전 12가지
- 15장 · 다음 글 예고 — Season 5 Ep 4: "dbt·SQLMesh·Dagster·Airflow·Prefect"
Prologue — "엔진은 도구, 문제는 워크로드"
2015–2020 OLAP 논쟁은 "어떤 엔진이 가장 빠른가"였다. 2025년은 다르다:
- 벤치마크는 마케팅 도구다(TPC-H·TPC-DS의 해석은 조건부)
- 엔진마다 특정 워크로드에 압도적 강점이 있다
- 한 회사가 2–4개 엔진을 쓰는 게 일반적이다
- "적재적소 배치"가 비용·성능·팀 역량 모두 결정한다
이 글은 2025년 주요 OLAP 엔진의 현실적 장단점과 배치 전략을 정리한다.
1장 · OLAP 엔진 분류
1.1 축 4개
- 배포: 단일 노드 / 분산 MPP / 서버리스
- 워크로드: BI (복잡 조인) / Real-time (낮은 지연) / Ad-hoc (탐색)
- 관리형 vs 셀프: SaaS / 오픈소스 + 셀프 운영
- 데이터 위치: 내장 스토리지 / Lakehouse 연동
1.2 주요 엔진 분류
| 엔진 | 배포 | 주 워크로드 | 모델 |
|---|---|---|---|
| DuckDB | 단일 | Ad-hoc, Embedded | 오픈 |
| ClickHouse | 분산 | Real-time, Log | 오픈 + Cloud |
| Snowflake | 서버리스 | BI, ELT | SaaS |
| BigQuery | 서버리스 | BI, ELT | SaaS |
| Databricks SQL | 분산 | BI + ML | 관리형 |
| Redshift | 분산 | BI | 관리형 |
| StarRocks | 분산 | Real-time BI | 오픈 + SaaS |
| Apache Doris | 분산 | Real-time BI | 오픈 |
| Apache Pinot | 분산 | 초저지연 | 오픈 |
| Apache Druid | 분산 | 시계열·스트림 | 오픈 |
| Trino/Presto | 분산 | 연합 쿼리 | 오픈 |
2장 · DuckDB — "단일 노드 OLAP의 혁명"
2.1 정체성
- 2019 CWI에서 시작
- Embedded OLAP: SQLite가 OLTP를 노트북에 가져왔듯, DuckDB는 OLAP를 노트북에
- Parquet/CSV/JSON 직접 쿼리, Iceberg·Delta 읽기 확장
2.2 강점
- 설치 5초, 단일 바이너리
- Python/R/Node/Go/Rust 바인딩
- 8–16GB RAM에서 수십억 행 분석 가능(열 기반 + 벡터화)
- Parquet을 "네이티브 SQL로" 쿼리
2.3 2024–2025 모멘텀
- MotherDuck: DuckDB의 클라우드 확장
- Iceberg·Delta 읽기 지원 정식화
- DuckDB WASM으로 브라우저 내 OLAP
- dbt-duckdb로 로컬 개발·CI 표준
2.4 제한
- 단일 노드(수직 스케일 한정)
- 동시성은 앱 내 수 수준
- 대규모 서버 클러스터 대체는 아님
2.5 쓰는 곳
- 분석가 로컬 개발
- CI에서 데이터 검증
- 중소 프로젝트 OLAP 백엔드
- Notebook/Python 스크립트의 SQL 엔진
3장 · ClickHouse — "실시간 OLAP의 왕"
3.1 정체성
- 2009 Yandex 내부 → 2016 오픈소스 → 2021 ClickHouse Inc.
- 분산 컬럼형, MergeTree 엔진 기반
- 실시간 수십억 행 삽입 + 초 단위 쿼리
3.2 강점
- 압도적 삽입·쿼리 성능(특정 워크로드)
- 실시간 dashboards의 사실상 표준
- Kafka/Kinesis Engine으로 직접 consumer
- 비용 효율(자체 운영 시)
3.3 2024–2025 동향
- ClickHouse Cloud (SaaS) 급성장
- Iceberg 읽기 확대
- Materialized view·Dictionary 고도화
- 많은 관측성 플랫폼(Datadog 일부, Axiom, Tinybird, PostHog)이 ClickHouse 기반
3.4 제한
- JOIN 최적화가 일부 엔진 대비 약함(최근 크게 개선)
- 운영 복잡(셀프 시)
- SQL 호환성 일부 차이
3.5 쓰는 곳
- 로그·이벤트 분석
- 실시간 대시보드
- Ads/Marketing analytics
- APM/Observability 백엔드
4장 · Snowflake·BigQuery — "관리형 거인"
4.1 Snowflake
- 서버리스, 컴퓨트·스토리지 분리
- Multi-cluster warehouse(자동 스케일)
- Native Iceberg table(2024)
- Cortex AI(LLM·ML 기능 통합)
- 데이터 공유(Data Sharing)
4.2 BigQuery
- Google Cloud 서버리스
- Slot 기반 컴퓨트, 빠른 ad-hoc
- Iceberg External + BigLake
- Gemini 통합(쿼리 SQL 자연어)
- BI Engine(in-memory 가속)
4.3 강점
- 운영 부담 제로
- 초기 셋업 며칠
- 보안·감사·백업 내장
- 대기업·엔터프라이즈에 압도적 점유
4.4 제한
- 비용: 규모가 커지면 월 수만–수십만 달러
- 락인(Iceberg 지원으로 완화 중)
- 일부 워크로드(초저지연)에 부적합
4.5 2025년 전략
- Iceberg External Table로 Lake의 외부 데이터 쿼리
- Hot/Cold 분리: Hot은 네이티브, Cold는 Iceberg
- dbt·Airflow·Dagster 통합이 표준
5장 · StarRocks·Doris — "MPP 실시간 BI"
5.1 공통점
- 실시간 + BI + Lakehouse 지원
- Iceberg/Hudi/Delta 읽기
- MySQL 프로토콜 호환(BI 친화)
- 중국 기원, 글로벌 확장
5.2 StarRocks
- Apache DorisDB 포크 → 독립
- CelerData가 상용 지원
- 2024–2025 빠른 성장
- Cost-based optimizer 성숙
5.3 Apache Doris
- Apache 재단 프로젝트
- Baidu 기원
- Routine Load(Kafka 직결)
- 실시간 대시보드에 강함
5.4 강점
- 실시간 + 복잡 조인 둘 다 강함
- Lakehouse + 자체 스토리지 이중 운영
- ClickHouse 대비 JOIN 우위
5.5 쓰는 곳
- 실시간 운영 BI
- Lakehouse 엔진 보완
- 중국·한국·일본에서 채택 증가
6장 · Apache Pinot·Druid — "초저지연 OLAP"
6.1 Apache Pinot
- LinkedIn 기원 → Apache
- 100ms 미만 쿼리 지연 목표
- Upsert 지원(2023–)
- StarTree (SaaS) 제공
6.2 Apache Druid
- Metamarkets 기원 → Imply가 상용
- 시계열·스트림에 특화
- Kafka indexing service
6.3 쓰는 곳
- LinkedIn, Uber, Netflix 등 초저지연 분석
- 사용자 대면 대시보드(Customer-facing)
- 실시간 추천·이상탐지
6.4 운영 난이도
- 셋업 복잡, 운영 엔지니어 필요
- SaaS(StarTree/Imply)가 부담 경감
6.5 ClickHouse·StarRocks와의 차이
- Pinot/Druid: 100ms 미만 초저지연에 특화
- ClickHouse: 광범위한 워크로드 + 뛰어난 가성비
- StarRocks: BI 복잡 조인 + Lakehouse 친화
7장 · Trino·Presto — "연합 쿼리(Federated Query)"
7.1 정체성
- Facebook Presto → Trino(2020 포크, 원 개발자들)
- Iceberg/Delta/Hudi, Hive, MySQL, Postgres, Kafka 등 수십 커넥터
- 여러 데이터 소스를 하나의 SQL로
7.2 강점
- 멀티 소스 JOIN
- Iceberg 읽기·쓰기 최고 성능 중 하나
- 셀프 호스팅 가능
- 기업 내 "중앙 쿼리 엔진" 역할
7.3 Starburst
- Trino 상용 배포, 엔터프라이즈 기능·지원
- Gateway·캐시·보안 통합
7.4 제한
- 대시보드용보다는 ad-hoc·ELT 강점
- 운영 복잡(Coordinator·Worker 관리)
- 실시간 수집보다 읽기 중심
7.5 Presto vs Trino
- Presto: Meta/PrestoDB 유지
- Trino: 사실상 커뮤니티 표준
- 2025년 신규는 Trino 선택이 일반적
8장 · Databricks SQL·Redshift
8.1 Databricks SQL
- Delta + Spark 기반 SQL warehouse
- Photon 엔진(벡터화)
- 2024 Iceberg UniForm 지원
- ML + BI 통합이 강점
8.2 Redshift
- AWS 전통 DW
- RA3 + AQUA로 컴퓨트·스토리지 분리
- Spectrum으로 S3 Iceberg 접근
- AWS 생태계와 깊은 통합
8.3 쓰는 곳
- Databricks SQL: 이미 Databricks 쓰는 팀
- Redshift: AWS 중심 기업, SAP·Salesforce 연결
8.4 2025 전략
- Databricks: Iceberg 호환 + Mosaic AI
- Redshift: 서버리스·AI 통합 강화
- 둘 다 락인 완화 방향
9장 · 벤치마크의 함정
9.1 TPC-H·TPC-DS
- 업계 표준이지만 실제 워크로드와 다름
- 엔진 벤더가 자체 튜닝한 결과로 홍보
- 쿼리 플랜·데이터 스케일·동시성 설정이 결과 크게 좌우
9.2 ClickBench
- ClickHouse 팀 주도(공정성 논란 있음)
- 하지만 다양한 엔진 비교 가능한 오픈 벤치
9.3 StarSchema·JOB
- 복잡 조인 벤치, 실제에 가까움
- 엔진 간 격차 드러내기 유용
9.4 실전 평가 프로토콜
- 자체 데이터 샘플링(10–100GB)
- 자주 쓰는 쿼리 5–15개
- 동시성 10–100 모의
- 비용 대비 성능 계산
- 운영 복잡도 평가(인프라·모니터·온콜)
9.5 "가격-성능 비율"이 진짜 지표
- 단순 ms 단위보다 $/쿼리 또는 $/TB 스캔
- 동시 사용자 수·대기 시간 SLA도 포함
10장 · 엔진 배치(Engine Placement) 패턴
10.1 "하나의 엔진" 안티패턴
- Snowflake만으로 모든 걸 → 초저지연 실패, 비용 폭증
- ClickHouse만으로 모든 걸 → BI 복잡 조인·관리 부담
- Trino만으로 모든 걸 → 실시간 불가
10.2 "2–4 엔진" 현실적 패턴
패턴 A: Startup (소규모)
- DuckDB: 개발·CI
- Snowflake/BigQuery: 프로덕션 BI
패턴 B: SaaS (실시간 대시보드 중심)
- ClickHouse: 프로덕션 분석·고객 대면
- DuckDB: 로컬 분석
- Snowflake: 내부 BI + ELT
패턴 C: Enterprise (대기업)
- Snowflake/Databricks: 전사 BI
- Trino: Lakehouse 연합 쿼리
- ClickHouse/Pinot: 특정 고성능 앱
- DuckDB: 분석가 개발
패턴 D: 고성능 사용자 대면
- Pinot/Druid: 밀리초 UX
- ClickHouse: 관리자 대시보드
- BigQuery/Snowflake: 경영·전략 BI
10.3 데이터 공유
- 원본은 Iceberg에 집중
- 각 엔진이 Iceberg를 읽되, 필요시 자체 스토리지로 복제
- 메타데이터 카탈로그는 공통(Polaris/Unity/Glue)
11장 · 한국 기업 선택 가이드
11.1 현황
- 금융·공공: Teradata/Oracle + Hadoop → Snowflake/Databricks로 이관 중
- 커머스·게임: ClickHouse + BigQuery·Snowflake 혼재
- 스타트업: DuckDB + Snowflake/BigQuery 급증
11.2 한국 특수성
- 망분리 요구: 온프레 엔진(ClickHouse·StarRocks·Trino) 선호
- 한국어 SQL 툴 호환성(Metabase·Redash·Superset 등 한국어 화면)
- 대용량 로그·게임 분석: ClickHouse가 가성비 우위
- 금융 BI: Snowflake·Databricks 채택 급증
11.3 실무 추천 매트릭스
| 시나리오 | 1순위 | 보조 |
|---|---|---|
| 전사 BI (대기업) | Snowflake/BigQuery | DuckDB·Trino |
| 실시간 로그·APM | ClickHouse | Druid/Pinot |
| 사용자 대면 대시보드 | Pinot/StarTree | ClickHouse |
| ML + BI 통합 | Databricks SQL | Snowflake |
| Lakehouse 연합 | Trino | DuckDB |
| 스타트업 첫 DW | BigQuery/Snowflake | DuckDB |
| 온프레 · 금융 | StarRocks/Doris | ClickHouse |
12장 · 성능 튜닝 범용 원칙
12.1 스키마 설계
- Star schema (Fact + Dim)이 여전히 강력
- Denormalization 수준을 엔진·워크로드별로 조절
- 컬럼 타입 최적화(Int32 vs Int64 등)
12.2 파티션·정렬
- 시간 파티션 기본
- Sort key는 WHERE·JOIN 패턴 기반
- ClickHouse: Primary key = Sort key
12.3 인덱스·투영(Projection)
- ClickHouse: Skip index, Projection
- StarRocks: Bitmap index, MV
- Snowflake: Search Optimization Service
- Iceberg: Puffin 통계
12.4 캐시
- Result cache(쿼리 결과)
- Metadata cache
- Query plan cache
- CDN/edge cache(대시보드)
12.5 Materialized view
- 자주 쓰는 집계 프리컴퓨트
- 증분 업데이트가 핵심
- ClickHouse·Snowflake·Materialize가 강함
13장 · 안티패턴 10선
13.1 "하나의 엔진으로 모든 걸"
실패 확정. 워크로드별 분리.
13.2 벤치마크만 보고 선택
자체 데이터·쿼리로 재평가 필수.
13.3 프로덕션 부하 없이 PoC 승인
동시성·SLA 테스트 부족.
13.4 스타 스키마 무시
Denormalization 과잉 → 유지 악몽.
13.5 파티션 과잉
작은 파일 수만 개 → 플래닝 지옥.
13.6 Materialized view 관리 부재
오래되고, 비용만 쌓임.
13.7 운영 온콜 준비 없이 셀프 호스팅
ClickHouse·Trino·Druid는 온콜 부담 크다.
13.8 락인 무시하고 SaaS 올인
데이터 주권 + 비용 리스크.
13.9 쿼리 튜닝 없이 스케일업
비용만 늘고 근본 해결 X.
13.10 사용자 쿼터·가드레일 부재
"1명이 전체 다운타임" 야기.
14장 · 체크리스트 — OLAP 엔진 도입 전 12가지
- 워크로드 분해(BI/실시간/Ad-hoc/사용자 대면)
- 엔진 후보 3–5개 자체 벤치마크
- 가격-성능 매트릭스
- 운영 복잡도 평가(관리형 vs 셀프)
- 보안·감사·RBAC 요구사항
- Lakehouse 호환성(Iceberg/Delta/Hudi)
- BI 툴·ETL 툴 호환성
- 데이터 공유·카탈로그 전략
- 재해 복구·백업
- 확장성 시뮬레이션(10–100배)
- 인력·교육 플랜
- 엔진 배치 다이어그램 최종본
15장 · 다음 글 예고 — Season 5 Ep 4: "dbt·SQLMesh·Dagster·Airflow·Prefect"
엔진이 데이터를 쿼리한다면, 오케스트레이터는 파이프라인을 다스린다. Ep 4는 데이터 변환·오케스트레이션의 도구 생태계.
- dbt의 표준화와 한계
- SQLMesh의 등장: dbt의 대안인가 보완인가
- Dagster: 데이터 에셋(asset-centric) 오케스트레이션
- Airflow 2.x, 3.0의 진화
- Prefect 3.0의 재탄생
- Temporal과의 경계
- 데이터 계약(Data Contracts)과 스키마 진화
- CI/CD for data pipelines
- 관측성 + 경보
- 한국 기업 스택 선택
- "한 도구가 다 한다" vs "도구 체인" 균형
"데이터 파이프라인의 CI/CD"가 2025년 데이터 엔지니어링의 진짜 전선.
다음 글에서 만나자.
요약: 2025년 OLAP은 "하나의 엔진으로 모든 걸"의 환상에서 벗어나 워크로드별 엔진 배치의 시대가 됐다. DuckDB는 단일 노드와 개발·CI를, ClickHouse는 실시간 분석을, Snowflake·BigQuery·Databricks SQL은 관리형 BI를, StarRocks·Doris는 실시간 BI + Lakehouse를, Pinot·Druid는 초저지연 사용자 대면을, Trino는 연합 쿼리를 맡는다. 벤치마크는 시작점, 자체 워크로드 평가는 필수, 그리고 2–4개 엔진 배치가 현실적 지배 패턴. 한국 기업은 망분리·한국어 BI 툴·게임·금융 특수성을 고려해서 엔진 믹스를 설계한다. "엔진 배치가 데이터 플랫폼 설계의 핵심"이 2025년의 교훈.