ClickHouse 오픈소스 10주년 — 어떻게 '말도 안 되게 빠른' 분석 DB가 됐나

무슨 일이냐면

분석용 데이터베이스 ClickHouse(클릭하우스)가 오픈소스로 공개된 지 10년이 됐어요. 처음엔 러시아 검색엔진 회사 얀덱스(Yandex) 내부에서 웹 트래픽 분석하려고 만든 사내 도구였는데요, 2016년에 오픈소스로 풀린 뒤로 지금은 전 세계에서 '빠른 분석 쿼리' 하면 빠지지 않고 거론되는 대표 주자가 됐거든요. 10주년을 맞아 그동안 어떻게 여기까지 왔는지 돌아본 글이에요.

그래서 ClickHouse가 뭔데

이게 뭐냐면, 어마어마한 양의 데이터를 두고 "지난 한 달 동안 국가별 매출 합계 보여줘" 같은 집계 쿼리를 눈 깜짝할 사이에 돌려주는 데 특화된 데이터베이스예요. 이런 용도를 OLAP(온라인 분석 처리)라고 부르는데요, 우리가 흔히 쓰는 MySQL이나 PostgreSQL은 "이 주문 한 건 저장해", "이 회원 정보 한 줄 가져와" 같은 OLTP(트랜잭션 처리)에 강하지, 수십억 줄을 통째로 훑어서 합계 내는 일엔 약하거든요. ClickHouse는 정확히 그 약한 부분을 노린 거죠.

빠른 비결: '세로로 저장한다'는 발상

핵심 비밀은 컬럼 기반 저장(columnar storage)이에요. 이게 뭐냐면, 데이터를 가로줄(행) 단위로 차곡차곡 쌓는 게 아니라 세로줄(열) 단위로 모아서 저장하는 방식이에요.

예를 들어볼게요. '주문 테이블'에 날짜, 국가, 금액 세 칼럼이 있다고 쳐요. "국가별 금액 합계"를 구하려면 사실 '국가'와 '금액' 두 칼럼만 있으면 되잖아요. 그런데 행 단위로 저장돼 있으면 주문 한 줄을 통째로(필요 없는 다른 칼럼까지) 디스크에서 다 읽어야 해요. 반면 칼럼 단위로 저장하면 딱 필요한 '국가'와 '금액' 묶음만 쏙 읽어오면 되거든요. 읽는 데이터 양 자체가 확 줄어드는 거예요.

게다가 같은 칼럼 안엔 비슷한 값이 모여 있어서(국가 칼럼엔 'KR', 'US'만 반복) 압축이 기가 막히게 잘 돼요. 디스크에서 읽는 양이 또 줄죠. 여기에 한 번에 데이터 한 덩어리씩 묶어서 CPU에 밀어 넣는 벡터화 실행(vectorized execution)까지 더해져요. 한 줄 한 줄 처리하는 대신 수천 줄을 한 묶음으로 CPU의 SIMD 명령어로 한꺼번에 계산하는 건데, 덕분에 CPU를 놀리지 않고 쥐어짜내요. 이 세 가지(컬럼 저장 + 강력한 압축 + 벡터화)가 합쳐져서 "같은 쿼리가 왜 이렇게 빠르지?" 소리가 나오는 거예요.

업계에서의 위치

비슷한 결의 도구가 여럿 있어요. 클라우드 쪽엔 구글 BigQuery, 아마존 Redshift, 스노우플레이크(Snowflake) 같은 분석 플랫폼이 있고, 오픈소스 진영엔 Apache Druid나 Apache Pinot처럼 실시간 분석에 강한 친구들이 있죠. ClickHouse의 차별점은 '직접 서버에 깔아서 단독으로 미친 속도를 낸다'는 점이에요. 복잡한 분산 클러스터 없이 노트북 한 대에서도 수억 줄을 척척 돌리는 가벼움과 빠름이 입소문의 핵심이었거든요. 최근엔 ClickHouse Cloud로 관리형 서비스까지 내놓으면서 스노우플레이크 같은 상용 진영과도 정면으로 붙고 있고요.

한국 개발자에게

실무에서 바로 떠올릴 수 있는 자리가 꽤 많아요. 서비스 로그 분석, 사용자 행동 이벤트 집계, 광고/커머스 대시보드, 모니터링 지표 저장 같은 곳이요. "우리 대시보드 쿼리가 너무 느려서 매번 몇 십 초씩 기다린다" 하는 상황이면 ClickHouse가 강력한 후보예요. 다만 주의할 점도 분명한데, 얘는 잦은 단건 수정(UPDATE)이나 삭제, 실시간 트랜잭션엔 약해요. 그러니 '서비스 메인 DB를 통째로 갈아엎자'가 아니라, 운영 DB는 그대로 두고 분석 전용으로 옆에 한 대 붙이는 구성으로 접근하는 게 현실적이에요. 데이터 엔지니어링이나 백엔드를 하는 분이라면 컬럼 기반 저장이라는 개념 자체는 꼭 이해해두면 두고두고 써먹어요.

마무리

10년 전 사내 도구가 글로벌 분석 DB 표준 중 하나가 된 비결은 결국 '필요한 데이터만, 압축해서, 한꺼번에 처리한다'는 단순한 원칙을 끝까지 밀어붙인 데 있어요. 여러분 회사의 분석 쿼리는 지금 충분히 빠른가요? 느리다면 그 병목이 정말 DB 종류 때문인지, 아니면 쿼리나 인덱스 설계 문제인지 한번 같이 이야기해봐요.