아날로그 장애 스토리 객차: 온콜을 따라다니는 ‘종이 아카이브’ 만들기

온콜은 마치 영화 중간에 갑자기 던져져서, 앞부분에 무슨 일이 있었는지 전혀 모르는 채로 시작하는 느낌일 때가 많습니다.

새벽 2시 17분, 페이저가 울립니다. 대시보드는 새빨갛고, 슬랙 채널은 불이 난 것처럼 난리입니다. 시스템은 런북에 적힌 단계와 맞지 않는 방식으로 이상 행동을 보이고 있습니다. 로그, 그래프, 예전 티켓, 구전 지식, 그리고 어렴풋이 기억나는 작년 포스트모템을 뒤지며 상황을 하나씩 짜 맞추기 시작합니다.

사실 지금 당신에게 정말 필요한 건, 이 시스템이 어떻게 실패해 왔는지에 대한 이야기가 — 명확하고, 단순하게, 필요할 때마다 — 당신 쪽으로 굴러와 주는 것입니다.

여기서 등장하는 개념이 바로 **아날로그 장애 스토리 객차(Analog Incident Story Train Car)**입니다. 과거 장애, 실패 패턴, 대응 내역을 담은 ‘굴러가는 종이 아카이브’로서, 온콜을 dosliterally (혹은 비유적으로) 따라다니며 무엇을 할지뿐 아니라 왜 그렇게 해야 하는지까지 이해하도록 도와줍니다.

이 글에서는 온콜 런북 위에 그런 “스토리 객차”를 어떻게 쌓아 올릴 수 있는지 살펴봅니다. 이를 통해 Mean Time To Resolution(MTTR)을 줄이고, 스트레스를 낮추며, 도메인 전문가가 아니어도 어떤 엔지니어든 자신 있게 장애에 대응할 수 있게 만듭니다.

런북에서 스토리북으로

**온콜 런북(on‑call runbook)**은 엔지니어가 장애에 효과적으로 대응할 수 있도록 절차를 문서화한 가이드입니다. 대부분의 팀은 이런 문서를 어느 정도는 가지고 있습니다.

• "서비스 X 지연(latency)이 임계값을 넘으면, 대시보드 Y를 확인하라"
• "에러 Z가 발생하면, 클러스터 B의 파드 A를 재시작하라"

분명 유용합니다. 하지만 한계도 뚜렷합니다. 이런 문서는 대개 정적이고, 깨지기 쉽고, 맥락이 빈약합니다. 어떤 순서로 무엇을 할지는 알려 주지만, 시스템이 시간에 따라 어떻게 행동해 왔는지는 잘 보여주지 못합니다.

**스토리 객차(story train car)**는 이런 런북을 살아 있는, 굴러가는 히스토리로 바꿉니다.

• 절차 옆에 과거 장애에 대한 스토리를 함께 싣습니다.
• 새로운 장애가 생길 때마다 앞으로 굴러가며 업데이트됩니다. 끝난 문서가 아니라, 계속 진화하는 기록입니다.
• 아날로그라는 말은 정보가 사람 친화적인 단순한 형태 — 타임라인, 스케치, 종이 다이어그램, 체크리스트 — 로 표현된다는 뜻입니다.

목표는 단지 어떤 버튼을 누를지가 아니라, 이 시스템이 보통 어떻게 망가지는지, 부하를 받으면 어떤 반응을 보이는지, 그리고 오늘 장애가 그 패턴 속에서 어디쯤에 위치하는지를 보여주는 것입니다.

이 추가적인 맥락이 MTTR을 안정적으로 낮추고, 새벽 2시의 당신이 멘붕에 빠지지 않도록 지켜줍니다.

왜 스토리가 런북 안에 있어야 할까

잘 설계된 온콜 문서는 단순히 명령어 목록을 넘어서는 역할을 합니다. 그것은:

