골판지 신뢰성 인형극 무대: 장애가 프로덕션에 가기 전에 연극으로 리허설하기

현대의 Site Reliability Engineering(SRE)은 대개 사용자에게 이미 영향을 준 뒤에야 장애를 다루는 데 많은 시간을 씁니다. 하지만 극단이 개막 전에 리허설을 하듯, 장애도 미리 연습할 수 있다면 어떨까요? 골판지, 실, 종이로 만든 마리오네트 인형만으로 연쇄 장애, 커뮤니케이션 오류, 기묘한 엣지 케이스를 탐색할 수 있다면요?

여기 등장하는 것이 바로 골판지 신뢰성 인형극 무대입니다. 의도적으로 저기술(low‑tech)이고 장난스러운 방식으로, 장애를 시뮬레이션하고, 대응을 연습하며, 문제를 프로덕션에 나타나기 전에 드러내는 도구입니다.

이 글에서는 이 방법이 왜 효과적인지, 기존 SRE 실천과 어떻게 어울리는지, 그리고 여러분 팀만의 신뢰성 인형극 무대를 어떻게 만들 수 있는지 살펴보겠습니다.

왜 SRE에 ‘놀이’와 ‘연습’이 더 필요할까

SRE의 본질은 불확실성 속에서의 신뢰성입니다. 팀은 다음과 같은 일을 합니다.

대규모 시스템의 **가용성(availability)**과 **성능(performance)**을 모니터링하고 개선합니다.
결함 허용(fault tolerance), 우아한 장애(graceful degradation), **빠른 복구(rapid recovery)**를 고려해 시스템을 설계합니다.
사용자가 고통을 느끼기 전에, 문제를 최대한 일찍 감지하고 대응하려 합니다.

이미 우리에겐 훌륭한 도구들이 있습니다. 관측성(observability) 스택, 카오스 실험(chaos engineering), 부하 테스트, 런북(runbook), 장애 후 회고(post‑incident review) 등이 그렇습니다. 하지만 이런 도구들은 종종 다음과 같은 특징을 가집니다.

위험 부담이 큼 – 아무리 신중히 해도 프로덕션에서 카오스를 돌리는 건 스트레스가 큽니다.
시간 압박이 큼 – 실제 장애는 우리가 완벽한 설명을 준비할 때까지 기다려주지 않습니다.
추상적임 – 다이어그램과 대시보드는, 장애를 악화시키는 사람 간 상호작용이나 오해를 항상 잘 드러내지 못합니다.

그래서 장난스럽고, 비용이 거의 들지 않는 도구가 필요합니다. 골판지 무대와 종이 인형으로 장애를 연기해 보면:

감정적인 부담이 줄어듭니다.
보이지 않던 의존성이 물리적으로 눈앞에 드러납니다.
기술적인 해결만이 아니라, 커뮤니케이션과 협조 자체를 연습하게 됩니다.

이건 기존 도구를 대체하는 것이 아닙니다. 시스템이 실패하는 속도보다 더 빨리 학습하게 해 주는 보완재입니다.

“신뢰성 인형극 무대”란 무엇인가

**신뢰성 인형극 무대(reliability puppet stage)**는 이름 그대로입니다.

시스템을 표현하는 단순한 골판지 “무대”
서비스, 사용자, 팀, 도구, 심지어 장애 양상까지 표현하는 종이/골판지 인형
의존 관계와 데이터 흐름을 나타내는 실, 막대, 라벨
시나리오를 설명하고, 팀원들이 인형으로 대응을 연기하도록 이끄는 진행자(facilitator)

소위 말하는 테이블탑(tabletop) 장애 시뮬레이션에 소품을 더한 것이라고 보면 됩니다. 예술성은 중요하지 않습니다. 핵심은 상호작용과 스토리텔링입니다.

인형극이 의외로 잘 통하는 이유

교육용 인형극 연구와 교실 현장의 경험에 따르면:

**스토리텔링과 역할놀이(role‑play)**는 몰입도와 기억력을 높입니다.
학생(어른도 마찬가지)은 자신의 목소리 대신 “인형을 통해” 헷갈리는 부분을 드러낼 때 더 안전하다고 느낍니다.
물리적인 소품은 자율적인 문제 해결, 실험, “만약 이렇게 되면?” 하는 상상력을 자극합니다.

SRE 팀도 동일한 효과를 활용할 수 있습니다. “Cache(캐시)”라고 적힌 종이 마리오네트가 드라마틱하게 쓰러지는 장면은 웃기지만, 그 덕분에 실패가 구체적이고 이야기하기 쉬운 것이 됩니다.

나만의 골판지 장애 무대 디자인하기

필요한 것은 많지 않습니다.

무대 역할을 할 골판지 한 장 혹은 화이트보드
인형용 인덱스 카드나 종이
테이프, 마커, 실, 막대(아니면 그냥 손)

1단계: 등장인물(캐스트) 정리하기

다음 요소들을 인형으로 만듭니다.

