HyperDX / ClickStack 심층 분석 — RUM/플랫폼 도입 실사

HyperDX/ClickStack을 “Datadog RUM 대체 + 통합 관측성 플랫폼” 후보로 도입할 때의 실사(due-diligence) 페이지입니다. “로그 스토어 선택지로서의 요약 판단"은 로깅 챕터의 HyperDX / ClickStack가 이미 다루므로 강점·약점은 다시 늘어놓지 않습니다. 이 페이지는 도입 결정에 필요한 팩트 — 연혁·아키텍처·배포 모드·기능 성숙도·라이선스·거버넌스 갭 — 을 플랫폼 실사 관점에서 심화합니다.

한 줄 결론: 웹 RUM 대체 후보로는 현실적으로 유일하지만 OSS의 접근통제 공백(SSO/RBAC/멀티테넌시/감사로그 전무)이 다중 팀 도입의 결정적 게이트입니다.

연혁 — DeploySentinel에서 ClickStack까지

리브랜드가 아니라 번들 재구성입니다. 실사에서는 이 차이가 중요합니다. HN에서 “HyperDX가 어디서 끝나고 ClickStack이 어디서 시작되는지” 혼란이 반복됐는데 팀의 공식 정의는 ClickStack = { HyperDX(UI/API), ClickHouse, OTel Collector }입니다. HyperDX는 폐기되지 않았고 ClickStack의 프론트엔드 컴포넌트로 편입됐습니다.

실사 주의: “Anthropic·character.AI가 ClickStack 프로덕션 레퍼런스"라는 프레이밍은 1차 출처로 뒷받침되지 않습니다. 두 팀은 고볼륨·고카디널리티 UI 동작에 피드백과 입력을 줬을 뿐입니다. ClickHouse 공식 블로그상 Anthropic은 HyperDX UI가 아니라 자체 air-gapped ClickHouse 관측성 스택(k8s + ClickHouse Operator + Prometheus + Vector)을 운영합니다 ✓. 패키지드 ClickStack 자체의 대규모 named 프로덕션 사례는 제품이 ~1년 되어 아직 얇습니다 ≈.

아키텍처 — 3 코어 + 1 필수 메타스토어

3개 코어 컴포넌트에 메타데이터 저장용 MongoDB가 필수 의존성으로 붙습니다. 이 조합이 스택의 운영 표면을 규정합니다. 관측성 데이터는 전부 ClickHouse에 들어가지만 대시보드·저장검색·사용자·알림 같은 앱 상태는 MongoDB에 남습니다 — 이 이원화가 HyperDX Only 모드에서도 사라지지 않습니다. MongoDB의 역할·부하 프로파일(관측 데이터 적재량이 아니라 사용자·설정 수에 비례)·배포 경로별 운영 형태는 HyperDX의 MongoDB에서 심화합니다.

• 인제스천은 OTLP(4317 gRPC / 4318 HTTP), 컬렉터 동적 구성은 OpAMP로 표준 프로토콜을 씁니다 ✓. 커스텀 컬렉터 config는 CUSTOM_OTELCOL_CONFIG_FILE로 베이스 config에 병합되며 기존 컴포넌트 오버라이드는 불가(신규 receiver/processor만 추가) ✓.
• MongoDB를 FerretDB(Postgres 기반 호환)로 대체한 커뮤니티 사례가 있으나 공식 지원은 아닙니다 ≈.

신호별 테이블 스키마 — RUM 상관의 근거

ClickStack은 신호별 최적화 스키마를 자동 생성합니다(codecs·TTL·secondary index 포함). 기본 속성 저장 타입은 Map(LowCardinality(String), String)이고 native JSON은 beta로 기본값 아닙니다 ✓. RUM 실사 관점에서 보면 세션↔트레이스 상관이 스키마에 하드코딩돼 있습니다.

otel_traces의 세션↔트레이스 조인에는 bloom filter가 붙습니다(TraceId bloom FP율 0.001, Duration minmax). otel_metrics_*는 gauge/sum/histogram/exp-hist/summary 타입별로 테이블이 나뉩니다. hyperdx_sessions는 Body=이벤트 페이로드, LogAttributes=메타데이터 맵으로 otel_logs와 동일한 컬럼 구조를 쓰고 bloom_filter 인덱스도 갖습니다 ✓.

