Rain Lag

아날로그 인시던트 그린룸: 다음 프로덕션 장애를 위한 백스테이지 종이 리허설

테이블탑 연습, 종이 런스루, 구조화된 아티팩트를 ‘인시던트 대응용 그린룸’으로 활용해, 실제 프로덕션 장애와 위기가 오기 전에 안전하게 리허설하는 방법을 소개합니다.

아날로그 인시던트 그린룸: 다음 프로덕션 장애를 위한 백스테이지 종이 리허설

연극에서 누구도 리허설 없이 바로 무대에 오르지 않습니다. 항상 그린룸(greenroom)이 있습니다. 출연진이 대사를 맞춰 보고, 동선 실수를 고치고, 관객이 보기 전에 위험한 아이디어를 시험해 보는 백스테이지 공간입니다.

대부분의 조직은 인시던트 대응에는 그런 특권을 주지 않습니다.

우리는 기능을 빠르게 배포하고, 모니터링을 붙인 다음, 실제 장애와 보안 사고만을 유일한 진짜 훈련으로 취급합니다. 이는 마치 개막 공연을 첫 리허설로 쓰는 것과 같습니다.

여기서 등장하는 개념이 바로 아날로그 인시던트 그린룸입니다. 실제 프로덕션에 장애가 발생하기 전에, 종이 리허설(paper rehearsal)과 테이블탑(tabletop) 연습으로 장애와 위기를 연습하는, 의도적인 저위험 "백스테이지" 공간입니다.


왜 인시던트에도 백스테이지가 필요할까

인시던트(incident)는 다음과 같은 사실을 처음 깨닫기에 최악의 순간입니다.

  • 외부 커뮤니케이션의 최종 책임자가 누구인지 아무도 모른다.
  • 의존하고 있는 로깅 파이프라인이 장애의 블라스트 레디우스(blast radius) 안에 같이 들어 있다.
  • 법무팀과 PR팀은 기술적 리스크를 이해하지 못하고, 기술팀은 그 반대의 상황이다.

테이블탑 연습과 종이 기반 시뮬레이션은 안전하고 통제된 환경을 제공합니다. 이를 통해:

  • 사람이 아니라 프로세스를 스트레스 테스트할 수 있고,
  • 기술·조직 양쪽의 보이지 않는 의존성을 드러낼 수 있으며,
  • 실제 피해 없이 압박 속 커뮤니케이션을 연습할 수 있습니다.

이 세션들을 여러분의 백스테이지 리허설로 생각해 보세요. 모든 것은 가짜지만, 실제인 것은 역량, 협업, 그리고 학습입니다.


구조화된 아티팩트: 리허설의 대본과 악보

좋은 연극에는 대본이 필요합니다. 좋은 인시던트 리허설에는 아티팩트가 필요합니다.

그린룸이 효과적으로 작동하게 만드는 핵심 아티팩트는 세 가지입니다.

1. 플레이북: 누가, 언제, 무엇을, 어떻게 할 것인가

**인시던트 플레이북(Incident Playbook)**은 특정 인시던트 유형에 대한 고수준 가이드입니다.

  • 퍼블릭 API에 대한 DDoS 공격
  • 코퍼레이트 IT 시스템 내 랜섬웨어 감염
  • 고객 계정을 침해한 데이터 유출
  • 플랜트(plant) 내 ICS/OT 시스템 장애

각 플레이북에는 다음이 포함되어야 합니다.

  • 트리거(Triggers): 어떤 신호가 이 플레이북을 시작하게 만드는가?
  • 역할(Roles): 인시던트 커맨더, 커뮤니케이션 리드, 스크라이브(기록 담당), 테크니컬 리드, 법무, PR 등
  • 핵심 의사결정(Key decisions): 차단 vs 관찰, 셧다운 vs 기능 저하, 즉시 공개 vs 추가 조사
  • 커뮤니케이션 템플릿: 내부 공지, 고객 공지, 규제기관 통지 문구 등

리허설에서 플레이북은 대본과 같습니다. 매번 즉흥적으로 대응하는 것이 아니라, 어떻게 대응하려 하는지를 실제로 검증하게 해 줍니다.

2. 런북: 세부 동선과 안무

**런북(Runbook)**은 플레이북 안에 들어 있는, 단계별 상세 절차입니다. 예를 들면:

  • "프로덕션 데이터베이스 자격 증명 전부 회전하기"
  • "Region A에서 Region B로 트래픽 페일오버하기"
  • "전 세계에서 침해된 사용자 세션 비활성화하기"

