소개

대부분의 팀은 인시던트 대응을 두 가지 방식 중 하나로만 연습합니다. 아예 하지 않거나, 실제 새벽 3시 알람과는 전혀 다른, 잘 짜여진 대본형 테이블탑(Tabletop) 연습만 합니다.

하지만 혼돈을 그냥 느껴볼 수 있다면 어떨까요? 눈앞에서 딸깍거리며 튀고 부딪히는 소리를 듣고, 그 움직임을 볼 수 있다면요? 온콜 트리아지 연습이 핀볼대 위를 미친 듯이 튀어다니는 공처럼, 직관적이고 예측 불가능하다면 어떨까요?

여기서 등장하는 것이 종이 인시던트 스토리 핀볼 테이블(Paper Incident Story Pinball Table) 입니다. 실제 프로덕션 장애를 안전하고 손으로 느낄 수 있는 방식으로 시뮬레이션하기 위해 설계된, 저기술 촉각형 ‘카오스 머신’입니다. 카오스 엔지니어링, 테이블탑 연습, 게임의 요소가 섞인 형태로, SRE와 프로덕트 팀이 함께 온콜 트리아지 역량을 키우도록 돕는 도구입니다.

이 글에서는 이 아이디어가 무엇인지, 어떻게 설계하는지, 그리고 이를 통해 실제 탄탄한 회복력(resiliency)과 신뢰성에 대한 공동 소유감을 어떻게 키울 수 있는지를 살펴봅니다.

왜 촉각적 카오스 머신인가?

디지털 시스템의 장애는 지저분하고 비선형적으로 발생합니다. 로그는 폭발하고, 대시보드는 온통 빨갛게 변하며, 알람은 연쇄적으로 울리고, 의존성들은 비틀거립니다. 그런데 대부분의 트레이닝은 선형적입니다. 슬라이드, 다이어그램, 예상 가능한 시나리오들뿐이죠.

핀볼 테이블 같은 물리적 카오스 머신은 구조화되지 않은, 몸으로 느끼는 랜덤성을 도입합니다.

• 공, 카드, 토큰 등으로 눈에 보이게 인시던트가 등장합니다.
• 서로 다른 컴포넌트에 부딪힐 때 나는 소리를 귀로 듣게 됩니다.
• 여러 개의 ‘인시던트’가 동시에 돌아다니면 시간 압박을 몸으로 느끼게 됩니다.

이것은 안드로이드의 Monkey가 무작위 UI 이벤트를 생성하거나, 카오스 엔지니어링 도구들이 프로세스를 랜덤하게 죽이는 방식처럼, 실제 세계의 혼돈을 닮았습니다. 그러나 여기서는 그 혼돈이 눈에 보이고, 사회적(social) 입니다. 테이블을 둘러싼 모두가 같은 현실을 동시에 바라보게 되는데, 이는 바로 좋은 인시던트 커맨드(Incident Command)가 추구하는 상태이기도 합니다.

물성이 있는 세팅은 팀이 서로 경쟁하는 우선순위, 불완전한 정보, 이벤트들의 충돌을 그대로 다뤄야 하도록 만듭니다. 실제 프로덕션과 똑같이요.

핀볼 메타포: 버그가 아니라 ‘충돌’을 다루는 일

새로 온콜에 합류하는 엔지니어는 인시던트 대응을 종종 “버그를 찾고, 버그를 고치는 일”로 상상합니다. 하지만 실제 인시던트는 대부분 충돌을 관리하는 일에 가깝습니다.

• 하나의 근본 원인(root cause)에 대해 여러 알람이 동시에 울리는 상황
• 종속된 서비스들이 연쇄적으로 장애를 일으키는 상황
• 가용성 vs 배포 속도 vs 비용 같은 상충하는 우선순위
• 여러 팀과 도구가 한 번에 모두 얽혀 들어오는 상황

핀볼 테이블은 이를 구체적으로 보여줍니다.

• **공(볼)**은 이벤트를 나타냅니다. 알람, 장애, 사용자 제보 등.
• **타겟(Target)**은 시스템, 서비스, 컴포넌트(API, DB, 캐시, 결제 게이트웨이 등)를 의미합니다.
• **범퍼(Bumper)**는 모니터링, 중복 구성, 오토힐링(auto-healing) 메커니즘을 나타냅니다.
• 레인(lane)이나 경로는 인시던트 워크플로우나 에스컬레이션 경로를 의미합니다.

