아날로그 사고 스토리 철도 다락방: 잊힌 장애 기록을 털어 오늘의 런북을 다시 쓰는 법

규모와 상관없이 모든 운영팀에는 하나씩 있다. 실제로 있든, 머릿속에만 있든 하나쯤은 존재하는 철도 다락방이다.

여기는 옛날 사고들이 먼지를 뒤집어쓴 채 방치된 저장 공간이다.

세 해 전 겨울에 났던 전원 장애
전체 서비스 절반을 날려버린 연쇄 DNS 장애
누구도 끝까지 이해하지 못했지만 언젠가 사라져 버린 “원인불명 레이턴시” 이슈

사람들은 몇 가지 조각만 기억한다. 사후 보고서는 어딘가에 있다. 런북에는 어렴풋한 언급 정도가 남아 있을 수 있다. 하지만 진짜 이야기―의사결정의 순서, 맹점, 숨은 비용―는 사실상 사라진 것이나 다름없다.

이렇게 쌓여 있는 아날로그 사고 스토리들의 철도 다락방은 현대 운영에서 가장 과소평가된 자산 중 하나다. 제대로 다루기만 하면, 런북을 설계하는 방식, 대응자를 교육하는 방식, 복원력(Resilience)에 투자하는 우선순위까지 통째로 바꿀 수 있다.

이 글에서는 다음을 다룬다.

사고 이력을 구전 설화가 아닌 검색 가능한 아카이브로 취급하는 법
과거 장애에 포렌식(Forensic) 스타일의 타임라인 분석을 적용하는 법
대형 사고를 런북을 직접 업데이트하는 구조화된 케이스 스터디로 바꾸는 법
사후 리뷰(Post-Incident Review)가 항상 런북 변경으로 이어지게 만드는 프로세스
폭염·폭우 같은 이상 기상과 경제적 영향 등 외부 스트레서를 통합하는 법
과거 데이터를 활용해 더 똑똑하게 복원력 투자를 결정하는 법

1. 사고 이력은 곧 철도 다락방이다

대부분의 조직에는 수년 치 사고 이력이 여기저기 흩어져 있다.

채팅 로그와 티켓 시스템
모니터링 대시보드
이메일 스레드
사후 리뷰 발표 슬라이드
복도 대화에서 전해지는 구전 “무용담”

이 모든 것을 하나의 오래된 철도 다락방이라고 생각해보자. 과거 탈선 사고와 아찔했던 아차사고에 대한 로그, 매뉴얼, 바랜 메모 상자들이 쌓여 있는 곳. 겉으로 보기엔 혼란스럽고 낡아 보인다. 하지만 의도를 가지고 올라가서 뒤지기 시작하면 다음 같은 것들을 발견하게 된다.

반복되는 실패 패턴 (예: 같은 의존성이 매번 다른 방식으로 고장남)
운영상의 블라인드 스팟 (예: 아무도 소유하지 않는 핵심 통합 지점)
런북의 빈 구멍 (예: 감지는 잘 문서화되어 있지만, 언제 서비스를 중단할지에 대한 가이드가 없음)
눈감고 넘어간 리스크 (예: 폭염 같은 외부 스트레서를 일회성 특이점으로 치부한 사례)

첫 단계는 관점 전환이다.

과거 사고는 부끄러워서 잊어야 할 실패가 아니다. 고해상도의 트레이닝 데이터다.

목표는 먼지 쌓인 사고 스토리를 오늘과 내일의 런북을 위한 구조화된 입력으로 바꾸는 것이다.

2. 과거 사고에 포렌식 스타일 타임라인 분석을 적용하라

옛날 포스트모템을 에세이 읽듯이 훑어보지 말고, 사이버/디지털 포렌식 조사를 하듯이 다뤄라.

중대한 장애에 대해서는 다음을 재구성한다.

정확한 사건 타임라인
- 증상이 처음 나타난 시점은 언제인가?
- 누군가 처음 눈치챈 시점은?
- 공식적으로 인시던트가 선언된 시점은?
- 주요 의사결정이 내려진 시점은 언제인가?
의사결정 지점과 고려했던 옵션들
- 실제로 어떤 액션이 실행됐는가?
- 논의되었지만 거부되었거나 잊힌 액션은 무엇인가?
- 혼선이나 이견 때문에 어디서 시간이 지연되었는가?
당시 이용 가능했던 정보 vs 필요했던 정보
- 각 단계에서 대응자들은 무엇을 사실이라고 믿었는가?
- 어떤 데이터가 없었거나, 오도했거나, 접근이 어려웠는가?
- 어떤 대시보드나 알림은 도움이 되었고, 어떤 것들은 노이즈만 만들었는가?
런북과의 상호작용
- 관련된 런북이 있었는가?
- 실제로 누구라도 그것을 사용했는가? 사용하지 않았다면 이유는?
- 사용했다면, 어디서 도움이 되었고 어디서 한계를 드러냈는가?

