들어가며 — Observability vs Monitoring

**Monitoring**: 알려진 문제 감지. "CPU > 80%면 알림."

**Observability**: 모르는 문제 탐구. "왜 갑자기 P99가 3배로?"

9개의 블랙박스를 뜯는 도구

2025년 엔지니어의 운영 필수 역량:

- 분산 트레이싱으로 요청 흐름 추적

- 프로파일로 CPU·메모리 병목 발견

- eBPF로 커널 레벨 진단

- SLO/Error Budget으로 릴리스 속도 결정

- Log·Metric 비용을 통제하면서 품질 유지

이 글은 Observability의 **기본·실전·비용·조직** 네 레이어를 한 번에 다룬다.

1부 — 3축 + 프로파일 = 4축 관측성

1.1 Metric

**숫자 시계열** — 집계·장기 보관·알림 용이.

- 예: `http_requests_total{status="200",method="GET"}`

- 도구: Prometheus, VictoriaMetrics, Mimir, Cortex

- 장점: 저장 효율, 대시보드 빠름

- 단점: 카디널리티 폭증 위험 (labels 많으면 비용↑↑)

1.2 Log

**이벤트 스트림** — 상세하지만 크다.

- 구조화 로깅이 필수 (JSON)

- 도구: Loki, Elasticsearch, OpenSearch, Quickwit, ClickHouse

- 장점: 상세·유연

- 단점: 비용 비쌈, 검색 느림

1.3 Trace

**요청의 인과 사슬** — 분산 시스템 디버깅 핵심.

- 개념: Span (작업 단위) + Context Propagation

- 도구: Jaeger, Tempo, Zipkin, Honeycomb

- 장점: 어느 서비스가 병목인지 한눈에

- 단점: 샘플링 전략이 핵심 (100% 저장 비현실적)

1.4 Profile (4번째 축, 2023~)

**프로세스 내부 CPU·메모리 프로파일** — 지속 저장.

- 도구: Pyroscope (Grafana), Parca, Polar Signals

- 장점: "어느 함수가 CPU 먹는가?" 실시간

- 단점: 오버헤드·스토리지 관리

1.5 4축 통합 시나리오

알림: P99 레이턴시 스파이크

↓

[Metric] 어느 서비스? → checkout-service

↓

[Trace] 어느 span? → payment-gateway 호출 3초

↓

[Log] 해당 trace_id의 로그 → timeout error

↓

[Profile] 해당 시간대 CPU → TLS handshake에 90%

↓

원인: 인증서 만료 임박으로 TLS handshake 증가

**Correlation** 이 핵심. trace_id로 4축을 꿰어야.

2부 — OpenTelemetry: 관측의 표준

2.1 OTEL이 해결한 것

이전: 벤더마다 다른 SDK (Prometheus, Datadog, New Relic...). 벤더 변경 = 코드 재작성.

OTEL: **한 번 계측, 어디든 전송**.

2.2 OTEL 구성 요소

Application

↓ (OTEL SDK)

OTLP Protocol

↓

[OTEL Collector]

├─ Receivers (OTLP, Prometheus, Jaeger...)

├─ Processors (batch, filter, sample, enrich)

└─ Exporters (Tempo, Loki, Prometheus, Datadog, ...)

↓

Backend (where you want)

2.3 Signal (신호) 3가지 + 프로파일

- **Traces**: 안정 (Stable)

- **Metrics**: 안정

- **Logs**: 안정 (2024)

- **Profiles**: 베타 (2024~2025)

2.4 Context Propagation

요청이 A 서비스 → B 서비스 → C 서비스로 흐를 때 **같은 trace_id 전파** 필수:

HTTP Headers:

traceparent: 00-{trace_id}-{span_id}-01

tracestate: ...

W3C Trace Context 표준. OTEL 자동 처리.

2.5 Auto-Instrumentation

- Java: `-javaagent:opentelemetry-javaagent.jar` (바이트코드 조작)

- Python: `opentelemetry-instrument python app.py`

- Node.js: `NODE_OPTIONS="--require @opentelemetry/auto-instrumentations-node/register"`

- Go: SDK 명시적 계측 (reflection 없음)

- Rust: `tracing` crate

2.6 2024~2025 OTEL 진화

- **Profile Signal** 정식화

- **Gen AI Semantic Conventions**: LLM 호출도 표준

- **Exponential Histograms**: 고해상도 메트릭

- **OTEL Collector Contrib**: 수백 개 receiver/exporter

3부 — Prometheus & Grafana Stack

3.1 Grafana Stack (2025 표준 OSS)

| 컴포넌트 | 역할 |

|---------|-----|

| **Prometheus** / **Mimir** | Metric |

| **Loki** | Log |

| **Tempo** | Trace |

| **Pyroscope** | Profile |

| **Grafana** | 대시보드 |