연습에서 여러분의 역할은 단순히 “공을 잡는 것”이 아닙니다. 충돌을 관리하고 라우팅하는 것입니다. 무엇에 우선순위를 둘지, 어디에 집중할지, 무엇을 무시할지, 시스템이 소용돌이치듯 망가지는 것을 어떻게 막을지 결정하는 일입니다.

종이 인시던트 스토리 핀볼 테이블 설계하기

실제 전자 장치나 핀볼 캐비닛이 필요하지 않습니다. 큰 화이트보드나 포스터 보드 위에 “종이 핀볼 테이블”을 만들 수 있습니다.

핵심 구성 요소

1. 플레이필드로서의 시스템 맵
   핀볼 플레이필드를 그리듯, 여러분의 아키텍처를 그립니다.

   • 서비스 상자들 (웹, API, DB, 큐, 캐시, 서드파티 연동 등)
   • 서비스 간 의존성을 나타내는 화살표
   • “CI/CD”, “Feature Flags(기능 플래그)”, “Traffic Router(트래픽 라우터)” 같은 특별 존

2. 인시던트 토큰(공 역할)
   인시던트를 물리적 토큰으로 표현합니다.

   • 색깔 있는 자석이나 포스트잇
   • 포커 칩, 구슬, 인쇄된 “인시던트 카드” 등
   • 각 토큰에는 타입이 있습니다. (레이턴시, 에러 스파이크, 데이터 불일치, 서드파티 장애 등)

3. 카오스 트리거
   랜덤성을 주입하는 방법들입니다.

   • 2–3분마다 주사위를 굴리거나 카드를 뽑아 새로운 인시던트를 생성
   • 작은 카오스 덱(Chaos Deck): “API 파드 1개 종료”, “DB 속도 10배 느려짐”, “외부 호출 20% 드롭” 같은 문구
   • 단순한 타임라인 (“T+5에 스토리지 쪽에서 무언가 장애가 발생”)을 잡고, 구체적 양상은 랜덤하게 결정

4. 컨트롤과 플리퍼(Flipper)
   기계식 플리퍼 대신 액션 카드를 사용합니다.

   • 특정 서비스를 스케일 업/다운
   • 배포 롤백
   • 피처 플래그 온/오프
   • 트래픽 라우팅 변경
   • 비필수 기능 스로틀링/제한 이런 것들을 팀이 선택할 수 있는 명시적인 카드나 옵션으로 적어 둡니다.

5. 스코어링과 결과
   다음 기준으로 점수를 매깁니다.

   • 사용자 영향을 얼마나 잘 피했는지/최소화했는지
   • 복구 시간(steady state로 돌아가는 데 걸린 시간)
   • 커뮤니케이션의 명확성과 문서화 정도

이 정도만 갖추면 몇 개의 랜덤 이벤트만으로도 현실적인, 다중 인시던트 스토리가 만들어지는 가볍지만 표현력 있는 시스템이 됩니다.

카오스 엔지니어링과 Kubernetes에서 아이디어 가져오기

시나리오를 실제 프로덕션처럼 느껴지게 만들려면, Kubernetes 스타일의 카오스 실험에서 아이디어를 빌려올 수 있습니다.

• 랜덤 파드 종료 → 특정 서비스에 용량이 줄어든 상태의 인시던트 토큰이 등장
• 네트워크 파티션 → 다이어그램상의 특정 엣지가 “죽거나” 불안정(flaky)해짐
• 리소스 고갈(Resource Starvation) → DB 최대 커넥션 절반 등으로 특정 컴포넌트를 인위적으로 제한
• 잘못된 롤아웃(Bad Rollout) → 롤백 카드가 사용될 때까지 특정 서비스 상자를 “성능 저하(degraded)” 상태로 표기

구체적인 구현 방법은 다음과 같습니다.

• 이런 내용을 담은 카오스 카드를 만듭니다.
  • “API 레플리카 2개 종료; 에러율 20% 스파이크”
  • “API와 캐시 사이 네트워크가 간헐적으로 실패”
  • “새 배포로 인해 5% 사용자에서 인증이 조용히 실패”
• 카오스 카드를 모니터링 단서와 함께 사용합니다.
  • 카오스 카드를 뽑으면, 관련된 ‘알람’ 포스트잇을 함께 건네줍니다.
    예: API_5XX_HIGH, LATENCY_DB, ALERT_3P_PROVIDER_ERRORS 등