hyperdx_sessions에는 “세션 7일/로그 14일"처럼 신호별로 다른 기본 TTL이 있다는 통념이 있으나 근거가 없습니다. ClickStack 배포 기본은 전 테이블 균일 TABLES_TTL(3일, 아래 §프로덕션 노브)이며 신호별 차등은 직접 설정하는 값입니다(상세: HyperDX 배포 §티어링) ✓.

쿼리 계층은 Lucene 스타일 검색(level:err)과 네이티브 ClickHouse SQL을 함께 지원합니다. timestamp 컬럼만 있으면 임의 스키마도 검색·상관·시각화됩니다(schema-agnostic) ✓. 이 유연성 덕분에 HyperDX Only 모드가 성립합니다.

배포 6모드 — 프로덕션 적합성 매트릭스

공식 문서가 6가지 옵션과 프로덕션 적합성을 명시합니다 ✓. 실사 관점에서 프로덕션에 올릴 수 있는 건 Managed 또는 Helm 둘 중 하나입니다. 자체 인프라 전략을 지키려면 HyperDX Only가 사실상의 정답 축입니다.

Helm 경로의 operator 함정: 활성 개발이 ClickHouse/ClickStack-helm-charts로 이관됐고 K8s 설치는 2개 차트(clickstack-operators 먼저 → clickstack 순서)로 나뉩니다 ✓⁽3-0⁾. 첫 차트가 ClickHouse Inc.의 신규 공식 operator(ClickHouseCluster/KeeperCluster CRD)와 MongoDB Community Operator(MongoDBCommunity CRD)를 설치해 ClickHouse·MongoDB를 모두 CRD로 관리합니다. plain StatefulSet이 아닙니다 ✓. Altinity operator(ClickHouseInstallation/CHI)가 아닙니다 ✓.

범용 분석 CH를 Altinity로 운영한다면 한 클러스터에 operator 2종이 공존합니다. 표준 Helm 경로를 그대로 따를지 vs 별도 operator 위에 CH를 세우고 HyperDX Only로 붙일지가 결정 사항입니다. 상세는 ClickHouse operator 참조.

HyperDX Only — 조건 정리

자체 인프라(EKS + 자체 ClickHouse)를 지키면서 HyperDX UI만 올리는 유일한 경로입니다. 그렇다고 “가볍다"고 오해하면 안 됩니다.

• MongoDB는 여전히 필수 — 대시보드·저장검색·사용자·알림을 저장합니다. CH만 자체 운영한다고 메타스토어가 사라지지 않습니다 ✓.
• 인제스천은 전적으로 사용자 책임 — 자체 OTel Collector, 클라이언트 직접 인입, ClickHouse Kafka/S3 테이블 엔진, ETL, ClickPipes 중 선택 ✓.
• 임의 스키마 허용(timestamp만 있으면) → 범용 분석용 ClickHouse에 관측성을 겸용하려는 니즈와 맞습니다 ✓.
• 기동은 docker run -e MONGO_URI=... docker.hyperdx.io/hyperdx/hyperdx 후 UI(8080)에서 외부 CH data source 등록 ✓.
• 프로덕션 노브: 기본 데이터 TTL은 3일(TABLES_TTL=72h)로 짧아 프로덕션에서는 대개 늘려야 합니다. ClickHouse 사이징 가이드는 인제스트 워크로드 10 MB/s당 1 vCPU, 쿼리 워크로드 1 QPS당 + 10 MB/s당 1 vCPU를 권장합니다(예: 100 MB/s 인제스트+쿼리 → 약 40 vCPU) Ⓥ.

기능 성숙도 매트릭스

범례: 🟢 성숙/핵심강점 · 🟡 사용 가능/개선중 · 🟠 초기/beta · 🔴 미지원/로드맵