• MTTR을 줄입니다. 패턴을 더 빨리 인식하고 효과적인 완화책을 선택할 수 있게 해 줍니다.
• 온콜 스트레스를 줄입니다. 명확하고 구조화된 가이드를 제공해, 판단 부담을 경감합니다.
• 모든 팀원이 장애를 다룰 수 있게 합니다. 특정 전문가가 아닌 누구라도 자신 있게 대응할 수 있도록 돕습니다.

온콜에서 오는 스트레스의 상당 부분은 ‘불확실성’에서 옵니다.

• "이거 예전에 겪어본 건가?"
• "시니어들은 다 아는 뻔한 걸 나만 모르고 있는 건 아닐까?"
• "내가 X를 하면, 어떤 연쇄 반응이 일어날지 확실히 알고 있나?"

스토리 객차는 이런 질문에 구체적인 장애 내러티브로 답합니다.

"2024‑05‑12에 비슷한 타임아웃이 발생했다. 원인: 서드파티 지연으로 인한 캐스케이딩 리트라이. 대응: 타임아웃 일시 증가, 동시성 축소, 특정 기능 플래그 비활성화. 장기 해결: 서킷 브레이커 추가."

이러한 스토리들이 런북의 단계와 나란히 존재하면, 온콜은 더 이상 ‘히어로 플레이’가 아니라, 정보에 기반한 ‘가이드된 프로세스’가 됩니다.

정적 실패 vs 동적 실패: 스토리 객차가 담아야 할 것들

유용한 장애 스토리 아카이브를 만들기 위해서는, 엔지니어링에서 흔히 쓰는 개념인 정적(static) 실패와 동적(dynamic) 실패를 구분해 생각하는 것이 좋습니다.

정적 실패 메커니즘

정적 실패는 비교적 안정적인 부하나 조건 아래에서 무언가가 ‘그냥’ 고장 나는 상황입니다.

• 디스크 용량이 100%에 도달한다.
• 설정 값이 잘못 들어 있다.
• 인증서가 만료된다.

이런 것들은 대개 이분법적입니다. 정상 → 고장. 런북으로 문서화하기 더 쉽습니다. 왜냐하면 다음과 같이 깔끔하게 맵핑되기 때문입니다.

"X가 참이면, Y를 하라."

동적 실패 메커니즘

동적 실패는 부하, 타이밍, 서비스 간 상호작용이 합쳐져 나타납니다.

• Thundering herd 문제
• 마이크로서비스 전반에 걸친 타임아웃/리트라이의 연쇄 반응
• 오토스케일링의 피드백 루프 (스케일 아웃 → DB 부하 증가 → DB 지연 → 타임아웃 증가 → 리트라이 증가 → …)

이런 실패는 시간 축을 갖습니다. 대응하는 동안 시스템 상태가 진화합니다.

효과적인 장애 대응을 위해서는 두 가지 모두를 이해해야 합니다.

• 정적: "이 구성요소가 고장났다; 고치거나 페일오버하면 된다."
• 동적: "지금 시스템이 악순환에 빠지고 있다; 내 액션이 이 악순환을 키울 수도, 줄일 수도 있다."

스토리 객차는 다음을 보존해야 합니다.

• 정적 실패: 명확한 증상 → 근본 원인 → 빠른 점검 포인트
• 동적 패턴: 사건의 시퀀스, 피드백 루프, 일시적인 상태 변이

여기서 현대 공학에서 쓰는 유한요소법(Finite Element Method, FEM) 같은 모델링 도구가 사고방식 측면에서 영감을 줄 수 있습니다. 실제 서비스 운영에서 FEA 툴을 쓰지 않더라도 말이죠.

장애 대응이 FEM에서 배울 수 있는 것들

유한요소법(FEM) 도구는 복잡한 구조물이 변동하는 하중(load), 강도(strength), 응력(stress) 아래서 어떻게 거동하는지 모델링합니다. 예를 들어 이런 질문에 답하게 돕습니다.

• 차량 통행이 늘어날 때, 이 다리는 어디서 먼저 휘어질까?
• 재료 특성이 달라지면, 파단 지점은 어떻게 달라질까?

분산 시스템도 비슷한 관점에서 볼 수 있습니다.

