소개

군사 작전 기획자들은 수세기 동안 샌드테이블을 사용해 왔습니다. 지형을 물리적으로 재현한 모형 위에서 지휘관들은 작전을 단계별로 밟아 보며, 다양한 가정을 검토하고, 실제 상황이 어떻게 틀어질 수 있는지 미리 상상해 봅니다. 디지털 시대에 들어와 우리는 대부분 모래와 실 대신 대시보드와 다이어그램을 택했습니다.

하지만 복잡한 장애와 연쇄적인 실패를 다룰 때, 많은 조직에 진짜로 빠져 있는 건 바로 이런 아날로그 방식의 사고입니다.

이 글에서는 **“아날로그 장애 스토리 샌드테이블”**을 살펴봅니다. 종이와 펜만으로, 인시던트가 시스템 전반에 걸쳐 어떻게 전개되는지 리허설하는 저기술 방식입니다. 인프라와 공급망을 나타내는 ‘종이 지형(paper terrain)’을 만드는 방법과, 이를 활용해 테이블탑(Tabletop) 연습을 진행하면서 취약 지점, 의존성 리스크, 사고 대응 계획에서 빠져 있는 부분을 실제 장애가 터지기 전에 미리 드러내는 방법을 알아봅니다.

디지털 장애일수록 아날로그가 중요한 이유

실제 인시던트가 터지면, 현실은 대개 다음과 같습니다.

• 불완전하고 지연된 텔레메트리
• 서로 모순되는 대시보드
• 여러 도구를 오가며 쏟아지는 다급한 메시지
• 업데이트를 요구하는 이해관계자들

시뮬레이션 도구, 카오스 실험, 디지털 트윈은 강력하지만, 모든 시스템에 대해 쉽게 구축하거나 안전하게 돌릴 수 있는 것은 아닙니다. 아날로그 샌드테이블 연습은 이를 아주 단순하게 만듭니다.

• 코드 배포 없음
• 프로덕션에 대한 리스크 없음
• 펜, 포스트잇, 테이블 말고는 필요한 도구 없음

여기서 리허설하는 것은 스토리, 즉 장애가 여러분의 생태계를 통과하며 움직이는 이야기이지, 밀리초 단위 CPU 지표 같은 정밀한 수치가 아닙니다. 이 스토리가 바로 엔지니어링, 운영, 보안, 비즈니스 이해관계자들을 한 방향으로 맞추게 해 줍니다. 실제로 중요한 것이 무엇인지, 일이 틀어졌을 때 모두가 같은 그림을 보게 합니다.

이렇게 생각해 볼 수 있습니다.

종이와 마커, 그리고 불편한 진실을 솔직히 마주하는 태도로 진행하는, 여러분이 맞이할 최악의 날에 대한 안전한 공동 리허설.

1단계: 종이 지형을 빚는다 – 실제 존재하는 것을 지도화하기

샌드테이블은 시스템 전반의 풍경을 물리적으로 표현한 지도에서 시작합니다. 슬라이드용으로 깔끔하게 다듬은 아키텍처 다이어그램이 아니라, 현실을 최대한 반영한 작업용 모델이어야 합니다.

테이블 위에 올려야 할 것들

인덱스 카드, 포스트잇, 또는 컴포넌트를 인쇄한 카드를 사용합니다. 카드 하나가 다음과 같은 개별 요소 하나를 대표하게 만드세요.

• 코어 서비스: 인증, 빌링, 검색, API 게이트웨이 등
• 데이터 저장소: 데이터베이스, 캐시, 오브젝트 스토리지, 분석용 데이터 웨어하우스
• 인프라: 로드 밸런서, 메시지 큐, DNS, CDN, VPN
• 애플리케이션: 고객 대상 앱, 사내 도구, 모바일 클라이언트
• 보안/컴플라이언스 계층: WAF, IAM, SIEM, 모니터링 및 알림 시스템
• 상류(Upstream) 의존성: 결제 대행사, 이메일 서비스, 클라우드 리전, 아이덴티티 제공자(IdP) 등
• 하류(Downstream) 소비자: 핵심 연동 파트너, 주요 파트너사, 해당 시스템에 크게 의존하는 내부 팀

카드를 대략적인 "존"으로 나눠 배치합니다. 예를 들면 엣지(Edge), 코어 서비스(Core Services), 데이터(Data), 서드파티(Third Parties), 비즈니스 기능(Business Functions) 같은 식입니다. 컴포넌트 간 의존성은 화살표로 연결해 표시합니다.

