소개

당신의 프로덕션 환경을 복잡한 철도 시스템이라고 상상해 보자.

선로는 의존성, 기차는 사용자 요청, 역은 서비스, 그리고 분기기는 기능 플래그와 라우팅 규칙이다. 일상적인 운영 중에는 모든 것이 문제없이 굴러가는 것처럼 보이지만, 작은 분기기 오동작이나 과부하가 걸린 선로 하나 때문에 전체 시스템이 순식간에 혼란에 빠질 수 있다.

대부분의 조직은 이 ‘철도’가 얼마나 취약한지 실제 장애가 터질 때까지 알지 못한다. 인시던트 대응 계획은 위키와 슬라이드 덱 안에 존재하지만, 현실 세계에서 벌어지는 지저분한 크로스팀 상호작용과 연쇄 장애를 반영한, 현실적인 조건에서 검증되는 일은 거의 없다.

여기서 등장하는 것이 바로 종이 런북 기차 세트(Paper Runbook Trainset) 다. 여러 팀이 종이 런북, 표준화된 템플릿, 진화하는 시나리오를 사용해 함께 인시던트를 리허설하는, 살아 있는 테이블탑 ‘철도’ 환경이다. 의도적으로 로우 테크지만, 사람들의 행동을 바꾸고, 빈틈을 드러내며, 진짜 회복탄력성을 키우는 데는 임팩트가 크다.

이제는 테이블탑 연습도 성숙해야 한다

전통적인 테이블탑 인시던트 연습은 대체로 이렇게 진행된다.

• 슬라이드 덱에 어렴풋한 장애 상황이 설명되어 있다.
• 퍼실리테이터가 대본을 읽어 내려간다.
• 몇몇 리더들이 자신들이 어떻게 할 것 같은지 말한다.
• 누군가가 메모를 남기지만, 실제 바뀌는 것은 거의 없다.

이런 방식이 아예 안 하는 것보다는 낫지만, 시뮬레이션의 핵심 가치인 시스템과 사람 모두를 현실적으로 스트레스 테스트하는 것을 놓치고 있다.

효과적인 테이블탑 연습이라면 다음과 같아야 한다.

• 구체적인 시나리오 기반: 그냥 “장애가 났다”가 아니라, 실제로 특정 대시보드가 깨지고, 로그 스트림이 멈추고, 온콜 로테이션이 꼬이고, 고객이 불만을 제기하는 상황을 본다.
• 시간 압박과 제약: 결정은 제약 속에서 이뤄진다. 5분 안에 에스컬레이션, 10분 안에 나쁜 옵션들 중에서 하나를 골라야 한다.
• 다팀·인터랙티브: 실제 인시던트는 한 팀만의 일이 아니다. Observability, 플랫폼, 프로덕트, 보안, 고객 지원이 한꺼번에 부딪힌다.

이런 현실성이 없으면, 우리는 인시던트 대응 능력이 아니라 이야기 잘 꾸미는 능력만 테스트하게 된다.

종이 런북 기차 세트: 이것이 무엇인가

"종이 런북 기차 세트(Paper Runbook Trainset)"는 물리적 혹은 가상 테이블탑 위에서 다팀 인시던트를 리허설하기 위한 프레임워크다. 다음 요소들을 활용한다.

• 서비스, SLO, 대시보드, 에스컬레이션 경로를 나타내는 종이 런북(인쇄본 또는 디지털 문서)
• 시스템을 기차 레이아웃처럼 취급하는 ‘철도 노선도’ 형태의 시스템 지도: 서비스, 의존성, 사용자 진입점, 외부 공급자 등을 단순화한 토폴로지 다이어그램
• 초기 장애와 그 파급 경로를 설명하는 시나리오 카드
• 시나리오가 진행되면서 연쇄 장애, 과부하, 새로운 변수를 시뮬레이션하기 위한 퍼실리테이터 규칙

프로덕션 환경을 위한 모형 기차 세트라고 생각하면 된다. 가지고 놀 수 있을 만큼 작지만, 어디에서 선로가 부러질지 드러낼 만큼은 충분히 정교한 모델이다.

다팀 인시던트: “수리”만이 아니라 “핸드오프”를 연습하라

대부분의 포스트모템을 살펴보면, 인시던트에서 가장 어려운 부분은 순수하게 기술적인 문제는 아니다.