| **Alertmanager** | 알림 |

| **Beyla** | eBPF 기반 auto-instrumentation |

3.2 Prometheus 4가지 메트릭 타입

1. **Counter**: 단조 증가 (요청 수)

2. **Gauge**: 현재값 (메모리 사용)

3. **Histogram**: 버킷화 (레이턴시 분포)

4. **Summary**: 분위수 직접 계산

3.3 PromQL 기본

분당 요청 수

rate(http_requests_total[1m])

서비스별 P99

histogram_quantile(0.99,

sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)

)

에러율

sum(rate(http_requests_total{status=~"5.."}[5m])) /

sum(rate(http_requests_total[5m]))

3.4 카디널리티 관리

**문제**: `{user_id, path, status, method}` → 100만 사용자 × 10 path × 5 status × 4 method = 2억 시계열. 프로메테우스 터짐.

**해결:**

- 높은 카디널리티 label 금지 (user_id, trace_id 등)

- Aggregation 먼저, 저장 나중

- VictoriaMetrics·Mimir로 확장 (Prometheus보다 효율)

4부 — 로그 관리: 비용과 품질의 균형

4.1 로그 비용이 폭주하는 이유

- 디버그 로그를 프로덕션에서 그대로

- JSON 아닌 텍스트 → 검색·집계 어려움

- 전문 검색 엔진(Elastic) 사용 비용

- 로그 보존 기간 과도

4.2 로그 레벨 전략

| 레벨 | 용도 | 보존 |

|-----|-----|-----|

| ERROR | 알림 필요 | 30~90일 |

| WARN | 주의 | 30일 |

| INFO | 주요 이벤트 | 7~30일 |

| DEBUG | 개발만 | 미저장 또는 1일 |

| TRACE | 특수 디버깅 | 미저장 |

4.3 구조화 로깅 (필수)

나쁨

logger.info(f"User {user_id} logged in from {ip}")

좋음

logger.info("user_login", extra={

"user_id": user_id,

"ip": ip,

"trace_id": trace_id,

})

검색·필터·집계가 모두 가능.

4.4 2025 로그 솔루션 비교

| 도구 | 모델 | 특징 |

|-----|-----|-----|

| **Loki** | 저비용, 인덱스 최소 | Grafana Stack 표준 |

| **Elasticsearch** | 전문 검색 | 비용 비쌈 |

| **OpenSearch** | Elastic fork | AWS 친화 |

| **Quickwit** | Rust, 로그 특화 | 새 선택지 |

| **ClickHouse** | 컬럼 DB | Analytics 강함 |

| **Vector.dev** (Datadog) | 수집 파이프라인 | 라우팅·필터 |

5부 — Distributed Tracing 실전

5.1 샘플링 전략 4가지

1. **Head-based (probabilistic)**: 요청 시작 시 N% 결정. 간단. Root-leaf 일관.

2. **Rate-limited**: 초당 X개만

3. **Tail-based**: 전체 받고 **에러·느림만 저장**. 비용·정보 균형

4. **Dynamic**: 문제 감지 시 자동 증가

5.2 Tail-based Sampling (2024~2025 대세)

OTEL Collector config

processors:

tail_sampling:

policies:

- name: errors

type: status_code

status_code: {status_codes: [ERROR]}

- name: slow

type: latency

latency: {threshold_ms: 1000}

- name: random

type: probabilistic

probabilistic: {sampling_percentage: 1}

에러·느림 100%, 일반 1%.

5.3 Span 이름·속성 규칙

- **Span 이름**: `{service}.{operation}` (예: `db.query`, `http.get`)

- **Attribute**: W3C Semantic Conventions 따르기

- **이벤트**: 주요 단계 (cache.hit, retry, backoff)

- **Error**: `span.setStatus(ERROR)` + `exception` 이벤트

5.4 분산 디버깅 예시

Gateway (20ms)

├─ auth-service (5ms)

├─ user-service (50ms)

│ └─ postgres.query (45ms) ← 여기 느림

└─ product-service (10ms)

45ms 쿼리 span 속성: `db.statement = "SELECT * FROM users WHERE ..."` → 인덱스 확인.

6부 — eBPF: 코드 수정 없는 관측

6.1 eBPF란

리눅스 커널에 안전한 바이트코드 삽입 → 네트워크·시스템 콜·함수 호출 추적.

**장점:**

- 애플리케이션 코드 수정 없이 관측

- 오버헤드 극저 (커널 내 실행)

- 네트워크·시스템 수준

6.2 2025 eBPF 관측 도구

- **Pixie** (New Relic): Kubernetes 전용, auto-telemetry

- **Cilium Hubble**: 네트워크 흐름

- **Parca**: 항상 켜진 CPU 프로파일

- **Grafana Beyla**: auto-instrumentation

- **Inspektor Gadget**: Kubernetes용 툴킷