이게 바로 여러분의 **종이 지형(paper terrain)**입니다. 완벽하지는 않지만, 실제 환경을 손으로 만질 수 있는 형태로 옮긴 모델입니다.

완벽함보다 상호작용에 초점을 맞추기

목표는 종이로 만든 완벽한 CMDB가 아닙니다. 목표는 공유된 멘탈 모델입니다.

• 엔지니어는 자신이 맡은 서비스가 더 큰 그림에서 어디에 위치하는지 이해합니다.
• 비즈니스 이해관계자는 기술적 장애가 고객-facing 기능에 어떻게 영향을 주는지 눈으로 봅니다.
• 보안팀은 중요한 통제가 실제로 어디에 놓여 있는지 확인합니다.

“이 서비스는 여기 두어야 한다 / 아니다”라거나 “저건 뭘 의존하는 거냐”를 두고 사람들이 논쟁을 시작한다면, 잘하고 있는 겁니다. 그 논쟁 자체가 바로 이 작업의 핵심입니다.

2단계: 장애가 걸려 있는 의존성을 지도처럼 그리기

장애는 한곳에 머물러 있지 않습니다. “작은” 문제 하나가 대형 인시던트로 번지는 이유는, 구성 요소들이 부하 상황에서 서로 어떻게 상호작용하는지 아무도 충분히 이해하지 못했기 때문인 경우가 많습니다.

샌드테이블 연습은 의존성을 명시적으로 드러내는 작업이 되어야 합니다.

1. 서로 의존하는 컴포넌트 사이에 방향 있는 화살표를 그립니다.
2. 화살표마다 의존성 유형을 라벨로 표시합니다.
   • 데이터: 예) “DB1에 주문 데이터 쓰기”
   • 아이덴티티: 예) “IdP-X의 SSO 필요”
   • 네트워크: 예) “VPN-Y를 통해 터널링”
   • 비즈니스: 예) “월말 마감 프로세스에 필수”
3. 카드 위에 **중요도(크리티컬리티)**를 직접 표시합니다. High / Medium / Low 같은 등급이나 색깔 점을 사용할 수 있습니다.

팀원들이 다음과 같은 부분을 솔직하게 드러내도록 유도하세요.

• 숨겨진 의존성: “사실 그 크론잡이 예전 API도 계속 호출하고 있어요.”
• 공유 리소스를 통한 결합: “이 서비스들은 ‘독립’이라고 말하지만 실제로는 같은 DB 클러스터를 씁니다.”
• 운영 상의 의존성: “이 대시보드가 죽으면, 우리는 거의 눈을 가리고 운영하는 셈입니다.”

단순히 선을 잇는 것이 아니라, 카드 하나가 장애로 인해 쓰지 못하게 되면 다른 세 장의 카드가 조용히 함께 무력화되는 지점을 찾는 것입니다.

3단계: 핵심 시스템과 주요 조직 활동에 우선순위를 매기기

모든 시스템이 장애 리허설에서 똑같이 중요한 것은 아닙니다. 우선 다음과 같은 시스템들에 집중하세요.

• 매출이나 핵심 미션 달성에 직접 영향을 주는 시스템
• 민감 데이터나 규제 대상 기능을 처리하는 시스템
• 운영상의 핵심 축이 되는 시스템 (예: 인증, 메시징, 로깅 등)

질문을 던져 봅니다.

• “이 카드가 사라지면 가장 먼저 무너지는 비즈니스 활동은 무엇인가?”
• “심각한 피해(재무적, 법적, 평판)가 발생하기까지 얼마나 걸리는가?”

다음과 같은 기능들을 떠받치고 있는 시스템에 표시를 해 둡니다.

• 고객 가입, 로그인, 결제(Checkout)
• 규제 보고 및 공시
• 생산/운영 시스템(예: 제조 공정 제어 시스템)
• 중요한 내부 워크플로우(예: 자체 인시던트 관리 플랫폼)

초기 샌드테이블 세션은 이런 영향도가 높은 컴포넌트에 초점을 맞추는 것이 좋습니다. 여기서 장애 리허설에 익숙해지고 나면, 점차 범위를 넓혀 더 다양한 시나리오를 다룰 수 있습니다.

