사건을 설명하는 알림(Alert) 설계하기

요약 (TL;DR)

• 알림은 모니터링 시스템이 측정값이 임계치를 초과할 때 보내는 메시지이며, 그 가치는 다음 10분 동안 사람이 내릴 결정에 반영됩니다.
• Google의 SRE Workbook에 따르면, 서비스가 한 시간 동안 에러 예산(error budget)의 2%를 소진하면 (소모율 14.4), 알림을 보내야 하며, 6시간 동안 5%를 소진할 때도 마찬가지입니다. 같은 표는 3일 만에 10%를 소진하는 경우 티켓 대기열로 보냅니다.
• 선택한 시간 창(window)은 몇 개의 페이지가 도착할지 결정합니다. 왜냐하면 99.9% 목표의 10분 간격 창은 월간 예산의 0.02%를 소모하는 이벤트에 대해 알림을 발생시키기 때문입니다.
• 그룹화(Grouping), 억제(inhibition), 무음 처리(silences) 및 뮤트 타이밍(mute timings)은 하나의 고장 난 종속성이 수백 개의 알림으로 변하는 것을 막는 메커니즘입니다.
• 페이지에는 증상(symptom), 범위(scope), 시간 창(time window), 런북(runbook)을 담아야 하며, 온콜(on call) 담당자의 이름을 명시해야 합니다.
• 소규모 팀을 위한 시작 구성은 페이지 수준의 임계치 하나, 티켓 수준의 임계치 하나, 그리고 주간 검토가 필요하며, 알림이 제 역할을 하는지 측정하려면 실제로 어떤 것이 발생했는지 읽어보는 것입니다.

알림에 포함되어야 할 내용

알림은 불편한 시간에 휴대폰으로 도착하는 메시지이며, 독자는 세 가지 질문을 갖게 됩니다. 사용자가 현재 무엇을 충족시키고 있는지, 서비스의 얼마나 많은 부분이 영향을 받았는지, 그리고 지침이 어디에 있는지입니다. 이 질문들에 답하는 알림은 업무로 변환됩니다. 단순히 메트릭 이름(metric name)을 보고하는 알림은 검색으로 변환될 뿐입니다.

Prometheus의 Alertmanager 문서는 이 컴포넌트가 받는 알림들을 어떻게 처리하는지 설명합니다. 즉, 중복 제거(deduplicates)하고, 그룹화하며, 이메일, PagerDuty 또는 OpsGenie와 같은 수신자에게 라우팅합니다. 중복 제거 및 라우팅은 이미 존재하는 알림에 작용하므로, 설계 결정은 시스템이 말할 가치가 있다고 판단하는 시점을 결정하는 상위 스트림(upstream)의 알림 규칙에 놓입니다.

Capture of the official Prometheus Alertmanager documentation page, showing the component description and the Grouping, Inhibition and Silences sections.

공식 Prometheus Alertmanager 문서(prometheus.io/docs/alerting/latest/alertmanager/, 2026-10-14 검색): 해당 컴포넌트 자체의 그룹화(grouping), 억제(inhibition), 그리고 침묵(silences)에 대한 설명.

가상의 시나리오를 가정해 봅시다. 여섯 명이 결제 페이지, 결제 제공업체, 야간 재고 동기화 작업이 있는 온라인 상점을 운영합니다. 결제 제공업체의 오류 카운터가 0을 넘어서면 알림(page)을 발생시키는 규칙과, 체크아웃 성공률이 목표치보다 낮아지면 알림을 발생시키는 규칙이 있습니다. 첫 번째 규칙은 의존성(dependency)을 설명하고, 두 번째 규칙은 비즈니스가 무엇을 잃고 있는지 설명합니다.

번 레이트(burn-rate) 창이 알림 수를 결정하는 방식

창 크기(Window size)는 알림 볼륨에 큰 영향을 미치며, SRE Workbook에서 이를 정량화했습니다. 예시는 99.9% 목표치를 가진 10분짜리 창으로 시작하여 비용을 보여줍니다: 0.1%의 오류율은 월별 오류 예산의 0.02%를 소비하면서 알림을 발생시킵니다. 창을 넓히면 정밀도가 향상되는데, 이는 알림이 더 큰 예산 소모를 요구하기 때문입니다. 저자들이 권장하는 시작점은 번 레이트 프레이밍(burn-rate framing)으로, 여기서 임계값(threshold)은 서비스가 목표치 대비 오류 예산을 얼마나 빨리 소비하는지를 설명합니다.