이 작업을 실제 사이버 공격이나 대형 철도 사고를 복원하는 것처럼 대하라. 과거 결정을 방어하려는 게 아니라, 현실의 정밀한 지도를 그리는 일이다.

목표는 명확하다. **런북에 암묵적으로 들어 있던 “우리가 사고를 이렇게 겪을 거라고 생각했던 방식”**과 사실상 사고가 전개된 실제 방식 사이의 간극을 찾아내는 것이다.

3. 대형 장애를 구조화된 케이스 스터디로 바꿔라

“블랙 프라이데이에 빌링이 죽었던 그때 기억나?” 같은 구전으로만 남겨 두지 말고, 대형 장애를 구조화된 케이스 스터디로 변환하라. 이렇게 하면:

신규 온콜·대응자 교육에 활용할 수 있고
런북 설계·업데이트에 곧바로 피드백을 줄 수 있으며
누가 회사를 떠나더라도 사라지지 않는, 정밀한 공유 기억을 만들 수 있다.

간단한 구조화 인시던트 케이스 스터디 템플릿은 다음과 같다.

컨텍스트
- 날짜, 영향받은 시스템, 사용자 영향, 비즈니스 영향
트리거와 근본 원인(Root Cause)
- 기술적 근본 원인과 기여 요인(사람·프로세스 요인 포함)
타임라인
- 주요 이벤트, 의사결정, 전환점
도움이 되었던 것들
- 도구, 알림, 특정 액션, 기존 런북 단계들
발목을 잡았던 것들
- 가시성 부족, 모호한 오너십, 오래되었거나 오해의 소지가 있는 문서
런북에 대한 시사점
- 어떤 섹션이 잘못되었거나, 없었거나, 지나치게 모호했는가
- “언제 페일오버할 것인가”, “언제 SEV-1을 선언할 것인가” 같은 의사결정 기준이 어디에 필요한가
시나리오 훅(Scenario Hooks)
- 이 인시던트를 교육용 연습이나 게임데이(Game Day)로 어떻게 재현할 수 있는가

이렇게 하면 각 대형 사고는 더 이상 아카이브 속에서 잠든 PDF가 아니라, 살아 있는 자산이 된다.

4. 사후 리뷰가 반드시 런북 업데이트로 이어지게 만들어라

흔한 안티 패턴은 이렇다. 팀이 꽤 괜찮은 사후 리뷰를 하고, 좋은 메모를 남긴다. 그리고… 운영 플레이북에는 아무 변화도 없다.

이를 피하려면 간단하지만 양보 불가능한 규칙을 하나 박아 두어야 한다.

모든 사후 리뷰는 반드시 집중적인 런북 리뷰 및 업데이트를 결과물로 가져와야 한다.

구체적으로는 다음과 같다.

리뷰 중에 영향받은 런북을 식별한다.
- 어떤 런북이 실제로 사용되었는가?
- 존재했어야 했는데 없던 런북은 무엇인가?
- 있었으면 도움이 되었을 텐데 아무도 몰랐던 런북은 무엇인가?
명시적인 런북 액션 아이템을 만든다.
- “데이터베이스 페일오버 런북에 롤백 의사결정 기준을 추가한다.”
- “결제 API 강등 모드(Degraded Mode) 운영을 위한 신규 런북을 만든다.”
기한과 오너를 지정한다.
- 런북 업데이트는 제안이 아니라 실제 업무다. 다른 엔지니어링 태스크처럼 추적한다.
루프를 닫는다.
- 업데이트가 완료되면, 무엇이 왜 바뀌었는지 팀에 간단히 공유한다.

이렇게 하면 문서는 현실과 함께 진화하지, 현실에서 점점 떨어져 나가는 문서가 되지 않는다.

5. 모든 런북에 명확한 오너십을 부여하라

오너십이 없는 런북은 발굴 작업이 필요한 고고학 유물이 된다.

각 런북마다 단일 책임 오너(그리고 이를 지원하는 팀)를 지정하라. 이 오너는 다음에 대해 책임을 진다.

런북이 실제 인시던트와 시스템 변경 사항에 계속 정렬되도록 유지하는 일
관련 런북들 사이의 용어와 포맷 일관성 확보
주기적인 상태 점검 (예: 아직 정확한가? 단계가 여전히 유효한가?)

좋은 실천 방법은 다음과 같다.

다음 정보를 담은 런북 카탈로그를 유지한다.
- 이름, 범위, 커버하는 시스템
- 1차 오너
- 마지막 리뷰 일자
- 관련 인시던트·케이스 스터디 링크
리뷰 주기를 정한다. (예: 크리티컬 런북은 분기마다, 그 외는 반기에 한 번)
폐기 기준을 명시한다. 시스템이 퇴역하면, 그에 맞춰 런북도 명시적으로 Deprecated 처리해야 한다.

오너십이 생기면 런북은 정적인 문서에서 관리되는 운영 도구로 바뀐다.

6. 날씨·시장 등 외부 스트레서를 무시하지 마라

