Rain Lag

아날로그 장애 ‘열차 주방’: 모든 장애 단계에서 통하는 한 장짜리 플레이북 만들기

SRE, 클라우드 네이티브 대응, 전통적인 ITIL 워크플로를 하나로 잇는, 모든 장애 수명주기를 실제로 ‘함께 이동하는’ 아날로그 친화 한 장짜리 인시던트 대응 플레이북을 설계하는 방법.

아날로그 장애 ‘열차 주방’: 모든 장애 단계에서 통하는 한 장짜리 플레이북

상황을 떠올려 보자. 메인 대시보드는 먹통이고, 채팅 툴은 불안정하며, 위키는 로딩이 안 된다. 클라우드 콘솔은 굼뜬데, 장애는 분명히 진행 중이고 고객 영향도 현실이다.

이때 당신에게 남은 건 무엇인가?

많은 조직에서 답은 놀랍도록 초라하다. 몇 가지 입에서 입으로 내려오는 의식 같은 절차, “지난번에 이렇게 했던 것 같아”라는 흐릿한 기억, 그리고 절반쯤만 동작하는 툴들을 이리저리 눌러보는 사람 한 명.

여기서 등장하는 것이 바로 **“아날로그 장애 열차 주방(analog outage railcar kitchen)”**이다. 반짝거리는 도구들이 대부분 망가져도 여전히 먹히는 한 장짜리 플레이북. 마치 열차의 작은 주방칸처럼, 장애 여정 내내—기록부터 종료까지—어디로 이동하든 함께 따라오는, 자기완결적인 키트다.

이 글에서는 그 한 장짜리 플레이북을 어떻게 설계해야 하는지 정리한다. 이 플레이북은 다음을 만족해야 한다.

  • 인시던트 라이프사이클의 모든 단계를 가로지른다
  • 아날로그·오프라인 환경에서도 동작한다
  • 온라인일 때는 클라우드 컨텍스트를 녹여 쓸 수 있다
  • SRE 실무, 클라우드 네이티브 대응, 전통 ITIL 워크플로를 하나로 잇는다

왜 대부분의 플레이북은 가장 필요할 때 망가지는가

팀들은 온라인 런북, 복잡한 대시보드, 자동화에 많은 투자를 한다. 그건 좋은 일이다. 다만 그런 도구 대부분은 어떤 전제를 깔고 있다.

  • 모두가 평소처럼 시스템에 잘 접속할 수 있다
  • 네트워크, SSO, VPN 상태가 정상이다
  • 모니터링과 로깅이 잘 수집·조회된다

대규모 장애는 자주 이 전제들을 깨버린다.

많은 조직에서 빠져 있는 것은, 단일하면서도 구조가 분명한, 휴대 가능한 참조물이다. 이 문서는 다음을 만족해야 한다.

  1. 인시던트의 어느 단계에 있든 지금 무엇을 해야 할지 알려준다
  2. 스트레스 상황에서도 실제로 펼쳐볼 만큼 짧다
  3. 특정 툴이나 네트워크 접속에 의존하지 않는다

그게 바로 ‘한 장짜리 플레이북’이다.

한 장짜리 플레이북: 개념과 제약 조건

한 장짜리 플레이북은 다음과 같다.

  • 간결함: 이상적으로 A4(또는 Letter) 기준 앞뒤 2페이지. 더 필요하다면 두꺼운 바인더가 아니라, 작은 접지 리플렛 정도를 떠올리자.
  • 휴대성: 프린트하기 쉽고, 들고 다니기 쉽고, 벽에 붙이거나 비상 가방에 넣어두기 좋다.
  • 페이즈 인지: 전체 인시던트 라이프사이클에 맞춰 명시적으로 정렬되어야 한다.
    • 로깅(Logging)
    • 트리아지(Triage)
    • 할당(Assignment)
    • 대응(Response)
    • 진단(Diagnosis)
    • 복구/해결(Resolution)
    • 종료(Closure)
  • 아날로그 친화적: 펜, 전화선, 화이트보드 하나만 있어도 쓸 수 있어야 한다.
  • 툴 비의존·툴 인지: 우선 역할과 행동을 기준으로 쓰고, 그다음에 PagerDuty, Jira, ServiceNow, Wiz, Slack 등 당시 상황에 따라 있을 수도·없을 수도 있는 툴과의 매핑을 덧붙인다.

이 문서를 인시던트 ‘열차’에 붙어 있는 주방칸이라고 생각해 보자. 작지만 자기완결적이며, 열차 어느 칸에 있든 같은 주방을 쓸 수 있는 것처럼, 장애 여정 내내 어디서든 꺼내 쓸 수 있다.

