소개

심각한 인시던트 동안 온콜을 해본 적이 있다면, 이런 상황이 낯설지 않을 것입니다. 휴대폰은 끊임없이 진동하고, Slack 채널은 폭발하듯 메시지가 쌓이고, 대시는 온통 빨간색으로 물들며, 한꺼번에 열 개가 넘는 P1 알림이 동시에 울립니다. 그 와중에 정말 중요한 신호는 묻혀버리고, 대응은 늦어지고, 스트레스는 치솟습니다.

이것이 바로 **알림 피로(alert fatigue)**입니다. 끊임없고 시끄러운 알림이 온콜 엔지니어를 과부하 상태로 몰아넣어, 긴급한 것과 무시해도 되는 것을 구분하기 어려워지는 현상입니다. 여기서 생기는 결과는 단순한 번아웃이 아니라, 다운타임 증가, SLA 미준수, 그리고 실제 비즈니스 리스크입니다.

이 글에서는 의외로 저기술이지만 강력한 도구인 **종이 인시던트 스토리 스위치보드(Paper Incident Story Switchboard)**를 소개합니다. 이것은 포스트잇과 실(또는 펜)만으로 **콜 라우팅 벽(call‑routing wall)**을 만들어, 복잡한 자동화를 도입하기 전에 알림 시스템을 모델링하고, 재설계하고, 디버깅할 수 있게 해주는 물리적이고 촉각적인 도구입니다. 이 과정에서 AI 기반 알림 상관관계 분석(alert correlation), 지능형 우선순위화, 그리고 태블탑(tabletop)·재해 복구(disaster recovery) 템플릿 같은 구조화된 계획 도구와도 어떻게 연결되는지 살펴보겠습니다.

문제: 알림 피로와 경쟁하는 알람들

현대 시스템은 수천 개의 신호를 쏟아냅니다. 로그, 메트릭, 트레이스, 헬스 체크, 서드파티 상태 알림 등 정말 다양합니다. 조금이라도 수상해 보이면 일단 페이지를 보내고 싶어지기 쉽습니다.

시간이 지나면 이런 현상이 쌓여 다음과 같은 상황을 만듭니다.

• 과도한 알림 볼륨: 엔지니어가 끊임없이 호출되지만, 상당수는 알아서 복구되는 이슈입니다.
• 중복 페이지: 하나의 근본 원인이 여러 도구와 여러 팀에 중복 알림을 발생시킵니다.
• 경쟁하는 심각도: 동시에 여러 개의 “크리티컬” 알림이 뜨지만, 무엇이 진짜 중요한지 알기 어렵습니다.
• 둔감해짐: 모든 것이 긴급해 보이면, 결국 아무것도 긴급하게 느껴지지 않습니다.

이 문제를 체계적으로 다룬 팀들은 종종 극적인 결과를 얻습니다. 알림 볼륨을 90% 이상 줄이고, 평균 복구 시간(MTTR)을 수 시간에서 수 분으로 단축하기도 합니다. 하지만 거기까지 가려면, 무엇이 언제 왜 울리는지, 알림 플로우를 깊이 이해해야 합니다.

그 지점에서 종이 인시던트 스토리 스위치보드가 등장합니다.

종이 인시던트 스토리 스위치보드란?

여러분의 온콜 우주를 표현하는 큰 벽(또는 화이트보드)을 떠올려 보세요.

가장 왼쪽에는 신호의 소스가 있습니다. (모니터링 도구, 로그, SLO 번 레이트 알림 등)

중간에는 알림 처리와 라우팅 영역이 있습니다. (그루핑, 중복 제거, AI 기반 상관관계 분석, 에스컬레이션 규칙 등)

오른쪽에는 수신자가 있습니다. (온콜 엔지니어, 인시던트 채널, 런북, 인시던트 커맨더 등)

이제 다음과 같이 해 봅니다.

• 각 알림 타입을 종이 카드나 포스트잇으로 만듭니다.
• 알림이 도구에서 사람에게 이동하는 경로를 와이어(실이나 펜 선)로 그립니다.
• 그루핑 규칙, 라우팅 규칙, 에스컬레이션 경로, 서프레션(suppression) 로직은 스위치(또 다른 포스트잇)로 표현합니다.

이렇게 하면 저기술이지만 촉각적인 콜 라우팅 벽—즉, 인시던트 스토리를 위한 스위치보드가 만들어집니다.

