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

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

"프로덕션이 죽었다"는 말은 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가 대중화시킴).

측정 가능한 차이.

Monitoring: "CPU가 90%인가?" (미리 정한 질문)
Observability: "지금 p99 레이턴시가 튄 요청들은 어떤 customer_id에서 오는가, 어떤 feature flag가 켜져 있는가, 어떤 build에서 터지는가?" (현장에서 만들어지는 질문)

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

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

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

2.1 Metrics — 숫자의 시계열

가장 쌈, 집계가 됨, cardinality 낮게 유지 필수
Prometheus가 사실상 de facto, PromQL이 쿼리 표준
Counter, Gauge, Histogram (특히 히스토그램의 bucket 설계가 p99 신뢰성을 만든다)
OpenTelemetry Metrics가 OTLP로 Prometheus를 감싸는 흐름

2.2 Logs — 이벤트의 문자열

가장 유연, 가장 비쌈(인덱싱 비용)
구조화 로그(JSON)가 필수, 비구조화 로그는 검색이 O(n) + grep
Grafana Loki가 "label만 인덱싱, body는 objstore"로 비용 혁신
Vector / Fluent Bit / OTel Collector가 pipeline
level, service, env, trace_id, span_id 상관관계 키 꼭 넣기

2.3 Traces — 요청의 생애

분산 트레이싱. 한 요청이 여러 서비스를 거치는 인과 체인
W3C Trace Context 헤더(traceparent, tracestate)가 표준
Jaeger, Zipkin → Grafana Tempo, Datadog APM, Honeycomb으로 중심 이동
Tail-based sampling이 2024년 대세 — 흥미로운 trace(에러/느림)만 저장해 비용 절감

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

2023~2024 급부상. eBPF로 프로세스·커널 스택을 상시(continuous) 샘플링
Parca, Grafana Pyroscope, Polar Signals, Google Cloud Profiler, Datadog Continuous Profiler
flame graph가 기본 시각화
OpenTelemetry Profiling signal이 2024년 stable 예정

3부. OpenTelemetry — 2025년의 표준

3.1 왜 OTel이 이겼나

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

Spec이 세 시그널(메트릭·로그·트레이스) 모두 stable
언어 SDK: Java·Go·Python·Node·.NET·Rust·C++ 모두 production-ready
Instrumentation 라이브러리 수백 개(express, gin, FastAPI, django, Spring, gRPC, kafka-clients...)
Collector가 vendor-neutral pipeline 허브로 자리잡음
모든 주요 벤더(Datadog, New Relic, Dynatrace, Honeycomb, Grafana)가 OTLP 수신 지원

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

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)

Java -javaagent:opentelemetry-javaagent.jar 붙이면 Spring·gRPC·JDBC 자동 trace
Node: --require @opentelemetry/auto-instrumentations-node/register
eBPF 기반 auto-instrumentation(Grafana Beyla, Odigos, Pixie, Coroot): 코드 수정 없이 HTTP/DB 호출을 추적
이게 혁명인 이유 — 레거시 서비스에도 trace가 생긴다

3.4 Semantic Conventions

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

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

4.1 왜 eBPF가 관측에 맞는가

커널 공간에서 안전하게 실행 → 프로덕션 부하에서 오버헤드 1~3%
애플리케이션 수정 없음 → 모든 프로세스 통째 관측
CPU profile, 네트워크 flow, syscall trace, DNS query 모두 잡힘

4.2 Continuous Profiling 스택

Parca (Polar Signals 오픈소스) — pprof 호환 프로파일을 상시 수집
Grafana Pyroscope (Pixie 기반 인수 합병) — flame graph UI가 뛰어남
Polar Signals Cloud — Parca SaaS
Datadog Continuous Profiler — 자체 eBPF agent
업계 표준 형식: pprof, OTel Profiling 시그널

4.3 네트워크 관측

