네트워크 & 서비스 옵저버빌리티 2026 완벽 가이드 - eBPF · Cilium Hubble · Pixie · Pyroscope · Grafana Loki + Tempo + Mimir · Netdata · OpenTelemetry 심층 분석

프롤로그 — 2026년, 옵저버빌리티는 "왜?"에 답해야 한다

2015년 옵저버빌리티는 메트릭·로그·트레이스 3 기둥(three pillars)이라는 단어와 함께 시작했다. 2023년 CNCF는 여기에 continuous profiling을 네 번째 기둥으로 공식화했다. 그리고 2026년 현재, 진짜 변화는 다른 곳에서 일어났다. 계측(instrumentation)이 사라졌다는 것이다.

5년 전만 해도 Java 앱에 트레이스를 붙이려면 OpenTelemetry SDK를 import하고, 모든 함수에 어노테이션을 달고, 컨텍스트 전파를 코드로 짜야 했다. 2026년의 표준은 eBPF로 커널 레벨에서 자동으로 잡는다이다. Cilium Hubble은 클러스터의 모든 패킷을 본다. Pixie는 K8s 노드에 DaemonSet 하나로 모든 HTTP/gRPC/SQL 요청을 본다. Beyla, Coroot, Caretta는 코드를 한 줄도 안 고치고 골든 시그널을 뽑는다.

그렇다고 SDK 시대가 끝난 것은 아니다. OpenTelemetry는 2024년 CNCF Graduated가 됐고, OTLP는 사실상의 와이어 프로토콜 표준이 됐다. eBPF가 "공짜로 얻는 80%"라면, OTel SDK는 "남은 20%의 비즈니스 의미"를 채운다. 즉, 2026년 스택의 진짜 모양은 eBPF + OTel 하이브리드다.

이 글은 그 지도를 그린다 — 메트릭·로그·트레이스·프로파일 4 기둥, eBPF의 모든 도구(Cilium / Hubble / Tetragon / Pixie / Inspektor Gadget / Coroot / Beyla / Caretta), Grafana LGTM(Loki + Tempo + Mimir + Pyroscope), Datadog/New Relic/Dynatrace 같은 SaaS 거인, 네트워크 옵저버빌리티 전용 도구들(Suzieq, ntopng, ThousandEyes), 그리고 한국·일본 기업의 실제 사용 사례까지.

옵저버빌리티는 모니터링의 상위 집합이다. 모니터링이 "정해진 지표가 임계치를 넘는지 보는 것"이라면, 옵저버빌리티는 "임의의 질문에 답할 수 있는 시스템 상태"다. 2026년의 차이를 만드는 건 도구가 아니라 이 질문을 던질 수 있게 만드는 스택 설계다.

다루는 것:

4 기둥(metrics / logs / traces / profiles)과 골든 시그널
eBPF 혁명 — Cilium 1.16, Hubble, Tetragon, Pixie
OpenTelemetry 2026 — Collector, OTLP, Auto-instrument
메트릭 스택 — Prometheus 3.0, VictoriaMetrics, Mimir
로그 스택 — Loki 3, Elastic, Vector, Quickwit, OpenObserve, SigNoz
트레이스 스택 — Tempo 2, Jaeger 2, Zipkin, Honeycomb
Continuous Profiling — Pyroscope, Parca, Polar Signals
네트워크 옵저버빌리티 — Suzieq, Skydive, ntopng, ThousandEyes
RUM & 합성 모니터링 — Cloudflare, Checkly, Grafana Synthetic
APM 비교 — Datadog, New Relic, Dynatrace, AppDynamics
K8s 옵저버빌리티 — Prometheus Operator, k9s, Lens
서비스 메시 + 옵저버빌리티 — Kiali, Linkerd dashboard
DevSecOps + 옵저버빌리티 — Falco + OTel
스토리지 백엔드 — VictoriaMetrics, Mimir, ClickHouse, MinIO
비용 모델 — Datadog $35-70/host vs self-host LGTM
한국 사례 — NCsoft Pixie, Coupang Datadog, Naver OTel, Kakao Grafana
일본 사례 — Mercari, LINE Yahoo, CyberAgent
SLO/SLI와 에러 버짓 운영
알림과 PagerDuty/Opsgenie/Incident.io
AI-native 옵저버빌리티의 윤곽
도입 로드맵 — 어디서 시작할 것인가
참고 문헌

