아날로그 버그 비행 시뮬레이터: 종이 조종석으로 재난적 장애를 리허설하기

항공 분야에서는 파일럿이 실제 조종석에 앉기 전에 반드시 비행 시뮬레이터에서 수십, 수백 시간 동안 엔진 화재부터 계기판 완전 고장까지 온갖 상황을 반복 훈련합니다. 반면 소프트웨어에서는 많은 팀이 첫 번째 진짜 재난을 실제 프로덕션 환경에서, 그것도 고객이 지켜보는 앞에서 처음 맞이합니다.

꼭 그렇게 될 필요는 없습니다.

이 글에서는 **“아날로그 버그 비행 시뮬레이터”**라는 아이디어를 살펴봅니다. 이는 종이 기반의 저위험 대형 장애 시뮬레이션으로, 실제 재난이 일어나기 훨씬 전에 팀이 인시던트 대응을 연습할 수 있게 해 줍니다. 종이 조종석(paper cockpit), SRE 원칙, 체크리스트, 테이블탑(tabletop) 연습을 결합하면, 통제를 잃은 혼란을 즉흥적 공황 상태가 아닌, 미리 리허설된 퍼포먼스로 바꿀 수 있습니다.

진짜 재난이 오기 전에 꼭 리허설해야 하는 이유

현대 시스템은 다음과 같은 특성을 갖습니다.

• 항상 켜져 있고(always-on) 전 세계에 분산되어 있으며
• 수많은 독립 서비스가 상호작용하는 구조이고
• 컴플라이언스·프라이버시·규제 요건과 촘촘히 얽혀 있습니다.

무언가 크게 잘못되면, 단순히 버그만 상대하는 것이 아닙니다. 동시에 다음과 마주해야 합니다.

• 고객 영향과 평판 리스크
• 컴플라이언스 의무와 법적 노출
• 팀 간 커뮤니케이션 붕괴
• 높은 인지 부하와 정서적 스트레스

이 모든 걸 처음부터 실전 상황에서 알아가라고 기대하는 건 비현실적입니다. 조종사가 시뮬레이터에서 재난 상황을 반복 훈련하듯, 소프트웨어 조직도 프로덕션에서 사고가 나기 전에 저위험 환경에서 재난적 장애를 리허설해야 합니다.

그때 필요한 것이 바로 아날로그 비행 시뮬레이터입니다.

아날로그 버그 비행 시뮬레이터란 무엇인가?

아날로그 버그 비행 시뮬레이터는 종이 기반의, 로우테크(저기술) 대형 인시던트 리허설입니다. 실제나 스테이징 환경에서 카오스 엔지니어링 실험을 돌리는 대신 다음과 같이 진행합니다.

• 시스템을 종이에 그려서 “조종석(cockpit)”으로 만들고
• 시간이 흐르며 전개되는 장애 시나리오를 정의하며
• 누가, 언제, 무엇을, 어떻게 하는지를 단계별로 따라가고
• 실제 상황처럼 체크리스트·런북·인시던트 플레이북을 사용하며
• 진행하면서 의사결정·실수·갭(gap)을 모두 기록합니다.

본질적으로 시스템 중심의 테이블탑(tabletop) 연습이지만, 특히 강조하는 요소는 다음 세 가지입니다.

• 시스템의 동작 방식
• 사람의 의사결정
• 프로세스와 커뮤니케이션

아날로그 방식이기 때문에 다음과 같은 이점이 있습니다.

• 극단적이거나 가능성이 낮은 장애 모드도 안전하게 탐색할 수 있고
• 언제든지 일시정지·되감기·“만약에…” 가지치기를 할 수 있으며
• 아직 모든 시스템에 접근 권한이 없는 사람도 참여시킬 수 있고
• 클릭보다 생각 그 자체에 집중할 수 있습니다.

이때 시험하는 것은 인프라가 아니라, 조직의 대응 능력입니다.

인시던트 대응 계획과 절차의 역할

아날로그 시뮬레이션의 품질은 그 안에서 실제로 실행해 보는 절차의 품질에 달려 있습니다. 그래서 **명확히 정의된 인시던트 대응 계획(incident response plan)**이 필수입니다.

