ELK에서 ClickHouse로: 대규모 로그·이벤트 분석 아키텍처 전환 이유와 비교 분석

엔지니어라면 누구나 뼛속 깊이 새겨진 본능이 있습니다. 어떤 기술이 지나치게 빠르거나 비용이 터무니없이 저렴하다고 하면, 일단 의심부터 하고 보는 습관입니다. 성능이 뛰어나면 가격이 비싸거나, 운영이 복잡하거나, 어떤 치명적인 약점을 감수해야 하는 것이 세상의 이치입니다. 엔지니어링의 세계에서 트레이드오프(Trade-off)는 질량 보존의 법칙만큼이나 거스를 수 없는 자연법칙으로 통합니다.

지난 10년이 넘는 시간 동안 시스템 로그, 애플리케이션 추적, 사용자 행동 이벤트를 다루는 영역에서 업계의 '절대적인 기본값'은 단연 ELK(Elasticsearch, Logstash, Kibana) 스택이었습니다. 새로운 서비스를 띄우면 으레 서버마다 Filebeat나 Logstash를 붙이고, 로그를 Elasticsearch로 쏘아 올린 뒤, Kibana 대시보드를 열어 확인하는 것이 개발팀의 당연한 개발 상식이었습니다.

그런데 최근 몇 년 사이, 데이터 엔지니어링 회의실과 기술 컨퍼런스에서 심상치 않은 대화가 오가기 시작했습니다.

"우리 로그 시스템, Elasticsearch 대신 ClickHouse로 바꿔보면 어떨까요?"

우버(Uber), 클라우드플레어(Cloudflare), 이베이(eBay), 깃랩(GitLab) 같은 글로벌 테크 기업부터 국내의 수많은 이커머스, 핀테크 유니콘 기업들까지 앞다투어 로그 및 시계열 분석의 중심축을 ClickHouse로 전환하고 있습니다. 전환을 마친 엔지니어들은 하나같이 믿기 힘든 이야기를 전합니다. 스토리지 비용이 5분의 1로 줄었고, 수억 건의 로그를 긁어모아 그래프를 그리는 쿼리가 엔터를 치자마자 수백 밀리초 만에 튀어나온다고 말입니다.

도대체 어떻게 이런 일이 가능할까요? ClickHouse가 물리학의 법칙을 깨뜨리는 마법이라도 부린 걸까요? 아니면 우리가 그동안 무언가 잘못된 도구를 쥐고 있었던 걸까요?

이 글에서는 두 기술이 추구하는 근본적인 철학의 차이부터 시작하여, 전환을 이끄는 실질적인 기술적 이유와 현업의 고충, 그리고 도입 전 반드시 따져보아야 할 냉정한 한계점까지 차근차근 짚어보겠습니다.

1. 도서관 사서와 엑셀 회계사: 패러다임의 차이

ClickHouse가 보여주는 기적 같은 성능의 비밀을 이해하려면, 두 시스템이 세상을 바라보는 방식부터 살펴보아야 합니다.

1-1. 책 속의 단어를 찾아주는 도서관 사서 (Elasticsearch)

Elasticsearch의 심장에는 아파치 루씬(Apache Lucene)이라는 검색 라이브러리가 있습니다. 루씬이 일하는 방식은 도서관의 책 뒤편에 붙어 있는 '색인(Index)'과 똑같습니다.

예를 들어 수만 권의 책에서 '결제실패'라는 단어가 어디에 나오는지 찾는다고 상상해 봅시다. 루씬은 문장이 들어오는 즉시 단어 단위로 쪼개어(토큰화), '결제실패'라는 단어가 103번, 502번, 991번 책에 들어있다는 목록을 미리 만들어 둡니다. 이것이 바로 역색인(Inverted Index)입니다.

이 방식은 웹 검색 포털이나 온라인 서점처럼, 사람이 입력한 자연어 문장에서 적절한 문서를 찾고, 오타를 고쳐주며, 검색어와 얼마나 관련이 깊은지 점수(BM25/TF-IDF)를 매기는 데 세상에서 가장 완벽한 구조입니다.

1-2. 장부에서 특정 열만 짚어 계산하는 회계사 (ClickHouse)