1. 4 기둥과 골든 시그널 — 무엇을 측정하는가

옵저버빌리티의 출발점은 "무엇을 보느냐"다. 2026년 현재 합의된 답은 4 기둥이다.

메트릭(Metrics) — 시계열 숫자. http_requests_total, cpu_usage_seconds_total 같은 카운터/게이지/히스토그램. 가장 싸고 가장 오래 보관할 수 있다.
로그(Logs) — 이벤트 텍스트. 사건이 일어났을 때의 컨텍스트가 풍부하지만, 비싸고 검색이 느리다.
트레이스(Traces) — 분산 요청의 인과관계. 한 사용자 요청이 마이크로서비스 A → B → C → DB를 어떻게 지나갔는지 보여준다.
프로파일(Profiles) — CPU/메모리/락 점유의 함수 단위 분포. 어떤 함수가 CPU를 가장 많이 쓰는지를 항상(continuously) 추적한다.

여기에 Google SRE 책의 골든 시그널 4종을 매핑하는 것이 표준 운영 시각이다.

골든 시그널	정의	메트릭 예시
Latency	요청을 처리하는 데 걸린 시간	p50/p95/p99 응답 시간
Traffic	시스템이 받고 있는 부하	RPS, QPS, MB/s
Errors	실패율	5xx 비율, 예외 카운트
Saturation	자원 포화도	CPU 사용률, 큐 길이, 디스크 IOPS

2023년 USE 메소드와 RED 메소드 — Brendan Gregg의 USE(Utilization / Saturation / Errors)는 자원 중심, Tom Wilkie의 RED(Rate / Errors / Duration)는 요청 중심. 둘 다 골든 시그널의 사촌이고, 어떤 시각으로 시작할지에 따라 첫 대시보드의 모양이 달라진다.

2. eBPF 혁명 — Cilium, Hubble, Tetragon, Pixie

2026년 옵저버빌리티의 진짜 변곡점은 eBPF(extended Berkeley Packet Filter)다. 리눅스 커널 안에 안전한 가상머신을 띄워 패킷·시스템 콜·소켓 이벤트를 가로채는 기술인데, 이게 옵저버빌리티에 가져온 변화가 결정적이다.

eBPF가 바꾼 것:

언어 무관(language-agnostic) 계측 — Go/Java/Python/Rust 무관하게 커널이 모든 syscall을 본다.
제로 코드 변경(zero-code-change) — DaemonSet 하나만 띄우면 끝.
저오버헤드 — 커널 수준이라 1~3% CPU.
L7 가시성 — HTTP/gRPC/SQL 파서를 eBPF로 돌려 메서드·경로·상태코드까지 잡는다.

대표 도구:

Cilium 1.16 (Isovalent, 2024년 Cisco 인수) — K8s 네트워킹 + 옵저버빌리티. CNI, 서비스 메시(Cilium Service Mesh), 보안, 가시성을 한 묶음으로.
Cilium Hubble — Cilium 위에 얹는 흐름(flow) 가시화 레이어. kubectl exec로 Hubble CLI를 띄우면 어떤 파드가 어떤 파드에 어떤 포트로 말을 거는지 실시간으로 본다.
Tetragon — Cilium의 런타임 보안 자매 프로젝트. 어떤 프로세스가 어떤 파일을 열었고 어떤 syscall을 호출했는지 추적.
Pixie (New Relic 인수, CNCF Sandbox) — K8s에 DaemonSet 한 줄로 깔면 모든 HTTP/gRPC/Postgres/Redis 호출을 자동 캡처. PxL이라는 자체 쿼리 언어 제공.
Inspektor Gadget — eBPF 기반 K8s 디버깅 툴킷. kubectl gadget trace dns 같은 커맨드로 즉시 트레이스.
Coroot, Caretta, Beyla — eBPF로 서비스 맵·골든 시그널을 자동 생성하는 신세대 도구들. Beyla는 Grafana Labs 출신.
bpftrace / BCC Tools — Brendan Gregg의 클래식. execsnoop, tcptracer, biolatency 같은 단일 목적 추적 도구.

# Cilium Hubble UI 설치 (helm)
cilium install --version 1.16.0
cilium hubble enable --ui
cilium hubble port-forward
# http://localhost:12000 에서 실시간 흐름 시각화

