옵저버빌리티 전쟁, 클릭하우스가 이기고 있다: 로그·메트릭·트레이스는 왜 '컬럼'으로 흐르는가

한 문장에서 시작하는 이야기

2026년, 엔지니어 Mat Duggan이 쓴 글 한 편이 개발자들 사이에서 조용히, 그러나 널리 퍼졌다. 제목은 도발적이다. 《ClickHouse is Winning the Observability Wars(클릭하우스가 옵저버빌리티 전쟁에서 이기고 있다)》. 10년 넘게 여섯 개 회사를 거치며 시스템을 운영해 온 저자의 결론은 한 문장으로 요약된다.

"로그(log)는 이 일을 하는 내내, 단 한 번도 최악의 골칫거리이기를 멈춘 적이 없다. 그런데 그 골칫거리를 스케일이 커져도 똑같이 단순하게 유지해 주는 도구가 하나 있다 — 클릭하우스다."

이 문장이 낯설게 들린다면, 먼저 질문을 하나 바꿔 던져보자. 우리 서비스가 지금 이 순간 왜 느린지, 누가 에러를 겪고 있는지, 어젯밤 3시에 무슨 일이 있었는지를 알아내려면 무엇이 필요할까? 답은 '데이터'다. 서버가 쏟아내는 로그, 메트릭, 트레이스라는 어마어마한 양의 흔적들. 그리고 그 흔적을 저장하고, 되묻고, 답을 얻는 기술 — 그것을 우리는 옵저버빌리티(observability, 관측 가능성) 라고 부른다.

이 글의 주장은 단순하다. 지난 10년간 이 옵저버빌리티 시장을 지배해 온 도구들(Elasticsearch, Datadog, Grafana 스택)이, 데이터가 폭발하는 2026년에 이르러 하나둘 무너지고 있고, 그 자리를 러시아에서 태어난 한 컬럼형 데이터베이스가 빠르게 차지하고 있다는 것이다.

📌 이 글의 약속. 첫째, 옵저버빌리티가 무엇이고 왜 어려운지를 밑바닥부터 짚는다. 둘째, 왜 하필 '컬럼(열)'이 답인지를 2005년 논문과 클릭하우스의 탄생 설화에서부터 따라간다. 셋째, 아키텍처의 속살(MergeTree·압축·벡터화)을 그림으로 열어본다. 넷째, 이 글의 하이라이트인 '스케일 전쟁' 표를 함께 읽는다. 다섯째, 2026년 지금 이 기술이 왜 중요한지를 실제 사례와 함께, 그리고 한계까지 솔직하게 짚는다. 용어가 생소해도 괜찮다. 하나씩, 천천히.

---

제1장: 옵저버빌리티란 무엇인가 — 세 개의 기둥

'옵저버빌리티'는 원래 제어공학 용어다. 시스템의 바깥에서 나오는 출력만 보고, 그 안에서 무슨 일이 벌어지는지 추론할 수 있는 정도를 뜻한다. 소프트웨어로 옮기면 이렇다 — 서버 내부를 직접 들여다볼 수 없으니, 서버가 밖으로 뱉어내는 신호를 보고 상태를 알아맞히는 능력.

전통적으로 그 신호는 세 종류(three pillars, 세 개의 기둥) 로 나뉜다.

세 줄로 외워두면 편하다. 메트릭은 문제가 있다고 알리고, 로그는 무슨 일인지 설명하고, 트레이스는 어디서 터졌는지 짚어준다.

'모니터링'과 '옵저버빌리티'는 다르다

여기서 많은 사람이 헷갈리는 지점을 확실히 하자. 모니터링(monitoring) 은 미리 정해둔 질문에 답한다. "CPU가 80%를 넘으면 알려줘" — 물어볼 질문을 이미 알고 있는 것이다. 업계 용어로 알려진 미지(known unknowns) 다.

반면 옵저버빌리티 는 미리 상상하지 못한 질문에 답할 수 있어야 한다. 새벽에 장애가 터졌는데 원인을 전혀 모른다. "혹시 특정 국가의 안드로이드 앱 15.2 버전 사용자들만, 결제 API를 3번 이상 재시도할 때 터지는 건가?" — 이런 질문은 사전에 대시보드로 만들어 둘 수 없다. 이것이 알려지지 않은 미지(unknown unknowns) 이고, 진짜 옵저버빌리티의 핵심이다.