세션 리플레이는 replay→trace→log 조인까지 되는데 대부분의 OSS 경쟁자가 못 따라오는 시그니처 강점입니다 ✓. 알림은 Search/Chart 조건, 그룹별 평가와 발화, 평가 이력, SQL로 작성하는 사용자 정의 통계 조건을 지원합니다. 다만 이 SQL 조건을 내장 ML 이상탐지로 보거나 Alertmanager식 grouping/inhibition/silencing과 동등하다고 볼 수는 없습니다(ClickStack 알림 공식 문서). Terraform Provider는 self-hosted와 ClickHouse Cloud 양쪽에서 대시보드·차트·검색·알림 등을 관리하지만 Terraform provider ClickHouse/clickhouse v3.25 이상에서 Beta입니다(공식 발표). OSS 알림 채널은 Slack/Generic Webhook 위주입니다(Slack API·PagerDuty OAuth는 Cloud 전용) ✓.

PromQL도 더 이상 단순한 “없음”은 아닙니다. 2026-06 기준으로 ClickHouse TimeSeries Engine에 저장한 메트릭을 직접 조회하는 경로와 외부 Prometheus 호환 서버로 프록시하는 경로가 실험적으로 추가됐습니다. 외부 서버 경로는 NEXT_PUBLIC_ENABLE_PROMQL=true로 켜야 하며 기본값은 꺼짐입니다. 기존 otel_metrics_* 테이블이 자동으로 PromQL 저장소가 되는 것은 아니므로, 현재 운영 판단에서는 여전히 SQL/Lucene 또는 별도 VictoriaMetrics 경로가 안전합니다(ClickStack 2026-06 공식 변경사항). Service Maps는 2025-11 beta, Event Deltas는 2025-10부터 구성 가능합니다 ✓.

RUM 실사의 결론입니다. (1) 웹 세션 리플레이·프론트↔백엔드 상관은 즉시 대체 가능한 🟢입니다. 모바일 리플레이는 존재하지 않는 🔴라 착수 전 Datadog RUM usage를 웹/모바일로 분해해야 합니다. (2) 대체는 프록시 매핑이 아니라 @hyperdx/browser SDK 교체로 갑니다 — datadogreceiver는 브라우저 RUM intake를 아예 수신하지 않습니다. 두 논점의 상세는 Datadog RUM 커버리지·dd 프록시 매핑 참조.

라이선스와 커뮤니티

핵심 UI가 MIT여서 SigNoz(요소 제약)·Grafana(AGPL)·BSL/SSPL 계열보다 관대합니다. 단 오픈코어 모델이라 접근통제 기능(SSO/SAML/RBAC/멀티테넌시)은 OSS에서 빠집니다.

메인 hyperdxio/hyperdx 레포의 MIT는 LICENSE 파일로 확인되나 ✓, ClickHouse/ClickStack-helm-charts 레포 자체의 라이선스 파일은 이번 조사에서도 명시 확인되지 않았습니다.

커뮤니티: hyperdxio/hyperdx는 ~9.7k stars·188 릴리스(월 다수 릴리스의 빠른 케이던스), 활성 Discord ✓. ClickHouse Inc.의 전담 Head of Observability 조직이 뒤를 받치면서 abandonware 리스크가 인수 전보다 낮아졌습니다 ≈. 부모 레포 ClickHouse/ClickStack은 아티팩트 저장소 성격으로 릴리스 없습니다 ✓.

OSS의 결정적 갭 — 접근통제 공백

이 페이지에서 가장 무거운 실사 항목입니다. OSS 자체 호스팅 HyperDX는 “인스턴스 = 하나의 평평한 팀, 전원 동일 권한” 모델입니다. 초대는 되지만 팀 A가 팀 B의 대시보드/데이터를 못 보게 하는 앱 내 장치가 전무합니다. Viewer/Editor/Admin과 폴더 권한을 기본으로 주는 Grafana OSS보다도 약합니다 ✓.

• RBAC는 이미 GA됐으나 OSS로 오지 않았습니다. 2026-04-01 RBAC 공지는 Managed ClickStack(ClickHouse Cloud) 전용이고 사용자 관리도 ClickHouse Cloud 조직 레벨에서 이뤄집니다. OSS RBAC 요청 이슈 #1293은 not planned로 CLOSED ✓. → RBAC에 관한 한 “로드맵 GA를 기다린다"는 전략은 로드맵에 없는 것을 기다립니다.
• 감사로그는 아직 미출시이나 RBAC 선례를 보면 Cloud 전용으로 착지할 가능성이 높습니다 ≈.

