Rain Lag

아날로그 인시던트 스토리 ‘날씨 테이블’: 온콜 주간 위로 종이 폭풍 전선을 굴리는 법

테이블탑 인시던트 시뮬레이션을 ‘온콜 주간의 일기예보’로 만드는 아날로그 날씨 테이블 기법으로, 반복 가능한 실험·데이터·시각화를 통해 실제 보안 개선과 이해관계자 정렬까지 이어가는 방법을 소개합니다.

아날로그 인시던트 스토리 ‘날씨 테이블’: 온콜 주간 위로 종이 폭풍 전선을 굴리는 법

현대 인시던트 대응은 사방에서 폭풍이 몰려오는 그린 스크린 앞에 서 있는 기분일 때가 많습니다. 피싱 소나기, 랜섬웨어 전선, SaaS 장애, 제로데이 번개까지. 하지만 TV 일기예보와는 달리, 우리의 “예측”은 종종 **감(感)**에 가깝습니다. 이번 분기가 지난 분기보다 더 바쁜 것 같고, 지난달에 바꾼 플레이북이 도움이 된 것 같다고 느낍니다. 하지만 느낌만으로는 부족합니다.

여기서 등장하는 것이 바로 **아날로그 인시던트 스토리 ‘날씨 테이블(Weather Table)’**입니다. 종이·화이트보드 기반의 매우 단순한 기법이지만, 테이블탑 시뮬레이션을 규율 있는, 반복 가능한 실험으로 바꾸고, 명확한 지표·더 나은 온콜 설계·강력한 툴 개선으로 이어지게 해 줍니다.

이 글에서는 다음을 다룹니다.

  • 테이블탑 연습을 반복 가능한 데이터 기반 프로세스로 바꾸는 법
  • 시간이 지나도 비교 가능한 방식으로 인시던트 “날씨” 데이터를 수집하는 법
  • 어떤 이해관계자라도 패턴을 직관적으로 이해할 수 있게 결과를 시각화하는 법
  • 우선순위가 명확한 액션 아이템을 도출하는 스토리로 결과를 제시하는 법
  • 실제 “폭풍 전선” 패턴에 맞게 온콜 스케줄을 설계하는 법
  • 사람 중심 프로세스로 인시던트 커뮤니케이션 툴을 선택하고 개선하는 법

‘혼돈 연극’에서 반복 가능한 실험으로

많은 테이블탑 인시던트 연습은 한 번 하고 끝나는 연극에 가깝습니다. 시나리오는 교묘하고, 토론은 치열하며, 문서에 몇 줄 메모가 남지만 그 뒤로는… 체계적인 것은 아무것도 없습니다.

이를 바꾸려면, 각 시뮬레이션을 다음과 같은 반복 가능한 실험으로 다뤄야 합니다.

  1. 명시적인 목표 설정
    예시:

    • “데이터 유출 문제를 인지하는 첫 번째 신호까지 걸리는 시간을 측정한다.”
    • “현재 페이징 규칙이 올바른 사람을 깨우는지 평가한다.”
  2. 고정된 구조
    매번 일관된 구조를 사용합니다.

    • 시나리오 브리프
    • 타임라인 인젝션 이벤트 (T+5, T+15, T+30…)
    • 예상 행동 vs 실제 행동
    • 디브리핑(회고) 질문
  3. 표준화된 데이터 필드
    매번 반드시 기록할 항목을 미리 정합니다.

    • 탐지까지의 시간(Time to detect, Ttd)
    • 트리아지(초기 분류/평가)까지의 시간
    • 올바른 팀이 개입할 때까지의 시간
    • 주요 결정 및 격리(Containment)까지의 시간
    • 사용된 커뮤니케이션 채널의 종류와 개수
    • 혼란·지연·에스컬레이션 실패가 발생한 지점

아날로그 날씨 테이블이 바로 그 중심에 있습니다. 종이나 화이트보드 위에 그리는 공유 타임라인으로, 진행 중 실시간으로 이벤트와 대응을 기록하는 물리적 보드입니다.


아날로그 인시던트 스토리 날씨 테이블 만들기

당신의 온콜 일주일을 하나의 일기예보 차트라고 생각해 봅시다. 온도나 습도 대신 다음과 같은 것을 그립니다.

  • 인시던트는 폭풍 셀(storm cell)
  • **심각도(Severity)**는 폭풍의 강도
  • 지속 시간은 캘린더를 가로지르는 전선(front)의 길이
  • 팀 부하는 쌓여가는 기압 체계