종이 리허설에서는 각 단계를 하나씩 따라가며 확인합니다.

  • 이 절차를 실행할 수 있는 사람이 누구인지 명확한가?
  • 시스템이 부분적으로 장애 상태여도, 실제로 사용할 수 있는 툴링인가?
  • 승인, 안전장치, 롤백 경로가 빠진 단계는 없는가?

테이블탑에서는 실제 시스템을 변경하지 않지만, 실제로 변경한다고 가정하면서 프로세스가 어디에서 깨지는지 확인합니다.

3. 근본 원인 분석 템플릿: 스토리를 기록하는 틀

마지막으로, RCA(Root Cause Analysis, 근본 원인 분석) 혹은 인시던트 리뷰 템플릿이 필요합니다. 이 템플릿은:

  • 기술적 원인조직·프로세스 상의 원인을 분리해 다루고,
  • 불확실한 상황 속에서 내려진 의사결정을 비난 없이(blameless) 분석하며,
  • 타임라인, 영향, 기여 요인, 개선사항을 체계적으로 담습니다.

리허설에서도 실제 인시던트에서 사용하는 것과 동일한 템플릿을 사용하세요. 이렇게 하면:

  • 문서화를 일관되게 연습하게 되고,
  • 투명하고 비처벌적인 학습 문화를 자연스럽게 정착시키며,
  • 실제 및 모의 인시던트를 모두 검색 가능한 라이브러리로 축적할 수 있습니다.

플레이북, 런북, RCA 템플릿 이 세 가지가 백스테이지를 구성하는 재료입니다. 이 아티팩트들이 연습을 일관되고, 반복 가능하며, 계속 개선 가능한 활동으로 만들어 줍니다.


현실적인, 우리 조직 맞춤 시나리오 설계하기

모든 조직에 두루 쓰이는 제너릭 시나리오는 정작 여러분이 배워야 할 것을 잘 못 짚는 경우가 많습니다. 연습은 자신들의 실제 리스크와 환경을 기반으로 설계해야 합니다.

아래와 같은 시나리오 계열을 고려해 보세요.

보안 인시던트 시나리오

  • 탈취된 관리자 계정이 고객 데이터를 외부로 유출하는 데 사용됨
  • 코퍼레이트 네트워크에 랜섬웨어가 감염되어 프로덕션 영역으로 확산 중
  • 벤더 알림을 통해 공급망(Supply Chain) 침해가 뒤늦게 발견됨

리허설에서 다뤄야 할 핵심 질문:

  • 누가 최종적으로 "차단 전략"을 결정하는가?
  • 법무, PR, 필요 시 수사기관과 어떻게 공조하는가?
  • 얼마나 빨리 시크릿을 회전시키고, 접근 권한을 회수하고, 무결성을 검증할 수 있는가?

ICS/OT(산업 제어/운영 기술) 장애 시나리오

산업 현장, 제조, 에너지 환경이라면 다음과 같은 상황을 가정할 수 있습니다.

  • 핵심 PLC나 SCADA 시스템과의 연결 상실
  • 안전 시스템 알람이 모호하거나 서로 상충된 신호를 내보냄
  • 원격 플랜트에서 표준 셧다운 절차를 따를 수 없는 상황 발생

이때 키워드는 다음과 같습니다.

  • OT 엔지니어, IT 보안, 시설팀 간 협업과 조정
  • 비용이 많이 들 수 있는 안전 관련 결정을 내릴 명확한 권한 라인
  • 현장 제어실과 중앙 운영조직 사이의 명료한 커뮤니케이션

법무 / PR / 규제 관련 위기 시나리오

  • 내부 모니터링보다 먼저 소셜 미디어에 데이터 유출 정황이 등장
  • 금융, 의료, 공공요금 등 규제 대상 서비스에 중대한 장애 발생
  • 영향력이 큰 고객이 인시던트를 경영진 레벨로 에스컬레이션

이 경우 초점을 맞출 부분은:

  • 누가 언제 외부에 발언하는지, 그 대변 창구와 타이밍
  • 촉박한 시간 안에서의 승인(approval) 워크플로우
  • 기술적 현실과 대외 발표 내용 간의 정합성 확보입니다.

시나리오가 여러분의 세계에서 충분히 있을 법한 일처럼 느껴질수록, 리허설은 더 설득력 있고 몰입감 있게 진행됩니다.