바로 이 지점이 이 글의 열쇠다. 옵저버빌리티가 "미리 상상 못 한 질문에 즉석으로 답하는 능력"이라면, 그 능력은 결국 밑에 깔린 데이터베이스가 얼마나 빠르고 싸게 원본을 되씹어 주느냐로 판가름 난다. 그리고 그 데이터베이스 싸움에서, 2026년 현재 클릭하우스가 앞서 나가고 있다는 것이다.

---

제2장: 왜 옛날 방식이 무너지는가 — grep이 통하던 시절의 끝

Duggan의 글에서 가장 공감을 산 대목은 이거다. "개발자들의 기대치는 작은 시스템에서 만들어졌다."

서버가 한 대일 때, 로그는 그냥 텍스트 파일이다. 문제가 생기면 SSH로 접속해서 grep ERROR app.log, jq 몇 번이면 원인이 나온다. 완벽하다. 이 경험이 우리 머릿속에 "로그 다루기는 쉬운 일"이라는 인상을 새긴다.

그런데 서버가 수천 대가 되고, 하루에 수 테라바이트의 로그가 쏟아지는 순간, 이 직관은 산산조각 난다. 두 가지 괴물이 등장한다.

괴물 ①: 스키마 드리프트 (Schema Drift)

로그의 모양은 시간이 지나면서 계속 변한다. 어떤 팀은 user_id라고 쓰고, 다른 팀은 userId, 또 다른 팀은 uid라고 쓴다. 새 필드가 생기고 옛 필드가 사라진다. 정형화된 표(table)를 기대했던 검색 엔진은 이 끊임없이 변하는 모양 앞에서 인덱스가 비대해지고 느려진다.

괴물 ②: 카디널리티 폭발 (Cardinality Explosion)

이게 진짜 킬러다. 카디널리티 란 "어떤 필드가 가질 수 있는 서로 다른 값의 개수"다. 국가 필드는 값이 200여 개(낮은 카디널리티)지만, user_id나 trace_id는 값이 수백만~수십억 개(높은 카디널리티)다.

전통적인 메트릭 시스템(예: Prometheus)은 레이블(label)의 조합마다 별도의 시계열(time series)을 하나씩 만든다. 여기에 user_id 같은 고카디널리티 필드를 레이블로 넣으면 어떻게 될까?

그래서 전통 시스템을 쓰는 팀들은 눈물을 머금고 "소중한 맥락을 버린다." user_id, trace_id 같은 필드를 아예 저장하지 않는 것이다. 그런데 이건 자기모순이다. 앞 장에서 봤듯이 진짜 옵저버빌리티(누가·어디서·왜)에 답하려면 바로 그 고유 식별자들이 반드시 필요하기 때문이다. 맥락을 버리는 순간, 옵저버빌리티는 이름만 남는다.

정리하면, 옛날 도구들이 무너지는 이유는 두 가지 상반된 고객을 동시에 만족시켜야 하기 때문이다.

이 딜레마를 정면으로 푸는 방법이, 알고 보면 데이터를 저장하는 방향을 90도 돌리는 것 이었다. 행(row)이 아니라 열(column)로.

---

제3장: 행이냐 열이냐 — 컬럼형 데이터베이스의 뿌리

90도 돌리기: 행 저장 vs 열 저장

데이터베이스에 표를 저장한다고 상상하자. 표에는 시각, 사용자, 국가, 응답시간, 상태코드… 40개의 열(column, 필드)이 있고, 로그 한 줄이 하나의 행(row)이다.

전통적인 데이터베이스(MySQL, PostgreSQL 등 '행 저장') 는 이 표를 한 줄씩 디스크에 붙여 쓴다. 1번 로그의 40개 필드를 모두 쓰고, 그다음 2번 로그의 40개 필드… 이 방식은 "1번 주문 전체를 가져와" 같은 한 행의 모든 정보 가 필요한 업무(주문 처리, 결제 — OLTP라고 부른다)에 최적이다.

