신뢰성 인덱스 카드 기차 세트: 거대한 장애를 연습하는 작은 종이 시나리오

모형 기차 세트에는 묘한 매력이 있습니다. 작고, 저렴하고, 안전하지만 선로, 스위치, 스케줄, 충돌까지 하나의 세계를 통째로 시뮬레이션할 수 있죠. 실제 200톤짜리 기관차를 선로에 올리기 전에, 시스템이 어떻게 움직이는지 배울 수 있습니다.

신뢰성을 위한 테이블탑 연습은 바로 여러분의 인덱스 카드 기차 세트입니다.

비용과 리스크가 낮은 시뮬레이션을 통해, 팀은 실제 고객에게 영향을 주는 사건 앞에 서기 전에 장애와 비상 상황에 대응하는 연습을 할 수 있습니다. 인덱스 카드 몇 장, 단순한 시나리오 하나, 그리고 회의실(또는 화상회의)에 모인 몇 사람만 있어도,

혼돈스러운 장애 대응 ↔︎ 조직적이고 자신감 있는 대응

을 가르는 차이가 됩니다.

이 글에서는 테이블탑 연습이 무엇인지, 왜 신뢰성을 높이는 ROI 높은 도구인지, 그리고 이걸 거대한 프로젝트로 만들지 않고도 설계하고 운영하는 방법을 다룹니다.

테이블탑 연습, 정확히 뭐죠?

가장 본질적으로, **테이블탑 연습(Tabletop Exercise, TTX)**은 구조화된, 시간 제한이 있는 대화입니다.

“이런 상황이 벌어졌습니다. 점점 악화되고 있습니다. 이제 무엇을 하시겠습니까? 그리고 그게 효과가 있는지는 어떻게 확인하죠?”

풀스케일 통합 테스트나 Chaos Engineering 실험과 달리, 테이블탑 연습은 다음과 같습니다.

• 저비용 – 랩 환경, 특수 도구, 실제 프로덕션 실험이 필요 없습니다.
• 저위험 – 시스템을 실제로 망가뜨리지 않고, 어떻게 대응할지를 탐색합니다.
• 고신호 – 계획, 역할, 도구, 커뮤니케이션의 빈틈을 빠르게 드러냅니다.

Incident Response를 위한 **프리게임 드릴(pre-game drill)**이라고 생각하면 됩니다.

• 실제 게임(장애)이 시작되기 전에, 플레이(대응 패턴)를 연습합니다.
• 시계가 돌아가는 상황에서 플레이북이 실제로 통하는지 시험합니다.
• 각자의 포지션—누가 무엇의 오너인지, 어떻게 소통하는지—를 점검합니다.

목표는 모든 장애 유형을 잡아내는 것이 아닙니다. 반복해서 연습해야 할 것은 다음과 같습니다.

• 문제 조기 인지
• 압박 속에서의 팀 간 조율
• 불완전한 정보로 의사결정하기
• 팀/조직 전체에 명확하게 커뮤니케이션하기

성숙한 신뢰성 조직이 테이블탑 연습을 사랑하는 이유

강한 신뢰성과 Incident Response 문화를 가진 조직을 보면, 거의 항상 정기적인 테이블탑 연습이 같이 있습니다.

이들은 성숙도를 보여주는 지표입니다. 그 이유는 다음과 같습니다.

1. 현실이 드러내기 전에, 약점을 먼저 드러낸다
   고객이 CEO를 멘션해서 트윗하기 전에 다음을 발견합니다.

   • 빠진 런북(runbook)
   • 불분명한 오너십
   • 취약한 의존성
   • 끊기거나 우회되는 커뮤니케이션 라인

2. 실제 Incident에서 쓸 ‘근육 기억’을 만든다
   뭔가 고장 나면 사람은 결국, 연습해 본 그대로 움직입니다. 반복적이고 현실적인 드릴은 실제 장애를 낯선 공포가 아니라, “해봤던 것”에 가깝게 만들어 줍니다.

