OSS 모니터링 스택 2026 깊이 분석 — SigNoz·Coroot·OpenObserve·Sentry·Grafana·Uptrace로 Datadog을 갈아끼우는 법

프롤로그 — Datadog 청구서, 그리고 그 후

2025년 한 시리즈 B 스타트업의 분기 회의록 한 줄. "지난달 Datadog 청구서가 14만 달러였습니다." CTO가 노트북 화면을 돌리자 모두가 침묵했다. 매출의 7%였다. 인덱스된 로그가 절반, 커스텀 메트릭이 30%, APM 호스트가 나머지였다. 다음 분기 안에 90% 줄이는 게 OKR이 됐다.

이런 장면은 2024년부터 시리즈 B 이상 SaaS 회사에서 분기별로 반복되고 있다. 한쪽엔 Datadog·New Relic·Splunk의 SaaS 매트릭스가 있고, 다른 쪽엔 OpenTelemetry 표준화로 진입 장벽이 무너진 OSS 옵저버빌리티가 있다. 2026년의 답은 더 이상 "둘 중 하나 골라라"가 아니다. 모듈식 OSS 스택으로 핵심을 가져오고, 정말 가치가 큰 곳에만 SaaS를 남긴다.

이 글은 2026년 5월 기준 OSS 모니터링 풍경의 정직한 지도다.

SigNoz — OpenTelemetry 네이티브, ClickHouse 저장, 트레이스·메트릭·로그·예외 통합. Datadog의 진짜 대안이라 부를 만한 첫 OSS.
Coroot — eBPF 기반 무계측 APM. 코드 한 줄 안 고치고 서비스 토폴로지와 SLO 대시보드가 나온다.
OpenObserve — Rust로 짠 차세대 로그·트레이스·메트릭. S3+Parquet 백엔드로 페타바이트 규모를 5%~30% 비용으로 돌린다.
Sentry self-hosted — 에러 추적의 캐논. Sentry SaaS의 가격이 부담스러우면 여전히 첫 번째 답이다.
Uptrace — 라이트웨이트 ClickHouse 기반 APM. 단일 노드에서 OpenTelemetry 시작하기 좋은 선택지.
Grafana 스택 — Loki·Tempo·Mimir·Pyroscope·k6·Beyla. 여전히 가장 큰 OSS 옵저버빌리티 에코.

각 도구가 어디서 빛나는지, 저장소 백엔드가 왜 결정적인지, OpenTelemetry 표준화가 무엇을 영구히 바꿨는지, 그리고 셀프호스트의 진짜 비용까지 — 환상 없이 본다.

1장 · OpenTelemetry — 모든 것을 바꾼 표준

OSS 옵저버빌리티가 2026년에 진짜로 위협이 된 단 하나의 이유는 OpenTelemetry(OTel)다. 그전엔 모든 SaaS가 자체 에이전트를 강요했고, 코드는 그 에이전트에 갇혔다. 한 번 Datadog APM에 묶이면 빠져나오는 게 곧 코드 리팩토링이었다.

OTel가 바꾼 것:

계측이 벤더 중립이 됐다. OTLP/gRPC로 메트릭·트레이스·로그를 한 포맷으로 내보내면, 받는 쪽은 SigNoz든 Datadog이든 Grafana든 상관없다.
시맨틱 컨벤션이 표준화됐다. http.request.method, db.system, messaging.destination.name 같은 이름이 모든 도구에서 같은 의미다.
자동 계측 라이브러리가 성숙했다. Python·Node·Java·Go·.NET·Ruby 모두 zero-code instrumentation이 가능하다.
OpenTelemetry Collector가 사실상의 라우터·필터·집계기로 자리 잡았다. 보내는 곳을 바꿔도 앱은 안 바꾼다.

2024년 OTel는 CNCF Graduated 프로젝트가 됐다. 2025년 로그 시그널이 GA로 풀렸다. 2026년 현재 트레이스·메트릭·로그·예외 전부가 안정 단계다. 프로파일링은 OTel Profiles로 베타 단계에 진입했다.

