연필로 그리는 장애 인형극: 종이 캐릭터로 숨은 장애 경로를 연극처럼 드러내기

복잡한 시스템에서 큰 사고가 터졌을 때 상황을 파악해 본 적이 있다면, 그 느낌을 잘 알 겁니다. 로그는 미친 듯이 쏟아지고, 대시보드는 온통 빨갛고, Slack은 불타고, 실시간으로 발견되는 절반의 의존성들은 애초에 아키텍처 다이어그램에도 없던 것들이죠.

이제 상상해 보세요. 그런 장애를 이미 한 번 리허설해 봤다고요—연필과 종이, 그리고 약간의 연극만 가지고.

이게 바로 **연필로 그리는 장애 인형극(Pencil-Drawn Outage Puppet Theater)**의 아이디어입니다. 시스템, 서비스, 사용자를 종이로 만든 “캐릭터”로 표현해서, 장애와 실패 경로를 함께 몸으로 연기하며 탐색하는 저기술 협업 기법입니다. 장난스러워 보이지만 결코 농담이 아닙니다. 이 방식은 숨은 장애 모드를 드러내고, 각자의 머릿속에 있는 시스템 모델을 정교하게 만들며, 팀의 사고 대응 준비도를 눈에 띄게 끌어올립니다.

이 글에서는 이 방식이 어떻게 작동하는지, 왜 효과적인지, 어떻게 첫 세션을 운영할 수 있는지를 살펴봅니다.

연필로 그리는 장애 인형극이란 무엇인가?

간단히 말해, 테이블탑(테이블 위) 사고 리허설과 스토리보드가 만난 형태입니다.

시스템, 서비스, 사용자를 단순한 종이 캐릭터로 그립니다.
테이블이나 화이트보드 위에 올려두고, 스토리가 전개되는 대로 인형극처럼 옮겨 가며 사용합니다.
장애 시나리오를 장면(scene) 단위로 나눠, 장애가 어떻게 시작되고, 퍼지고, 결국 어떻게 수습되는지 연극처럼 풀어갑니다.

핵심은 그림 실력이 아닙니다. 막대기인형이어도 충분합니다. 중요한 것은 다음 세 가지입니다.

이야기의 구조 (분명한 시작, 중간, 끝)
눈에 보이는 상호작용 (누가 누구를 호출하고, 누구에게 의존하는지)
공유된 이해 (모두가 같은 “무대”를 보면서 이야기할 수 있는 것)

시스템을 머릿속 추상 구조가 아니라, 캐릭터와 행동이 있는 이야기로 바깥에 꺼내 놓으면, 복잡성이 읽을 수 있는 것이 됩니다. 그것도 시니어 엔지니어만이 아니라, 딜리버리와 운영에 관여하는 누구에게나요.

대시보드도 있는데 왜 종이 인형까지?

이 방식은 기존 도구들이 해결하지 못하는 문제를 다른 각도에서 다룹니다.

1. 저위험·저비용의 사고 시뮬레이터

실제 프로덕션이나 스테이징에서 장애 주입(chaos engineering)을 하는 건 강력하지만, 비용이 크고 정치적으로도 부담스럽습니다.

연필 인형극은 저위험·저비용으로 사고를 시뮬레이션하는 방법을 제공합니다.

종이, 펜, 포스트잇 정도 외에는 인프라가 필요 없습니다.
실제 시스템을 망가뜨릴 위험이 없습니다.
실제로 해보기 어려운 “만약에?” 시나리오도 부담 없이 시도할 수 있습니다.

예를 들어 이런 것들을 빠르게 탐색할 수 있습니다.

“이 리전이 통째로 죽으면 어떻게 되지?”
“이 서드파티 API가 에러 대신 이상한 쓰레기 데이터를 돌려주면?”
“알림(알럿)이 10분 늦게 온다면?”

시뮬레이션이 워낙 가볍기 때문에, 실제로 테스트하기엔 부담스럽거나 어려운 시나리오도 오후 몇 시간 안에 여러 개 돌려볼 수 있습니다.

2. 숨은 장애 경로와 엣지 케이스 발굴

리뷰나 자동화 테스트는 매우 중요하지만, 보통 이미 알고 있는 경로에 집중합니다.

문서화된 의존성
설계된 트래픽 흐름
예상 가능한 에러 조건

반면, 장애를 연기하기 시작하면 자연스럽게 사람들은 애드리브를 치기 시작합니다.

