AI 시대의 분석 기반으로서 ClickHouse를 선택하는 이유

AI 프로덕트의 데이터 기반은 단순한 「빠른 분석 DB」만으로는 부족해졌다.

RAG를 만들면 애플리케이션 로그, 사용자 행동, 프롬프트, 추론 결과, 평가 스코어, 문서의 메타데이터, 임베딩 벡터(Embedding Vector)가 같은 장소로 모여든다. 게다가 그것들을 나중에 분석하고 싶어진다.

그래서 ClickHouse가 후보에 오른다.

단, ClickHouse를 선택하는 이유는 「빠를 것 같아서」라면 약하다. 살펴봐야 할 것은 다음 4가지다.

대량의 로그를 SQL로 집계할 수 있는가
장애 시에 어디까지 읽기/쓰기를 계속할 수 있는가
데이터량이나 동시 실행 수가 늘어났을 때 확장할 수 있는가
벡터 검색(Vector Search)을 도입해도 운용이 파탄 나지 않는가

이 기사에서는 ClickHouse를 AI 시대의 분석 기반으로 볼 때, 무엇을 평가해야 하는지를 정리한다.

이 기사는 ClickHouse 입문서가 아니라, 본 프로덕션 투입 전의 판단 재료를 정리한 것이다. 기술 내용은 2026년 6월 시점의 공식 문서와 공개 정보를 바탕으로 하고 있다.

ClickHouse는 다음과 같은 요구사항이라면 궁합이 매우 좋다.

요구사항	ClickHouse가 적합한 이유
대량의 이벤트 로그를 집계하고 싶다	OLAP(Online Analytical Processing)용 열 지향(Column-oriented) DB이므로, 집계나 필터링에 특화되어 있음
...

반대로, 다음과 같은 용도로 선택한다면 신중하게 살펴봐야 한다.

용도	주의점
범용 트랜잭션 DB로 사용한다	ClickHouse는 OLAP용이며, OLTP(Online Transaction Processing)의 대체재가 아님
...

이 선긋기가 되어 있다면 ClickHouse는 매우 강력한 선택지가 된다. 반대로, 이 선긋기 없이 도입하면 「빠르지만 운용에서 막히는」 상황이 되기 쉽다.

AI 계열의 데이터 기반에서는 다음과 같은 데이터가 증가한다.

애플리케이션 로그
사용자 행동 로그
프롬프트와 응답(Response)
추론 결과
평가 스코어
문서의 메타데이터
임베딩 벡터

이것들은 단독으로 보기보다, 횡단적으로 보고 싶어진다.

예를 들어, RAG라면 「검색으로 찾아낸 문서」「모델의 답변」「사용자의 재질문」「평가 스코어」를 한꺼번에 분석하고 싶다. 장애 대응이라면 「특정 모델의 레이턴시(Latency)」「실패한 프롬프트」「직전의 배포」「사용자 영향」을 동일한 쿼리로 추적하고 싶다.

ClickHouse는 이러한 종류의 로그 분석에 강하다. 게다가 Array(Float32)와 같은 열에 벡터를 저장하고, 거리 함수로 근방 검색(Nearest Neighbor Search)도 작성할 수 있다. ClickHouse 25.8 이후부터는 vector similarity index도 사용할 수 있다. 현재 방식은 HNSW다.2

다만, 여기서 오해해서는 안 된다.

ClickHouse의 강점은 「분석과 벡터 검색을 동일한 기반에서 다룰 수 있다는 것」이다. 벡터 검색만 본다면 전용 벡터 DB가 더 적합한 케이스도 있다.

일반적인 데이터베이스에서는 Primary와 Replica와 같이 서버 단위로 중복성을 고려하는 경우가 많다.

ClickHouse의 ReplicatedMergeTree 계열 테이블에서는 레플리케이션(Replication)이 서버 전체가 아니라 테이블 단위로 동작한다. 동일한 서버 위에 레플리케이션되는 테이블과 되지 않는 테이블을 함께 둘 수도 있다.3

분산 구성에서는 주로 다음 요소들을 조합한다.

요소	역할
Shard	데이터를 분할하여 배치하는 단위
...

전형적으로는 다음과 같은 형태가 된다.

Shard 1
Replica 1
Replica 2
...

