Ⅱ-6. 컴퓨터 시스템 장애 대응 절차와 복구 전략 분석

컴퓨터 시스템에서 장애가 발생하면 단순히 서버를 재시작하거나 고장 난 장비를 교체하는 것만으로 대응이 끝나는 것은 아니다.

장애를 발견하고, 상태를 확인하고, 영향을 제한하고, 원인을 판단한 뒤, 적절한 방법으로 복구하고, 정상 동작을 검증하는 과정이 이어져야 한다.

따라서 장애 대응 능력을 평가하려면 각각의 대응 단계가 어떻게 연결되는지와 함께 각 단계에 어느 정도의 시간이 소요되는지를 함께 살펴봐야 한다.

1. 장애 대응의 기본 단계

일반적인 장애 대응은 다음과 같은 흐름으로 구성할 수 있다.

장애 발생 → 장애 탐지 → 상태 확인·진단 → 영향 범위 판단 → 장애 격리 → 복구 방법 결정 → 복구 작업 → 서비스 정상 여부 검증 → 대응 결과 기록

여기서 중요한 것은 모든 장애가 동일한 순서와 동일한 시간으로 처리되는 것은 아니라는 점이다.

자동으로 장애를 탐지하고 이중화 시스템이 즉시 전환하는 경우도 있지만, 원인 확인을 위해 로그와 장비 상태를 직접 확인해야 하는 경우에는 진단 시간이 길어질 수 있다.

따라서 장애 대응 시간은 단순한 하나의 시간이 아니라 각 대응 단계에서 발생하는 시간의 합으로 보는 것이 정확하다.

2. 1단계 — 장애 탐지

장애 대응의 시작은 장애가 발생했다는 사실을 알아내는 것이다.

장애 탐지는 다음과 같은 방법으로 이루어질 수 있다.

• 모니터링 시스템의 경보
• 서버·네트워크 장비의 상태 감시
• 서비스 응답시간 증가
• 오류율 증가
• 사용자 장애 신고
• 로그 및 이벤트 발생
• 이중화 시스템의 장애 감지

이 단계에서 발생하는 시간이 탐지시간이다.

탐지시간 = 장애 발생 시점부터 장애를 인지한 시점까지의 시간

예를 들어 장애가 10시 00분에 발생했지만 모니터링 시스템이 10시 02분에 장애를 감지했다면 탐지시간은 2분이다.

따라서 장애 대응 성능을 높이려면 단순히 복구 작업을 빠르게 하는 것뿐 아니라 장애를 얼마나 빨리 발견하는가도 중요하다.

3. 2단계 — 상태 확인과 진단

장애를 발견했다고 해서 바로 복구 작업을 시작할 수 있는 것은 아니다.

먼저 실제 장애인지, 일시적인 오류인지, 어느 구성요소에서 문제가 발생했는지를 확인해야 한다.

확인 대상은 다음과 같다.

• CPU·메모리·스토리지 상태
• 네트워크 연결 상태
• 운영체제 로그
• 애플리케이션 로그
• 시스템 이벤트
• 장비 상태 및 오류 코드
• 프로세스와 서비스 상태
• 최근 변경 작업
• 다른 시스템과의 연관성

이 단계에서 발생하는 시간이 진단시간이다.

진단시간 = 장애 인지 후 원인과 상태를 판단하기까지의 시간

여기서 주의할 점은 진단시간이 길다고 해서 반드시 대응이 느린 것은 아니라는 것이다.

복잡한 장애를 충분히 확인하지 않고 성급하게 복구하면 장애가 다시 발생하거나 다른 시스템으로 영향이 확대될 수 있기 때문이다.

따라서 진단시간은 무조건 줄이는 것이 아니라 정확한 판단에 필요한 범위까지 관리하는 것이 중요하다.

4. 3단계 — 영향 범위 판단

장애 원인을 확인하는 과정과 동시에 장애가 어느 범위까지 영향을 미치고 있는지도 판단해야 한다.

예를 들어 특정 서버 한 대의 문제인지, 동일한 네트워크 구간 전체의 문제인지, 여러 서비스가 공통으로 사용하는 저장장치나 인증 시스템의 문제인지에 따라 대응 방법이 달라진다.