• 위험한 결정을 내릴 권한은 누가 갖고 있는가?
• 플랫폼 팀은 언제 프로덕트 팀에 넘겨야 하는가?
• 시간 압박 속에서 보안과 법무는 어떻게 엮어 넣을 것인가?
• 고객과는 누가, 무엇을, 어떻게 이야기해야 하는가?

이는 디버깅 문제가 아니라, 크로스펑셔널 커뮤니케이션과 의사결정의 문제다.

종이 런북 기차 세트에서는 각 팀이 철도 상의 하나 혹은 여러 개의 “역” 역할을 맡는다.

• SRE / 플랫폼: 라우팅, 인프라 선로, 공용 서비스
• 프로덕트 / 피처 팀: 특정 역과 그 주변 로컬 선로
• 보안(Security): 구간을 차단하거나 격리할 수 있는 특수한 “분기기”
• 고객 지원 / 커뮤니케이션: 상태 페이지, SLA, 유입되는 불만 등으로 표현되는 “승객 경험”

팀은 한 자리에 모이거나(혹은 화상 회의 브레이크아웃 룸으로) 각자의 런북과 대시보드를 앞에 두고 앉는다. 시나리오가 전개되면서 해야 할 일은 다음과 같다.

• 인시던트 역할(Incident Commander, Communications, Operations 등)을 선언하고 갱신한다.
• 다른 선로에 도움을 요청하고 에스컬레이션한다. (예: “DB 팀을 당장 콜에 불러야 합니다”)
• 롤백 vs. 부분 셧다운, 기능 플래그 조정 vs. 트래픽 셰이핑 같은 결정을 함께 조율한다.

목표는 마찰을 드러내는 것이다.

• 핸드오프가 명확한가, 아니면 매번 애드리브인가?
• 사람들은 누구에게 전화해야 할지 알고 있는가, 아니면 그냥 아무 Slack 채널이나 외치고 보는가?
• 승인 대기 때문에 어디에서 결정이 막히는가?

여기서 연습하는 것은 “Redis를 어떻게 고치느냐”가 아니라, “세 팀이 이 문제를 얼마나 빠르고 안전하게 함께 풀어가는가”다.

연쇄 장애와 과부하: Motter–Lai를 테이블탑으로 끌어오기

실제 시스템은 깔끔하게 고장 나지 않는다. 한 컴포넌트(예: 커뮤니케이션 도구)의 부분적인 장애가, 조용히 전체의 효율을 갉아먹기도 한다.

이때 연쇄 장애(cascading failure)와 과부하 전파(overload propagation) 모델(예: Motter–Lai 모델)의 개념을 활용하면, 더 풍부한 테이블탑 시나리오를 설계하는 데 도움이 된다.

아주 거칠게 말하면, 이런 모델은 다음과 같은 가정을 한다.

• 각 컴포넌트에는 감당할 수 있는 용량(capacity) 이 있다.
• 부하는 네트워크 상의 여러 컴포넌트에 분산된다.
• 어떤 컴포넌트가 장애를 일으키거나 과부하가 걸리면, 그 부하가 주변에 재분배되면서 이웃 노드들까지 과부하 상태로 만들 수 있다.

인시던트 시뮬레이션에서는 이를 다음과 같이 구현할 수 있다.

• 각 “선로”(서비스)에 용량 카드를 부여한다: 정상, 성능 저하(degraded), 과부하(overloaded).
• 서비스가 다운되면 부하 이동을 시뮬레이션한다. 예: 리전 A가 죽으면 트래픽이 리전 B로 몰린다, 상태 페이지가 불분명하면 고객 지원 티켓이 폭증한다.
• 숨겨진 혹은 지연된 효과를 집어넣는다. 예: 인시던트 채팅 혹은 페이징 시스템이 불안정해 알림이 늦게 도착하고, 그로 인해 DB 과부하가 더 커지고 복구에 더 오래 걸리는 상황.

시뮬레이션할 수 있는 연쇄 사례 예시는 다음과 같다.