각 shard에 여러 개의 replica를 갖게 하면, 1대의 ClickHouse 서버가 다운되어도 다른 replica에서 읽기나 쓰기를 계속하기 쉬워진다. ClickHouse의 레플리케이션은 비동기(Asynchronous) 방식이자 multi-master 방식이므로, INSERT나 ALTER는 사용 가능한 replica로 보낼 수 있다. 데이터는 투입된 replica로부터 다른 replica로 복사된다.3

단, 「replica가 있으니까 무조건 안전하다」는 아니다. 기본적으로 INSERT는 1개의 replica에 대한 쓰기 확인이 완료되면 성공으로 간주된다. 여러 replica에 대한 쓰기 확인을 받고 싶다면 insert_quorum을 사용한다. 가용성과 쓰기 보증은 설정에 따라 달라진다.

ClickHouse의 가용성에서 가장 간과하기 쉬운 것이 Keeper라고 생각한다.

ClickHouse Keeper는 ZooKeeper 호환 조정 서비스(Coordination Service)로, ClickHouse에서는 레플리카(Replica)의 메타데이터 관리에 사용된다. 공식 문서에서도 ClickHouse Keeper가 권장된다.3

Keeper가 관여하는 대표적인 처리는 다음과 같다.

레플리카의 메타데이터 관리
INSERT의 중복 제거
part 명의 채번
merge 또는 mutation의 할당
분산 DDL 등, 여러 서버 간에 정합성(Consistency)이 필요한 처리

ClickHouse Keeper 자체는 Raft 기반의 메커니즘으로, ZooKeeper의 대체재로 설계되었다.4

운영에서 두려운 것은, ClickHouse 서버는 여러 대인데 Keeper가 취약한 구성이 되는 케이스다. Keeper에 접속할 수 없는 상태에서 서버가 기동되면, 복제 테이블(Replicated table)은 읽기 전용(Read-only)이 된다. INSERT 도중 Keeper를 사용할 수 없는 경우에는 예외(Exception)가 반환된다.5

레플리카를 2대로 구성하더라도, Keeper가 단일 장애점(Single Point of Failure)이라면 쓰기 계열의 가용성은 거기서 막히게 됩니다.

운영 환경에서는 Keeper도 쿼럼(Quorum)을 유지할 수 있는 구성으로 만들어야 한다. 작은 검증 환경에서는 1대로도 동작하지만, 운영 설계로서는 ClickHouse 서버뿐만 아니라 Keeper도 모니터링 대상으로 포함해야 한다.

운영 전 검증에서 확인해야 할 것은 단순히 "장애가 발생해도 동작하는가"가 아니다.

다음과 같이, 어느 계층이 중단되었을 때 무엇이 멈추는지 나누어서 확인해야 한다.

시험	확인할 내용
ClickHouse 서버를 1대 중단	읽기가 지속되는가. 쓰기 대상이 전환되는가
...	`insert_quorum`을 활성화
	어떤 조건에서 INSERT가 성공하고, 어떤 조건에서 실패하는가

ClickHouse는 SELECT 시에는 ZooKeeper나 Keeper를 사용하지 않기 때문에, Keeper의 상태가 읽기 성능에 직접적으로 영향을 주는 것은 아니다.3 반면, 복제 테이블의 기동, INSERT, ALTER, merge 또는 mutation의 조정에는 Keeper가 관여한다.

장애 시험에서는 최소한 다음 두 가지 종류를 나누어 시도하고 싶다.

systemctl stop clickhouse-server

이것은 ClickHouse 서버 측의 장애를 보는 시험이다. 레플리카가 올바르게 구성되어 있다면, 다른 레플리카에서 처리를 계속할 수 있을 가능성이 있다.

systemctl stop clickhouse-keeper

이것은 조정 서비스 측의 장애를 보는 시험이다. 복제 테이블이 읽기 전용(Read-only)이 되는지, INSERT가 어떻게 실패하는지, 복구 후에 어느 정도의 시간이 지나야 정상 상태로 돌아오는지 확인한다.

"ClickHouse 노드가 여러 개 있다"는 것과 "시스템 전체가 고가용성(High Availability)을 갖추고 있다"는 것은 같은 것이 아닙니다. Keeper, 로드 밸런서(Load Balancer), 클라이언트의 재시도(Retry), 쓰기 보증까지 포함해서 살펴볼 필요가 있습니다.