이 물리적인 맵을 통해 다음과 같은 것을 쉽게 파악할 수 있습니다.

• 알림이 어디서 퍼져나가며 곱절로 늘어나는지
• 중복되거나 가치가 낮은 페이지는 어디인지
• 어떤 알람들이 서로 관심을 두고 경쟁하는지
• 더 똑똑한 그루핑, 우선순위, 자동화 규칙을 어떻게 설계할지

즉, 자동화하기 전에 인시던트와 알림 플로우를 스토리보드화하는 셈입니다.

1단계: 지금의 알림 혼돈을 그대로 맵에 옮기기

먼저 이상향이 아니라, 지금 실제 상태를 담는 것부터 시작합니다.

1. 최근 1주일~4주일간 인시던트 수집하기
   특히 고통스러웠던 사례를 골라 보세요. 각 인시던트마다 다음을 정리합니다.

   • 발생한 알림(타임스탬프 포함)
   • 영향받은 서비스/컴포넌트
   • 누가 어떤 방식으로 페이지를 받았는지 (PagerDuty, Opsgenie, SMS, Slack 등)
   • Acknowledge와 해결까지 걸린 시간

2. 알림 카드 만들기
   각 알림 타입마다 카드를 하나씩 만듭니다. (각 인스턴스가 아니라, 유형 기준)

   • 이름: “API 5xx 비율 스파이크”, “DB 리플리카 지연” 등
   • 소스 도구: Prometheus, Datadog, 클라우드 모니터 등
   • 현재 설정된 심각도(severity)
   • 일반적인 발생 빈도: “매일”, “주 1회”, “배포 때만” 등
   • 액션 가능성(actionability): 온콜이 무엇을 해야 하는지

3. 벽 구성하기

   • 왼쪽 컬럼: 도구와 소스 (도구별 섹션)
   • 가운데: 현재 라우팅과 에스컬레이션 흐름 (이메일 → Slack → 온콜 로테이션 등)
   • 오른쪽 컬럼: 사람 수신자 (앱 온콜, DB 온콜, SRE, 인시던트 커맨더, 리더십 등)

4. 실제 플로우 그리기
   각 알림 카드를 소스 → 라우팅 → 사람으로 연결합니다. ‘정리해서 예쁘게’ 그릴 필요는 없습니다. 하나의 이벤트가 8개의 페이지를 만든다면, 8개 모두 그립니다.

이제 여러분은 알림 혼돈의 잔인할 정도로 솔직한 전체 그림을 갖게 됩니다.

2단계: 노이즈, 충돌, 공백 찾기

이제 벽을 앞에 두고 몇 가지 실제 인시던트를 스토리처럼 따라가 봅니다.

“02:14에 서비스 A의 레이턴시가 급상승했다. 가장 먼저 무엇이 울렸지? 어디로 갔지? 누가 페이지를 받았지? 그 다음에 무슨 일이 일어났지?”

다음과 같은 것들을 찾아보세요.

• 중복 경로
  같은 상태를 설명하는 여러 알림이 각각 사람을 따로 페이지하고, 묶이지 않고 있는 경우.

• 비(非)액션성 페이지
  거의 사람이 개입할 필요가 없는 알림. (항상 스스로 회복되는 “CPU > 80% for 30s” 같은 것)

• 알림 폭주(alert storm)
  하나의 장애가 수십 개의 알람으로 폭발하는 경우. (모든 다운스트림 서비스, 여러 도구에서 한꺼번에 터지는 패턴)

• 상충하는 우선순위
  둘 다 “크리티컬”로 설정되어 있지만, 실제 비즈니스 임팩트는 명백히 다르게 느껴지는 두 알림.

• 블라인드 스팟
  심각한 인시던트였는데 알림이 늦거나 부실했던 부분. 고객이 먼저 제보할 때까지 아무도 페이지를 받지 못한 영역.

이 지점들을 색깔 스티커나 기호로 표시합니다.

• 빨간 점: 노이즈가 많거나 중복이 심한 곳
• 노란 삼각형: 소유권이 모호하거나 헷갈리는 곳
• 파란 사각형: 그루핑/상관관계 후보 영역

이 시각적인 분류가 이후 시스템 재설계의 기반이 됩니다.

3단계: 더 똑똑한 그루핑과 우선순위 설계