Cilium Hubble — CNI 통합 flow 관측
Inspektor Gadget — 커널 이벤트 실시간
Pixie — 무에이전트 K8s 관측 (kube-state-metrics 없이도 Pod/Service RPS 잡힘)

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)가 합쳐져 오픈소스 단일 생태계.

Mimir: Prometheus 호환, 10억 series까지 수평 확장
Loki: label만 인덱싱, S3/GCS에 log body 저장. 인덱싱 비용 1/10
Tempo: S3 기반 trace 저장소, trace_id 조회에 최적화
Pyroscope: flame graph 기반, pprof 호환
Grafana: 한 UI에서 네 시그널 상관관계(Explore → Logs → Trace → Profile 원 클릭)

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

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

6.1 Datadog

가장 통합적(인프라+APM+로그+RUM+Security+LLM)
가격이 기하급수적으로 비쌈(2024년 일부 고객 연 수천만 달러 사례)
Watchdog(AI 이상 탐지), DBM(Database Monitoring), APM Live Search가 차별점

6.2 Honeycomb

BubbleUp — p99가 튄 trace들을 자동 클러스터링해 공통 attribute 찾기
고카디널리티 쿼리가 핵심 강점
Charity Majors의 "observability-driven development" 철학

6.3 New Relic / Dynatrace / Splunk

전통 APM 강자, 엔터프라이즈 계약 많음
Dynatrace OneAgent는 자동 계측 완성도 높음
Splunk Observability Cloud(구 SignalFx)는 메트릭 처리 강함

6.4 Sentry

에러 추적 원조, 최근 Performance Monitoring 확장
Frontend RUM 특히 강함, Release 단위 회귀 자동 감지
Spotlight(로컬 개발용), Session Replay가 특색

6.5 Coroot, Odigos, SigNoz, Highlight

오픈소스·작은 팀 친화 신흥 주자들
eBPF 기반 zero-instrumentation 철학

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

7.1 Head-based vs Tail-based 샘플링

Head: 진입 시점에서 5% 확률로 결정 → 단순, 싸지만 에러 trace를 놓침
Tail: 전체를 일단 모은 뒤 policy로 필터(에러/느림/VIP user) → 놓치지 않지만 Collector 메모리·상태 관리 복잡

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

7.2 Context Propagation 실패 시나리오

async job queue에서 traceparent 헤더 누락 → trace 끊김
서드파티 SDK가 OTel을 모름 → span 분리
HTTP 1.1/2, gRPC, Kafka, RabbitMQ 각자 propagation 방식. 확인 필수

7.3 Span Attribute 설계 지침

고카디널리티(user.id, tenant.id)는 속성으로 — 집계로 가지 않도록
PII(email, 이름, 카드번호)는 절대 금지
비즈니스 식별자(order.id, payment.id) 넣기
Error kind, retry count, circuit breaker state 등 실패 분석 가능한 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 로그 비용 통제

Sampling은 로그에서도 유효(DEBUG/INFO 샘플링 5%, WARN/ERROR 100%)
로그 → 메트릭 변환(에러 카운트 등)
Loki 같은 "body 인덱싱 안 함" 설계 고려
로그 레벨 정책을 팀 규율로 문서화 — info 남발이 비용 폭발 주범

8.3 민감정보와 PII

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

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

9.1 SLI (Service Level Indicator)

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

Availability: 2xx+3xx 비율
Latency: p99 또는 specific-threshold 비율(예: 500ms 미만 비율)
Quality: data freshness, correctness
Throughput: 처리 속도

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

9.2 SLO (Objective)

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

Availability SLO 99.9% = 월 43분 허용 다운타임
99.99% = 월 4.3분 — **정말 필요한가?**를 묻는 질문
너무 높으면 혁신 속도가 죽음, 너무 낮으면 사용자 이탈

9.3 Error Budget

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

9.4 Multi-window multi-burn alerts

