문제
리텐션 서비스 3개의 운영 상태와 비즈니스 이상을 알리는 채널이 서비스별로 17개 흩어져 있었습니다.
알림을 받는 사람은 개발자와 비개발 담당자로 나뉘는데, 채널은 받는 사람 기준으로 나뉘어 있지 않았습니다.
그래서 문제를 “누가 받는가(개발자, 비개발 담당자)와 무슨 역할의 알림인가, 두 축으로 채널을 다시 짜는 것”으로 정했습니다.
접근
- 수집은 각 서비스가 지표(Prometheus)와 로그(Loki)를 내보내고, 알림 저장소는 조회 쿼리, 패널, 알림만 정의하도록 책임을 나눴습니다.
- 채널 구조는 7개 안을 식별성 25%, 소음 감소 25%, 확장성 20%, 받는 사람 분리 20%, 운영 부담 10%로 가중 비교하고, 정보 품질과 운영 단순성 두 축의 사분면 그림으로도 봤습니다. 1위는 역할 중심 채널에 받는 사람을 나눈 안이었습니다.
- 심각도는 대응 강도로 나눴습니다: 긴급은 채널 알림, 담당자 호출, 조건부 장애 선언까지, 높음은 채널 알림과 담당자 호출까지, 통지는 채널 알림만 보냅니다.
결정
- 채널 5개: 개발자용 3개(오류, 배치 실패, 모니터링), 비즈니스 담당자용 1개(이상 알림), 공지용 1개로 나눴습니다.
- 규칙 36개: 긴급 19개, 높음 4개, 통지 13개로 나눴습니다.
- 라우팅: 받는 곳 3종(서비스 묶음별 채널과 호출 2종, 전체 통지용 채널)으로 서비스와 심각도에 따라 나눴습니다.
결과
- 알림 채널은 17개에서 5개로 줄었고, 규칙 36개가 심각도 3단계로 정리됐습니다.
기록과 자동화
- 문서: 채널 구조를 고른 가중 결정표(사분면 그림 포함)를 남겼습니다.
- 누가 쓰나: 개발자는 오류·배치 실패·모니터링 채널을, 비개발 담당자는 비즈니스 채널을, 당번 담당자는 호출을 받습니다.
배운 점
- 구조를 바꾸는 결정은 대안과 기준을 가중 결정표로 비교해 고른 이유를 남깁니다.
- 상황: 알림 채널이 서비스별로 17개 흩어져 있어 어떤 구조로 모을지 정해야 했습니다.
- 한 일: 7개 안을 기준 5개(식별성, 소음 감소, 확장성, 받는 사람 분리, 운영 부담)로 가중 비교했습니다.
- 결과: 역할 중심 채널에 받는 사람을 나눈 안을 골라 채널을 17개에서 5개로 줄였습니다.