ClickHouse가 더 빨랐지만, 도입하지 않았다

왜 로그 시스템을 구축했나

기존 환경에서는 시스템 에러가 발생했을 때 이를 추적하기 어려웠다. 에러 핸들링도 충분히 갖춰져 있지 않아, 오류를 파악하고 대응하는 방식을 개선할 필요가 있었다.

이런 문제를 개선하기 위해 로그 시스템을 구축하게 됐다. 어떤 오류가 발생했는지 더 잘 추적할 수 있는 환경을 만드는 것이 출발점이었다.

시스템에서 발생한 오류를 더 잘 추적하고 대응할 수 없을까?

처음부터 더 빠른 데이터베이스를 찾거나 두 제품의 성능 순위를 매기려던 것은 아니었다. 성능 비교는 로그 시스템을 만드는 과정에서 저장 방식을 검토하며 시작한 일이었다.

로그 시스템을 만들며 저장 방식도 다시 검토했다

기존에는 PostgreSQL을 사용하고 있었다. 하지만 로그 시스템을 구성하는 만큼, 기존 방식을 그대로 따르기보다 로그 데이터를 다루는 데 더 적합한 저장 방식이 있는지도 살펴보고 싶었다.

지금 만들고 있는 로그 시스템에는 더 적합한 저장 방식이 있지 않을까?

그 질문을 가지고 다른 선택지를 조사하기 시작했다. PostgreSQL이 느리거나 오류 추적 문제의 원인이라고 확인해서 시작한 비교는 아니었다.

조사하다 알게 된 컬럼형 데이터베이스

그 과정에서 컬럼형 데이터베이스라는 개념을 처음 알게 됐다. 로그 시스템에 적합할 수 있다는 설명을 접하면서 관심이 생겼고, 그중 ClickHouse를 비교 대상으로 정했다.

PostgreSQL 외에 다른 선택지가 있다는 것을 알게 되자, 실제로 어느 정도 차이가 나는지 궁금해졌다.

압도적인 읽기 성능을 기대하며

테스트 전에는 ClickHouse가 PostgreSQL보다 읽기 성능에서 압도적으로 빠를 것이라고 예상했다.

설명으로만 보던 성능 차이를 직접 체감해보고 싶었다.

그래서 PostgreSQL과 ClickHouse를 로컬에서 비교할 수 있도록 테스트베드를 구성하고 직접 테스트를 진행했다. ‘로그 시스템에 더 좋은 방법이 있지 않을까?’라는 질문을, 두 데이터베이스를 같은 데이터와 조회 조건에서 비교하는 실험으로 옮긴 것이다.

운영 트래픽이 아니라, 작은 테스트베드

두 데이터베이스에 같은 범위의 원본 데이터를 사용하고 조회 조건을 맞췄다. 조건 조회, 그룹 집계, 연결 집계라는 세 형태를 비교했다. 이 세 가지를 고른 특별한 이유는 없었다. 실제 서비스의 모든 쿼리를 대표하는 실험이라고 주장하려는 것은 아니다.

원본 데이터 범위

1건부터 100만 건까지 · 9개 구간

반복 측정

각 조건·DB별 20회 · 중앙값 사용

실행 방식

로컬 환경 · 쿼리를 하나씩 실행

결과 확인

사전 실행 제외 · 두 DB의 계산 결과 비교

비교 구간은 1건, 10건, 100건, 1천 건, 1만 건, 3만 건, 10만 건, 30만 건, 100만 건이었다. 반복 측정에서 우열을 확정하기 어려운 조건은 판단을 보류했다.

예상과 달랐던 세 가지 결과

01 · 조건 조회는 끝까지 PostgreSQL

조건에 맞는 행을 찾고 요약값을 계산한 조회에서는, 측정한 모든 구간에서 PostgreSQL이 빨랐다. 100만 건 범위에서도 PostgreSQL은 0.764ms, ClickHouse는 6.362ms였다. 읽기라면 무조건 ClickHouse가 빠를 것이라는 내 기대와는 달랐다.

02 · 그룹 집계는 규모가 커지며 역전

항목별로 묶어 요약값을 계산한 그룹 집계에서는 1만 건까지 PostgreSQL이 앞섰다. 3만 건의 중앙값은 4.100ms와 3.928ms였지만, 원문 기록에서는 판단을 보류했다. 숫자가 조금 작다는 이유만으로 ClickHouse의 승리로 바꾸지는 않았다.

10만 건부터는 ClickHouse가 앞섰다. 100만 건에서는 PostgreSQL 35.568ms, ClickHouse 7.443ms였다. PostgreSQL의 소요 시간은 ClickHouse의 약 4.78배였고, 절대 차이는 28.125ms였다. 배율뿐 아니라 실제로 얼마나 줄었는지도 함께 볼 필요가 있었다.

03 · 연결 집계는 1천 건부터 ClickHouse

원본 행에 분류 정보를 하나씩 연결하고 요약한 연결 집계는 다른 모습을 보였다. 100건까지는 PostgreSQL이 빨랐지만, 1천 건부터 ClickHouse가 앞섰다. 100만 건에서는 각각 55.113ms와 15.833ms였다.

세 조회에 공통으로 적용할 수 있는 전환점은 확인되지 않았다.

내게 가장 인상적이었던 것은 그룹 집계에서 수만~10만 건 구간을 지나며 차이가 드러났다는 점이다. 그렇다고 ‘ClickHouse는 10만 건부터 빠르다’는 법칙을 얻은 것은 아니다. 연결 집계는 이미 1천 건부터 달랐고, 조건 조회는 100만 건에서도 결과가 반대였다.

범위를 바꾸며 직접 비교해보기

