LabHub

블로그

관측가능성의 현대 — OpenTelemetry·eBPF Continuous Profiling·LGTM·Pyroscope·Sentry·Datadog·Honeycomb·SLO·SRE·온콜 심층 가이드 (2025)

2026-04-15 · 21 분 읽기 · #observability#opentelemetry#ebpf#profiling#slo#sre#datadog#honeycomb#grafana#oncall

관측가능성은 왜 이제 "팀 역량"이 아니라 "조직 역량"인가

"프로덕션이 죽었다"는 말은 2025년 더 이상 단일 서비스의 장애가 아니다. 수십 개 마이크로서비스, 수백 개 컨테이너, 수천 개의 함수 호출, 여러 클러스터·여러 리전·여러 클라우드가 걸린 분산 상태다. 장애의 근원이 당신의 코드가 아닐 가능성이 70%다 — CDN, 서드파티 API, DNS, NIC queue, noisy neighbor, Kubernetes scheduler, Kernel bug, JVM GC pause, 심지어 AWS 리전 전체. 증상은 한 서비스에 나타나지만, 원인은 다른 어딘가에 있다. 그래서 관측가능성은 이제 한 엔지니어의 도구 세트가 아니라 조직의 엔지니어링 문화의 바닥이 됐다.

Gartner는 2025년 디지털 네이티브 기업의 70%가 관측가능성에 연 매출의 1~3%를 쓴다고 추정한다. Datadog은 2024년 ARR 28억 달러로 매년 30%+ 성장. Grafana Labs는 10억 달러 평가. Honeycomb·New Relic·Sentry·Splunk가 경쟁. 오픈소스 진영도 폭발했다 — OpenTelemetry는 CNCF에서 Kubernetes 다음으로 많은 커밋을 기록하고, eBPF 기반 Parca/Pyroscope/Polar Signals가 "continuous profiling"이라는 새 축을 만들었다. 이 글은 그 2025년의 관측가능성 전부를 훑는다.

이 글은 앞선 Computer Architecture 심층 가이드의 자연스러운 연속이다. CPU와 메모리가 어떻게 움직이는지를 알았다면, 이제는 "그것이 지금 어떻게 움직이고 있는지를 실시간으로 관측"해야 한다.

1부. Monitoring과 Observability의 차이 — 진지하게

2010년대까지 사람들이 하던 건 Monitoring이었다. 미리 예상 가능한 실패 모드(디스크 80% 참, CPU 90%, 5xx 비율)에 대시보드·알람을 걸어놓는 방식. 서비스가 수십 개였을 때는 가능했지만, 현재의 시스템은 "예상 가능한 실패"가 아닌 unknown unknowns로 가득하다. 처음 보는 실패 모드, 처음 보는 요청 경로. 이때 필요한 건 질문 가능성 — 새로운 질문을 즉석에서 던질 수 있는 능력이다. 이게 Observability의 정의(Honeycomb의 Charity Majors가 대중화시킴).

측정 가능한 차이.

이 차이가 Cardinality 폭발을 다루는 능력을 결정한다. 전통적 TSDB는 label 차원 수에 약하지만, columnar 저장소 기반 도구(Honeycomb, ClickHouse 기반 Grafana Pyroscope, Datadog의 후드 내부)는 수백만 고유 값도 쿼리한다.

2부. Four Pillars — 메트릭·로그·트레이스·프로파일

Three Pillars(Metric/Log/Trace)에 Profile이 추가된 게 2023년 이후 업계 합의다.

2.1 Metrics — 숫자의 시계열

2.2 Logs — 이벤트의 문자열

2.3 Traces — 요청의 생애

2.4 Profiles — 코드 단위의 CPU/메모리 비용

3부. OpenTelemetry — 2025년의 표준

3.1 왜 OTel이 이겼나

2019년 OpenCensus(Google) + OpenTracing(Uber/Lightstep)이 합쳐져 출범. 2024년 말 기준:

다시 말해 "벤더 락인 없이 계측을 표준화"라는 오래된 꿈이 현실이 됐다.

3.2 OTel Collector

receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  batch:
  tail_sampling:
    policies:
      - name: errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow
        type: latency
        latency: { threshold_ms: 1000 }
      - name: probabilistic
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }
exporters:
  otlphttp/datadog:
    endpoint: https://api.datadoghq.com
  prometheusremotewrite:
    endpoint: https://mimir.example.com/api/v1/push
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, tail_sampling]
      exporters: [otlphttp/datadog]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheusremotewrite]

Collector 덕분에 벤더 전환이 설정 변경 수준이 됐다.

3.3 자동 계측(auto-instrumentation)

3.4 Semantic Conventions

http.route, db.system, messaging.kafka.destination.name 같은 키 이름을 명세로 고정. 벤더 간 상호 운영이 되고, 대시보드/알람이 이식 가능해짐.

4부. eBPF — 관측가능성의 게임 체인저

4.1 왜 eBPF가 관측에 맞는가

4.2 Continuous Profiling 스택

4.3 네트워크 관측

4.4 Golden Signals을 eBPF로 자동 수집

Beyla/Coroot/Odigos: "코드 한 줄 안 건드리고 RED 메트릭(Rate/Errors/Duration)을 서비스별로" 뽑는 시대. 2024~2025 DevOps 현장에서 가장 도입 쉬운 관측 방법.

5부. LGTM 스택 — Grafana Labs의 레퍼런스

Loki (logs) + Grafana (UI) + Tempo (traces) + Mimir (metrics) = LGTM. 여기에 Pyroscope(profile)과 Alloy(agent, OTel Collector distro)가 합쳐져 오픈소스 단일 생태계.

이 스택의 매력은 "자체 호스팅 가능, S3만 있으면 된다"는 운영 단순성.

6부. 상용 SaaS들 — 언제 어떤 걸 쓰는가

6.1 Datadog

6.2 Honeycomb

6.3 New Relic / Dynatrace / Splunk

6.4 Sentry

6.5 Coroot, Odigos, SigNoz, Highlight

7부. Tracing 실전 — 샘플링·Context·Cardinality

7.1 Head-based vs Tail-based 샘플링

현대 설계는 계층형 — edge에서 head-based로 필터링 + Collector에서 tail-based로 가치 필터링.

7.2 Context Propagation 실패 시나리오

7.3 Span Attribute 설계 지침

8부. 로그의 현대화 — 구조화·집계·비용

8.1 구조화 로그

{
  "ts": "2026-04-15T10:30:00Z",
  "level": "error",
  "service": "payments",
  "env": "prod",
  "trace_id": "a4b...",
  "span_id": "7e1...",
  "msg": "charge failed",
  "error_kind": "stripe_timeout",
  "order_id": "o_12345",
  "user_id": "u_6789",
  "build": "c1f2..."
}

필드 이름은 OTel Semantic Conventions을 따라야 상관관계가 자동.

8.2 로그 비용 통제

8.3 민감정보와 PII

자동 마스킹 필수. OTel Collector attributes processor로 패턴 기반 스크러빙. GDPR/HIPAA 대응에서 감사 필수 항목.

9부. SLI · SLO · Error Budget — SRE Book 이후 10년

9.1 SLI (Service Level Indicator)

측정 가능한 신뢰성 지표. 대표 4종.

"Good events / Total events"로 비율화하는 게 핵심.

9.2 SLO (Objective)

SLI의 목표치. 예: "30일 rolling window에서 availability 99.9%"

9.3 Error Budget

"허용 가능한 실패량". 99.9% SLO에서 한 달 예산은 43분. 이걸 다 쓰면 feature freeze, 남으면 배포 가속. 엔지니어링과 프로덕트의 정치를 정량화하는 도구.

9.4 Multi-window multi-burn alerts

9.5 User Journey SLO

단순 서비스 SLO 너머로 "체크아웃 성공률", "검색 후 클릭 전환율" 같은 사용자 여정을 SLO로. Honeycomb·Datadog이 2024~2025 대대적으로 민다.

10부. 알림 설계 — 페이저가 울리는 순간을 존중하라

10.1 좋은 알람의 조건

10.2 On-call 교대와 PagerDuty/Opsgenie/Grafana Oncall

10.3 Alert Fatigue

11부. 포스트모템 — 블레임리스 + 구조화

11.1 포스트모템의 목적