목표는 실제 인프라를 완벽하게 모사하는 것이 아닙니다. 실패의 형태(shape) 와, SRE와 프로덕트 팀이 실제로 마주치는 트레이드오프, 가설 수립 방식을 담는 것입니다.

물리적 랜덤성을 이용한 온콜 트리아지 연습

핀볼 테이블 세팅이 끝났다면, 이제 온콜 드릴을 돌릴 수 있습니다. 기본적인 포맷은 다음과 같습니다.

1. 역할 정의하기

   • 인시던트 커맨더(Incident Commander)
   • 커뮤니케이션 리드(상태 공유 담당)
   • 프라이머리 리스폰더(Primary Responder, 온콜 엔지니어)
   • 옵저버/노트 테이커(기록 담당)

2. 카오스 머신 가동

   • 시간 0에, 보드 위에 인시던트 토큰 1–2개를 올립니다.
   • 매 몇 분마다 주사위를 굴리거나 카오스 카드를 뽑아 새로운 이벤트를 생성합니다.

3. 옵저버빌리티(관측 가능성) 시뮬레이션

   • 각 인시던트마다:
     • 1–3개의 알람 정보
     • 미리 인쇄한 차트나 캡처, 혹은 말로 설명하는 “대시보드 스냅샷”을 제공합니다.
   • 참가자는 시간을 소모하는 대신, 더 많은 데이터를 요청할 수 있습니다.

4. 압박 속에서 의사결정하기 참가자들은 다음을 수행해야 합니다.

   • 어떤 인시던트에 우선순위를 둘지 결정
   • (스케일 조정, 롤백, 플래그 토글, 레이트 리밋 등) 어떤 액션을 취할지 선택
   • 그 이유를 소리 내어 설명

5. 시간과 시스템 상태 전개하기

   • 각 결정 후, 진행 역할을 맡은 사람이 보드를 업데이트합니다.
     • 어떤 인시던트는 해결됩니다.
     • 어떤 인시던트는 악화됩니다.
     • 새로운 인시던트가 등장할 수도 있습니다.

물리적인 랜덤성 덕분에 같은 연습을 두 번 돌려도 상황이 매번 다릅니다. 트리아지 연습은 “대본 외우기”가 아니라, 패턴 인식과 의사결정의 질을 키우는 활동이 됩니다.

복구 시간을 핵심 지표로 활용하기

이 접근법의 큰 장점 중 하나는 복구 시간(recovery time) 을 연습에 바로 녹여 넣을 수 있다는 점입니다.

각 인시던트에 대해:

• 시작 시간: 첫 알람이나 토큰이 보드에 나타난 시점
• 복구 시간: 시스템이 정의된 “steady state”로 돌아온 시점

을 기록합니다.

steady state는 간단하게 정의할 수 있습니다.

• 기준선(baseline) 이상으로 사용자 오류가 발생하지 않음
• 레이턴시가 SLO 범위 내로 돌아옴
• 크리티컬 알람이 더 이상 울리지 않음

그 다음, 연습이 끝난 뒤에는:

• 여러 시나리오의 복구 시간을 비교합니다.
• 어떤 결정이 복구를 단축했고, 어떤 결정이 복구를 지연시켰는지를 묻습니다.
• 지식의 단일 실패 지점(single point of failure) 을 찾습니다.
  예: “이 서비스를 롤백하는 방법을 아는 사람은 Alex 한 명뿐이었다.”

시간이 지남에 따라 팀의 성과를 다음과 같이 추적할 수 있습니다.

• 연습에서의 MTTA(Mean Time To Acknowledge, 인지까지 평균 시간)
• MTTR(Mean Time To Recovery, 복구까지 평균 시간)
• 커뮤니케이션이 무너진 인시던트의 수

이 지표들은 실제 프로덕션에서도 중요하게 보는 것들이고, 이제는 저위험 환경에서 이 숫자들을 개선하는 연습을 할 수 있습니다.

간단한 케이스 관리: 종이 인시던트를 위한 종이 티켓

좋은 습관을 강화하기 위해, 핀볼 연습을 가벼운 케이스 관리 시스템과 함께 운영해 보세요.

