Rain Lag

종이 회로 온콜 극장: 인덱스 카드, 바닥 테이프, 그리고 ‘화면 0개’로 프로덕션 장애 리허설하기

인덱스 카드, 바닥 테이프, 출력물 같은 저기술·종이 기반 시뮬레이션으로 프로덕션 장애 대응을 리허설하고, 온콜 리스크를 줄이며, 더 탄탄한 인시던트 대비 문화를 만드는 방법—노트북 없이도 가능하다.

종이 회로 온콜 극장: 인덱스 카드, 바닥 테이프, 그리고 ‘화면 0개’로 프로덕션 장애 리허설하기

대부분의 팀은 모니터 앞에서 인시던트 대응을 연습합니다. 대시보드, 런북, 티켓 큐, 끝없이 올라가는 슬랙 스크롤을 보면서 말이죠. 그런데 모든 화면을 꺼 버려도—프로덕션 장애를 효과적으로 연습할 수 있다면 어떨까요?

여기에 종이 회로 온콜 극장(Paper-Circuit On-Call Theater) 이 있습니다. 인덱스 카드, 바닥 테이프, 출력한 다이어그램, 그리고 약간의 상상력만으로 장애를 시뮬레이션하는, 화면 없이 완전히 물리적인 연습 방식입니다.

이건 단순한 레트로 감성 놀이가 아닙니다. 물리적이고 저충실도의 시뮬레이션도 고기술 도구만큼이나 효과적으로 인시던트 대응을 가르칠 수 있고, 어떤 면에서는 더 낫습니다. 인시던트를 셸 명령 모음이 아니라 ‘연극’으로 다루면, 시스템에 불이 났을 때 진짜로 중요한 것들—역할, 인수인계, 커뮤니케이션—에 초점을 맞추게 됩니다.


왜 클릭으로 연습하지 말고 ‘연기’로 연습할까?

실제 장애 상황에서는 사용하는 도구가 중요합니다. 하지만 그게 제일 어려운 부분은 아닙니다. 진짜 어려운 건 도구 주변에 있는 모든 것입니다.

  • 누가 인시던트를 선언하나요?
  • 누가 이해관계자에게 상황을 알리나요?
  • 누가 롤백할지 롤포워드할지 결정하나요?
  • 인시던트 도중에 교대가 생기면 인수인계는 어떻게 되나요?
  • 왜 다섯 명이 같은 걸 조용히 디버깅하고 있는 상황을 피하지 못했나요?

물리적 시뮬레이션은 대시보드와 터미널을 걷어내고, 사람과 프로세스에만 집중하게 해 줍니다.

이 방식이 효과적인 이유

1. 키보드 입력보다 ‘역할’을 강조한다
연극처럼 리허설하면, 사람들은 역할을 ‘연기’하게 됩니다. 인시던트 커맨더(Incident Commander), 커뮤니케이션 리드, Ops/SRE, 프로덕트 대표, 옵저버 등. 초점이 “어떤 명령을 치지?”에서 “어떤 결정을 내리고, 누구에게 말해야 하지?”로 바뀝니다.

2. 애초에 ‘저위험·저충실도’라 부담이 적다
인덱스 카드 한 장이 데이터베이스를 나타낼 수 있습니다. 바닥 테이프 한 줄이 서비스 경계를 나타낼 수 있습니다. 아무것도 실제가 아니기 때문에 마음껏 실패해도 안전합니다. 일부러 안 좋은 선택을 해 보고, 이상한 엣지 케이스를 탐색하고, “이렇게 다르게 해 보면 어떨까?”를 중간에 멈춰 서서 논의할 수 있습니다. 프로덕션에 대한 리스크는 0입니다.

3. 숨겨진 실패 모드를 드러낸다
실제 인시던트 중에는 너무 바빠서 작은 마찰 지점을 인지하지 못합니다. 종이 시뮬레이션에서는 그걸 볼 시간이 생깁니다. 빠진 런북, 모호한 에스컬레이션 경로, 불분명한 오너십, 모니터링 블라인드 스팟, 결정을 못 내리는 상황 등.