핵심 한 줄: OTel만 잘 깔아두면 백엔드는 갈아끼울 수 있는 옵션이 됐다. 이게 모든 OSS 도구가 동시에 살아남는 이유다.

2장 · 2026년 OSS 옵저버빌리티 지형 한눈에

먼저 비교 매트릭스. 컬럼이 많으니 가로로 펼쳐서 봐야 한다.

도구	주 시그널	저장소 백엔드	강점	약점	라이선스	적합 규모
SigNoz	트레이스·메트릭·로그·예외	ClickHouse	OTel 네이티브, 통합 UI	ClickHouse 운영 부담	MIT + 일부 Enterprise	중대형
Coroot	메트릭·트레이스(eBPF)	Prometheus·ClickHouse	무계측, 자동 토폴로지	윈도우 미지원	Apache 2.0 + Enterprise	중형 K8s
OpenObserve	로그·트레이스·메트릭	S3+Parquet	저장 비용 5~30%	UI 신생, 호환성 일부 부족	AGPL-3.0	대형 로그
Sentry self-hosted	예외·세션·트레이스	PostgreSQL·ClickHouse	에러 UX 압도	self-host 정책 변동 위험	FSL/BSL	전 규모
Uptrace	트레이스·메트릭·로그	ClickHouse	단일 노드 부팅 쉬움	커뮤니티 작음	AGPL-3.0	소·중형
Grafana 스택	분리형 5종	각자 다름	가장 큰 에코·LGTM	도구 5개 통합 부담	AGPL-3.0	전 규모

저장소 백엔드가 이 표의 진짜 축이다. ClickHouse는 압축률과 쿼리 속도, S3+Parquet는 저비용 장기 보관, Prometheus TSDB는 메트릭에 최적이다. 셋의 트레이드오프는 뒤에서 다시 본다.

3장 · SigNoz — Datadog의 진짜 대안

SigNoz는 2021년 OTel-native APM·로그·메트릭 통합 도구로 시작했다. 2026년 현재 4만 GitHub 스타, SOC 2 Type II 인증, 시리즈 A 후속 라운드까지 마쳤다. 셀프호스트는 무료(Community Edition)이고, SaaS는 GB/CPU·호스트별로 과금한다.

기술 스택:

계측 — OTel SDK 그대로. 별도 에이전트 없음.
수집 — OpenTelemetry Collector 풀스택. 또는 OTLP로 직접.
저장 — ClickHouse(필수). 트레이스·메트릭·로그가 한 DB.
쿼리 — SigNoz 자체 UI + PromQL + ClickHouse SQL.
알람 — Grafana식 규칙 또는 자체 UI.

왜 ClickHouse인가? OLAP 컬럼형 DB가 옵저버빌리티에 자연스럽게 맞는다. 트레이스 한 줄은 보통 30~~80개 속성이 있고, 거의 모든 쿼리가 "조건 + 집계"다. 컬럼형은 필요한 컬럼만 읽고, LZ4 압축률이 평균 8~~12배라 저장 비용도 낮다. ClickHouse 자체가 분당 수억 행 인입을 처리한다.

핵심 차별점:

단일 UI에서 트레이스·메트릭·로그 점프 — 같은 trace_id가 세 시그널 모두에 박혀 있다. 한 클릭으로 이동.
Exception 시그널 — Sentry처럼 예외만 따로 모아 그룹화·집계.
PromQL + ClickHouse SQL — Grafana 사용자도 익숙하고, 깊은 분석이 필요하면 SQL.
Tail-based sampling 내장 — 에러·느린 트레이스만 보존하는 게 표준 기능.

도커 컴포즈 한 방 부팅:

git clone -b main https://github.com/SigNoz/signoz.git
cd signoz/deploy
./install.sh
# 브라우저 http://localhost:3301

쿠버네티스는 Helm 차트로:

helm repo add signoz https://charts.signoz.io
helm install signoz signoz/signoz \
  --namespace platform \
  --create-namespace \
  --set otelCollector.replicaCount=3 \
  --set clickhouse.persistence.size=500Gi

규모 가이드:

트레이스 RPS 1만 미만 — 단일 ClickHouse 노드 가능. 16 vCPU / 64 GB / 1 TB NVMe.
RPS 1만~10만 — ClickHouse 클러스터 3 노드, ZooKeeper 또는 ClickHouse Keeper.
RPS 10만 이상 — 별도 SRE 팀 필요. 이 시점에선 Datadog 비용과 셀프호스트 인건비를 다시 비교해야 한다.

운영의 함정:

ClickHouse 디스크 압박은 사일런트 킬러. TTL 정책을 정확히 설정(트레이스 7일, 메트릭 30일, 로그 14일이 기본).
OTel Collector를 한 줄로 풀어두면 단일 장애점. DaemonSet + Gateway 패턴으로 분리.
카디널리티 폭발. user_id, request_id를 라벨로 박지 마라. 속성(attribute)으로만.

4장 · Coroot — eBPF로 무계측 APM

Coroot는 한 줄도 안 고치고 APM을 시작하는 게 목표다. eBPF로 커널 레벨에서 TCP 연결을 후킹하고 HTTP/gRPC/DB 트래픽을 자동 분류한다. 코드에 SDK를 박을 시간이 없거나, 박을 권한이 없는 환경(레거시 자바·인하우스 PHP·노드)에 매력적이다.

핵심 아키텍처:

coroot-node-agent — DaemonSet으로 모든 노드에 eBPF 프로브.
coroot-cluster-agent — Kubernetes 메타데이터 수집.
coroot — UI + 룰 엔진. Prometheus 메트릭 + ClickHouse 트레이스 + 자체 인벤토리.

eBPF가 잡아주는 것:

서비스 토폴로지 — 자동.
SLO·SLI 추정 — 응답 시간·에러율 자동 계산.
DB·메시지큐 호출 — Postgres·MySQL·Redis·Kafka 프로토콜 디코딩.
컨테이너별 CPU·메모리 사용량 — cgroup 기반.
노드 네트워크 손실·재전송 — TCP 통계.

eBPF가 잡지 못하는 것:

비즈니스 컨텍스트(주문 ID·결제 금액 같은 도메인 속성)
함수 단위 트레이스(코드 내부 호출 그래프)
윈도우(eBPF는 리눅스 커널 기능)
TLS 종료 후 평문 HTTP — 이건 uprobe로 SSL 라이브러리 후킹해야 한다(Coroot가 부분적으로 지원)

2026년 Coroot 라이센싱은 두 갈래다. 코어는 Apache 2.0 OSS, AI 기반 RCA(Root Cause Analysis)와 SSO·RBAC는 Enterprise. 무료 셀프호스트로 80%는 충분히 커버된다.

쿠버네티스 설치:

helm repo add coroot https://coroot.github.io/helm-charts
helm install coroot coroot/coroot \
  --namespace coroot \
  --create-namespace \
  --set clickhouse.shards=1 \
  --set prometheus.retention=15d

UI를 한 번 띄우면 "내 클러스터에 이런 게 돌고 있었구나"가 처음으로 보인다. 그게 Coroot의 진짜 가치다. 계측 노력 제로 + 즉시 가시성.

함께 쓰면 좋은 패턴: Coroot로 자동 베이스라인, 그 위에 SigNoz·Sentry로 비즈니스 컨텍스트가 필요한 곳만 수동 계측.

5장 · OpenObserve — Rust와 S3로 페타바이트를 5% 비용에

OpenObserve는 2023년 등장한 Rust 기반 로그·트레이스·메트릭 플랫폼이다. 2026년 GitHub 스타 1.6만, 시리즈 A 펀딩 완료, AGPL-3.0 라이선스. 가장 큰 무기는 저장소 비용이다.

벤치 한 줄. 같은 양의 로그를 Elasticsearch 대비 140배 적은 저장, Splunk 대비 140배 저렴한 운영 비용. 어떻게? S3 + Parquet + 인덱스리스 풀텍스트 검색.

전통적 로그 시스템(Elasticsearch·Splunk)은:

모든 필드를 인덱싱한다 — 디스크가 폭발한다.
인덱스를 메모리에 캐싱한다 — 비싼 인스턴스 필요.
로컬 디스크에 저장한다 — 장기 보관용 콜드 스토리지 따로 필요.