3. 역할을 넘나드는 공통 컨텍스트를 만든다
   엔지니어, SRE, 고객지원, 보안, 프로덕트, 리더십이 모두, 장애가 어떻게 흘러가는지, 서로에게 실제로 무엇이 필요한지를 직접 보게 됩니다.

4. 비용 대비 효과(ROI)가 압도적이다
   적절한 사람들과 두어 시간만 써도, 이후에 발생할 수 있는 막대한 비용을 막을 수 있습니다.

   • 매출 손실
   • SLA 위반 페널티
   • 브랜드 신뢰 하락
   • 소방전처럼 우왕좌왕하며 겪는 번아웃

요약하면, 테이블탑 연습은 때로는 인덱스 카드와 화이트보드 정도의 작은 투자로 **크고 탄탄한 신뢰성과 회복탄력성(Resilience)**을 끌어내는 장치입니다.

좋은 시나리오는 무엇이 다를까? (도구가 아니다)

가치 있는 연습을 위해 커스텀 시뮬레이션 플랫폼은 필요 없습니다. 필요한 건 현실적이고 잘 조준된 시나리오와 적절한 사람들입니다.

좋은 시나리오는 보통 다음 특징을 갖습니다.

1. 실제 환경을 반영한다
   가능한 한 실제를 그대로 씁니다.

   • 실제 서비스와 의존성
   • 실제 온콜(on-call) 로테이션
   • 실제 모니터링·알림 도구(예: Prometheus, Datadog 등)
   • 실제 커뮤니케이션 채널(Slack, Teams, 전화 등)

2. 핵심 자산 또는 핵심 플로우를 겨냥한다
   비즈니스에 정말 중요한 것에 집중합니다.

   • 결제 처리
   • 사용자 로그인/인증
   • 코어 API
   • 데이터 무결성 또는 보안 통제

3. SF가 아니라, “충분히 있을 법한” 상황이다
   좋은 시나리오의 재료:

   • 실제로 겪었던 장애 (“이때 상황이 더 악화됐으면 어땠을까?”)
   • 아슬아슬하게 넘어간 사건(near-miss)
   • 취약하다고 이미 알려진 컴포넌트나 의존성

4. 명확한 시간 진행이 있다
   시나리오는 시간에 따라 진화해야 합니다. 예를 들어:

   • T+0분: 알람이 울리기 시작하고, 고객이 에러를 보기 시작한다.
   • T+10분: 에러율이 두 배로 증가하고, 대시보드는 느려진다.
   • T+20분: 의존성 벤더 측에서 장애 공지를 올린다.
   • T+30분: 리더십이 ETA와 영향 범위 요약을 요청한다.

5. 사소한 지식 테스트가 아니라, ‘결정’을 강요한다
   가장 좋은 연습은 누가 특정 CLI 명령어를 외우고 있느냐가 아니라,

   • 판단력
   • 조율 능력
   • 커뮤니케이션 을 검증합니다. 참가자가 “이건 런북을 찾아볼 것 같아요”라고 말해도 괜찮습니다. 현실에서도 다 그렇게 합니다.

토론형 vs. 실습형: 두 가지 연습 스타일

테이블탑 연습은 대체로 두 가지 스타일로 나뉩니다.

1. 토론형(Tabletop Discussion)

가장 클래식한 형식입니다.

• 참가자들이 단계별로 “지금 무엇을 하겠다”를 말로 풀어갑니다.
• 퍼실리테이터가 시간 경과에 따라 새로운 정보를 풀어 줍니다.
• 화이트보드, 포스트잇, 인덱스 카드로 이벤트와 결정을 정리합니다.

적합한 경우:

• Incident 프로세스를 처음 배우는 신규 팀
• 엔지니어링–지원–커뮤니케이션–리더십 등 크로스 펑셔널 조율 연습
• 여러 “그럼 이런 경우엔?” 분기들을 빠르게 탐색하고 싶을 때

2. 운영/실습형(Operational / Hands-On Tabletop)

여기서는 토론에 더해, 실제 도구를 제한적으로 사용해 봅니다. 다만 프로덕션을 실제로 깨뜨리지는 않습니다.