“잠깐—모바일 앱이 Service B로 직접 붙지 않나요?”
“이 큐가 밀리면, 청구도 같이 늦어지는 거 아닌가요?”
“무한 재시도하는 저 레거시 크론 잡, 이거 주인이 누구죠?”

이런 애드리브에서 바로 숨은 장애 경로가 튀어나옵니다.

스토리와 종이 인형이 결합되면 다음과 같은 것들을 눈으로 파악하기 쉬워집니다.

예상치 못한 전이(Transitive) 의존성
눈에 잘 안 보이는 공유 병목 (예: “이 모든 서비스가 같은 Feature Flag 서비스를 호출하네?”)
재시도, 타임아웃, 디그레이드 모드(degraded mode) 주변의 엣지 케이스

전통적인 아키텍처 다이어그램은 정적입니다. 반면 인형극은 동적입니다. 박스와 화살표가 어디 있는지만 보는 게 아니라, 시스템이 시간에 따라 어떻게 행동하는지를 보게 됩니다.

시스템을 캐릭터와 장면으로 바꾸기

이 방법의 핵심은 각 컴포넌트를 이야기 속 등장인물로 다루는 것입니다.

1단계: 캐스팅 – 등장인물 정하기

중요한 엔티티마다 간단한 종이 카드를 하나씩 만듭니다.

시스템 & 서비스: API Gateway, Search Service, Payment Processor, Feature Flags, Auth Service
데이터 저장소: User DB, Cache, Analytics Warehouse
외부 의존성: Email Provider, SMS Gateway, Third-Party API
사용자 & 역할: End User, On-call Engineer, SRE, Support, Manager

각 카드에 짧게 메모를 추가합니다.

역할: “user 세션 저장”, “checkout 처리” 등
SLO/SLA 요약: “p95 < 200ms”, “가용성 99.9% 목표” 등
알려진 특성: “rate limit 있음”, “cold start 느림”, “단일 리전” 등

이 카드들이 곧 여러분의 **인형(puppet)**이 됩니다.

2단계: 플롯(줄거리) 정하기

좋은 연극처럼, 장애에도 스토리 아크가 필요합니다.

도입(Setup) – 평상시 정상 동작. 사용자가 시스템과 어떻게 상호작용하는지.
사건 발생(Inciting Incident) – 무언가가 고장 나거나 성능이 떨어지기 시작.
격화(Escalation) – 영향 범위가 넓어지고, 새로운 증상이 나타나고, 사람들에게 알림이 갑니다.
절정(Climax) – 핵심 의사결정, 트레이드오프, 개입이 이뤄지는 순간.
해결(Resolution) – 시스템이 회복되고, 후속 조치가 정리됩니다.

이 구조를 화이트보드에 대충 적어두고, 세션 중에 팀이 세부 내용을 채워가게 하면 됩니다.

3단계: 직접 연기해 보기

이제 시나리오를 라이브 리허설로 돌려봅니다.

한 명은 내레이터(해설자) 역할을 맡습니다.
예: “14:03에 데이터베이스 레이턴시가 갑자기 치솟기 시작합니다….”
나머지는 종이 캐릭터를 집어 들고 움직이거나, 목소리를 내줍니다.
예: “Search Service: DB에서 결과를 못 가져오겠어. 사용자에게 타임아웃 에러를 내기 시작할게.”
퍼실리테이터는 이런 질문을 던집니다.
“누가 제일 먼저 눈치채나요?”
“어떤 알림이 뜨나요?”
“누가 온콜로 호출되나요?”
“처음에 뭘 해 보나요?”

목표는 완벽한 대응이 아니라 배움입니다. 누군가 “잠깐, 이건 잘 모르겠는데요”라고 말하는 지점이 바로 추후에 파고들어야 할 포인트입니다.

실제 사고를 위한 리허설 기법

연극인들은 실제 공연 때 얼어붙지 않고 반응할 수 있도록 수없이 리허설합니다. 장애 인형극은 동일한 목표를 향해 있습니다.

팀이 다음과 같은 것들을 연습하도록 도와줍니다.

압박 속에서의 협업 – 누가 리드하고, 누가 외부 커뮤니케이션을 맡고, 누가 로그를 파보는지.
의사결정 – 롤백을 할지, 페일오버를 할지, read-only 모드로 전환할지.
커뮤니케이션 패턴 – 대응자를 방해하지 않으면서 이해관계자에게 어떻게 상황을 공유할지.