OpenObserve의 다른 길:

인덱스리스. 로그를 Parquet로 압축해 바로 S3에 쌓는다.
인메모리 블룸 필터로 1차 필터링, 컬럼형 스캔으로 실제 매칭.
S3는 그 자체로 무한 + 저렴 + 내구성 11 9s. 콜드/핫 분리가 자동.

트레이드오프:

인덱스가 없으니 "모든 로그에서 X 찾기"는 Elasticsearch보다 느릴 수 있다.
다만 시간 범위 + 한두 개 필드 필터는 빠르다(실제 90%의 쿼리 패턴).
풀텍스트는 블룸 필터 + Parquet 통계로 충분한 경우가 대다수.

2026년 시점 OpenObserve는 다음을 지원한다:

로그 — JSON·Syslog·Fluentbit·OTLP.
트레이스 — OTLP/gRPC + Jaeger 호환.
메트릭 — Prometheus Remote Write + OTLP.
알람·대시보드 — 자체 UI.
멀티테넌시·SSO·RBAC — Enterprise.

도커 한 줄 부팅:

docker run -d \
  -v $PWD/data:/data \
  -p 5080:5080 \
  -e ZO_ROOT_USER_EMAIL=admin@example.com \
  -e ZO_ROOT_USER_PASSWORD=admin \
  public.ecr.aws/zinclabs/openobserve:latest

쿠버네티스 + S3 모드:

# values.yaml (Helm)
config:
  ZO_S3_BUCKET_NAME: my-o2-logs
  ZO_S3_REGION_NAME: ap-northeast-2
  ZO_DATA_STREAM_TYPE: s3
ingester:
  replicaCount: 3
querier:
  replicaCount: 2

규모가 페타바이트 단위로 가고 로그가 핵심인 회사(보안·핀테크·게임)에 OpenObserve는 진짜 답이 된다. Loki + S3와 비교하면 OpenObserve의 단일 도구 통합이 운영 비용을 더 낮춰준다.

6장 · Sentry self-hosted — 여전히 에러의 캐논, 하지만 정책이 흔들렸다

Sentry는 2008년부터 에러 추적의 사실상 표준이었다. 셀프호스트도 오래 무료였다. 그런데 2024년부터 흐름이 바뀌었다.

2023년 FSL(Functional Source License)로 라이선스 전환. 2년 후 Apache 2.0으로 자동 전환되는 BSL 변형.
2024년 일부 신규 기능(Replay·Crons)은 SaaS 우선, OSS 지연 출시.
2025년 self-host 패키지가 더 무거워짐(50 GB 디스크, 다중 컴포넌트).
Sentry 측 공식 입장: "self-host는 계속 유지하지만, SaaS 우선 개발 페이스가 빨라진다."

2026년 5월 현재 self-host는 살아 있다. 매월 릴리스가 있고, 핵심 기능(Error·Performance·Profiling·Crons)은 다 들어온다. 다만 운영 부담은 결코 가볍지 않다.

self-host 구성 요소:

Snuba — ClickHouse 위의 쿼리 레이어
Relay — 이벤트 수집·필터 게이트웨이
Kafka — 이벤트 큐
Redis — 캐시·레이트리밋
PostgreSQL — 메타데이터
Sentry 본체 — 장고 + 셀러리
Symbolicator — 소스맵·심볼 해석

전부 합치면 8~12개 컨테이너, 50 GB 디스크가 출발선. 단일 노드에서 트래픽 일 100만 이벤트까지는 무리 없다. 그 이상이면 Kafka·ClickHouse 분리가 시작된다.

설치:

git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
./install.sh
# .env에서 SENTRY_EVENT_RETENTION_DAYS=90 같은 옵션 조정

세 가지 시나리오:

순수 에러 추적 — Sentry self-host가 압도. 그룹화·트렌드·릴리스 비교가 동급 OSS에 없다.
에러 + 풀스택 옵저버빌리티 — SigNoz가 통합으로 우위. Sentry의 Exception은 SigNoz에서도 1급 시그널.
에러 + 비용 부담 큼 — Sentry SaaS의 Developer/Team 가격이 부담이면 self-host가 답.