핵심 서비스: API, 프론트엔드, 인증(auth), 결제(payments), 데이터베이스(DB), 캐시(cache), 메시지 큐(message queue)
외부 의존성: 서드파티 API, DNS, 클라우드 제공자
사용자: 최종 사용자, 사내 고객, 온콜(on‑call) 엔지니어
도구 및 프로세스: 모니터링, 알림(alerting), 런북, 인시던트 커맨더(incident commander)
장애 패턴(Failure modes): “Network Partition(네트워크 분할)”, “Thundering Herd(떼 몰림 현상)”, “Disk Full(디스크 가득 참)”, “Deployment Gone Wrong(배포 실패)”

각 인형에는 명확한 라벨을 붙입니다. 디자인을 복잡하게 만들 필요는 없습니다. 막대기 사람(stick figure) 정도면 충분합니다.

2단계: 관계 표현하기

실, 화살표, 선을 이용해 다음을 표현합니다.

데이터 흐름 (user → frontend → API → DB)
의존성 (서비스 A가 서비스 B에 의존)
제어 경로 (alerts → on‑call → incident channel)

목표는 각자의 멘탈 모델을 외부화하는 것입니다. 이 단계만으로도 서로 이해가 엇갈려 있음을 발견하는 경우가 많습니다.

3단계: 간단한 시나리오 정의하기

작지만 현실적인 장애 상황으로 시작해 보세요. 예를 들면:

“캐시 제거 버그로 DB 트래픽이 갑자기 급증한다.”
“서드파티 결제 제공자의 레이턴시가 3배로 늘어난다.”
“새 배포가 조용히 핵심 클라이언트의 재시도 로직을 비활성화한다.”

각 시나리오는 카드에 한 줄로 적어둡니다. 진행자가 카드를 소개하면, 그때부터 인형극이 시작됩니다.

인형극으로 장애 시뮬레이션 진행하기

이 세션은 45–60분 정도의 짧은 연습으로 운영할 수 있습니다.

1. 배경 세팅

진행자가 “정상” 상태의 인형들을 무대 위에 배치합니다.
누가 누구를 호출하고, 무엇이 핵심이고, 무엇이 있으면 좋은(optional)지 간단히 설명합니다.
역할을 나눕니다. 누군가는 온콜, 누군가는 관측성, 누군가는 데이터베이스 등으로.

2. 장애 트리거하기

진행자가 장애 카드 소개: 예) “10:03에 캐시가 에러를 반환하기 시작한다.”
해당 인형을 맡은 사람이 인형을 흔들거나, 쓰러뜨리거나, 위치를 바꾸며 장애를 표현합니다.
진행자는 시나리오가 전개되는 동안 시간을 추적합니다. ("지금은 T+5분입니다… T+15분입니다…")

3. 탐지와 대응 연기하기

참가자들에게 각자 역할에 맞춰 반응해 달라고 합니다.

모니터링이 눈치챘나요? “Alerting” 인형을 움직이며 가짜 알림을 읽어봅니다.
온콜은 가장 먼저 무엇을 하나요? 어느 인형에게 “말을 걸고”, 어떤 대시보드를 “본다”고 하나요?
누군가 “DB는 괜찮을 거야”라고 가정하면, 그 가정이 인형 움직임에도 반영되도록 합니다.

이 과정을 통해 시스템의 행동뿐 아니라 팀의 행동도 함께 볼 수 있습니다.

4. 반전(트위스트) 추가하기

대응 패턴이 어느 정도 잡히면, 진행자는 다음과 같은 요소를 더할 수 있습니다.

두 번째 장애 인형 추가 (“이제 재시도가 큐를 과부하 시킨다.”)
관측성 부족 드러내기 (“새로운 의존성에 대한 레이턴시 메트릭이 없다는 걸 깨닫는다.”)
커뮤니케이션 문제 시뮬레이션 (“상태 페이지가 30분 동안 업데이트되지 않는다.”)

이런 반전들은 숨겨진 결합도, 빠져 있는 안전장치, 취약한 절차를 드러냅니다.

5. 되돌아보기(디브리핑)와 학습 정리

20–30분 정도 인형극을 진행한 뒤, 잠시 멈추고 논의합니다.

어떤 탐지 경로에 가장 많이 의존했나요? 그 경로는 견고했나요?
어디서 “추측”에 의존했나요? 어떤 데이터가 없었나요?
어떤 단계가 가장 오래 걸렸나요? 혼선이나 불일치가 나타난 지점은 어디였나요?
이 일이 내일 실제 프로덕션에서 벌어진다면, 무엇이 달라져 있길 바라나요?

이 논의를 구체적인 액션 아이템으로 연결합니다.

새로운 알림이나 대시보드 추가
더 명확한 책임 범위 정의
런북 업데이트
가정을 검증하기 위한 실험

이렇게 해서 실패보다 빠른 학습이 이뤄집니다. 실제로 장애가 일어나지 않았지만, 학습은 진짜입니다.

왜 이런 저기술 방식이 고기술 시스템에서 통할까

겉보기엔 단순하지만, 골판지 무대는 몇 가지 강력한 메커니즘을 활용합니다.

1. 안전하고 부담 없는 탐색