이 단계에서는 다음을 확인한다.

• 장애가 발생한 구성요소
• 영향을 받은 서비스
• 영향을 받을 가능성이 있는 서비스
• 공통 의존성 존재 여부
• 이중화 구성의 정상 여부
• 장애 전파 가능성

영향 범위를 잘못 판단하면 복구 작업의 방향 자체가 잘못될 수 있다.

따라서 장애를 발견한 시간과 장애의 범위를 판단한 시간은 구분해서 관리할 필요가 있다.

5. 4단계 — 장애 격리

장애가 다른 시스템으로 확대될 가능성이 있다면 해당 장애 영역을 분리해야 한다.

예를 들어 다음과 같은 조치가 가능하다.

• 장애 서버를 서비스 그룹에서 분리
• 장애 네트워크 포트 차단
• 문제가 있는 프로세스 중지
• 장애 장비의 트래픽 우회
• 문제가 있는 노드를 클러스터에서 제외
• 장애 구간과 정상 구간 분리

이 단계에서 중요한 시간은 격리시간이다.

격리시간 = 장애 격리가 필요하다고 판단한 시점부터 실제 격리가 완료된 시점까지의 시간

격리시간이 길어지면 장애가 다른 구성요소로 확산될 가능성이 커질 수 있다.

반대로 너무 넓은 범위를 차단하면 정상 서비스까지 영향을 받을 수 있다.

따라서 격리는 단순히 빠르게 차단하는 것이 아니라 필요한 범위만 신속하게 분리하는 것이 핵심이다.

6. 5단계 — 복구 방법 결정

장애를 격리한 이후에는 어떤 방법으로 서비스를 복구할 것인지 결정한다.

복구 방법은 장애의 원인과 시스템 구조에 따라 달라질 수 있다.

• 서비스 재시작
• 프로세스 재기동
• 서버 재부팅
• 이중화 시스템으로 전환
• 장애 장비 교체
• 백업 데이터 복원
• 이전 버전으로 롤백
• 설정 변경 또는 원상복구
• 다른 서버로 서비스 이전

이 단계에서 발생하는 시간이 의사결정시간이다.

의사결정시간 = 복구 방법을 결정하기 시작한 시점부터 실제 복구 방법이 결정된 시점까지의 시간

복구 방법을 잘못 선택하면 복구 작업 자체가 장애를 더 크게 만들 수 있다.

따라서 이 단계에서는 단순히 “가장 빨리 복구되는 방법”보다 현재 장애 상태에서 가장 안전하게 서비스를 정상화할 수 있는 방법을 선택해야 한다.

7. 6단계 — 복구 작업

복구 방법이 결정되면 실제 복구 작업을 수행한다.

예를 들어 서버 재기동, 장애 장비 교체, 백업 복원, 서비스 전환 등의 작업이 이루어진다.

이 단계에서 발생하는 시간이 복구작업시간이다.

복구작업시간 = 복구 작업을 실제로 수행한 시간

복구작업시간을 줄이기 위해서는 다음과 같은 준비가 중요하다.

• 표준 복구 절차
• 자동화된 전환
• 예비 장비 확보
• 최신 백업
• 복구 테스트
• 명확한 작업 권한
• 장애별 대응 매뉴얼

특히 자동화된 이중화 시스템에서는 복구작업시간 자체가 매우 짧아질 수 있다.

그러나 자동 전환이 이루어졌다는 사실만으로 서비스 복구가 완전히 끝났다고 판단해서는 안 된다.

8. 7단계 — 서비스 정상 여부 검증

복구 작업이 끝난 후에는 실제 서비스가 정상적으로 동작하는지 확인해야 한다.

단순히 서버가 켜졌거나 프로세스가 실행되고 있다는 것만으로는 충분하지 않다.

다음 항목을 확인할 필요가 있다.

• 서비스 응답 여부
• 오류율 정상화
• 주요 기능 정상 동작
• 데이터 정합성
• 네트워크 연결
• 연계 시스템 정상 여부
• 사용자 요청 처리 여부
• 모니터링 지표 정상화

