맥북에 10억 행을 넣었는데 엔터를 치는 순간 답이 나왔다 - 조성문이 만난 클릭하우스의 정체

맥북에 10억 행을 넣었는데 엔터를 치는 순간 답이 나왔다

TL;DR

• 글의 출발점이 엔지니어의 직업병인데 뭔가 성능이 좋으면 항상 의심하는 것이 뼛속까지 밴 습관이라는 것이다. 근거도 분명하다. 당연히 가격이 비싸거나 다른 어떤 특징을 희생해야 한 가지 분야에서 성능이 좋아질 수 있다는 것이며, 트레이드오프는 질량 보전의 법칙만큼이나 자연스러운 것이라고 표현한다.
• 발견 경로가 실화인데 차트모굴 고객이 되면서 방대한 시계열 데이터를 다루면서도 어떤 필터를 적용하든 최신 숫자에 가까운 결과를 거의 실시간으로 보여주는 것을 보고 창업자 Nick에게 이메일을 보냈다. 컨설팅 비용을 낼 테니 비결을 알려달라고 전화로 물었더니 답이 돌아왔다. 자기도 Snowflake를 썼었는데 이제 ClickHouse를 쓴다는 것이었다.
• 검증 장면이 이 글의 절정인데 엔지니어가 3시간쯤 후 얼굴이 벌겋게 상기된 채로 흥분해서 달려왔다. 맥북에 그냥 깔고 약 10억 개의 데이터를 넣은 뒤 관계형 데이터베이스에서 악명 높게 느린 SELECT … GROUP BY … ORDER BY를 던졌더니 엔터를 치는 순간 답이 나왔고, 인덱싱을 걸었느냐는 물음에 아무것도 안 했다는 답이 돌아왔다.
• 답이 물리학 위반이 아니라고 정리되는데 같은 일을 할 때 읽는 바이트 수와 CPU가 하는 쓸데없는 일을 아주 많이 줄였다는 것이다. 네 가지가 겹친 결과다. 컬럼별 저장으로 필요한 칼럼만 읽고 압축 효율도 얻고, 블록(벡터) 단위 처리로 한 행씩 넘기지 않으며, 여러 코어가 부분 합계를 만들어 마지막에 합치고, 인덱스는 기본값으로 약 8,192행마다 표시를 두는 희소 기본 인덱스를 쓴다.
• 그런데 만능이 아니라고 명시하며 높은 업데이트·삭제 빈도와 수 밀리초 단건 처리에는 약하다고 한다. 자리도 규정된다. 잘 설계된 PostgreSQL은 개별 기록 즉시 조회와 트랜잭션에 여전히 훌륭하고 데이터 웨어하우스는 거대 조직 전체 데이터에 강점인데, ClickHouse는 그 사이에서 방대한 이벤트·시계열·로그 데이터를 매우 빠르게 필터하고 집계하는 자리를 파고들었고 현재 전체 데이터의 절반 가까이를 처리한다.

Source

클릭하우스(ClickHouse) – 기적의 데이터베이스 기술 — 조성문, 2026년 8월 29일

저자는 차트메트릭 창업자이자 대표이고 UCLA MBA 출신이다.