모든 단계를 ‘함께 이동’하는 플레이북 설계하기

인시던트 라이프사이클을 단계별로 따라가면서, 한 장짜리 플레이북에 반드시 들어가야 할 내용을 살펴보자.

1. 로깅(Logging): 사건을 ‘기록된 인시던트’로 만들기

목표: “뭔가 이상한데?”라는 느낌을, 실제로 기록된 인시던트로 전환한다.

플레이북에는 다음을 포함한다.

  • 트리거 체크리스트: 반드시 인시던트로 기록해야 하는 신호의 짧은 목록
    • 예: P1 알람, 보안 이상 징후, 결제 실패 증가, 가용성 급락 등
  • 툴이 죽어 있어도 수기로 남길 수 있는 최소 기록 필드:
    • 탐지 시각
    • 최초 발견자
    • 영향받는 시스템/서비스
    • 고객 영향(확인/의심 여부 포함)
    • 초기 심각도(Severity) 가정

플레이북에는 분명히 적어야 한다. “애매하면 일단 인시던트로 기록한다.”

스트레스 상황에서는 사람들은 오히려 망설인다. 플레이북은 그 망설임을 줄여야 한다.

2. 트리아지(Triage): 정말 인시던트인가, 얼마나 심각한가

목표: 이게 얼마나 심각한 일인지, 그리고 어떤 트랙으로 태워야 할지 빠르게 결정한다.

플레이북에는 다음을 넣는다.

  • 영향도와 긴급도 기준의 심각도 매트릭스(P1–P4)
  • 간단한 예/아니오(Yes/No) 결정 트리:
    • “현재 또는 임박한 고객 영향이 있는가?” → 예면 최소 P2 이상
    • “매출, 안전, 보안이 위험한 상태인가?” → P1으로 즉시 상향
  • 명시적인 시간 제한: 예: “탐지 이후 트리아지는 최대 10분 이내에 끝낸다.”

이 단계에서는, Wiz 같은 도구에서 나오는 클라우드 리스크 컨텍스트가 있다면 매우 유용하다.

영향받은 시스템이 HIGH-RISK(민감 데이터, 고권한, 인터넷 노출 등) 태그인 경우, 심각도를 한 단계 상향한다.

이 규칙을 종이에 박아 두어야 한다.

3. 할당(Assignment): 책임자를 분명히 세우기

목표: 인시던트를 누가 책임지는지가 분명하고, 모두가 그 사실을 알고 있게 한다.

플레이북에는 다음을 정의한다.

  • 핵심 역할:
    • 인시던트 커맨더(IC, Incident Commander) – 의사결정과 전체 조율 책임자
    • 커뮤니케이션 담당(Comms Lead) – 상태 공유와 이해관계자 커뮤니케이션 담당
    • Ops/Tech 리드 – 기술 대응 팀의 작업 조율
  • 온콜 시스템이 죽었을 때를 위한 Fallback 선정 규칙:
    • “온콜 관리 툴을 쓸 수 없으면, P1을 가장 먼저 인지한 엔지니어가 임시 IC가 되며, 정식 온콜 담당자에게 성공적으로 핸드오프할 때까지 책임을 진다.”
  • 손으로 바로 적어 넣을 수 있는 역할 할당 템플릿:
    • IC: ______
    • Comms: ______
    • Ops Lead: ______

4. 대응(Response): 더 망가지는 것을 막고, 우선 안정화

목표: 원인을 다 파악하기 전에라도, 피해 확산을 멈추고 시스템을 안정화한다.

종이에는 우선순위 **사다리(priority ladder)**를 제시한다.

  1. 안전·보안 최우선 – 데이터, 자금, 안전에 위험이 있으면 과감히 중단·격리한다.
  2. 고객 영향 다음 – 롤백, 페일오버, 축소된(degraded) 모드 전환 등을 고려한다.
  3. 노이즈 줄이기 – 알람과 커뮤니케이션 빈도를 줄여, 사람이 사고할 여지를 만든다.

또한 커뮤니케이션 미니 런북을 포함한다.

  • 내부 상태 업데이트 주기: 예: P1의 경우 15–30분 간격
  • 최소 상태 메시지 템플릿:
    • 지금 무슨 일이 벌어지고 있는지
    • 누가(어떤 고객/서비스가) 영향받는지
    • 지금 무엇을 하고 있는지
    • 다음 업데이트 예정 시각

그리고 반드시 적는다. “추측 금지. 확인된 사실만 공유한다.”

5. 진단(Diagnosis): 통제력을 잃지 않고 원인을 찾기

목표: 인시던트 전체 통제는 유지한 채로, 근본 원인(root cause)을 파악한다.

