---
id: observability
title: "Observability"
category: "DevOps"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["Observability", "관측 가능성", "옵저버빌리티"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.80
created_at: 2026-07-11
updated_at: 2026-07-11
review_reason: "깨진 링크 다발 해소용 AI 생성 초안 — 원출처 리서치로 검증·보강 권장"
merge_history: []
tags: ["devops","monitoring","sre"]
raw_sources: []
applied_in: []
github_commit: ""
---

# [[Observability]]

## 🎯 한 줄 통찰 (One-line insight)
시스템 외부 출력(로그·메트릭·트레이스)만으로 내부 상태를 추론할 수 있는 성질 — 모니터링이 "아는 문제의 감시"라면 관측 가능성은 "모르는 문제의 진단"이다.

## 🧠 핵심 개념 (Core concepts)
- **세 기둥** — 로그(무슨 일이), 메트릭(얼마나), 분산 트레이스(어디서 지연이) — 셋이 함께 있어야 원인 추적이 닫힌다.
- **높은 카디널리티** — "어떤 사용자·어떤 요청에서?"에 답하려면 태그가 풍부한 이벤트 데이터가 필요하다.
- **SLI/SLO 연결** — 관측은 목표(SLO)가 있어야 의미를 가진다. 무엇이 "정상"인지 정의부터.
- **계측은 설계 단계에서** — 나중에 붙이는 로그는 구멍이 많다. 코드 경계마다 의도적으로 계측한다.

## 🧩 추출된 패턴 (Extracted patterns)
- 장애 대응의 질은 "대시보드 개수"가 아니라 "낯선 질문에 답할 수 있는가"로 측정된다.

## 🔗 Knowledge Connections
- **Related Topics:** [[Software Architecture]] · [[CQRS]]