구체적인 수치는 암기할 가치가 있습니다. 30일 예산의 2%를 한 시간에 사용했다는 것은 14.4의 번 레이트와 같고, 6시간에 5%를 사용했다는 것은 6과 같습니다. 이 둘 모두 알림(paging) 경로에 포함되어야 합니다. 3일 동안 10%를 사용했다면 번 레이트는 1이 되며, 워크북은 이를 티켓 대기열(ticket queue)에 배치하는데, 이는 근무일로 흡수할 수 있는 느린 누출(slow leak)에 적합합니다. 문제가 몇 시간 만에 예산을 소진하는 경우, 능동적인 알림이 중단을 얻게 됩니다.

Netics editorial diagram of the burn-rate thresholds recommended for paging and tickets, showing 14.4x for 2% of the budget in one hour, 6x for 5% in six hours and 1x for 10% in three days.

Netics 편집 다이어그램: SRE Workbook의 표 5-6에 제시된 세 가지 소진율(burn-rate) 임계값과 창(window)을, 각각이 정당화하는 알림에 매핑한 내용입니다.

하나의 개선 사항으로 남아있는 대부분의 격차를 해소할 수 있습니다. 멀티윈도우 알림은 짧은 기간과 긴 기간을 함께 확인하며, 그 지속 시간의 1/12을 작업 지침으로 삼아 오류가 멈춘 직후 페이지가 작동을 멈춥니다. 워크북의 예시 페이지는 소진율이 이전 한 시간과 이전 5분 동안 모두 14.4를 초과할 때 발생합니다. 같은 섹션에는 실제 사고가 발생하면 스스로 비용을 회수하는 경고도 추가됩니다: 중첩되는 창은 동일한 사고를 설명하므로, 하나의 결함으로부터 세 개의 알림이 발생하는 것을 방지하기 위해 억제(suppression)가 필요합니다.

그룹화 및 억제를 통해 깨진 종속성을 단일 알림으로 통합하기

깨진 종속성은 그것에 의존하는 항목의 수에 비례하여 알림을 생성하며, Alertmanager는 이 산술을 평탄화(flatten)하기 위해 존재합니다. 그 그룹화(grouping) 개념은 유사한 성격의 알림들을 하나의 알림으로 모으고, 문서에서는 정확히 이러한 시나리오를 제시합니다: 네트워크 분할로 인해 서비스 인스턴스의 절반이 데이터베이스에 도달하지 못하게 되고, 수백 개의 알림이 감지 계층을 빠져나갑니다. 이들을 클러스터 및 알림 이름별로 그룹화하면 여전히 영향을 받는 인스턴스를 명시하는 하나의 간결한 메시지가 생성됩니다.

억제(Inhibition)는 다른 각도에서 동일한 문제에 접근합니다. 알림이 전체 클러스터가 도달할 수 없다고 상태를 표시할 때, Alertmanager는 더 큰 알림이 계속 발생하는 동안 해당 클러스터에 대한 다른 모든 알림을 음소거(mute)할 수 있습니다. 이 억제는 설정에서 단 한 번 선언되며, 대응자가 동일한 장애를 설명하는 백 개의 알림을 읽어야 하는 작업을 면제해 줍니다.