탄탄한 인시던트 대응 계획은 일반적으로 다음을 포함해야 합니다.

• 명확한 역할과 책임 분담
  • 인시던트 커맨더(Incident Commander, IC)
  • 커뮤니케이션 리드
  • 시스템/도메인별 테크니컬 리드
  • 스크라이브 / 인시던트 기록 담당자
• 심각도(severity) 레벨과 트리거 조건
  무엇이 SEV-1이고, 무엇이 SEV-2인가? 누가 심각도를 선언하거나 하향 조정할 수 있는가?
• SOP(Standard Operating Procedure, 표준 운영 절차)
  장애 유형별 단계별 가이드: 서비스 중단, 데이터 유출, 랜섬웨어 등
• 커뮤니케이션 플레이북
  • 내부 커뮤니케이션(Slack/Teams, 이메일, 인시던트 채널)
  • 외부 커뮤니케이션(상태 페이지, 고객 공지, 필요 시 규제 기관 보고)
• 컴플라이언스 및 법무 절차
  예: 데이터 침해 시 법으로 정해진 기한 내에 통지를 해야 할 수 있습니다.

종이 조종석 세션에서는 반드시 이 절차들을 실제처럼 수행해 봐야 합니다.

• 모두가 계획이 존재한다는 사실과, 어디에 있는지를 알고 있는가?
• 새로 합류한 사람도 체크리스트만으로 따라갈 수 있는가?
• 인계·결정 과정이 명확하게 느껴지는가, 아니면 즉흥적이고 혼란스러운가?

아날로그 시뮬레이션은 문서화된 프로세스가 실제와 어디에서 어긋나는지를 드러냅니다. 실제 인시던트가 어그러지는 지점이 바로 여기입니다.

모의 해킹에서 종이 조종석으로: 현실적인 공격 시뮬레이션

성숙한 조직이라면 이미 보통 다음을 수행합니다.

• **침투 테스트(penetration test, 펜테스트)**로 취약점을 찾고
• 테이블탑(tabletop) 연습으로 보안 인시던트를 시나리오 기반으로 검토합니다.

이는 매우 중요하지만, 종종 다음과 같은 한계를 가집니다.

• 보안 관점에만 좁게 초점을 맞추거나
• 이상적인 커뮤니케이션·빠른 의사결정을 전제로 하거나
• 더 넓은 관점의 안정성·비즈니스 영향까지는 잘 다루지 못합니다.

여기에 아날로그 비행 시뮬레이터를 더해 보안과 안정성을 함께 다루면 다음과 같은 효과가 있습니다.

• 펜테스트 결과를 시나리오 씨앗으로 활용할 수 있습니다.
  예: “이 취약점이 새벽 3시에 실제로 악용되었다고 가정하자.”
• 테이블탑 연습을 실제 시간 흐름을 따르는 SRE 스타일 인시던트 드릴로 구조화할 수 있습니다.
• 기술적 장애, 사람(조직) 요인, 비즈니스 결과를 하나의 일관된 리허설 안에서 연결할 수 있습니다.

목표는 단순히 통제가 존재하는지만 확인하는 것이 아니라, 다음을 검증하는 것입니다.

사람, 프로세스, 시스템이 스트레스 상황에서 함께 제대로 작동하는가.

재난 훈련의 뼈대가 되는 SRE 원칙

Site Reliability Engineering(SRE) 원칙은 이런 시뮬레이션을 설계하고 운영하기에 자연스러운 프레임워크를 제공합니다.

도입하면 좋은 핵심 SRE 개념은 다음과 같습니다.

1. SLO(Service Level Objective, 서비스 수준 목표)
   영향도를 구체적으로 만듭니다. 드릴 동안 다음을 추적합니다.

   • 어떤 SLO가 위반되고 있는가?
   • 얼마 동안 SLO 미준수 상태를 버틸 수 있는가?

