HyperDX 알아보기 — 로그에서 트레이스까지 이어서 보기

사용자가 결제 버튼을 눌렀는데 화면이 멈췄다고 한다.

브라우저 에러를 찾고, 같은 시간대의 API 로그를 보고, 느린 외부 호출을 찾으러 트레이스를 연다.

각 데이터가 있어도 도구 사이에서 시간과 요청 ID를 계속 맞춰야 한다면 조사에 시간이 걸린다.

HyperDX는 로그, 메트릭, 트레이스, 세션 리플레이를 연결해 탐색하는 관측성 UI다.

ClickStack은 HyperDX에 ClickHouse와 OpenTelemetry 수집 경로 등을 결합한 관측성 스택이다. ClickStack 소개 

ClickHouse가 분석할 데이터를 저장하고 계산한다면, HyperDX는 사람이 그 데이터를 따라가며 원인을 찾는 화면을 맡는다.

네 가지 구성요소부터 보기

여기서는 직접 설치하는 오픈소스 구성을 기준으로 본다.

MongoDB가 함께 있다는 점이 처음에는 조금 의외일 수 있다.

로그를 ClickHouse에 저장하더라도, 어떤 테이블을 어떤 소스로 보여줄지와 사용자가 만든 대시보드를 보관할 곳은 필요하다.

그래서 ClickHouse의 데이터만 복구해서는 원래의 사용 환경이 전부 돌아오지 않는다. ClickStack 아키텍처 

검색 결과에서 요청 하나를 따라가기

앞의 결제 실패를 조사한다고 해보자.

먼저 서비스와 시간 범위를 좁혀 에러 로그를 찾는다.

로그에 trace_id가 기록돼 있다면 같은 요청의 트레이스로 이동해, 어떤 호출에 시간이 걸렸는지 볼 수 있다.

브라우저 세션까지 계측했다면 사용자가 어느 화면에서 어떤 동작을 했는지도 함께 살펴볼 수 있다. 세션 리플레이 

이 연결의 바탕은 데이터에 담긴 식별자다.

화면에 로그와 트레이스가 모두 있다는 것만으로 두 데이터가 자동으로 연결되지는 않는다.

애플리케이션이 trace context를 다음 서비스에 전달해야 하고, 로그에도 같은 요청을 가리키는 식별자가 있어야 한다.

브라우저 세션 리플레이 역시 별도 SDK 계측이 필요하다. 브라우저 계측 

도입 검증에서는 데이터가 몇 건 들어왔는지와 함께, 테스트 요청 하나를 브라우저에서 백엔드까지 실제로 따라갈 수 있는지 보는 것이 좋다.

기존 ClickHouse에도 붙일 수 있을까

HyperDX는 기존 ClickHouse 데이터와 연결해 사용할 수 있다.

다만 테이블이 존재하는 것과 UI가 그 데이터를 이해하는 것은 다른 단계다.

로그라면 시간과 메시지를 어느 컬럼에서 읽을지, 트레이스라면 trace ID와 span ID를 어디에서 찾을지 소스 설정을 맞춰야 한다. ClickHouse 데이터 소스 연결 

처음 도입할 때 기본 수집 경로와 스키마를 사용하면 이 연결을 확인하기가 수월하다.

이미 운영 중인 데이터에 붙일 때는 기존 스키마를 보존하면서 필요한 필드와 타입이 맞는지부터 확인한다.

어떤 기대를 가지고 도입하면 좋을까

HyperDX의 매력은 관측 데이터를 ClickHouse에 두고, 그 위에 조사 화면을 붙일 수 있다는 점이다.

SQL로 데이터를 직접 살펴볼 여지도 있고, 데이터 보관 위치와 기간을 직접 정할 수 있다.

그만큼 운영할 구성요소도 생긴다.

수집이 밀리면 Collector를, 조회가 느리면 ClickHouse를, 화면 설정이 사라지면 MongoDB와 앱 상태를 봐야 한다.

기존 관측성 제품을 옮기는 경우에는 수신 가능한 데이터 형식뿐 아니라 알림, 대시보드, 사용자 권한까지 별도로 확인해야 한다.

예를 들어 2026-09-15 공식 문서의 세밀한 RBAC는 Managed ClickStack 전용으로 안내돼 있다.

로그인용 프록시를 앞에 두는 것만으로 self-hosted HyperDX 내부의 리소스별 권한이 같은 수준으로 생기지는 않는다. ClickStack RBAC 

처음부터 모든 관측 데이터를 옮기기보다, 서비스 하나의 로그와 트레이스로 조사 흐름을 확인하면 판단할 근거가 생긴다.

그 흐름이 도움이 된다면 다음에는 얼마나 오래 보관하고, 장애 때 어디까지 유지할지를 정하면 된다.

다음 글에서는 그 기준으로 셀프호스팅 구성을 잡아본다.