소개

대부분의 인시던트 대응 훈련은 실제 인시던트가 벌어지는 곳, 즉 도구 안에서 이루어집니다. 관측(Observability) 플랫폼에 가짜 알림을 띄우고, 스테이징 환경에서 장애를 시뮬레이션하고, 프로덕션에서 카오스 실험을 돌리기도 합니다. 모두 가치 있는 연습입니다.

하지만 팀들이 자주 건너뛰는 연습이 하나 있습니다. 아예 화면에서 완전히 떨어져 보는 것입니다.

화이트보드 신뢰성 워크숍(Whiteboard Reliability Workshop) 은 화이트보드, 마커, 마스킹 테이프만 사용하는 스크린‑프리, 핸즈온 포맷으로 복잡한 대규모 장애를 리허설하는 방식입니다. 인시던트를 본질만 남기고 재구성합니다. 공유된 이해, 명확한 역할, 빠른 의사결정, 효과적인 커뮤니케이션 말입니다.

이 글에서는 방 세팅부터 시나리오 설계, 드릴 이후 피드백 루프까지, 화이트보드 기반 인시던트 드릴을 직접 설계하고 운영하는 방법을 단계별로 안내합니다.

왜 인시던트 드릴을 스크린 없이 할까?

장애가 나면 사람들은 자연스럽게 도구로 향합니다. 대시보드, 로그, 티켓 시스템, 채팅, 문서 등. 모두 중요하지만, 동시에 집중을 분산시키고 정렬되지 않은 상태를 가리는 역할을 하기도 합니다.

스크린‑프리 워크숍은 의도적으로 이런 디지털 지팡이를 치워버립니다. 그 이유는 다음과 같습니다.

• 디지털 산만함을 줄이기 위해 – “이 그래프만 잠깐 볼게요” 같은 새는 시간을 없애고, 모두가 하나의 공통 아티팩트인 화이트보드에만 집중하게 합니다.
• 공유된 멘탈 모델을 강제하기 위해 – 화이트보드에 적혀 있지 않으면 인시던트의 일부가 아닙니다. 이 과정에서 이해와 커뮤니케이션의 간극이 그대로 드러납니다.
• 생각을 눈에 보이게 만들기 위해 – 가정, 가설, 결정이 전부 글과 그림으로 남습니다. 혼란과 의견 차이, 진전 상황을 눈으로 볼 수 있습니다.
• 경험·도구 의존도를 낮추고 평평한 경기장을 만들기 위해 – 특정 도구를 더 잘 아는 사람이 ‘더 유능한’ 참가자가 아닙니다. 이 워크숍에서는 명료함, 협업, 시스템 사고가 진짜 실력입니다.

화이트보드는 인시던트 컨트롤 센터가 됩니다. 실제 프로덕션에서 벌어질 고위험 상황을 위한 저기술(low‑tech) 대체물인 셈입니다.

인시던트 컨트롤 센터로서의 화이트보드

그냥 다이어그램을 그리는 수준을 넘어, 물리적인 오퍼레이션 콘솔을 설계한다고 생각해야 합니다. 실제 인시던트가 전개되는 방식과 최대한 비슷하게 보드를 구성합니다.

일반적인 레이아웃 예시는 다음과 같습니다.

1. 인시던트 타임라인

   • 화이트보드 상단을 가로지르는 긴 수평선.
   • 마스킹 테이프로 표시한 시간 마커: T0, +5, +10, +30 등.
   • 시나리오가 진행되면서 주요 이벤트, 결정, 상태 변화가 계속 추가됩니다.

2. 영향(Impact) 평가 구역

   • 누가 영향을 받는가? (고객, 내부 사용자, 지역/리전 등)
   • 무엇이 망가졌는가? (기능, API, 워크플로)
   • 심각도(Severity), 비즈니스 임팩트, 리스크 메모.

3. 리소스 할당 & 팀 역할 배치

   • 현장 역할(on‑scene roles) 을 한눈에 볼 수 있는 명단: 인시던트 커맨더(IC), 스크라이브, 커뮤니케이션 리드(Comms Lead), 테크니컬 리드(Dev, Ops, Security), 기타 SME.
   • 누가 어떤 스레드/트랙을 맡고 있는지 마스킹 테이프로 레인(swimlane)을 만들어 시각화.