이 단계에서 발생하는 시간이 서비스 검증시간이다.

서비스 검증시간 = 복구 작업 완료 후 서비스가 정상 상태임을 확인하기까지의 시간

따라서 서버가 복구된 시간과 서비스가 복구된 시간은 다를 수 있다.

이 차이를 구분하지 않으면 실제 복구 성능을 지나치게 좋게 평가할 수 있다.

9. 장애 대응 단계와 시간 기준의 일치

장애 대응 단계와 시간 기준을 연결하면 다음과 같이 정리할 수 있다.

대응 단계	주요 작업	대응 시간 기준	시간의 시작과 종료
장애 탐지	장애 발생 인지	탐지시간	장애 발생 → 장애 인지
상태 확인·진단	상태 및 원인 확인	진단시간	장애 인지 → 원인·상태 판단
영향 범위 판단	영향 서비스·구간 확인	진단 과정에 포함 가능	상태 확인 → 영향 범위 판단
장애 격리	장애 영역 분리	격리시간	격리 판단 → 격리 완료
복구 방법 결정	복구 방법 선택	의사결정시간	복구 판단 시작 → 방법 결정
복구 작업	재시작·전환·복원·교체	복구작업시간	복구 시작 → 복구 작업 완료
서비스 검증	기능·데이터·연계 확인	검증시간	복구 완료 → 정상 서비스 확인

여기서 영향 범위 판단은 별도의 고정된 시간 항목으로 반드시 분리해야 하는 것은 아니다.

실제 운영에서는 상태 확인·진단 과정에 포함되어 진행될 수 있기 때문이다.

중요한 것은 각 단계의 명칭보다 시간을 어디서 시작하고 어디서 끝내는지를 명확하게 정의하는 것이다.

10. 전체 장애 대응시간 계산

앞의 단계를 시간으로 연결하면 전체 장애 대응시간을 다음과 같이 볼 수 있다.

전체 장애 대응시간 = 탐지시간 + 진단시간 + 격리시간 + 의사결정시간 + 복구작업시간 + 서비스 검증시간

예를 들어 다음과 같은 상황을 가정할 수 있다.

• 탐지시간: 2분
• 진단시간: 8분
• 격리시간: 3분
• 의사결정시간: 2분
• 복구작업시간: 10분
• 서비스 검증시간: 5분

그러면

전체 장애 대응시간 = 2 + 8 + 3 + 2 + 10 + 5 = 30분

이렇게 계산하면 단순히 “복구하는 데 10분이 걸렸다”고 평가하는 것보다 실제 장애가 발생한 순간부터 서비스가 정상적으로 확인될 때까지 어떤 과정에서 시간이 소비되었는지를 알 수 있다.

11. MTTR과 장애 대응시간을 혼동하지 않기

앞에서 MTTR을 별도로 다루었다면 여기서는 용어를 불필요하게 중복해서 사용할 필요가 없다.

장애 대응 과정에서는 각 단계의 시간을 분해해서 보는 것이 목적이다.

예를 들어 전체 대응시간이 30분이라고 하더라도 실제 복구작업은 10분밖에 걸리지 않을 수 있다.

이 경우 문제는 복구 작업 자체보다 다음과 같은 앞단의 과정에 있을 수 있다.

• 장애를 늦게 발견함
• 원인 파악에 시간이 오래 걸림
• 영향 범위 판단이 늦음
• 복구 방법 결정이 지연됨

따라서 장애 대응 개선에서는 “복구 작업을 빨리하자”만 보는 것이 아니라 전체 시간 중 어느 단계가 가장 큰 비중을 차지하는지를 확인해야 한다.

12. 자동화와 수동 대응의 시간 차이

동일한 장애라도 자동화 수준에 따라 단계별 시간이 크게 달라질 수 있다.

예를 들어 자동 장애 탐지와 자동 페일오버가 구성되어 있다면 탐지와 복구 전환에 필요한 시간이 짧아질 수 있다.