반면 ClickHouse는 관계형 분석 데이터베이스(OLAP)입니다. ClickHouse는 데이터를 책처럼 저장하지 않고, 거대한 엑셀 스프레드시트처럼 다룹니다. 그런데 아주 독특한 방식으로 다룹니다.

일반적인 데이터베이스는 한 사람의 정보(이름, 나이, 주소, 주문일시)를 가로 한 줄(Row)로 묶어서 디스크에 차곡차곡 보관합니다. 반면 ClickHouse는 '이름'만 모아둔 파일, '나이'만 모아둔 파일, '주문일시'만 모아둔 파일처럼 세로 한 열(Column) 단위로 쪼개어 디스크에 연속해서 저장합니다. 이것을 컬럼 지향 저장소(Columnar Storage)라고 부릅니다.

1-3. 우리가 매일 로그 시스템에 던지는 진짜 질문들

여기서 질문을 하나 던져보겠습니다.

"우리가 매일 시스템에 쌓아두는 수십억 건의 로그 데이터 중에서, 문학 작품 검색하듯 복잡한 전문 검색을 수행하는 비율은 얼마나 될까요?"

운영팀이 모니터링 대시보드를 열고 던지는 질문을 찬찬히 살펴보면 이렇습니다:

• "오늘 새벽 2시부터 3시 사이에 발생한 에러 로그만 보여줘."
• "주문 서비스(order-api)에서 HTTP 상태 코드가 500 이상인 요청이 분당 몇 건인가?"
• "결제 API의 지난 1시간 동안의 99퍼센타일(p99) 지연 시간(latency)을 그래프로 그려줘."

놀랍게도 현업에서 발생하는 로그 쿼리의 90% 이상은 본문 속의 단어를 찾는 검색이 아니라, '시간과 서비스명으로 범위를 좁힌 뒤 수치를 합산하고 평균을 내는 통계 작업'입니다.

우리는 그동안 엑셀 통계가 필요한 작업에 도서관 사서를 데려다 앉혀놓고, 매초 수십만 건의 영수증 장부를 한 줄 한 줄 읽으며 색인 카드를 손으로 쓰라고 시키고 있었던 셈입니다. 이것이 바로 우리가 겪었던 성능 저하와 자원 낭비의 근본적인 원인이었습니다.

2. 클릭하우스는 왜 이렇게 빠르고 저렴할까?

ClickHouse가 분석 작업에서 압도적인 효율을 내는 이유는 한두 가지 마법이 아니라, 디스크와 CPU가 하는 쓸데없는 일을 극단적으로 덜어낸 설계의 결과입니다.

2-1. 불필요한 열은 쳐다보지도 않는다

만약 한 줄에 50개의 다양한 정보가 담긴 거대한 로그 테이블이 있다고 가정해 봅시다. 여기서 '응답 시간 평균'을 구하려면 timestamp와 latency라는 딱 2개 컬럼만 있으면 충분합니다.

기존 행 기반 시스템이나 Elasticsearch는 문서를 통째로 꺼내오거나 관련 메모리 영역을 넓게 훑어야 합니다. 하지만 컬럼 기반인 ClickHouse는 디스크에서 오직 latency 컬럼 파일만 쏙 뽑아서 메모리로 올립니다. 나머지 48개 컬럼은 디스크 헤드가 건드리지도 않습니다. 읽어야 할 바이트 수 자체가 물리적으로 20분의 1, 50분의 1로 줄어드는 것입니다.

2-2. 같은 성격의 데이터끼리 모여 기적 같은 압축이 일어난다

디스크에 글자를 저장할 때, 내용이 제각각인 문장(예: JSON 본문 전체)을 압축하는 것과, 똑같은 데이터 타입이 연속으로 나열된 데이터를 압축하는 것은 효율 면에서 하늘과 땅 차이입니다.

ClickHouse의 컬럼 파일 안에는 오직 정수형이면 정수형, 타임스탬프면 타임스탬프만 나란히 모여 있습니다.