4. 실시간 상태 & 가설 보드

   • 예를 들어 이런 컬럼들:
     • 관찰된 증상(Observed symptoms)
     • 현재 가설(Current hypotheses)
     • 진행 중인 실험/액션(Experiments / actions in progress)
     • 블로킹 이슈 / 결정 필요(Blocked / needs decision)
   • 잘 운영되는 인시던트 채널이나 상태 문서(status doc)가 가진 구조를 화이트보드로 옮겨놓는 느낌입니다.

5. 커뮤니케이션 보드

   • 고객 공지 초안, 이해관계자(stakeholder) 브리핑, 내부 공지 문구 등을 적는 공간.
   • 언제, 어떤 채널로, 어떤 내용을 보냈는지 추적하는 영역.

마스킹 테이프로 각 섹션과 스윔레인을 깔끔하게 나누세요. 색깔 있는 마커(예: 빨강=임팩트, 파랑=액션, 초록=결정)를 쓰면 패턴이 훨씬 잘 드러납니다.

드릴이 끝날 즈음이면, 여러분의 화이트보드는 방금 “겪고 온” 인시던트의 시각적인 포스트모템이 되어 있어야 합니다.

마커와 테이프로 만드는 시뮬레이션 설계

좋은 워크숍은 인시던트의 전체 라이프사이클을 통과시킵니다. 단순히 “고쳤다”에서 끝나지 않습니다. 드릴을 설계할 때 다음 단계를 모두 다루도록 구성하세요.

1. 감지(Detection)

   • 누가 제일 먼저 알아채는가? 모니터링 시스템, 고객 지원, 실제 고객, 보안 툴링?
   • 초기 신호는 얼마나 애매한가? (예: 애매한 레이턴시 스파이크 vs. 분명한 에러 폭증)

2. 트리아지(Triage)

   • 심각도를 얼마나 빨리, 어떻게 분류하는가?
   • 누구를 호출해 투입시키는가?
   • 가장 먼저 내려야 할 결정은 무엇인가?

3. 커뮤니케이션(Communication)

   • 언제 외부 커뮤니케이션(고객/파트너 공지)을 시작할 것인가?
   • 이해관계자 업데이트 주기는 어느 정도로 할 것인가?
   • 내부 소음(noise)과 신호(signal)를 어떻게 구분·관리할 것인가?

4. 대응 및 복구(Response and Recovery)

   • 어떤 가설을 어떤 순서로, 왜 검증하는가?
   • 언제 롤백하거나, 페일오버를 하거나, 부분 장애 상태를 받아들일 것인가?
   • 언제 “위기에서 벗어났다(out of the woods)”고 판단할 수 있는가?

5. 안정화 및 후속 조치(Stabilization and Follow‑Up)

   • 재발 여부를 어떻게 모니터링할 것인가?
   • 포스트모템을 위해 무엇을 기록해둘 것인가?
   • 어떤 장기적인 개선/픽스를 식별했는가?

각 시나리오는 단계적으로 펼쳐지는 하나의 이야기입니다. 퍼실리테이터는 보드에 정보를 하나씩 흘려보냅니다. 예를 들어: 고객 지원 티켓, 보안 알림, 손으로 그린 그래프, 고객 불만 메모 등.

팀은 이 정보들 속에서 신호와 노이즈를 구분하고, 타임라인을 갱신하며, 실시간으로 대응 전략을 조정해야 합니다. 실제 장애 상황에서와 똑같이 말입니다.

DevSecOps 관점에서: 처음부터 크로스‑펑셔널로

인시던트는 거의 절대 순수하게 “Dev 문제”, “Ops 문제”, “보안 문제”로만 끝나지 않습니다. 대부분 시스템 전체를 건드리는 이벤트입니다.

화이트보드 신뢰성 워크숍을 DevSecOps 훈련장으로 설계하세요.

• 모든 드릴에 Dev, Ops, Security를 함께 넣습니다. 트랙을 나누지 말고, 같이 연습합니다.
• 평소 맡지 않는 역할을 돌려가며 맡겨봅니다. 개발자가 인시던트 커맨더를 맡고, 보안 엔지니어가 커뮤니케이션 리드를 맡는 식입니다.
• 트레이드오프를 명시적으로 드러내세요. 예를 들면:
  • 배포 롤백은 서비스를 복구하지만 이미 알려진 보안 취약점을 다시 노출시킬 수 있습니다.
  • 빠른 설정 변경으로 부하를 줄일 수 있지만, 사기 탐지(fraud detection)에 필요한 핵심 분석 기능이 꺼질 수 있습니다.