- **Odigos**: eBPF 기반 auto-instrumentation SaaS

6.3 eBPF의 진짜 가치

"언어 불문 auto-instrument" — Java·Go·Python·Rust·Node 어떤 언어든 HTTP/gRPC/DB 호출을 자동 트레이스.

**단점**: 커널 ≥ 5.x 필요, Windows 미지원 (진행 중), 아직 디버깅 난이도 높음.

7부 — SLO·SLI·Error Budget

7.1 정의 (Google SRE 책)

- **SLI** (Service Level Indicator): 측정값 — "요청 99%가 200ms 내 응답"

- **SLO** (Objective): 목표 — "99.9% SLI 달성"

- **SLA** (Agreement): 고객과 약속 — "99.5% 아래면 환불"

7.2 Error Budget

**100% - SLO = Error Budget**.

- SLO 99.9% → Budget 0.1% = 월 ~43분 다운타임 허용

- Budget 남음 → 릴리스 가능

- Budget 소진 → 릴리스 중단, 안정화 집중

7.3 Good SLI 선택 기준

1. **사용자 중심**: 내부 지표 아닌 사용자가 느끼는 것

2. **간단함**: 계산·이해 쉽게

3. **예측 가능**: 정상 운영에서 100% 달성

4. **조작 불가능**: 재정의로 올릴 수 없어야

**예시:**

- 나쁨: "서버 CPU ≤ 70%"

- 좋음: "사용자 요청 99%가 500ms 내 200 응답"

7.4 Burn Rate

Error Budget 소진 속도.

Burn Rate = (현재 에러율) / (허용 에러율)

14x burn for 1 hour = 5% budget 소진

6x burn for 6 hours = 5% budget 소진

**Multi-window alert**: 짧은 기간 고강도 + 긴 기간 중강도 조합 → false positive 감소.

7.5 Error Budget Policy

Budget 100~50% 남음: 일반 릴리스 속도

Budget 50~10%: 릴리스 테스트 강화, feature freeze 준비

Budget 10% 이하: Feature freeze, 안정화 sprint

Budget 소진: 포스트모템, 프로세스 재검토

8부 — 2025 관측 플랫폼 선택

8.1 상용 vs OSS

| 상용 | OSS Stack |

|-----|-----------|

| Datadog, New Relic, Dynatrace, Splunk, Honeycomb | Grafana Stack, Signoz, Kibana |

| 빠른 ROI, 지원, 고급 AI | 유연, 저비용, 락인 없음 |

| 비용 폭주 위험 | 운영 인력 필요 |

8.2 어떤 상황에 무엇

| 상황 | 추천 |

|-----|-----|

| 스타트업 < 20명 | Datadog 또는 Signoz SaaS |

| 성장 스타트업 | Grafana Cloud 또는 Honeycomb |

| 중견 기업 | Grafana Stack self-host + Prometheus |

| 대기업 | 혼합 (Datadog + OSS + 자체 구축) |

| 비용 극한 통제 | ClickHouse + Grafana |

8.3 Datadog 비용 함정

- **Custom Metrics**: 시계열 하나당 월 ~$5. 카디널리티 폭주 시 폭탄

- **Log Ingestion**: GB당 비쌈. 필터 필수

- **APM Host**: 호스트당 월 $31. 마이크로서비스 많으면 폭증

- **해결**: OTEL Collector에서 pre-filter, sample, aggregate

8.4 Honeycomb의 독특한 가치

- **High-cardinality 검색 우선**: trace_id, user_id로 자유 검색

- **BubbleUp**: 이상 그룹 자동 발견

- "metric 먼저"가 아닌 "원본 event 먼저" 철학

9부 — 조직적 Observability

9.1 Observability-driven Development

- 개발 단계부터 계측 생각

- PR에 "관측성 영향" 체크박스

- 새 기능엔 SLO 초안 필수

- Post-incident에서 "왜 관측 실패했나?" 분석

9.2 Incident Management와의 접점

- **MTTR 감소 = 관측성 성숙도**의 대리 지표

- Runbook에 "이 알림 → 이 대시보드 → 이 trace 확인" 체크리스트

- Postmortem Blameless: 시스템이 왜 감지 못했나?

9.3 관측성 코스트 모델

총 관측 비용 = Σ (signal 크기 × 저장기간 × 비용/GB)

절감 레버:

1. Sample (trace 1%, log 10%)

2. Aggregate (metric은 raw 아닌 rollup)

3. Retention 차등 (ERROR 90d, INFO 7d)

4. Pre-filter (OTEL Collector)

5. Cold/hot tier (S3로 arhive)

**목표**: 관측 비용 = 인프라 비용의 5~15% 수준 유지.

10부 — LLM 관측성 (2024~2025 새 영역)

10.1 추가로 측정할 것

- **Token Usage**: prompt/completion 토큰