4. 기억에 잘 남고, 재미있다
SRE 연습에 게임 또는 연극 요소를 섞으면, 원래 지루할 수 있는 트레이닝이 사람들이 실제로 기억하는 경험이 됩니다. 연습이 재미있고 몰입될수록, 팀은 그때 배운 내용을 일요일 새벽 3시에 더 잘 꺼내 쓸 수 있습니다.

5. 싸고, 누구나 할 수 있다
라이선스도, 특수 도구도, 복잡한 환경도 필요 없습니다. 필요한 건:

  • 인덱스 카드나 포스트잇
  • 바닥 테이프(또는 화이트보드 테이프)
  • 시스템 아키텍처 다이어그램 출력물
  • 마커와 펜
  • 공간(회의실이나 심지어 복도도 가능)

세 명짜리 스타트업부터 큰 SRE 조직까지, 어떤 팀이든 할 수 있습니다.


무대 만들기: 종이 회로 극장 세팅하기

시뮬레이션을 하나의 연극으로 생각해 보세요. 해야 할 일은:

  1. 무대(시스템과 환경)를 디자인한다
  2. 출연진(인시던트 팀)을 캐스팅한다
  3. 시나리오의 주요 전환점(비트, beats)을 쓴다
  4. 공연(연습)을 진행한다
  5. 공연 후 회고(디브리핑)를 한다

1. 무대 디자인: 시스템을 물리적으로 만든다

회의실(또는 아무 넓은 공간이든)을 “프로덕션 환경”으로 사용합니다.

  • 바닥 테이프: 서로 다른 서브시스템이나 서비스를 구역으로 나눠 표시합니다. frontend, payments, auth, databases, message queue 등.
  • 인덱스 카드: 각 카드는 하나의 리소스나 이벤트를 뜻합니다.
    • 서비스: User Service, Order Service, Auth Service
    • 인프라: Postgres Cluster, Redis Cache, Kafka Topic
    • 이벤트: 500 에러 급증, CPU 95%, DB connection timeout, PagerDuty alert
  • 출력한 다이어그램: 단순화한 아키텍처 다이어그램을 벽에 붙입니다. 이게 참가자들이 공간을 이해하고 위치를 파악하는 기준점이 됩니다.

목표는 100% 정확한 모델링이 아닙니다. 참가자들이 실제로 걸어 다니며 경험할 수 있는 공유된 멘탈 모델을 만드는 게 목적입니다.

2. 역할 캐스팅

사람이 겹치더라도 역할은 명확히 지정합니다.

  • 인시던트 커맨더(Incident Commander, IC) – 최종 결정과 흐름을 책임집니다. 꼭 가장 시니어 엔지니어일 필요는 없습니다.
  • Operations / SRE – 원인 조사, 완화 방안 제안, (시뮬레이션 상에서) 기술적 액션 수행을 담당합니다.
  • 커뮤니케이션 리드(Communications Lead) – 이해관계자, 고객, 경영진 등에게 보내는 모든 업데이트를 전담합니다.
  • 서비스 오너(Service Owners) – 데이터베이스, 네트워크, 결제 등 특정 도메인을 대표합니다.
  • 옵저버 / 퍼실리테이터(Observer / Facilitator) – 시뮬레이션을 진행하고, 새 이벤트를 투입하고, 시간과 메모를 관리합니다.

각 사람에게 역할 설명이 적힌 카드를 주어, 연습 내내 그 역할에 ‘몰입’하도록 합니다.

3. 시나리오 비트 작성

완전한 대본이 필요하지는 않습니다. 필요한 건 인시던트의 핵심 전환점(beat) 입니다.

예시: “결제 지연 급증(Checkout Latency Spikes)” 시나리오

  • 비트 1: checkout-latency 모니터링 알람 발생(알림 카드가 IC에게 전달됨).
  • 비트 2: 고객 지원팀에서 결제 화면에서 막혀 있다는 고객 문의를 전달.
  • 비트 3: Auth 서비스 에러율 상승.
  • 비트 4: 데이터베이스 커넥션이 한계에 도달.
  • 비트 5: 직전에 체크아웃 서비스에 배포가 있었음.
  • 비트 6: 롤백 후에도, 다운스트림 의존성에서 오는 에러가 계속됨.

각 비트마다 퍼실리테이터는 증상이나 데이터(로그 일부, 메트릭 요약, 고객 영향 설명 등)가 적힌 카드를 준비해 둡니다. 이 카드를 시간 간격을 두고, 또는 팀의 행동에 반응해 투입합니다.


