이 글의 목적
관측성 기초 본편 14편을 마쳤다. 이 글은 시리즈 전체를 압축·연결하고 다음에 어디로 갈지 짚는 에필로그다.
- 14편 동안 본 개념을 한 장 지도로 다시 본다
- 관측성에서 뻗어 나가는 주제와 블로그 내 다른 시리즈를 연결한다
- 관측 지식이 어떤 직업·역할과 맞닿는지 정리한다
- 손으로 확인하는 방법과 읽을거리를 남긴다
1. 14편이 만든 큰 그림
관측성은 알람 하나가 아니라 로그·메트릭·트레이스를 상관해 “왜?”에 답하는 능력이다.
| Part | 핵심 질문 | 기억할 키워드 |
|---|---|---|
| 0 오리엔테이션 | Monitoring과 Observability 차이는 | 삼각형, unknown-unknown, correlation |
| 1 로그 | 무슨 일이 일어났나 | JSON, pipeline, trace_id, tail·filter |
| 2 메트릭 | 얼마나·얼마나 자주 | RED/USE, Prometheus, Grafana, cardinality |
| 3 트레이스 | 요청이 어디를 거치나 | span, OpenTelemetry, exemplar, propagation |
| 4 운영 실전 | 언제 깨우고 어떻게 배우나 | SLO·error budget, runbook, K8s 3층 |
한 줄로 묶으면:
구조화 로그와 메트릭으로 증상을 숫자로 잡고(신호)
trace_id·exemplar로 신호를 연결하고(상관)
SLO·burn rate로 page 기준을 맞추고(정책)
runbook·postmortem·K8s scrape로 운영한다(실전)2. 실무에서 다시 만나는 지점
교과서 개념은 대시보드·알람·장애로 확인할 때 살아난다.
| 관측 개념 | 실무에서 보는 곳 | 도구·명령 |
|---|---|---|
| 구조화 로그 | “어느 user?” grep 불가 | Loki/ELK, trace_id filter |
| RED | 5xx spike, RPS drop | PromQL rate, Grafana |
| cardinality | Prometheus OOM, slow query | topk, relabel, label drop |
| 분산 trace | checkout만 느림 | Tempo/Jaeger, waterfall |
| exemplar | p99 ↑ 원인 hop | Grafana → trace jump |
| SLO burn | 배포 freeze 논쟁 | recording rule, burn alert |
| runbook | page 왔는데 15분 blank | annotation runbook_url |
| K8s 3층 | Running인데 5xx | kube-state + cAdvisor + app RED |
| postmortem | 같은 장애 3주 후 | timeline, action item owner |
- "CPU 80%" page와 "checkout down" page는 severity가 다르다 — impact·SLO 기준 (온콜 편)
- Monitoring은 알려진 대시보드, Observability는 처음 보는 failure mode를 신호 조합으로 좁히는 것 (오리엔테이션)
3. 이후 확장되는 개념
본 시리즈는 로그·메트릭·트레이스 + SLO + K8s scrape 공통 기반까지다.
| 확장 영역 | 관측에서 온 질문 | 더 깊이 가면 |
|---|---|---|
| ELK · Elastic | 로그 pipeline·검색 | ingest pipeline, ILM, APM, SIEM |
| 플랫폼·K8s | Pod·노드 메트릭 | service mesh telemetry, eBPF (Cilium) |
| IaC · GitOps | scrape·rule 코드화 | Prometheus Operator, Mimir/Thanos |
| 아키텍처 | 품질 속성 측정 | SLI per capability, chaos 실험 |
| 데이터베이스 | 슬로우 쿼리·복제 lag | pg_stat, slow log → metric |
| 보안 | 감사·침해 | audit log, OTel sec signal |
| 비용 | retention·cardinality | sampling policy, cost per TB |
| AI ops | anomaly·RCA | LLM assist, predictive alert (실험적) |
블로그 내 이어읽기 (권장 순)
- ELK · Elastic Cloud — 로그·APM·검색 심화 (로그 파이프라인 편 이후)
- IaC — Prometheus·Grafana·Alertmanager GitOps
- 플랫폼 · DevOps · Cloud — K8s·CI/CD·배포 annotation
- 소프트웨어 아키텍처 — MSA·품질 속성·내고장성 (SLO 연계)
- 데이터베이스 따라잡기 — 슬로우 쿼리·WAL·복제 lag 관측
- 애플리케이션 보안 — audit·AuthN/Z 로그 상관
- 네트워크 기초 — RTT·TLS·트러블슈팅 (로그로 장애 좁히기와 맞물림)
4. 관심 있게 지켜볼 직업·직업군
관측성은 SRE·플랫폼·백엔드 전반의 공통 언어다.
| 역할 | 하는 일 | 관측 시리즈와의 연결 |
|---|---|---|
| SRE | SLO·온콜·용량 | burn rate, runbook, postmortem |
| 플랫폼·DevOps | K8s·CI/CD·스택 운영 | scrape, ServiceMonitor, metrics-server 분리 |
| 백엔드 | API·비즈니스 로직 | RED instrumentation, trace propagation |
| 데이터·DBA | 쿼리·복제·백업 | slow query log, replication lag metric |
| 보안 | 감사·침해 대응 | structured audit log, SIEM pipeline |
| 성능 | tail latency·프로파일 | histogram, continuous profiling |
| 데이터 엔지니어 | pipeline·CDC | lag metric, data quality SLI |
| ML / AI infra | GPU·배치 job | job metric, queue depth, cost observability |
지켜볼 만한 방향 (2020s~)
- OpenTelemetry — 로그·메트릭·트레이스 단일 SDK·Collector 표준화
- eBPF / Pixie / Cilium — 커널·네트워크 무침습 관측
- Profiles (OTel) — trace + continuous profiling 연계
- Grafana LGTM / Mimir / Loki / Tempo — OSS observability 스택 통합
- FinOps observability — cardinality·retention 비용을 1급 지표로
- AI-assisted RCA — 상관은 도구, 판단은 여전히 사람 (speculative)
역할마다 깊이는 다르다. 백엔드는 PromQL·trace propagation을, SRE는 SLO·runbook을, 플랫폼은 scrape·Operator를 최소로 갖추면 시너지가 난다.
5. 앞으로의 학습 루틴
개념만으로는 부족하다. 짧은 루프를 권한다.
| 주기 | 활동 | 예 |
|---|---|---|
| 매주 | 한 서비스 RED 보드 점검 | error rate·p99·RPS 한 화면 |
| 매월 | PromQL·Explore 연습 | histogram_quantile, exemplar jump |
| 분기 | game day / tabletop | burn page → runbook → postmortem 초안 |
| 연 1회 | 스택·retention review | cardinality audit, sampling 정책 |
추가 읽을거리
| 수준 | 자료 |
|---|---|
| 입문·복습 | Observability Engineering — Majors, Fong-Jones, Miranda (본 시리즈 기준) |
| SRE·SLO | Site Reliability Engineering — Google; Implementing Service Level Objectives |
| Prometheus | prometheus.io docs, Prometheus Up & Running |
| OpenTelemetry | opentelemetry.io, OTel spec (logs·profiles 확장) |
| 실습 | minikube + kube-prometheus-stack, Grafana Play dashboards |
| 트렌드 | CNCF OTel blog, Grafana/Mimir release notes |
6. 시리즈 색인 (14편 요약)
필요할 때 해당 편으로 바로 점프한다.
| # | 제목 | 거기서 답하는 질문 |
|---|---|---|
| 1 | 관측성 오리엔테이션 | Monitoring vs Observability, 삼각형 |
| 2~4 | 로그 | JSON·pipeline·장애 좁히기 |
| 5~8 | 메트릭 | RED/USE, Prometheus, Grafana, cardinality |
| 9~11 | 트레이스 | span, OpenTelemetry, 신호 연계 |
| 12~14 | 운영 | SLO·온콜·K8s 관측 |
7. 마치며
처음에는 kubectl get pods와 CPU 그래프만 봤을지 모른다. 시리즈를 지나며 Running ≠ healthy, 메트릭 ≠ SLI, 알람 ≠ observability를 구분하게 됐다. page가 왔을 때 runbook → RED → trace → log → mitigate → postmortem 순서가 손에 잡히면, 이 시리즈의 목표는 거의 달성한 것이다.
관측을 안다는 건 모든 exporter를 설치한다는 뜻이 아니다. 장애·설계 대화에서 “그건 cardinality다 / burn rate다 / trace hop이다 / replica gap이다”고 위치를 잡고, 다음 신호를 고를 수 있다는 뜻에 가깝다.
해당 내용은 Observability Engineering (Charity Majors, Liz Fong-Jones, George Miranda), Site Reliability Engineering (Google), 및 시리즈 1~14편을 바탕으로 정리했습니다.
'관측성' 카테고리의 다른 글
| K8s 관측 (0) | 2026.07.01 |
|---|---|
| 온콜과 인시던트 (0) | 2026.06.30 |
| SLO와 에러 버짓 (0) | 2026.06.29 |
| 트레이스와 로그·메트릭 연계 (0) | 2026.06.28 |
| OpenTelemetry (0) | 2026.06.27 |