완화 경로 — 앱 밖에서 접근통제 조립

OSS를 고수하려면 세 기법을 조합해야 합니다. AuthN(인증)은 상당 부분 흉내 낼 수 있으나 AuthZ(인가)는 앱 밖에서 매우 제한적이라는 비대칭이 있습니다.

oauth2-proxy는 HyperDX 자체 로그인을 못 꺼 이중 로그인이 생기고 trusted-header 자동 로그인도 미지원이라 인스턴스 내부 격리는 전혀 못 합니다 ✓/≈. 팀별 인스턴스는 관리 상한을 넘으면 인스턴스 스프롤로 Managed가 TCO상 유리해집니다 ✓/≈. row policy는 DB 레벨 격리일 뿐 대시보드·알림 같은 앱 상태(MongoDB)엔 닿지 않습니다 ✓. 규제 팀을 Managed ClickStack으로 옮기면 RBAC·SSO/SAML/SCIM·(향후) 감사로그가 turnkey로 따라오지만 Cloud 인프라 전용이라 self-host는 포기해야 합니다 ✓.

이 접근통제 갭 자체의 의사결정 프레임과 조직 규모별 매트릭스는 Datadog 대체 매트릭스·마이그레이션 로드맵에서 이어집니다.

우리 케이스에서는

전제 차이를 먼저 정리합니다. 로깅 챕터는 로그 내재화 단독 관점이라 로그는 VictoriaLogs로 가고 통합 저장소(D4)는 “earn it last”, ClickStack은 채택하지 않는다고 결론냈습니다 — CH+MongoDB 운영 표면이 이번 로그 규모에는 과하기 때문입니다.

이 조사는 거기에 전제를 더합니다: (1) 목표가 Datadog RUM 대체이고 웹 RUM은 HyperDX가 사실상 유일한 현실 경로, (2) 관측성 밖 범용 분석용 ClickHouse를 어차피 운영, (3) 운영 인력을 보유. 이 세 전제가 붙으면 self-hosted CH의 “earn it” 조건이 로그 단독으로 볼 때보다 앞당겨집니다.

두 챕터는 양립합니다. 로그는 여전히 VictoriaLogs에 두고(CH로 옮기라는 게 아님), 모바일 RUM은 Datadog에 잔류시킵니다. 조사 [권고]는 이 전제 위에서:

• RUM은 SDK 교체(@hyperdx/browser)로 갑니다. 프록시 매핑은 쓰지 않습니다. 웹 세션 리플레이·CWV·프론트↔백엔드 상관을 dual-instrument로 병행 검증한 뒤 컷오버합니다. RUM 대체는 대규모 프로덕션 레퍼런스가 아직 얇아 PoC 성공을 진입 게이트로 삼습니다 ≈.
• ClickHouse는 HyperDX Only로 붙입니다. ClickStack 내장 CH를 켜지 말고 자체 운영 CH(범용 분석 겸용)에 연결해 operator를 일원화합니다. CH 배포·operator 판단은 ClickHouse 심층에서 다룹니다.
• 메트릭은 HyperDX로 몰지 않습니다. PromQL이 실험 기능이고 일반 otel_metrics_*에 자동 적용되지 않으며 대시보드/알림도 기존 Prometheus 운영 모델과 동등하지 않기 때문에, 메트릭 계층은 VictoriaMetrics + Grafana로 분리 존치합니다 ✓.
• 최대 리스크는 OSS 접근통제 공백입니다. 다중 팀 광범위 롤아웃을 단일 OSS 인스턴스로 하면 Datadog 대비 거버넌스가 후퇴합니다 → 파일럿은 oauth2-proxy 경계 SSO, 중간 롤아웃은 팀별 인스턴스 + row policy, 규제/감사 필수 팀만 Managed로 분리하는 단계적 하이브리드로 완화합니다.

본문은 2026-07 조사이며, 2026-09 재검증에서 달라진 기능은 위에 갱신했습니다. 이후 확인된 변경점은 HyperDX 커버리지 재판정(2026-09)에서 다룹니다.