이런 과정을 차분한 환경에서 반복하다 보면, 팀은 자연스럽게 **근육 기억(muscle memory)**을 쌓습니다.

주니어/신입 엔지니어는 “좋은” 사고 대응이 어떤 모습인지 몸으로 배웁니다.
시니어 엔지니어는 문서화되지 않았던 묵시적 지식을 밖으로 꺼내 공유하게 됩니다.
모두가 영향(impact), 리스크, 트레이드오프라는 공통 언어를 익힙니다.

실제 장애가 터졌을 때, 완전한 혼돈처럼 느껴지기보다는, 힘들지만 어디선가 연습해 봤던 장면처럼 느껴지게 됩니다.

SRE만의 놀이가 아니라, 전사(全社) 학습의 장

이 인형극 형식의 가장 큰 장점 중 하나는, 비엔지니어도 신뢰성 논의에 자연스럽게 들어올 수 있게 해 준다는 점입니다.

시스템 전체가 테이블 위에 펼쳐져 있기 때문에:

PM은 “여기가 죽으면 실제로 어떤 사용자 플로우가 깨지나요?”라고 물을 수 있습니다.
고객지원은 “이게 느려지면 고객들이 보통 이런 식으로 불만을 제기해요”라고 경험을 공유할 수 있습니다.
보안팀은 “이 부분의 fail-open 동작은 보안상 리스크가 큽니다”라고 짚어줄 수 있습니다.

이 시각적·서사적 방식은 직군마다 다른 전문 용어의 간극을 줄여 줍니다.

“DB p95 레이턴시가 threshold를 넘었다”라고 말하는 대신,
“User DB 캐릭터가 답을 늦게 주다 보니 Search Service가 사용자들을 오래 기다리게 만들고, 결국 사용자가 새로고침을 반복하기 시작한다”라고 말할 수 있습니다.

이렇게 만들어진 공유된 스토리는:

심리적 안전감을 높입니다.
“모든 걸 알 필요는 없고, 같이 탐색해도 된다”는 분위기를 만듭니다.
열린 커뮤니케이션을 유도합니다.
“이 부분은 항상 헷갈렸는데, 이번 기회에 같이 짚어볼 수 있을까요?” 같은 대화가 더 자연스러워집니다.
크로스펑셔널 트레이드오프 논의를 가능하게 합니다.
“이 안정성 개선을 우선순위로 올리면, 방금 본 세 가지 장애 시나리오를 줄일 수 있습니다”처럼요.

애매한 프로젝트를 구체적인 스토리보드로 바꾸기

많은 신뢰성 관련 프로젝트는 이런 모호한 슬로건에서 시작합니다.

“레질리언스를 좀 더 높여야겠어요.”
“MTTR을 줄여야 합니다.”
“결제 파이프라인을 더 튼튼하게 만들어야 해요.”

인형극 방식은 이런 흐릿한 목표를 구체적이고 시각적인 스토리보드로 바꿔줍니다.

현재 흐름을 그립니다. 누가 누구와 어떤 순서로 통신하는지.
장애 시나리오를 연기하면서, 구체적인 취약 지점을 찾습니다.
바뀐 흐름을 곧바로 종이에 그려 봅니다. 새 타임아웃, 재시도 전략, 폴백, 카나리 경로 등을 포함해서요.

각 반복(iteration)은 빠르게 끝납니다.

카드를 바꾸고,
화살표를 옮기고,
새로운 장면을 돌려봅니다.

추상적인 말싸움을 할 필요 없이, 테이블을 가리키며 이렇게 말할 수 있습니다.

“이 변경을 적용하면, Email Provider가 죽었을 때도 이메일을 큐에 쌓아두고 checkout은 계속 진행할 수 있습니다. 지금처럼 전체 주문을 실패시키지 않고요.”

이렇게 되면 “레질리언스 강화”는 더 이상 철학적인 이야기가 아니라, 모두가 보고 합의한 구체적인 시스템 행동의 시퀀스가 됩니다.

신뢰성 작업을 더 재미있고 기억에 남게 만들기

공연·인형극에서 가져온 역할, 장면, 대본 같은 요소는 단순히 귀엽기만 한 장식이 아닙니다. 학습 내용을 오래 기억하게 만드는 장치이기도 합니다.

사람들은 대체로 다음을 더 잘 기억합니다.

