Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

"프로덕션이 죽었다"는 말은 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의 레퍼런스

**L**oki (logs) + **G**rafana (UI) + **T**empo (traces) + **M**imir (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 구조

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

- "사람이 실수함"에서 멈추기 → 시스템이 실수를 허용한 이유를 파라

- 액션 아이템이 추상적("프로세스 개선") → 구체화

- 배포 후 리뷰 미실행 → 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 단계별 로드맵

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 스타트업 ~ 중견기업 ~ 엔터프라이즈 가이드

- **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

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년이다.

- **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

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