단발성 드릴이 아니라, 전체적인 트레이닝 프로그램을 만들기

한 번의 테이블탑도 물론 유용합니다. 하지만 진짜 준비 태세를 만드는 것은 프로그램 형태의 반복적인 리허설입니다.

여러 훈련 모드를 조합하라

  1. 테이블탑 연습(Tabletop Exercises, 종이 리허설)

    • 실제로 한 자리에 모이거나(오프라인), 화상회의로 진행
    • "지금 시각 09:05, 이런 알람이 떴다…"와 같은 내러티브 중심 전개
    • 의사결정, 커뮤니케이션, 프로세스에 초점
  2. 런북 드릴(Runbook Drills)

    • 하나 또는 두 개의 핵심 절차만 집중적으로 연습
    • 종이 위 워크스루만 하거나, 비프로덕션 환경에서 실제로 실행
    • 예: 매월 "모든 퍼블릭 엔드포인트의 TLS 인증서 교체" 연습
  3. 라이브 시뮬레이션 / 게임데이(GameDays)

    • 스테이징 또는 (가드레일을 갖춘) 프로덕션 환경에서의 통제된 장애·부하 테스트
    • 사람, 도구, 시스템이 실제로 기대한 대로 작동하는지 검증

테이블탑(종이 기반)은 디자인과 개선에, 라이브 시뮬레이션은 검증과 단단한 강화에 활용하십시오.

준비도를 측정하는 구체적인 지표 설정

"오늘 느낌 어땠어요?"만으로는 부족합니다. 다음과 같은 지표를 추적해 보세요.

  • MTTD (Mean Time to Detect) – "우리가 큰일 났다는 사실"을 인지하는 데 걸리는 평균 시간
  • MTTA (Mean Time to Acknowledge) – 누군가 인시던트를 공식적으로 맡아 책임지는 데 걸리는 평균 시간
  • MTTR (Mean Time to Recovery/Resolution) – 완화하거나 복구하는 데 걸리는 평균 시간
  • 커뮤니케이션 리듬(Communication cadence) – 이해관계자들에게 얼마나 자주, 얼마나 명확하게 업데이트하는지
  • 에스컬레이션 정확도(Escalation accuracy) – 혼란 없이, 적시에 정말 필요한 전문가에게 잘 에스컬레이트되었는지

이 지표들은 리허설과 실제 인시던트 모두에서 동일하게 적용하십시오. 시간이 갈수록 다음과 같은 변화를 기대할 수 있습니다.

  • 더 빠르고, 더 자신감 있는 대응
  • 핸드오프(인수인계) 실패 감소
  • 더 명료하고 일관된 커뮤니케이션

현실 세계의 사례에서 배우기

처음부터 모든 것을 직접 설계할 필요는 없습니다.

Google, PagerDuty, Atlassian, 주요 보안 벤더들은 다음과 같은 자료들을 공개적으로 제공합니다.

  • 인시던트 이후 보고서 및 장애 회고(Post-Incident Report, Outage Retrospective)
  • 카오스 엔지니어링(Chaos Engineering) 및 게임데이(GameDay) 플레이북
  • 보안 훈련 및 위기 시뮬레이션 프레임워크

이 자료들을 다음과 같이 활용할 수 있습니다.

  • 영감(Inspiration) – 시나리오를 여러분의 시스템과 리스크에 맞게 변형
  • 벤치마크(Benchmark) – 그들의 프로세스, 타임라인, 역할 정의를 우리와 비교
  • 학습 자료(Teaching material) – 공개된 RCA를 함께 읽고, 그걸 기반으로 테이블탑 연습 진행

목표는 다른 회사의 프로세스를 그대로 복사하는 것이 아니라, 그들이 이미 겪은 시행착오를 뛰어넘고, 성숙한 패턴을 여러분의 맥락에 맞게 재구성하는 것입니다.


플래너와 플레이어를 분리하라

자주 발생하는 실패 패턴 중 하나는, 연습을 설계한 사람들이 연습에 직접 "플레이어"로 참여하면서 무의식적으로 해피 패스(happy path)로 유도하는 것입니다.

이를 피하려면 다음처럼 역할을 분명히 나눠야 합니다.