• 연속으로 증가하는 시간 데이터: 앞뒤 차이값만 저장하는 DoubleDelta 압축
• 반복되는 문자열(예: 리전 이름, 로그 레벨 INFO/WARN/ERROR): 번호표를 매겨 저장하는 LowCardinality 딕셔너리 압축
• 일반 텍스트 데이터: 블록 단위 LZ4, ZSTD 압축

반면 Elasticsearch는 원본 JSON 문자열(_source)을 그대로 보관하면서, 빠른 검색을 위한 역색인과 통계를 위한 doc_values 컬럼 캐시를 따로따로 만듭니다. 그 결과 데이터가 들어가면 원본 텍스트 용량의 1.2배에서 2배로 덩치가 부풀어 오릅니다.

ClickHouse는 반대로 원본 텍스트 대비 5배에서 10배, 상황에 따라 15배까지 데이터를 꽉 압축해 버립니다. 똑같은 한 달 치 로그를 담는 데 드는 디스크 비용이 5분의 1 이하로 뚝 떨어지는 비결입니다.

2-3. 한 땀 한 땀 검사하지 않고 한 번에 쓸어 담는다 (SIMD 벡터 연산)

학생 1,000명의 시험 점수 평균을 낸다고 해봅시다. 한 명씩 불러서 점수를 받아 적고 더하는 방식이 전통적인 쿼리 엔진의 동작 방식입니다.

ClickHouse는 CPU의 최신 하드웨어 가속 기술인 SIMD(Single Instruction Multiple Data)를 적극적으로 활용합니다. CPU 레지스터에 숫자를 한 묶음으로 얹어놓고, 단 하나의 CPU 사이클로 수십 개의 데이터를 동시에 덧셈합니다. 마치 한 사람씩 줄을 세워 신분증을 검사하던 검문소에서, 열 명이 동시에 통과할 수 있는 자동 게이트를 열어젖힌 것과 같습니다.

2-4. 촘촘한 인덱스 대신 성긴 표시(Sparse Mark)로 건너뛰기

우리가 흔히 쓰는 관계형 데이터베이스(MySQL, PostgreSQL)나 Elasticsearch는 거의 모든 행마다 위치를 가리키는 촘촘한 인덱스를 둡니다. 이 인덱스를 유지하는 데만도 엄청난 메모리와 디스크가 들어갑니다.

ClickHouse는 발상을 전환했습니다. 대략 8,192개 행마다 깃발(Mark)을 하나씩 꽂아둡니다. 이를 희소 기본 인덱스(Sparse Primary Index)라고 부릅니다.

[인덱스 깃발]     깃발 1                  깃발 2                  깃발 3
                  │                       │                       │
[정렬된 데이터]   [09:00:00 ~ 09:05:00]   [09:05:01 ~ 09:10:00]   [09:10:01 ~ 09:15:00]
                  └─ 8,192개 데이터 묶음 ─┴─ 8,192개 데이터 묶음 ─┘

만약 '09시 12분'의 로그를 찾는 쿼리가 들어오면, ClickHouse는 깃발 1과 깃발 2에 속한 약 16,000개의 데이터는 뚜껑도 열어보지 않고 통째로 건너뜁니다(Skip). 인덱스 크기가 워낙 작다 보니 수십억 건의 데이터 인덱스도 서버 메모리에 가볍게 올라가고, 조건에 맞지 않는 데이터 블록은 거대한 보폭으로 껑충껑충 건너뛰며 스캔합니다.

3. 현업 엔지니어가 절감하는 운영의 고통: ELK의 아킬레스건

성능 수치보다도 엔지니어들을 ClickHouse로 이끄는 더 큰 원동력은 바로 '운영 안정성'입니다. Elasticsearch를 대규모로 운영해 본 사람이라면 누구나 겪어보았을 대표적인 고통들이 있습니다.

3-1. 공포의 JVM 힙 메모리와 31GB의 저주

Elasticsearch는 Java로 작성되어 JVM 위에서 돌아갑니다. 그런데 Java의 객체 포인터 압축(Compressed OOPs) 기술 특성상, 노드 하나에 줄 수 있는 최대 권장 힙 메모리는 약 31GB로 제한됩니다.