이를 바탕으로 단순하지만 강력한 날씨 테이블을 다음과 같이 만들 수 있습니다.

1. 축(Axis) 설정하기

큰 종이 한 장이나 화이트보드에 다음과 같이 그립니다.

  • 가로 축: 시간
    예: 월요일 00:00 → 일요일 24:00, 혹은 단일 연습이라면 T0 → T+120
  • 세로 축: 인시던트 스트림 또는 팀/역할
    예: Detection(탐지), Response(대응), Comms(커뮤니케이션), Legal, Execs(경영진)

2. 인시던트를 날씨로 표현하기

시뮬레이션 주간(혹은 “가상 며칠”을 다루는 단일 테이블탑) 동안:

  • 각 인시던트를 폭풍 전선으로 그립니다. 타임라인을 가로지르는 색 띠로 표현합니다.
  • 색상이나 선 스타일로 심각도를 표현합니다.
    예: 빨간 실선 = SEV-1, 주황색 점선 = SEV-2
  • 주요 전환 지점에 주석을 답니다.
    • “여기서 탐지 신호 감지”
    • “IR 리드로 에스컬레이션”
    • “고객 영향 확인”

연습이 진행되는 동안, 퍼실리테이터와 참가자들이 자신의 대응을 말로 설명하면서 동시에 실제로 이 테이블 위에 직접 그려 나갑니다.

3. 대응(리스폰스) 주석 추가하기

같은 날씨 테이블 위에 다음을 바로 적습니다.

  • 각 시점에 누가 온콜이었는지
  • 어떤 툴·채널이 사용되었는지 (Slack, 페이저, 전화 트리, 티켓 시스템 등)
  • 주요 의사결정 포인트와 책임자
  • 지연·혼란·컨텍스트 부족이 나타난 지점 (항상 같은 색으로 동그라미 표시)

이 아날로그 지도는 디브리핑과 사후 분석을 위한 스토리의 척추(Story Spine) 역할을 합니다.


날씨 스토리를 메트릭으로 바꾸기

예쁜 그림을 그리는 것이 목표가 아닙니다. 목표는 측정입니다.

각 날씨 테이블에서 다음과 같은 일관된 메트릭을 추출합니다.

  • 탐지 시간 vs Acknowledge(인지) 시간 vs 격리/Containment까지의 시간
  • 핸드오프나 담당자 재지정 횟수
  • 사용된 커뮤니케이션 채널 개수 (그리고 그 채널에서 얼마나 자주 커뮤니케이션이 끊기는지)
  • 에스컬레이션이 멈추거나 모호해진 지점
  • 온콜 로테이션에 미친 영향 (한 사람이 동시에 몇 개의 폭풍을 떠안았는지)

이 데이터를 여러 번의 시뮬레이션에 걸쳐 추적합니다.

  • 알림 튜닝 이후 탐지 시간이 실제로 줄어들었는가?
  • 에스컬레이션 정책을 개편한 뒤 인시던트 라우팅이 더 효율적이 되었는가?
  • 새로 만든 런북이 격리/Containment까지의 시간을 줄였는가?

이러한 데이터는 스프레드시트나 가벼운 데이터베이스처럼 구조화된 형식으로 저장합니다. 이렇게 하면 다음을 할 수 있습니다.

  • 트렌드 차트 생성
  • 시나리오 유형별(예: 랜섬웨어 vs SaaS 계정 탈취)로 연습 결과 비교
  • 각 메트릭을, 시뮬레이션 사이에 실제로 배포한 개선 작업과 연결

이렇게 해서 **“Lessons learned(배운 교훈)”**이 **“Lessons measured(측정된 교훈)”**로 바뀝니다.


이해관계자를 위한 인시던트 날씨 시각화

대부분의 경영진은 패킷 캡처를 보고 싶어 하지 않습니다. 그들이 원하는 것은 **명료함(Clarity)**입니다. 날씨 메타포는 기술적 혼돈을 누구나 이해할 수 있는 패턴으로 바꿔 주는 시각 자료를 만드는 데 도움이 됩니다.

아날로그 테이블에서 다음과 같은 디지털 시각화를 만들 수 있습니다.

  • 주간 폭풍 지도(Weekly Storm Map):
    달력 뷰 형태로, 시뮬레이션(또는 실제) 인시던트가 언제 발생했는지 표시하고 심각도별로 색상을 입힙니다.
  • 부하 프로파일(Load Profile):
    팀별 혹은 온콜 엔지니어별로 겹치는 인시던트를 누적 막대 그래프로 표시합니다.
  • 마찰 지점(Friction Hotspot):
    지연이 몰리는 구간(예: 법무 승인, 고객 커뮤니케이션, DB 접근 등)을 히트맵으로 표현합니다.

