Observability,Whitepaper,미분류

상용 SaaS 과금은 호스트 수 기본요금에 커스텀 메트릭과 로그 수집량이 얹혀, 규모가 커질수록 청구액이 비선형으로 증가합니다. 데이터가 벤더 폐쇄 포맷에 쌓이면 벤더 락인(vendor lock-in, 공급사 제품에 묶여 교체 비용이 커지는 상태)도 따라옵니다. 그렇다고 오픈소스만으로 꾸리면 신호마다 도구가 갈립니다. 메트릭은 Prometheus, 로그는 Elasticsearch 기반 스택, 트레이스는 Jaeger로 나뉘어 따로 운영해야 합니다. 인프라팀은 상용의 비용 곡선과 오픈소스의 파편화 중 어느 부담이 큰지부터 점검해야 합니다.

핵심은 단순합니다. 메트릭·트레이스·로그를 단일 애플리케이션에서 다루고, 셀프호스트(self-host, 자체 인프라에 직접 운영)로 데이터를 직접 소유합니다. 두 결정이 이를 떠받칩니다. 첫째, 계측은 OpenTelemetry에 맡깁니다. OpenTelemetry(OTel, 벤더 중립 관측 데이터 수집 표준)는 CNCF가 호스팅하는 프로젝트이며, 이 도구는 전송 규격 OTLP를 직접 수집합니다. 단, CNCF 프로젝트는 OpenTelemetry이고 제품은 그 위에서 동작하는 독립 제품입니다. 둘째, 세 신호를 ClickHouse 단일 컬럼형 데이터베이스에 통합 저장해 한 화면에서 봅니다.

종속을 푸는 자리는 제품이 아니라 표준입니다. 상용 APM은 자사 에이전트로 계측을 안내해 백엔드 교체 시 재계측이 필요하지만, 표준 계측은 보낼 대상만 바꾸면 됩니다.

exporters:
  otlp/signoz:
    endpoint: "signoz-otel-collector:4317"
service:
  pipelines:
    traces:
      exporters: [otlp/signoz]

평가에 앞서 계측을 표준으로 옮길 수 있는지 점검합니다.

커뮤니티 에디션은 셀프호스트 기준 라이선스가 0달러이고 데이터가 자사 인프라에 머뭅니다. 다만 “비용 0″은 라이선스에 한정됩니다. 그 자리에는 설치·업그레이드·백업·장애 대응이라는 운영 부담이 남습니다. 과금은 호스트나 좌석이 아니라 수집량에만 붙고 사용자는 무제한입니다. 그래서 라이선스 금액만 보지 말고, 인프라비와 운영 인력 시간을 더한 총소유비용(TCO)으로 추정해야 합니다.

실질적 강점은 단계적 채택입니다. 핵심 기능이 커뮤니티에 모두 있으므로, 0원으로 검증한 뒤 거버넌스 요건이 나타날 때만 상용으로 넘어가면 됩니다. 전환 신호는 SAML·OIDC 기반 SSO, 역할 단위 세분화 RBAC, 계약으로 보장된 응답 시간이 필요해지는 순간입니다. 검증은 작게 시작합니다. ClickHouse가 단일 노드부터 동작하므로 서버 한 대로 핵심 서비스를 OpenTelemetry로 계측하고 성공 지표를 숫자로 정합니다.

강점은 표준 준수와 과금의 단순함입니다. OpenTelemetry를 기본 경로로 두어 계측 자산이 특정 제품에 묶이지 않고, 세 신호를 단일 ClickHouse에 통합해 장애 대응 동선을 줄이며, 수집량 한 축으로만 과금해 비용을 예측하기 쉽습니다. 동적 마이크로서비스 비중이 높고 데이터를 자체 인프라에 두려는 요건이 있으며 운영 인력을 갖춘 조직이라면 강력한 선택지입니다. 반대로 메트릭 중심이거나 벤더 지원을 그대로 누리려는 조직이라면 매니지드 클라우드가 맞습니다. 어느 쪽이든 무료 검증으로 운영 부담을 확인한 뒤 결정하면 됩니다.

SigNoz는 CNCF 프로젝트인가요?

아니요. CNCF가 호스팅하는 것은 OpenTelemetry이고, 이 제품은 그 표준 위에서 동작하는 독립 제품입니다. 표준을 기본 경로로 채택해 생태계와 가깝지만 CNCF 호스팅 프로젝트는 아닙니다.

Datadog보다 정말 비용이 줄어드나요?

조건이 있습니다. 라이선스는 셀프호스트 시 0이지만 인프라비와 운영 인력 시간이 새로 듭니다. 구독료만 견주면 반쪽짜리 비교이며, 운영비까지 포함한 총소유비용으로 따져야 합니다.

Prometheus와 ELK를 이미 쓰는데 바꿔야 하나요?

반드시 바꿀 필요는 없습니다. Prometheus는 메트릭, Elasticsearch 기반 스택은 로그에 강점이 있습니다. 장애가 여러 신호에 걸쳐 나타나는 일이 잦다면 통합 백엔드가 유리하고, 한 신호만 본다면 전용 도구가 단순합니다.

• 옵저버빌리티(Observability) — 외부 출력만으로 시스템 내부 상태를 추론하는 힘입니다.
• OpenTelemetry(OTel) — 관측 데이터를 벤더에 묶이지 않게 수집하는 CNCF 오픈 표준입니다.
• OTLP(OpenTelemetry Protocol) — OpenTelemetry 데이터를 실어 나르는 전송 프로토콜입니다.
• ClickHouse — 데이터를 열 단위로 저장해 집계에 강한 컬럼형 데이터베이스입니다.

• SigNoz GitHub repo 방문: https://github.com/SigNoz/signoz
• CNCF Slack 참여: https://slack.cncf.io/
• CNCF Landscape 확인: https://landscape.cncf.io/