종이만으로 버티는 인시던트 등대 레일맵: 근무 중 도구가 탈선해도 라이브 장애를 안내하는 방법

근무 도중이다. 티켓 처리, 대시보드 모니터링, Slack 알림을 동시에 juggling 하고 있는데, 갑자기 모든 게 미끄러지듯 무너진다.

• 모니터링 월이 전부 까맣게 죽는다.
• 인시던트 봇이 더 이상 응답하지 않는다.
• 상태 페이지에 접속이 안 된다.
• 공들여 만든 플레이북이 있는 내부 위키조차 내려가 있다.

장애는 이제 고객만이 아니라, 원래라면 장애를 해결하는 데 써야 할 도구들까지 같이 날려버리고 있다.

이럴 때 계속 움직일 수 있는 팀은, 화려한 옵저버빌리티 스택을 가진 팀이 아니다. 미리 **‘종이 전용 인시던트 등대 레일맵’**을 준비해 둔 팀이다. 어떤 도구가 날아가도 동작하는, 단순하고 튼튼한 오프라인 인시던트 대응 계획(IRP, Incident Response Plan) 말이다.

이 글에서는 그런 레일맵을 어떻게 만드는지 살펴본다. 특정 업계에 종속되지 않고(industry-agnostic), SRE 관점이 녹아 있으며, 종이로 뽑아도 쓸 수 있는 IRP를 만들어, 디지털 세상이 한순간에 암흑이 되어도 라이브 장애를 처리할 수 있게 하는 방법이다.

왜 인시던트 대응 계획은 프린터 잉크를 견뎌야 하는가

**인시던트 대응 계획(IRP)**은 예기치 않은 장애를 처리하기 위한 플레이북이다. 전체 장애, 성능 저하, 보안 사고 등 다양한 상황에 대응한다. 이론상 모든 조직에는 IRP가 있다. 그러나 실제로 많은 계획서는 이런 상태다.

• 장애 때마다 접속이 안 되는 위키에만 박혀 있다.
• “Tool X에서 이 버튼을 눌러…”처럼 특정 도구에 지나치게 종속되어, 정작 Tool X가 장애의 일부일 때는 쓸 수가 없다.
• 현장 대응자보다 **감사(Audit)**를 위해 작성되어 지나치게 길고 실전성이 떨어진다.

쓸모 있는 IRP에는 세 가지 핵심 속성이 있다.

1. 명확하고 반복 가능할 것 – 스트레스가 극심할 때도 단계별로 따라갈 수 있어야 한다.
2. 업계 무관(Industry-agnostic)일 것 – 특정 기술 스택·업계·툴셋을 전제로 하지 않아야 한다.
3. 인쇄·오프라인 가능할 것 – 네트워크가 죽어도 동작해야 한다.

IRP를 **GPS가 아닌 ‘철도 노선도(rail map)’**로 생각해보자. GPS는 멋지고 편리하다. 하지만 휴대폰 배터리가 나가거나 신호가 끊기면 무용지물이다. 반면 철도 노선도는 그리 화려하진 않지만, 새벽 3시에 손전등 불빛 하나만 있어도 쓸 수 있다.

업계와 무관하게 통하는 IRP의 뼈대

팀과 업계를 가리지 않고 유연하게 쓰이려면, IRP는 도구가 아니라 역할, 의사결정, 흐름에 초점을 맞춰야 한다.

탄탄한, 업계-무관 IRP 템플릿에는 보통 다음 요소들이 들어간다.

1. 트리거와 트리아지(Triage)

• 무엇이 인시던트인가? SEV-1, SEV-2처럼 명확한 심각도(severity) 기준이 필요하다.
• 누가 인시던트를 선언할 수 있는가? 온콜이면 누구나? 팀 리드만?
• 처음 5분 체크리스트 (종이 친화적으로 구성):
  • 탐지 시각과 보고자를 기록한다.
  • 심각도를 선언한다.
  • 인시던트 커맨더(IC, Incident Commander)를 지정한다.
  • 커뮤니케이션 채널을 만든다. (무전, 전화 브리지, 백업 채팅, 아니면 실제 ‘워룸’ 모이기 등)

2. 역할과 책임

도구 장애 상황에서도 유지될 수 있는 방식으로 역할을 정의하자.