• 보드 위의 각 인시던트 토큰은 하나의 종이 인시던트 티켓과 매핑됩니다.
• 각 티켓에는 다음을 기록합니다.
  • 탐지 시간
  • 징후(알람, 사용자 제보)
  • 추정 원인들
  • 취한 액션(타임스탬프와 함께)
  • 해결/완화 방법
  • 후속 작업 항목이나 배운 점

연습 중에는 누군가(보통 옵저버)가 인시던트 서기(scribe) 역할을 맡습니다.

이 방식의 장점:

• 팀은 간결하고 유용한 타임라인 작성 연습을 하게 됩니다.
• 사후 인시던트 리뷰(post-incident review) 자료를 즉시 확보하게 됩니다.
• 문서화가 인시던트 대응의 일부이며, 나중에 하는 숙제가 아니라는 인식을 자연스럽게 심어줍니다.

드릴이 끝나면 짧은 레트로를 진행합니다.

• 무엇이 잘 되었는가?
• 어디서 시간을 낭비했거나 혼란이 생겼는가?
• 어떤 플레이북/런북이 필요하지만 아직 존재하지 않는가?
• 어떤 알람이 시끄럽기만 했거나 별로 도움이 되지 않았는가?

이 연습에서 나온 종이 흔적(paper trail)은 트레이닝 자산이자, 실제 시스템을 개선하기 위한 설계 인풋이 됩니다.

신뢰성의 공동 소유를 위해 SRE와 프로덕트 팀 함께 묶기

핀볼 테이블은 SRE가 프로덕트 팀을 위해 대신 진행할 때보다, 함께 할 때 가장 효과적입니다.

• SRE는 신뢰성, 옵저버빌리티, 카오스 패턴에 대한 전문성을 제공합니다.
• 프로덕트 엔지니어는 비즈니스 플로우, 엣지 케이스, 사용자 영향에 대한 감각을 제공합니다.

SRE가 프로덕트 팀과 함께 임베디드(embedded)되어 있을 때 이 드릴을 진행해 보세요.

• 시스템 맵을 공동 설계하여, 양쪽 모두가 실제 동작 방식을 같은 그림으로 이해하게 만듭니다.
• 과거 실제 인시던트를 반영한 카오스 카드를 함께 만듭니다.
• 역할을 로테이션하여, 프로덕트 엔지니어도 가끔 인시던트 커맨더 역할을 해보도록 합니다.

이 과정은 신뢰성의 공동 소유(shared ownership) 를 키워 줍니다.

• 신뢰성은 플랫폼 팀만의 것이 아니라, 제품의 속성으로 인식됩니다.
• 프로덕트 팀은 자신들의 기능이 스트레스 상황에서 어떻게 동작하는지 배우게 됩니다.
• SRE는 프로덕트의 우선순위와 사용자에게 중요한 경로(critical path)에 대한 맥락을 얻습니다.

시간이 지날수록 “SRE 인시던트”와 “프로덕트 인시던트”의 경계가 흐려지는데, 사실 그것이 우리가 원하는 상태에 가깝습니다.

결론

종이 인시던트 스토리 핀볼 테이블은 의도적으로 단순합니다. 종이, 마커, 토큰, 그리고 주사위 하나 정도면 충분합니다. 그러나 이 단순함 속에는 강력한 아이디어가 담겨 있습니다.

• 물리적 카오스를 이용해 실제 운영상 혼돈을 흉내낸다.
• 온콜 트리아지를 개인 플레이가 아닌 팀 스포츠로 연습한다.
• 복구 시간, 커뮤니케이션, 불확실성 속의 의사결정에 초점을 맞춘다.
• 카오스 엔지니어링 원칙을 누구나 접근 가능한 저기술 포맷으로 가져온다.

무엇보다도, 핀볼 메타포는 엔지니어에게 인시던트 대응이 단일 버그를 사냥하는 일이 아니라는 점을 상기시켜 줍니다. 이는 빠르게 움직이는 이벤트, 알람, 장애, 사람들 간의 충돌을 관리하고, 전체 시스템을 다시 안정성으로 이끄는 일입니다.

지금 여러분의 인시던트 트레이닝이 평면적이거나 이론적으로만 느껴진다면, 직접 종이 카오스 머신을 만들어 보세요. 인덱스 카드 몇 장과 핀볼 마인드셋만으로도, 팀이 얼마나 많은 것을 배울 수 있는지 놀라게 될지도 모릅니다.