Pixie의 마법 — 보통 분산 트레이싱을 붙이려면 모든 서비스에 OTel SDK를 박아야 한다. Pixie는 K8s 노드에 PEM(Pixie Edge Module) DaemonSet 하나만 설치하면 끝이다. 5분 만에 모든 마이크로서비스의 HTTP·gRPC 호출 그래프가 보인다.

3. OpenTelemetry 2026 — 사실상의 표준

OpenTelemetry(OTel)는 2024년 CNCF Graduated가 됐다. CNCF에서 Kubernetes 다음으로 큰 프로젝트가 됐다는 뜻이다. 2026년 현재 OTel은 "관찰 데이터의 와이어 표준"이라고 부를 만하다.

구성요소:

OTel SDK — Go / Java / JS / Python / Rust / .NET / PHP / Ruby / Swift 등 11개 공식 언어 지원
OTel Collector — 데이터 파이프라인. 수집(receivers) → 처리(processors) → 전송(exporters)
Auto-instrumentation — Java는 -javaagent 한 줄, Python은 opentelemetry-instrument 한 줄로 자동 계측
OTLP 프로토콜 — gRPC + HTTP. 메트릭/로그/트레이스/프로파일(2025년 GA) 모두 한 프로토콜로 전송

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
  loki:
    endpoint: http://loki:3100/loki/api/v1/push
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/tempo]

왜 OTel이 이겼나 — 5년 전만 해도 Datadog Agent, New Relic Agent, Jaeger Client, Zipkin Brave가 모두 자기 SDK를 강요했다. 한 회사가 Datadog → New Relic으로 옮기는 데만 수개월이 걸렸다. OTel은 "데이터는 표준화, 백엔드는 자유"라는 약속으로 이 lock-in을 깼다. 2026년에는 Datadog조차 OTLP를 1급 시민으로 받는다.

4. 메트릭 스택 — Prometheus 3.0과 그 동료들

메트릭은 가장 오래되고 가장 성숙한 기둥이다. 2026년 현재 표준은 단연 Prometheus 생태계다.

Prometheus 3.0 (2024.11 릴리스) — UTF-8 라벨, 네이티브 히스토그램, OTLP receiver 내장
VictoriaMetrics — Prometheus 호환의 고성능 대안. 단일 바이너리, 10배 압축
Grafana Mimir — Prometheus의 수평 확장 백엔드. AWS S3/GCS/MinIO에 장기 저장
Thanos — Mimir의 선배. Prometheus + S3 + 멀티 리전 글로벌 뷰
Cortex — Mimir의 전신. 여전히 일부 인스톨레이션에서 사용
Datadog / New Relic / Dynatrace — 상용 메트릭 스택. SaaS 대시보드까지 포함.

# Prometheus 3.0 scrape 예시 + OTLP receive
global:
  scrape_interval: 15s

# OTLP receiver (3.0 신기능)
otlp:
  promote_resource_attributes:
    - service.name
    - service.namespace
    - deployment.environment

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod

VictoriaMetrics와 Mimir의 차이:

항목	VictoriaMetrics	Grafana Mimir
아키텍처	단일 바이너리	분산 마이크로서비스
저장소	로컬 디스크	S3/GCS/MinIO
쿼리 언어	PromQL + MetricsQL	PromQL
압축	매우 높음	보통
운영 난이도	낮음	중간
적합한 규모	단일~중규모	멀티테넌트 대규모

5. 로그 스택 — Loki, Elastic, Vector, Quickwit

로그는 가장 비싸고 가장 자주 문제를 일으키는 기둥이다. 2026년에는 인덱스를 줄이고 컬럼 스토어를 쓰자는 흐름이 확고하다.

Grafana Loki 3.x — "라벨만 인덱싱"하는 로그 DB. Prometheus와 같은 모델, S3 백엔드
Elasticsearch / OpenSearch — 클래식. 전체 텍스트 인덱싱. 강력하지만 비싸다
Quickwit — Rust로 작성된 검색 엔진. S3 우선, 풀텍스트 인덱싱, Elastic 대안
VictoriaLogs — VictoriaMetrics 팀의 로그 DB. 빠른 풀텍스트
OpenObserve — Rust 기반 올인원(메트릭·로그·트레이스)
SigNoz — ClickHouse 위의 오픈소스 옵저버빌리티 (메트릭·로그·트레이스)
ClickHouse — 컬럼 스토어. Uber, Cloudflare가 로그 백엔드로 채택
Fluentd / Fluent Bit / Vector — 로그 수집기. Vector는 2021년 Datadog이 인수한 Rust 기반의 신세대

