로그·RUM을 직접 굴리기 전에 나눠야 할 결정들

관측성 비용을 줄이려다 보면 가장 먼저 저장소 가격표를 열게 됩니다.

그리고 ClickHouse의 압축률이나 오브젝트 스토리지 단가를 보고 계산을 시작합니다.

그런데 저장소를 바꾸는 일은 수집기, 대시보드, 알림, RUM SDK, 복구 절차를 한꺼번에 바꾸는 일과 같지 않습니다.

이걸 하나의 “관측성 내재화” 결정으로 묶으면 무엇이 끝났고 무엇이 남았는지 알기 어렵습니다.

그래서 네 갈래로 나눠 봅니다.

1. 수집 파이프라인을 누가 복구할 것인가

애플리케이션에서 데이터가 나오는 순간부터 저장소에 도착할 때까지가 첫 번째 결정입니다.

SDK / Agent
   → node collector
   → gateway collector
   → queue / retry
   → storage exporter
   → ClickHouse

OpenTelemetry를 쓰면 백엔드 교체가 쉬워질 수 있습니다.

하지만 exporter 주소를 바꾸는 것과 전송 내구성을 확보하는 것은 다른 문제입니다.

Collector의 기본 sending_queue가 메모리에 있다면 파드가 죽을 때 대기 중인 데이터도 사라집니다.

파일 기반 queue나 외부 버퍼를 쓰면 복구 가능성은 높아지지만 디스크와 재처리 운영이 추가됩니다.

수집 경로에는 다음 지표가 필요합니다.

• 수신 이벤트 수와 바이트
• exporter 전송 성공·실패 수
• queue 길이와 포화율
• retry 횟수와 가장 오래된 이벤트의 나이
• 파싱·필터링으로 버린 이벤트 수

저장소 알림만 있고 수집기 자체의 경보가 없으면,

대시보드가 조용해진 것이 서비스가 평온해서인지 데이터가 끊겨서인지 구분할 수 없습니다.

2. 저장 비용과 데이터 모델을 함께 바꿀 것인가

ClickHouse를 도입하는 이유를 “S3가 싸다”로 적으면 설계가 너무 빨리 닫힙니다.

ClickHouse의 MergeTree는 정렬키, part, merge, sparse index를 전제로 움직입니다.

운영자가 맡는 일도 같이 따라옵니다.

스토리지 단가만 낮춰도 이 질문은 사라지지 않습니다.

오히려 관리형이 숨기던 항목이 청구서 밖으로 나와 운영자의 일감이 됩니다.

3. 웹 RUM과 모바일 RUM을 같은 결정으로 볼 것인가

웹 세션 리플레이가 된다고 RUM 전체를 옮긴 것은 아닙니다.

@hyperdx/browser는 웹에서 세션 리플레이, 오류, Web Vitals, 네트워크와 trace 상관을 제공할 수 있습니다.

하지만 모바일 SDK와 기존 녹화의 호환은 별개입니다.

마이그레이션 전에 현재 사용량을 최소한 다음처럼 나눠야 합니다.

모바일 비중이 큰데 웹 경로만 옮기면 비용은 조금 줄고 운영 스택은 하나 더 늘어날 수 있습니다.

기존 세션 분류, frustration signal, 저장된 보고서가 새 도구에서 같은 의미를 갖는지도 확인해야 합니다.

SDK가 이벤트를 보냈다는 성공과 운영자가 같은 질문에 답할 수 있다는 성공은 다릅니다.

4. 서버 요금 옆에 누가 맡을 일을 적었는가

셀프호스팅 비용표에는 CPU, 디스크, S3가 잘 들어갑니다.

사람의 시간은 자주 0으로 남습니다.

그러면 서버 요금이 싼 구성이 항상 이깁니다.

실제로는 다음 작업이 반복됩니다.

• ClickHouse·Keeper·MongoDB 업그레이드
• 디스크 증설과 storage policy 변경
• 백업 성공 감시와 복원 리허설
• Collector 배포와 queue 장애 대응
• 스키마·TTL·materialized view 변경
• 접근통제와 secret 회전
• 장애 후 데이터 정합성 확인

이 일에 월 몇 시간을 쓸지,

장애 때 누가 호출될지,

그 사람이 이미 맡은 시스템은 무엇인지 적어야 합니다.

전담 운영자가 없는 팀에서 인프라 절감액이 몇 시간의 엔지니어 비용보다 작다면 셀프호스팅의 TCO는 쉽게 뒤집힙니다.

정확한 인원수를 보편 기준으로 정할 수는 없습니다.