호스트 서버에 128GB나 256GB짜리 거대한 RAM을 꽂아주어도, Elasticsearch 노드 하나가 그 메모리를 온전히 다 쓰지 못합니다. 결국 한 대의 강력한 물리 서버 안에 인위적으로 여러 개의 컨테이너를 쪼개어 띄워야 합니다.

더 무서운 것은 대규모 집계 쿼리가 들어왔을 때입니다. 힙 메모리가 꽉 차면 자바 가비지 컬렉터(GC)가 출동하면서 모든 작업을 일시 정지시키는 'Stop-the-world'가 발생합니다. 수 초 동안 서버가 묵묵부답이 되며 노드가 클러스터에서 이탈하고, 샤드(Shard)들이 길을 잃으며 클러스터 상태 모니터에 빨간불(Red Alert)이 켜지는 악몽이 반복됩니다.

ClickHouse는 순수 C++로 작성되었습니다. 가비지 컬렉터 자체가 존재하지 않습니다. 서버에 256GB의 메모리가 있다면, 그 메모리를 운영체제의 페이지 캐시와 버퍼 풀로 시원하게 전부 쏟아붓습니다. 쿼리가 메모리를 너무 많이 쓰면 사전에 설정한 제한값에 따라 해당 쿼리만 정중하게 에러를 내고 멈출 뿐, 노드 전체가 기절하는 일은 발생하지 않습니다.

3-2. 치솟는 클라우드 청구서와 스토리지 티어링

로그 보관 주기를 늘려야 하는 감사 요건이 생길 때마다, 인프라 담당자는 머리를 싸매게 됩니다. 비싼 NVMe SSD에 수개월 치 로그를 계속 쌓아두는 것은 비용 감당이 되지 않기 때문입니다.

ClickHouse는 태생적으로 오브젝트 스토리지(Amazon S3, MinIO, GCS)와 한 몸처럼 연동됩니다.

-- 스토리지 정책 예시
최근 3일 데이터   ───> 고속 로컬 NVMe SSD
4일 지난 데이터   ───> 저렴한 Amazon S3 오브젝트 스토리지

이 모든 계층 이동이 백그라운드에서 완전히 자동으로 이루어집니다. 더 놀라운 점은, 개발자가 작성하는 조회 쿼리는 데이터가 SSD에 있든 S3에 있든 상관없이 똑같은 SQL로 실행된다는 것입니다. ClickHouse 쿼리 엔진이 S3에 있는 압축 블록에서 필요한 컬럼만 HTTP 범위 요청(Range Read)으로 쏙쏙 골라 읽어오기 때문에, 저렴한 S3에 테라바이트급 데이터를 몇 달이고 쟁여둘 수 있습니다.

3-3. 라이선스 이슈와 오픈소스 생태계의 안도감

2021년 Elastic이 오랜 아파치 2.0 라이선스를 버리고 독자적인 SSPL(Server Side Public License)로 정책을 선회하면서, 수많은 기업들이 라이선스 위반 소송이나 벤더 종속에 대한 불안감을 느끼게 되었습니다. 이로 인해 AWS 진영이 OpenSearch로 갈라져 나오면서 생태계도 파편화되었습니다.

ClickHouse는 가장 자유롭고 관대한 Apache License 2.0을 변함없이 지키고 있습니다. 또한 현대적 모니터링의 표준인 Grafana 공식 플러그인, 클라우드 네이티브 텔레메트리 수집 표준인 OpenTelemetry Collector와의 완벽한 궁합 덕분에, 특정 상용 벤더에 얽매이지 않는 투명한 인프라를 구축할 수 있습니다.

4. ELK vs ClickHouse 구조 및 특성 비교

두 아키텍처가 로그를 받아들이고 처리하는 파이프라인의 전체 그림과 세부 지표를 비교해 보겠습니다.

4-1. 데이터 파이프라인 아키텍처 비교

[전통적인 ELK 아키텍처]
각종 서비스 로그
      │
      ▼
Logstash / Filebeat (무거운 파이프라인 / 메모리 소모)
      │
      ▼
Elasticsearch (루씬 역색인 생성 + 원본 복사 + 31GB 힙 제한)
      │
      ▼
Kibana (Discover, 쿼리 시각화, APM 대시보드)