컬럼형 데이터베이스(클릭하우스 등 '열 저장') 는 표를 세로로 눕혀 저장한다. 모든 로그의 시각만 쭉 모아서 한 파일에, 국가만 쭉 모아서 다른 파일에… 이렇게 열 단위로 저장한다.

이 사소해 보이는 차이가 옵저버빌리티에서 왜 결정적일까? 앞 장에서 봤듯이 옵저버빌리티 질문은 대개 이렇게 생겼다 — "지난 1시간, 국가별 평균 응답시간은?" 이 질문에 필요한 열은 시각, 국가, 응답시간 딱 3개다. 나머지 37개 열은 볼 필요가 없다.

핵심 통찰: 로그·메트릭·트레이스는 본질적으로 "수십억 행을 훑어서 몇 개 열만 집계하는" 질문이다. 이건 컬럼형이 세상에서 가장 잘하는 일이다. 반대로 "주문 1건 조회" 같은 건 잘 안 하는 일 — 그런데 옵저버빌리티엔 그런 질문이 거의 없다. 애초에 모양이 딱 맞는 것이다.

뿌리를 찾아서: C-Store 논문 (2005)

이 '열로 눕히기' 아이디어는 최신 유행이 아니다. 학문적 뿌리는 2005년으로 거슬러 올라간다. 데이터베이스 분야의 전설적 인물 마이클 스톤브레이커(Michael Stonebraker) 를 필두로 MIT·브라운·브랜다이스·매사추세츠 보스턴 대학 연구진이 VLDB 학회(노르웨이 트론헤임)에서 발표한 논문 《C-Store: A Column-oriented DBMS》 다.

이 논문의 문제의식은 지금 우리가 본 것과 정확히 같았다. 당시 거의 모든 상용 DB는 쓰기 최적화(write-optimized, 행 저장) 였다. 하지만 분석(읽기)이 지배적인 워크로드에는 정반대의 설계, 읽기 최적화(read-optimized) 가 필요하다는 것. 논문이 제시한 설계 원칙들은 오늘날 클릭하우스에 그대로 살아 있다.

C-Store의 코드는 2006년을 마지막으로 멈췄지만, 상용 버전 버티카(Vertica) 로 이어져 살아남았다. 그리고 이 '읽기 최적화 컬럼 DB'라는 계보의 가장 성공적인 오픈소스 후손이, 지구 반대편 러시아에서 완전히 독립적으로 태어나고 있었다.

---

제4장: 클릭하우스의 탄생 — 얀덱스의 한 엔지니어

시계를 2008~2009년, 러시아 모스크바로 돌리자. 무대는 '러시아의 구글'이라 불리는 얀덱스(Yandex). 그곳의 웹 분석 서비스 얀덱스 메트리카(Yandex.Metrica) — 구글 애널리틱스의 러시아판 — 는 심각한 문제에 부딪혔다.

메트리카는 전 세계 웹사이트의 방문 기록을 실시간으로 집계해 보여줘야 했다. 그 양이 상상을 초월했다. 2014년 기준 하루 약 120억 건의 이벤트(페이지뷰·클릭·세션). 그런데 고객사가 대시보드에서 아무 조건이나 걸어 즉석 리포트를 뽑으면, 그걸 미리 집계해 둘 수 없으니 매번 원본 수백억 행을 실시간으로 훑어야 했다.

당시 세상에 있던 어떤 데이터베이스도 이걸 감당하지 못했다. 그래서 얀덱스의 엔지니어 알렉세이 밀로비도프(Alexey Milovidov) 는 없는 도구를 직접 만들기로 한다. 그렇게 태어난 것이 클릭하우스(ClickHouse) 다. 이름의 뜻마저 실용적이다 — "Click stream + Data wareHouse"(클릭 스트림 데이터 창고).

얼마나 큰 규모를 감당했는지 숫자로 보면 감이 온다. 메트리카를 돌리던 클릭하우스 클러스터는 결국 374대 서버로 자라났고, 20조 3천억 행을 저장했으며, 압축 후 용량이 약 2페타바이트(압축 전 17PB)였다. 하루에 새로 밀어 넣는 레코드가 1,000억 건 이상. 이 괴물 같은 규모를 견디도록 처음부터 벼려진 도구이기에, 오늘날 테라바이트급 옵저버빌리티는 클릭하우스에게 오히려 '가벼운' 축에 든다.