이제 벽을 더 나은 스위치보드로 바꾸는 단계입니다.

3.1 증상과 스토리 단위로 묶기

신호 하나당 알림 한 개에서 벗어나, 인시던트 단위 번들로 묶습니다.

• 알림을 다음 기준으로 그룹화합니다.

  • 서비스 또는 서브시스템 (API, 결제, 인증 등)
  • 고객 영향 (결제 실패, 로그인 문제 등)
  • 공유된 근본 원인 (데이터베이스 장애, 네트워크 분리 등)

• 다음과 같은 규칙을 설계할 수 있습니다.

  • “3분 안에 결제 API 관련 알림이 5개 이상 발생하면 하나의 인시던트로 묶고, 결제 온콜에게 한 번만 페이지한다.”
  • “DB 프라이머리가 다운되면, 다운스트림의 ‘DB 연결 불가’ 알림은 억제하거나, 메인 인시던트의 자식(child) 알림으로 표시한다.”

종이 스위치보드의 가운데 영역에 새 그루핑 노드를 그려서 여러 선을 한데 모읍니다.

3.2 우선순위 다시 생각하기

모든 알림이 사람을 깨워야 하는 것은 아닙니다. 명확한 티어를 만듭니다.

• P1 / 크리티컬: 현재 고객 영향이 크고, 데이터 손실이나 대규모 보안 사고가 걸려 있는 경우.
• P2 / 높음: 치명적이진 않지만 성능 저하 등 눈에 띄는 문제. 근무 시간 내 처리 또는 부담이 덜한 온콜 정책.
• P3 / 정보성: 즉각적인 인적 개입이 필요 없는 것. 대시보드나 일일 리포트로 모아서 전달.

각 알림 카드를 “지금 설정된 심각도”가 아니라, 실제로 되어야 할 우선순위 기준으로 업데이트합니다. 많은 팀이 이 과정을 통해 현재 “P1”로 지정된 알림의 절반 이상이 사실은 다운그레이드되어야 한다는 것을 깨닫습니다.

목표는 단순합니다. 진짜 긴급하고 액션 가능한 알림만 사람이 잠에서 깨게 만드는 것입니다.

4단계: AI 기반 상관관계와 라우팅(개념 설계)

종이 실습을 마치면, 이후 자동화를 위한 **청사진(블루프린트)**이 생깁니다.

현대 인시던트 관리 도구(또는 자체 파이프라인)는 AI를 활용해 다음을 수행할 수 있습니다.

• 관련 알림들을 하나의 인시던트로 상관관계 분석 (시간, 서비스 토폴로지, 과거 인시던트 이력 등을 활용)
• 부모 인시던트가 식별된 이후, 중복 알림을 서프레스
• 과거 패턴을 기반으로 인시던트를 가장 가능성 높은 담당 팀에게 자동 라우팅
• 이전 인시던트 서술과 비교해, 가능한 근본 원인 후보를 제안

벽 위에서는 이를 특수 노드로 표현할 수 있습니다.

• “AI Correlator”: 여러 알림을 입력받아 하나의 인시던트를 만들어 내는 노드
• “AI Router”: 가장 가능성 높은 온콜 오너와 채널을 선택하는 노드

실제로 “AI Correlator”라고 적힌 포스트잇을 붙이고, 어떤 알림들이 이 노드를 통해 하나로 합쳐질지 그려 보세요. 이렇게 하면 AI 도입 계획이 추상적인 기능 목록이 아니라 실제 플로우에 기반한 설계가 됩니다.

이를 신중하게 구현한 팀은 다음과 같은 효과를 얻기도 합니다.

• 사람에게 도달하는 노이즈 알림이 90% 이상 감소
• 대응자가 50개의 조각난 알림이 아니라, 하나의 일관된 인시던트 스토리에 집중할 수 있어 MTTR이 수 시간에서 수 분으로 단축

5단계: 태블탑 연습과 재해 복구 계획과의 연결

종이 스위치보드는 그 자체만으로도 강력하지만, 구조화된 사전 준비와 함께 사용할 때 진가를 발휘합니다.

5.1 태블탑(Tabletop) 연습

인시던트 대응 태블탑 연습 템플릿을 활용해, 새로 설계한 스위치보드를 기준으로 가상 인시던트를 돌려 봅니다.