[현대적인 ClickHouse 기반 로그 아키텍처]
각종 서비스 로그
      │
      ▼
Vector / Fluent Bit / OTel Collector (초경량 Rust/C 수집기)
      │
      ▼ (대규모 피크 완충)
Apache Kafka
      │ (배치 쓰기 최적화)
      ▼
ClickHouse (C++ 엔진 / 컬럼 압축 / MergeTree / S3 계층화)
      │
      ▼
Grafana / 사내 웹 포털 / ClickHouse Web Console

4-2. 핵심 지표 한눈에 보기

5. 모든 경우에 ClickHouse가 정답일까? (냉정한 트레이드오프)

처음에 이야기했듯이, 엔지니어링에 '만병통치약'은 없습니다. 만약 누군가 "이제 모든 시스템에서 Elasticsearch를 걷어내고 ClickHouse로 바꾸자!"고 주장한다면 그것은 또 다른 위험한 착각입니다. ClickHouse에도 뚜렷한 약점이 존재합니다.

5-1. 진짜 '사람의 언어'를 찾아야 하는 경우

검색창에 사용자가 입력하는 오타 섞인 단어를 찾고, 한국어 형태소를 분석하여 '사과를', '사과가', '사과'를 같은 의미로 묶어내며, 어떤 상품이 고객의 의도와 가장 밀접한지 점수를 매겨 정렬해야 하는 일은 여전히 Elasticsearch의 독무대입니다. ClickHouse는 텍스트를 깊이 있게 해체하고 이해하는 검색 엔진이 아니라, 정형화된 데이터를 번개처럼 스캔하는 분석기이기 때문입니다.

5-2. 단 한 줄의 데이터를 즉시 고치거나 지워야 하는 경우

ClickHouse는 한 번 들어간 데이터는 절대 바뀌지 않는 '추가 전용(Append-only)' 시계열 데이터에 특화되어 있습니다.

만약 개인정보 보호 규정(GDPR)이나 사용자의 요청으로 특정 사용자 ID의 로그 몇 건을 즉시 삭제하거나 수정해야 한다면, ClickHouse의 ALTER TABLE ... UPDATE / DELETE 명령은 몹시 비싼 대가를 치러야 합니다. 백그라운드에서 해당 조건이 포함된 거대한 데이터 파트 파일 전체를 디스크에서 새로 쓰기 때문입니다. 수시로 데이터가 변경되는 쇼핑몰 장바구니나 트랜잭션 데이터베이스의 자리를 ClickHouse가 대신할 수 없는 이유입니다.

5-3. 턴키 UI와 SQL 학습 곡선

Kibana는 비개발자나 신입 엔지니어도 마우스 몇 번 클릭하고 검색어를 치면 곧바로 로그 흐름을 볼 수 있는 친절한 완성형 제품입니다.

반면 ClickHouse는 데이터베이스 엔진 그 자체입니다. 개발자가 Grafana를 따로 띄워 대시보드를 연동해야 하고, 원하는 로그를 추출하기 위해 SQL 쿼리를 능숙하게 짤 줄 알아야 합니다. 팀 내에 SQL에 익숙하지 않은 구성원이 많다면 초기 정착 과정에서 상당한 학습 비용이 들 수 있습니다.

6. 현실적인 마이그레이션 가이드

그렇다면 이미 거대하게 돌아가고 있는 ELK 클러스터를 보유한 팀은 어떻게 접근해야 할까요? 빅뱅 방식의 전면 교체는 절대 권장되지 않습니다. 실무에서 가장 검증된 점진적 도입 전략을 소개합니다.

6-1. 카프카를 활용한 듀얼 라이팅(Dual-write)

수집기와 저장소 사이에 Apache Kafka를 버퍼로 두고 양쪽에 동시에 데이터를 쏘아주는 방식입니다.

                  ┌───> Logstash ───> Elasticsearch ───> Kibana
[로그 수집기] ───> Kafka
                  └───> Vector   ───> ClickHouse    ───> Grafana

