2026년 옵저버빌리티(observability) 담론은 한 문장으로 정리됩니다. “모든 것은 로그다.” GeekNews 토픽 페이지에서 화제가 된 “모든 것은 로그다” 논의는 로그·메트릭·트레이스를 별도 시스템에 보관하는 “세 기둥(three pillars)” 모델이 더 이상 비용·성능 양면에서 지속 가능하지 않다는 진단을 깔고 있습니다.
본 가이드는 한국 IT 백엔드·플랫폼 팀이 마주하는 옵저버빌리티 비용 폭증과 디버깅 지연을 배경으로, 2026년 1월 ClickHouse가 발표한 “What is observability in 2026?” 글의 진단을 기준점으로 “옵저버빌리티 2.0” 흐름을 정리합니다.
1. 세 기둥 모델이 깨진 이유
전통적인 옵저버빌리티는 메트릭은 Prometheus, 로그는 ELK(Elastic·Logstash·Kibana), 트레이스는 Jaeger처럼 데이터 종류별로 특화된 백엔드에 따로 저장합니다. ClickHouse 엔지니어링 리소스 허브에 게재된 Aditya Somani의 2026년 1월 7일자 분석에 따르면, 이 구조는 장애 대응 흐름을 “Grafana에서 알림을 받고 Kibana로 로그를 찾고 Jaeger에서 트레이스를 잇는” 다단계 컨텍스트 스위치로 만듭니다.
같은 자료 기준으로 데이터 중복 문제도 큽니다. trace_id나 customer_id 같은 공통 식별자가 세 저장소에 같이 저장되면서 스토리지 비용이 늘고, 세 개의 stateful 시스템을 각각 운영해야 하므로 운영 부담도 누적됩니다.
2. “모든 것은 로그다”가 의미하는 것
옵저버빌리티 2.0의 핵심은 메트릭·트레이스·이벤트를 모두 구조화된 “wide event”로 보고 한 곳에 적재하는 발상입니다. GeekNews 토픽 페이지 제목인 “모든 것은 로그다”는 이 흐름을 압축한 표현입니다.
구체적으로는 OpenTelemetry 같은 표준 수집 계층으로 텔레메트리를 한 번 모으고, 컬럼나 분석 DB에 raw event 그대로 적재한 뒤, SQL로 모든 신호를 함께 질의하는 방식입니다. ClickHouse 글의 “Modern unified analytics model” 비교표는 이 구조가 사전 정의 대시보드 중심의 모니터링이 아니라 “unknown-unknowns”를 탐색하는 ad-hoc 쿼리 모델로 바뀐다는 점을 강조합니다.
3. 카디널리티가 분석을 결정한다
3-1. 시계열 DB의 라벨 폭발
Prometheus는 “metric name + label set” 조합마다 별도 시계열을 만듭니다. ClickHouse 분석 기준, Kubernetes 클러스터에서 컨테이너별·사용자 세션별로 라벨을 붙이면 “combinatorial explosion”이 발생해 메모리 압박과 인스턴스 불안정으로 이어집니다.
이 상황을 회피하려고 user_id·trace_id 같은 식별자를 제거하면, 정작 장애 조사 시점에 “누구에게 문제가 발생했는가”라는 질문에 답할 수 없게 됩니다.
3-2. 검색 엔진의 분석 한계
Elasticsearch는 inverted index 기반으로 전문 검색에는 강하지만, GROUP BY나 COUNT DISTINCT 같은 집계는 doc values를 거쳐야 하므로 JVM heap에 부담이 누적됩니다. ClickHouse 자료에 인용된 사례로, 디디(Didi)는 같은 한계를 이유로 로그 플랫폼을 Elasticsearch에서 ClickHouse로 이전했다고 소개됩니다.
4. 컬럼나 분석 DB로 통합하는 흐름
옵저버빌리티 2.0의 백엔드 후보로 가장 많이 거론되는 구조는 컬럼나 분석 DB입니다. ClickHouse 자체 자료 기준으로 컬럼별 동일 자료형 압축 덕분에 평균 압축률 15~20배 수준을 보고하고 있으며, 100% raw 데이터를 보관하면서도 비용을 통제할 수 있다는 주장이 핵심 셀링 포인트입니다.
실제 채택 사례도 같은 글에서 정리됩니다. OpenAI는 옵저버빌리티 플랫폼을 ClickHouse 기반으로 재구축했고, Anthropic은 같은 자료 인용 기준 “queries are lightning-fast, and money is not on fire as much”라고 표현했습니다. Tesla는 메트릭 플랫폼 백엔드로 ClickHouse를 채택했다는 사실이 같은 자료에 언급됩니다.
대규모 trace 검색 사례로는 Shopee가 같은 ClickHouse 글에서 인용되는데, 약 300억 행 규모 데이터셋에서도 특정 trace_id를 초 단위로 조회할 수 있다고 소개됩니다.
5. 도입 전 점검 사항
5-1. 마이그레이션 경로
ClickHouse 가이드 기준으로 ELK·Prometheus·Jaeger 동시 이전이 권장되지 않습니다. 통상 OpenTelemetry collector로 트레이스부터 라우팅하고, 쿼리 패턴 검증 후 로그·메트릭을 단계적으로 이전하는 3~6개월 일정이 현실적입니다.
5-2. 운영 복잡도
같은 가이드는 컬럼나 DB가 partition key, ordering key, materialized view 튜닝과 샤딩·복제 전략 운영을 요구한다고 명시합니다. UI 중심 SaaS 옵저버빌리티에 익숙한 팀이라면 별도 DBA 또는 데이터 플랫폼 인력 배치를 함께 검토해야 합니다.
5-3. SQL 학습 부담
PromQL이나 Lucene 쿼리에 익숙한 엔지니어는 SQL 표현식 재학습이 필요합니다. ClickHouse가 ClickStack의 일부로 제공하는 HyperDX 같은 시각화 계층은 Lucene 유사 문법을 SQL로 변환해 학습 곡선을 완화하는 옵션으로 소개됩니다.
6. 언제 도입하고, 언제 미루어야 하는가
- 일 텔레메트리 100GB 미만이고 알람 중심 운영이라면 Datadog 등 매니지드 SaaS가 빠른 시간 대비 효과를 제공할 수 있습니다(ClickHouse 글의 trade-off 섹션 기준).
- 장애 시 “누구·언제·어디서” 같은 raw 식별자 질의가 자주 필요하고, 비용 압박이 큰 단계라면 unified analytics 모델 도입 타당성이 높아집니다.
- 전문 검색만 필요한 경우에는 inverted index 시스템이 여전히 효율적이라는 점이 같은 자료에 명시되어 있습니다.
- 도입을 결정하기 전에 OpenTelemetry collector를 먼저 표준화하면, 백엔드 전환 시 코드 변경 범위를 최소화할 수 있습니다.
7. 관련 글
옵저버빌리티 2.0 흐름을 따라가다 보면 코드 자체의 추상화 비용, 운영 도구 전환, 외부 위협 대응 같은 다른 시니어 토픽과도 자연스럽게 이어집니다.
- 대규모 리팩토링 의사결정 맥락은 잘못된 추상화는 중복보다 비싸다 — Sandi Metz 클래식이 2026년 다시 회자되는 이유에서 함께 확인할 수 있습니다.
- 운영 도구 라이프사이클 변화를 추적한 사례로 Gemini CLI 종료 D-1: Antigravity CLI 전환 체크리스트를 참고할 수 있습니다.
- 플랫폼 신뢰성과 직결되는 공급망 보안 관점은 LinkedIn 가짜 채용으로 위장한 npm 백도어 — 한국 개발자 방어 가이드를 함께 살펴보세요.
📌 함께 보시면 좋은 글
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요