이 단계에서는 세세한 내용보다 구조가 더 중요하다.

  • 단순한 조사 루프(investigation loop):
    1. 가설을 세운다.
    2. 안전한 실험 방법을 정한다.
    3. 실험을 수행한다.
    4. 결과를 관찰한다.
    5. 가설을 유지하거나 버린다.
  • 가드레일(안전 장치):
    • “프로덕션에 대한 실험은 IC 승인 없이 진행하지 않는다.”
    • “위험한 변경은 반드시 롤백 경로를 확인한 뒤에만 수행한다.”

온라인 상태라면, 이 단계에서 클라우드 네이티브 컨텍스트가 매우 강력하다.

  • “최신 클라우드 설정 드리프트(config drift)를 확인한다.”
  • “Wiz(또는 동급 도구)에서 영향받은 컴포넌트와 연관된 신규 고위험 노출이 있는지 확인한다.”

종이 위에는 도구 이름에 덜 의존하는, 다소 일반화된 문장으로 써 두되, 실제 상황에서 “아, 지금 Wiz(또는 CSPM)도 같이 봐야겠다”는 행동이 자연스럽게 떠오르도록 해둔다.

6. 복구/해결(Resolution): 안전하게 서비스 정상화

목표: 시스템을 통제된 방식으로 다시 건강한 상태로 되돌린다.

플레이북에는 다음을 포함한다.

  • 복구 결정 트리:
    • “직전 안정 버전으로 안전하게 롤백할 수 있는가?”
    • “건강한 리전/클러스터로 페일오버할 수 있는가?”
    • “임시로 기능 플래그(Feature Flag)로 끌 수 있는 부분이 있는가?”
  • 필수 검증 체크리스트:
    • 핵심 지표가 정상 범위이거나 정상 방향으로 복귀 중인지
    • 해당 인시던트와 연관된 새 알람이 더 이상 발생하지 않는지
    • Synthetic 또는 실제 사용자 여정을 통해 정상 동작을 확인했는지

“끝났다”는 느낌이 아니라 체크리스트로 정의해야 한다.

7. 종료(Closure): 학습을 남기고 진짜로 마무리하기

목표: 티켓, 학습, 책임 정리까지 포함해 수명주기를 온전히 닫는다.

아날로그 형식으로도 다음을 한 장에 담을 수 있다.

  • 같은 종이 안에 들어가는 사후 검토(Post-Incident Review) 요약 양식:
    • 무슨 일이 있었는지(타임라인)
    • 영향(내부/외부)
    • 기여 요인(Contributing factors)
    • 잘한 점
    • 개선해야 할 점
  • 예를 들어 이런 규칙:
    • “P1/P2 인시던트는 5영업일 이내에 사후 검토를 진행해야 하며, 최소 IC + Tech Lead + 제품 담당자가 참석한다.”

그리고 이를 명시적으로 ITIL 스타일 티켓 워크플로와 연결한다.

  • “종료(Closure)를 위해서는 티켓 업데이트, 상태 ‘Resolved’ 변경, 사후 검토 링크, 후속 작업(Task) 생성 및 담당자 지정이 모두 완료되어야 한다.”

구조가 생명이다: 압박 속에서도 버티는 플레이북 아키텍처

좋은 한 장짜리 플레이북은 항목 목록을 넘어선다. **구조(Architecture)**가 있어야 한다. 그래야 대응자들이 즉시 다음을 파악할 수 있다.

  • 지금 인시던트가 어느 단계에 있는지
  • 누가 무엇을 책임지는지
  • 다음에 어떤 결정을 내려야 하는지

실용적인 구조 팁:

  • 앞면: 인시던트 라이프사이클(Logging → Closure)을 큰 다이어그램으로 그리고, 각 단계에 1–3개의 핵심 불릿만 둔다.
  • 뒷면:
    • 역할 정의
    • 심각도 매트릭스
    • 커뮤니케이션 템플릿
    • 인시던트 ID, 주요 시각, 담당자 이름을 적을 수 있는 간단한 메모 영역
  • 단계별로 굵은 제목, 아이콘, 색 띠(인쇄용) 등을 활용해 시각적으로 구분한다.
  • 깊은 들여쓰기나 긴 문단은 피한다.

형식은 지하철 노선도처럼, 내용은 교과서가 아니라 지도에 가깝게 만든다.

클라우드 컨텍스트를 녹이되, 플레이북을 ‘깨지지 않게’ 유지하기

Wiz 같은 클라우드 보안/리스크 툴의 템플릿을 보면, **실시간 환경 컨텍스트(리스크 데이터, 노출, 오구성 등)**가 진단 속도를 크게 높이고 의사결정을 개선할 수 있음을 알 수 있다.

