LabHub

블로그

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

한국어English日本語

프롤로그 — 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 모니터링 풍경의 정직한 지도다.

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


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

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

OTel가 바꾼 것:

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

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

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


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

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

도구주 시그널저장소 백엔드강점약점라이선스적합 규모
SigNoz트레이스·메트릭·로그·예외ClickHouseOTel 네이티브, 통합 UIClickHouse 운영 부담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·호스트별로 과금한다.

기술 스택:

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

핵심 차별점:

  1. 단일 UI에서 트레이스·메트릭·로그 점프 — 같은 trace_id가 세 시그널 모두에 박혀 있다. 한 클릭으로 이동.
  2. Exception 시그널 — Sentry처럼 예외만 따로 모아 그룹화·집계.
  3. PromQL + ClickHouse SQL — Grafana 사용자도 익숙하고, 깊은 분석이 필요하면 SQL.
  4. 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

규모 가이드:

운영의 함정:


4장 · Coroot — eBPF로 무계측 APM

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

핵심 아키텍처:

eBPF가 잡아주는 것:

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

eBPF가 잡지 못하는 것:

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)은:

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

OpenObserve의 다른 길:

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

트레이드오프:

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

도커 한 줄 부팅:

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년부터 흐름이 바뀌었다.

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

self-host 구성 요소:

전부 합치면 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 같은 옵션 조정

세 가지 시나리오:

  1. 순수 에러 추적 — Sentry self-host가 압도. 그룹화·트렌드·릴리스 비교가 동급 OSS에 없다.
  2. 에러 + 풀스택 옵저버빌리티 — SigNoz가 통합으로 우위. Sentry의 Exception은 SigNoz에서도 1급 시그널.
  3. 에러 + 비용 부담 큼 — 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와의 차이:

언제 Uptrace를 고르는가:

언제 SigNoz로 가는가:

도커 한 줄:

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 옵저버빌리티의 가장 큰 단일 진영이다. 도구별로 보면:

장점:

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

단점:

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

언제 Grafana 스택인가:

언제 SigNoz·Uptrace가 더 나은가:

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


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

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

9.1 ClickHouse — 컬럼형 OLAP

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

장점:

단점:

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

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

장점:

단점:

9.3 Prometheus TSDB — 시계열 전용

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

장점:

단점:

조합 가이드:


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

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

10.1 시작 상태

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 결과

10.4 후회 항목


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

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

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

언제 SaaS가 이기는가:

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


12장 · 안티패턴 모음

오랜 시간 누적된 함정들.

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

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

질문을 순서대로 답해라.

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

14장 · 2026년 이후의 흐름

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 안티패턴 요약

14.3 다음 글 예고

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


참고 / References

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다