새벽 세 시, 두 운영팀.
A팀은 조용합니다. 모니터링이 없는 건 아니지만, 알림이 너무 많이 와서 다들 채널 알림을 꺼 두었습니다. 아침 아홉 시, 고객센터로 "결제가 안 돼요" 전화가 빗발치고 나서야 A팀은 새벽 두 시부터 결제 DB 디스크가 꽉 차 있었다는 걸 알게 됩니다. 일곱 시간을 모르고 흘려보낸 겁니다.
B팀은 자정에 모니터링이 보낸 경고를 받았습니다 — "결제 DB 디스크 사용률 85퍼센트 초과". 아직 서비스는 멀쩡합니다. 당직자는 오래된 로그를 정리해 사용률을 60퍼센트대로 내립니다. 아침에 출근한 팀은 아무 일도 없던 것처럼 일을 시작합니다. 고객은 장애가 있었는지조차 모릅니다.
두 팀의 차이는 모니터링 도구의 유무가 아닙니다. 신호를 받고도 살아 있는 체계가 있느냐입니다. A팀은 신호를 꺼 버렸고, B팀은 신호를 분류해 행동으로 연결했습니다. 이 모듈은 '장애를 신고받기 전에 먼저 아는' 이벤트·모니터링 관리 체계를 다룹니다.
- 1이벤트(CI·서비스의 상태 변화 신호)가 사용자 신고와 어떻게 다른지 설명할 수 있다
- 2이벤트를 정보(Information)·경고(Warning)·예외(Exception)로 분류하고 각각에 맞는 대응을 정할 수 있다
- 3능동 모니터링과 수동 모니터링의 차이를 알고, 무엇을 모니터링할지(CPU·메모리·디스크·오류율·지연) 설계할 수 있다
- 4임계치(threshold)와 알림(alert)이 인시던트 자동 생성으로 이어지는 흐름을 그릴 수 있다
- 5알림 피로(alert fatigue)의 위험을 이해하고, 상관분석·중복 억제로 노이즈를 줄이는 방향을 제시할 수 있다
이벤트란 무엇인가 — 신고가 아니라 신호
이벤트는 시스템이 스스로 보내는 상태 변화 신호다
지금까지 운영의 출발점은 대부분 '사람의 신고'였습니다 — "메일이 안 와요", "결제가 느려요". 그런데 사람이 신고할 때쯤이면 이미 고객이 불편을 겪은 뒤입니다. 한 칸 앞으로 가려면, 시스템이 스스로 신호를 보내게 해야 합니다. 그 신호가 바로 **이벤트(Event)**입니다.
이벤트는 "구성요소(CI)나 서비스의 상태 변화 중, 관리상 의미가 있는 것을 알리는 신호"입니다. 핵심은 두 가지입니다.
- 출발점이 사람이 아니다. 디스크가 임계치를 넘거나, 서비스가 응답을 멈추거나, 배치가 끝나는 것 모두 시스템이 자동으로 발생시키는 이벤트입니다.
- 모든 이벤트가 나쁜 건 아니다. "배치 정상 종료", "백업 성공"도 이벤트입니다. 이벤트는 '경보'가 아니라 '신호'이고, 그중 일부만 대응이 필요합니다.
| 구분 | 인시던트(앞 모듈) | 이벤트(이 모듈) |
|---|---|---|
| 출발점 | 사람의 신고 또는 감지된 장애 | 시스템이 보낸 상태 변화 신호 |
| 좋고 나쁨 | 항상 '나쁜 일'(서비스 저하) | 좋을 수도, 나쁠 수도 있음 |
| 시점 | 보통 이미 영향 발생 후 | 영향 발생 전에 받을 수 있음 |
| 관계 | — | 의미 있는 이벤트가 인시던트로 이어질 수 있음 |
그래서 이벤트 관리의 목표는 단순합니다. 고객이 신고하기 전에, 시스템이 먼저 말하게 한다. 이벤트는 사전 감지의 원료입니다.
이벤트 분류 — 정보·경고·예외
모든 신호를 똑같이 대하면 진짜 신호를 놓친다
이벤트가 하루 수천 건씩 쏟아지는데 전부 똑같이 본다면, 백업 성공 알림과 결제 서버 다운 알림이 같은 줄에 섞입니다. 그래서 이벤트는 대응의 시급함에 따라 세 등급으로 나눕니다. 이것이 이벤트 관리의 가장 기본적인 분류입니다.
| 유형 | 뜻 | 예 | 조치 |
|---|---|---|---|
| 정보(Information) | 정상 동작의 기록. 대응 불필요, 추세·감사용으로 보관 | "야간 배치 정상 종료", "사용자 로그인 성공", "백업 완료" | 기록만 한다. 알림은 보내지 않거나 모아서 본다 |
| 경고(Warning) | 아직 정상이지만 곧 한계에 닿을 수 있는 예측 신호 | "디스크 사용률 85퍼센트 초과", "응답 지연 증가 추세", "큐 적체 증가" | 예방 조치를 계획한다. 비상 대응은 아니다 |
| 예외(Exception) | 이미 정상 범위를 벗어남. 즉시 대응이 필요 | "결제 서비스 응답 없음", "오류율 급증", "디스크 가득 참" | 인시던트로 연결해 즉시 대응·에스컬레이션 |
분류의 실전 감각:
- 정보를 알림으로 쏘지 마라. "로그인 성공" 같은 정보를 매번 알림으로 보내면, 그게 곧 알림 피로의 시작입니다. 정보는 '기록'하되 '깨우지'는 않습니다.
- 경고는 '시간을 버는 신호'다. 경고가 왔을 때 손을 쓰면 예외(=실제 장애)를 막을 수 있습니다. 경고를 무시하는 조직은 늘 예외 단계에서야 움직입니다.
- 예외는 인시던트의 입구다. 예외 이벤트는 대부분 인시던트 생성으로 이어집니다. 다음 절에서 이 자동 연결을 봅니다.
확대
그림: 신호를 정보·경고·예외로 나눠야 진짜 신호를 놓치지 않는다 — 알림 피로의 해법은 알림을 끄는 것이 아니라 정확하게 만드는 것이다.
모니터링 — 능동과 수동, 그리고 무엇을 볼까
이벤트를 만들어내는 눈, 모니터링
이벤트가 '신호'라면, **모니터링(Monitoring)**은 그 신호를 만들어내는 '눈'입니다. 모니터링이 상태를 관찰하다가 의미 있는 변화를 발견하면 이벤트가 발생합니다. 모니터링은 관찰 방식에 따라 둘로 나뉩니다.
- 능동 모니터링(Active): 시스템이 대상에게 주기적으로 '말을 걸어' 상태를 확인합니다. 헬스 체크 요청을 보내 응답·응답시간을 보고, 합성 거래(synthetic, 가짜 사용자 시나리오)를 돌려 결제가 실제로 되는지 확인합니다. 장점은 사용자가 겪기 전에 먼저 안다는 것입니다.
- 수동 모니터링(Passive): 대상이 흘려보내는 신호(로그·메트릭·실제 트래픽)를 받아서 관찰합니다. 실제 사용자 요청의 오류율·지연을 보는 방식이라 '현실'을 반영하지만, 사용자가 이미 겪은 뒤일 수 있습니다.
둘은 경쟁이 아니라 보완입니다. 능동으로 사용자보다 먼저 감지하고, 수동으로 실제 사용자 경험을 확인합니다.
그렇다면 무엇을 모니터링해야 할까요? 깊은 도구 설정은 cloud·kubernetes 트랙의 영역이고, 여기서는 '관리자가 무엇을 봐야 하는가'의 목록을 잡습니다.
| 대상 | 무엇을 보나 | 왜 보나 |
|---|---|---|
| CPU 사용률 | 지속적으로 높은지(예: 90퍼센트 초과 지속) | 처리 한계 임박, 응답 지연의 전조 |
| 메모리 사용률 | 점유율·스왑 발생 | 메모리 고갈 시 프로세스 강제 종료 위험 |
| 디스크 사용률 | 남은 공간(예: 85퍼센트 초과) | 가득 차면 로그·DB 쓰기 실패로 서비스 정지 |
| 오류율(5xx 등) | 전체 요청 중 서버 오류 비율 | 사용자가 실제로 실패를 겪고 있다는 직접 신호 |
| 응답 지연(latency) | 평균보다 상위 백분위(p95·p99) | 평균은 멀쩡해도 일부 사용자는 느릴 수 있음 |
| 가용성(up/down) | 서비스가 응답하는가 | 가장 기본적인 '살아 있나' 신호 |
지연은 평균이 아니라 **상위 백분위(p95·p99)**로 보는 게 핵심입니다. 평균 응답이 0.2초여도 상위 1퍼센트 사용자가 5초를 기다린다면, 그 1퍼센트에게 서비스는 고장 난 것입니다.
임계치에서 인시던트까지 — 자동 연결의 흐름
임계치를 넘으면 알림, 알림이 인시던트가 된다
이벤트가 의미 있는 행동으로 이어지려면 세 단계를 거칩니다. 이 흐름을 설계하는 것이 이벤트 관리의 실체입니다.
- 임계치(Threshold): "어디까지가 정상인가"의 경계선입니다. 디스크 사용률 85퍼센트 초과를 경고, 95퍼센트 초과를 예외로 정하는 식입니다. 임계치가 너무 빡빡하면 알림 폭주, 너무 헐겁면 놓침이 생깁니다.
- 알림(Alert): 이벤트가 임계치를 넘으면 정해진 사람·채널에 알림이 발송됩니다. 누구에게(당직자), 어떤 채널로(메신저·전화), 얼마나 급하게(경고는 채널, 예외는 전화 호출) 보낼지가 정책입니다.
- 인시던트 자동 생성: 예외급 알림은 사람이 받아 적기 전에 자동으로 인시던트 티켓을 생성할 수 있습니다. 이렇게 하면 신고를 기다리지 않고, 알림 시각·대상 서비스·원인 신호가 티켓에 자동 기록됩니다.
정리하면 이렇게 흐릅니다.
| 단계 | 무슨 일이 일어나나 | 예 |
|---|---|---|
| 1. 관찰 | 모니터링이 상태를 측정 | 디스크 사용률을 일 분마다 측정 |
| 2. 이벤트 | 상태 변화가 신호로 발생 | "사용률 96퍼센트" 이벤트 발생 |
| 3. 임계치 비교 | 정상 경계와 비교해 등급 판정 | 95퍼센트 초과 → 예외 |
| 4. 알림 | 정책에 따라 통보 | 당직자에게 전화 호출 |
| 5. 인시던트 | 예외급은 티켓 자동 생성 | "결제 DB 디스크 임박" 인시던트 자동 등록 |
이 자동화가 앞 모듈에서 배운 인시던트 관리와 만나는 지점입니다. 사람의 신고만 기다리던 인시던트의 입구에, 이제 모니터링이 만든 자동 입구가 하나 더 생기는 것입니다.
직접 해보기 — 이벤트 분류와 대응 설계
아래 5건은 모니터링이 발생시킨 이벤트입니다. 각각 (1) 정보·경고·예외 중 무엇이고, (2) 어떤 대응이 적절한지 정해 보세요. 정답은 아래 ObserveBlock에 있습니다.
가. "결제 API 헬스체크 응답 없음 — 연속 3회 실패" (능동 모니터링)
나. "일일 데이터 백업 정상 완료" (배치)
다. "주문 서비스 p99 응답시간이 평소 0.4초에서 2.1초로 증가" (수동 모니터링)
라. "웹서버 CPU 사용률 92퍼센트가 십 분째 지속" (메트릭)
마. "신규 사용자 회원가입 성공" (애플리케이션 로그)
판단 직관: '지금 깨졌나(예외)' / '곧 깨질 신호인가(경고)' / '정상 기록인가(정보)' 세 질문을 순서대로 던집니다.
분류: 정보 / 경고 / 예외 → 대응- 가 = 예외(Exception). 결제는 핵심 서비스이고 응답이 없으므로 즉시 인시던트 자동 생성·당직 호출. 영향 큰 서비스라 우선순위 높게
- 나 = 정보(Information). 정상 동작 기록이므로 대응 불필요. 알림으로 깨우지 말고 기록만 — 단, 백업 실패였다면 예외가 된다
- 다 = 경고(Warning). 아직 동작하지만 p99가 다섯 배로 악화. 추세를 보고 원인(부하·쿼리)을 조사해 예외(장애)로 번지기 전에 손을 쓴다
- 라 = 경고(Warning) 또는 예외 진입 직전. 지속적 고부하는 곧 응답 지연·실패로 이어질 전조. 부하 원인 확인·증설 검토
- 마 = 정보(Information). 정상 동작 기록. 추세 분석용으로 보관하되 개별 알림은 보내지 않는다
- 핵심 감각: 같은 이벤트라도 대상 서비스의 중요도와 정상 경계(임계치)에 따라 등급과 우선순위가 달라진다 — 분류 기준을 미리 합의해 두는 것이 운영의 절반이다
현장에서 자주 보는 함정
증상: 모니터링은 잘 갖춰져 있는데, 알림이 하루 수백 건씩 쏟아집니다. 처음엔 다 보던 팀이 점점 둔감해지고, 결국 메신저 알림을 음소거하거나 채널을 떠납니다. 그러다 진짜 예외 알림(결제 다운)이 그 속에 섞여 들어와도 아무도 즉시 반응하지 못합니다. 이것이 **알림 피로(alert fatigue)**입니다.
원인: 보통 세 가지가 겹칩니다.
- 정보를 알림으로 쐈다 — "로그인 성공", "배치 시작" 같은 정상 신호까지 알림으로 보냄.
- 임계치가 너무 빡빡하다 — 일시적으로 잠깐 넘었다 돌아오는 값에도 매번 알림.
- 상관분석이 없다 — DB 한 대가 죽으면 그에 의존하는 모든 서비스가 각자 알림을 쏴, 한 원인이 수십 건의 중복 알림이 됨.
해결 방향(노이즈를 줄이되, 신호는 살린다):
- 정보는 알림에서 빼고 기록으로 돌린다. 깨우는 알림은 경고·예외에만.
- 임계치를 '지속 조건'과 함께 건다 — "92퍼센트를 십 분 이상 지속" 같은 식으로, 순간 스파이크에 반응하지 않게.
- 상관분석(Correlation)으로 묶는다 — 시간·토폴로지·근본 원인이 같은 알림을 하나로 합쳐, "DB 다운 한 건"으로 보게 한다.
- 중복 억제(de-duplication) — 같은 알림이 반복되면 한 건으로 묶고 횟수만 누적.
알림 피로의 해법은 '알림을 끄는 것'이 아니라 **'알림을 정확하게 만드는 것'**입니다. 알림을 끄면 신호 자체가 사라지지만, 정확하게 만들면 적은 수의 알림이 모두 의미를 갖습니다. 운영자가 알림 하나하나를 신뢰할 수 있을 때, 비로소 모니터링은 제 역할을 합니다.
확대
그림: 노이즈를 줄이되 신호는 살린다 — 정보 알림 제거·지속 조건 임계치·상관분석·중복 억제로 적은 알림이 모두 의미를 갖게 만든다.
심화 — 신호는 있는데 판단이 없다: 관제가 외주가 될 때
심화: 관제실의 알람은 왜 조치로 이어지지 않는가
이벤트 관리 이론은 "신호 → 분류 → 대응"이 한 조직 안에서 매끄럽게 흐른다고 가정합니다. 그런데 한국 기업·공공의 실제 운영 구조에서는 이 흐름이 회사 경계와 권한 경계에서 끊어집니다. 도구가 아니라 구조가 신호를 죽이는 것입니다.
- 관제와 판단의 분리: 24시간 관제는 대개 관제 전문 협력사의 상주 요원이 맡습니다. 이들의 계약상 역할은 "알람 감지 시 매뉴얼에 따라 유선·SMS 통보"까지이고, 판단과 조치 권한은 없습니다. 그래서 "p99가 5배로 뛰었다"는 경고를 봐도 매뉴얼에 없는 패턴이면 통보 대상조차 아닙니다. 신호를 보는 사람은 해석할 권한이 없고, 해석할 사람은 자고 있는 구조 — 이벤트 관리의 성패는 임계치 설계만큼이나 통보 매트릭스와 에스컬레이션 권한 설계에 달려 있습니다.
- 경고 단계 예방 조치의 역설: 경고에 손을 쓰려면 로그 정리·증설·설정 변경 같은 작업이 필요한데, 이는 변경 절차(품의·승인·점검창)를 타야 해서 며칠이 걸립니다. 반면 장애(예외)가 터지면 긴급 변경 권한이 즉시 열립니다. 결과적으로 "고장 나야 고칠 수 있는" 인센티브가 생기고, 조직은 늘 예외 단계에서만 움직이게 됩니다. 성숙한 조직은 경고 대응용 사전 승인 작업 목록(디스크 정리·재기동 등)을 표준 변경으로 등록해 이 역설을 끊습니다.
- 알람 건수가 KPI가 되는 순간: 관제 월간 보고에 "알람 건수"가 실적 지표로 들어가면, 건수를 줄이는 가장 쉬운 방법은 노이즈 개선이 아니라 임계치 상향입니다. 숫자는 좋아지고 감지력은 죽습니다. 봐야 할 지표는 알람 총량이 아니라 사전 감지율(인시던트 중 신고 이전에 모니터링이 먼저 잡은 비율)과 경고 단계 예방 조치 이행률입니다.
- 규모별 풍경: 소규모 조직은 당직자 폰 알림 하나로 돌고, 대기업·공공은 대형 화면이 늘어선 통합관제센터를 둡니다. 그런데 그 대시보드가 방문자 시연용으로만 관리되고 실제 대응은 여전히 전화로 도는 경우가 있습니다 — 화면의 수가 아니라 새벽 2시에 신호가 조치권자에게 닿는 경로가 그 조직의 진짜 모니터링 수준입니다.
상황: 결제 DB 디스크 사용률이 새벽 2시 14분 88%를 넘어 경고가 발생했습니다. 관제 협력사 요원은 규정대로 관제 일지에 기록했습니다 — "02:14 경고 감지. 통보 기준표상 경고 등급은 야간 유선 통보 대상 아님. 익일 오전 보고로 분류." 오전 6시 50분 디스크가 가득 차 결제가 전면 중단됐고, 7시 30분 출근한 운영 담당자가 일지를 보고서야 다섯 시간 전 신호를 발견했습니다. 사후 회의에서 관제 요원은 "매뉴얼대로 했습니다"라고 답했고, 실제로 매뉴얼대로 했습니다.
원인: 사람도 도구도 아닌 통보 기준표의 실패입니다. 3년 전 만들어진 기준표는 "예외=즉시 유선, 경고=익일 보고"로만 나뉘어 있었고, 그 사이 결제 서비스의 야간 거래량은 몇 배로 늘어 "경고가 아침까지 버텨 주는" 전제가 무너져 있었습니다. 더 깊은 원인은 갱신 주체의 부재입니다 — 기준표는 관제 계약서 별첨 문서라 운영팀도 관제사도 서로 상대가 관리한다고 여겼고, 3년간 개정 이력이 없었습니다. 관제 요원에게는 기준표를 벗어나 판단할 권한도, 그럴 유인도 없었습니다(임의 통보로 담당자를 깨웠다가 항의받은 전례가 팀 내에 전승되고 있었습니다).
진단: 이런 구조 문제는 장애 한 건이 아니라 패턴으로 확인합니다. 최근 1년 관제 일지에서 "경고 감지 후 익일 보고로 분류"된 건 중, 다음 날 예외(장애)로 번진 건을 세어 봅니다 — 이 조직은 14건 중 5건이었습니다. 즉 기준표가 다섯 번의 예방 기회를 규정으로 막고 있었던 것입니다. 함께 볼 것: 통보 기준표의 최종 개정일, 야간 연락망의 현행화 여부(퇴사자·번호 변경), 관제 요원이 기준 밖 판단을 한 건수(0건이면 권한이 죽어 있다는 뜻).
해결: ① 통보 기준을 "등급"이 아니라 "등급 × 서비스 중요도 × 추세" 매트릭스로 재설계 — 핵심 서비스(서비스 수준 관리의 SLA 대상)의 경고 중 자원 고갈형(디스크·큐 적체)은 도달 예상 시각을 계산해 야간이라도 즉시 통보. ② 관제 요원에게 "애매하면 깨워라"를 명문화하고, 오탐 통보에 불이익을 주지 않는다는 조항을 관제 계약에 반영. ③ 기준표에 소유자(운영팀장)와 분기 개정 의무를 지정하고, 반기마다 야간 통보 경로를 실제로 시험(새벽 테스트 콜). ④ 월간 보고 지표를 알람 건수에서 사전 감지율·예방 조치 이행률로 교체. 다음 반기, 같은 유형의 자원 고갈 경고 4건이 전부 새벽에 통보·조치되어 장애 0건으로 막혔습니다. 모니터링 체계의 마지막 구간은 소프트웨어가 아니라 문서와 권한입니다.
이벤트·모니터링 관리는 운영(SM) 담당과 서비스데스크가 '수동적 신고 접수'에서 '능동적 사전 감지'로 넘어가는 지점입니다. 발주사·원청의 운영 담당자라면, 협력사(하도급) 엔지니어가 도구를 설치·운영하더라도, **"무엇을 모니터링하고, 임계치는 얼마이며, 어떤 알림을 누가 언제 받고, 알림 노이즈는 어떻게 관리하는가"**를 정의하고 점검하는 것은 관리자의 몫입니다.
현장에서 관리자가 실제로 던지는 질문은 이렇습니다. "핵심 서비스의 가용성·오류율·지연을 보고 있는가?" "경고 단계에서 예방 조치가 실제로 이뤄지는가, 아니면 늘 예외(장애) 단계에서야 움직이는가?" "알림 피로 때문에 진짜 알림을 놓치고 있지는 않은가?" 이 질문에 데이터로 답할 수 있는 운영 조직은 장애를 신고받기 전에 끄고, 그렇지 못한 조직은 늘 고객 전화로 장애를 알게 됩니다.
이 역량은 SLA(서비스 수준 협약)와도 직결됩니다. 가용성 99.9퍼센트를 약속했다면, 그 수치를 '측정'하는 것이 바로 모니터링이고, 위반 전조를 잡는 것이 이벤트 관리입니다. 보고서에 "이번 달 가용성 99.95퍼센트, 경고 12건 중 11건 예방 조치 완료"라고 쓸 수 있는 근거가 여기서 나옵니다.
실전 랩으로 손에 익히기: 이벤트·모니터링 실습 — 이벤트 유형·임계·알림을 설계하고 경보 피로를 방지합니다.
관련 모듈로 더 깊이:
- 가용성·용량 관리 — 모니터링 데이터로 가용성·용량을 관리하는 활동
- 인시던트 관리 — 이벤트 감지에서 인시던트 대응으로 이어지는 흐름
- 서비스 수준 관리 — 모니터링이 측정하는 SLA 가용성·대응 지표
다음 모듈에서는 이렇게 모니터링으로 모은 데이터를 바탕으로, 서비스가 약속한 수준을 유지하도록 관리하는 가용성·용량 관리(서비스가 필요할 때 동작하고, 부하를 감당할 자원을 미리 확보하는 일)를 다룹니다.