AI 계열 워크로드에서는 데이터량도 쿼리량도 갑자기 늘어나기 쉽다.

ClickHouse의 스케일링(Scaling)은 크게 수직 스케일(Vertical Scale)과 수평 스케일(Horizontal Scale)로 나뉜다.

종류	무엇을 늘리는가	효과적인 상황
수직 스케일	CPU 또는 메모리	무거운 집계, JOIN, 단발성 대규모 쿼리
수평 스케일	node, replica, shard	동시 실행 수, 수집량, 데이터량의 증가

CPU나 메모리를 늘려 1대당 처리 능력을 높이는 방법이다.

ClickHouse는 1대의 리소스를 최대한 활용하도록 설계되어 있어, 우선 수직 스케일을 검토할 가치가 있다. JOIN이나 무거운 집계와 같이 하나의 쿼리가 많은 메모리를 사용하는 경우에는 특히 효과적이다.

ClickHouse Cloud에서는 Scale 플랜과 Enterprise의 표준 1:4 프로필을 통해 자동 수직 스케일링(Auto Vertical Scaling)이 제공된다. Basic의 단일 레플리카 서비스는 고정된 크기로, 수직·수평 스케일 대상에서 제외된다.6

노드나 레플리카를 늘려 처리를 분산하는 방법이다.

셀프 호스트(Self-hosted) ClickHouse에서는 샤드(Shard)를 늘림으로써 데이터량에 맞춰 수평적으로 확장할 수 있다. 다만, 샤드 설계, 분산 테이블(Distributed table), 데이터 재배치, 운영 절차는 직접 관리해야 한다.

ClickHouse Cloud에서는 공유 스토리지(Shared storage)를 전제로 한 SharedMergeTree가 사용되며, 사용자가 수동으로 ReplicatedMergeTree의 인자나 샤드(shard) 배치를 관리해야 하는 상황이 줄어들고 있다. Cloud에서는 복제(replication)가 자동으로 처리되므로, 보통은 replication 인자 없이 테이블을 생성한다.3

수평 확장(Horizontal scale)은 동시 실행 수나 데이터 수집량(ingestion rate)이 증가했을 때 효과적이다. 다만, 모든 문제를 수평 확장으로 해결할 수 있는 것은 아니다. 무거운 단일 쿼리에는 수직 확장(Vertical scale)이 더 효과적일 때도 있다.

ClickHouse를 셀프 호스트(Self-host)로 운영하는 경우, 다음과 같은 설계와 운영을 직접 담당해야 한다.

샤드(shard) 설계
레플리카(replica) 설계
Keeper의 구성 및 모니터링
백업 및 복구(Restore)
장애 발생 시 원인 파악(Troubleshooting)
업그레이드
용량 계획(Capacity planning)

ClickHouse Cloud는 이러한 운영 부하를 상당 부분 서비스 측으로 넘긴다.

공식 사이트에서는 ClickHouse Cloud가 샤드, 레플리카, 인프라 관리의 복잡성을 책임지며, 멀티 AZ(Multi-AZ) 구성, 오토스케일링(Auto-scaling), 자동 백업, 복구 프로세스를 제공한다고 설명하고 있다.7

이는 단순히 "ClickHouse를 호스팅해 주는 것" 이상이다. 셀프 호스트 시 어려운 부분, 특히 복제(replication), 공유 스토리지, 스케일링, 백업을 서비스 측으로 위임하는 선택이다.

한편, Cloud를 사용한다고 해서 설계가 불필요해지는 것은 아니다. 테이블 설계, ORDER BY, 파티션(partition), 수집 단위, 쿼리 작성 방식, 벡터 인덱스(vector index)의 메모리 소비는 여전히 사용자의 책임이다.

ClickHouse는 정확한 검색(exact search)과 근사 검색(approximate search)을 모두 다룰 수 있다. 벡터를 컬럼으로 저장하고, 거리 함수를 사용하여 SQL로 검색할 수 있다. 나아가 벡터 유사도 인덱스(vector similarity index)를 사용하면 HNSW를 통한 근사 검색도 가능하다.2

이 단계에서 설계가 허술하면 나중에 어려움을 겪게 된다.

RAG(Retrieval-Augmented Generation)에서 사용할 계획이라면, 미리 다음 사항을 결정해 두어야 한다.

관점	확인하고 싶은 사항
데이터 양	exact search로 충분한가, 근사 검색이 필요한가
...