• Load(부하) → 트래픽, 잡 볼륨, 요청 패턴
• Strength(강도) → 용량, rate limit, 리소스 제약
• Stress(응력) → 지연(latency), 에러율, 큐 길이, CPU/메모리 압박

현대 FEM 도구는 단일 구성만 모델링하지 않고, 변동과 상호작용을 시뮬레이션합니다.

• 특정 구간의 부하가 치솟고, 다른 구간의 강도가 떨어지면 어떻게 될까?
• 로컬한 핫스팟이 어디서 생기고, 어떻게 전파될까?

스토리 객차는 내러티브 형태로 이것과 유사한 일을 해야 합니다.

• 장애가 서비스 간을 따라 어떻게 전파되었는지를 캡처합니다.
• **응력 집중(stress concentration)**이 가장 먼저 나타난 지점을 기술합니다. (예: 큐, DB 레플리카, 캐시)
• 특정 운영 액션이 응력 분포를 어떻게 바꾸었는지 보여줍니다.

FEA의 메쉬(mesh) 대신, 우리는 타임라인, 다이어그램, 메모를 사용합니다. 하지만 사고방식은 같습니다.

"이 부하 패턴 아래에서, 응력이 우리 시스템 안에서 이렇게 이동했고, 결국 여기서 실패했다."

이 관점을 가지면 런북은 더 스마트해지고, 대응은 더 정밀해집니다.

아날로그 장애 스토리 객차 설계하기

이제 구체적으로, 온콜을 따라다니는 굴러가는 종이 아카이브를 어떻게 만들 수 있을지 살펴봅시다.

각 핵심 서비스나 서브시스템마다 여러 관점을 묶어 놓은 번들을 만든다고 생각하면 됩니다.

1. 첫 장: 퀵 액션 런북

압박 속에서도 한눈에 훑어볼 수 있는 한 페이지(실물 종이든 디지털이든)입니다.

• 서비스 이름 & 역할: 이 서비스가 무엇을 하는지 한 문장으로 요약
• 골든 시그널(golden signals): 지연, 에러, 포화도, 트래픽을 어디서 보는지
• 가장 흔한 알람과 그에 대응하는 점검 절차
• 즉시 실행해도 항상 안전한 액션: 예: "read-only 모드로 전환", "이 노드 드레인(drain)", "stateless 워커 재시작" 등

이 페이지의 목적은, 이미 알려지고 반복되는 80%의 장애에 대한 MTTR을 줄이는 것입니다.

2. 그 뒤의 페이지들: 장애 스토리 내러티브

첫 페이지 뒤에는, 주요 장애 유형별로 1~2페이지씩 스토리를 붙입니다. 각 스토리는 다음을 포함합니다.

• 제목: 어떤 종류의 실패인지 (예: "부분 DB 장애 시 write-path 붕괴")
• 시나리오 스케치: 부하가 어떻게 이동했고, 어떤 컴포넌트가 스트레스를 받았으며, 어디서 깨졌는지를 보여주는 간단한 다이어그램(박스와 화살표 정도면 충분)
• 타임라인: 핵심 이벤트를 타임스탬프와 함께 정리
  • 증상이 시작된 시점
  • 최초 감지 시점
  • 시도했던 것(실패한 시도 포함)
  • 최종적으로 효과가 있었던 조치
• 정적 vs 동적 요소: 다음을 불릿으로 정리
  • 정적: 설정 오류, 용량 한계, 하드 페일
  • 동적: 피드백 루프, 리트라이 폭주, 오토스케일링 동작
• 운영 인사이트(Operational lessons):
  • "다음에 비슷한 상황이면, 이 3가지를 먼저 확인하라."
  • "X는 절대 하지 말 것 — 왜냐하면 … 해서 상황을 악화시킨다."

장편 소설이 필요하지 않습니다. 장애 패턴 하나당 잘 구조화된 1~2페이지면 충분합니다.

3. FEM에서 영감을 받은 뷰: 스트레스 맵과 핫스팟

실제 장애를 바탕으로, 스트레스 거동을 아주 단순한 시각 자료로 표현해둡니다.