반면 사람이 모니터링 화면을 확인하고 서버에 접속한 후 장애 원인을 판단하고 수동으로 서비스를 전환해야 한다면 여러 단계에서 시간이 누적될 수 있다.

따라서 자동화의 효과는 단순히 “자동화했다”는 사실보다 어떤 대응 단계의 시간을 줄였는가로 평가하는 것이 더 정확하다.

13. 장애 대응 시간을 줄이는 방법

전체 장애 대응시간을 줄이려면 각 단계별 병목을 찾아야 한다.

탐지시간이 길다면

• 모니터링 기준 개선
• 장애 감지 임계값 조정
• 알림 체계 개선
• 주요 서비스 상태 감시 강화

진단시간이 길다면

• 로그 통합
• 장애별 점검 절차 표준화
• 상태 정보 수집 자동화
• 원인 분석에 필요한 데이터 확보

격리시간이 길다면

• 장애 구간 사전 정의
• 자동 트래픽 우회
• 장애 노드 자동 제외
• 격리 절차 표준화

의사결정시간이 길다면

• 장애 유형별 대응 기준 마련
• 복구 우선순위 정의
• 담당자 권한 명확화
• 복구 방법 사전 검증

복구작업시간이 길다면

• 자동화
• 예비 장비 확보
• 백업 및 복원 절차 개선
• 표준 복구 절차 마련

서비스 검증시간이 길다면

• 정상 상태의 기준값 정의
• 자동 서비스 점검
• 주요 기능 테스트 자동화
• 데이터 정합성 확인 절차 마련

14. 장애 대응 기록을 다음 장애에 활용하기

장애 대응이 끝난 후에는 단순히 “복구 완료”라고 기록해서는 안 된다.

최소한 다음과 같은 정보를 남기는 것이 좋다.

• 장애 발생 시각
• 장애 탐지 시각
• 장애 인지 시각
• 원인 확인 시각
• 격리 시각
• 복구 방법 결정 시각
• 복구 시작 및 완료 시각
• 서비스 정상 확인 시각
• 장애 원인
• 영향을 받은 서비스
• 수행한 조치
• 예상과 달랐던 부분

이 자료가 축적되면 다음 장애에서 어느 단계가 반복적으로 지연되는지 확인할 수 있다.

결국 장애 대응 기록은 단순한 사후 보고서가 아니라 다음 장애의 대응시간을 줄이기 위한 운영 데이터가 된다.

15. 최종 판단 — 장애 대응은 ‘복구 속도’만으로 평가할 수 없다

컴퓨터 시스템의 장애 대응 능력을 판단할 때는 “몇 분 만에 복구했는가?”만 보는 것으로 충분하지 않다.

장애가 발생한 순간부터 정상 서비스가 확인되는 순간까지의 과정을 단계별로 나누어야 한다.

장애 탐지 → 진단 → 격리 → 복구 결정 → 복구 작업 → 서비스 검증

그리고 각 단계에서 시간이 얼마나 소요되었는지를 확인해야 실제 병목을 찾을 수 있다.

특히 다음 네 가지를 확인하면 장애 대응 구조를 훨씬 명확하게 판단할 수 있다.

우리 시스템은 장애를 얼마나 빨리 발견하는가?

발견한 뒤 원인과 영향 범위를 얼마나 빨리 판단하는가?

복구 방법을 결정하고 실제 복구하는 데 어느 단계에서 시간이 가장 많이 걸리는가?

복구 작업이 끝난 뒤 서비스가 실제로 정상화되었다는 것을 무엇으로 확인하는가?

결국 좋은 장애 대응 체계는 단순히 빨리 복구하는 체계가 아니라, 장애 발생부터 정상 서비스 확인까지 각 단계의 시간을 관리할 수 있는 체계라고 볼 수 있다.

핵심정리

• 장애 대응시간은 하나의 시간이 아니라 탐지 → 진단 → 격리 → 의사결정 → 복구 → 검증 과정의 시간으로 나누어 봐야 한다.
• 서버가 복구된 시간과 서비스가 정상화된 시간은 같지 않을 수 있다. 따라서 마지막 검증 단계까지 확인해야 실제 복구를 판단할 수 있다.