💡 왜 이 탄생 설화가 중요한가. 클릭하우스는 "빠른 DB를 만들자"에서 출발한 게 아니라, "실시간 웹 로그 분석"이라는 옵저버빌리티와 쌍둥이인 문제에서 태어났다. 즉 옵저버빌리티는 클릭하우스에게 나중에 갖다 붙인 용도가 아니라, 태생 그 자체다. 도구와 문제의 모양이 처음부터 같았다.

---

제5장: 아키텍처 심층 — MergeTree·압축·벡터화

이제 속살을 열어보자. 클릭하우스가 어떻게 그 속도를 내는지, 핵심 세 가지 장치를 뜯어본다. 용어가 생소하겠지만 비유로 하나씩 풀겠다.

장치 ①: MergeTree — '이미 다 쓴 원고를 합치는' 저장 엔진

클릭하우스의 심장은 MergeTree(머지트리) 라는 저장 엔진 계열이다. 발상은 LSM 트리(Log-Structured Merge Tree) 에서 왔다. 작동 방식은 의외로 도서관 사서를 닮았다.

이 "불변 파트를 쌓고, 뒤에서 합친다"는 구조 덕분에 클릭하우스는 초당 수백만 행을 밀어 넣으면서 동시에 빠르게 읽을 수 있다. 로그처럼 끝없이 쏟아지고(append-only), 시간순이며, 지우지 않는 데이터에 완벽히 들어맞는다.

장치 ②: 세밀한 조직화 — 그래뉼과 희소 인덱스

파트 안에서 데이터는 다시 그래뉼(granule) 이라는 단위로 쪼개진다. 그래뉼은 클릭하우스가 스캔할 때 다루는 가장 작은 덩어리로, 보통 8,192행이다. 실제 디스크 입출력은 약 1MB짜리 압축 블록 단위로 이뤄진다.

여기서 클릭하우스의 영리함이 나온다. 전통 DB는 모든 행마다 인덱스를 만든다(빽빽한 인덱스). 클릭하우스는 대신 그래뉼마다 대표값 하나씩만 기록하는 희소 인덱스(sparse index) 를 쓴다. 마치 두꺼운 책의 모든 문장이 아니라 각 페이지 첫 줄만 색인해 두는 것과 같다. 인덱스 자체가 가벼워 메모리에 통째로 올라가고, "이 조건은 3번~7번 페이지에만 있겠군" 하고 나머지를 통째로 건너뛴다.

장치 ③: 압축 코덱 — 값의 성격에 맞춘 맞춤옷

앞서 컬럼 저장은 압축이 잘 된다고 했다. 클릭하우스는 여기서 한 발 더 나간다. 열의 데이터 성격에 따라 다른 압축 코덱을 입힌다.

예컨대 로그의 타임스탬프는 대개 아주 조금씩 증가한다. Delta 코덱은 "이전 값과의 차이"만 저장해 이런 데이터를 극적으로 줄인다. DoubleDelta는 "차이의 차이"까지 저장해, 일정 간격으로 증가하는 시퀀스를 최대 800:1까지 압축한다. 이 맞춤형 압축이 클릭하우스의 저장 비용을 경쟁자 대비 몇 배씩 낮추는 비결이다.

장치 ④: 벡터화 실행 — 한 번에 한 다발씩

마지막으로 질의 실행 방식. 전통 DB가 데이터를 한 행씩 처리한다면(한 알씩 까먹기), 클릭하우스는 벡터화 실행(vectorized execution) 으로 값을 한 다발(batch)씩 묶어 CPU의 SIMD 명령으로 동시에 처리한다(한 움큼씩 까먹기). 컬럼 저장이라 같은 종류 값이 이미 나란히 있으니, 이 '한 다발 처리'가 자연스럽게 맞아떨어진다. 이것이 수십억 행 집계를 1초 이하로 끝내는 힘이다.

---

제6장: 스케일 전쟁 — 데이터가 10배 늘어도 그림은 똑같다

