종이 시계 장애 키친 타이머: 끊임없는 온콜 연습을 위한 10분 아날로그 드릴 설계하기

장애는 편한 시간을 잘도 피해 갑니다. 금요일 저녁, 배포 윈도우 한가운데, 누군가의 첫 온콜 근무 중간에 벌어지곤 합니다. 그런데도 많은 팀은 드문드문 하는 게임데이, 혹은 실제 장애의 한복판에서 즉석으로 배우는 식으로만 “훈련”을 합니다.

여기에는 더 나은 방법이 있습니다: 끊임없고, 가벼운 연습입니다.

이 글에서는 종이 시계 장애 키친 타이머를 이용해 10분 아날로그 드릴을 돌리며 작은 장애 상황을 시뮬레이션하는 간단한 방법을 소개합니다. 이 방식으로 다음을 연습할 수 있습니다.

집중 연습을 구조화하기 위한 저기술(로우테크) 종이 “시계” 활용하기
촘촘한 타임박스 안에서 SRE 개념(SLI, SLO, 에러 버짓)을 실제처럼 적용하기
상상력이 아닌 리스크 기반으로 시나리오를 우선순위화하기
BC/DR(비즈니스 연속성/재해 복구) 플레이북에서 아이디어 가져오기
현실적인 시간 압박 속에서 관측 가능성(Observability) 역량 갈고닦기
플레이북을 계속 개선하는 작은 회고를 붙여서 돌리기
실제 장애가 “처음 겪는 사고”가 아니라 “리허설 같게” 만드는 문화 만들기

왜 종이 시계인가?

도구는 점점 정교해지는데, 훈련만큼은 일부러 저기술로 가는 게 이상하리만치 강력합니다. 가장 단순한 건, 가장자리에 분 단위가 표시된 종이 원과, 직접 손으로 옮기는 시계바늘 하나뿐입니다.

이 방식이 통하는 이유:

촉각이 주는 긴박감: 손으로 실제 바늘을 “지금부터 10분 후”로 옮기면, 카운트다운이 정말로 피부에 와닿습니다.
앱 오버헤드 없음: 컨텍스트 스위칭도, 알림도, UI 조작도 없습니다. 오로지 당신, 종이 시계, 그리고 문제뿐입니다.
공유된 아티팩트: 회의실에서든 원격 화면 공유에서든, 모두가 같은 타임박스를 한눈에 볼 수 있습니다.
심리적 경계: 종이 시계는 이게 “훈련”이라는 걸 계속 상기시켜 줍니다. 실패해도 되고, 멈춰도 되고, 되짚어 봐도 괜찮은 공간입니다.

준비물은 아주 단순합니다.

0–10분(여유를 두려면 0–15분)까지 표시된 원형 종이 한 장
종이 화살표와 핀/압정, 또는 그냥 마감 시간을 펜으로 그려 넣어도 됩니다

이게 바로 당신의 장애 키친 타이머입니다.

10분짜리 미니 장애 시나리오

각 드릴은 축약된 장애 시뮬레이션입니다. 작게 설계되어 있지만, 실제처럼 진지하게 다룹니다.

기본 포맷은 이렇습니다.

세팅 (1–2분)
- 시나리오 카드 한 장을 뽑습니다(뒤에서 설명).
- 한 명은 Incident Commander(IC, 사고 지휘자)를 맡습니다.
- 한 명은 Scribe(기록 담당)를 맡습니다.
- 나머지는 온콜 응답자 역할을 합니다.
종이 시계 설정 (10분)
바늘을 지금으로부터 10분 후에 맞춥니다. 바늘이 0에 도달하면, 장애 상황은 거기서 종료입니다.
장애 진행 (10분)
- 누군가가 “시스템” 역할을 맡거나, 로그/메트릭/증상을 주입합니다.
- 팀은 탐색하고, 소통하고, 완화를 시도합니다.
미니 회고 (5–10분)
- 무엇이 잘됐는지, 무엇이 헷갈렸는지, 문서/도구를 어떻게 바꿀지 나눕니다.