• 인시던트 커맨더(IC) – 최종 의사결정을 책임지고, 모두가 흐름을 따라가게 조율한다.
• 커뮤니케이션 리드 – 내부 이해관계자와 고객에게 상태 업데이트를 전달한다.
• 오퍼레이션/테크 리드 – 기술적인 조사와 대응을 조정한다.
• 스크라이브(Scribe) – 수행한 액션, 의사결정, 타임스탬프를 기록한다. (펜 + 종이면 충분하다.)

이 역할들은 나중에 각 조직의 팀 구조(Ops, SRE, NOC, 고객지원 등)에 맞게 매핑하면 된다.

3. 조사 흐름(툴-중립적 Investigation Flow)

“Dashboard X를 열어 Panel Y를 확인한다” 대신 이렇게 서술하자.

• “서로 다른 두 개 이상의 독립적인 데이터 소스를 사용해 영향 범위를 검증한다.”
• “문제가 로컬 vs. 지역 vs. 글로벌 수준 중 어디에 해당하는지 판단한다.”
• “최근 24시간 내 배포, 설정 변경, 인프라 변경 등 최근 변경 이력을 확인한다.”

이 표현들은 헬스케어, 금융, SaaS, 제조, 교통 등 어느 업계에서도 유효하다.

4. 커뮤니케이션 리듬(Communication Cadence)

• 초기 공지: 인시던트 선언 후 X분 이내.
• 정기 업데이트: SEV-1은 Y분마다, SEV-2는 Z분마다 등.
• 채널: 1차 + 백업 (예: Slack + 전화 브리지, 이메일 + SMS 리스트 등)
• 대상: 리더십, 지원팀, 고객, 규제 기관 등 (해당하는 경우)

패턴은 한 번 정의하면 되고, 구체적인 매체는 상황에 따라 달라질 수 있다.

5. 복구 & 사후 대응(Post-Incident)

• 복구 선언 기준.
• ‘진화 진압’에서 ‘안정화’ 단계로 넘기는 인수인계 절차.
• 사후 리뷰(Postmortem/사후 분석)를 위한 필수 기록 항목.
• RCA(근본 원인 분석) 타임라인 (예: 초안 48시간 이내 작성).

이 부분도 의도적으로 업계-무관하게 유지한다.

대시보드가 죽었을 때: 종이와 오프라인 사본의 힘

디지털 도구들이 인시던트 도중에 멈춰 버리면, 다음과 같은 복합 문제가 생긴다.

• 런북에 접근할 수 없다.
• 시스템을 볼 수 있는 대시보드가 사라진다.
• 협업·조율을 위한 채팅이나 티켓 시스템이 멈춘다.

이때 종이 또는 오프라인 버전의 IRP와 핵심 런북이 진짜 ‘등대’가 된다.

• 모든 온콜 자리마다 인쇄된 IRP 소책자를 비치한다.
• 오프라인 PDF를 사전 동기화된 로컬 머신이나 보안 USB 드라이브에 저장해 둔다.
• 어떤 인시던트에서도 처음 15분을 버티기 위한 라미네이팅된 퀵 레퍼런스 카드를 만들어 둔다.

종이 IRP가 전체 시스템 다이어그램을 완벽히 담으려 할 필요는 없다. 대신, 다음을 제공해야 한다.

• 사람들이 익숙하고 연습된 흐름으로 다시 중심을 잡게 해 주는 기준점.
• 체크리스트와 의사결정 트리.
• 중요한 백업 연락처와 커뮤니케이션 채널 목록.

그리고 팀이 종이 버전으로 실제 연습을 해 본 적이 없다면, 그건 진짜 백업이라고 보기 어렵다. 최소 분기 1회는 **‘종이만 쓰는(paper-only) 인시던트 드릴’**을 돌려보자. 이때는 이런 설정으로 진행한다.

• 네트워크는 불안정하다고 가정.
• 내부 대시보드와 위키에는 접근 불가.
• 채팅 도구는 지연·끊김이 심하다고 가정.

이렇게 해보면 오프라인 준비에서 어떤 부분이 비어 있는지 금세 드러난다.

내부 모니터링을 외부 시그널로 보완하기

내부 도구가 비틀거려도, 대부분의 경우 넓은 의미의 인터넷은 여전히 살아 있다. 이때 외부 상태 확인 도구들이 임시로 현실을 보여주는 창이 될 수 있다.

