아날로그 인시던트 철도 식당차: 장애 때 ‘손대지 않을 것’을 고르는 종이 메뉴

프로덕션이 불타고 있을 때, 우리의 뇌는 최상의 상태가 아니다.

인지 부하는 치솟고, 스트레스는 올라가고, 임원들은 상태를 물어보며 메시지를 보내고, 열 명이 넘는 사람들이 각자 “빨리 끝낼 수 있는” 해결책을 쏟아낸다. 바로 이때 팀은 가장 위험한 변경을 집어 들기 쉽다. 코어 데이터베이스 재시작, 정체 불명의 피처 플래그 토글, 스택 절반 재배포, 혹은 그냥 “전부 롤백하자”는 식의 결정들이다.

이렇게 작은 장애가 대형 장애로 번진다.

이 글에서는 의도적으로 로우테크인 대응책을 소개한다. 아날로그 인시던트 철도 식당차(Incident Railway Dining Car) — 인시던트 발생 후 처음 15분 동안 팀이 함께 “어디에는 절대 손을 대지 않을지”를 고르는 단순하고 촉각적인 종이 메뉴다.

이 메뉴를 SRE 베스트 프랙티스를 바탕으로 한 가벼운 인시던트 플레이북과 함께 사용하면, 더 침착한 의사결정, 덜한 패닉성 변경, 더 탄탄한 인시던트 대응 문화를 만들 수 있다.

왜 “인시던트 식당차”인가?

옛날 철도 식당칸을 떠올려 보자.

자리에 앉으면 메뉴판을 받는다. 메뉴에는 세상 모든 음식이 적혀 있지 않다. 이미 선별된, 미리 정해진 옵션들만 있다. 당신은 압박 속에서 새로운 요리를 발명하는 것이 아니라, 이미 정리된 범위 안에서 안전하게 고르는 것이다.

이 메타포를 인시던트 대응에 그대로 가져와 보자.

철도(Railway) 는 달리고 있는 당신의 프로덕션 환경이다.
식당차(Dining Car) 는 인시던트 커맨드 스페이스다. Zoom, Slack, 워룸(war room) 같은 공간.
메뉴(Menu) 는 “하고 싶지만 위험한” 흔한 액션들을 적어둔 실제 종이 한 장이다.

인시던트가 시작되면, 이것저것을 섣불리 고치려고 달려들기보다, 팀이 메뉴를 펼쳐 놓고 처음 15분 동안은 어디에 손대지 않을지 명시적으로 합의한다.

이 작은 의식(ritual)이 가져오는 효과는 생각보다 크다.

속도를 살짝 늦춰 패닉을 막는다.
옵션 공간을 미리 검토된 안전한 선택지로 제한한다.
지금 당장은 절대 하지 않을 일에 대해 모두의 기대치를 맞춰 준다.

종이 메뉴: 무엇에 손대지 않을지 고르기

종이 메뉴는 말 그대로 종이다.

디지털 세상에 굳이 아날로그를 쓰는 이유는?

손에 잡히고 무시하기 어렵다.
툴이나 대시보드가 느리거나 죽었을 때도 쓸 수 있다.
심리적인 프레임을 바꿔 준다. 지금은 해킹하는 시간이 아니라, 메뉴에서 주문하는 시간이라는 신호다.

메뉴는 이런 모습이다

1~2페이지짜리 단일 시트로, 온콜 데스크마다 출력해 두고, 다음과 같은 섹션을 둔다.

섹션 A – 고위험 액션 (기본값: 첫 15분 동안 DO NOT TOUCH)

기본(primary) 데이터베이스 클러스터 재시작
세컨더리 리전으로 페일오버
메인 모놀리식 서비스 전체 롤백
전체 트래픽의 50% 초과에 영향을 주는 글로벌 피처 플래그 변경
DNS 레코드나 엣지 레벨 트래픽 라우팅 변경
전체 캐시 퍼지 / 대량 캐시 무효화