이제 이 글의 하이라이트다. Duggan의 원문이 화제가 된 진짜 이유는, 데이터 규모가 커질수록 각 도구가 어떻게 변하는지를 세 단계로 나눠 적나라하게 비교했기 때문이다. 등장인물은 넷이다.

1단계: 하루 1TB — "다들 괜찮아요"

작은 규모에서는 넷 다 잘 돈다. 복잡도도 비슷하다. 차이는 오직 비용뿐이다. 그런데 그 비용 차이가 이미 눈이 휘둥그레진다.

같은 하루 1TB인데 클릭하우스는 월 150~250만 원 남짓, Datadog은 6천만~1억 원대. 무려 30배 차이가 이미 여기서 벌어진다. (막대 너비는 Datadog 최대치 75K를 기준 100%로 환산했다.)

2단계: 하루 5TB — "균열이 시작된다"

여기서부터 도구들의 성격이 갈라진다. 단순히 비싸지는 게 아니라, 구조 자체가 뒤틀리기 시작한다.

특히 Datadog 사례가 상징적이다. 데이터가 늘자 "청구서를 줄이는 것만이 목적인 팀" 을 따로 만든다는 것 — 도구를 쓰려고 사람을 쓰는 게 아니라, 도구값을 깎으려고 사람을 쓰는 역설이다.

3단계: 하루 10TB — "혼자만 그대로다"

결정적 국면. 이 지점에서 세 경쟁자는 거의 다른 종(種)의 시스템으로 변모하고, 클릭하우스만 홀로 처음 모습을 유지한다.

원문에서 가장 인상적인 문장이 이것이다 — "10TB의 다이어그램은 1TB의 다이어그램과 똑같은 다이어그램이다. 샤드 수만 다르다." 이것이 클릭하우스가 이기고 있는 진짜 이유다. 경쟁자들은 규모가 커질 때마다 머릿속 모델(mental model)을 통째로 갈아엎어야 한다. Kafka 버퍼, 샤드 수학, 연합 클러스터, 파이프라인 팀… 반면 클릭하우스는 커져도 "서버 몇 대 더" 라는 같은 문장으로 설명된다. 규모가 곧 복잡도가 되지 않는 것 — 이 단순함이 곧 승리다.

⚖️ 공정하게 짚을 것. 클릭하우스도 공짜 점심은 아니다. 리밸런싱(데이터 재분배)이 수동이라 미리 용량을 잡거나 이중 쓰기(dual-write) 마이그레이션을 해야 한다. 작은 규모에서는 오히려 스키마 설계와 질의 엔진 전문성을 미리 요구해 개발자를 잠시 더 고생시킨다. 하지만 그 '선불 복잡도'를 한 번 치르면, 규모가 10배로 뛰어도 운영 부담이 지수적으로 늘지 않는다. 복잡도를 나중에 폭발적으로 겪느냐, 처음에 조금 치르고 마느냐의 선택이다.

---

제7장: ClickStack과 wide events — 2026년의 통합

그렇다면 "클릭하우스를 옵저버빌리티에 쓴다"는 건 실제로 어떤 모습일까? 2026년의 답은 ClickStack(클릭스택) 이다. 클릭하우스가 직접 내놓은, 로그·메트릭·트레이스·세션을 하나로 묶은 오픈소스 옵저버빌리티 스택이다. 구성은 딱 세 층이다.

각 층은 독립적으로 확장된다. 데이터 유입이 늘면 Collector를 늘리고, 저장·질의가 버거우면 ClickHouse를 늘린다. 앞 장에서 본 "그림이 안 변한다"가 여기서 실현된다.

세 기둥에서 'wide events'로

그런데 ClickStack의 진짜 사상적 전환은 아키텍처가 아니라 데이터 모델에 있다. 제1장에서 옵저버빌리티를 로그·메트릭·트레이스 '세 기둥'으로 나눴던 걸 기억하자. 전통적으로는 이 셋을 각각 다른 시스템(Prometheus·Elasticsearch·Jaeger)에 나눠 담았다. 그 결과가 악명 높다.