• 실제 모니터링 대시보드와 티켓 시스템에 로그인합니다.
• 실제처럼 알람, Incident 채널, Status 페이지 업데이트를 시뮬레이션합니다.
• 실제 양식, 템플릿, 커뮤니케이션 워크플로를 그대로 써 봅니다.

적합한 경우:

• 도구와 워크플로가 실제로 잘 동작하는지 검증할 때
• 온콜 담당자 교육을 안전하게 하고 싶을 때
• Incident Commander/Incident Lead 역할을 훈련시킬 때

처음에는 순수 토론형으로 시작하고, 팀이 익숙해질수록 점진적으로 실습 요소를 추가해 가면 됩니다.

준비는 무겁지 않아도 된다

유용한 연습을 위해 한 달짜리 프로젝트 플랜은 필요 없습니다. 며칠 정도의 집중된 준비면 충분한 경우가 많습니다.

가벼운 준비 템플릿은 다음과 같습니다.

1. 목표 정의하기
   최대한 구체적으로 적습니다.

   • “부분적인 DB 데이터 손실 상황을 처리할 수 있는지 테스트한다.”
   • “3rd-party 장애 상황에서 크로스팀 조율을 연습한다.”

2. 시나리오 1–2개만 고르기
   범위를 좁히세요. 피상적으로 5개를 훑는 것보다, 1개의 장애를 깊게 파는 편이 훨씬 낫습니다.

3. 참가자를 의도적으로 선정하기
   다음을 포함하는 것이 좋습니다.

   • 온콜 엔지니어(또는 곧 온콜에 들어갈 사람)
   • Incident Commander(또는 그 역할을 연습할 사람)
   • 핵심 파트너 팀 대표(예: 고객지원, 보안, 커뮤니케이션 담당)

4. 간단한 타임라인 스크립트 작성
   T+0, T+10, T+20 등에 무슨 일이 일어나는지 개괄합니다. 참가자가 특정 액션을 했을 때만 공개할 정보도 미리 정해 둡니다.

5. ‘인덱스 카드’를 준비하기
   실제 인덱스 카드여도 좋고, 슬라이드여도 됩니다. 여기에 담습니다.

   • 새로운 증상과 알람
   • 로그나 메트릭 스냅샷
   • 다른 팀이나 고객으로부터 온 메시지
   • 상충되는 정보 같은 ‘변수 카드(curveball)’

6. 기대치를 미리 맞추기
   참가자에게 알려야 할 것:

   • 소요 시간(예: 60–90분)
   • 스코프 안/밖에 무엇이 있는지
   • 목표는 학습이지, 비난이나 완벽한 수행이 아니라는 점

이 정도면 충분합니다. 작은 종이 기차 세트를 굴릴 준비가 끝났습니다.

연습 진행하기: 재미와 마찰이 함께 나오는 구간

연습 중에 여러분이 할 일은, 시스템이 스스로 어떤 약점을 갖고 있는지 드러내도록 두는 것입니다.

필요한 역할들

• 퍼실리테이터(Facilitator) – 시나리오를 이끌고, 정보를 공개하며, 시간을 관리합니다.
• 서기(Scribe) – 결정, 질문, 장애물, 놀랐던 점을 기록합니다.
• 참가자(Participants) – 실제 맡고 있는 역할(온콜, 커맨더, 지원 등)을 그대로 수행합니다.

관찰해야 할 것들

시나리오가 전개되는 동안, 특히 다음을 눈여겨보세요.

• 누가 얼마나 빨리 오너십을 가져가는지
• 어떻게 의사결정이 이뤄지고, 어떻게 공유되는지
• 어디서 막히는지 (권한 부족, 애매한 런북, 도구 사용의 불편함 등)
• 정보가 어떻게 흐르는지 (팀 간, 그리고 이해관계자에게)

참가자가 다음과 같이 행동하는 것은 전혀 문제 없습니다.

• 문서나 런북을 찾아본다.
• “이 상황에 대한 프로세스가 없는 것 같습니다”라고 말한다.
• 여러 옵션을 두고 공개적으로 토론한다.