다만 특정 툴 하나에 의존해 플레이북 전체가 깨지는 걸 막으려면 다음이 필요하다.

  • 우선 **일반화된 행동(Action)**부터 정의한다.
    • “영향받은 자산에 대한 클라우드 리스크 포스처를 확인한다.”
    • “관련 계정/프로젝트의 최신 보안 이슈를 검토한다.”
  • 그리고 프린트 가능한 작은 툴 매핑 테이블을 추가한다.
    • 클라우드 리스크 포스처 → Wiz / CSPM X / Security Center Y
    • 로그 → CloudWatch / Stackdriver / Datadog / Splunk
    • 티켓 → Jira / ServiceNow / 내부 티켓 시스템

이렇게 하면, 툴이 바뀌더라도 플레이북의 구조와 행동 흐름은 그대로 유지된다.

실제로 쓰이게 만들기: 연습, 업데이트, 다듬기

겉만 멋진 한 장짜리 플레이북이지만 아무도 안 쓰면, 그건 그냥 벽 장식일 뿐이다.

운영에 녹이려면 다음이 필요하다.

  1. 테이블탑(Tabletop) 연습을 할 때, 일부러 종이와 화이트보드만 써서 인시던트를 흉내 낸다.
  2. 일부 툴을 “다운된 것”으로 가정한 모의 장애를 돌려 본다.
  3. 실제 인시던트가 끝날 때마다 묻는다.
    • 플레이북에 무엇이 빠져 있었는가?
    • 겹치거나 헷갈리는 부분은 무엇이었는가?
  4. 버전을 명시적으로 올린다(예: “Version 1.4 – 2026-02”). 이전 버전 종이는 과감히 수거한다.

베스트 프랙티스:

  • 문장은 짧고, 평이하고, 행동 지향적으로 쓴다.
  • 조직이 실제로 쓰는 현재 워크플로·툴에 맞춘다. “이상향” 기준으로 쓰지 않는다.
  • 최신 버전을 빠르게 인쇄할 수 있는 위치에 저장해 두고, 핵심 위치(네트워크 운영실, 온콜 좌석 등)에 미리 인쇄본을 비치해 둔다.

SRE, 클라우드 네이티브, ITIL을 한 칸에 태우기: 하나의 열차, 하나의 주방

SRE 스타일 온콜, 클라우드 네이티브 인시던트 대응, ITIL 티켓 수명주기는 서로 다른 언어를 쓰는 별개 세계처럼 느껴지기 쉽다. 잘 만든 아날로그 플레이북 하나는 조직에 다음을 강제한다.

  • 모두가 인정하는 공통 라이프사이클을 정의한다.
  • SRE와 ITIL 프로세스 오너 모두가 수긍할 수 있는 방식으로 역할을 명확히 정의한다.
  • 클라우드 중심 개념(리스크 포스처, 노출)을 전통적 상태(New, In Progress, Resolved, Closed 등)와 정렬시킨다.

한 장짜리 플레이북이 제대로 완성되면, 시니어 SRE든 서비스 데스크 분석가든 누구든 간에 같은 종이를 집어 들고:

  • 같은 언어로 대화하고
  • 같은 단계를 따라가며
  • 서로 다른 팀과 툴 사이에서도 매끄럽게 핸드오프할 수 있다.

결론: 터널에 들어가기 전에 ‘열차 주방’을 만들어라

아날로그 장애 열차 주방을 만드는 시점은, 이미 터널 안에 들어간 뒤가 아니라 그 전이어야 한다.

다음과 같은 한 장짜리 플레이북을 설계하자.

  • 로깅, 트리아지, 할당, 대응, 진단, 복구, 종료까지 전체 단계를 명시적으로 따라간다.
  • 대시보드와 봇이 아니라, 펜과 전화만 있어도 쓸 수 있다.
  • 클라우드·리스크 컨텍스트를 활용하되, 여기에 의존하지는 않게 설계한다.
  • SRE, 클라우드 네이티브, ITIL 실무를 하나의 일관된 플로우로 묶어 낸다.

그리고 이 플레이북이 지루할 정도로 익숙해질 때까지 연습하고, 현실이 기대를 배반할 때마다 계속 업데이트하라.

다음 대형 장애가 터지고 툴들이 줄줄이 쓰러질 때, 그 한 장짜리 종이가 조직이 가진 인프라 중 가장 가치 있는 자산이 될지도 모른다.

아날로그 장애 ‘열차 주방’: 모든 장애 단계에서 통하는 한 장짜리 플레이북 만들기 | Rain Lag