인형극은 누구나 보기에도 시뮬레이션입니다. 이 심리적 거리감 덕분에:

비난에 대한 두려움이 줄어듭니다.
“잘 모르겠다”는 말을 더 쉽게 할 수 있습니다.
“별로인 것 같은 아이디어”도 마음 편히 실험해 볼 수 있습니다.

위험이 0에 가까울수록 창의성은 올라가고, 솔직한 성찰도 쉬워집니다.

2. 복잡성을 손에 잡히게 만들기

대규모 시스템은 한 사람이 머릿속에 모두 담기엔 너무 큽니다. 인형은:

보이지 않는 네트워크 호출을 눈에 보이는 선과 위치로 바꿔 줍니다.
무대가 얼마나 복잡하게 얽히는지로 결합도를 한눈에 보여 줍니다.
“잠깐만, 왜 이게 저것에 의존하지?” 같은 질문을 하게 만듭니다.

바로 그 순간, 숨겨져 있던 문제가 수면 위로 떠오릅니다.

3. 장애의 ‘인간적인 측면’ 연습하기

대부분의 포스트모템은 기술적 실패뿐 아니라 다음과 같은 요인을 함께 드러냅니다.

오해와 불명확한 책임 범위
느리거나 과도하게 시끄러운 장애 대응
모호한 의사결정 권한

인형극 시뮬레이션은 팀이 다음을 리허설하도록 돕습니다.

누가 인시던트 커맨더가 되는지
내부와 외부에 상태를 어떻게 공유하는지
장애가 여러 팀이나 타임존을 걸쳐 이어질 때 인수인계를 어떻게 하는지

이 과정에서 디버깅 대상은 단지 시스템만이 아니라 대응 프로세스 자체가 됩니다.

4. 스토리텔링을 학습 엔진으로 활용하기

교육용 인형극의 관점에서 보면, 장애는 하나의 이야기입니다.

등장인물(서비스와 사람들)이 있고
갈등(장애, 과부하, 버그)이 있으며
해결(완화, 복구, 학습)이 있습니다.

이야기 구조는 정보를 오래 기억하게 만듭니다. 나중에 실제 장애를 맞닥뜨렸을 때, 사람들은 “이거, 캐시가 조용히 죽어서 DB가 녹아내리던 그 인형극이랑 비슷하다”는 식으로 떠올릴 수 있습니다.

인형극 무대를 SRE 실천에 녹여 넣기

지속적인 가치를 얻으려면, 인형극 무대를 신뢰성 문화의 일부로 만들어야 합니다.

정기 드릴: 소방훈련처럼 월간 혹은 분기별로 세션을 운영합니다.
크로스팀 참여: 가끔은 프로덕트, 지원, 리더십도 함께 참여시킵니다.
진행자 교체: 여러 사람이 돌아가며 진행자가 되면, 서로 다른 관점의 장애 양상을 떠올리게 됩니다.
시스템 버전 관리: 아키텍처가 바뀌면 인형도 업데이트합니다.

다른 실천과도 연계할 수 있습니다.

실제 장애 후 회고에서 나온 시나리오를 인형극용으로 재구성합니다.
새로운 아키텍처 설계를 구현 전에 인형극으로 먼저 “연기”해 봅니다.
인형극에서 드러난 문제를 신뢰성 개선 백로그 우선순위에 반영합니다.

시간이 지나면, 이런 장난기 있는 리허설이 팀의 근육 기억을 만듭니다. 팀은 더 자신감 있고, 정렬이 잘 맞고, 문제를 더 일찍 탐지하고 대응하는 데 능숙해집니다. 이것이 바로 SRE가 지향하는 바입니다.

결론: 실패보다 더 빠르게 학습하기

골판지 상자와 종이 인형 몇 개는 프로덕션 텔레메트리, 카오스 실험, 탄탄한 엔지니어링을 대체할 수 없습니다. 하지만 그럴 필요도 없습니다. 이 도구의 힘은 다음과 같은 점에 있습니다.

부담을 낮춰 솔직한 탐색을 이끌어낸다는 것
추상적인 아키텍처를 구체적이고 공유 가능한 모델로 만든다는 것
스토리텔링, 역할놀이, 교육용 인형극 기법을 활용해 몰입과 자율적 문제 해결을 촉진한다는 것

골판지 신뢰성 인형극 무대는 장애 대응 연습을 단순한 피해 통제가 아니라 반복적인 학습 과정으로 다시 정의합니다. 장애가 프로덕션에 닥치기 전에 연극으로 먼저 겪어 봄으로써, 팀은 약한 신호를 더 일찍 포착하고, 더 효과적으로 협력하며, 덜 당황하고 더 명확하게 대응할 수 있게 됩니다.

다시 말해, 실제 장애는 리허설 없이 맞지 않도록 미리 연습하는 셈입니다. 사용자에게는 그 연극을 보여주지 않아도 되도록요.

필요한 것은 골판지, 마커 몇 개, 그리고 신뢰성을 위해 시스템과 팀이 조금은 연극적이 되는 것을 즐겁게 받아들이려는 마음뿐입니다.