장애 대응 런북은 "무엇을 미리 결정해 두었는가"로 트랙션이 갈린다. 2025년 공개 사례들을 보면 MTTA·MTTR이 줄어든 쪽은 역할 배정과 완화 조치를 수치와 함께 미리 문서화해 둔 경우였다. 반대로 런북 문서가 존재해도 복구 판정 기준이 숫자로 없으면 결과는 똑같이 느려진다.
장애 대응 런북, 있어도 왜 작동하지 않나?
런북이 있어도 작동하지 않는 이유는 대부분 "문서는 있지만 판단 기준이 없기" 때문이다. 절차 목록은 길게 정리돼 있는데, 정작 "지금이 장애인가 아닌가", "복구됐다고 볼 수 있는가"를 판단할 숫자가 빠져 있는 경우가 많다.
- 장애 선언 기준이 지표(오류율·지연시간·결제 실패율)가 아니라 담당자 직감에 의존하면 선언 자체가 늦어진다.
- 역할(인시던트 커맨더·기술 담당·커뮤니케이션 담당)을 사전에 정하지 않으면 같은 로그를 여러 명이 동시에 들여다보는 중복이 생긴다.
- 완화 조치와 원인 규명 순서가 뒤섞이면 "원인을 찾을 때까지 복구를 미루는" 지연이 발생한다.
- 복구 판정이 "알림이 꺼졌다"는 기준뿐이면 재발을 복구로 착각한다.
가장 흔한 함정은 런북을 "절차 나열"로만 쓰는 것이다. 실제로 장애를 티켓 종료 건수로만 평가한 사례에서는 실제 비즈니스 영향이 기록에 반영되지 않았다는 점이 문제로 지적됐다출처. 런북은 절차표가 아니라 "이 수치가 이 값을 넘으면 이 행동을 한다"는 조건문의 묶음이어야 한다. 조건문이 빠진 런북은 장애가 터진 순간 다시 논의를 시작하게 만든다.
장애 초반, 무엇을 먼저 확정해야 하나?
초반에 먼저 확정해야 할 것은 선언 기준과 역할 배정이다. 서비스별 핵심 지표(오류율, 지연시간, 로그인 실패율 등)를 먼저 정의하고, "몇 분 이상 지속되면 장애로 선언한다"는 조건을 명시해 두지 않으면 담당자마다 판단이 갈린다. 심각도는 사용자 영향, 매출 영향, 데이터 손상 가능성, 복구 예상 시간으로 나눠 P1~P3 등급을 미리 정해 두는 편이 실무에서 빠르다.
역할 배정도 이 단계에서 끝내야 한다. 2025년 incident.io 사례에서는 채널 생성, 역할 할당, 알림까지 수동으로 조율하는 데 20~30분이 걸리던 과정이 문제로 제시됐고, 이를 자동화한 런북이 대응 방식으로 쓰였다출처. 역할이 없으면 누가 고객에게 공지를 보내고 누가 롤백 버튼을 누를지가 장애 도중에 결정되는데, 이 결정 자체가 지연의 큰 부분을 차지한다. 영향 범위 확인도 초반에 함께 처리해야 한다. 전체 장애인지 특정 리전·테넌트·API 버전 장애인지를 분리하지 않으면 불필요한 전면 롤백으로 이어질 수 있다. 한 공개 사례에서는 사용자 신고로 발견되는 장애 비율이 22%에서 3%로 줄고, 사전 탐지 비율이 78%에서 97%로 올라간 결과가 제시됐다출처.
원인을 모르는 상태에서 무엇부터 멈춰야 하나?
원인을 모르는 상태에서는 완화 조치부터 실행하고 원인 규명은 뒤로 미뤄야 한다. 우선순위는 일반적으로 "사용자 영향 축소 → 서비스 복구 → 근본 원인 확인" 순이다. 캐시 우회, 읽기 전용 전환, 문제 기능 비활성화, 트래픽 분산 같은 완화 조치는 원인이 확정되지 않아도 적용할 수 있도록 런북에 별도로 적어 둬야 한다. 공개된 사례에서는 데이터베이스 커넥션 풀이 고갈된 장애에 대해 커넥션 풀을 재시작해 서비스를 먼저 복구하고, 쿼리 최적화와 용량 계획은 후속 조치로 분리해 처리했다출처.
최근 변경 사항 대조도 이 단계에서 함께 진행된다. 배포, 설정 변경, 스키마 변경, 인증서 교체, 트래픽 급증, 외부 공급자 장애를 시간순으로 나열해 영향 지표와 겹치는 시점이 있는지 확인한다. 겹치면 원인을 완전히 확정하기 전이라도 롤백이나 트래픽 차단을 검토하는 쪽이 안전하다. 자동화된 완화도 이 단계에 포함될 수 있는데, 대상·최대 재시도 횟수·중단 조건·승인 필요 여부를 명확히 해야 한다. 컨테이너 오케스트레이션 환경에서 Pod 장애를 자동 재시작해 MTTR을 20분에서 3분 미만으로 낮췄다는 사례가 공개됐지만, 이는 "한 번만 실행", "5분 내 재발하면 수동 전환" 같은 제한 조건이 함께 있었던 경우다출처.
복구 판정은 언제, 무엇으로 내리나?
복구 판정은 알림이 사라진 시점이 아니라 지표가 일정 시간 유지된 시점으로 내려야 한다. 오류율, p95·p99 지연시간, 성공률, 큐 적체, 결제 성공률, 사용자 신고량 같은 지표를 정상화 이후 일정 시간 관찰하고, "정상화 후 15분간 핵심 지표 유지"처럼 수치 조건을 런북에 명시해야 재발을 복구로 착각하지 않는다.
고객 공지 시점도 복구 판정과 맞물린다. 내부적으로 원인이 확정되지 않았더라도 영향과 임시 조치를 먼저 공지할 수 있도록 템플릿을 준비해 두는 편이 낫다. 발생 시각, 영향 기능, 현재 조치, 다음 업데이트 시각, 복구 여부를 포함하고 "원인 조사 중"이라는 표현만 반복하지 않는 것이 중요하다. MTTD·MTTA·MTTR을 글이나 보고서에서 제시할 때는 측정 시작·종료 시점을 고정해야 한다는 점도 함께 확인해야 한다출처. 2026년 기준으로 공개된 사례들은 대체로 공급자가 작성한 고객 사례이므로, 업계 평균이 아니라 "해당 사례의 결과"로 읽는 편이 안전하다.
알림이 사라지면 장애가 끝난 걸까?
아니다. 알림이 꺼졌다는 것은 모니터링 임계값을 더 이상 넘지 않는다는 뜻이지, 핵심 지표가 정상 범위로 돌아와 일정 시간 유지됐다는 뜻이 아니다. 커넥션 풀을 재시작해 오류율이 순간적으로 떨어지면 알림은 바로 사라지지만, 몇 분 뒤 동일한 패턴으로 재발하는 경우가 실무에서 드물지 않다.
이 오해가 특히 문제가 되는 지점은 복구 완료를 공지한 뒤 재발했을 때다. 고객에게는 "복구됐다"는 메시지가 먼저 나가고, 이후 재장애가 발생하면 신뢰 손상이 이중으로 발생한다. 런북에 "정상화 후 일정 시간 핵심 지표 유지"라는 조건을 숫자로 넣어 두면, 공지 시점 자체가 뒤로 밀리더라도 재발로 인한 두 번째 공지를 피할 수 있다. 중견 금융 서비스 기업 사례에서는 알림과 런북·대시보드를 직접 연결한 뒤 MTTA가 22분에서 3.5분으로, MTTR이 58분에서 19분으로 줄었고 조치가 필요한 알림 비율은 31%에서 89%로 늘었다출처. 이 수치는 알림이 "더 많이 울려서"가 아니라 "복구 판정 기준이 더 명확해져서" 줄어든 결과로 읽는 편이 맞다.
런북이 어긋났을 때 무엇을 다시 설계하나?
런북이 어긋났을 때 다시 설계해야 할 것은 절차 자체가 아니라 판단 조건의 숫자다. 사후 분석(포스트모템)에서 "이 조건이었다면 더 빨리 선언했을까", "이 지표가 있었다면 더 빨리 완화했을까"를 되짚고, 런북의 임계값과 체크리스트 항목을 고쳐 쓰는 작업이 실질적인 복구 단계다.
최소한 아래 항목은 사후 분석 때마다 갱신 대상으로 점검하는 편이 좋다. 장애 ID와 선언 시각, 탐지 경로와 MTTD, 최초 인지·응답 시각과 MTTA, 심각도와 영향 범위, 담당자 역할, 최근 배포·설정 변경 목록, 완화 조치와 자동화 실행·중단 조건, 롤백 승인자, 고객 공지와 업데이트 시각, 복구 판정 지표와 관찰 기간, 데이터 정합성 확인, 사후 분석 담당자와 완료 기한이다. 이 항목들은 한 번 정해 두면 끝나는 것이 아니라, 장애가 날 때마다 숫자가 틀렸던 지점을 찾아 다시 쓰는 대상이다. AI 거버넌스 운영 사례에서는 12주 프로그램 동안 MTTD 7분 미만, MTTR 2.5시간 미만을 목표로 두고 실제 P3 사례의 MTTR이 1시간 44분으로 보고됐는데, 이 역시 목표치와 실측치를 나란히 놓고 런북 조건을 계속 고쳐 쓴 결과로 봐야 한다출처.
핵심 정리
- 런북이 작동하지 않는 가장 흔한 이유는 절차는 있는데 선언·완화·복구 판정에 쓸 수치 조건이 없기 때문이다.
- 초반에는 선언 기준과 역할 배정을 동시에 끝내야 수동 조율 시간(공개 사례 기준 20~30분)을 줄일 수 있다출처.
- 원인 규명보다 완화 조치를 먼저 실행하는 순서를 런북에 명시해야 복구가 지연되지 않는다.
- 복구 판정은 알림 소멸이 아니라 "정상화 후 일정 시간 핵심 지표 유지"라는 수치 조건으로 내려야 한다.
- 공급자가 공개한 수치(MTTR 37% 감소, 알림 78% 감소 등)는 업계 평균이 아니라 해당 사례의 조건부 결과로 읽어야 한다.