너무 일찍 알람 → 알람 피로
너무 늦게 알람 → 예산 소진 후 대응 불가
2019년 Google SRE 워크북이 제안한 multi-burn(고속+저속 윈도우 복합)이 표준이 됨

9.5 User Journey SLO

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

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

10.1 좋은 알람의 조건

Actionable — 깨어나서 할 수 있는 행동이 있어야
Symptom-based — 원인이 아니라 증상(사용자 영향)에서
Unique — 같은 장애에 10번 울리면 하나로 통합
Runbook — 알람마다 대응 가이드 링크

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

주간·야간·주말 로테이션
Follow-the-sun (지역 분산 팀일 때)
보상: 야간 호출에 대한 금전적 또는 휴가 보상이 문화 성숙도의 척도
2024년 Grafana가 인수한 Grafana Oncall이 오픈소스 대안으로 부상

10.3 Alert Fatigue

주간 50건 이상 → 대응력 붕괴
월간 알람 리뷰 의식: "쓸모 있었는가, 삭제/통합할 수 있는가"
P1/P2/P3 단계화, P3 이하는 Slack 채널에만

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

11.1 포스트모템의 목적

같은 장애를 두 번 겪지 않는 것
개인 처벌이 아니라 시스템 개선
Etsy·Google SRE·GitLab이 공개한 템플릿이 표준

11.2 구조

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

11.3 Retrospective Antipattern

"사람이 실수함"에서 멈추기 → 시스템이 실수를 허용한 이유를 파라
액션 아이템이 추상적("프로세스 개선") → 구체화
배포 후 리뷰 미실행 → 30일 뒤 액션 아이템 상태 확인 필수

12부. AIOps와 LLM for Observability

12.1 이상 탐지

Datadog Watchdog, New Relic AI, Dynatrace Davis — seasonality 학습 기반
2024~2025 LLM 도입: 자연어로 쿼리("지난 24시간 checkout 에러 급증 원인"), root cause 요약
Grafana LLM app, Honeycomb BubbleUp AI

12.2 RCA (Root Cause Analysis) 자동화

Trace topology + metric anomaly를 입력으로 LLM이 가설 제시
아직 "정답"이 아니라 초동 힌트 수준이지만, 온콜 초동 대응 시간 30~50% 단축 사례

12.3 Incident Commander AI

OpsGenie/PagerDuty의 AI는 장애 초기 Slack 요약을 자동 작성
타임라인 수집·관련 인원 호출·릴리즈 윈도우 확인 자동

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

13.1 단계별 로드맵

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

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

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

10명 미만: Sentry + Grafana Cloud free + Axiom — 월 $100
100명 미만: Grafana Cloud + Sentry 또는 Datadog 스타터 — 월 수천~수만 달러
1000명 이상: 자체 LGTM + Datadog/Honeycomb 병용, 전담 Observability 팀

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

Datadog·Splunk가 월별 계약서 3페이지인 이유는 dimension·host·log·custom metric마다 다른 요금
Host-based vs Usage-based 계약
cardinality 한 단어 잘못 넣으면 일주일 만에 청구서 3배
FinOps 팀과 연동: 월별 벤더 비용 트렌드, 서비스별 "관측 비용 per request"

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

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

✅ 체크리스트 12

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

⚠️ 안티패턴 10

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

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

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

Internal Developer Platform (IDP) 왜 필요한가
Backstage — Spotify가 만들고 CNCF에 기부한 포털 표준
GitOps — ArgoCD, Flux, Crossplane
Kubernetes Operator 패턴 — CRD와 컨트롤러
Golden Paths, Scorecards — 팀 자율성과 표준의 균형
Score, Humanitec, Kratix — 플랫폼 abstraction의 새 물결
Dagger, Nix, Bazel — 재현 가능한 빌드
Remote Dev Environment — GitHub Codespaces, Gitpod, Coder
Developer Experience 지표 — DORA 4 metrics, DX Survey, SPACE framework

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