바로 이런 순간들이, 어디를 개선해야 할지 가장 잘 보여 줍니다.

진짜 가치: 배움을 ‘회복탄력성’으로 바꾸기

연습을 진행하는 것만으로는 가치의 절반만 얻은 것입니다. 나머지 절반은 연습 이후의 리뷰에 있습니다.

복잡할 필요는 없지만, 최소한 의도적으로 진행해야 합니다.

AAR(After-Action Review) 체크리스트

며칠 안에 참가자들을 모아 30–60분 정도 리뷰를 진행하며, 다음을 묻습니다.

1. 무엇이 잘 되었는가?

   • 명확한 핸드오프가 있었는가?
   • 리더십이 적절했는가?
   • 특히 도움이 된 도구나 대시보드는 무엇이었나?

2. 무엇이 헷갈리거나 느렸는가?

   • 역할이나 에스컬레이션 경로가 불명확했는가?
   • 런북이 없거나 오래되었는가?
   • 도구나 접근 권한에서의 공백이 있었는가?

3. 무엇이 우리를 놀라게 했는가?
   놀라운 지점은 대개, 시스템이나 조직이 어떻게 동작하는지에 대한 잘못된 가정을 드러냅니다.

4. 지금 당장 무엇을 바꿀 것인가?
   발견한 내용을 실제 액션으로 바꿉니다.

   • 플레이북과 런북 업데이트
   • 알람과 대시보드 개선
   • 온콜 절차나 역할 조정
   • 새 교육이나 문서화 작업 생성

목표는 완벽함이 아닙니다. 연습을 할 때마다 시스템과 사람이 조금씩 더 강해지도록 하는 것입니다.

진짜 목표: ‘Zero Incident’가 아니라 ‘자신감’

Incident는 완전히 없앨 수 없습니다. 복잡한 시스템은 항상 새롭고 창의적인 방식으로 실패합니다.

테이블탑 연습—신뢰성을 위한 인덱스 카드 기차 세트—의 목적은 다음과 같습니다.

• 일이 잘못될 때, 완전한 백지 상태에서 시작하는 것이 아님을 확신하게 만드는 것
• 스트레스 상황에서도 팀 간 조율 능력을 강화하는 것
• 각 사건에서 대응·복구·학습하는 능력을 끌어올리는 것

시간이 지나며, 가벼운 연습을 꾸준히 이어 가면 문화가 바뀝니다.

• Incident는 그저 “버텨내야 할 일”이 아니라, 배움의 기회가 됩니다.
• 사람들은 자신의 역할을 이해하고, 동료를 신뢰하게 됩니다.
• 리더십은 신뢰성을, 정적인 문서가 아니라 **능동적인 실천(practice)**으로 보게 됩니다.

작게 시작하기: 첫 번째 기차 세트

시작하기 위해 임원 후원이나 거대한 프로그램은 필요 없습니다.

이번 주에 바로 할 수 있는 다음 단계를 제안합니다.

1. 하나의 핵심 서비스와, 그 서비스에 대한 현실적인 “최악의 하루” 시나리오를 고릅니다.
2. 관련 사람들과 90분짜리 일정을 캘린더에 잡습니다.
3. 시간 축을 기준으로 한 간단한 스크립트와, 몇 장의 “이벤트 카드”를 작성합니다.
4. 연습을 진행하고, 끝나기 전에 30분짜리 리뷰를 반드시 하겠다고 스스로에게 약속합니다.

그다음에는 반복하면서 개선합니다. 조금씩 복잡도를 올리고, 시나리오·참가자·포커스 영역을 돌려 가며 바꿔 보세요.

테이블 위의 모형 기차 세트처럼, 이 작은 통제된 시뮬레이션은 신호등이 빨간색으로 바뀌었을 때 시스템이 어떻게 움직이는지를 알려 줍니다. 연습을 할 때마다, 실제 선로—여러분의 서비스, 팀, 고객—는 조금씩 더 안전해집니다.

작은 종이 스케줄, 거대한 장애. 리스크가 낮을 때 미리 연습해 두세요.