숫자보다 스토리
컴포넌트 이름보다 캐릭터
다이어그램보다 대화

세션이 끝난 뒤 팀 대화에서 이런 말이 나옵니다.

“그때 Feature Flags가 죽으면서 앱 절반이 같이 날아갔던 장면 기억나요?”
“그때 On-call Engineer가 read-only 백도어 엔드포인트가 있는지도 몰랐다는 걸 깨달았잖아요.”

이런 짧은 언급들이 팀의 **공유된 구전(folklore)**이 됩니다. 이후 논의가 훨씬 빠르고 현실감 있게 진행되죠.

또 인형극 형식은 신뢰성 작업에 대한 심리적 장벽을 낮춰줍니다.

신입도 첫날부터 참여할 수 있습니다. 시스템을 깊이 알 필요가 없습니다.
모두가 “놀고 있는” 느낌이기 때문에, 소위 ‘초보자 같은 질문’을 하는 것도 훨씬 편해집니다.
“2시간짜리 또 다른 사고 회고 미팅”보다는 “인형극 세션 한 번 해보자”가 훨씬 달콤하게 들립니다.

참여도가 높을수록, 조직이 집단적으로 쌓는 **정신적 모델(mental model)**은 더 풍부해집니다.

첫 번째 인형극 세션 운영 방법

크게 준비할 것 없습니다. 작게 시작하세요.

스코프 정하기
특정 사용자 여정이나 서브시스템 하나만 고릅니다.
예: “유저 로그인”, “checkout 플로우” 등.
4–8명 정도 모으기
엔지니어 1명 이상, 온콜/SRE 1명, 그리고 PM·지원 등 비엔지니어 1명 이상을 포함해 구성해 보세요.
기본 재료 준비
- 인덱스 카드나 포스트잇
- 펜/마커
- 테이블이나 화이트보드 같이 펼쳐놓을 수 있는 공간
캐릭터 그리기
핵심 서비스, 데이터 저장소, 사용자, 역할을 카드로 만듭니다.
장애 시나리오 하나 정리하기
예: “피크 시간 동안 DB 프라이머리 노드가 느려지고 간헐적으로 타임아웃이 발생한다.”
직접 연기하기
- 먼저 정상 동작을 walkthrough 합니다.
- 그다음 장애를 주입합니다.
- 누가 먼저 눈치채는지, 어떤 알림이 뜨는지, 누가 온콜되는지, 어떤 액션을 취하는지 내레이션하며 진행합니다.
인사이트 정리하기
별도 종이에 다음을 메모합니다.
- “모르는 부분”과 예상 밖의 발견
- 숨은 의존성
- 프로세스나 도구의 구멍
- 개선 아이디어
1–3개의 후속 작업 정하기
인사이트를 구체적인 태스크로 바꿉니다. 예를 들면:
- “Feature Flags 의존성 문서화”
- “큐 백로그에 대한 알림 추가”
- “read-only 모드 플레이북 정의” 등.

이 과정을 정기적으로 반복하세요. 시스템을 위한 **소방훈련(tabletop fire drill)**처럼 다루면 됩니다.

결론: 실제 장애 전에 먼저 리허설하라

현대 시스템은 정적인 다이어그램이나 코드만으로 완전히 이해하기에는 너무 복잡합니다. 우리는 실패를 안전하고, 저렴하고, 협업적인 방식으로 ‘가지고 놀’ 수 있는 도구가 필요합니다.

연필로 그리는 장애 인형극은 다음을 제공합니다.

사고와 장애를 위한 저위험·저비용 시뮬레이터
숨은 장애 경로와 엣지 케이스를 드러내는 방법
엔지니어·PM·기타 이해관계자를 한데 묶는 공유된 내러티브
실제 상황 전에 사고 대응을 연습하는 리허설 공간
모호한 신뢰성 목표를 구체적인 시각적 스토리보드로 바꾸는 도구
공연과 인형극에서 빌려온, 기억에 남고 몰입되는 형식

새로운 소프트웨어가 필요하지 않습니다. 종이, 연필, 그리고 시스템을 무대 위 캐릭터로 바라보려는 약간의 마음가짐이면 충분합니다.

작은 시나리오 하나로 시작해 보세요. 인형을 그리고, 이야기를 들려주세요. 프로덕션에서 실제로 뭔가가 터지기 전에, 팀이 얼마나 많은 것을 미리 배울 수 있는지 아마 놀라게 될 겁니다.