하지만 시간 항목을 0으로 놓는 계산이 낙관적이라는 것은 분명합니다.

네 결정을 한 번에 하지 않는 순서

낮은 후회의 순서는 대개 수집 경계를 먼저 표준화하는 쪽입니다.

1. 현재 사용량과 소비자를 분해한다
2. SDK·Agent에서 OTel 경계를 만든다
3. 기존 백엔드와 새 백엔드에 병렬 전송한다
4. 같은 질문의 결과를 비교한다
5. 보관·복구·알림 운영을 시험한다
6. 신호 하나씩 읽기 경로를 전환한다
7. 계약과 기존 저장소를 마지막에 줄인다

병렬 전송에는 비용과 중복이 생깁니다.

그래도 되돌아갈 경로를 남긴 채 의미 차이를 찾을 수 있습니다.

한 번에 저장소와 SDK와 대시보드를 바꾸면 결과가 달라졌을 때 원인을 가르기 어렵습니다.

기능 개수보다 실제 질문으로 비교한다

“A 제품 100개 기능 중 B 제품이 70개 지원” 같은 표는 보기 좋습니다.

하지만 로그 수집 한 행과 Incident Management 제품군 한 행을 같은 무게로 셉니다.

부분 지원을 완전 지원과 함께 더하면 더 큰 문제가 생깁니다.

대신 실제 사용 질문을 테스트 케이스로 만듭니다.

이 표에서 중요한 항목 하나가 실패하면 기능 호환율 90%도 별 의미가 없습니다.

셀프호스팅이 맞는 조건

상시 부하가 있고,

데이터 위치나 보관 정책을 직접 통제해야 하며,

스토리지와 수집 파이프라인을 운영할 담당자가 있다면 검토할 이유가 생깁니다.

특정 SaaS 가격 모델이 워크로드와 맞지 않는 경우도 그렇습니다.

다만 “ClickHouse를 이미 안다”와 “관측성 제품 전체를 운영할 수 있다”는 같은 조건이 아닙니다.

UI의 상태를 담는 MongoDB,

전송을 맡는 Collector,

접근통제와 알림 채널까지 범위에 들어옵니다.

관리형이 맞는 조건

데이터가 작고 간헐적이거나,

전담 운영자가 없거나,

세밀한 RBAC·감사·온콜 제품군을 바로 써야 한다면 관리형이 더 단순할 수 있습니다.

scale-to-zero처럼 셀프호스트의 최소 고정비를 피하는 기능도 간헐 워크로드에서 큽니다.

이 판단은 “관리형이 항상 싸다”는 뜻이 아닙니다.

조직이 운영 복잡성을 제품 비용으로 사는 쪽이 맞는지 보는 것입니다.

홈랩과 PoC에서 확인할 수 있는 범위

작은 환경은 데이터 흐름을 배우기에 좋습니다.

브라우저 → Collector → ClickHouse → HyperDX UI가 이어지는지,

MongoDB를 복원했을 때 설정이 돌아오는지,

TTL과 source mapping이 실제로 어떻게 생겼는지 확인할 수 있습니다.

하지만 단일 노드의 성공으로 HA와 기업 규모 TCO를 증명할 수는 없습니다.

작은 트래픽에서 queue가 비지 않았다는 결과도 장애 중 유실률의 상한이 아닙니다.

PoC의 목적을 “설치 성공”이 아니라 “다음 단계로 넘어갈 조건 확인”으로 잡는 편이 낫습니다.

판단을 바꿀 조건을 먼저 쓴다

결정을 오래 유지하려면 채택 이유보다 재검토 조건이 더 쓸모 있습니다.

예를 들면 다음과 같습니다.

• 웹과 모바일 사용 비중이 바뀐다
• 보관 기간이 늘어 hot/cold 비용 차이가 커진다
• 복원 리허설이 목표 시간을 넘는다
• 접근통제 요구가 OSS 범위를 벗어난다
• 운영 시간의 실제값이 예상보다 커진다
• 새 릴리스가 막혀 있던 기능을 제공한다

제품은 계속 바뀝니다.

2026-09 기준 ClickStack은 Helm v2.x , Managed 전용 RBAC , Terraform provider v3.25 Beta  같은 변화가 이미 있었습니다.

따라서 조사 날짜가 없는 기능표는 빠르게 오래된 문서가 됩니다.

결론 : 관측성 셀프호스팅은 저장소 선택이 아니라 수집·저장·RUM·운영 책임 네 가지를 따로 통과시키는 일입니다.

확인 시점: 2026-09-15.