컬럼형이라 고카디널리티가 부담이 아니라는 점이 이 모델을 가능케 한다. 제2장에서 전통 시스템이 카디널리티 폭발 때문에 맥락을 '버려야' 했던 걸 떠올리자. 컬럼 DB에서 user_id는 그냥 압축 잘 되는 열 하나다. 그래서 버리지 않고 다 담을 수 있다. ClickStack은 심지어 반정형 이벤트가 들어오면 자동으로 열을 만들고 타입을 관리하는 네이티브 JSON 지원까지 갖췄다.

그 효율의 극단이 클릭하우스 자신의 내부 옵저버빌리티다 — 43페타바이트의 OpenTelemetry 데이터를 저장하면서, 상용 대비 200배 낮은 비용을 달성했다고 밝힌다.

---

제8장: 실전 사례와 2026년의 의미

이미 오래전부터, 조용히

클릭하우스 옵저버빌리티는 최신 유행이 아니라 거대 기업들이 이미 몇 년째 조용히 굴려온 검증된 선택이다.

한 대규모 사례에서는 멀티리전으로 10페타바이트 이상의 텔레메트리를 600테라바이트로(약 16배 압축) 눌러 담아, 선도적 상용 SaaS 대비 약 300배 경제적이라고 보고한다.

AI 시대가 불을 지폈다

2026년 이 흐름에 기름을 부은 건 AI다. AI 워크로드는 토큰·추론·평가 로그를 천문학적으로 쏟아내고, 그걸 실시간으로 되씹어야 한다. 최전선 AI 기업들의 증언이 이 도구의 위상을 말해준다.

"돈이 불타고 있지 않다"는 Anthropic의 표현은, 제6장의 Datadog 청구서를 떠올리면 뼈가 있는 농담이다. 옵저버빌리티는 오랫동안 비용이 데이터와 함께 지수적으로 타오르는 영역이었다. 그 불을 끈 것이 이 컬럼형 엔진이다.

그래서, 2026년의 결론

이 글을 관통하는 한 줄은 이렇다. "당신의 데이터베이스 아키텍처가, 현대적 옵저버빌리티가 가능한지 아닌지를 결정한다." 미리 상상 못 한 질문에 1초 안에 답하려면(제1장), 고카디널리티 맥락을 버리지 않고 다 쥐고 있어야 하고(제2장), 그러려면 열로 눕혀 필요한 것만 읽고 꾹 눌러 담아야 한다(제3~5장). 그 요구를 정확히 충족하는 도구가, 규모가 커져도 그림이 안 변하는 클릭하우스다(제6~7장).

물론 만능은 아니다. 앞서 짚었듯 작은 규모에선 오히려 손이 더 가고, 리밸런싱은 수동이며, "그냥 카드 긁고 Datadog 쓰는" 편리함을 포기해야 한다. Duggan조차 Datadog의 상업적 성공을 인정한다("풀타임 엔지니어 한 명을 아껴준다"는 그들의 주장을 "다소 정신 나갔다"고 꼬집으면서도). 편리함을 살 것인가, 확장성과 비용을 살 것인가 — 이건 결국 팀의 규모와 성장 곡선에 달린 선택이다.

하지만 방향성은 분명하다. 데이터가 폭발하고 AI가 로그를 쏟아내는 시대에, "규모가 곧 복잡도가 되지 않는다" 는 약속은 점점 더 값지다. 2005년 스톤브레이커의 논문이 씨앗을 뿌리고, 2008년 모스크바의 한 엔지니어가 싹을 틔운 '열로 눕힌 데이터베이스'가, 2026년 옵저버빌리티 전쟁의 승기를 쥐고 있다. 로그·메트릭·트레이스는, 이제 열(column)로 흐른다.

---

📚 참고 자료

• Mat Duggan, 《ClickHouse is Winning the Observability Wars》 (matduggan.com)
• Stonebraker et al., 《C-Store: A Column-oriented DBMS》, VLDB 2005
• ClickHouse, 《ClickStack: A High-Performance OSS Observability Stack》 · 《What is observability in 2026?》
• ClickHouse Docs — Architecture overview / MergeTree / Using ClickHouse for observability
• Cloudflare Blog (2017), 《HTTP Analytics for 6M requests per second using ClickHouse》