4단계: 공급망을 테이블 위로 끌어올리기

요즘 장애의 상당수는 순수하게 “내부” 문제만으로 끝나지 않습니다. 장애는 다음과 같은 경로를 타고 흘러갑니다.

• 클라우드 제공업체와 특정 리전
• 매니지드 데이터베이스와 SaaS 도구
• 서드파티 API (결제, 커뮤니케이션, 아이덴티티, 분석 등)
• 오픈소스 라이브러리와 프리빌트(Pre-built) 컴포넌트

현실적인 리허설을 위해서는, 공급망 리스크 분석을 종이 지형에 통합해야 합니다.

1. 여러분이 의존하고 있는 주요 서드파티 시스템에 대한 카드를 만듭니다.
2. 각 카드에 다음을 적습니다.
   • 어떤 내부 서비스가 이 서드파티에 의존하는지
   • 이것이 실패했을 때 영향을 받는 비즈니스 프로세스는 무엇인지
   • 존재하는 SLA / SLO (얼마나 오래 장애가 지속될 수 있다고 가정해야 하는지)
3. 필요한 경우 **상류의 상류(Upstream of upstream)**도 고려합니다. 예) 클라우드 리전, 네트워크 제공자, DNS 권한 기관 등

그다음, 연습 중에 다음과 같은 시나리오를 포함해 보세요.

• 대형 SaaS 제공업체가 장애를 겪는 상황
• 특정 클라우드 리전 전체가 장애 상태가 되는 상황
• 핵심 보안 벤더가 침해(Compromise)를 당하는 상황

장애가 어떻게 연쇄적으로 번지는지 한 단계씩 따라가 봅니다. 그러다 보면 다음과 같은 사실을 금방 확인하게 됩니다.

• 단일 제공업체에 리스크가 과도하게 집중되어 있는지
• 페일오버 전략이 부실하거나 없는지
• 외부 장애의 영향 반경(Blast radius)을 지나치게 과소평가하고 있었는지

5단계: 장애 스토리를 테이블탑 연습으로 실행하기

이제 지형은 준비되었습니다. 이번에는 스토리를 시작할 차례입니다.

시나리오 설정하기

현실적으로 일어날 법한 “불씨”를 하나 고릅니다.

• “Region A의 기본(Primary) 데이터베이스 클러스터에 접근할 수 없게 된다.”
• “우리 아이덴티티 제공자가 침해되었다. 신뢰 관계를 즉시 철회해야 한다.”
• “서드파티 결제 대행사가 부분적으로 장애를 겪으며 간헐적으로 실패한다.”

정보를 단계적으로 공개하고, 그룹의 집중을 유지해 줄 퍼실리테이터를 한 명 지정합니다.

분 단위로 스토리를 진행하기

시나리오가 한 단계씩 진행될 때마다 다음 질문을 던집니다.

• 지금 이 순간 직접적으로 영향을 받는 카드는 무엇인가?
• 그 결과로 어떤 의존성들이 함께 실패하는가?
• 사용자 입장에서는 무엇이 보이고, 어떤 문제가 느껴지는가?
• 내부 팀은 무엇을 보고, 무엇을 보지 못하는가?
• 우리는 이 상황이 벌어지고 있다는 사실을 어떻게 인지하게 되는가?

카드를 움직이거나 뒤집어서 상태를 표시합니다.

• ❌ 완전 다운
• ⚠️ 성능 저하 또는 부분 장애
• ❓ 상태 불명 / 확실치 않음

동시에 다음을 기록합니다.

• 탐지(Detection): 문제를 어떻게, 어디서 처음 알아차리는지
• 진단(Diagnosis): 원인을 어떻게 좁혀 나가는지
• 커뮤니케이션(Communication): 누구에게, 어떤 채널로, 언제 알릴 것인지
• 조정(Co-ordination): 어떤 팀이 리드하고, 어떤 팀이 지원하는지
• 의사결정 포인트: 언제 페일오버를 할지, 기능을 의도적으로 낮출지, 인시던트를 공식 선언할지

여기서는 기술적인 장애 흐름과 사람들의 대응 두 가지를 동시에 리허설하는 것입니다.

6단계: 연습 결과를 사고 대응 계획 점검과 개선에 활용하기