자주 묻는 질문: "Sentry는 OTel 호환되나?" 부분적으로 YES. OTel 트레이스를 Sentry로 보낼 수 있지만(Performance 시그널) 에러는 여전히 Sentry SDK가 표준이다. 2026년 들어 OTel Exception 시그널과 Sentry 그룹화가 통합되는 작업이 진행 중.

7장 · Uptrace — 라이트웨이트 ClickHouse APM

Uptrace는 SigNoz와 같은 ClickHouse 기반 OTel APM이지만 단일 노드에서 가볍게 시작하는 게 미덕이다. AGPL-3.0, 셀프호스트는 무료, SaaS는 별도 과금.

SigNoz와의 차이:

단일 바이너리 부팅 가능 — 도커도 한 컨테이너.
ClickHouse 한 노드면 충분 — 트래픽 일 5천만 스팬까지 무리 없다.
UI가 더 간결 — 트레이스 위주, 메트릭은 보조.

언제 Uptrace를 고르는가:

팀이 작고, 셀프호스트 인력 1명도 빠듯할 때.
ClickHouse는 처음이지만 한 번 깔아보고 싶을 때.
트레이스 한 가지만 깊게 보고 싶을 때.

언제 SigNoz로 가는가:

트레이스 + 메트릭 + 로그 + 예외 모두 통합으로 보고 싶을 때.
팀이 커지고 ClickHouse 클러스터 운영을 받아들일 수 있을 때.

도커 한 줄:

docker run -d --name uptrace \
  -p 14317:14317 -p 14318:14318 \
  -v $PWD/uptrace.yml:/etc/uptrace/uptrace.yml \
  uptrace/uptrace:latest

Uptrace는 OTel Collector를 통합 형태로 안에 박아두기도 한다(Standalone 모드). OTel 처음 시작하는 팀에 "가장 진입 장벽 낮은 옵션"이다.

8장 · Grafana 스택 — 가장 큰 에코, 가장 모듈러한 선택

Grafana Labs가 2017년부터 쌓아 올린 스택은 2026년 OSS 옵저버빌리티의 가장 큰 단일 진영이다. 도구별로 보면:

Prometheus — 메트릭의 사실상 표준. 2024년 OTLP 수신 지원으로 OTel 호환 완성.
Mimir — Prometheus의 수평 확장 백엔드. 멀티테넌트, S3 저장.
Loki — 로그. "라벨만 인덱스" 철학으로 저장 비용 낮음.
Tempo — 분산 트레이스. S3·GCS·MinIO 저장 가능.
Pyroscope — 컨티뉴어스 프로파일링. eBPF + 언어별 SDK.
Grafana — 대시보드의 표준. LGTM 데이터를 한 화면에.
Alloy — OpenTelemetry Collector 배포판. 2024년 Grafana Agent 후속.
Beyla — eBPF 자동 계측. Coroot보다 가벼움, 단일 서비스 단위.
k6 — 부하 테스트. 옵저버빌리티 시그널과 자연스럽게 묶임.

장점:

각 도구가 한 가지를 깊게. 옵저버빌리티 인력이 있는 팀에 유리.
연합 운영 가능. Mimir 한 곳, Tempo 한 곳, Loki 한 곳으로 분산 책임.
Grafana 대시보드 에코시스템이 거대. 어떤 도구든 그리는 게 익숙하다.

단점:

5개 도구를 운영한다. 단일 통합 UI는 Grafana지만 백엔드는 따로.
시작이 무겁다. 도커 컴포즈 하나로는 못 끝난다.
알람·룰이 도구마다 다름. 표준화 필요.

언제 Grafana 스택인가:

이미 Prometheus를 쓰고 있고 자연스럽게 확장하는 경우.
옵저버빌리티 전담 SRE 팀이 있는 경우.
멀티테넌트·연합 클러스터 요구가 있는 경우.

언제 SigNoz·Uptrace가 더 나은가:

통합 UI 한 곳에서 모두 보고 싶을 때.
운영 인력이 부족할 때.
처음 시작하는 팀.