이때 시각 자료는 다음 원칙을 지킵니다.

  • 일관성: 슬라이드·리포트 전반에 걸쳐 같은 색, 스케일, 라벨 사용
  • 미니멀리즘: 노이즈를 줄이고, 각 시각 자료에서 2~3개의 핵심 패턴만 강조
  • 액션 지향성: 모든 시각 자료는 “어떤 질문을 던질지, 어떤 결정을 내려야 할지”를 암시해야 합니다.

목표는 이해관계자가 슬라이드를 한 번 보고 이렇게 말하게 만드는 것입니다.
“어디에서 폭풍이 항상 막히는지 보이네요. 저 병목부터 해결합시다.”


액션 아이템으로 끝나는 논리적 스토리 만들기

데이터만으로는 조직이 움직이지 않습니다. 결과를 동반한 스토리가 필요합니다.

테이블탑 결과를 발표할 때는 다음과 같은 명확한 내러티브 구조를 사용합니다.

  1. 컨텍스트 – 어떤 주/시나리오를 시뮬레이션했는가? 무엇을 배우려 했는가?
  2. 예보 vs 현실 – 우리가 기대했던 흐름은 무엇이었는가? 날씨 테이블에 기록된 실제 진행은 어땠는가?
  3. 패턴 – 폭풍이 일관되게 느려지거나 강해지는 지점은 어디였는가?
  4. 영향 – 이것이 실제 인시던트였다면, 어떤 리스크·비용·고객 피해가 발생했을까?
  5. 액션 – 우리가 실제로 수행하기로 합의한 3~5개의 우선순위 높은 변경 사항

각 연습은 다음과 같은 구체적이고 순위가 매겨진 액션 아이템으로 끝나야 합니다.

  • “SEV-1 인시던트에 단일 실패 지점(single point of failure)이 생기지 않도록 온콜 스케줄을 재설계한다.”
  • “모든 시니어 엔지니어를 대상으로 필수 인시던트 커맨더(Incident Commander) 교육을 도입한다.”
  • “새 인시던트 커뮤니케이션용 Slack 앱을 파일럿 도입하고 사용성 테스트를 실시한다.”

각 액션에 담당자, 마감 기한, 성공 지표를 부여합니다. 다음 시뮬레이션 사이클에서는 이 변경들이 실제로 숫자를 움직였는지 직접 검증할 수 있습니다.


실제 폭풍 전선에 맞춘 온콜 스케줄 설계

날씨 테이블을 몇 번만 돌려 봐도 익숙한 패턴이 보이기 시작합니다. 바로 **폭풍 클러스터(Storm Cluster)**입니다.

당신은 다음을 보게 될 것입니다.

  • 특정 시간대에 인시던트가 한 사람에게 몰리는 구간
  • 항상 여러 전선에 동시에 끌려 들어가는 역할
  • 중요한 커버리지가 비어 있는 공백 시간대

이를 바탕으로 다음과 같은 베스트 프랙티스를 적용해 온콜을 재설계합니다.

  • 가능하다면 Follow-the-sun 모델 적용:
    여러 타임존을 활용해 피로를 줄이고 야간 부하를 분산합니다.
  • 인시던트 커맨드 역할과 실제 대응자 역할 분리:
    한 사람이 동시에 문제를 해결하고 조정까지 맡지 않도록 합니다.
  • 중요한 기능(예: 커뮤니케이션, DB 관리, 클라우드 인프라 등)에 대해 각 교대(Shift)마다 중복 인력을 둡니다.
  • 온콜 자체를 계측합니다:
    인터럽트 횟수, 야간 호출, 응답 시간(Time-to-Response)을 1급 메트릭으로 추적합니다.

툴링도 중요합니다.

  • 로테이션, 대체(on-call override), 휴가를 깔끔하게 처리할 수 있는 현대적인 온콜 스케줄링 플랫폼을 사용합니다.
  • 페이징을 인시던트 관리 툴과 연동하여 수동 단계를 최소화합니다.

목표는 단순한 “커버리지를 채우는 것”이 아니라, 실제 폭풍 패턴을 고려한 지속 가능한 커버리지를 구축하는 것입니다. 날씨가 늘 맑다고 가정하는 스케줄은 피해야 합니다.


