LabHub

블로그

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

2026-05-16 · 34 분 읽기 · #observability#ebpf#cilium-hubble#pixie#pyroscope#loki#tempo#netdata#opentelemetry#monitoring

한국어English日本語

프롤로그 — 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년의 차이를 만드는 건 도구가 아니라 이 질문을 던질 수 있게 만드는 스택 설계다.

다루는 것:

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

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

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

여기에 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가 바꾼 것:

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

대표 도구:

# 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-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 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의 차이:

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

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

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

# 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 일반론:

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

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

# 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% 오버헤드로 잡는다.

대표 사용 사례:

# 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 예시: 모든 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):

합성 모니터링(Synthetic Monitoring):

// 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강은 여전히 같다.

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

기타 옵션:

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

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

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

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

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

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

# 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

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

저장 기간 가이드라인:

데이터 종류핫(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년 기준 공시가):

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

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

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

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

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

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

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

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

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

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

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

도구:

# 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. 알림과 인시던트 관리

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

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

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

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

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

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

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

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

스타트업 (1-20명):

중규모 (20-200명):

대규모 (200명+):

22. 참고 문헌

원문 보기: https://www.youngju.dev/blog/culture/2026-05-16-network-service-observability-2026-ebpf-cilium-hubble-pixie-pyroscope-grafana-loki-tempo-netdata-deep-dive

댓글

아직 댓글이 없습니다.

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