Grafana Cloud의 무료 티어가 꽤 넉넉해서 "셀프호스트 vs Grafana Cloud" 비교도 항상 같이 본다. 2026년 무료 티어는 메트릭 10k 시리즈, 로그 50 GB, 트레이스 50 GB, 14일 보존이다.

9장 · 저장소 백엔드 — 진짜 결정

도구 선택의 8할은 백엔드 선택이다. 세 가지 패턴이 시장을 양분한다.

9.1 ClickHouse — 컬럼형 OLAP

쓰는 곳: SigNoz, Uptrace, Sentry(Snuba), Coroot(트레이스).

장점:

압축률 8~12배. 디스크 비용 낮음.
분당 수억 행 인입.
컬럼형 스캔으로 좁은 쿼리 빠름.
SQL 그대로 쓸 수 있다.

단점:

운영 난이도 높음. 백업·레플리카·키퍼 모두 학습 필요.
머지·뮤테이션 비용. 잦은 업데이트엔 부적합.
카디널리티 폭발에 취약. 라벨 설계 잘못하면 디스크 폭주.

9.2 S3 + Parquet — 인덱스리스 객체스토리지

쓰는 곳: OpenObserve, Tempo, Loki(블록), Mimir(블록).

장점:

사실상 무한 + 11 9s 내구성 + 저렴.
콜드 스토리지 자동. 핫/콜드 티어링 옵션.
분리된 컴퓨트 — 쿼리 노드만 늘리면 됨.

단점:

로컬 디스크보다 느림. 캐시 레이어 필수.
쿼리 패턴이 시간 + 좁은 필드에 한정될 때 효율적.
풀텍스트 무거운 분석에 약함.

9.3 Prometheus TSDB — 시계열 전용

쓰는 곳: Prometheus, Mimir, Cortex, VictoriaMetrics.

장점:

메트릭에 압도적 최적화. 적은 디스크, 빠른 쿼리.
PromQL 생태계가 표준.
운영 단순(단일 노드 기준).

단점:

트레이스·로그엔 안 맞음. 시계열만.
수평 확장은 Mimir·Thanos 같은 별도 도구 필요.

조합 가이드:

메트릭이 80% — Prometheus + Mimir.
로그가 80% — OpenObserve 또는 Loki + S3.
트레이스가 80% — SigNoz·Uptrace + ClickHouse, 또는 Tempo + S3.
셋 다 균형 — SigNoz 단일.

10장 · Datadog → SigNoz 마이그레이션 실제 사례

2025년 분기말 5만 호스트 규모 SaaS의 마이그레이션 노트를 재구성했다.

10.1 시작 상태

월 청구서 14만 달러(APM 8만, 로그 4만, 메트릭 2만).
자바·고·노드 백엔드 80개 서비스.
Datadog Agent로 자동 계측.
카디널리티 폭주로 커스텀 메트릭이 매월 12% 증가.

10.2 단계별 이전

Phase 1 — 계측 추상화(4주)

OTel SDK로 전환. 코드 변경 최소화하기 위해 자동 계측 라이브러리 우선. 일부 비즈니스 속성만 수동 추가.

Phase 2 — 듀얼 백엔드(6주)

OTel Collector에서 Datadog·SigNoz 양쪽으로 동시 전송. SigNoz는 dev·staging 먼저, 1주씩 프로덕션 일부 서비스에 적용. 데이터 일치 검증.

Phase 3 — SLO 검증(4주)

핵심 알람·대시보드 SigNoz에서 재구성. 응답 시간·에러율 SLO 정의가 Datadog Monitor와 동일하게 동작하는지 확인. on-call이 SigNoz UI에 익숙해질 시간.

Phase 4 — Datadog 제거(2주)

서비스별로 단계 차단. 마지막은 Datadog Agent 제거.

10.3 결과

월 청구서 14만 → SigNoz 인프라 1.2만 + SRE 부담 증가 → 순 비용 90% 절감.
트레이스 30일 보존 → 15일 단축(필요성 재검토 결과 충분).
카디널리티 정책으로 커스텀 메트릭 50% 감소.
on-call MTTR 변화 없음.