플래너(Planners)

  • 시나리오, 인젝트(inject, 중간에 추가되는 변수), 타임라인을 설계
  • 백스테이지에서 사용할 상세 스크립트와 핸드북을 유지
  • 어떤 데이터를 언제 보여줄지(로그, 알람, 이해관계자 요구사항 등) 결정
  • 참가자의 행동, 의사결정, 마찰 지점을 관찰하고 기록

플레이어(Players)

  • 실제 인시던트를 겪는 것처럼 최대한 현실적으로 상황을 경험
  • 실제 상황에서 사용할 수 있는 도구와 정보만 사용
  • 불완전한 정보 속에서, 불확실성을 안고 의사결정

플래너는 전체 대본을 알고 있습니다. 플레이어는 "지금 이게 진짜일 수도 있다"라고 느끼는 상태에서 연습해야 합니다.


심리적 안전감: 방 안에서 가장 중요한 통제 장치

백스테이지에서는 배우가 대사를 잊어버려도, 다시 해도 괜찮습니다. 인시던트 그린룸도 마찬가지여야 합니다.

**심리적 안전감(psychological safety)**이 없다면, 리허설은 다음과 같은 방향으로 흐르기 쉽습니다.

  • 사람들이 혼란스럽다는 사실을 숨기고, 드러내지 않는다.
  • 리더가 모든 결정을 주도해, 설계된 프로세스가 작동할 기회를 잃는다.
  • 망가진 런북이나 불명확한 책임 구분을 아무도 지적하지 않는다.

연습을 설계할 때 다음을 명확히 하십시오.

  • 비난 금지(Blamelessness) – 초점을 개인이 아니라 시스템과 프로세스에 맞추기
  • 학습 목표(Learning goals) – "오늘의 목표는 완벽해 보이는 것이 아니라, 약점을 최대한 많이 발견하는 것입니다"라고 처음에 못 박기
  • 오픈 리플렉션(Open reflection) – 매 연습 마지막에는 솔직한 디브리핑(debrief)을 진행:
    • 무엇이 가장 의외였는가?
    • 어디에서 막히거나 불확실함을 느꼈는가?
    • 어떤 아티팩트(플레이북, 런북, 도구)가 도움이 되었고, 무엇이 방해가 되었는가?

대화가 솔직해질수록, 같은 1시간을 써도 얻는 가치는 훨씬 커집니다.


아날로그 그린룸을 실제로 운영에 올리는 방법

처음부터 거대한 프로그램을 만들 필요는 없습니다. 작게 시작하되, 실제처럼 만들면 됩니다.

  1. 임팩트가 큰 시나리오 하나를 고르세요.
    예: 대규모 고객 영향 장애, 보안 침해, OT 시스템 장애 등
  2. 오늘 당장 우리가 어떻게 대응할 것이라고 생각하는지를 담은, 간단한 플레이북과 핵심 런북 몇 개를 작성하세요.
  3. 90분짜리 테이블탑을 한 번 돌려보세요. 구성은 다음과 같이:
    • 인시던트 커맨더(Incident Commander)
    • 테크 리드(Technical Lead)들
    • 커뮤니케이션/PR 담당(그 역할을 대행할 사람도 가능)
    • 스크라이브(기록 담당)
  4. 플래너와 플레이어를 분리하고, 중간에 몇 가지 예상치 못한 변수(인젝트)를 스크립트로 준비하세요.
  5. 솔직하게 디브리핑을 진행하고, 아티팩트를 업데이트한 뒤, 다음 리허설 일정을 잡으세요.

시간이 지나면서, 여러분의 아날로그 인시던트 그린룸은 다음과 같은 것들이 됩니다.

  • 신입과 신규 리더를 위한 훈련장
  • "만약 이런 일이 생기면 어쩌지?"를 헤드라인이 되기 전에 안전하게 탐색하는 공간
  • 조직 레질리언스를 만들어 가는 핵심 활동

언젠가 실제 장애는 반드시 발생합니다. 그때 여러분의 팀은 개막 공연 날 처음 무대에 서서 즉흥 연기를 하는 팀이 아닐 것입니다. 이미 같은 무대를 열두 번은 걸어본 배우들처럼, 익숙한 공간 위에 서게 될 것입니다.

그리고 관객—여러분의 고객, 파트너, 규제기관—은 그 부드러운 대응 뒤에 얼마나 많은 백스테이지 작업과 신중한 리허설이 있었는지 아마도 알지 못할 것입니다.

아날로그 인시던트 그린룸: 다음 프로덕션 장애를 위한 백스테이지 종이 리허설 | Rain Lag