공연 시작: 화면 없는 인시던트 리허설 진행하기

60–90분 세션을 위한 간단한 구조 예시는 다음과 같습니다.

Step 1: 브리핑 (10–15분)

  • 규칙 설명: 노트북/모바일 금지, 실제 도구 사용 금지. 모든 것은 방과 카드로 표현됩니다.
  • 목표 명확화: 커뮤니케이션, 역할, 의사결정 연습이 목적이지, 명령어 암기가 목적이 아님을 강조합니다.
  • 시스템 개요 설명: 바닥 테이프 구역과 아키텍처 다이어그램을 함께 걸어 다니며 설명합니다.

Step 2: 인시던트 시작 (20–30분)

퍼실리테이터가 시작을 알립니다.

  1. 트리거: IC에게 “Alert(알림)” 카드 전달. IC는 인시던트를 선언하고, 역할이 사전에 정해지지 않았다면 그 자리에서 할당합니다.
  2. 커뮤니케이션 연습: 커뮤니케이션 리드는 주기적으로 ‘가상의 이해관계자’(다른 참가자나 퍼실리테이터)에게 “상태 업데이트”를 제공합니다.
    • 우리가 알고 있는 것
    • 우리가 지금 하고 있는 것
    • 추정되는 영향
  3. 조사 진행:
    • 팀원들은 바닥 테이프 구역 사이를 실제로 이동하며, 시스템의 각 부분을 “본다”고 표현합니다.
    • 퍼실리테이터는 조사하는 위치나 행동에 맞춰, 새로운 단서나 추가 문제를 담은 카드를 건넵니다.

팀은 자신의 행동을 소리 내어 말합니다. 예를 들어: “데이터베이스 커넥션이 포화 상태인지 확인하고 싶어요”, “마지막 배포를 롤백하겠습니다.” 등. 퍼실리테이터는 미리 준비한 결과를 알려주거나, 상황에 맞춰 즉흥적으로 반응을 만듭니다.

Step 3: 에스컬레이션, 인수인계, 트레이드오프 (15–20분)

더 현실적인 도전을 추가합니다.

  • 핵심 전문가 한 명이 10분 동안 “부재 중”이 됩니다.
  • IC의 근무 시간이 끝나, 새로운 IC에게 인수인계를 해야 합니다.
  • 이해관계자가 ETA를 요구하거나, 위험한 ‘지름길’ 해결책을 제안합니다.
  • 팀은 지금 당장 쓸 수 있는 부분 완화책과, 시간은 더 걸리지만 근본적인 해결책 사이에서 선택해야 합니다.

이런 순간들은 프로세스의 빈틈을 드러냅니다.

  • IC 교대를 매끄럽게 하는 방법을 모두 알고 있나요?
  • 위험한 변경을 중단시킬 권한은 누가 갖고 있나요?
  • SLO, 에러 버짓, 허용 가능한 리스크는 명확한가요?

Step 4: 해결 및 마무리 (5–10분)

팀이 효과적인 완화 또는 해결 방안을 찾으면, 퍼실리테이터가 인시던트 종료를 선언합니다.

커뮤니케이션 리드는 실제 인시던트 리포트 형식과 비슷하게 최종 요약을 합니다. 영향, 타임라인, 완화 조치, 다음 단계 등을 포함해서요.


막이 내린 뒤: 디브리핑과 학습

진짜 가치는 디브리핑(회고) 에서 나옵니다.

이런 질문을 사용해 보세요.

  • 커뮤니케이션은 어디에서 잘 작동했고, 어디에서 실패했나요?
  • 역할은 명확했나요? 누가 막히거나 과부하를 느끼지는 않았나요?
  • 어떤 정보가 있었으면 좋겠다고 느꼈나요? 그건 모니터링의 문제인가요, 문서화의 문제인가요?
  • 어떤 결정이 특히 어려웠나요? 무엇이 있었으면 더 쉬웠을까요?
  • 이게 실제 인시던트였다면, 런북이나 에스컬레이션 경로를 어떻게 바꾸고 싶나요?

