---
type: knowledge
domain: infra
status: active
last-reviewed: 2026-07-27
---

# 관측성 실전

> 한 줄 정의
> 관측의 목표는 데이터 수집이 아니라 **"사용자가 지금 아픈가"에 30초 안에 답하는 것**이다. 관측 3종(로그·메트릭·트레이스) 최소선은 [[인프라 원리]], AWS 구현은 [[11_관측성과 운영]] — 여기는 무엇을 재고 어떻게 배치하는가의 규율이다.

## 메트릭 3층 — 아래층만 보면 사용자를 놓친다

| 층 | 내용 | 답하는 질문 |
|----|------|------------|
| 업무 지표 | 주문 수·처리 건수·전환율 — 도메인의 성공 단위 | 비즈니스가 정상인가? |
| 서비스 골든 시그널 | **지연(p95)·트래픽·에러율·포화도** 4종 | 서비스가 정상인가? |
| 인프라 리소스 | CPU·메모리·디스크·네트워크 | 왜 그런가? (원인 탐색용) |

- 진단은 위에서 아래로: 업무 지표 이상 → 어느 서비스인가 → 어느 리소스인가. **인프라 지표만 있는 시스템은 "CPU는 멀쩡한데 주문이 0건"을 탐지하지 못한다.**
- 업무 지표가 가장 싸고 가장 강력한 감시다 — "시간당 처리 건수가 평소의 절반"은 어떤 인프라 알림보다 먼저 사고를 말해준다.
- 배치·비동기 시스템은 **마지막 성공 시각**이 핵심 지표다 — "어제 배치가 안 돌았음을 오늘 아는 구조"는 무성 실패다.

## 헬스체크 설계 — liveness와 readiness는 다른 질문이다

| 종류 | 질문 | 실패 시 동작 | 의존성 포함? |
|------|------|-------------|------------|
| liveness | 프로세스가 살아 있나 | 재시작 | **포함 금지** — DB 다운 시 전 인스턴스 재시작 폭풍 |
| readiness | 트래픽 받을 준비가 됐나 | 트래픽 제외 | 필수 의존성만 포함 |

- liveness에 DB 체크를 넣는 것이 고전적 사고다: DB가 잠깐 흔들리면 멀쩡한 앱 전체가 재시작 루프에 빠진다.
- readiness의 의존성은 "이것 없이는 어떤 요청도 처리 불가"인 것만 — 부가 기능의 의존성까지 넣으면 부분 장애가 전체 차단이 된다.
- 헬스체크 엔드포인트는 인증 없이 얕고 빠르게(수 ms) — 헬스체크가 무거우면 그 자체가 부하가 된다. 폐쇄망이라면 핵심 연동 대상 접근성을 별도 딥체크로 → [[폐쇄망·온프레미스 실전]].

## 대시보드 규율 — 화면 하나 = 질문 하나

- 대시보드마다 답할 질문을 하나 정한다: "지금 서비스가 정상인가"(첫 화면), "이 서비스가 왜 느린가"(서비스별), "이번 배포가 회귀를 만들었나"(배포 확인용).
- **장애 시 보는 순서로 배치한다**: 좌상단에 사용자 영향(에러율·지연), 그 아래로 원인 후보 순. 장애 중에 그래프를 찾아 헤매는 대시보드는 없는 것과 같다.
- 배포 시각을 대시보드에 마커로 남긴다 — "그래프가 꺾인 지점 = 배포 지점" 상관 분석이 조사 시간의 대부분을 줄인다.
- 40개 그래프짜리 만능 대시보드는 아무 질문에도 답하지 못한다 — 안 보는 그래프는 지운다.

## SLO와 알림 — 원인이 아니라 증상에 건다