• 커뮤니케이션 → 전력망 비유: 인시던트 채팅 도구나 페이징 시스템이 불안정하면, “전력망(핵심 서비스)”의 다운타임이 길어지고 과부하가 심해진다. 사람들의 대응이 늦거나 조율되지 않기 때문이다.
• 완화 작업의 ‘떼 몰림’(Thundering Herd): 여러 팀이 동시에 재시작, 재인덱싱, 페일오버 같은 빠른 조치를 남발하면, 공용 인프라에 과부하를 일으킨다.

이처럼 과부하와 연쇄를 명시적으로 모델링하면, 팀은 인시던트를 더 이상 단일 장애 지점(SPOF)의 문제로 보지 않고, 서로 얽힌 네트워크적·시스템적 사건으로 보기 시작한다.

표준화된 아티팩트, 그러나 로컬 소유

이 테이블탑 세션을 효과적으로 운영하려면, 일관되고 접근 가능한 아티팩트가 필요하다.

• SLO 템플릿: “사용자 지향 에러율”, “핵심 엔드포인트 지연 시간”, “리전별 가용성”처럼 공통 구조를 가져 팀 간의 언어를 맞춘다.
• 런북 템플릿: 트리거 조건, 첫 단계 액션, 확인해야 할 그래프, 의사결정 트리, 에스컬레이션 경로, 롤백 절차 등.
• 대시보드 템플릿: 골든 시그널, 용량, 의존성 등 모든 서비스에 공통으로 존재해야 할 뷰(지표 자체는 달라도 된다).
• 포스트모템 템플릿: 타임라인, 임팩트, 근본 원인, 기여 요인, 후속 조치를 담는 표준 구조.

하지만 이 템플릿들은 중앙에서 다 써 내려간 경전이 되어서는 안 된다.

각 서비스 팀은 다음을 직접 해야 한다.

• 실제 사용자 경험에 맞게 SLO를 커스터마이즈한다.
• 로컬 현실과 의존성에 맞게 런북을 조정한다.
• 스스로 유용하다고 느끼는 방식으로 대시보드를 설계·개선한다.

이렇게 하면 다음 두 가지를 얻을 수 있다.

1. 일관성: 테이블탑에서 퍼실리테이터와 참가자들이 어느 팀의 자료든 빠르게 이해하고 탐색할 수 있다.
2. 로컬 전문성: 팀이 스스로 작성하고 주기적으로 손보는 문서이기 때문에, 실제로 내용이 몸에 배어 있다.

‘신뢰성 전담 팀’이 운전석에 앉지 않게 하라

많은 조직이 중앙에 “신뢰성(reliability)” 혹은 “인시던트 대응” 팀을 만들고, 그 팀이 모든 것을 책임지게 하고 싶어 한다. 런북, SLO, 인시던트 프로세스, 포스트모템까지 전부 말이다.

이 방식은 확장성이 떨어지고, 종종 역효과를 낳는다.

• 서비스 팀이 신뢰성의 소비자가 되고, 오너십을 잃는다.
• 지식이 중앙에만 몰려, 그 팀이 비가용하면 인시던트 대응 품질이 떨어진다.
• 일반론적인 가이드라인 때문에, 로컬 특성이 반영되지 못한다.

종이 런북 기차 세트 모델은 분산된 오너십을 기본 전제로 한다.

• 작은 중앙 그룹(SRE / 플랫폼 / 레질리언스 오피스 등)이 템플릿을 큐레이션하고, 연습을 퍼실리테이션하며, "철도 노선도"를 유지한다.
• 각 서비스 팀은 자신의 선로 구간—런북, SLO, 인시던트 대비 상태—에 대한 오너십을 가진다.
• 다팀 연습을 통해 빈틈을 드러내고, 공유된 근육 기억(shared muscle memory) 을 만들어 간다.

이렇게 하면 신뢰성은 특정 전문 팀이 대신 제공해 주는 서비스가 아니라, 모든 팀이 함께 연습하고 책임지는 것이 된다.

살아 있는 테이블탑 환경으로 만들기

한 번짜리 테이블탑 연습은 괜찮은 워크숍이다. 하지만 살아 있는 테이블탑 환경은 조직의 운영 리듬의 일부다.

이를 살아 있게 유지하려면 다음을 실천해야 한다.

1. 아키텍처가 바뀔 때마다 지도를 업데이트하라.

   • 신규 서비스, 종료되는 서비스, 변경된 의존성을 반영한다.
   • 새 서드파티 공급자와 중요한 통합 지점을 추가한다.