그리고 이 인사이트를 구체적인 개선 작업으로 옮깁니다.

  • 런북과 인시던트 플레이북을 업데이트합니다.
  • 핵심 서비스의 오너십을 명확히 합니다.
  • 빠져 있는 알람이나 대시보드를 추가합니다.
  • 실제 온콜 로테이션에서의 역할과 책임을 정의·정교화합니다.

이런 테이블탑 스타일의 종이 시뮬레이션을 꾸준히 진행하면, 다음 세 가지 사이에 강력한 피드백 루프가 생깁니다.

  • 시스템 설계 (탄력성, Observability)
  • 팀 프로세스 (온콜, 인시던트 대응)
  • 문화 (심리적 안전, 실패로부터의 학습)

왜 이 저기술 방식이 실제 온콜 스트레스를 줄여주는가

사람들이 압박 없는 환경에서 여러 시나리오를 충분히 리허설해 봤다면, 온콜은 더 이상 ‘뭔지 모르는 공포의 상자’처럼 느껴지지 않습니다.

종이 회로 리허설은 다음을 도와줍니다.

  • 인시던트를 시작하고, 진행하고, 마무리하는 ‘근육 기억’ 을 만들어 줍니다.
  • 도움 요청과 역할 위임을 자연스러운 행동으로 만듭니다.
  • 실제 비상 상황에서도 사람들이 더 잘 말문을 열게 합니다. 이미 비슷한 ‘공연’을 해 본 적이 있기 때문입니다.
  • 기술적 실패 모드(단일 장애 지점, 취약한 의존성)와 워크플로 실패 모드(혼란스러운 에스컬레이션 경로, 모호한 의사결정 권한)를 모두 드러냅니다.

다음에 페이저가 울릴 때, 팀이 덜 패닉에 빠질 가능성이 높습니다. 이 ‘공연’을 예전에 한 번쯤은 해 봤으니까요.


시작하기: 간단한 첫 연습 예시

처음부터 할리우드급 프로덕션을 만들 필요는 없습니다. 작게 시작하세요.

  1. 흔하게 발생하는 인시던트 유형 하나를 고릅니다. (예: 메인 API의 에러율 상승)
  2. 화이트보드에 매우 대략적인 아키텍처를 그립니다.
  3. 인덱스 카드를 사용해 다음을 표현합니다.
    • 알람(모니터링, 고객 지원, 고객 제보 등에서 오는 것)
    • 증상(메트릭, 로그, 트레이스 내용을 자연어로 요약)
    • 의존성(데이터베이스, 외부 API, 캐시 등)
  4. 45분짜리 세션을 구성합니다.
    • IC 1명
    • 커뮤니케이션 리드 1명
    • 응답자 2–4명
    • 퍼실리테이터/옵저버 1명
  5. 20분 동안 디브리핑을 하고, 꼭 실행할 1–2개의 개선 사항 을 정합니다.

이걸 매달 반복합니다. 시나리오는 조금씩 바꾸고, 역할도 돌려 가며 맡깁니다. 시간이 지나면 인시던트 리허설이 자연스럽고 당연한 문화가 되고—심지어 꽤 즐거운 시간이 되기도 합니다.


결론: 신뢰성을 위한 도구로서의 ‘연극’

신뢰성은 더 좋은 대시보드나 더 강력한 자동화만으로 만들어지지 않습니다. 스트레스 상황에서 사람들이 어떻게 함께 움직이는가 가 핵심입니다.

종이 회로 온콜 극장은 다음을 가능하게 하는, 저비용·반복 가능·그리고 놀랍도록 재미있는 방법입니다.

  • 프로덕션에 리스크를 주지 않고 인시던트를 연습하기
  • 도구의 세부 기능보다 커뮤니케이션, 명확성, 의사결정을 우선순위에 두기
  • 모니터링, 에스컬레이션, 오너십의 숨은 빈틈을 발견하기
  • 온콜을 덜 신비롭고, 더 인간적인 경험으로 만들기

필요한 것은 바닥 테이프, 인덱스 카드 몇 장, 그리고 인시던트 대응도 공연처럼 미리 리허설할 수 있는 것 이라는 마음가짐뿐입니다. 진짜 막이 오르기 한참 전에 말이죠.

종이 회로 온콜 극장: 인덱스 카드, 바닥 테이프, 그리고 ‘화면 0개’로 프로덕션 장애 리허설하기 | Rain Lag