이게 전부입니다. 20–25분이면 하나의 학습 사이클이 완성됩니다.

짧은 타임박스는 집중을 강제합니다. 완벽을 도모할 시간은 없으니, 자연스럽게 우선순위, 커뮤니케이션, 리스크 트레이드오프 연습을 하게 됩니다.

각 드릴에 SRE 개념을 녹여 넣기

이 연습들이 막연한 “디버깅 퀴즈”로 흐르지 않게 하려면, 매 드릴을 핵심 SRE 개념에 단단히 묶어야 합니다.

1. SLIs를 핫시트에 올리기

각 시나리오는 반드시 **서비스 레벨 인디케이터(SLI)**를 짚으면서 시작하거나, 참가자에게 물어보면서 시작합니다.

“이 API에서 우리가 중요하게 보는 SLI는 뭐죠?”
“지금 어떤 SLI가 나빠지고 있나요? 레이턴시, 에러율, 가용성, 데이터 신선도 중에?”

참가자들에게 실제로 관련 대시보드를 열어 보게 하거나, 어떤 시그널을 볼지 설명하게 합니다. 드릴 도중 가끔씩 이렇게 찔러 주세요.

“이 장애 동안에 여러분의 북극성 SLI는 무엇인가요?”

2. SLO를 의사 결정의 경계로 쓰기

시나리오는 항상 **서비스 레벨 오브젝티브(SLO)**의 맥락 안에 놓습니다.

“우리는 30일 기준 99.9% 가용성을 목표로 합니다. 이 장애로 이번 달 에러 버짓의 20%를 이미 썼습니다. 이게 여러분의 의사 결정에 어떤 영향을 줄까요?”

팀이 다음을 고민하게 해 주세요.

빠른 완화와 회귀 위험 사이의 균형
더 깊은 디버깅 대신 무딘(but safe) 완화책(예: 일시적 기능 비활성화)을 언제 선택할지

3. 에러 버짓을 행동의 “허가서”로 쓰기

10분짜리 드릴에서도 에러 버짓 소진을 가상으로 시뮬레이션할 수 있습니다.

“이번 주에 이미 다른 이슈들로 에러 버짓의 절반을 썼습니다. 지금 위험한 핫픽스를 하는 게 괜찮을까요?”
“반대로, 에러 버짓은 아직 넉넉합니다. 잠깐 레이턴시 스파이크를 감수하더라도 빠른 롤백을 해도 괜찮을까요?”

핵심은, 묵시적인 감(直感)이 아니라, 명시적으로 버짓을 근거로 한 트레이드오프를 연습하는 겁니다.

올바른 시나리오 고르기: 리스크 기반 연습

많은 팀이 실제로는 거의 일어나지 않을 법한 극적인 시나리오(전체 리전 다운, 글로벌 DNS 붕괴 등)에 집착합니다. 그러다 실제로는 더 자주, 더 은근하게 발생하는 문제들을 놓치곤 합니다.

대신, 실제 리스크 신호를 바탕으로 시나리오 카드를 점수화하고 우선순위를 매기세요.

과거 장애: 장애 로그에서 반복되는 패턴
근접 손실(near miss): 한때는 “플래키”라고 치부했다가 나중에 심각해진 알림들
알고 있는 취약점: 단일 장애 지점(SPOF), 오래된 위험한 기능 플래그, 깨지기 쉬운 데이터 파이프라인
비즈니스 영향: 매출, SLA, 안전과 직접 연결된 시스템

간단한 리스크 점수 체계를 만듭니다.

발생 가능성(1–5) × 영향도(1–5) = 우선순위 점수

이 점수로 시나리오 카드를 정렬하고, 상위 카드들부터 뽑아 연습합니다.

예시 시나리오 카드:

“한 리전에서만 Checkout API의 5xx 에러율 상승”
“백그라운드 잡 백로그 증가, 아직 사용자 영향은 가시화되지 않음”
“특정 테넌트에서 기능 플래그 롤아웃 후 2% 에러 스파이크”
“프라이머리 DB 노드는 느리지만 죽지 않았고, 리드 레플리카는 정상”

가장 가능성이 높고, 영향이 클 실패를 먼저 연습하고, 가끔씩은 BC/DR 정렬을 위해 희귀하지만 치명적인 시나리오를 섞어 주세요.

BC/DR에서 가져오기: 자주, 다양하게 하는 테이블탑 드릴

비즈니스 연속성(BC)과 재해 복구(DR) 분야에서는 오래전부터 알고 있었습니다. 드물지만 거창한 연습보다, 자주 하는 현실적인 연습이 훨씬 낫다는 사실을요.

이 마인드를 엔지니어링에도 그대로 가져오세요.

테이블탑, 게임데이만 하지 말기: 분기별 “빅뱅” 게임데이 대신, 주간 10분 테이블탑을 돌립니다.
볼거리보다 다양성: 네트워크 이슈, 의존성 장애, 설정 오류, 용량 문제 등을 번갈아 가며 다룹니다.
역할 다양화: 어떤 날은 IC를 시니어가 맡고, 어떤 날은 주니어가 맡습니다. 어떤 날은 DB 전문가가 “부재중”인 설정으로, 나머지가 스스로 해결하게 합니다.

목표는, 장애 대응을 가끔 하는 공연이 아니라, 꾸준히 단련하는 근육으로 만드는 것입니다.

시간 압박 속에서의 Observability 훈련

온콜의 성패는 시스템 디테일을 얼마나 많이 외웠느냐보다, 시그널을 읽고 빠르게 좋은 가설을 세우는 능력에 더 좌우됩니다.

드릴을 활용해 다음 역량을 날카롭게 만드세요.

1. 시그널 트리아지

다음 질문에 빠르게 답하는 연습을 합니다.

“이 증상에서 항상 먼저 보는 대시보드는 무엇인가요?”
“처음에 tail 할 로그는 무엇인가요?”
“이게 클라이언트, 네트워크, 백엔드 중 어디 문제인지 가르는 데 어떤 트레이스가 도움이 되나요?”

기본 원칙은: 아무 대시보드나 무작위로 클릭하지 말 것. 팀에게 항상 내레이션하도록 요청하세요.

“이 엔드포인트에서 5xx가 늘고 있으니, 먼저 서비스 SLO 대시보드를 보고, 5xx로 필터링된 요청 트레이스를 살핀 다음, 배포 시간과 상관관계를 확인하겠습니다.”

2. 가설 → 테스트 → 학습 루프

10분 안에 여러 번의 짧은 루프를 돌리는 게 목표입니다.

가설 세우기 (“X 리전에서 pod 재시작이 발생하는 건 Y 설정 변경 때문일 것 같다.”)
테스트하기 (이벤트 로그, 롤아웃 히스토리, pod 상태 등을 확인)
결과에 따라 믿음을 빠르게 업데이트하기

진행자는 가끔 시간을 멈추고 이렇게 물어보세요.

“지금 여러분의 현재 가설은 무엇인가요?”
“어떤 증거가 나오면 이 가설이 틀렸다고 볼 수 있을까요?”

시간이 지날수록 엔지니어들이 사고를 더 빠르고, 더 체계적으로 정리하는 모습을 보게 됩니다.

5–10분 회고: 드릴을 실제 개선으로 연결하기

되짚어 보지 않으면, 드릴은 그냥 연극이 됩니다. 진짜 마법은 미니 회고에서 일어납니다.

각 드릴 직후, 아직 맥락이 생생할 때:

1. 세 가지 질문

무엇이 잘 되었나요?
- 특히 도움이 되었던 도구, 대시보드, 커뮤니케이션 패턴
무엇이 헷갈리거나 느렸나요?
- 빠졌던 알림, 모호한 오너십, 알아보기 어려운 대시보드 이름
이번 주 안에 무엇을 바꿀 건가요?
- “~하면 좋겠다”가 아닌, 구체적인 액션