• 정상 상태에서 부하는 어디에 주로 집중되는가?
• 컴포넌트 A가 고장 났을 때, 스트레스는 어디로 옮겨가는가?
• 어떤 컴포넌트가 보통 가장 이른 경고 신호를 주는가?

이 역시 거창할 필요 없습니다. 간단한 스케치, 부하 화살표, 그리고 이런 메모 정도면 충분합니다.

"캐시 레이어 C가 느려지면, DB D의 CPU가 2분 이내에 스파이크 난다. D의 CPU를 리딩 인디케이터로 모니터링할 것."

이걸 스토리 객차에 묶여 있는 아날로그 ‘시뮬레이션 스냅샷’이라고 생각하면 됩니다.

4. 바닥글: 객차를 업데이트하는 방법

좋은 화물열차 객차에는 항상 새 화물이 실립니다.

각 페이지 하단에는 다음 정보를 넣어 둡니다.

• "마지막 업데이트" 날짜
• 오너 (팀 또는 담당자)
• 짧은 "새 스토리 추가 방법" 체크리스트
  • 주요 장애가 끝난 뒤, 대응자가 1~2페이지 분량의 스토리를 추가한다.
  • 원인, 영향, 조치, 새로 관찰된 스트레스 패턴을 요약한다.
  • 더 자세한 내용은 전체 포스트모템 링크를 건다.

이러면 시스템이 진화함에 따라, 아카이브도 함께 굴러가며 업데이트됩니다.

실제 온콜에서 달라지는 것들

이런 장애 스토리 객차를 몇 달 정도 꾸준히 사용하면, 다음과 같은 변화를 느끼게 될 것입니다.

• MTTR 감소: 익숙한 패턴을 더 빨리 인식하게 됩니다.
• 스트레스 감소: 일이 꼬일 때 붙들고 있을 수 있는 신뢰할 만한 ‘손잡이’가 생깁니다.
• 참여 인원 확대: 미드레벨과 주니어 엔지니어도, 알려진 패턴에 대해서는 안전하게 장애 대응을 리드할 수 있습니다.
• 더 나은 설계 피드백: 스토리 객차에서 드러난 패턴이 아키텍처/용량 설계 논의로 바로 이어집니다.

각 장애를 매번 ‘완전히 새로운 사건’처럼 대하는 대신, 시스템이 어떻게 실패하는지에 대한 점점 정교해지는 모델과 상호작용하게 됩니다. 그 모델은 대시보드나 로그 원시 데이터가 아니라, 아날로그 스토리의 형태로 캡처되어 있습니다.

결론: 당신의 스토리가 함께 달리게 하라

장애는 언제나 발생합니다. 시스템은 계속해서 여러분을 놀라게 할 것입니다. 하지만 페이저가 울릴 때마다 매번 제로부터 시작할 필요는 없습니다.

런북을 아날로그 장애 스토리 객차 — 온콜을 따라다니는 ‘실패 스토리의 종이 아카이브’ — 로 확장하면, 다음을 얻습니다.

• 정적/동적 실패 메커니즘을 모두 포착할 수 있습니다.
• 내러티브와 단순한 시각 자료로, 부하·강도·스트레스의 변화를 모델링합니다.
• 엔지니어가 단순히 명령만 수행하는 것이 아니라, 맥락을 이해한 상태에서 대응할 수 있게 합니다.

이를 위해 새로운 플랫폼이나 화려한 AI 도구가 꼭 필요한 건 아닙니다. 공유 문서 하나, 전쟁실(war room)에 붙여 둔 출력물, 물리적 바인더처럼 구성한 위키 섹션이면 시작하기에 충분합니다.

중요한 건, 시스템이 굴러가며 진화하듯이 당신의 스토리도 함께 굴러가야 한다는 점입니다. 그래야 각 장애가 다음 장애를 더 쉽게 만들고, 온콜 근무는 생존 가능하고, 지속 가능하며, 어쩌면 조금은 ‘뿌듯하기까지 한’ 일이 될 수 있습니다.