샌드테이블 세션 하나하나는 사실상 사고 대응 계획(Incident Response Plan)에 대한 숨은 테스트입니다. 시나리오를 따라가면서, 옆에 사고 대응 계획 문서를 펼쳐 놓고 비교해 보세요.

반복해서 물어봅니다.

• 우리가 실제로 하고 있는 행동과, 문서에 적힌 계획이 일치하는가?
• 단계별로 역할과 책임이 명확하게 정의되어 있는가?
• 지금 우리가 취하고 있는 조치에 대해, 문서화된 런북(Runbook)이 존재하는가?
• 고객, 임원, 규제기관을 위한 커뮤니케이션 템플릿이 준비되어 있는가?

진행하면서 발견한 갭은 바로바로 적어 둡니다.

• 핵심 서드파티에 대한 연락처 정보 부재
• 영향도가 높은 서비스의 소유권(Owner)이 모호함
• 언제 인시던트를 “메이저Incident”로 선언해야 하는지 기준이 없음
• 서드파티의 부분 장애(Intermittent failure)에 대한 플레이북 부재

이런 항목들은 실제로 해결해야 할 행동 가능한 백로그로 다뤄야 합니다. 샌드테이블의 진짜 가치는 오늘 테이블에서 나눈 이야기가 아니라, 그 이야기 덕분에 내일의 실제 인시던트 전에 개선되는 것들입니다.

7단계: 보완재로서의 몰입형·디지털 도구 고려하기

아날로그 샌드테이블은 정렬과 공유 이해를 만드는 데 매우 강력한 도구입니다. 그렇다고 해서 기술적 시뮬레이션을 대체할 수 있는 것은 아니고, 서로를 보완하는 관계입니다.

종이를 활용해 다음을 해냈다면:

• 취약한 의존성을 찾아내고
• 역할과 책임을 명확히 하고
• 현실적인 장애 시나리오를 정의했다면,

그다음에는 그중 일부 스토리를 더 풍부한 시뮬레이션으로 확장할 수 있습니다.

• 인시던트 커맨더 교육을 위한 VR 또는 3D 인프라 시각화
• 시간 압박 속에서 팀이 협업을 연습하는 가상 관제실 시뮬레이션
• 샌드테이블에서 드러난 가정을 실제로 검증하는 카오스 엔지니어링 실험
• 디지털 시나리오 스크립트를 따라 팀을 안내하는 자동화된 테이블탑 도구

샌드테이블은 비용과 리스크가 매우 낮은 리허설 무대입니다. 더 몰입감 있는 도구들은, 한 차원 높은 스케일에서 실제 근육 기억과 도구 활용 능력을 스트레스 테스트하는 곳입니다. 어디에 집중해야 할지 아는 상태에서야 이런 도구들이 진짜 가치를 발휘합니다.

결론: 위기가 스스로 이야기를 쓰기 전에, 먼저 스토리를 연습하라

복잡한 시스템은 복잡한 방식으로 실패합니다. 그리고 그 과정에서 조직이 갖고 있던 블라인드 스팟을 함께 드러냅니다. 실제 장애가 터질 때까지 그 블라인드 스팟을 방치하는 것은, 비용이 너무 비싼 학습 방법입니다.

아날로그 장애 스토리 샌드테이블은 현실적인 대안을 제시합니다.

• 시스템과 공급망을 손으로 만질 수 있는 형태로 지도로 만들고,
• 의존성과 그에 따른 리스크를 명시적으로 드러내며,
• 핵심 비즈니스 활동을 지탱하는 크리티컬 시스템에 집중하고,
• 실제로 대응에 참여할 사람들과 함께 현실적인 장애 스토리를 리허설하고,
• 그 결과를 바탕으로 사고 대응 계획을 정교하게 다듬고, 더 고도화된 시뮬레이션에 반영합니다.

이를 위해 거창한 랩 환경이나 막대한 예산이 필요한 것은 아닙니다. 필요한 것은 종이, 테이블, 시간, 그리고 최악의 날을 미리 함께 걸어가 보려는 의지뿐입니다.

아직 해 본 적이 없다면, 우선 한 개의 크리티컬 시스템부터 골라 보세요. 관련된 사람들을 모아 첫 번째 종이 지형을 만드세요. 그 테이블 주변에서 나누는 이야기가, 다음 실제 장애가 “치명적 재앙”이 아니라 “버틸 수 있는 위기”로 남게 만드는 이유가 될지도 모릅니다.