클릭하우스(ClickHouse) – 기적의 데이터베이스 기술

엔지니어로서, 뼛속까지 밴 습관이 있다. 뭔가 성능이 좋으면 항상 의심하는 것. 당연히 가격이 비싸거나, 다른 어떤 특징을 희생하거나 해야 한 가지 분야에서 성능이 좋아질 수 있다. 트레이드오프(Trade-off) — 엔지니어링을 공부한 사람이라면, 그리고 그 기술로 제품을 만들어본 사람이라면 언제나 이를 생각하게 마련이다. 이는 질량 보전의 법칙만큼이나 자연스러운 것이다.

시중에는 다양한 데이터베이스 기술이 있다. 가장 쉽게 접근할 수 있고 가장 흔하게 쓰는 것은 관계형 데이터베이스다. MySQL, PostgreSQL 등이 여기에 속한다. 가장 단순하게는 테이블 형태로 데이터를 저장하고, SQL이라는 표준 언어로 필요한 것을 꺼내는 방식이다.

예를 들어 주문 기록이 들어 있는 테이블에서, 2026년 8월 1일 이후로 나라별 매출을 확인한 후에 매출이 높은 순서대로 정렬해서 보여주고 싶다면 우리는 이렇게 묻는다.

SELECT country, SUM(amount)
FROM orders
WHERE ordered_at >= '2026-08-01'
GROUP BY country
ORDER BY SUM(amount) DESC;

인간이 생각할 수 있는 가장 단순한 방법이다.

관계형 데이터베이스는 보통 인덱싱(indexing)을 잘 활용한다. 도서관의 색인 카드처럼, 특정 칼럼 또는 칼럼 조합을 정리해 두고 원하는 자료를 빨리 찾는다. 조건에 잘 맞는 인덱스가 있고, 실제로 적은 행만 찾는 요청이라면 수 밀리초 응답도 충분히 가능하다.^¹

문제는 “모든 질문에 좋은 인덱스”는 없다는 데 있다. 인덱스는 저장 공간을 쓰고, 데이터를 넣거나 고칠 때도 함께 관리해야 한다. 자주 쓰는 조건이 바뀌면 인덱스 설계도 다시 고민해야 한다. 특히 수십억 행을 넓게 훑으며 GROUP BY와 ORDER BY를 함께 하는 분석 쿼리는, 한 행을 빨리 찾아내는 데 최적화된 구조만으로는 버거울 수 있다. “10억 행부터 무조건 느려진다”는 절대 법칙은 아니지만, 종종 몇 분이 걸릴지도 모르는 작업이 된다.

그래서 데이터 웨어하우스(Data Warehouse)가 등장했다. BigQuery, Amazon Redshift, 그리고 Snowflake가 대표적이다. “웨어하우스”, 즉 창고라는 말에 걸맞게 테라바이트를 넘어 페타바이트까지의 데이터를 보관하고 분석하는 데 초점이 있다.

이들은 보통 데이터를 여러 컴퓨터에 나누어 두고, 쿼리가 들어오면 각 컴퓨터가 자기 몫을 읽어 중간 결과를 만든 다음 마지막에 합친다. 한 대가 모든 일을 하는 대신, 여러 대가 병렬로 일하는 것이다. 또 행 전체를 붙여 두기보다 칼럼별로 저장하는 경우가 많다. 집계에 필요한 칼럼만 읽을 수 있고, 같은 성격의 값들이 모여 있어 압축도 잘 된다. 결국 디스크에서 읽을 양 자체가 줄어든다.^²

물론 이것도 공짜는 아니다. 분산 환경에서는 서버를 깨우고, 작업을 나누고, 결과를 다시 합치는 비용이 있다. 아주 작은 범위에서 한두 행만 즉시 꺼내는 요청은, 잘 설계된 PostgreSQL이 더 자연스럽고 빠를 수 있다. 그래서 우리는 사용자에게 곧바로 보여줄 정보는 PostgreSQL에서, 약간 시간이 걸려도 큰 범위를 요약해 보여줄 정보는 Snowflake에서 처리해 왔다. 자주 보는 요약은 미리 만들어 관계형 데이터베이스에 저장하기도 했다. (이 외에도 우리는 Elasticsearch를 사용하고 있지만, 오늘의 주제는 아니다.)