가장 아픈 사고들 중 상당수는, 전통적인 런북이 범위 밖으로 취급하는 외부 스트레서 때문에 촉발되거나 증폭된다. 예를 들면:

데이터센터·네트워크·전원에 영향을 주는 폭염·폭풍·홍수 같은 이상 기상
블랙 프라이데이, 바이럴 캠페인, 규제 마감일 등으로 인한 예기치 못한 트래픽 폭증
클라우드 리전, 결제 게이트웨이, 통신사 장애 같은 상류(Upstream) 서비스 장애

당신의 철도 다락방에도 거의 확실히 이런 스트레서가 배경에 있었던 사고들이 있을 것이다. 하지만 대부분 “한 번 있었던 희한한 일”로 처리되었을 가능성이 크다.

그러지 말고, 의도적으로 이 외부 스트레서를 인시던트 시나리오와 런북 설계에 통합하라.

다음과 같은 시나리오별 런북을 만든다.
- “온프레미스 하드웨어에 영향을 주는 극한 폭염 이벤트”
- “프라이머리 클라우드 리전이 장기간 장애를 겪는 시나리오”
- “피크 세일즈 데이에 결제 프로세서 성능 저하 발생 시 대응 런북”
비기술적 영향도 함께 담는다.
- 물리적 데이터센터 접근 지연
- 지역 재난 상황에서 깨지는 공급업체 SLA
- 고스트레스 상황에서의 커뮤니케이션 병목

이 시나리오들은 모두 과거 장애 기록에서 직접 끌어와야 한다.

저 지역의 회선을 폭풍이 날려 버렸을 때 실제로 무슨 일이 있었는가? 그때 우리가 미리 준비해 두었더라면 좋았을 것들은 무엇인가?

이 질문에 답하면서 런북을 설계하라.

7. 과거 데이터를 이용해 복원력 투자를 우선순위화하라

사고를 일화가 아닌 구조화된 데이터로 다루기 시작하면, 어디에 투자해야 할지 정량화할 수 있다.

과거 주요 장애에 대해 다음을 꾸준히 기록하라.

기술적 영향: 장애 시간, 영향받은 시스템, 심각도(Severity)
비즈니스 영향: 매출 손실, 운영 비용, 고객 이탈, SLA 페널티, 평판 손상
근본 원인 카테고리: 설정 오류, 용량 이슈, 하드웨어 장애, 서드파티 의존성, 외부 이벤트 등
런북 퍼포먼스: 존재/부재, 실제로 따랐는지 여부, 충분했는지 여부

그러면 패턴이 보이기 시작한다.

특정 서비스는 계속해서 고비용 장애를 유발하지만, 해당 런북은 빈약하거나 오래되었다.
특정 외부 스트레서(예: 폭염, 전력 불안정, 클라우드 리전 장애)가 고심각도 인시던트와 강하게 상관된다.
몇 가지 투자(더 나은 Observability, 페일오버 자동화, 명확한 의사결정 기준)는 과거의 여러 인시던트를 한꺼번에 완화했을 수 있다.

이 데이터를 활용해 다음을 결정하라.

어떤 런북을 먼저 전면 개편할지
어디에 새로운 런북이나 시나리오를 추가할지
과거의 구체적인 경제적 영향을 근거로 복원력 투자를 정당화할지

이 철도 다락방에는 이야기만 있는 것이 아니다. ROI 중심 복원력 계획을 위한 데이터셋이 숨어 있다.

결론: 의도를 가지고 다락방에 다시 올라가라

현대의 신뢰성(Resilience·Reliability) 작업은 종종 다음 도구, 다음 대시보드, 다음 자동화에 집착한다. 하지만 가장 강력한 레버 중 하나는 이미 거기 있다. 바로 시스템이 실제로 어떻게 실패했는지, 팀이 실제로 어떻게 대응했는지에 대한 잊힌 기록이다.

이 사고 이력을 큐레이션할 가치가 있는 철도 다락방으로 대하라.

포렌식 스타일 타임라인 분석으로 실제로 무슨 일이 있었는지 복원하고
대형 사고를 서서히 희미해지는 무용담이 아닌 구조화된 케이스 스터디로 만들고
모든 사후 리뷰가 구체적인 런북 업데이트로 이어지게 만들고
명확한 오너십을 부여해 런북이 최신성과 일관성을 유지하게 하고
폭염·시장 이벤트 같은 외부 스트레서를 계획 단계에 통합하고
과거의 기술·비즈니스 임팩트 데이터를 사용해 복원력 투자를 설계하라.

이 과정을 일관되게 수행하면, 런북은 이상적인 세상을 전제로 작성된 정적 문서에서 벗어나, 실제 장애·실제 의사결정·실제 비용 위에 세워진 살아 있는 운영 내러티브가 된다.

필요한 것은 과거 인시던트의 수를 줄이는 일이 아니다. 이미 겪은 인시던트에서 훨씬 더 공격적으로 학습하는 것이다.