2. 시나리오를 지속적으로 추가하라.

   • 실제 인시던트에서 가져와, 약간 변형해(“리믹스”) 활용한다.
   • 리전 전체 장애, 주요 클라우드 공급자 장애, 공급망 공격 같은 가상 시나리오를 추가한다.
   • “조용히 쌓이는 문제”(무음 데이터 손상, 누적되는 백로그)처럼 서서히 타오르는(slow burn) 장애도 포함한다. 단발성 대규모 장애만 다루지 말라.

3. 참가자와 역할을 로테이션하라.

   • 시니어 엔지니어만 아니라, 주니어, 매니저, 지원, 프로덕트까지 포괄한다.
   • Incident Commander, 커뮤니케이션 담당, 테크니컬 리드 역할을 번갈아 맡게 한다.

4. 짧고 규칙적인 세션을 운영하라.

   • 1년에 한 번 하는 대규모 훈련보다, 2~3주에 한 번씩 60–90분 세션이 훨씬 낫다.
   • 처음에는 소규모(한두 팀)로 시작해, 점차 전체 다팀 연습으로 확장한다.

5. 배운 내용을 실제에 피드백하라.

   • 각 세션이 끝날 때마다 런북, 대시보드, SLO가 반드시 업데이트되게 하라.
   • 실제 인시던트 액션 아이템과는 별도로, “테이블탑 액션 아이템”을 추적하고, 반드시 클로즈한다.

시간이 흐르면, 이 철도 메타포는 비유를 넘어 현실이 된다. 단일 진화형 지도 위에서, 아키텍처, 인시던트 기대치, 주요 실패 모드를 누군가에게 산책하듯 설명할 수 있게 된다.

당신만의 종이 런북 기차 세트 시작하기

최소한의 셋업은 다음과 같을 수 있다.

1. 단순한 시스템 지도를 그린다.
   • 서비스는 역, 의존성은 화살표, 외부 공급자는 명확히 표시한다.
2. 2–3개 팀과 단일 시나리오를 고른다.
   • 예: 피크 트래픽 시간대에 발생한 주요 DB 지연(latency) 스파이크.
3. 해당 팀의 아티팩트를 인쇄하거나 준비한다.
   • SLO, 런북, 대시보드 스크린샷, 에스컬레이션 트리.
4. 역할과 타임박스를 정한다.
   • 퍼실리테이터, 서기(scribe), Incident Commander, 각 팀 대표.
5. 30–45분 안에 시나리오를 실행한다.
   • “알림 지연”, “티켓 볼륨 폭증” 같은 새 이벤트를 단계적으로 공개한다.
   • 팀이 무엇을 보고, 무엇을 할지, 누구에게 연락할지 계속 말로 선언하게 한다.
6. 가차 없이(deep하게) 회고한다.
   • 어디에서 느리거나 혼란스러웠는가?
   • 런북이나 대시보드에서 무엇이 빠져 있었는가?
   • 우리가 당연하다고 여긴 것 중, 문서화되지 않은 것은 무엇이었는가?

이후에는 반복이다. 선로를 더 추가하고, 팀을 늘리고, 실패 모드의 폭을 넓혀 나가라.

결론

인시던트는 시스템의 진짜 모습을 드러내는 순간이다. 인프라뿐 아니라 사람, 프로세스, 크로스팀 커뮤니케이션이 모두 드러난다.

종이 런북 기차 세트 같은 살아 있는, 시나리오가 풍부한 테이블탑 환경을 구축하면 다음을 이룰 수 있다.

• 정적인 인시던트 계획을 몸에 밴 행동(rehearsed behavior) 으로 바꾼다.
• 고객에게 상처를 주기 전에 연쇄 장애 경로와 과부하 역학을 발견한다.
• 압박 속에서의 다팀 조정, 의사결정, 핸드오프 역량을 강화한다.
• 중앙의 한 팀이 아니라, 분산된 오너십을 기반으로 한 신뢰성 문화를 만든다.

시작하는 데 화려한 시뮬레이션 도구는 필요 없다.

필요한 것은 지도 한 장, 약간의 종이, 몇 개의 의욕적인 팀, 그리고 실제 프로덕션에서 기차가 선로를 이탈하기 전에 함께 실패를 연습해 보겠다는 의지뿐이다.