화이트보드를 이용해 이런 긴장 관계를 시각화하세요. 의사결정 브랜치를 그려보고, 각 선택지의 리스크를 적고, 누가 어떤 결정을 책임지는지 표시합니다. 이를 통해 신뢰성과 보안 모두에 대한 공동 책임 감각이 고압 상황에서도 생기게 됩니다.

역할, 의식(Ritual), 핸드오프: 실제 프로덕션처럼 연습하기

스크린‑프리 워크숍은 실제 인시던트 때 원하는 사람 간의 안무(human choreography) 를 연습하기에 최적의 환경입니다.

최소한 다음 역할은 연습해보세요.

• 인시던트 커맨더(Incident Commander, IC) – 전체 대응을 책임지고, 우선순위를 정하며, 팀이 이리저리 휘둘리지 않도록 합니다.
• 스크라이브(Scribe) – 타임라인과 보드를 실시간으로 업데이트하며, 결정, 상태 변화, 핵심 사실을 기록합니다.
• 커뮤니케이션 리드(Comms Lead) – 고객 및 이해관계자 업데이트 문구를 만들고, IC와 함께 빈도와 내용을 조율합니다.
• 테크니컬 리드(Dev/Ops/Sec) – 각자의 도메인에서 조사와 복구를 이끌고, IC에게 상태를 보고합니다.

여기에 간단한 의식을 더합니다.

• 처음 2분 스캔: IC가 현재까지 이해한 문제를 다시 말해 정리하고, 각자 역할을 확인한 뒤 첫 타임박스(예: “10분 안에 추정 블라스트 레이디우스(burst radius)를 파악하자”)를 설정합니다.
• 정기 상태 콜아웃: 5–10분마다 IC가 진행을 잠시 멈추고 묻습니다. 무엇이 바뀌었나? 현재 가설은 무엇인가? 어디가 막혀 있는가?
• 핸드오프 프로토콜: IC나 다른 핵심 역할이 바뀔 경우, 타임라인에 교대 시점을 명시하고, 기존 담당자가 현재 상태를 짧게 정리해 인수인계를 합니다.

이 동작들이 지루할 정도로 익숙해질 때까지 연습하세요. 바로 그 “지루할 정도의 근육 기억”이 실제 새벽 3시 인시던트에서 인지 부하를 크게 낮춰 줍니다.

시나리오 설계: 실제 포스트모템에서 배워라

시나리오는 추상적인 퍼즐이 아니라, 실제 있었던 장애를 바탕으로 할 때 훨씬 효과적입니다.

공개된 인시던트 포스트모템을 자세히 읽어보세요. (예를 들어, 일부 Azure DevOps 인시던트는 풍부한 타임라인과 근본 원인 분석을 함께 공개합니다.) 다음과 같은 패턴을 찾아봅니다.

• 여러 요인이 겹친 실패 (예: 설정 실수 + 모니터링 블라인드 스팟).
• 처음에는 작게 시작했다가 서서히 커지는 슬로우‑번 이슈.
• 서비스, 리전, 의존성 사이의 예상 밖 상호작용.
• 인증 실패, 인증서 문제, 접근 권한 오구성 등 보안과 인접한 사건.

이제 이 동학(dynamics)을 그대로 베끼지 말고, 닮은 구조의 프롬프트를 만듭니다. 예를 들면:

• 일부 테넌트나 특정 리전만 영향을 받는 롤링 부분 장애, 메트릭과 사용자 리포트가 서로 다른 이야기를 하는 상황.
• 배포 중에 잘못 설정된 방화벽 룰 때문에 내부 중요 서비스가 막혀버리는 보안 색채가 짙은 신뢰성 인시던트.
• 데이터 정합성이나 컴플라이언스를 위태롭게 하면서까지 빨리 복구할 것인지 고민해야 하는 복구 딜레마.

실제 인시던트에서 그랬던 것처럼, 단서를 한 번에 주지 말고 시간이 지날수록 조금씩 공개하세요. 퍼실리테이터의 역할은 불확실성을 시뮬레이션하되, 시나리오의 일관성은 유지하는 것입니다.

빠른 피드백과 반복: 디브리핑이 진짜 수업이다