[

Capture of the official Grafana Alerting documentation page, showing the alerting overview and its notification, silence and inhibition sections.](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F4g2sqg2sfbedzl07jk1o.png

공식 Grafana Alerting 문서(grafana.com/docs/grafana/latest/alerting/, 2026-10-14 검색): 연락 지점(contact points), 알림 정책(notification policies), 음소거 시간(mute timings), 무음 처리(silences) 및 억제 규칙(inhibition rules)을 별도의 제어 기능으로 분리했습니다.

'보기 싫은 경우(ugly case)'에 대한 하드캡이 존재합니다. Alertmanager는 단일 알림 이름이 가질 수 있는 활성 알림 수를 제한하여, 한계에 도달하면 새로운 알림은 폐기하지만 이미 알고 있는 알림의 심장 박동 신호(heartbeats) 처리는 계속하며, 폐기된 모든 항목에 대한 카운터를 노출합니다. 이 문서는 해당 기능을 리시버 보호 기능으로 설명합니다. 언급된 사용 사례는 같은 알림이 한 번에 예기치 않게 많이 도착하는 경우입니다.

무음 처리와 음소거 시간은 계획된 작업을 다룹니다

무음 처리(Silences)는 선언된 기간 동안 알림을 비활성화하며, 이는 알림 자체의 레이블과 일치합니다. Alertmanager는 이를 웹 인터페이스에서 구성합니다. Grafana의 알림 문서는 같은 계열의 제어 기능들을 분리하여 다룹니다: 반복되는 기간에 대한 음소거 시간(mute timings) 및 활성 시간 간격, 일회성 유지보수를 위한 무음 처리(silences), 그리고 더 큰 알림이 이미 상황을 포괄하는 경우를 위한 억제 규칙(inhibition rules)입니다.

설계 질문은 누가 이러한 기능을 생성할 수 있는가입니다. 변경 기간을 초과하여 지속되는 무음 처리는 타임스탬프가 찍힌 사각지대(blind spot)이 되므로, 팀에게는 감사 추적 가능하게 만드는 두 가지 필드, 즉 이유(reason)와 만료일(expiry)가 필요합니다. Grafana의 문서는 무음 처리 접근을 규칙 편집 권한과는 별개의 자체적인 권한으로 취급합니다.

Capture of the official Google SRE Workbook chapter Alerting on SLOs, showing the introduction, alerting considerations, precision and recall.

Google SRE Workbook의 'SLO 기반 알림(Alerting on SLOs)' 장(sre.google/workbook/alerting-on-slos/, 2026-10-14 검색): 위에서 언급된 번 레이트 임계값이 나오는 출처가 되는 장입니다.

응답자가 03:00에 여는 runbook

스스로를 설명하는 페이지는 네 가지 필드로 시작합니다. 사용자 용어의 증상(symptom), 숫자로 표현되는 범위(scope), 측정값이 포함하는 기간(window), 그리고 지침서 링크입니다. 앞의 세 가지는 알림 페이로드(alert payload)에서 가져옵니다. 네 번째는 디시플린(discipline)에서 가져오는데, 빈 페이지를 가리키는 런북(runbook) 링크는 아예 없는 것보다 더 나쁩니다.

소유자(owner)가 다섯 번째 필드입니다. 알림은 이를 처리할 수 있는 팀에게는 의미를 지니지만 다른 모든 사람들에게는 노이즈일 수 있으므로, 라우팅 결정은 해당 규칙을 생성하는 주체에 속합니다. Alertmanager의 라우팅 트리(routing tree)는 이러한 소유권을 설정 파일에 유지하며, 이는 직원 변경에도 영향을 받지 않습니다.

유용한 테스트는 비용이 들지 않습니다. 지난달 가장 자주 발생했던 세 가지 알림에 대한 런북을 열고 잠들어 있는 사람의 입장에서 읽어보세요. 텍스트가 메트릭 이름으로 시작하는 곳에서는 그 알림이 아직 완성되지 않은 것입니다.

소규모 팀을 위한 시작 설정

네 가지 결정만으로도 소규모 팀이 다루는 대부분의 문제를 해결할 수 있습니다. 체크아웃 성공률이나 한 시간 내 작업 완료와 같이 사용자에게 노출되는 여정(journey)별로 하나의 목표를 정하세요. 그에 대해 두 개의 알림 규칙을 작성합니다. 하나는 페이지잉 경로(paging path)의 14.4 버닝 레이트 임계값(burn-rate threshold)에서, 다른 하나는 티켓의 1 임계값에서 설정합니다. 14.4 규칙은 온콜(on-call) 경로로 라우팅하고, 1 규칙은 티켓 대기열로 라우팅하며, 둘 다 서비스별로 그룹화하고, 단일 장애가 온콜 채널을 범람시키지 않도록 알림 이름별 제한(per-alert-name limit)을 설정합니다. 그리고 다음 주 온콜 담당자를 지정하고 알림 어노테이션(annotation)에 런북 링크를 넣으세요.

Netics editorial diagram of the four steps in designing an alert that explains an incident: choosing the symptom, the burn-rate window, the grouping rule and the named responder with the runbook.

Netics 에디토리얼 다이어그램: 사용자가 마주하는 증상부터 알림에 첨부된 런북까지, 팀이 작업하는 순서대로 배열된 네 가지 설계 단계.

이 첫 번째 버전은 설정(configuration)을 작게 유지하기 위해 워크북의 두 번째 페이지링 계층(paging tier), 즉 6시간 동안 6개씩 소모되는 비율(burn rate)을 의도적으로 미루고 있으며, 이 계층은 두 가지 규칙이 제자리를 잡으면 페이지링 경로에 합류합니다. 그때까지는 14.4페이지 미만의 소모율로 아무도 관심을 갖지 않습니다.

페이지가 가치를 창출하는지 측정하기

중요한 수치들은 발화(firing) 기록에 있습니다. 지난달 몇 개의 페이지가 도착했는지, 그 중 몇 개가 조치(action)로 이어졌는지, 그리고 몇 개가 노이즈로 닫혔는지를 계산하세요. 작업으로 절대 이어지지 않는 페이지는 티켓(ticket)으로 강등될 후보이며, 반복적으로 장애(outage)로 변하는 알림(alert) 티켓은 승격될 후보입니다.

검토는 주간 단위로 짧게 유지하세요. 가장 빈번한 세 가지 알림을 읽고, 그들의 창(window)을 소모율 표와 비교하며, 런북(runbook)이 여전히 현재 아키텍처를 설명하는지 확인하세요. 이 단계를 거치지 않으면 침묵 목록(silence list)이 커지고 채널에 대한 신뢰가 줄어들며, 이는 같은 문제의 비용이 많이 드는 버전입니다.