Downdetector 같은 서비스 활용

Downdetector 같은 도구는 주요 서비스에 대한 사용자 신고 기반 장애 정보를 집계한다. 이를 통해 다음을 할 수 있다.

• 서드파티 제공자(클라우드, DNS, SaaS, ISP 등)에 장애가 있는지 확인한다.
• “우리만 문제인가, 모두가 겪는 중인가?” 같은 사용자 체감 영향도를 가늠한다.
• 특정 의존성이 분명히 장애 중일 때, 그에 맞게 커뮤니케이션 우선순위를 조정한다.

종이 IRP에는 다음과 같은 내용을 넣을 수 있다.

• 주요 서드파티 제공자 목록.
• 각 제공자의 공식 상태 페이지(URL) 위치.
• 사용자 신고 기반 도구(Downdetector 등)로 교차 확인하라는 리마인더.

속도 측정 및 번들 연결성 체크 도구

응답자가 “시스템이 느려요”, “API 요청이 타임아웃나요”라고 말할 때, 빠르게 다음을 구분해야 한다.

• 로컬 이슈 (와이파이, 사내 네트워크, VPN, 특정 ISP 문제 등)
• 지역 이슈 (ISP 피어링 문제, 특정 리전 클라우드 장애 등)
• 글로벌 이슈 (제공자 전체 장애 등)

대역폭 측정(스피드 테스트)과 주요 서비스 도달성 체크를 묶어서 제공하는 앱/도구는 이런 상황에서 강력하다. 이를 통해 다음을 할 수 있다.

• 연결성 문제가 우리 쪽 문제인지, 바깥쪽(인터넷/ISP/클라우드) 문제인지 빠르게 가늠한다.
• 실제로는 ISP 장애인데 애플리케이션 코드만 괜히 파고드는 낭비를 줄인다.

IRP에는 이런 문장을 명시적으로 적어 두자.

“네트워크 이슈가 의심될 때는, 애플리케이션 문제로 단정 짓기 전에 **서로 다른 네트워크(예: 사무실 vs. 모바일 핫스팟)**에서 두 개 이상의 독립적인 속도/상태 체크를 수행한다.”

이 단계들은 따라가기 쉽고, 종이에 적어 두기도 쉽다.

SRE의 역할: ‘신뢰성’을 1급 시민으로 만들기

**Site Reliability Engineering(SRE)**의 목표는 시스템이 다음을 만족하도록 만드는 것이다.

• 사용자가 필요로 할 때 **가용(Available)**할 것.
• 실제 트래픽 하에서도 **성능(Performance)**이 유지될 것.
• 문제를 이해하고 고칠 수 있을 만큼 **관측 가능(Observable)**할 것.

SRE의 실천은 인시던트 대응에 규율을 부여한다.

• **SLO(Service Level Objective)**가 무엇이 ‘충분히 좋음(good enough)’인지 정의한다.
• **에러 버짓(Error Budget)**이 안정성을 위해 언제 변경 속도를 늦춰야 하는지 판단하게 돕는다.
• 런북과 플레이북은 반복 가능한 대응을 문서화한다.
• 블레이멀리스(blameless) 사후 리뷰는 장애를 학습 기회로 전환한다.

실제 라이브 장애 상황에서 SRE는 보통 다음 역할을 한다.

• (도구가 살아 있을 때) 메트릭과 로그를 해석한다.
• (네트워크, DB, 배포 등) 가능성이 높은 장애 도메인을 좁혀 나간다.
• 기술적 대응을 이끌거나 지원한다.

그러나 도구가 모두 다운되었을 때도 SRE 원칙은 여전히 유효하다.

• 항상 사용자 영향에 초점을 둔다. (완전 중단인지, 특정 기능/경로만 저하인지 등)
• 장애 도메인(Failure domain) 관점으로 생각한다. (격리가 가능한지, 페일오버 가능한지 등)
• 위험한 ‘한방(big bang)’ 변경보다 안전하고 되돌릴 수 있는 변경을 우선한다.

이러한 SRE 원칙을, 그래프나 대시보드 링크가 아니라 휴리스틱과 체크리스트로 종이 IRP에 직접 녹여 넣어야 한다. Grafana 링크 하나로 끝내서는 안 된다. 그 대시보드가 장애 중일 수도 있으니 말이다.