10.4 후회 항목

듀얼 운영 기간이 너무 짧았다. 8주 권장.
로그 마이그레이션을 같이 했어야 했다. 따로 했더니 컨텍스트가 끊겼다.
ClickHouse 디스크 모니터링을 처음에 빼먹어 디스크 풀로 한 번 사고.

11장 · 셀프호스트의 진짜 비용

"OSS면 공짜"는 거짓말이다. 정직한 비용 모델은 이렇다.

인프라: ClickHouse·S3·Prometheus 노드, 백업, 멀티 AZ. 월 1만~~5만 달러 규모(50~~500 호스트 기준).
인건비: SRE 0.3~~1명 풀타임. 연 5만~~15만 달러.
다운타임 리스크: 옵저버빌리티 자체가 죽으면 트러블슈팅이 막힌다. HA 설계 필수.
러닝 커브: ClickHouse·Kafka·S3 라이프사이클, OTel Collector 튜닝, 보존 정책. 첫 6개월은 시행착오.

언제 셀프호스트가 이기는가:

청구서가 월 3만 달러 이상이고
SRE가 있고
데이터를 외부에 안 보내야 할 컴플라이언스 이유가 있고
카디널리티·보존 정책을 본인이 통제하고 싶을 때.

언제 SaaS가 이기는가:

팀이 작고 SRE가 없음.
청구서가 월 5천 달러 이하.
보안·컴플라이언스가 SaaS를 막지 않음.
빨리 시작이 가치가 더 큼.

중간 옵션: Grafana Cloud 또는 SigNoz Cloud. OSS의 백엔드를 매니지드로 받는다. 청구서가 Datadog의 30~50% 수준이면서 운영 부담이 없다.

12장 · 안티패턴 모음

오랜 시간 누적된 함정들.

"옵저버빌리티 = 로그" — 로그만 쌓으면 트레이스·메트릭이 없어 인과 추적이 불가능하다.
카디널리티 폭발 — user_id, request_id를 라벨에 박는 순간 끝. 속성으로만.
샘플링 없이 풀스로틀 — 트래픽 1만 RPS인데 트레이스 100% 보존? 디스크가 폭발한다. Tail-based sampling으로 에러·느린 것만.
알람 폭격 — 한 사람에 시간당 30개 알람은 곧 무시된다. SLO 기반 알람으로 의미 있는 것만.
단일 OTel Collector — 단일 장애점. DaemonSet + Gateway 두 단계.
TTL 미설정 — 디스크가 가득 차고서야 깨닫는다. 셀프호스트 첫 주에 무조건.
대시보드 200개 — 아무도 안 본다. 5개의 골든 대시보드 + 자동 알람이 더 효과적.
개발자 계측 의무화 없이 도구만 배포 — 도구는 깔렸는데 데이터가 없다. 계측 게이트 + CI 검증 필수.
OTel 시맨틱 컨벤션 무시 — 본인이 만든 키 이름은 일주일 후 본인도 못 찾는다. 표준 컨벤션 따라가라.
백엔드 1개에 몰빵 — ClickHouse만 뜨면 SigNoz·Sentry·Uptrace 다 죽는다. 분리.

13장 · 도입 의사결정 플로차트

질문을 순서대로 답해라.

현재 월 옵저버빌리티 비용은? 1만 달러 미만이면 → SaaS 유지.
SRE 또는 옵저버빌리티 담당이 있는가? 없다면 → SaaS 또는 매니지드(Grafana Cloud·SigNoz Cloud).
컴플라이언스로 외부 전송 금지인가? 그렇다면 → 셀프호스트 결정.
주된 시그널이 무엇인가?
- 트레이스+메트릭+로그 통합 → SigNoz.
- 로그가 지배적 → OpenObserve 또는 Loki.
- eBPF로 무계측 시작 → Coroot.
- 에러 추적이 핵심 → Sentry self-host.
- 가벼운 단일 노드 → Uptrace.
- 모듈러 운영 → Grafana 스택.
향후 3년 규모 예측은? 페타바이트 로그 예상 → OpenObserve·Loki. 그 이하 → SigNoz.