아래 화면은 당시 기록한 중앙값을 다시 표현한 것이다. 조회 유형과 원본 데이터 범위를 바꾸면 결과가 달라진다. 새로 측정하거나 데이터베이스에 접속하는 화면은 아니다.

전체 측정 기록

원문에 있는 27개 조건, 두 DB의 중앙값 54개를 모두 옮겼다. 단위는 ms이며 작을수록 빠르다.

출처: docs/postgresql-clickhouse-comparison.md · 로컬 테스트베드의 기록

이 결과로 말할 수 없는 것

이 글은 두 데이터베이스의 보편적인 우열을 증명하는 벤치마크가 아니다. 여기서 확인한 것은 이 로컬 테스트베드의 데이터와 조회 조건에서 관찰한 차이다.

현재 정리한 원문에는 하드웨어, DB 버전, 스키마·인덱스·정렬 키, 실제 SQL, 실행 계획, 캐시 통제, 연결 방식과 시간 측정 경계가 포함되어 있지 않다. 재현 조건이 완전하지 않으므로, 특정 숫자를 다른 환경에 그대로 적용하거나 차이의 원인을 하나로 단정할 수 없다.

20회 중앙값은 실험을 요약하는 값이다. 개별 실행값, 분산, 신뢰구간과 세부 판정 규칙은 이 문서에 없어 통계적 유의성을 별도로 입증하지는 않는다. 화면의 ‘판단 보류’와 빠른 쪽 표시는 원문 기록을 그대로 따른다.

이번 기록은 단일 쿼리의 조회 시간 비교다. 쓰기 처리량, 동시 요청, 저장 비용, 보관 정책, 장애 대응까지 검증한 것은 아니다. 한 요청의 응답 시간 전체나 실제 이용자의 체감 성능과도 구분해야 한다.

공식 문서에서는 컬럼형 저장이 분석 쿼리의 필요한 컬럼을 읽는 데 유리한 이유를 설명한다. PostgreSQL 문서에서도 인덱스가 조건에 맞는 행을 효율적으로 찾도록 도울 수 있다고 설명한다. 다만 이것은 배경 지식이며, 이번 실험이 특정 인덱스나 실행 계획 때문에 빨랐다는 증거는 아니다. [1] [2]

성능 차이를 확인하고도 도입하지 않은 이유

성능상의 이점이 있다는 것과, 그 이점이 지금 서비스에 필요하다는 것은 다른 문제였다.

당시 예상한 조회 규모

적용 대상은 B2B SaaS였다. 당시 내가 예상한 사용 패턴에서는 한 번에 10만 건 이상의 로그 데이터를 대상으로 조회·집계할 일이 많지 않다고 판단했다. 이는 운영 트래픽을 측정해 확인한 수치가 아니라, 그 서비스의 요구에 대한 내 판단이었다. B2B SaaS라면 모두 그렇다는 뜻도 아니다.

반환 행이 적어도 계산 범위는 클 수 있고, 이번 연결 집계처럼 작은 구간에서 차이가 나는 쿼리도 있다. 따라서 ‘10만 건을 반환할 일이 없다’는 사실만으로 도입 여부를 결정할 수는 없다. 나는 당시 예상한 조회 패턴과 성능 이점을 활용할 가능성을 함께 봤다.

학습 비용도 유지보수의 일부

컬럼형 데이터베이스에 대해 주변 개발자들과 이야기했을 때, 개념을 알고 있는 사람이 없었다. 기술의 가치를 낮게 볼 이유는 아니었지만, 팀에 도입한다면 새로 익혀야 할 영역이 생긴다는 신호로 받아들였다.

팀원들의 러닝커브는 결국 유지보수 포인트의 증가라고 판단했다. 당장 활용할 성능 이점과 앞으로 함께 이해하고 관리해야 할 범위를 비교했고, 당시에는 ClickHouse를 도입하지 않기로 했다.

빠르지 않아서가 아니라, 지금 그 장점을 얼마나 활용할 수 있는지를 보고 선택했다.

기존 PostgreSQL에서 별도의 시스템으로 마이그레이션하는 프로젝트는 2026년 7월 말 완료했다. 이 글에서는 저장소를 검토한 경험과 성능 비교에만 집중한다.

AI는 검증 비용을 낮췄고, 판단은 내가 했다

이번 과정에서 AI는 테스트베드를 구성하고 속도 차이를 단순하게 리포트하는 데 활용했다. 결과의 의미를 해석하고, 서비스에 맞는 선택인지 판단하고, 도입하지 않기로 결정한 것은 나였다.

이 경험은 매우 의미가 있었다. 내 상황에 맞지 않았을 뿐, ClickHouse는 앞으로도 충분히 고려할 수 있는 선택지였다. 무엇보다 AI의 도움으로 테스트베드를 만들고 트레이드오프를 비교해보는 일이 이전보다 수월해졌다는 점이 좋았다.

AI가 기술을 골라준 것이 아니라, 내가 직접 비교해볼 수 있는 비용을 낮춰줬다.

도입하지 않은 것도 실험의 결과다

이번에는 ClickHouse를 사용하지 않았다. 그렇다고 실험이 실패했다고 생각하지 않는다. 막연히 압도적으로 빠를 것이라 기대했던 기술이 어느 조건에서 강점을 보이는지 직접 확인했고, 내 상황에서 선택하지 않을 이유도 정리할 수 있었다.

다음에 다른 규모와 조회 패턴의 문제를 만나면 다시 검토할 것이다. 그때도 먼저 묻고 싶은 것은 같다. 이 기술은 얼마나 좋은가보다, 지금 내가 해결하려는 문제에 얼마나 적합한가.

참고 자료

측정값의 출처는 위 원문 기록이다. 아래 공식 문서는 저장 구조와 인덱스에 대한 배경 설명으로만 참고했다.