- **알림은 사용자 증상에**: 에러율·지연·처리 정체. CPU 80% 같은 원인 후보는 알림이 아니라 대시보드용이다 — CPU 90%여도 사용자가 멀쩡하면 새벽에 깨울 일이 아니다.
- SLO(예: 30일 성공률 99.9%)를 정하면 **에러 예산**이 생긴다: 예산 소진 속도가 알림 기준이 되고, 예산이 남았으면 배포를 계속하고 소진되면 안정화를 우선한다 — 변경 속도와 신뢰성을 논쟁이 아니라 숫자로 조정한다.
- 모든 알림에는 받는 사람과 첫 행동(런북 링크)이 있어야 한다 — 행동 없는 알림은 소음이다. 앱 에러 알림 예산은 [[에러 처리와 로깅 실전]], 알림 이후의 대응은 [[장애 대응 실전]].

## 로그·메트릭·트레이스 — 역할 분담

| 신호 | 답하는 질문 | 비용 특성 |
|------|------------|----------|
| 메트릭 | 얼마나 자주·얼마나 느리게? (집계) | 싸다 — 알림·대시보드의 주재료 |
| 로그 | 그 요청에 정확히 무슨 일이? (개별 사건) | 양에 비례 — 보존 기간 관리 필수 |
| 트레이스 | 어느 구간에서 시간을 썼나? (요청의 여정) | 샘플링으로 통제 |

- 셋을 잇는 접착제가 **traceId**다 — 메트릭 이상 → 해당 시간대 트레이스 → 그 트레이스의 로그로 내려가는 동선이 성립해야 한다. 로그 구조·전파 규율은 [[에러 처리와 로깅 실전]].
- 메트릭으로 답할 질문을 로그 전수 검색으로 답하고 있다면 설계가 뒤집힌 것이다 — 로그는 비싸고 느린 최후 수단이다.

## 외주 지점

- **검수 항목에 관측을 포함한다**: 대시보드 구성·알림 목록·수신자가 검수 대상이다. "기능은 다 되는데 모니터링은 없음"인 채 검수 통과하면 하자보수 기간 내내 수행사가 눈 감고 운영한다.
- **알림 수신자 = 발주사 담당자 지정**: 수행사 개인 연락처로만 알림이 가는 구조는 계약 종료와 함께 관측이 죽는다. 인수인계 시점에 수신자 전환을 명시적으로 확인한다.
- **하자보수 기간의 원격 접근 제약**: 폐쇄망·보안 정책상 수행사가 상시 접속할 수 없는 경우가 많다 — 발주사 담당자가 대시보드만 보고 1차 판단할 수 있는 수준(화면 하나 = 질문 하나)으로 만드는 것이 원격 접근의 대체재다.
- 관측 데이터(로그·메트릭)도 발주사 소유다 — 외부 SaaS 수집·반출 금지 가능성을 착수 시점에 확인 → [[폐쇄망·온프레미스 실전]].

## 안티패턴

- **수집은 많고 질문은 없음** — "일단 다 모으자"는 비용만 내고 답은 못 하는 상태다. 질문(SLO·대시보드)이 수집을 결정한다.
- **liveness에 의존성 체크** — 의존성 장애가 재시작 폭풍으로 증폭된다.
- **평균 지연만 감시** — 평균은 거짓말한다. p95·p99가 사용자의 진짜 경험이다.
- **알림 무시가 문화가 됨** — 오탐 알림을 끄지도 고치지도 않고 무시하는 순간, 진짜 알림도 함께 죽는다.

## 관련 문서

- [[00_인프라 허브]] — 08_인프라 진입점
- [[인프라 원리]] — 관측 3종 최소선
- [[11_관측성과 운영]] — AWS 구현판 (CloudWatch·OpenTelemetry·SLO)
- [[에러 처리와 로깅 실전]] — 앱 로그 규율·알림 예산
- [[장애 대응 실전]] — 알림 이후: 완화·심각도·포스트모템
- [[폐쇄망·온프레미스 실전]] — 외부 SaaS 불가 시 자가 관측