14장 · 2026년 이후의 흐름

OSS 옵저버빌리티는 어디로 가고 있는가.

OTel Profiles GA — 2025년 베타, 2026년 후반 GA 예상. 컨티뉴어스 프로파일링이 4번째 시그널로 자리.
AI 기반 RCA — Coroot·SigNoz·Grafana 모두 자체 RCA 기능을 OSS와 Enterprise로 나눠 출시 중. LLM이 인시던트 첫 가설을 던지는 게 표준이 될 전망.
eBPF 보편화 — Beyla·Coroot 외에 더 많은 도구가 eBPF 기반 자동 계측을 지원할 것.
저장소 분리·연합 표준화 — Iceberg·Parquet 기반 공통 포맷이 도구별 락인을 풀어주는 흐름.
카디널리티 가격제의 종말 — Datadog·New Relic도 라벨 카디널리티 기반 가격제에서 후퇴 압박. OSS의 자유로움이 가격 모델 자체를 압박.

3년 뒤 예측 한 줄: OTel + S3-Parquet + ClickHouse + eBPF 조합이 OSS 옵저버빌리티의 사실상 기본 스택이 된다. Datadog·New Relic은 여전히 존재하지만 시장 점유율은 30~40%대로 떨어질 가능성이 크다.

에필로그 — 셀프호스트는 권리이고, 책임이다

오래된 진리: 옵저버빌리티는 보험이 아니라 제품이다. 그 제품의 백엔드를 SaaS에 맡기는 것도 정당한 선택이고, 직접 운영하는 것도 정당한 선택이다. 다만 둘 다 비용이 든다. SaaS는 청구서로, 셀프호스트는 시간과 SRE 인건비로.

2026년이 흥미로운 이유는 선택지가 진짜로 늘었기 때문이다. OpenTelemetry가 벤더 록인을 깼고, ClickHouse·S3-Parquet가 저장 비용 곡선을 끌어내렸고, eBPF가 계측 노력을 0으로 수렴시켰다. 결과적으로 한 도구가 모든 걸 다 잘하는 시대는 끝났고, 여러 도구를 모듈식으로 조합하는 시대가 됐다.

14.1 도입 체크리스트

14.2 안티패턴 요약

옵저버빌리티 = 로그라고 착각하기.
카디널리티 폭발 무시하기.
샘플링 없이 100% 보존.
알람 폭격으로 신뢰 잃기.
단일 OTel Collector로 운영.
TTL 안 걸기.
대시보드 200개.
계측 의무화 없이 도구만 배포.
시맨틱 컨벤션 무시.
백엔드 한 곳에 몰빵.

14.3 다음 글 예고

다음 글에선 OTel Collector 깊이 분석을 다룬다. DaemonSet vs Gateway, 처리기·필터·라우터 구성, Tail-based sampling 실제 구현, 카프카 백킹·재시도·DLQ까지. OSS 옵저버빌리티의 진짜 운영 시작점이 거기에 있다.

참고 / References

OpenTelemetry: https://opentelemetry.io/
OTel Collector: https://opentelemetry.io/docs/collector/
SigNoz: https://signoz.io/ · https://github.com/SigNoz/signoz
Coroot: https://coroot.com/ · https://github.com/coroot/coroot
OpenObserve: https://openobserve.ai/ · https://github.com/openobserve/openobserve
Sentry self-hosted: https://develop.sentry.dev/self-hosted/ · https://github.com/getsentry/self-hosted
Uptrace: https://uptrace.dev/ · https://github.com/uptrace/uptrace
Grafana Loki: https://grafana.com/oss/loki/
Grafana Tempo: https://grafana.com/oss/tempo/
Grafana Mimir: https://grafana.com/oss/mimir/
Grafana Pyroscope: https://grafana.com/oss/pyroscope/
Grafana Beyla: https://grafana.com/oss/beyla-ebpf/
Grafana Alloy: https://grafana.com/oss/alloy-opentelemetry-collector/
ClickHouse: https://clickhouse.com/
Prometheus: https://prometheus.io/
CNCF Observability TAG: https://github.com/cncf/tag-observability