# Fluent Bit -> Loki 파이프라인 예시
[INPUT]
    Name              tail
    Path              /var/log/containers/*.log
    Parser            docker
    Tag               kube.*

[OUTPUT]
    Name                  loki
    Match                 kube.*
    Host                  loki.observability.svc
    Port                  3100
    Labels                job=fluentbit

Loki vs Elasticsearch 일반론:

로그가 메트릭과 같이 다뤄지길 원한다 → Loki
풀텍스트 검색, SIEM, 보안 분석이 1순위 → Elasticsearch / OpenSearch
Rust 스택, S3 우선 → Quickwit / VictoriaLogs
메트릭·로그·트레이스 통합 → SigNoz / OpenObserve

6. 트레이스 스택 — Tempo 2, Jaeger 2

분산 트레이스는 마이크로서비스의 인과관계를 본다. "한 사용자 요청이 어디서 느렸나"의 정답을 준다.

Grafana Tempo 2.x — 라벨만 인덱싱, S3 백엔드, Loki와 같은 철학
Jaeger 2 (CNCF Graduated, 2024년 풀 재작성) — OTel Collector 기반으로 다시 작성. v1 호환
Zipkin — Twitter 원조. 여전히 단순한 설치를 원할 때 좋다
Honeycomb — 이벤트 기반 옵저버빌리티의 원조. Charity Majors의 영향력
Lightstep (ServiceNow 인수) — 대규모 트레이스 분석
AWS X-Ray / GCP Cloud Trace / Azure Monitor — 클라우드 네이티브 옵션
Datadog APM / New Relic APM / Dynatrace — 상용 통합

# Python OTel auto-instrument 한 줄
# pip install opentelemetry-distro opentelemetry-exporter-otlp
# opentelemetry-bootstrap -a install
# opentelemetry-instrument --traces_exporter otlp \
#   --exporter_otlp_endpoint http://tempo:4317 python app.py

Jaeger 2의 의미 — 1.x 시절 Jaeger는 자체 Cassandra/Elasticsearch 백엔드와 자체 SDK를 가졌다. 2024년 Jaeger 2는 모든 것을 OTel Collector 기반으로 재작성했다. 이는 "트레이스 백엔드도 더 이상 lock-in이 아니다"라는 선언이다.

7. Continuous Profiling — Pyroscope, Parca

2023년부터 옵저버빌리티의 네 번째 기둥으로 정착한 것이 continuous profiling이다. 프로덕션에서 항상 CPU/메모리/락 프로파일을 1~5% 오버헤드로 잡는다.

Grafana Pyroscope — CNCF, Polar Signals의 Parca와 합쳐진 후속작
Parca — 오리지널 eBPF 기반 프로파일링. 2024년 Pyroscope에 통합
Polar Signals Cloud — Parca의 상용 호스팅
Datadog Continuous Profiler — APM에 통합된 상용 옵션
Pyroscope OSS — 자가 호스팅 가능

대표 사용 사례:

CPU 핫스팟 찾기 — 어떤 함수가 CPU의 60%를 먹는지 한눈에
메모리 누수 추적 — 시간에 따른 alloc/free 그래프
락 컨텐션 분석 — 어떤 mutex가 가장 자주 blocking인지

# Pyroscope를 Kubernetes에 배포 (Helm)
helm repo add grafana https://grafana.github.io/helm-charts
helm install pyroscope grafana/pyroscope \
  --set pyroscope.config.scrape_configs[0].job_name=k8s-pods

eBPF + Pyroscope 조합 — Pyroscope의 eBPF 프로파일러는 노드 레벨에서 모든 프로세스의 CPU 프로파일을 자동으로 수집한다. 코드 변경 없이 Go, Rust, C++, Python까지 한 번에 잡힌다.

8. 네트워크 옵저버빌리티 전용 도구

서비스 옵저버빌리티와는 결이 다른 네트워크 자체의 가시성도 중요한 카테고리다.

Suzieq — 네트워크 옵저버빌리티. 스위치·라우터·방화벽 상태를 SQL로 질의
Skydive — 실시간 네트워크 토폴로지 + 트래픽 시각화
ntopng / ntop — 플로우 분석(NetFlow / IPFIX / sFlow)의 클래식
Netflix Atlas — Netflix가 만든 시계열 모니터링. 클라우드 네트워크 메트릭에 강함
Wireshark / tcpdump — 패킷 캡처의 표준. eBPF 시대에도 여전히 마지막 답
Cisco ThousandEyes — 인터넷 경로 모니터링 SaaS. BGP, DNS, CDN 가시성
Catchpoint / Pingdom — 합성 모니터링과 인터넷 모니터링의 상용 옵션
Kentik — 대규모 네트워크 분석 SaaS
Arista CloudVision — 데이터센터 네트워크 옵저버빌리티

# Suzieq 예시: 모든 BGP 세션 상태를 SQL로 조회
$ suzieq-cli
suzieq> bgp show state=NotEstd
namespace  hostname    vrf  peer        state
prod       leaf01      default  10.0.0.2  Active
prod       leaf03      default  10.0.0.6  Connect

클라우드와 함께 네트워크 옵저버빌리티가 다시 중요해진 이유 — 5년 전에는 "네트워크는 클라우드 vendor가 알아서 한다"였다. 2026년에는 멀티 클라우드, 멀티 리전, 서비스 메시, 0 트러스트 네트워크가 일상이 되면서 누가 누구와 무엇을 말하고 있나가 다시 핵심 질문이 됐다.

9. RUM(Real User Monitoring)과 합성 모니터링

서버 측 옵저버빌리티 못지않게 중요한 게 사용자 화면에서 실제로 어떻게 보이는가다.

RUM(Real User Monitoring):

Datadog RUM — 가장 성숙. 세션 리플레이까지
New Relic Browser — 브라우저 모니터링 클래식
Cloudflare Browser Insights — CDN과 통합된 RUM
Sentry Performance — 에러 모니터링과 통합된 RUM (별도 글에서 다룸)
PostHog Session Replay — 프로덕트 분석 + 세션 리플레이

합성 모니터링(Synthetic Monitoring):

Checkly — 코드 우선 합성 모니터링. Playwright 통합
Datadog Synthetics — 멀티스텝 API/브라우저 체크
Grafana Synthetic Monitoring — Grafana Cloud에 통합
Pingdom — 클래식 가용성 모니터링
UptimeRobot, Better Stack — 단순 ping 모니터링의 저비용 옵션

// Checkly 합성 모니터 예시 (Playwright)
import { expect, test } from '@playwright/test'

test('homepage loads', async ({ page }) => {
  const res = await page.goto('https://example.com')
  expect(res.status()).toBeLessThan(400)
  await expect(page.locator('h1')).toContainText('Welcome')
})

2026년의 RUM 표준 — Core Web Vitals(LCP, INP, CLS)를 OTLP로 OTel Collector에 보내고, Grafana로 보는 패턴이 자리잡았다. Cloudflare는 이걸 무료로 제공한다.

10. APM 비교 — Datadog vs New Relic vs Dynatrace

상용 APM(Application Performance Monitoring) 시장의 3강은 여전히 같다.

항목	Datadog	New Relic	Dynatrace
강점	통합 폭, UX	가격, AI-aware	AI(Davis), 자동 감지
비용	호스트당 35-70 USD	GB당 0.30 USD (체감)	단위가 복잡 (DPS)
OTel 지원	1급 시민	1급 시민	1급 시민
자동 계측	매우 잘됨	매우 잘됨	가장 잘됨 (OneAgent)
K8s	강함	강함	강함
AI 분석	Bits AI	New Relic AI	Davis AI (원조)

기타 옵션:

AppDynamics (Cisco/Splunk) — 엔터프라이즈
Elastic Observability — Elastic Stack 통합
Splunk Observability (구 SignalFx) — Splunk Cloud 통합
Honeycomb — 이벤트 기반 옵저버빌리티의 prestige 브랜드
Logz.io / Sumo Logic — SaaS ELK/통합

2026년의 트렌드 — "Datadog 한 벤더 lock-in"에서 "Grafana LGTM 자가호스팅 + Datadog/New Relic을 일부 영역에" 하이브리드로 옮겨가는 회사가 늘고 있다. 비용 압박이 그 주된 이유다.

11. K8s 옵저버빌리티 — Operator, k9s, Lens

쿠버네티스 옵저버빌리티는 별도 카테고리로 다뤄질 정도로 풍부하다.

Prometheus Operator — Prometheus를 K8s 네이티브로 운영. ServiceMonitor, PodMonitor CRD
kube-prometheus-stack — Helm 차트 통합 (Prometheus + Grafana + Alertmanager + node-exporter)
kube-state-metrics — K8s 리소스 상태를 Prometheus 메트릭으로 노출
node-exporter — 노드 시스템 메트릭
k9s — 터미널 K8s 클라이언트의 끝판왕
Lens / OpenLens — GUI K8s IDE
k0s, k0sctl — 경량 K8s 디스트리뷰션
Cilium + Hubble + OTel + Pixie — eBPF 풀스택

# Prometheus Operator의 ServiceMonitor 예시
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
    - port: metrics
      interval: 30s

12. 서비스 메시와 옵저버빌리티

서비스 메시는 사이드카가 모든 트래픽을 가로채기 때문에 본질적으로 트레이스/메트릭 자동 생성기다.

Istio + Kiali — Kiali는 Istio 서비스 메시 토폴로지 시각화의 표준
Linkerd dashboard — 단순함이 강점. CNCF Graduated
Consul Connect + Consul UI — HashiCorp 스택
Cilium Service Mesh — eBPF 기반의 사이드카 없는 메시
Envoy Admin — 모든 메시의 데이터플레인. /stats 엔드포인트로 1000+ 메트릭

사이드카 없는 메시 — Istio Ambient Mode와 Cilium Service Mesh가 2024-2025년에 GA가 되면서 "노드 레벨 데이터플레인"이 표준이 됐다. 옵저버빌리티 관점에서는 사이드카가 사라져도 같은 데이터를 얻을 수 있다는 점이 핵심.

13. DevSecOps와 옵저버빌리티의 통합

런타임 보안과 옵저버빌리티는 같은 데이터를 보지만 다른 질문을 한다.

Falco — eBPF/syscall 기반 런타임 보안 (CNCF Graduated)
Tetragon — Cilium의 보안 자매 프로젝트
OPA / Gatekeeper — 정책 엔진
Kubescape — K8s 보안 스캐너 (CNCF Incubating)
Cloud SIEM — Datadog Cloud SIEM, Elastic Security, Sumo Logic Cloud SIEM
CrowdStrike Falcon / Wiz / Lacework — CSPM/CNAPP 상용

# Falco 규칙 예: 컨테이너 안에서 셸이 떴을 때 알람
- rule: Terminal shell in container
  desc: A shell was used as the entrypoint/exec point in a container
  condition: spawned_process and container and shell_procs
  output: "A shell was spawned in a container (user=%user.name container=%container.id)"
  priority: WARNING

14. 스토리지 백엔드 — VictoriaMetrics, Mimir, ClickHouse, MinIO

옵저버빌리티 데이터의 양은 폭발적이다. 어디에 얼마나 오래 저장할지가 핵심.

VictoriaMetrics — 메트릭 장기 저장. 매우 높은 압축률
Grafana Mimir — Prometheus 메트릭의 분산 백엔드. S3 우선
Grafana Loki — 로그. S3 우선
Grafana Tempo — 트레이스. S3 우선
ClickHouse — 컬럼 스토어. 로그/트레이스 백엔드로 빠르게 채택 (SigNoz, OpenObserve, Cloudflare)
MinIO — S3 호환 오브젝트 스토리지. 자가 호스팅 옵저버빌리티의 표준 백엔드
AWS S3 / GCS / Azure Blob — 클라우드 옵션

저장 기간 가이드라인:

데이터 종류	핫(Hot)	웜(Warm)	콜드(Cold)
메트릭	15일	90일	13개월+
로그	7일	30일	1년+ (S3 IA)
트레이스	3-7일	30일	90일+
프로파일	7일	30일	보통 폐기

15. 비용 모델 — SaaS vs Self-Host

옵저버빌리티 비용은 보통 인프라 비용의 5-15%를 먹는다. 큰 규모에서는 30%까지 가는 경우도 흔하다.

SaaS 가격 (2026년 기준 공시가):

Datadog APM: 호스트당 약 35-70 USD/월, 커스텀 메트릭은 별도
New Relic: 사용자당 99 USD/월 + 데이터 GB당 0.30 USD 체감 (실제 모델은 더 복잡)
Dynatrace: DPS(Davis Platform Subscription) 단위, 보통 호스트당 80-200 USD/월
Honeycomb: 이벤트 양 기반, 무료 티어 후 GB당 가격
Grafana Cloud Pro: 사용량 기반, 무료 티어 후 메트릭 시리즈/로그 GB로 부과

자가호스팅 LGTM 비용 (대략):

100 호스트 / 일 1TB 로그 / 일 100GB 트레이스 가정시:

컴퓨트: K8s 노드 10대 약 3,000 USD/월
S3 스토리지: 약 500-800 USD/월 (1년치 보관)
운영 인건비: 0.5 FTE 이상 (가장 큰 숨은 비용)

결론 — 50 호스트 이하는 SaaS가 거의 항상 싸다. 200 호스트 이상은 자가호스팅이 거의 항상 싸다. 그 사이는 회사 사정에 따라 갈린다. 비용 압박이 심한 한국·일본 회사들은 이 임계점을 빠르게 넘어 자가호스팅으로 가는 추세다.

16. 한국 기업 사례 — NCsoft, Coupang, Naver, Kakao

한국 빅테크의 옵저버빌리티 도입은 2020년경 Datadog 도입기를 거쳐 2024년 이후 점진적 자가호스팅 회귀로 옮겨가는 패턴이 보인다.

NCsoft — Pixie와 eBPF 도입 사례를 KubeCon에서 발표(2023). 게임 백엔드의 마이크로서비스 트레이스에 활용
Coupang — Datadog 대규모 사용자. APM과 인프라 모니터링 통합
Naver — OpenTelemetry 도입. 자체 메트릭/트레이스 백엔드 구축 사례를 DEVIEW에서 공유
Kakao — Grafana 스택 자가호스팅. 메시저 백엔드의 메트릭 가시성에 활용
배달의민족(우아한형제들) — Datadog + 자가호스팅 Grafana 하이브리드
카카오뱅크/토스 — 금융 규제 때문에 자가호스팅 비중이 높다. ELK + Grafana
당근마켓 — Datadog APM + Sentry 조합
라인플러스(한국) — OpenTelemetry + Grafana

공통 패턴 — 한국 회사들은 (1) 초기 빠른 가시성은 Datadog/New Relic으로 시작, (2) 비용이 일정 임계를 넘으면 LGTM 스택으로 옮기되 RUM/Sentry는 남기는 하이브리드 패턴이 흔하다.

17. 일본 기업 사례 — Mercari, LINE Yahoo, CyberAgent

일본 시장은 한국보다 OpenTelemetry와 eBPF 채택이 한 발 앞서 있다는 평가가 있다.

Mercari — Datadog 메이저 유저. OTel 마이그레이션을 SRECon 2024에서 발표
LINE Yahoo — 합병 후 OpenTelemetry 표준화 가속. 자체 메트릭 백엔드
CyberAgent — Cilium 대규모 도입. KubeCon에서 eBPF 발표 다수
DeNA — Datadog + Grafana 하이브리드
Rakuten — Splunk 대규모 사용자. APM은 New Relic
PayPay — AWS 네이티브 옵저버빌리티 + Datadog
Smartbank / Kyash — 핀테크 스타트업의 OTel 도입 사례
메루카리 ML팀 — Pyroscope/Parca로 머신러닝 워크로드 프로파일링

일본 SRE 문화 — Mercari, CyberAgent를 중심으로 한 SRE 커뮤니티(SRE Lounge, SRE NEXT 컨퍼런스)가 옵저버빌리티 베스트 프랙티스 전파에 큰 역할을 한다. 한국보다 한 박자 빠른 OTel 채택의 배경.

18. SLO/SLI와 에러 버짓 운영

옵저버빌리티의 끝은 **SLO(Service Level Objective)**다. "p99 응답시간이 200ms 이하이고, 가용성은 99.9%다"를 정의하고, 그걸 메트릭으로 모니터링하고, 어겼을 때 에러 버짓을 소진하는 모델이다.

도구:

Sloth — Prometheus 기반 SLO 생성기. YAML로 SLO 정의
Pyrra — Sloth와 비슷한 카테고리의 SLO 컨트롤러
OpenSLO — SLO 정의의 YAML 표준
Nobl9 — SLO 전문 SaaS
Datadog SLO / Honeycomb SLO — APM 내장 옵션

# Sloth SLO 정의 예
version: prometheus/v1
service: my-api
slos:
  - name: requests-availability
    objective: 99.9
    sli:
      events:
        error_query: sum(rate(http_requests_total{code=~"5.."}[5m]))
        total_query: sum(rate(http_requests_total[5m]))
    alerting:
      page_alert:
        labels:
          severity: page
      ticket_alert:
        labels:
          severity: ticket

19. 알림과 인시던트 관리

옵저버빌리티의 마지막 단계는 알림과 인시던트 대응이다.

Alertmanager — Prometheus 생태계 표준
Grafana Alerting — Grafana 통합 옵션 (멀티 데이터소스 지원)
PagerDuty — 인시던트 관리의 SaaS 표준
Opsgenie (Atlassian) — PagerDuty의 경쟁자
Incident.io — 채팅 우선의 신세대 인시던트 관리. Slack 통합 강력
FireHydrant, Rootly — 인시던트 관리 신생 SaaS
Better Stack — Uptime 모니터링 + 인시던트 관리 통합

2026년의 흐름 — Slack/Teams가 인시던트 룸의 표준이 됐고, Incident.io 같은 도구는 그 위에서 자동으로 채널을 생성하고, 상태 페이지를 업데이트하고, 포스트모템을 시작한다. PagerDuty도 이 방향으로 빠르게 진화 중.

20. AI-native 옵저버빌리티의 윤곽

2026년의 가장 큰 화두는 AI가 옵저버빌리티를 어떻게 바꿀 것인가다.

자동 근본 원인 분석(RCA) — Dynatrace Davis, New Relic AI, Datadog Bits AI
자연어 쿼리 — Honeycomb Query Assistant, Grafana LLM, Datadog AI Assistant
이상 탐지 자동화 — 모든 메이저 APM이 ML 기반 anomaly detection 제공
LLM 옵저버빌리티 자체 — LangSmith, Helicone, Phoenix, Arize, OpenLLMetry. LLM 응답의 latency/cost/quality를 트레이스
에이전트 트레이싱 — OTel의 GenAI semantic conventions가 2025년 발표. Agent 도구 호출의 트레이스 표준

AI 워크로드의 옵저버빌리티 — LLM은 비결정적이고 비쌌다. "이 사용자 요청이 GPT-4o로 갔는지 Claude 3.5로 갔는지, 토큰을 얼마나 썼는지, 누가 쿼리를 캐싱했는지"가 새로운 골든 시그널이 되고 있다.

21. 도입 로드맵 — 어디서 시작할 것인가

옵저버빌리티 스택을 새로 짠다면, 2026년 기준 추천 순서는 다음과 같다.

메트릭 먼저 — Prometheus + Grafana로 시작. node-exporter, kube-state-metrics
로그를 표준화 — Loki 또는 Elastic. Vector/Fluent Bit으로 수집 통일
트레이스 도입 — Tempo + OTel Collector. 자동 계측부터
eBPF로 가시성 80% 채우기 — Cilium Hubble 또는 Pixie 둘 중 하나
continuous profiling 추가 — Pyroscope를 Grafana에 통합
SLO 정의 — Sloth로 핵심 서비스 3-5개의 SLO를 YAML로
AI/LLM 트레이싱 — LLM 사용한다면 LangSmith 또는 Phoenix를 OTel과 함께
인시던트 관리 자동화 — Incident.io 또는 PagerDuty를 Slack에 통합

스타트업 (1-20명):

SaaS 풀 활용 — Datadog 또는 New Relic + Sentry + Better Stack
학습 곡선을 사지 말고 코드를 짜자

중규모 (20-200명):

Grafana Cloud + Sentry + Incident.io
비용을 보면서 LGTM 자가호스팅으로 점진 이전

대규모 (200명+):

LGTM 자가호스팅 + 일부 영역(RUM, APM)만 SaaS
전담 옵저버빌리티 플랫폼 팀