그러다가 발견한 기적의 기술이 클릭하우스(ClickHouse)이다. 이 희한한 이름의 데이터베이스를 처음 알게 된 건 우리가 차트모굴(ChartMogul)의 고객이 되면서부터다. 구독 서비스를 하는 우리 같은 회사들이 스트라이프(Stripe)와 연결하면 월간 반복 매출(MRR) 같은 유용한 지표를 쉽게 보고 분석할 수 있게 해주는 서비스인데, 방대한 시계열 데이터를 다루면서도 어떤 필터를 적용하든 최신 숫자에 가까운 결과를 거의 실시간으로 보여주고 있었다. 그런 성능이 어떻게 나오는지 너무 신기했다.

그래서 창업자 Nick에게 이메일을 보냈다. 이야기 좀 하자고.

전화로 말했다. 컨설팅 비용을 낼 테니 비결을 알려달라고. 어떤 비법(?)을 쓰길래 이런 양의 데이터를 수많은 고객에게 제공하면서도 이 정도 성능을 내는지, 혹시 AWS에 엄청난 돈을 내고 있는 건 아닌지.

껄껄 웃으며 그가 말했다. 자기도 Snowflake를 썼었는데, 이제 ClickHouse를 쓴다고. ClickHouse? 무슨 오픈소스 기술인가 싶어서 바로 찾아봤다. 역시나 오픈소스 기술이었고, 비교적 새로 나온 데이터베이스였다. 그걸 쓰면 빠르고 비용도 적다고 했다.

다음 날 출근해서 한 엔지니어에게 이야기를 했다. ClickHouse라는 기술이 있는데 한번 테스트해 보자고. 3시간쯤 후, 엔지니어가 얼굴이 벌겋게 상기된 채로 흥분해서 달려왔다.

“이것 좀 보세요. 믿을 수 없네요.”

그러더니 자기 랩탑(맥북)을 열어 보여주었다. 데이터베이스를 그냥 맥북에 깔았고, 테스트하려고 약 10억 개의 데이터를 넣어 봤다고. 그다음 관계형 데이터베이스에서 악명 높게 느린 질문을 던져 봤다고. 바로 SELECT … GROUP BY … ORDER BY였다.

엔터를 치는 순간 답이 나왔다. 그 느리던 평균값, 총합을 구하는 일도 엔터를 치는 순간 바로 답이 나왔다. 순간 소름이 끼쳤다.

“인덱싱 걸었지?”
“아니요. 전혀. 아무것도 안 했는데요.”

내 눈으로 보고도 믿을 수 없었다. 맥북에 깔아서 돌렸는데 이 정도 성능이 나올 수 있다니. 게다가 다른 데이터베이스보다 비용도 훨씬 저렴했다. 그 이후로 우리는 ClickHouse에 더 의존하기 시작했고, 지금은 전체 데이터의 절반 가까이를 ClickHouse가 처리하고 있다. 다른 데이터베이스를 사용하는 것들을 계속해서 옮기고 있다.

다시 처음 했던 질문으로 돌아가 보자. 도대체 어떻게 이게 가능한 일일까. 어떻게 물리학의 법칙(?)을 어기는 기술이 가능하단 말인가.

정답은 물리학을 어긴 것이 아니라, 같은 일을 할 때 읽는 바이트 수와 CPU가 하는 쓸데없는 일을 아주 많이 줄였다는 데 있다. ClickHouse가 분석 작업에 특히 강한 이유는 몇 가지가 겹친 결과다.

1) 칼럼별로 저장한다