• 템플릿에서 시나리오 하나를 고릅니다. (예: “부분 리전 장애”, “결제 게이트웨이 레이턴시 스파이크”)
• 다음을 따라가며 검증합니다.
  • 지금 설계대로라면 어떤 알림이 뜰까?
  • 어디로 라우팅될까?
  • 누가 페이지를 받을까?
  • 그 다음 대응 플로우는 어떻게 이어질까?
• 확인해야 할 것들:
  • 그루핑이 충분히 공격적으로 되어 있는가?
  • 첫 페이지를 받는 팀이 정말 ‘맞는’ 팀인가?
  • 명확한 인시던트 커맨더와 전용 채널이 있는가?

태블탑 연습을 통해, 새 스위치보드 설계의 구멍을 새벽 3시에 실제로 터지기 전에 미리 발견할 수 있습니다.

5.2 재해 복구(DR) 템플릿

마찬가지로, 재해 복구(DR) 템플릿은 알림과 복구 전략을 정렬시키는 데 도움을 줍니다.

• 각 DR 시나리오에 대해 다음을 정의합니다.
  • 핵심 탐지 신호 (SLO 번 레이트, 페일오버 트리거, 복제 상태 등)
  • 필요한 복구 단계와 담당자
  • RTO/RPO 같은 시간 목표와, “너무 늦은” 상태의 기준

이 탐지 신호들을 벽 위 카드로 만들어 올리고, 다음을 확인합니다.

• 적절한 라우팅이 되어 있는가? (올바른 대응자에게 도달하는가?)
• 대규모 인시던트 동안 다른 노이즈에 묻혀버리지 않는가?

이 과정을 통해 설계–연습–회복탄력성(resilience) 사이의 선순환을 구축할 수 있습니다.

사람 이야기: 번아웃을 막으면서 신뢰성 지키기

알림 튜닝은 겉보기에 기술적인 일처럼 보이지만, 실제로는 사람의 문제입니다.

알림 노이즈가 심하면:

• 온콜 엔지니어는 수면의 질이 떨어지고, 온콜 순번을 두려워하게 됩니다.
• 팀은 알림을 무시하거나 채널을 음소거(snooze)하기 시작합니다.
• 이직률이 높아지고, 어렵게 쌓은 시스템 지식이 함께 빠져나갑니다.

반대로, 종이 인시던트 스토리 스위치보드 같은 도구로 불필요한 알림을 줄이고 고가치 신호에만 집중하면:

• 엔지니어의 웰빙과 지속 가능성을 지킬 수 있고,
• 중요한 신호가 더 잘 드러나기 때문에 신뢰성을 유지하거나 오히려 향상시키며,
• 인시던트 리뷰와 지속적 개선에 쓸 수 있는 여유를 확보하게 됩니다.

이는 시스템의 목소리를 묵살하는 것이 아니라, 또렷하게 말하도록 가르치는 것에 가깝습니다.

결론: 종이로 프로토타입하고, 자신 있게 자동화하라

새로운 도구를 하나 더 도입하거나 복잡한 알림 라우팅 규칙을 작성하기 전에, 잠시 멈추고 종이 스위치보드로 여러분의 인시던트 스토리를 만들어 보세요.

다음과 같은 과정을 거치면서:

• 실제 알림 플로우와 온콜 경로를 맵에 옮기고,
• 노이즈, 충돌, 공백을 식별하고,
• 더 똑똑한 그루핑과 우선순위를 설계하고,
• AI 기반 상관관계·라우팅 개념을 레이어링하고,
• 태블탑과 재해 복구 템플릿으로 검증하면,

고객과 엔지니어 모두에게 도움이 되는 알림 시스템에 대한, 명확하고 공유 가능한 청사진을 만들 수 있습니다.

그 다음에야, 기존 도구든 새로운 AI 기반 플랫폼이든, 어떤 자동화를 구현하더라도 훨씬 덜 위험하고 훨씬 더 효과적입니다.

종이 인시던트 스토리 스위치보드가 인시던트를 알아서 해결해 주지는 않습니다. 하지만 팀이 혼돈을 눈에 보이는 형태로 꺼내고, 손으로 만지며 구조화할 수 있게 해 줍니다. 그리고 이것이야말로, 온콜 경험을 탄탄하고, 인간적이며, 좋은 의미에서 지루할 정도로 안정적인 상태로 만드는 첫걸음입니다.