섹션 B – 중간 위험 액션 (명시적 승인 필요)

코어 서비스 재배포(redeploy)
스키마 마이그레이션 / 롤백
대량 데이터 수정 스크립트 실행

섹션 C – 안전한 디폴트 (초기 단계에서 권장되는 액션)

추가 로깅 / 트레이싱 활성화
임시 알림 / 대시보드 추가
부하 감소(레이트 리밋, 큐 일시 중지, 부분적 기능 축소·저하)
사전에 검증된 “세이프 모드(safe mode)” 플래그 토글

인시던트가 시작되면, 인시던트 커맨더(IC)가 섹션 A를 소리 내어 읽고 이렇게 말한다.

“앞으로 15분 동안은, 만장일치로 ‘유리 깨기(break glass)’를 결정하지 않는 한, 이 고위험 액션들은 하지 않습니다. 동의하나요?”

그리고 팀이, 지금 당장은 금지할 액션들에 체크를 한다.

이 작은 단계 하나가 대화를 “뭘 해볼까?”에서 **“지금은 하지 않기로 의도적으로 결정한 것은 무엇인가?”**로 재구성한다.

메뉴와 인시던트 플레이북의 페어링

메뉴는 그 자체로 끝나는 ‘재미 요소’가 아니다. 명확하고 가벼운 인시던트 플레이북과 페어링될 때 가장 잘 작동한다. 이 플레이북은 처음 15분, 그리고 그 이후를 안내하는 역할을 한다.

플레이북에는 최소한 다음 내용이 포함되어야 한다.

1. 첫 15분 체크리스트

처음 15분의 목적은 영웅 플레이가 아니라, 안정화와 가시성 확보다.

예시 체크리스트:

역할 할당 (IC, 커뮤니케이션 담당, 서기(Scribe), SME(도메인 전문가)들)
영향도를 쉬운 말로 설명: “사용자가 X를 못 하고 있다 / 에러율은 Y / Z 시점부터 시작된 것으로 보임”
종이 메뉴를 펼쳐 지금은 손대지 않을 것들을 결정한다.
가설이 아닌 사실을 수집: 대시보드, 로그, 최근 변경, 알림 이벤트.
옵저버빌리티(관측 가능성)를 개선: 로그 추가, 프로브 범위 좁히기, 트레이싱 활성화.
봉쇄(containment) 전략 검토: 레이트 리밋, 부분적인 기능 비활성화, 비핵심 트래픽 드랍.
첫 상태 업데이트 공지 발송: 미리 준비한 커뮤니케이션 템플릿 사용.

2. 복구 의사결정 매트릭스

즉흥적인 위험한 수정 작업을 피하려면, 공통적인 복구 전략들에 대해 사전에 합의된 기준을 정의해야 한다.

예를 들어:

언제 서비스를 재시작할 것인가
- 조건: 서비스가 응답하지 않고(non-responsive) 무상태(stateless) 이며, 진행 중인 쓰기 작업이 없을 때.
언제 리전 페일오버를 할 것인가
- 조건: 영향이 특정 리전에 국한되고, 자동화된 헬스 체크가 대상 리전을 정상으로 표시하며, 커뮤니케이션·롤백 계획이 준비되어 있을 때.
언제 롤백할 것인가
- 조건: 인시던트가 특정 배포와 강하게 상관관계를 보이고, 이전 버전이 ‘정상 동작 verified’ 상태일 때.

종이 메뉴에는 이 매트릭스를 참고하라는 문구를 넣을 수 있다. “섹션 A나 B의 어떤 액션을 수행하기 전에, 복구 의사결정 매트릭스를 확인할 것.”

3. 커뮤니케이션 템플릿

아무도 상황을 모를 때, 인시던트는 더 심각하게 느껴진다. 다음과 같은 템플릿을 준비해 둔다.