[sungmooncho.com/2026/08/29/clickhouse](https://sungmooncho.com/2026/08/29/clickhouse/)

Knowledge

성능이 좋으면 의심하는 습관

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

기술 지형이 차례로 정리된다. 가장 쉽게 접근할 수 있고 가장 흔하게 쓰는 것은 관계형 데이터베이스이며 MySQL과 PostgreSQL 등이 여기 속한다는 것이다. 방식이 단순하게 설명된다. 가장 단순하게는 테이블 형태로 데이터를 저장하고 SQL이라는 표준 언어로 필요한 것을 꺼내는 방식이라는 것이다. 예시로 주문 기록 테이블에서 2026년 8월 1일 이후 나라별 매출을 확인해 높은 순서대로 정렬하는 쿼리가 제시되고 인간이 생각할 수 있는 가장 단순한 방법이라고 평가된다.

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

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

데이터 웨어하우스와 그 비용

그래서 데이터 웨어하우스가 등장했다고 서술된다. BigQuery와 Amazon Redshift, 그리고 Snowflake가 대표적이라는 것이다. 이름의 의미도 짚는다. 창고라는 말에 걸맞게 테라바이트를 넘어 페타바이트까지의 데이터를 보관하고 분석하는 데 초점이 있다는 것이다.

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

그런데 공짜가 아니라고 명시한다. 분산 환경에서는 서버를 깨우고 작업을 나누고 결과를 다시 합치는 비용이 있다는 것이다. 그래서 역전이 생긴다. 아주 작은 범위에서 한두 행만 즉시 꺼내는 요청은 잘 설계된 PostgreSQL이 더 자연스럽고 빠를 수 있다는 것이다.

실제 운영 방식이 밝혀진다. 사용자에게 곧바로 보여줄 정보는 PostgreSQL에서, 약간 시간이 걸려도 큰 범위를 요약해 보여줄 정보는 Snowflake에서 처리해 왔다는 것이다. 그리고 자주 보는 요약은 미리 만들어 관계형 데이터베이스에 저장하기도 했다고 한다. 이 외에 Elasticsearch도 사용하고 있지만 오늘의 주제는 아니라고 덧붙인다.

컨설팅 비용을 내겠다며 물어본 비결

발견 경로가 실화로 제시된다. 이 희한한 이름의 데이터베이스를 처음 알게 된 건 차트모굴의 고객이 되면서부터라는 것이다. 차트모굴이 무엇인지도 설명된다. 구독 서비스를 하는 회사들이 스트라이프와 연결하면 월간 반복 매출 같은 유용한 지표를 쉽게 보고 분석할 수 있게 해 주는 서비스라는 것이다.

의심을 부른 지점이 명확하다. 방대한 시계열 데이터를 다루면서도 어떤 필터를 적용하든 최신 숫자에 가까운 결과를 거의 실시간으로 보여주고 있었다는 것이고 그런 성능이 어떻게 나오는지 너무 신기했다는 것이다.

그래서 행동으로 옮긴다. 창업자 Nick에게 이야기 좀 하자고 이메일을 보냈다는 것이다. 전화에서 요청이 직접적이다. 컨설팅 비용을 낼 테니 비결을 알려 달라는 것이었고 어떤 비법을 쓰길래 이런 양의 데이터를 수많은 고객에게 제공하면서도 이 정도 성능을 내는지, 혹시 AWS에 엄청난 돈을 내고 있는 건 아닌지 물었다는 것이다.

답이 뜻밖이었다. 껄껄 웃으며 자기도 Snowflake를 썼었는데 이제 ClickHouse를 쓴다고 말했다는 것이다. 반응도 솔직하다. 무슨 오픈소스 기술인가 싶어서 바로 찾아봤고 역시나 오픈소스 기술이었으며 비교적 새로 나온 데이터베이스였다는 것이다. 그리고 두 가지가 함께 온다고 들었다. 그걸 쓰면 빠르고 비용도 적다는 것이었다.

3시간 후 얼굴이 벌겋게 상기된 채로

검증 과정이 이 글의 절정이다. 다음 날 출근해서 한 엔지니어에게 ClickHouse라는 기술이 있는데 한번 테스트해 보자고 이야기했다는 것이다. 그리고 3시간쯤 후, 엔지니어가 얼굴이 벌겋게 상기된 채로 흥분해서 달려왔다는 것이다. 첫마디가 이것 좀 보라며 믿을 수 없다는 것이었다.

실험 설정이 단순하다. 데이터베이스를 그냥 맥북에 깔았고 테스트하려고 약 10억 개의 데이터를 넣어 봤다는 것이다. 그다음 관계형 데이터베이스에서 악명 높게 느린 질문을 던져 봤는데, 바로 SELECT와 GROUP BY, ORDER BY였다는 것이다.

결과가 짧게 서술된다. 엔터를 치는 순간 답이 나왔다는 것이다. 그 느리던 평균값과 총합을 구하는 일도 엔터를 치는 순간 바로 답이 나왔고 순간 소름이 끼쳤다는 것이다.

확인 문답이 두 줄로 붙는다. 인덱싱 걸었지 하고 물었고 아니요 전혀 아무것도 안 했는데요라는 답이 돌아왔다는 것이다.

믿기 어려웠다는 반응이 이어진다. 자기 눈으로 보고도 믿을 수 없었다는 것이고 맥북에 깔아서 돌렸는데 이 정도 성능이 나올 수 있다니 하는 것이다. 게다가 다른 데이터베이스보다 비용도 훨씬 저렴했다고 한다.

그래서 도입 규모가 밝혀진다. 그 이후로 ClickHouse에 더 의존하기 시작했고 지금은 전체 데이터의 절반 가까이를 ClickHouse가 처리하고 있다는 것이다. 그리고 다른 데이터베이스를 사용하는 것들을 계속해서 옮기고 있다고 한다.

물리학을 어긴 것이 아니다

질문이 처음으로 돌아간다. 도대체 어떻게 이게 가능한 일이며 어떻게 물리학의 법칙을 어기는 기술이 가능하단 말인가 하는 것이다.

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

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

둘째는 한 줄씩이 아니라 묶음으로 계산하는 것이다. 값을 한 행씩 천천히 넘기는 대신 칼럼의 값들을 블록, 즉 벡터 단위로 처리한다는 것이다. 비유도 붙는다. 쉽게 말해 한 사람씩 줄 세워 검사하는 것이 아니라 비슷한 일을 한 번에 여러 명에게 처리하는 방식이라는 것이다.

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

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

마법이 아니라 자리

만능론이 명확히 부정된다. ClickHouse가 모든 데이터베이스를 대체하는 마법의 기술은 아니라는 것이다.

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

그런데도 놀라움은 남는다. 소프트웨어 제품을 개발하는 입장에서 10억 행을 담은 맥북에서 복잡한 집계가 즉시 답을 내놓는 광경은 여전히 기적처럼 보인다는 것이다.

권유가 마지막에 온다. 이 기술을 언급하면 데이터를 다루는 일을 하는 회사임에도 처음 듣는다는 반응을 보이는 경우가 꽤 많다는 것이다. 그래서 데이터를 다루는 회사라면, 특히 제품 안에서 실시간 분석이나 대시보드를 고민하고 있다면 꼭 한번 검토해 보기를 권한다.

각주에서 단서를 보강한다. PostgreSQL의 인덱스는 B-tree를 포함한 여러 방식이 있으며 특정 행이나 좁은 범위 접근을 빠르게 하는 핵심 수단이지만 인덱스의 효용은 쿼리와 데이터 분포, 선택도에 좌우된다는 것이다. 데이터 웨어하우스마다 실제 구현은 다르며 여기서는 대규모 분석 시스템에 흔한 분산·컬럼형 처리의 직관을 설명한 것이라고 밝힌다. ClickHouse 문서가 MergeTree의 컬럼별 파일과 압축 블록, 정렬과 희소 기본 인덱스의 관계를 설명한다고 출처를 걸고 벡터화는 값을 묶음으로 처리해 호출 오버헤드를 줄이고 CPU 캐시와 SIMD 활용을 돕는 실행 방식이라고 정의한다.

댓글에 달린 두 반응

댓글 두 개가 대비된다. 9월 2일 이봉호는 요즘 검토 중이던 차에 이런 간증글을 보게 된다며 잘 읽어 보겠다고 감사를 표한다.

9월 3일 김남희의 반응이 더 흥미롭다. AI나 링크드인스러운 바이브가 느껴지는데도 글을 몰입도 있게 잘 썼다며 재밌게 읽고 간다는 것이다. 기술 도입기 특유의 서술 방식에 대한 요즘의 감각이 드러나는 대목이다.

더 생각해보기

• 성능이 좋으면 의심한다는 습관이 옳다면, ClickHouse가 희생한 것은 정확히 무엇이고 그 대가는 언제 청구되는가.
• 인덱싱 없이 빨랐다는 놀라움은, 관계형 데이터베이스의 인덱스 설계 부담이 얼마나 컸는지를 반증하는가.
• 8,192행마다 표시를 두는 희소 인덱스는 어떤 데이터 분포에서 효과가 급격히 떨어지는가.
• 전체 데이터의 절반 가까이를 옮겼다면, 남은 절반이 옮겨지지 않는 이유는 기술적인가 조직적인가.
• 컨설팅 비용을 내겠다며 경쟁사가 아닌 공급사 창업자에게 직접 물은 방식은, 기술 탐색에서 얼마나 일반화할 수 있는가.
• 맥북 한 대에서 10억 행이 즉시 처리된다면, 분산 데이터 웨어하우스가 여전히 필요한 규모의 경계는 어디인가.
• 높은 업데이트·삭제 빈도에 약하다는 약점은 실무에서 어떤 설계로 우회되는가.
• 데이터를 다루는 회사조차 처음 듣는다는 반응이 많은 이유는, 기술 확산에서 무엇이 병목인가.
• 댓글의 AI 같은 바이브라는 반응은, 기술 도입기라는 장르가 지금 어떤 의심을 받고 있음을 뜻하는가.