OLAP 재정의: 2026년의 분산
- 년 전, OLAP라 하면 Vertica, Redshift, Snowflake 같은 중앙 집중형 대규모 분산 클러스터가 대명사였습니다. 2026년의 풍경은 완전히 달라졌습니다. 서버리스화된 ClickHouse Cloud가 초 단위 스케일을 실현하는 한편, DuckDB는 단일 프로세스로 수백 GB를 처리하고, 브라우저 내 WASM에서 동작하는 DuckDB로 프론트엔드에서 S3의 Parquet을 직접 쿼리하는 구성이 현실이 되었습니다.
KGA가 2026년 Q1에 받은 분석 인프라 상담 23건 중, 기존의 "Snowflake/BigQuery에 모두를 집약한다"는 구성을 처음부터 선택한 것은 9건이었습니다. 나머지 14건은 "중앙의 data warehouse(Snowflake 또는 BigQuery)와 현장의 경량 OLAP(ClickHouse/DuckDB)를 역할 분담시킨다"는 하이브리드 구성을 선택했습니다. 실제로 용도를 분리함으로써 총 비용이 30~50% 절감되는 경우가 많습니다.
ClickHouse Cloud의 2026년 포지션
ClickHouse Cloud는 2024년의 서버리스 대응, 2025년의 SharedMergeTree(컴퓨트와 스토리지의 완전 분리), 그리고 2026년의 Query Condition Cache와 Parallel Replica 자동화로 운영 편의성과 성능의 양립이 최고 수준에 도달했습니다. KGA의 광고 게재 고객에서는 초당 200만 이벤트의 수집과 초 응답 대시보드 쿼리를 기존 대비 40% 낮은 비용으로 처리하고 있습니다.
ClickHouse가 압도적으로 강한 것은 다음 특성이 모두 갖춰진 워크로드입니다.
- 쓰기가 append-only인 시계열/이벤트 로그: 광고 임프레션, 게임 이벤트, IoT 텔레메트리, APM 트레이스, 웹 분석.
- 단일/소수 테이블에 대한 집계 쿼리가 주류: GROUP BY, SUM, COUNT, PERCENTILE.
- 저레이턴시의 인터랙티브 대시보드: P95 500ms 이하 응답이 요구되는 용도.
- 카디널리티가 높은 차원에서의 집계: user_id, session_id, trace_id 축의 분석.
반대로, 다수 테이블 join이 많고, update/delete가 빈번하며, ad-hoc 탐색이 중심인 워크로드는 Snowflake/BigQuery가 더 적합합니다. 2026년의 ClickHouse는 Parallel Hash Join, Grace Hash Join의 성숙으로 join 내성이 상당히 향상되었지만, 10개 이상의 테이블로 구성된 star schema에서는 여전히 다른 MPP가 더 안정적입니다.
DuckDB 1.2의 충격
DuckDB는 "in-process OLAP 데이터베이스"로, 라이브러리로서 애플리케이션에 내장할 수 있습니다. 1.2에서의 진화는 세 가지 점이 중요합니다.
HTTP server 모드: 지금까지 library-only였던 DuckDB가 HTTP 서버로 기동할 수 있게 되었습니다. Python/Go/TypeScript에서 HTTP를 통해 쿼리를 보내고, 결과를 JSON/Arrow IPC로 받는 구성이 안정화되었습니다. 경량 데이터 API의 뒤단으로 ClickHouse보다 구축이 빠릅니다.
Iceberg/Delta 읽기/쓰기: 1.1 시점에서 Iceberg 읽기, 1.2에서 Iceberg 쓰기가 구현되었습니다. S3의 Iceberg 테이블을 DuckDB에서 직접 읽고 쓸 수 있어, 레이크하우스에 대한 경량 접근이 가능합니다.
WASM 성능: 브라우저 내에서 동작하는 DuckDB-WASM이 SIMD 최적화와 병렬 Worker 대응으로, 데스크톱 버전의 60~70% 성능을 낼 수 있게 되었습니다. Observable, Evidence.dev, Perspective 같은 BI 툴이 이 위에 구축되어 있으며, "프론트엔드만으로 100GB의 Parquet를 분석한다"는 것이 브라우저에서 완결됩니다.
KGA의 지자체 고객에서는 오픈 데이터 시각화 대시보드를 DuckDB-WASM으로 구현했습니다. S3에 있는 공개 Parquet를 직접 브라우저가 읽고, 집계·시각화를 모두 클라이언트 사이드에서 처리합니다. 서버 측 컴퓨팅 리소스가 제로이고, 스케일 비용도 실질적으로 제로입니다. 100만 사용자까지 부하 테스트를 통과했습니다.
MotherDuck의 상업적 정착
MotherDuck은 DuckDB를 토대로 한 매니지드 서비스로, 2024년 베타에서 2025년 GA를 거쳐, 2026년에는 중소 규모 분석 워크로드에서 Snowflake/BigQuery의 현실적인 대안으로 자리 잡았습니다.
최대 특징은 "하이브리드 실행"입니다. 쿼리의 일부(파일 읽기, 필터링)를 클라우드 측에서, 나머지를 로컬 DuckDB 측에서 실행함으로써 데이터 전송을 최소화하면서 로컬 컴퓨팅 자원을 활용합니다. 특히 Python 개발자에게, 노트북 내에서 `motherduck`을 attach하면 대규모 클라우드 테이블과 로컬의 CSV/Parquet를 원활하게 JOIN할 수 있는 경험은 다른 곳에서 얻기 어렵습니다.
요금도 매력적으로, 10GB 이하의 데이터라면 무료 플랜으로 운용 가능합니다. 100GB~1TB 규모의 분석이라면 Snowflake의 1/5 정도 비용으로 처리할 수 있습니다. 단, 10TB 이상 규모나 동시 병렬 사용자 50명을 초과하는 대시보드 용도에서는 MotherDuck보다 Snowflake/ClickHouse가 적합합니다.
Turso와 LibSQL의 독자 노선
Turso는 SQLite 포크인 LibSQL을 기반으로 한 엣지 분산 SQL 데이터베이스로, 엄밀히는 OLAP보다 OLTP에 가깝지만, 2026년에 도입된 Analytics 확장(AlloyDB Columnar처럼 행 지향과 열 지향을 병용하는 구조)으로 소~중 규모 분석에도 대응하게 되었습니다.
특징적인 것은 데이터베이스를 전 세계 엣지에 복제할 수 있는 멀티 테넌트 구성입니다. Cloudflare Workers나 Vercel Edge Functions에서 단 몇 밀리초로 쿼리할 수 있는 것이 강점입니다. IoT 기기 제조사나 SaaS의 대시보드 용도에서, 지리적으로 분산된 사용자에 대한 응답 성능이 문제가 되는 경우에 적합합니다.
OLAP 순수 용도로는 DuckDB/ClickHouse에 미치지 못하지만, "OLTP겸 경량 분석을 단일 DB로 해결하고 싶다" "엣지에 배포하고 싶다"는 경우에는 첫 번째 후보입니다.
Tiered storage와 hot/cold 설계
- 년 OLAP 운영에서 필수가 된 것이 tiered storage(계층형 스토리지)입니다. ClickHouse Cloud는 SharedMergeTree에서 S3/GCS가 프라이머리 스토리지, 로컬 NVMe가 캐시 레이어라는 구조를 표준으로 합니다. Snowflake/BigQuery도 유사한 구조이지만, ClickHouse에서는 cache policy를 명시적으로 튜닝할 수 있다는 것이 차이점입니다.
KGA의 광고 고객에서는 "지난 30일 = hot(NVMe 캐시 상주), 31~180일 = warm(S3, 온디맨드로 NVMe에 로드), 181일 이후 = cold(S3 Glacier, 쿼리 시 Athena로 직접)"라는 3계층 설계로 스토리지 비용을 80% 절감했습니다. 쿼리 성능은 hot/warm은 실질적으로 동등하고, cold만 10~20배 느리지만, 180일 이상 된 데이터를 인터랙티브하게 접근하는 요건은 드물기 때문에 허용됩니다.
일본어 워크로드의 함정
일본 기업의 데이터 분석에 특유한 과제를 다섯 가지 들겠습니다.
1. 타임존: JST(UTC+9)와 UTC의 혼재로 날짜 경계가 하루 어긋나는 버그는 2026년에도 빈발합니다. ClickHouse는 `DateTime64`의 `'Asia/Tokyo'` 타임존 파라미터로 명시화하고, BigQuery/Snowflake는 UTC 저장 + 표시 시 변환을 철저히 합니다. DuckDB는 `TIMESTAMPTZ` 형의 도입으로 1.2부터 안정화되었습니다.
2. 멀티바이트 문자와 collation: 전각 스페이스, 반각·전각 영숫자, 구자체를 포함한 고객명/상품명 비교에서 UTF-8의 바이트 비교만으로는 부족합니다. ClickHouse는 ICU 확장으로, DuckDB는 NFKC 정규화 함수로 대응합니다. 집계 키로 사용하는 경우에는 사전에 정규화 파이프라인을 구성하는 것이 철칙입니다.
3. 한자 숫자·일본식 연호: "레이와 6년 3월" 같은 표현을 다루는 장면이 관공서 프로젝트에서는 피할 수 없습니다. SQL 레벨에서 완결시키지 않고, 수집 시 ISO 8601로 정규화하여 저장하는 것이 건전합니다.
4. CP932/Shift_JIS의 혼입: 레거시 기간 시스템에서의 CSV 내보내기에서 여전히 등장합니다. DuckDB의 `read_csv`는 1.2부터 encoding 파라미터 대응이 공식 GA가 되었습니다. ClickHouse는 `INPUT` 함수로 변환합니다.
5. 반각 가타카나: 은행계 데이터에서는 아직도 존재하며, NFKC로 전각으로 변환하면 "ｶ"와 "カ"가 동일 값이 되지만, 원본 데이터가 키로서 반각을 기대하는 경우에 문제가 발생합니다. 변환 규칙은 조기에 확정하여 문서화해야 합니다.
2026년 권장 아키텍처
KGA가 고객에게 권장하는 "현대적인 분석 데이터 스택"은 다음과 같은 역할 분담입니다.
- 중앙 DWH(Snowflake / BigQuery / Databricks): 전사 횡단 분석, 재무, 경영 지표. 레이크하우스(Iceberg) 쓰기로 외부에 개방.
- 실시간 OLAP(ClickHouse Cloud): 초 단위 대시보드, 광고·게임·IoT 이벤트, APM.
- 노트북/국소 분석(DuckDB + MotherDuck): 데이터 사이언티스트의 시행착오, 중간 데이터 마트 생성.
- 브라우저 측 시각화(DuckDB-WASM): 공개 대시보드, 사내 BI의 경량 프론트엔드.
- 엣지 OLTP+Analytics(Turso): 지리 분산 SaaS의 테넌트별 DB.
이 5계층을 Semantic Layer(Cube.dev 등)로 통합하고, LLM 에이전트에서 자연어로 모든 것을 끌어낼 수 있는 구성이 2026년판 "모던 데이터 스택"의 도달점입니다. 단일 벤더로 완결시키는 것이 아니라, 역할별로 최적 툴을 선정하고 메타데이터와 시맨틱스로 접합하는 설계가 장기적으로 가장 비용 효율과 확장성이 높습니다.