특히 벡터 유사도 인덱스(vector similarity index)는 메모리를 사용한다. 공식 문서에서도 인덱스는 검색 시 메인 메모리로 로드되므로, 캐시 크기를 예측해야 한다고 설명하고 있다.2

ClickHouse는 분석과 검색을 함께 처리할 수 있다는 점이 강력하다. 반대로, 벡터 검색만을 극한까지 최적화하고 싶다면 전용 DB와의 비교가 필요할 것이다.

마지막으로, 도입 전에 살펴봐야 할 포인트를 정리한다.

Keeper 장애 시 복제 테이블(replicated table)이 읽기 전용(read-only)이 되는가
ClickHouse 서버 장애 시 읽기가 지속될 수 있는가
쓰기 대상 레플리카(replica) 장애 시 애플리케이션이 다른 레플리카로 전환할 수 있는가
insert_quorum의 유무에 따라 INSERT 성공 조건이 어떻게 변하는가
로드 밸런서와 클라이언트의 재시도(retry)가 예상대로 작동하는가
복제 큐(replication queue)의 지연이 어느 정도 발생하는가
새 레플리카 추가 시 동기화 시간이 허용 가능한 수준인가
샤드(shard)를 늘리는 운영 절차를 갖추고 있는가
무거운 단일 쿼리에는 수직 확장(vertical scale)으로 충분한가
동시 실행 수나 수집량에는 수평 확장(horizontal scale)이 효과적인가
백업으로부터의 복구 시간이 허용 가능한가
복구 후 누락된 파트(part)가 올바르게 동기화되는가
스토리지 사용률이 높아졌을 때, 머지(merge)나 뮤테이션(mutation)이 정체되지 않는가
벡터 유사도 인덱스(vector similarity index)의 생성 시간이 허용 가능한가
인덱스의 메모리 사용량과 캐시 히트율(cache hit rate)을 모니터링할 수 있는가
대량의 INSERT와 벡터 검색을 동시에 실행할 때 정체되지 않는가
exact search와 approximate search의 품질 차이를 측정하고 있는가

ClickHouse는 강력하지만 마법의 상자는 아니다. 특히 셀프 호스트의 경우, Keeper와 복제(replication)에 대한 이해도가 곧 운영 품질로 직결된다.

ClickHouse는 AI 시대의 분석 기반으로서 현실적인 선택지가 되고 있다.

대량의 로그와 이벤트를 고속으로 집계할 수 있다. Shard(샤드)와 Replica(레플리카)를 통해 크게 확장할 수 있다. Cloud(클라우드)를 사용하면 운영 부하가 큰 부분을 서비스 측으로 돌릴 수 있다. 나아가 벡터 검색(Vector Search)도 SQL 내에서 다룰 수 있다.

다만, 적합한 용도와 그렇지 않은 용도가 나뉜다.

ClickHouse는 OLAP(Online Analytical Processing)용 데이터베이스이며, 범용 트랜잭션 DB가 아니다. Replication(복제)은 비동기 방식이 기본이며, 쓰기 보증은 설정에 따라 달라진다. Keeper의 설계를 가볍게 여기면, Replica가 있더라도 쓰기 작업에서 병목이 발생한다. 벡터 검색 또한 인덱스의 메모리 사용량이나 업데이트 빈도를 고려하지 않고 도입하면 어려움을 겪게 된다.

그렇기에 ClickHouse를 선택하는 이유가 단순히 "빠를 것 같아서"라면 설득력이 부족하다.

로그, 메트릭(Metrics), 추론 결과, 벡터, 메타데이터를 동일한 분석 기반에서 다루고 싶다. 나아가 운영 환경까지 포함하여 스케일 아웃(Scale-out)하고 싶다. 그러한 요구사항이라면 ClickHouse는 검토하기 쉬운 선택지다.

PoC(Proof of Concept) 단계에서는 쿼리 속도를 확인한다. 운영 환경 적용 전에는 Keeper, Replication, 페일오버(Failover), 백업, 그리고 벡터 인덱스의 메모리 부하를 한계치까지 테스트한다.

이러한 순서로 검토한다면, ClickHouse는 AI용 분석 기반으로서 유력한 후보가 될 것이다.

AI 시대의 분석 기반으로서 ClickHouse를 선택하는 이유

요약

핵심 포인트

댓글