- **Latency**: TTFT, total, per-token

- **Cost**: USD 단위 (모델×토큰)

- **Quality**: LLM-as-Judge score, user feedback

- **Tool Calls**: 성공/실패, 체인 깊이

- **Safety**: moderation 결과, refuse rate

10.2 도구

- **Langfuse**: 오픈소스, 자가 호스팅 가능

- **LangSmith**: LangChain 팀

- **Helicone**: 프록시 기반

- **Phoenix** (Arize): 오픈소스 강력

- **OTEL Gen AI Semantic Conventions**: 표준 통합

10.3 LLM Trace 구조

user_query (root span)

├─ retrieval (vector search)

│ ├─ embedding (token count)

│ └─ qdrant.search (query vector)

├─ llm.openai.chat (tokens, cost)

│ └─ tool_call: get_weather

│ └─ api.weather

└─ response_generation

11부 — Observability 로드맵 6개월

Month 1: 기초

- Prometheus + Grafana 설치

- 4가지 메트릭 타입 이해

- PromQL 기본

Month 2: Logging

- 구조화 로깅 표준

- Loki 또는 Elastic 운영

- Log level 정책

Month 3: Tracing

- OTEL SDK 통합

- Tempo 또는 Jaeger

- Tail-based sampling

Month 4: SLO

- 주요 서비스 SLI 정의

- Error Budget 계산

- Burn Rate 알림

Month 5: eBPF + Profile

- Pyroscope 도입

- Cilium Hubble (K8s 네트워크)

- Beyla auto-instrumentation

Month 6: 비용 + 조직

- 관측 비용 감사

- LLM 관측성 (Langfuse)

- Post-incident review 프로세스

12부 — Observability 체크리스트 12

1. **3축 + Profile**의 각 강점을 안다

2. **OpenTelemetry Collector** 구조를 설명할 수 있다

3. **Prometheus 4가지 메트릭 타입**을 안다

4. **카디널리티 폭증**의 의미와 예방을 안다

5. **Head vs Tail-based sampling** 차이를 안다

6. **W3C Trace Context**로 서비스 간 연결 원리를 안다

7. **eBPF가 왜 auto-instrumentation에 유리한지** 안다

8. **SLI·SLO·SLA** 차이를 명확히 안다

9. **Error Budget과 Burn Rate**를 계산할 수 있다

10. **로그 비용 절감 5가지**를 안다

11. **Datadog 비용 함정** 3가지를 안다

12. **LLM 관측성의 새 지표 5가지**를 안다

13부 — Observability 안티패턴 10

1. **비구조화 로그**: `printf`식. 검색·집계 불가

2. **카디널리티 무시**: label에 user_id 넣어 폭발

3. **100% trace 저장**: 비용·저장 파탄. Tail sampling 필수

4. **log-to-metric 난발**: 비싸다. Counter·Gauge로 메트릭화

5. **알림 피로**: 매일 수백 개. 정말 중요한 것만

6. **SLO 없이 운영**: 어느 정도가 "문제"인지 합의 없음

7. **Dashboard 정글**: 50개 대시보드 중 10개만 사용

8. **trace_id 연결 안 함**: 로그에 trace_id 없으면 디버깅 지옥

9. **Retention 통일**: ERROR와 DEBUG 같은 기간 저장 = 낭비

10. **관측성 후순위**: 출시 후 "넣겠다" → 영원히 미뤄짐

마치며 — Observability는 "시스템의 자아성"이다

인간이 고통을 못 느끼면 몸을 다스릴 수 없듯, 시스템도 **자기 상태를 인지**하지 못하면 운영할 수 없다.

2025년 Observability의 본질은:

- **표준** (OpenTelemetry로 벤더 독립)

- **통합** (4축을 trace_id로 꿰기)

- **경제성** (비용 통제하며 품질 유지)

- **조직성** (SLO는 팀 합의)

도구는 매년 바뀐다. Grafana Stack이 Prometheus → Mimir → Grafana Cloud로, Elastic이 OpenSearch로, Datadog이 eBPF로. 하지만 **원리는 그대로**다.

**"관측할 수 없으면 운영할 수 없다"**를 기억하라.

다음 글 예고 — "보안 완전 가이드: Zero Trust·Secret 관리·OAuth·OIDC·Supply Chain·AI 보안"

Season 2 Ep 10은 "운영의 필수" **보안 엔지니어링**. 다음 글은:

- Zero Trust 아키텍처 실전

- OAuth 2.1 / OIDC / PKCE

- Secret 관리 (Vault, AWS KMS, SOPS)

- SBOM과 Supply Chain 공격 방어

- Container·K8s 보안 (Pod Security, Admission)

- OWASP Top 10 for LLM

- 보안 관점의 관측성

암호는 쉽지만 보안은 어렵다, 다음 글에서 이어진다.