2. 에러 버짓(Error Budget)
   시나리오를 실제 트레이드오프와 연결합니다.

   • “이번 분기 에러 버짓의 80%를 이미 소진했다면, 어떤 의사결정이 달라지는가?”

3. 인시던트 라이프사이클
   전체 흐름을 연습합니다.

   • 탐지(Detection) → 트라이아지(Triage) → 완화(Mitigation) → 복구(Recovery) → 포스트모템(Postmortem)

4. 블레이멀리스 포스트모템(Blameless Postmortem)
   모든 아날로그 드릴은 비난 없는 회고로 마무리해야 합니다. 예를 들어:

   • 무엇이 상황을 어렵게 만들었는가?
   • 도구·프로세스·조직 구조 중 어떤 것이 발목을 잡았는가?
   • 앞으로 무엇을 바꿀 것인가?

SRE는 시뮬레이션이 단지 혼란을 재연하는 데 그치지 않고, 실제로 탄력성(resilience)을 높이도록 언어와 구조를 제공합니다.

체크리스트와 절차적 규율: 항공에서 배우는 교훈

항공의 높은 안전 기록은 체크리스트와 절차적 규율 위에 구축되어 있습니다. 고도 3만 피트 상공에서는 누구도 기억력에 의존하지 않습니다.

소프트웨어 인시던트에서도 같은 접근을 차용할 수 있습니다.

아날로그 드릴용 체크리스트 예시

1. 인시던트 초기화 체크리스트

   • 인시던트 커맨더 지정
   • 심각도(severity) 레벨 선언
   • 인시던트 채널과 로그 문서 생성
   • 영향받는 서비스와 관련 SLO 식별
   • 온콜(on-call) 인원 및 관련 이해관계자에게 알림

2. 격리·완화(Containment & Mitigation) 체크리스트

   • 추가 피해 방지(예: 악성 IP 차단, 침해 계정 비활성화)
   • 시스템을 가능한 한 가장 안전한 축소(degraded) 상태로 전환
   • 상태를 변경하기 전, 가능한 범위에서 핵심 포렌식 데이터 수집
   • 모든 변경 사항과 타임스탬프를 기록

3. 커뮤니케이션 체크리스트

   • 인시던트 채널에 X분 간격으로 내부 상황 요약 게시
   • 정의된 주기로 외부 상태 페이지(Status Page) 업데이트
   • 기준을 넘을 경우 리더십/법무/PR로 에스컬레이션

종이 기반 시뮬레이션 중에는 이 체크리스트를 실제 인시던트인 것처럼 엄격하게 적용합니다. 시간이 지날수록 다음과 같은 효과를 볼 수 있습니다.

• 저압 환경에서 습관 형성
• 팀·지역·시간대가 달라도 일관된 대응
• 실제 비상 상황에서 인지 부하 감소

목표는 사람을 로봇처럼 만드는 것이 아니라, 체크리스트로 처리 가능한 기본기를 덜어내고 새롭고 복잡한 문제 해결에 인지 자원을 집중하게 만드는 것입니다.

첫 번째 종이 조종석 연습 설계하기

큰 예산이나 화려한 도구가 필요하지 않습니다. 현실적인 첫 연습은 다음과 같이 구성할 수 있습니다.

1. 구체적이고 그럴듯한 재난 시나리오 하나를 고른다

   • 예: “스키마 마이그레이션 중에 주요 데이터베이스 클러스터에서 상관된(correlated) 장애가 발생하고, 페일오버는 예상보다 느리며, 데이터 일관성이 불분명하다.”

2. 크로스펑셔널 그룹을 소집한다

   • 온콜 엔지니어
   • SRE/운영 담당
   • 필요 시 보안 담당
   • 프로덕트 / 고객 성공(CS)
   • 고객 또는 외부 이해관계자 역할을 맡을 사람 1명 이상

3. 종이 조종석을 만든다

   • 화이트보드나 큰 종이에 주요 서비스, 데이터 저장소, 외부 의존성을 그립니다.
   • 모니터링/오브저버빌리티 도구와 커뮤니케이션 채널도 표시합니다.