드릴은 시나리오가 안정 상태에 도달하면 끝납니다. 하지만 학습은 그 다음 디브리핑(debrief) 에서 일어납니다.

20–30분 정도의 디브리핑을 다음 구조로 진행해 보세요.

1. 뭐가 잘 됐나?

   • 어떤 의식이나 결정이 대응 속도를 높였는가?
   • 언제 팀이 가장 잘 정렬되어 있다고 느꼈는가?

2. 뭐가 느렸거나 혼란을 유발했나?

   • 역할이 불명확했는가?
   • 서로 말이 엇갈리거나, 중복 작업이 나왔는가?
   • 좁은 가설 하나에 너무 오래 집착했는가?

3. 무엇을 자동화하거나 도구화해야 할까?

   • 반복적인 수동 점검 → 런북이나 스크립트로 만들 수 있는 것.
   • 매번 손으로 쓰는 상태 업데이트 → 템플릿화할 수 있는 것.
   • “이런 대시보드/알람이 있었으면 좋았겠다” 싶은 것.

4. 다음 드릴 전까지 어떤 프로세스 변화를 시도할까?

   • 역할 정의를 더 명확히 해야 할 부분.
   • 새로 작성해야 할 런북.
   • 인시던트 채널 에티켓이나 에스컬레이션 경로를 바꿔볼 지점.

이 내용들은 막연한 다짐이 아니라 구체적인 액션 아이템으로 남기세요. 다음 워크숍은, 이 변화들이 실제로 도움이 되는지 실험하는 장이 됩니다.

여러 번 반복하다 보면, 화이트보드에서의 팀 행동은 물론 실제 인시던트에서도 팀의 움직임이 더 체계적이고, 더 빠르고, 더 침착해지는 것을 볼 수 있습니다.

첫 워크숍 운영을 위한 실무 팁

실제로 돌려볼 때 도움이 되는 몇 가지 준비 사항입니다.

• 인원 규모: 한 시나리오에 6–10명이 적당합니다. 그 이상이면 관찰자 그룹을 두거나, 방을 나누어 병렬 시나리오를 돌리세요.
• 소요 시간: 시나리오 1개당 90–120분 정도를 잡으세요. (세팅 + 드릴 + 디브리핑 포함)
• 필수 준비물:
  • 대형 화이트보드 2–3개(또는 이동식 보드)
  • 마스킹 테이프 (레인, 타임라인 구획용)
  • 다양한 색의 마커
  • 스티키 노트 (이벤트, 가설 등을 옮겨 다니게 쓸 때 유용)
• 그라운드 룰:
  • 시나리오상 필요할 때를 제외하고는 노트북·폰 사용 금지.
  • 보드에 없는 것은 ‘실제로 존재하지 않는 것’으로 간주.
  • 선의(good intent)를 기본값으로 두고, 피드백은 개인이 아니라 시스템과 상호작용에 집중.

처음에는 단순하게 시작하세요. 시나리오 1개, 보드 1개, 작은 그룹. 포맷이 잘 맞는지 검증한 뒤에, 여러 팀·여러 방을 아우르는 복잡한 시뮬레이션으로 확장해도 늦지 않습니다.

결론

화이트보드 신뢰성 워크숍은 도구 기반 인시던트 연습을 대체하려는 것이 아닙니다. 다만 도구만으로는 채워지지 않는 빈 공간을 메워 주는 연습입니다.

스크린에서 한 발 물러나, 몇 개의 화이트보드를 공유 컨트롤 센터로 만드는 순간 여러분은 다음을 얻습니다.

• 크로스‑펑셔널 DevSecOps 협업 역량 강화
• 역할, 의식, 핸드오프에 대한 근육 기억 형성
• 실제 장애가 터지기 전에 커뮤니케이션·프로세스의 구멍을 드러내기
• 무엇을 자동화하거나 더 잘 계측해야 할지 발견하기

무엇보다도, 인시던트를 각개전투의 기술 문제가 아닌, 팀이 함께 다루는 시스템 문제로 경험하게 됩니다.

마커와 마스킹 테이프를 챙기고, 회의실을 예약해, 첫 시나리오를 돌려보세요. 화이트보드 위에서 얻은 교훈이, 다음 실제 인시던트가 뉴스 헤드라인이 되는 일을 막아줄지도 모릅니다.