SRE 원칙과 종이 기반 IRP를 통합하기

진짜 인시던트 등대 레일맵을 만들려면, 다음 두 세계의 장점이 모두 필요하다.

• SRE가 제공하는 엄격함과 신뢰성 중심 사고방식.
• 종이가 제공하는 단순함과 회복력.

이를 통합하는 방법은 다음과 같다.

1. 업계-무관 IRP 템플릿부터 시작한다.

   • Detect → Triage → Communicate → Mitigate → Recover → Review 같은 단계(Phase)를 정의한다.
   • 지시는 특정 도구가 아닌 “결과와 의도”에 집중해 툴-중립적으로 적는다.

2. 여기에 SRE 특유의 가이던스를 덧입힌다.

   • 영향도 평가 체크리스트: “어떤 SLO들이 깨졌을(혹은 깨질) 가능성이 높은가?”
   • 의사결정 규칙: “에러율이 X 이상이 Y분간 지속되면 심각도를 상향 조정한다.”
   • 안전 가드레일: “피크 시간대에는 DB 스키마 변경보다 기능 플래그 롤백을 우선한다.”

3. 프린트 가능한 최소 버전을 설계한다.

   • 처음 15분에 집중하는 1페이지짜리 ‘퀵 스타트’.
   • 추가 페이지에는 역할 정의, 커뮤니케이션 템플릿, 에스컬레이션 경로를 적는다.
   • 타임스탬프, 주요 의사결정, 관찰 사항을 쓸 수 있는 여백을 둔다.

4. 오프라인 대안을 명시적으로 문서화한다.

   • 채팅이 죽으면 → 전화 브리지 사용.
   • 대시보드가 죽으면 → 외부 상태 도구와 간단한 synthetic 체크 활용.
   • 위키가 죽으면 → 인쇄된 런북과 다이어그램으로 대체.

5. 카오스 드릴/게임데이에서 실제로 테스트한다.

   • ‘툴 장애’를 시나리오에 포함시킨다.
   • 종이 IRP와 소수의 외부 도구(Downdetector, 스피드 테스트 등)만 허용한 채 인시던트를 풀어 보게 한다.

응답자들이 이 종이 기반 레일맵을 실전에서 여러 번 써봐서 믿을 수 있게 되었을 때, 비로소 그 문서는 어떤 벤더, 대시보드, 채팅 플랫폼보다 오래 가는 진짜 자산이 된다.

결론: 도구 자체를 단일 장애 지점(SPOF)으로 만들지 말 것

장애는 피할 수 없다. 진짜 질문은, 당신의 대응 프로세스 자체가 얼마나 쉽게 부서지는지다.

다음과 같은 순간에 인시던트 대응이 무너진다면:

• 내부 위키가 내려가는 순간,
• 상태 페이지가 열리지 않는 순간,
• 채팅 플랫폼이 버벅이는 순간,

당신의 도구는 이미 **또 하나의 단일 장애 지점(Single Point of Failure)**이 되어 버린 것이다.

종이 전용 인시던트 등대 레일맵—명확하고, 업계와 무관하며, SRE 관점이 녹아 있고, 인쇄와 연습이 되어 있는 IRP—은 다음을 가능하게 해 준다.

• 조율(Coordinate)
• 커뮤니케이션(Communicate)
• 건전한 의사결정(Make sound decisions)

…을, 평소에 쓰던 도구들이 근무 도중 탈선하더라도 계속 할 수 있게 해 준다.

지금 시간을 들여 다음을 준비하자.

• 튼튼하고 툴-중립적인 IRP를 설계하고,
• 종이와 오프라인 버전을 만들어 배포하고,
• SRE 원칙과 Downdetector·스피드 테스트·서비스 상태 체크 같은 외부 시그널을 녹여 넣고,
• 이 자료들만 가지고도 자연스럽게 대응할 수 있을 때까지 반복 훈련하라.

다음 대형 장애가 터져 모든 화면이 암전되더라도, 당신의 팀은 맨손으로 날뛰지 않을 것이다. 펜 한 자루, 전화 한 대, 종이에 비추는 손전등 한 줄기 빛만으로도 따라갈 수 있는, 잘 설계되고 충분히 연습된 레일맵을 손에 쥐고 움직일 것이다.