사람 중심 툴: 요구사항 먼저, 그다음 사용성

인시던트 커뮤니케이션 툴은 편의점에서 우산을 고르듯 선택되는 경우가 많습니다.
“가까이 있고, 대충 괜찮아 보이니까 이걸로 하지 뭐.”
그 결과, 제대로 쓰이지 않는 티켓 시스템, 임시 Slack 채널, 아무도 기억 못하는 워룸(전용 회의실/채널)이 양산됩니다.

대신 두 단계의 사람 중심(Human-centered) 프로세스를 적용해야 합니다.

1. 요구사항 분석(Requirements Analysis)

툴을 선택하거나 만들기 전에 다음을 먼저 이해합니다.

  • 누가, 어떤 정보를, 언제, 어떤 형식으로 필요로 하는가?
  • 고스트레스 인시던트 상황에서 실제 제약은 무엇인가?
    (모바일만 사용 가능, VPN 문제, 인지 과부하 등)
  • 현재 조직은 압박 상황에서 이미 어떻게 커뮤니케이션하고 있는가?

인터뷰, 섀도잉(업무 동행 관찰), 과거 인시던트 리뷰를 통해 다음과 같은 구체적인 요구사항을 도출합니다.

  • “인시던트를 시작하거나 참가하는 데 3클릭 이내여야 한다.”
  • “실시간으로 업데이트되는 단일 소스 오브 트루스(Single Source of Truth)를 제공해야 한다.”
  • “커맨더, 서기(Scribe), 커뮤니케이션 담당, 기술 리드 등 역할이 명확히 구분되어야 한다.”

2. 사용성 테스트(Usability Testing)

후보 툴이나 워크플로가 정해지면:

  • 해당 툴을 활용한 짧고 집중된 테이블탑 드릴을 실행합니다.
  • 사람이 어디에서 머뭇거리거나 잘못 클릭하거나, 예전 습관으로 되돌아가는지 관찰합니다.
  • 참가자에게 자신의 생각 과정을 소리 내어 설명하게 합니다(Think-aloud 방식).

이때 날씨 테이블에 “이 툴이 대응 폭풍에 마찰을 줄였는지, 아니면 더했는지”를 함께 기록합니다.

이 과정을 반복해 툴을 조정합니다. 벤더 데모 속 이상적인 사용자가 아니라, 지금 당신 조직의 실제 사람들에게 잘 맞는 툴이 될 때까지 계속합니다.


결론: 폭풍을 그냥 버티지 말고, 예측하라

인시던트는 언제나 어느 정도는 날씨와 비슷할 것입니다. 예측 불가능한 요소가 있고, 때로는 폭력적이며, 완전히 통제할 수는 없습니다. 하지만 그렇다고 해서 매번 완전한 불시의 기습으로만 받아들일 필요는 없습니다.

아날로그 인시던트 스토리 날씨 테이블을 테이블탑 시뮬레이션의 척추로 삼으면, 다음을 할 수 있습니다.

  • 혼돈스러운 시나리오를 규율 있는, 반복 가능한 실험으로 전환
  • 스토리를 “개선 혹은 퇴보”를 보여주는 실제 메트릭으로 변환
  • 복잡한 패턴을 비기술 이해관계자도 진짜 리스크를 이해할 수 있는 시각 자료로 변환
  • 실제 폭풍 전선을 기준으로 온콜 스케줄과 툴을 설계하고, 단순한 추측에 의존하지 않기

무엇보다 중요한 것은, 테이블탑 연습을 단순한 컴플라이언스용 ‘연기’에서 전략적 예측 도구로 바꾸는 일입니다. 온콜 주간 위에 그려지는 종이 폭풍 전선 하나하나가, 조직이 압박 상황에서 실제로 어떻게 반응하는지를 보여 주는 장기적이고 실행 가능한 “기후 기록”이 됩니다.

테이블탑을 그냥 “한 번 해 보고 마는 행사”로 두지 마십시오.

날씨를 지도에 옮기고, 폭풍을 측정하십시오.
그리고 다음 폭풍을 훨씬 더 수월하게 넘길 수 있도록, 그 데이터에 기반한 변화를 실제로 배포하십시오.

아날로그 인시던트 스토리 ‘날씨 테이블’: 온콜 주간 위로 종이 폭풍 전선을 굴리는 법 | Rain Lag