장애 대응 매뉴얼은 왜 필요한가: “그때 가서”가 가장 위험한 이유

장애는 예고 없이 옵니다. 더 정확히 말하면, 예고는 있었는데 아무도 못 봤던 경우가 많습니다. 알람이 울리고, 문의가 쌓이고, 서비스가 느려지고, 누군가는 말합니다. “지금 장애 맞나요?” 그리고 5분 뒤에는 더 중요한 질문이 나옵니다. “이제 누가 뭘 하죠?”

이때 팀을 살리는 건 ‘실력 좋은 한 명’이 아니라 흐름입니다. 누가 리드하고, 어디부터 확인하고, 어떤 기준으로 심각도를 나누고, 언제 공지를 내고, 어디까지 복구하면 “정상”으로 볼지. 이런 게 정리되어 있으면 상황이 빨리 안정됩니다. 그 정리의 형태가 바로 장애 대응 매뉴얼입니다.

 

 

 

매뉴얼이 필요한 첫 번째 이유: 장애 때는 생각보다 판단력이 빨리 떨어집니다

장애 상황에서는 정보가 불완전합니다. “어디서부터 터진 건지”가 안 보이고, 여러 사람이 동시에 말하고, 알람이 우르르 울립니다. 그때는 숙련자도 실수를 합니다. 더군다나 야간, 휴일, 인수인계가 애매한 상황이라면 더 위험합니다.

매뉴얼은 이때 ‘뇌를 대신해주는 체크리스트’ 역할을 합니다. 복잡한 결정을 대신 내려주지는 않지만, 최소한 “지금 이걸 먼저 확인하자”를 잡아줍니다. 장애 대응에서 가장 무서운 건 시간이 새는 겁니다. 매뉴얼은 그 시간을 줄여줍니다.

 

 

두 번째 이유: 역할이 정해지지 않으면 모두가 같은 일을 하게 됩니다

매뉴얼이 없는 팀의 흔한 패턴이 있습니다. 전원이 한 곳에 모여서 같은 대시보드를 보고, 같은 로그를 보고, 같은 이야기를 합니다. 그런데 정작 해야 할 일은 분업이 필요합니다. 누군가는 범위를 좁혀야 하고, 누군가는 롤백 가능성을 확인해야 하고, 누군가는 운영/CS와 커뮤니케이션을 해야 합니다.

장애 대응 매뉴얼에는 보통 “누가 리드(조율)하고, 누가 조사하고, 누가 공지 담당인지” 같은 역할 분배가 들어갑니다. 이런 역할이 바로 서면, 팀은 훨씬 덜 흔들립니다. 여기서 차이가 큽니다.

 

 

세 번째 이유: “무엇이 정상인가”가 정의돼 있어야 끝낼 수 있습니다

복구가 더딘 팀을 보면, 기술이 부족해서라기보다 “언제 끝난 걸로 보지?”가 애매한 경우가 많습니다. 로그인은 되는데 결제는 느리다, 일부 지역만 안 된다, 특정 버전 앱만 터진다 같은 상황에서는 “정상”의 기준이 필요합니다.

매뉴얼이 있으면 정상 기준을 빠르게 맞출 수 있습니다. 예를 들어 핵심 지표(에러율, 응답시간, 결제 성공률)가 특정 범위로 돌아오면 1차 복구로 보고, 이후 관찰 시간을 갖는다 같은 식입니다. 이런 기준이 없으면 사람들은 불안해서 계속 손을 대다가 2차 사고를 내기도 합니다.

 

 

네 번째 이유: 커뮤니케이션이 매뉴얼이 없을 때 제일 망가집니다

장애가 길어질수록 “언제 복구돼요?”라는 질문이 내부에서 폭발합니다. 운영팀, CS, 세일즈, 경영진까지 모두 묻습니다. 그때 개발팀이 기술 설명을 길게 하면 오히려 혼란이 커집니다. 사람들은 원인보다 “현재 영향”과 “다음 업데이트 시간”이 필요합니다.

매뉴얼은 공지 템플릿과 공유 리듬을 만들어줍니다. 예를 들어 15분마다 상황 업데이트, 영향 범위/우회 방법/다음 공유 시점 포함 같은 규칙이 있으면, 개발팀은 조사에 집중할 수 있고 조직 전체가 덜 불안해집니다. 장애는 기술 문제이기도 하지만, 조직의 불안을 다루는 문제이기도 합니다.

 

 

다섯 번째 이유: ‘재발 방지’는 매뉴얼이 있어야 루틴이 됩니다

장애가 지나가면 다들 지칩니다. “이제 끝났다”는 마음이 커져서 사후 정리를 미루기 쉽습니다. 그런데 사후 정리가 없으면 같은 장애가 다른 형태로 다시 옵니다. 로그가 부족했던 문제, 알람이 약했던 문제, 배포 절차가 허술했던 문제는 그대로 남습니다.

장애 대응 매뉴얼은 사후정리(포스트모템)까지 포함하는 경우가 많습니다. 타임라인, 영향 범위, 원인과 촉발 요인, 개선 작업과 담당자까지 남기게 만드는 구조입니다. 이렇게 남겨두면 시간이 지나도 팀이 배웁니다. 결과적으로 장애가 줄어드는 게 아니라, 장애의 비용이 줄어듭니다.

 

 

매뉴얼이 있다고 해서 모든 장애를 막지는 못합니다

여기서 오해가 하나 생깁니다. “매뉴얼이 있으면 장애가 안 나나요?” 아닙니다. 장애는 계속 납니다. 하지만 차이는 있습니다. 매뉴얼이 있는 팀은 장애가 나도 “흔들리는 시간이 짧습니다.” 그리고 복구 후에 같은 실수를 반복할 확률이 줄어듭니다.

즉, 매뉴얼은 완벽한 방패가 아니라 안전벨트에 가깝습니다. 사고가 ‘안 나게’ 하는 게 아니라, 사고가 났을 때 피해를 줄이고 회복을 빠르게 하는 역할입니다.

 

 

실무에서 매뉴얼에 보통 들어가는 것들

장애 대응 매뉴얼이라고 해서 거창할 필요는 없습니다. 오히려 짧고 바로 찾히는 문서가 실무에서 오래 살아남습니다. 보통 아래 요소가 있으면 충분히 효과가 납니다.

• 장애 판단 기준(무슨 지표가 어느 정도면 장애로 볼지)
• 초기 대응 순서(5분 안에 할 것들)
• 역할 분배(리드/조사/공지 담당)
• 자주 쓰는 조치(롤백, 기능 차단, 트래픽 제한 등)
• 공지 템플릿(영향/조치/다음 공유 시간)
• 사후 정리 체크리스트(타임라인/원인/재발 방지)

이 정도만 있어도 장애가 터졌을 때 “무엇부터?”가 줄어듭니다. 결국 매뉴얼은 문서가 아니라 습관을 만드는 장치입니다.

참고로 사고 대응과 사후 분석 문화는 Google SRE 자료가 큰 틀을 잡는 데 도움이 됩니다.
Google SRE Book – Incident Response

 

---

 

 

장애 대응 매뉴얼이 필요한 이유는 장애를 막기 위해서가 아니라, 장애가 났을 때 팀이 덜 흔들리고 더 빨리 회복하기 위해서입니다. 판단이 흐려지는 순간에 순서를 잡아주고, 역할을 나누고, 공지를 안정시키고, 사후 정리를 루틴으로 만들어줍니다. 결국 매뉴얼은 “그때 가서”가 아니라 “미리 정리해둔 팀”이 덜 고생하게 만드는 장치입니다.