2. 아티팩트를 바로 업데이트하기

회고 시간 안에 실제로 손을 대세요.

런북 / 플레이북
- 빠진 단계를 추가합니다(“로그를 보기 전에 먼저 기능 플래그 X를 확인한다.” 등).
- 지나치게 복잡한 흐름은 단순화합니다.
Incident Response Plan(사고 대응 계획)
- 누가 IC, Scribe, 커뮤니케이션 담당인지 더 명확히 씁니다.
- 에스컬레이션 경로와 페이징 규칙을 정리해 둡니다.
대시보드 / 알림
- 이번에 있었다면 도움이 되었을 알림을 만들거나 수정합니다.
- 메인 서비스 대시보드에 빠른 “트리아지” 패널을 추가합니다.

룰은 단 하나입니다. 드릴마다 최소 한 개의 작고 구체적인 개선을 남길 것. 분기 단위로 보면, 이 작은 변경들이 쌓여서 장애 대응 태세를 눈에 띄게 끌어올립니다.

끊임없고 가벼운 연습의 문화를 만들기

이 접근법이 효과를 내려면, 일회성 이벤트가 아니라 습관이 되어야 합니다.

1. 루틴으로 만들기

주기: 팀당 주 1회부터 시작하세요. 중요 기간에는 주 2–3회까지 늘릴 수 있습니다.
타임박스: 캘린더에 25–30분을 보호하세요. 절대 오버런하지 않습니다.
로테이션: 역할(IC, Scribe, 옵저버)과 참가자를 돌려 가며, 신입도 꼭 포함합니다.

2. “안전한 실패”를 당연하게 만들기

드릴은 심리적으로 안전한 공간이어야 합니다.

단서를 놓쳐도, 최적이 아닌 완화책을 골라도 괜찮습니다.
여기서 빈틈을 드러내야, 진짜 장애에서 다치지 않습니다.

다음과 같은 순간을 오히려 축하해 주세요.

“이런 런북이 하나 빠져 있었네”를 발견한 것
“이 알람은 지금 팀이 아니라 다른 팀을 깨우네”를 알아낸 것
“저 대시보드가 어디 있는지 모르겠어요”라고 솔직히 말한 것

3. 장애만이 아니라, 연습 자체도 측정하기

다음을 추적해 보세요.

팀별 월간 실시한 드릴 횟수
드릴을 통해 새로 만들거나 업데이트한 런북 개수
새로 만들거나 개선한 알림·대시보드 개수

이 지표들을 엔지니어링 리뷰에서 공유합니다. 연습을 신뢰성의 핵심 축으로 다루고, 부수적인 활동으로 취급하지 마세요.

모두 한데 모으기

종이 시계 장애 키친 타이머는 일부러 아주 단순하게 설계된 도구입니다. 바로 그게 장점입니다. 연습의 진입 장벽을 극도로 낮춰, “안 할 이유”를 없애 줍니다.

10분짜리 미니 장애를 반복하면서:

SLI, SLO, 에러 버짓 같은 SRE 기본기를 자연스럽게 녹여 넣고
상상 속 재난이 아닌, 실제 리스크 기반으로 시나리오를 우선순위화하며
BC/DR 연습에서 차용한 높은 빈도와 다양한 패턴을 유지하고
Observability와 빠른 가설 검증에 초점을 맞추고
짧지만 구체적인 회고로 런북과 계획을 계속 업데이트하면

…결국 실제 장애가 즉흥극이 아니라, 연습해 본 시나리오처럼 느껴지기 시작합니다.

지금 바로 시계를 출력하고, 화살표를 꽂고, 첫 번째 10분 드릴을 캘린더에 올리세요. 몇 주만 지나도 온콜 로테이션은 훨씬 차분해지고, 다음 장애를 맞을 준비가 훨씬 더 잘 되어 있을 것입니다.