내부 공지용 업데이트
임원 브리핑용 요약
고객 상태 페이지용 공지

각 템플릿에는 불확실성에 대한 솔직함이 담겨야 한다. 예: “현재 원인을 조사 중이며, X는 안정화했습니다. Y와 같은 위험한 변경은 피하고 있습니다. Z분 후에 다음 업데이트를 드리겠습니다.”

4. 안전한 복원(Safe Restore) 단계

상대적으로 안전한 복원 경로를 단계별로 문서화한다.

검증된 롤백 시퀀스
데이터베이스 페일오버 절차 및 가드레일
트래픽 시프팅(traffic shifting) 단계와 명확한 중단(abort) 기준

이 단계들을 다시 메뉴와 연결한다. 충분한 정보를 모은 첫 15분 이후에 어떤 것들을 점진적으로 시도할 수 있는지에 대한 가이드가 된다.

식당차 뒤에 있는 SRE 베스트 프랙티스

이 접근법은 귀여운 메타포 위에, 꽤 진지한 SRE 원칙들을 덮어 놓은 것이다.

명확한 역할

인시던트 중에는 반드시 인시던트 커맨더 가 한 명 있어야 한다. 그 외에도 다음과 같은 역할이 있다.

Operations Lead / Tech Lead
Communications Lead(커뮤니케이션 담당)
Scribe(기록 담당)

IC는 메뉴와 플레이북을 손에 쥐고, 팀이 사전에 합의한 레일 위에서 움직이도록 조율한다.

사전 정의된 런북

플레이북과 서비스별 런북은 곧 메뉴의 상세 설명이다. “X를 해볼까?”라는 막연한 생각을 “X를 안전하게 하는 구체적인 방법”으로 바꿔 준다. 기록되지 않은 즉흥적인 액션이 장애를 더 키우는 지점이다.

직감이 아닌 기준에 의한 의사결정

압박 상황에서 사람들은 직감이나, 가장 큰 목소리를 가진 사람의 의견에 따른다. 메뉴와 의사결정 매트릭스는 의견이 아닌 기준을 코드처럼 적어 두는 방식이다. 이렇게 해야 새벽 2시에 튀어나오는 “그냥 다 리부트하자” 충동을 막을 수 있다.

먼저 안정화, 그다음에 수정

핵심 마인드셋 전환은 이것이다. 수정보다 안정화가 우선이다.

식당차에서 우리는 테이블에 앉아 기차 엔진을 뜯어고치지 않는다. 다음 역까지 버틸 수 있게 우리를 ‘유지’해 줄 무언가를 주문할 뿐이다.

인시던트에서도, 안정화란 다음을 의미한다.

블라스트 레디어스(영향 범위) 축소: 레이트 리밋, 기능 비활성화, 그레이스풀 디그레이션(graceful degradation)
무슨 일이 벌어지고 있는지 보이게 만드는 것: 메트릭, 로그, 트레이스
가용성보다 데이터 무결성을 우선해야 한다면, 그 선택을 하는 것

시스템이 더 나빠지지 않는 상태를 만들고 난 뒤에야 다음을 시도해야 한다.

침습적인(invasive) 복구 액션
스키마, 설정, 장기 인프라 변경

종이 메뉴는 이러한 침습적인 조치를 기본값으로 막아 두고, 의식적인 Opt-in이 필요하게 만듦으로써 이 원칙을 강화한다.

교육 도구이자 리더십 연습 플랫폼

인시던트 식당차는 교육용 장치이자 리더십 연습의 장이기도 하다.

드릴에 활용하기

게임데이(Game Day)나 카오스 엔지니어링 연습에서 다음과 같이 활용한다.

IC는 2분 안에 반드시 메뉴를 펼쳐야 한다.
팀은 지금 손대지 않기로 한 항목들에 대해 왜 그런 선택을 했는지 설명해야 한다.
임원 압박을 시뮬레이션한다. “그냥 페일오버하면 안 돼?”라는 요청에 IC가 “첫 15분 메뉴에 없는 이유는 이렇습니다”라고 답하는 연습을 한다.