ClickHouse는 데이터를 칼럼별로 저장한다. 예를 들어 국가별 매출을 계산한다면 날짜·국가·금액 정도만 읽으면 된다. 제품 설명, 주소, 메모처럼 쿼리에 필요 없는 칼럼은 디스크에서 꺼낼 이유가 없다. 같은 타입의 값이 붙어 있으니 압축 효율도 좋아진다. 덜 읽고, 읽은 것도 더 작으니 시작부터 유리하다.^³

2) 한 줄씩이 아니라, 묶음으로 계산한다

ClickHouse는 값을 한 행씩 천천히 넘기는 대신, 칼럼의 값들을 블록(벡터) 단위로 처리한다. 쉽게 말해 “한 사람씩 줄 세워 검사”가 아니라 “비슷한 일을 한 번에 여러 명에게 처리”하는 방식이다.^⁴

3) 여러 코어가 동시에 나눠 일한다

집계는 특히 병렬화하기 좋다. 각 CPU 코어가 데이터의 다른 조각을 읽어 부분 합계·부분 평균을 만들고, 마지막에 그것들을 합치면 된다. 한 대의 노트북에서도 여러 코어를 쓸 수 있고, 더 큰 환경에서는 여러 서버로 확장할 수도 있다.

4) 인덱싱을 안할까?

데이터의 물리적 정렬 순서를 정하고, 그 순서에 따라 희소(sparse) 기본 인덱스를 만든다. 기본값으로는 약 8,192행마다 한 번씩 표시(mark)를 둔다. 행마다 촘촘한 B-tree 인덱스를 만드는 대신, “이 8,192행 묶음은 아예 볼 필요가 없다”를 빠르게 판단하는 것이다. 즉, 매번 질문을 위해 전통적인 보조 인덱스를 따로 수십 개 만들지 않았는데도, 컬럼 저장·압축·벡터 처리·병렬 처리 덕분에 광범위한 집계가 굉장히 빠르다는 것. 반대로 높은 업데이트/삭제 빈도, 수 밀리초 단건 처리에는 약하다.

ClickHouse가 모든 데이터베이스를 대체하는 마법의 기술은 아니다. 잘 설계된 PostgreSQL은 개별 사용자 기록을 즉시 찾고, 트랜잭션을 안전하게 처리하는 데 여전히 훌륭하다. 데이터 웨어하우스는 거대한 조직 전체의 데이터와 복잡한 분산 운영에 강점이 있다. ClickHouse는 그 사이에서, 방대한 이벤트·시계열·로그 데이터를 매우 빠르게 필터하고 집계하는 자리를 강하게 파고들었다.

하지만 소프트웨어 제품을 개발하는 입장에서, 10억 행을 담은 맥북에서 복잡한 집계가 즉시 답을 내놓는 광경은 여전히 기적처럼 보인다. 내가 이 기술을 언급하면, 데이터를 다루는 일을 하는 회사임에도 처음 듣는다는 반응을 보이는 경우가 꽤 많다. 데이터를 다루는 회사라면, 특히 제품 안에서 실시간 분석이나 대시보드를 고민하고 있다면, 꼭 한번 검토해 보기를.

각주

1. PostgreSQL의 인덱스는 B-tree를 포함한 여러 방식이 있으며, 특정 행 또는 좁은 범위 접근을 빠르게 하는 핵심 수단이다. 하지만 인덱스의 효용은 쿼리·데이터 분포·선택도에 좌우된다. 출처 보기

2. 데이터 웨어하우스마다 실제 구현은 다르다. 여기서는 대규모 분석 시스템에 흔한 분산·컬럼형 처리의 직관을 설명한 것이다.

3. ClickHouse 문서는 MergeTree의 컬럼별 파일, 압축 블록, 정렬과 희소 기본 인덱스의 관계를 설명한다. 출처 보기

4. 벡터화는 값을 묶음으로 처리해 호출 오버헤드를 줄이고 CPU 캐시·SIMD 활용을 돕는 실행 방식이다. 출처 보기