11.2 구조

  1. Summary (1~2문장)
  2. Impact — 사용자 수, 시간, 매출
  3. Timeline (분 단위, UTC)
  4. Root Cause (5 Whys 기법)
  5. Contributing Factors
  6. Action Items — 담당자와 기한 포함, 후속 추적
  7. Lessons Learned

11.3 Retrospective Antipattern

12부. AIOps와 LLM for Observability

12.1 이상 탐지

12.2 RCA (Root Cause Analysis) 자동화

12.3 Incident Commander AI

13부. 프로덕션에 도입하는 6단계

13.1 단계별 로드맵

  1. Baseline 메트릭 — RED(Rate/Errors/Duration), USE(Utilization/Saturation/Errors) 대시보드
  2. 구조화 로그 + trace_id 상관관계
  3. OTel auto-instrumentation 배포 (자바는 javaagent, Node/Python은 auto-init)
  4. Tail-based sampling Collector 도입
  5. eBPF continuous profile 상시 수집
  6. SLO 정의 + Error budget 알람

각 단계에서 비용·알람 피로·cardinality를 측정하며 진행. 한번에 다 하려다 망한 팀 수백.

13.2 스타트업 ~ 중견기업 ~ 엔터프라이즈 가이드

14부. 비용의 현실 — 무시할 수 없는 축

실전 팁: 알람·대시보드·쿼리마다 "얼마 드는가" 표시하는 내부 툴 만들기(Grafana Labs가 "ObservaCost"로 시도).

15부. 체크리스트 12 · 안티패턴 10

✅ 체크리스트 12

  1. 모든 서비스에 OTel auto-instrumentation이 붙어 있는가?
  2. 구조화 로그가 trace_id, span_id를 포함하는가?
  3. Tail-based sampling policy가 에러·slow trace를 반드시 잡는가?
  4. SLO가 팀당 3~5개 이하로 명문화되고, Error Budget 알람이 작동하는가?
  5. 알람은 symptom-based이고 runbook 링크가 붙어 있는가?
  6. 핫 서비스에 eBPF continuous profile이 붙어 있는가?
  7. Cardinality explosion 모니터가 있는가? (label 수 상한)
  8. 로그·메트릭·trace·profile 간 원 클릭 이동이 되는가?
  9. 온콜 로테이션이 공평·보상·교대 주기 규정이 있는가?
  10. 포스트모템이 블레임리스·구조화된 템플릿을 쓰는가?
  11. PII 마스킹이 Collector 레벨에 적용되어 있는가?
  12. 관측 비용이 서비스별 per-request로 배분되고 FinOps에 보고되는가?

⚠️ 안티패턴 10

  1. print/console.log로 디버깅하며 Production에 그대로 둠
  2. 비구조화 로그(grep 기반)로 대응
  3. 모든 요청 100% trace 수집 후 비용 폭발
  4. PII를 span attribute에 그대로 박기
  5. SLO가 없거나, 있어도 Error Budget이 예산으로 안 쓰임
  6. 알람이 노이즈 → on-call이 알림을 자동 dismiss
  7. 포스트모템에서 "주의하겠습니다"로 끝남(개인 탓)
  8. 자동 계측 없이 수동으로 모든 span 박기
  9. 컨테이너 재시작 시 최근 로그 유실
  10. LLM을 이상 탐지에 맹신(hallucination root cause)

다음 글 예고 — "플랫폼 엔지니어링과 Developer Experience" — Backstage·IDP·GitOps·K8s Operator·Scorecards·Score·Dagger·Nix·Remote Dev Env

관측가능성을 갖췄다면, 이제는 엔지니어들이 그 관측을 자기 서비스에 쉽게 붙일 수 있어야 한다. 다음 글은 플랫폼 엔지니어링의 2025년이다.

엔지니어가 코드를 잘 짜는 것에서, 조직이 코드를 잘 굴리는 것으로 — 스택의 가장 높은 층으로 올라간다.

원문 보기: https://www.youngju.dev/blog/culture/2026-04-15-observability-opentelemetry-ebpf-profiling-lgtm-slo-sre-datadog-honeycomb-oncall-deep-dive-guide-2025

댓글

아직 댓글이 없습니다.

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