침착하고 명시적인 결정 연습

종이에 체크 표시를 하는 의식은 다음과 같은 효과가 있다.

리더십이 눈에 보이는 형태로 드러난다.
심리적 안전감을 만든다. 사람들은 “그래도 계획은 있다”는 사실을 눈으로 본다.
나중에 비난을 줄인다. 위험한 액션들이 “깜빡 잊힌 것”이 아니라, 의도적으로 미뤄진 것임이 분명해지기 때문이다.

우리는 사람들에게 반사적으로 대응하게 만드는 대신, 의도적으로 선택하는 법을 훈련시키는 것이다.

매 인시던트 이후 메뉴를 살아 있게 유지하기

정적인 메뉴는 곧 낡거나, 위험할 정도로 불완전해진다.

중대한 인시던트가 끝난 후, 포스트모텀/사후 리뷰에서 다음을 확인한다.

너무 유혹적이었던 액션이 무엇인지 묻는다. 누군가가 반복해서 제안했지만 실제론 초기에 하지 말았어야 할 행동이 있었는가? 그렇다면 섹션 A에 올려야 할지 검토한다.
효과 없거나 해로운 습관적 액션을 퇴출한다. 자주 쓰이는데 자꾸 일을 더 꼬이게 만드는 조치가 있다면, 고위험 섹션으로 격상시키거나 메뉴에서 제거한다.
검증된 안전한 액션을 승격한다. 반복적으로 사용해 보니 안전하고 유용한 대응이라면, Safe Defaults 섹션에 추가한다.
출력·재배포한다. 업데이트된 물리 메뉴를 다시 인쇄하고, 모든 온콜 담당자가 최신 버전을 가지고 있는지 확인한다.

시간이 지나면서, 이 메뉴는 조직의 집단 학습이 농축된 결과물이 된다. “다시는 이렇게 하지 말자”와 “이건 항상 고려하자”는 경험적 지혜가 한 장에 모인다.

이번 주 안에 시작하는 방법

큰 프로젝트가 필요 없다. 작게 시작하자.

1차 버전 메뉴를 초안으로 만든다.
- 첫 15분 동안 손대지 말아야 할 고위험 액션 5~10개
- 초기에 해도 좋은 안전한 액션 3~5개
출력해서 모든 온콜 워크스테이션에 비치한다.
간단한 첫 15분 체크리스트를 인시던트 문서에 추가한다.
단 한 번의 테이블탑(tabletop) 연습이라도 메뉴를 사용해 진행해 본다.
피드백을 받아 다듬는다.

실제 인시던트에서, 꽤 자주 누군가가 이렇게 말하게 될 것이다. “일단 메뉴부터 보죠.”

결론: 더 나은 인시던트를 위한 단순한 의식

시스템은 점점 복잡해지지만, 인시던트 대응 의식은 꼭 복잡할 필요는 없다.

아날로그 인시던트 철도 식당차 — 종이 메뉴, 공유된 메타포, 그리고 첫 15분 플레이북은 팀이 다음을 할 수 있게 돕는다.

패닉에 휩쓸린 고위험 조치를 피한다.
심각한 수술에 들어가기 전에, 안정화와 관측 가능성 확보에 집중한다.
압박 속에서도 침착하고, 기준 기반의 리더십을 연습한다.
힘들게 얻은 교훈을 살아 있는 물리 아티팩트에 담아 축적한다.

다음 장애가 터져 아드레날린이 치솟고, 모두가 “뭐라도 해보자”고 말하고 싶어질 때, 식당차에 올라가 메뉴를 펼치고, 함께 결정하자. 지금은 무엇을 고치지 않을지.

미래의 당신, 업타임 그래프, 그리고 사용자들이 그 선택에 감사하게 될 것이다.