기존 ELK 모니터링 체계를 평소처럼 유지한 채, 동일한 로그 스트림을 ClickHouse에도 흘려보냅니다. Grafana에 동일한 화면을 구성해 보면서 한두 달간 집계 수치와 누락 여부를 대조해 봅니다. 속도와 비용 절감이 충분히 검증되고 팀원들이 Grafana에 익숙해졌을 때, 기존 ELK 파이프라인의 보관 주기를 줄여나가며 점진적으로 전원을 내리면 됩니다.

6-2. 로그 메시지 검색을 위한 최신 스킵 인덱스 활용

ClickHouse에서 긴 에러 로그 메시지를 검색할 때 성능을 끌어올리려면 토큰 블룸 필터(Token Bloom Filter) 또는 최신 버전의 인버티드 스킵 인덱스를 컬럼에 걸어줍니다.

CREATE TABLE service_logs (
    timestamp DateTime64(3, 'UTC'),
    service_name LowCardinality(String),
    level LowCardinality(String),
    trace_id String,
    message String,
    -- 메시지 내 단어 검색을 빠르게 건너뛰기 위한 토큰 블룸 필터
    INDEX idx_message message TYPE tokenbf_v1(30720, 2, 0) GRANULARITY 1,
    INDEX idx_trace trace_id TYPE bloom_filter() GRANULARITY 1
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(timestamp)
ORDER BY (service_name, level, timestamp);

이렇게 하면 message LIKE '%ConnectionReset%' 같은 부분 문자열 검색을 실행할 때, 해당 단어가 절대 들어있지 않은 수백만 건의 데이터 블록을 통째로 패스하여 검색 속도를 대폭 끌어올릴 수 있습니다.

6-3. 파티션은 하루 단위가 아니라 월 단위로

처음 ClickHouse를 접하는 엔지니어들이 가장 흔하게 범하는 실수가 테이블을 만들 때 PARTITION BY toDate(timestamp)로 일 단위 파티션을 잘게 쪼개는 것입니다.

파티션이 너무 잘게 쪼개지면 디스크 파트 파일의 개수가 수만 개로 불어나 서버가 백그라운드 머지를 처리하느라 지치게 됩니다. 하루에 수십 테라바이트가 들어오는 초대형 서비스가 아니라면, PARTITION BY toYYYYMM(timestamp)으로 월 단위로 넉넉하게 묶어주고, 날짜와 시간 검색은 ORDER BY의 타임스탬프 조건으로 처리하는 것이 훨씬 안정적입니다.

7. 마치며

엔지니어링에서 영원한 것은 없습니다. 지난 10년간 우리의 든든한 친구였던 ELK 스택은 텍스트 검색 분야에서 여전히 눈부신 걸작입니다.

하지만 데이터의 양이 기하급수적으로 폭증하고, 인프라 비용 절감(FinOps)이 기업 생존의 화두가 된 오늘날, 단순 집계와 통계 쿼리를 위해 거대한 역색인 엔진을 돌리는 것은 너무나 무거운 사치가 되었습니다.

• 형태소 분석, 동의어 처리, 오타 교정, 유사도 점수 기반의 전문 검색이 중심이라면 Elasticsearch를 지켜야 합니다.
• 수억에서 수십억 건의 로그와 메트릭을 초고속으로 집계하고, 스토리지 비용을 몇 배 이상 줄이며, JVM 메모리 장애로부터 해방되고 싶다면 ClickHouse는 더할 나위 없는 명쾌한 해답입니다.

내가 풀고자 하는 문제의 본질이 '단어 검색'인지, 아니면 '시계열 데이터의 대규모 분석'인지 질문해 보시기 바랍니다. 도구의 목적과 내 문제의 본질이 일치하는 순간, 복잡했던 시스템 엔지니어링의 병목은 놀랍도록 시원하게 풀려나갈 것입니다.

참고 링크:

• 클릭하우스(ClickHouse) - 기적의 데이터베이스 기술 (조성문의 블로그)
• ClickHouse 공식 아키텍처 및 컬럼 지향 스토리지 가이드
• Uber Engineering Blog: Building an Observability Engine with ClickHouse
• Cloudflare: How Cloudflare Analyzes Petabytes of Log Data with ClickHouse
• Grafana ClickHouse 공식 데이터소스 플러그인 문서