Observability 를 위한 컬럼형 데이터베이스 ClickHouse 소개

로그와 트레이스가 매일 수십 TB씩 쌓이는 기업이라면, Elasticsearch 기반 모니터링 스택의 저장 비용이 인프라 예산에서 가장 빠르게 늘어납니다. Cloudflare·Uber·Sentry 같은 글로벌 기업이 2016년 공개 이후 각자 독립적으로 같은 결론에 도달한 도구가 컬럼 지향 OLAP 데이터베이스 ClickHouse 입니다. 국내 인프라 조직의 관측 가능성(observabil…

2026년 06월 22일

왜 지금 ClickHouse인가?

관측 가능성 데이터는 본질적으로 OLAP(온라인 분석 처리) 워크로드입니다. 수억 행을 스캔한 뒤 시간대별·서비스별로 집계하는 패턴이 대부분이기 때문입니다. 그런데 ELK(Elasticsearch·Logstash·Kibana) 스택은 텍스트 검색용 역색인(inverted index) 구조라, 집계가 늘수록 저장 용량과 쿼리 지연이 함께 커집니다. ClickHouse 는 2009년 Yandex 에서 출발해 2014년부터 프로덕션에서 검증됐고, 2024년 150억 달러 평가를 받은 독립 엔진입니다(백서 1장). 그래서 인프라 조직은 자사 저장 비용 추세부터 점검해야 합니다.

Observability 비용을 잡는 ClickHouse 도입 기준 - 백서 다운로드

CNF 백서 구독하기🔔

새로운 백서가 발간되면 가장 먼저 안내드려요!

CNF가 전하는 최신 백서와 클라우드 인사이트를 가장 빠르게 만나보실 수 있습니다.

진심으로 구독 부탁드립니다 🙏

기존 데이터베이스들이 분석에서 무너지는 지점

MySQL·PostgreSQL 같은 행 지향 데이터베이스는 한 행의 모든 컬럼을 디스크에 붙여 저장합니다. 단건 조회에는 최적이지만, “지난 30일 서비스별 오류율” 같은 집계는 필요 없는 컬럼까지 전부 읽어 I/O(입출력)를 수십 배 낭비합니다. 제품 분석 도구 PostHog 는 PostgreSQL 위에서 집계 쿼리가 18초, P95(상위 5% 느린 쿼리) 지연이 60초까지 치솟는 한계를 겪었습니다(백서 5장). 근본 원인은 분석 워크로드와 행 지향 저장의 구조적 불일치였습니다. 그래서 검토 조직은 자사 쿼리가 집계형인지 단건 조회형인지부터 점검해야 합니다.

컬럼 지향과 벡터화가 만드는 성능 차이

ClickHouse 의 정량 우위는 세 설계가 연쇄로 작동한 결과입니다. 컬럼 지향(columnar) 저장이 읽을 데이터 범위를 줄이고, ZSTD·LZ4 압축이 저장 공간을 줄이며, 벡터화 실행이 남은 CPU 작업을 SIMD(한 명령으로 여러 값을 동시에 계산) 명령으로 가속합니다. 핵심 엔진 MergeTree 는 INSERT 를 잠금 없이 받아 두고 백그라운드에서 데이터를 키 순서로 병합하므로, 초당 수십만 건을 받으면서도 집계는 밀리초 단위로 응답합니다(백서 4장).

-- 관측 로그용 MergeTree 테이블 예시
CREATE TABLE otel_logs (
    timestamp DateTime64(9),
    service   LowCardinality(String),
    severity  LowCardinality(String),
    body      String
) ENGINE = MergeTree
ORDER BY (service, timestamp);

ORDER BY 키와 LowCardinality 타입만 워크로드에 맞게 잡아도 압축률과 조회 성능이 크게 달라집니다. 같은 컬럼 지향 제품인 Vertica·Greenplum 대비 5~24배 빠른 성능이 이 구조에서 나옵니다(백서 2장).

글로벌 채택사가 검증한 정량 효과

수치는 한 회사의 주장이 아니라 여러 조직의 독립 검증으로 모입니다. 동일한 OpenTelemetry 로그 기준 10억 행에서 Elasticsearch 가 245GB 를 쓸 때 ClickHouse 는 49GB 만 썼고, 500억 행에서는 12TB 대 2.4TB 로 벌어졌습니다(백서 6장). 전체 저장 비용으로 환산하면 60~70% 절감입니다. Cloudflare 는 문서당 저장을 600바이트에서 60바이트로 줄였고(백서 5장), Uber 는 ELK 를 걷어내며 일부 쿼리를 50배 가속하고 클러스터를 절반 이상 줄였습니다(백서 5장).

사례	핵심 지표	효과
Elasticsearch 대비	10억 행 저장	245GB → 49GB
Cloudflare	문서당 저장	600B → 60B
Uber	쿼리 속도	최대 50배
PostHog	P95 지연	60초 → 4초

자사 환경에서 확인하려면 가장 비슷한 사례를 PoC(개념 검증) 기준선으로 삼아 한 워크로드부터 적용해야 합니다.

도입을 결정하기 전에 점검할 핵심

ClickHouse 도입을 검토하는 조직은 기술 우위만큼 라이선스와 운영 조건도 함께 따져야 합니다. 다음 네 가지를 순서대로 점검해야 합니다.

라이선스: ClickHouse 는 Apache 2.0 이라 상업 임베드·SaaS 백엔드 모두 소스 공개 없이 쓸 수 있습니다(백서 3장). 배포 형태별 LICENSE·NOTICE 의무를 먼저 점검해야 합니다.
워크로드 적합성: 집계·시계열 조회가 많은지 단건 트랜잭션이 많은지 구분해 적용 범위를 결정해야 합니다.
전환 위험: 전면 교체 대신 PostHog 식 점진 전환으로 분석 쿼리만 옮기며 착수해야 합니다.
운영 체계: ReplicatedMergeTree 와 ClickHouse Keeper 로 복제·장애 대응을 어떻게 구성할지 준비해야 합니다.

정리하면, ClickHouse 도입 결정은 “빠른 데이터베이스”를 고르는 문제가 아니라 관측 가능성 백엔드의 저장 비용 구조와 쿼리 패턴을 다시 설계하는 문제입니다. 검증된 글로벌 사례와 Apache 2.0 라이선스, 컬럼 지향·MergeTree 아키텍처를 함께 놓고 보면 ClickHouse 도입 판단의 근거는 사실로 충분히 뒷받침됩니다.

자주 묻는 질문 정리

ClickHouse는 Elasticsearch와 무엇이 다른가요?
Elasticsearch 는 텍스트 검색용 역색인 구조이고, ClickHouse 는 집계에 강한 컬럼 지향 OLAP 데이터베이스입니다. 모니터링 쿼리 대부분이 집계형이라 저장 용량과 속도 양쪽에서 유리합니다.

ClickHouse로 바꾸면 저장 비용은 얼마나 줄어드나요?
글로벌 사례 기준 전체 저장 비용 60~70% 절감이 보고됐고, 10억 행 비교에서 245GB 가 49GB 로 줄었습니다(백서 6장). 로그 압축률은 10:1~20:1 수준으로 나타납니다.

ClickHouse 라이선스는 상업적으로 안전한가요?
ClickHouse 는 Apache 2.0 라이선스라 소스 공개 의무 없이 상업 제품 임베드와 SaaS 운영이 가능합니다. LICENSE·NOTICE 파일 보존 의무만 지키면 됩니다(백서 3장).