4. 인시던트 타임라인을 스크립트로 작성한다

   • T+0: 알림(alert) 발생
   • T+5: 추가 알림이 발생하고, 고객이 문제를 보고하기 시작
   • T+20: 2차 시스템에서 연쇄 장애 발생
   • T+45: 데이터 손실 가능성을 시사하는 정황 증거 등장
   • 이후에도 새로운 단서와 복잡성이 점진적으로 추가되도록 구성

5. 시뮬레이션을 실행한다

   • 한 명의 퍼실리테이터가 진행 시간에 따라 새로운 이벤트를 공개합니다.
   • 팀은 실제 상황처럼 문서, 대시보드, 런북을 참고하며 무엇을 할지 설명합니다.
   • 스크라이브가 행동, 질문, 장애물(블로커)을 모두 기록합니다.

6. SRE 스타일 포스트모템으로 디브리핑한다

   • 무엇이 잘 작동했는가?
   • 어디에서 절차가 실패했거나, 아예 존재하지 않았는가?
   • 어떤 문서나 도구가 부족했는가?
   • 앞으로 어떤 구체적 개선 조치를 취할 것인가?

이 연습을 정기적으로 반복하되, 시나리오를 바꾸고 역할을 순환시키세요. 그러면 탄력성이 몇몇 전문가 개인이 아니라 조직 전체에 축적됩니다.

상시 가동 프로덕션 환경에서 이것이 중요한 이유

상시 가동(always-on) 세계에서 다운타임과 데이터 인시던트는 단순한 기술적 결함이 아니라, 재무적·법적·평판상의 영향을 동반하는 비즈니스 이벤트입니다.

아래만으로는 충분하지 않습니다.

• 견고한 아키텍처
• 모니터링과 알림 시스템
• 침투 테스트와 레드팀(red team)

이것들은 필수지만, 충분 조건은 아닙니다.

조직은 다음 또한 보장해야 합니다.

• 사람들이 압박 속에서 자신의 역할을 정확히 알고 있고
• 프로세스가 현실적인 조건에서 검증되었으며
• 커뮤니케이션 경로가 리허설되어 있고 신뢰할 수 있으며
• 컴플라이언스 의무를 이해하고, 실제로 실행할 수 있는 상태인지

재난을 선제적으로 리허설하는 것—특히 저위험 아날로그 시뮬레이션을 통해—은 미지의 리스크를 이미 경험해 본 도전 과제로 바꿉니다. 실제 재난이 닥쳤을 때, 팀은 즉흥 대응을 하는 것이 아니라 연습된 플레이북을 실행하며, 공황이 아닌 익숙함의 상태에서 상황에 적응하게 됩니다.

결론: 실패를 위한 ‘플라이트 스쿨’을 만들자

시뮬레이터에서 훈련해 본 적이 없는 조종사가 모는 비행기에 타고 싶지 않다면, 왜 진짜 재난을 한 번도 리허설해 본 적 없는 상시 가동 시스템을 신뢰해야 할까요?

아날로그 버그 비행 시뮬레이터—종이 조종석, 체크리스트, 구조화된 테이블탑 연습—는 다음을 가능하게 하는 강력하고도 저위험인 방법입니다.

• 인시던트 대응 계획을 실제로 검증하고
• 조직의 의사결정 구조를 스트레스 테스트하며
• SRE 원칙을 일상에 스며들게 만들고
• 보안과 안정성 체계를 동시에 강화합니다.

완벽한 툴링이 없어도 시작할 수 있습니다. 필요한 것은 다음뿐입니다.

• 화이트보드 한 개
• 몇 장의 출력된 체크리스트와 플레이북
• 현실감 있는 시나리오 하나
• 솔직하고 비난 없는 학습에 대한 조직의 의지

작게 시작하세요. 시뮬레이션을 한 번 돌려 보고, 배운 점을 기록한 뒤, 개선합니다.

시간이 지나면 더 탄탄한 시스템뿐 아니라, 재난적 장애가 프로덕션에 발생하기 전에 이미 대비가 되어 있는, 훨씬 더 탄력적인 조직을 갖게 될 것입니다.