개념
모니터링과 관측성은 같은 말이 아니다
"우리 모니터링 잘 되고 있죠?"라는 질문에는 대개 대시보드 화면으로 답한다. CPU, 메모리, 응답 시간, 에러율. 그 화면은 누군가가 미리 "이것을 보자"고 정해 둔 것들 이다. 장애가 그 목록 밖에서 일어나면 화면은 초록색인 채로 사용자만 아프다. 두 단어를 이렇게 갈라 둔다.
| 모니터링 | 관측성(observability) | |
|---|---|---|
| 하는 일 | 미리 정한 질문 에 답한다 | 미리 정하지 않은 질문 을 던질 수 있게 한다 |
| 전형적 형태 | 고정된 지표·임계값·대시보드 | 높은 카디널리티 속성이 붙은 이벤트·트레이스를 임의로 쪼개 보기 |
| 잘 잡는 것 | 아는 고장 방식(known unknowns) | 처음 보는 고장 방식(unknown unknowns) |
| QA 의 개입점 | 임계값과 경보 규칙이 맞는지 | 사고 조사에 필요한 속성이 실제로 남는지 |
관측성이 모니터링의 상위 호환은 아니다. 관측성은 데이터가 충분히 풍부한가 에 대한 시스템의 성질이고, 모니터링은 그 데이터로 무엇을 계속 지켜볼지 정한 운영 행위 다.
로그·메트릭·트레이스 세 신호의 성격과 도구 사용법은 모듈 14 레슨 6에서 이미 다뤘다. SLI·SLO·오류 예산의 정의와 SLO 를 정하는 절차는 모듈 14 레슨 7 이 담당한다. 이 레슨은 그 위에서 운영 조직이 24시간 굴리는 이벤트 관리 로 각을 튼다. 누가 언제 깨는가, 수십 개 경보를 어떻게 한 건으로 묶는가, 그 규칙을 누가 시험하는가.
ITIL 이 말하는 "이벤트"의 정확한 뜻
레슨 3 에서 인시던트·문제·변경을 구분했다. 이벤트(event) 는 그 앞자리에 있다. ITIL 에서 이벤트는 구성요소나 서비스의 상태 변화 이고, 그 자체로는 좋고 나쁨이 없다. 이벤트 관리 프랙티스는 이벤트를 분류하고, 대응할 것과 기록만 할 것을 가르는 일을 한다.
정보(informational) 기록만 한다. 배치 완료, 사용자 로그인, 스케일아웃 성공
경고(warning) 임계에 접근했다. 아직 서비스는 정상. 디스크 80%, 큐 적체 증가
예외(exception) 합의된 기준을 벗어났다. 대응이 필요하다. 5xx 급증, 노드 다운이 구분이 실무에서 무너지는 지점은 "정보"를 경보로 보내는 것 이다. 배치 성공 알림이 당직 채널로 오면 당직자는 채널을 음소거하고, 같은 채널로 온 예외를 못 본다. 경보 설계의 첫 규칙이 여기서 나온다 — 사람을 깨우는 통보는 예외만.
이벤트에서 사람에게 도달하기까지 잘릴 수 있는 지점은 여덟 곳이다. "왜 경보가 안 왔나"를 물을 때 이 순서로 짚는다.
1. 계측 신호를 만드는가 5. 라우팅 어느 팀·당직 일정으로 가는가
2. 수집 받아 저장하는가 6. 통보 실제 채널로 전달되는가
3. 판정 예외로 분류하는가 7. 수신 당직자가 확인(ack)하는가
4. 상관 묶고 정비 창을 거르는가 8. 기록 인시던트 레코드로 남는가대부분의 "경보가 안 울렸다" 사고는 1·3·5·6 에서 잘린다. 계측이 없었거나, 임계값이 실제 장애를 못 넘거나, 라우팅이 퇴사자에게 가 있거나, 통보 채널 연동이 조용히 끊긴 것이다. 이 목록 자체가 시험 대상 목록 이다.
증상 기반 경보와 원인 기반 경보
경보 규칙을 둘로 나눈다.
| 증상 기반(symptom-based) | 원인 기반(cause-based) | |
|---|---|---|
| 보는 것 | 사용자가 겪는 것 — 실패율, 지연, 응답 없음 | 내부 상태 — CPU, 힙, 스레드 풀, 복제 지연 |
| 예 | 결제 오류율이 30분간 기준 초과 | 결제 서버 CPU ≥ 90% 5분 지속 |
| 장단 | 원인 불문 놓치지 않는다 / 어디가 문제인지 따로 찾아야 | 원인을 바로 가리킨다 / 사용자가 멀쩡한데 울린다 |
| 통보 | 사람을 깨운다 | 원칙적으로 티켓·대시보드 로 |
기본 규칙은 이렇다. 사람을 깨우는 것은 증상, 조사를 돕는 것은 원인. CPU 가 95% 여도 사용자 응답이 멀쩡하면 깨울 일이 아니라 용량 계획 과제다.
예외는 임박한 고갈 하나다. 디스크 잔량, 인증서 만료, 토큰 소진처럼 지금은 증상이 없지만 확정적으로 곧 증상이 되는 것은 원인 기반이어도 사람에게 보낸다. 다만 근무 시간 내 처리 등급으로 — "72시간 뒤 만료" 를 새벽 3시에 깨울 이유는 없다.
SLO 기반 경보와 오류 예산 소진율(burn rate)
고정 임계값 경보의 고질병은 "5분간 오류율 1% 초과" 같은 규칙이 장애의 크기를 구분하지 못한다는 것이다. 전면 장애도, 아주 작은 오류 증가도 같은 등급으로 1분 뒤 울린다.
SLO 를 쓰면 풀린다. Google 의 SRE Workbook 은 소진율(burn rate) 을 "SLO 대비 서비스가 오류 예산을 얼마나 빨리 소비하는가" 로 정의한다. 소진율
1 은 SLO 기간이 끝나는 시점에 예산을 정확히 다 쓰는 속도 다. 30일 SLO 가 99.9% 라면 오류 예산은 30일의 0.1% — 43.2분 이고, 오류율이 계속
0.1% 면 소진율은 1 이다. 이렇게 하면 "얼마나 빨리 타고 있는가" 로 등급을 나눌 수 있다. Workbook 이 99.9% SLO 의 출발점으로 제시하는 다중 창·
다중 소진율 구성은 이렇다.
| 소진율 | 긴 창 | 짧은 창 | 그 창에서 소비되는 예산 | 통보 |
|---|---|---|---|---|
| 14.4 | 1시간 | 5분 | 2% | 호출(page) |
| 6 | 6시간 | 30분 | 5% | 호출(page) |
| 1 | 3일 | 6시간 | 10% | 티켓(ticket) |
계산은 단순하다. 30일은 720시간이므로 14.4 × (1 / 720) = 2%, 6 × (6 / 720) = 5%, 1 × (72 / 720) = 10% 다. 이 구성이 주는 것은 등급 분리
(빠르게 타면 깨우고 천천히 타면 티켓)와 짧은 창의 역할 이다. 긴 창만 쓰면 장애가 끝난 뒤에도 경보가 한참 계속 울린다. 짧은 창을 AND 조건으로
붙여 지금도 타고 있을 때만 울리게 한다.
숫자를 그대로 베끼지는 않는다. 99.9% 를 전제로 만들어진 표이고, 트래픽이 적은 서비스에서는 소진율이 요청 몇 건에 출렁인다. 하루 요청이 수백 건인 서비스에 그대로 걸면 3건 실패로 호출이 온다. 이런 서비스는 최소 요청 수 조건을 걸거나, 창을 늘리거나, 합성 모니터링 실패로 판정한다.
경보 피로 — 억제와 그룹핑
경보 피로(alert fatigue)는 당직자가 경보를 읽지 않고 닫는 상태 다. 여기까지 오면 경보 시스템은 있으나 마나가 아니라 해롭다 — 진짜 경보가 가짜 더미에 섞여 사라진다. 측정부터 한다. 실행 가능률(통보받은 경보 중 실제 조치가 있었던 비율), 자동 해소율(사람이 손대기 전에 스스로 닫힌 비율 — 높으면 임계값이 예민하다는 뜻), 야간 호출 수(당직 1인당 주간 야간 호출 건수) 셋이다. "실행 가능률이 20%" 라는 숫자 하나가 "경보가 좀 많아요" 보다 힘이 세고, 그때부터 경보 정리가 개선 과제 가 된다. 줄이는 수단은 넷이다.
억제(계획 정비·배포 창 동안 막기 — 창이 끝났는데 안 풀리는 것이 전형적 사고), 그룹핑(같은 라벨로 묶어 한 통보로 — 키가 넓으면 다른 장애가 가려진다), 의존 억제(상위가 죽었으면 하위를 묶기 — CMDB·토폴로지가 최신이어야 한다), 등급 강등(호출 → 티켓 → 대시보드).
강등은 특히 조심한다. 대시보드로 내린 경보는 누가 언제 보는지 정해져 있을 때만 살아 있다. 정해지지 않았다면 솔직하게 삭제하고, 그래서 감시하지 않게 된 범위를 기록에 남긴다. 레슨 8 에서 축소 시험의 미검증 범위를 기록했던 것과 같은 습관이다.
이벤트 상관 분석 — 하나의 장애가 수십 개 경보로 번질 때
데이터베이스 하나가 멎으면 경보는 하나로 오지 않는다. DB 연결 실패, API 지연, 큐 적체, 배치 실패, 헬스체크 실패, 그 API 를 쓰는 다른 세 서비스의 오류율. 당직자가 받는 것은 알림 47개 다. 상관 분석은 이 47개를 한 건으로 묶는 일이고, 묶는 축은 넷이다.
| 축 | 규칙 | 예 |
|---|---|---|
| 시간 | 정해진 창 안에 발생한 경보를 후보로 본다 | 90초 창 안의 경보를 한 묶음 후보로 |
| 토폴로지 | 구성 항목 의존 그래프의 상하 관계로 묶는다 | DB → API → 프런트 경로의 경보는 한 건 |
| 라벨 | 동일 라벨 조합을 묶는다 | service=payments, cluster=prod-a |
| 이력 | 과거에 늘 같이 울린 조합을 묶는다 | 지난 20건에서 항상 동반 발생한 두 규칙 |
함께 정해야 하는 것이 대표 경보(부모) 선정 규칙 이다. 통보는 한 건으로 가는데 그 한 건이 무엇을 가리키느냐에 따라 초동이 달라진다. 토폴로지의 가장 상류 를 부모로 두고, 상류를 못 정하면 가장 먼저 발생한 것 을 부모로 둔다.
상관 분석에는 고유한 위험이 있다. 묶다가 삼킨다. 같은 창 안에 무관한 두 장애가 일어나면 규칙이 둘을 한 건으로 묶고 당직자는 하나만 본다. 그래서 상관 규칙은 자식 경보를 모두 보존 하고, 부모와 서비스·클러스터가 다른 자식 을 표시하게 만든다. 이 둘이 상관 규칙 리뷰의 첫 질문이다.
대시보드는 "누가 보는가"로 나눈다
한 화면에 모든 것을 넣은 대시보드는 아무도 쓰지 않는다. 독자를 먼저 정하고 세 벌을 만든다.
| 독자 / 주기 | 답해야 할 질문 | 핵심 요소 | 판정 기준 |
|---|---|---|---|
| 당직자 / 호출 직후 3분 | 지금 무엇이 아픈가, 어디부터 볼까 | 서비스별 증상 신호, 최근 배포, 진행 중 인시던트, 런북 링크 | 3분 안에 다음 행동이 정해지는가 (스크롤이 필요하면 실패) |
| 서비스 오너 / 주간 | 추세가 나빠지고 있나 | SLO 달성률·오류 예산 잔량, 인시던트 유형 분포, 변경 실패율 | 개선 과제 하나를 고를 수 있는가 |
| 경영진 / 월간 | 약속을 지키고 있나 | SLA 준수, 중대 인시던트 건수·영향, 개선 과제 진척 | 숫자 하나가 의사결정에 쓰이는가 (도구 이름·내부 용어 금지) |
표의 마지막 줄이 판정 기준 이다. 대시보드도 산출물이고 산출물에는 인수 기준이 있다. 신규 당직자에게 화면만 주고 "지금 무엇부터 보겠는가"를 3분 안에 말하게 해보면 대부분의 당직 대시보드가 통과하지 못한다.
경영진 화면에서 자주 어긋나는 것은 숫자의 정의 다. 오너 화면의 SLO 달성률과 경영진 화면의 SLA 준수율이 다른 이유는 대개 제외 항목(계획 정비, 고객 책임 구간, 일부 지역)이 다르기 때문이다. 두 화면의 숫자가 다르면 다른 게 맞는지부터 확인한다 — 레슨 4 에서 SLA 보고서를 레코드에서 재계산해 본 이유가 이것이다.
QA 의 몫 — 경보가 실제로 울리는지 시험한다
경보 규칙은 배포되고 나면 아무도 실행해 보지 않는 코드 다. 평소에는 거짓을 반환하고, 참을 반환해야 하는 순간은 1년에 두 번뿐이다. 그 두 번에 틀리면 아무도 모른다.
시험 방법 1 — 합성 모니터링(synthetic monitoring). 실제 사용자 없이 핵심 여정을 주기적으로 실행해 본다. 로그인 → 검색 → 결제 흐름을 5분마다 돌리고 실패하면 경보를 만든다. 합성 모니터링은 통제된 시나리오를 트래픽 없는 새벽에도 돌리지만 시나리오 밖은 못 본다. 실 사용자 지표(RUM)는 전 구간을 덮지만 사용자가 없는 시간대에는 아무 신호도 없다. 새벽 2시에 결제가 죽었는데 사용자가 없어 지표가 조용한 상황을 잡는 것은 합성 모니터링뿐이다. 합성 시나리오 목록을 감시 범위 선언서 로 취급하고 신규 핵심 여정이 추가됐는지 확인하는 것이 QA 의 정기 과제다.
시험 방법 2 — 장애 주입. 통제된 환경에서 실제로 고장을 만들고, 앞의 여덟 단계 중 어디까지 도달했는지 본다.
| 주입 | 기대 경보 | 확인할 것 |
|---|---|---|
| 의존 서비스에 5xx 를 일정 비율로 주입 | 증상 기반 오류율 경보 | 소진율 등급이 맞게 나오는가, 몇 분 만에 오는가 |
| 응답에 지연 삽입 | 지연 SLI 경보 | 평균이 아니라 p95·p99 로 판정하는가 |
| DB 정지(격리 환경) | 다수 경보 → 1건으로 상관 | 부모가 DB 로 잡히는가, 자식이 보존되는가 |
| 통보 채널 차단 | 경보는 발생, 통보는 실패 | 통보 실패 자체를 감지하는 장치가 있는가 |
마지막 줄이 자주 빠진다. 경보 시스템이 죽었을 때 알려줄 장치 — 주기적으로 스스로 신호를 보내고 그 신호가 끊기면 알리는 방식(dead man's switch) — 이 없으면 경보 시스템의 침묵과 서비스의 평온이 구분되지 않는다. 주입 시험을 운영 환경에서 한다면 범위·중단 조건·롤백 을 사전 합의한다. 카오스 엔지니어링 절차는 모듈 39 레슨 7 에서 다룬다.
시험 방법 3 — 경보 규칙을 리뷰 대상으로 올린다. 경보 규칙은 코드 리뷰를 받아야 하는 코드다.
[ ] 증상 기반인가 원인 기반인가. 원인 기반인데 사람을 깨우는가 — 근거는?
[ ] 임계값의 근거가 있는가 (SLO 유도 / 과거 데이터 / 추측)
[ ] 지속 시간 조건이 있는가. 트래픽이 적은 시간대에 오탐하는가
[ ] 통보 대상이 현재 당직 일정과 일치하는가
[ ] 런북 링크가 붙어 있고, 그 런북의 첫 단계가 실행 가능한가
[ ] 규칙이 참을 반환하는 조건을 시험으로 재현했는가
[ ] 해소 조건(자동 닫힘)이 있는가. 없으면 수동 종료 책임자는 누구인가여섯 번째 줄이 결정적이다. "이 규칙이 울리는 것을 본 적이 있는가" 에 답할 수 없는 규칙은 미검증 규칙이다.
실무에서 왜 필요한가
사고 회고에 가장 자주 나오는 문장 둘이 있다. "경보는 왔는데 아무도 안 봤다" 와 "경보가 아예 안 왔다". 앞은 경보 피로이고, 뒤는 계측 공백 또는 경로 단절이다. 둘 다 장애 당일이 아니라 평소에 시험했어야 잡히는 것 이고, 그래서 QA 의 일이다.
경보 설계는 운영 품질의 다른 지표로 직접 이어진다. 레슨 3 에서 본 평균 탐지 시간(MTTD)·평균 복구 시간(MTTR)은 대부분 탐지 에서 갈린다. 복구 절차를 아무리 다듬어도 30분 늦게 알면 30분이 그대로 더해진다.
조직 관점에서는 경보의 소유권 문제가 있다. 소유자가 없는 규칙은 오탐이 나도 "우리 게 아닌데요"로 끝난다. 경보 규칙에도 구성 항목처럼 소유 팀을 붙이고, 실행 가능률이 낮은 규칙을 분기마다 소유 팀에 되돌려 보낸다. 레슨 4 의 서비스 관리 시스템(SMS)이 말하는 관리 대상 문서 로 올리는 것이다.
채용시장에서의 위치
운영 품질·SRE·플랫폼 QA 공고의 "모니터링 구축 경험"은 흔한 문구지만, 면접에서 갈리는 지점은 도구 이름이 아니라 "경보 규칙을 어떻게 정했나요" 와 "그 경보가 울리는 것을 확인해 봤나요" 두 질문이다. 이 레슨의 산출물 — 경보 규칙 리뷰 체크리스트, 상관 규칙 표, 독자별 대시보드 설계, 장애 주입 시험 기록 — 은 레슨 7 의 산출물 포트폴리오에 그대로 들어간다.