Ⅴ-14. 컴퓨터 시스템 장애 재발 방지와 대응 개선 분석

장애 재발 방지와 대응 개선 분석

1. 장애 복구 이후에 필요한 분석 장애

컴퓨터 시스템에서 장애가 발생하면 우선 서비스를 정상 상태로 복구하는 것이 중요하다.

그러나 서비스가 다시 작동한다고 해서 장애 대응이 모두 끝난 것은 아니다.

장애가 발생한 원인을 확인하지 않거나 원인에 맞지 않는 조치를 적용하면 동일하거나 유사한 문제가 반복될 수 있다. 또한 장애 원인을 제거했더라도 탐지와 복구가 늦어지는 문제가 남아 있다면 다음 장애에서도 서비스 중단 시간이 길어질 수 있다.

따라서 장애 대응은 다음과 같은 단계로 구분하여 분석할 필요가 있다.

• 장애 발생 및 증상 확인
• 긴급 복구와 서비스 정상화
• 장애 원인 및 발생 조건 분석
• 원인 제거와 재발 방지 조치
• 탐지·분석·복구 과정의 개선
• 개선 효과 검증 및 후속 조치

이 과정의 목적은 장애를 한 번 해결하는 데 그치지 않고, 같은 문제가 다시 발생할 가능성과 장애 발생 시의 영향을 함께 줄이는 것이다.

2. 긴급 복구와 재발 방지는 구분해야 한다

장애 대응 과정에서는 당장 서비스를 복구하기 위한 조치와 장애의 재발 가능성을 낮추기 위한 조치를 구분해야 한다.

구분	주요 목적	적용 사례
긴급 복구	중단된 서비스의 정상화	서비스 재시작, 장애 장비 전환
원인 제거	장애를 직접 유발한 원인 해소	결함 수정, 고장 부품 교체
재발 방지	같은 원인이 다시 발생할 가능성 감소	자원 관리 개선, 결함 검증 강화
대응 개선	장애 탐지·분석·복구 시간 단축	경보 기준 조정, 복구 절차 표준화

예를 들어 메모리 부족으로 서비스가 중단된 경우 서비스를 재시작하면 일시적으로 정상화될 수 있다.

그러나 메모리 사용량이 계속 증가하는 원인이 남아 있다면 같은 장애가 다시 발생할 수 있다.

따라서 복구 조치가 효과적이었는지와 장애 원인이 제거되었는지는 별도로 확인해야 한다.

3. 장애 원인과 개선 조치를 연결한다

재발 방지 조치는 장애 원인과 직접적으로 연결되어야 한다.

장애가 발생했다는 사실만으로 일반적인 점검이나 자원 증설을 반복하면 실제 원인을 해결하지 못할 수 있다.

확인된 원인	적절한 개선 방향	추가 확인 사항
저장장치 용량 부족	불필요한 데이터 정리, 용량 관리 기준 개선	증가 추세와 확보 효과
메모리 누수	프로그램 결함 수정, 메모리 회수 동작 검증	장시간 실행 시 메모리 사용 추세
네트워크 연결 불안정	연결 경로와 장비 상태 점검, 장애 구간 개선	패킷 손실과 연결 복구 여부
잘못된 설정 변경	설정 검증 및 변경 승인 절차 개선	변경 이력과 적용 결과
과도한 요청 집중	처리 용량과 요청 분산 방식 개선	부하 증가 시 응답시간과 오류율

여기서 중요한 것은 장애 증상과 원인을 동일하게 취급하지 않는 것이다.

CPU 사용률이 높았다는 사실은 관찰된 상태일 수 있지만, 그 자체만으로 장애의 근본 원인이라고 단정할 수는 없다.

장애 당시의 로그, 자원 사용 기록, 설정 변경 이력, 오류 발생 순서 등을 함께 확인하여 원인과 결과의 관계를 판단해야 한다.

4. 근본 원인과 기여 요인을 구분한다

장애는 하나의 원인만으로 발생하기도 하지만 여러 조건이 겹치면서 발생하기도 한다.

예를 들어 메모리 누수로 사용 가능한 메모리가 점차 줄어들고 결국 메모리 부족으로 서비스가 중단되었다면 메모리 누수는 직접적인 원인 후보가 된다.

여기에 메모리 사용량 감시가 부족했거나 경보 기준이 적절하지 않았다면 장애를 늦게 발견하게 된 기여 요인일 수 있다.

이때 다음 사항을 구분하여 기록할 수 있다.

• 근본 원인: 장애를 발생시킨 결함이나 조건을 설명하는 원인
• 직접적인 장애 조건: 원인이 실제 서비스 중단으로 이어지게 된 상태
• 기여 요인: 장애의 발생 가능성이나 영향, 탐지 지연을 키운 조건
• 대응상의 문제: 원인 확인이나 복구를 늦추거나 어렵게 만든 문제

이 구분은 모든 장애에 동일하게 적용되는 고정된 분류라기보다, 원인과 대응 과정을 명확하게 설명하기 위한 분석 기준이다.

원인을 확인할 때는 장애 발생 시점에 함께 나타난 현상만으로 결론을 내리지 않아야 한다.

시간 순서, 재현 가능성, 관련 기록, 조치 전후의 변화 등을 근거로 가설을 검증해야 한다.

원인이 확정되지 않았다면 추정 원인과 확인된 원인을 구분하여 기록하는 것이 바람직하다.

그래야 불확실한 판단에 근거하여 잘못된 개선 조치를 적용하는 일을 줄일 수 있다.

5. 장애 탐지 시간을 줄인다

재발 방지는 동일한 장애가 다시 발생하지 않도록 하는 것뿐 아니라, 장애가 발생할 가능성을 조기에 발견하고 영향이 커지기 전에 대응할 수 있도록 하는 것도 포함한다.

이를 위해 시스템의 정상 상태와 변동 범위를 파악하고 장애와 관련된 지표를 지속적으로 관찰해야 한다.

주요 관찰 대상은 다음과 같다.

• CPU와 메모리 사용량
• 저장장치 용량 및 입출력 지연
• 네트워크 오류와 패킷 손실
• 서비스 응답시간과 오류율
• 시스템 로그와 반복되는 오류 기록
• 요청량, 처리량, 대기열 증가 추세

다만 모든 지표에 일률적으로 임계값을 적용하는 것은 적절하지 않을 수 있다.

시스템의 특성, 업무 시간, 정상적인 부하 변동 등을 고려하여 경보 조건을 설정해야 한다.

또한 경보가 발생했다는 사실만으로 장애가 확정되는 것은 아니다.

경보 이후 실제 장애로 이어졌는지, 조기에 대응할 수 있었는지, 불필요한 경보가 반복되지는 않았는지를 함께 확인해야 한다.

탐지 시간은 다음과 같이 구분하여 평가할 수 있다.

이상 징후 발생 → 경보 발생 → 담당자 인지 → 대응 시작

각 단계의 지연을 따로 확인하면 단순히 “경보가 늦었다”는 평가보다 어느 지점에서 대응이 지연되었는지 구체적으로 확인할 수 있다.

단, 실제 장애의 시작 시점을 명확하게 확인할 수 없는 경우에는 그 한계도 함께 기록해야 한다.

6. 장애 복구 시간을 줄인다

장애의 재발을 완전히 막기 어려운 환경에서는 장애가 발생했을 때 신속하고 안정적으로 복구할 수 있는 대응 체계도 필요하다.

복구 시간을 줄이기 위해 다음 사항을 개선할 수 있다.

• 장애 유형별 초기 점검 절차 표준화
• 로그와 시스템 상태 정보의 신속한 수집
• 복구 절차 및 이전 장애 사례의 문서화
• 담당자별 역할과 보고 체계 명확화
• 백업 및 대체 시스템의 정상 작동 여부 검증
• 복구 후 데이터 정합성과 서비스 정상 상태 확인

여기서 복구 시간을 단순히 서비스가 다시 실행될 때까지의 시간으로만 판단하면 부족할 수 있다.

서비스가 실행되더라도 데이터가 손상되었거나 주요 기능이 정상적으로 작동하지 않는다면 완전한 복구라고 보기 어렵다.

따라서 복구 과정에서는 최소한 다음 단계를 구분할 필요가 있다.

장애 인지 → 대응 시작 → 서비스 복구 → 주요 기능 확인 → 데이터 및 상태 검증 → 정상 운영 전환

이를 통해 단순히 “서비스가 켜졌다”가 아니라 실제로 정상 운영 상태가 회복되었는지를 확인할 수 있다.

7. 장애 대응 과정에서 어디가 늦었는지 분석한다

장애 대응을 개선하려면 장애가 발생했다는 사실만 보는 것이 아니라 대응 과정 전체를 시간 순서로 확인해야 한다.

예를 들어 다음과 같이 기록할 수 있다.

단계	확인 내용
이상 발생	최초 이상징후가 나타난 시점
탐지	시스템 또는 담당자가 이상을 인지한 시점
분석 시작	원인 분석이 시작된 시점
원인 후보 확인	주요 원인 후보가 좁혀진 시점
복구 조치	실제 복구 작업이 시작된 시점
서비스 복구	서비스가 다시 작동한 시점
정상 상태 확인	주요 기능과 데이터 상태를 확인한 시점

이렇게 구분하면 전체 장애 시간이 길었다는 사실만으로 끝나지 않고 탐지가 늦었는지, 분석이 늦었는지, 복구 작업이 늦었는지를 구분할 수 있다.

8. 장애 대응 절차 자체의 문제를 찾는다

장애의 원인이 시스템 내부에 있더라도 대응 과정에서 문제가 있었다면 같은 장애가 발생했을 때 다시 대응이 늦어질 수 있다.

예를 들어 다음과 같은 문제가 있을 수 있다.

• 필요한 로그를 찾는 방법이 정리되어 있지 않음
• 담당자에게 필요한 권한이 없음
• 장애별 초기 점검 절차가 없음
• 담당자 간 역할이 불분명함
• 복구 절차가 문서화되어 있지 않음
• 과거 장애 사례를 활용하지 못함
• 경보가 너무 많아 중요한 경보를 놓침
• 복구 후 정상 상태 확인 절차가 없음

이러한 문제는 장애의 직접적인 원인과는 다를 수 있지만 장애의 영향과 복구 시간을 증가시키는 대응상의 문제가 될 수 있다.

따라서 재발 방지 분석에서는 시스템 자체뿐 아니라 대응 체계도 함께 평가해야 한다.

9. 개선 조치가 실제로 효과가 있었는지 확인한다

개선 조치를 적용했다고 해서 자동으로 재발 방지가 완료되는 것은 아니다.

개선 후 실제로 문제가 줄어들었는지를 확인해야 한다.

예를 들어 메모리 누수를 수정했다면 단순히 프로그램을 수정했다는 사실만 기록할 것이 아니라,

• 장시간 실행 시 메모리 증가가 멈췄는가
• 동일한 조건에서 문제가 재현되지 않는가
• 메모리 부족 경보가 감소했는가
• 서비스 응답시간이 안정되었는가

등을 확인할 필요가 있다.

즉,

개선 조치 적용 → 결과 관찰 → 효과 확인

의 과정이 필요하다.

10. 재현 또는 검증 환경에서 개선 효과를 확인한다

가능하다면 실제 운영 환경에 바로 적용하기 전에 별도의 검증 환경에서 개선 효과를 확인하는 것이 좋다.

예를 들어 특정 부하에서 장애가 발생했다면 유사한 조건을 구성하여 개선 전후의 상태를 비교할 수 있다.

개선 전 → 장애 발생

개선 후 → 동일 조건에서 장애 미발생

이라는 결과가 반복적으로 확인된다면 개선 조치의 효과를 뒷받침하는 근거가 될 수 있다.

다만 실제 운영 환경과 검증 환경의 차이가 있다면 그 차이도 기록해야 한다.

검증 환경에서 문제가 발생하지 않았다는 사실만으로 운영 환경에서 재발 가능성이 완전히 제거되었다고 단정해서는 안 된다.

11. 재발 방지와 장애 영향 최소화를 함께 고려한다

모든 장애를 완전히 제거할 수 있는 것은 아니다.

따라서 재발 방지와 함께 장애가 발생하더라도 영향 범위를 줄이는 방법을 고려해야 한다.

예를 들어 다음과 같은 방법이 있다.

• 이중화 구성
• 장애 장비 자동 전환
• 서비스 격리
• 부하 분산
• 백업 및 복구 체계 강화
• 장애 발생 영역의 확산 방지
• 복구 가능한 상태의 지속적인 확보

이 경우 목표는 단순히

“장애가 발생하지 않게 한다.”

에만 있는 것이 아니라,

“장애가 발생하더라도 서비스 전체로 확산되지 않게 하고, 필요한 기능을 빠르게 복구한다.”

는 방향으로 확장된다.

12. 동일 장애와 유사 장애를 함께 검토한다

재발 방지 조치를 평가할 때는 완전히 동일한 장애만 대상으로 보면 부족할 수 있다.

같은 근본 원인이나 동일한 취약한 조건이 다른 형태의 장애를 만들 수도 있기 때문이다.

예를 들어 특정 저장장치의 오류가 한 서비스에서는 응답 지연으로 나타났지만 다른 서비스에서는 데이터 처리 실패로 나타날 수 있다.

따라서 개선 조치가 특정 증상만 제거한 것인지, 아니면 같은 원인에서 파생될 수 있는 다른 장애 가능성까지 줄였는지를 확인하는 것이 중요하다.

13. 개선 조치의 우선순위를 정한다

모든 개선사항을 동시에 적용하기 어려운 경우에는 위험과 효과를 기준으로 우선순위를 정할 수 있다.

개선 대상	판단 기준
발생 가능성 감소	동일 장애가 다시 발생할 가능성을 얼마나 줄이는가
영향 감소	장애가 발생해도 서비스 영향 범위를 얼마나 줄이는가
탐지 개선	이상을 얼마나 빨리 발견할 수 있는가
분석 개선	원인 파악 시간을 얼마나 줄이는가
복구 개선	정상 상태로 돌아가는 시간을 얼마나 줄이는가
검증 가능성	개선 효과를 실제 데이터로 확인할 수 있는가
유지 가능성	운영 과정에서 지속적으로 관리할 수 있는가

이를 통해 단순히 개선사항을 많이 만드는 것이 아니라 실제로 위험을 줄이는 조치부터 적용할 수 있다.

14. 개선 결과를 기록하고 다음 장애 분석에 활용한다

장애 대응이 끝난 후에는 무엇을 고쳤는지만 기록해서는 부족하다.

다음과 같은 정보를 함께 남겨두면 이후 유사 장애를 분석할 때 활용할 수 있다.

• 장애 증상
• 확인된 원인
• 발생 조건
• 기여 요인
• 긴급 복구 방법
• 원인 제거 조치
• 재발 방지 조치
• 탐지 과정의 문제
• 분석 과정의 문제
• 복구 과정의 문제
• 개선 후 검증 결과
• 아직 남아 있는 불확실성
• 추가로 필요한 조치

이러한 기록이 쌓이면 과거 장애 사례가 단순한 기록이 아니라 다음 장애를 더 빠르게 분석하기 위한 지식으로 활용될 수 있다.

15. 재발 방지 조치는 다시 검토되어야 한다

한 번 적용한 개선 조치가 영구적으로 효과를 유지한다고 보기는 어렵다.

시스템 구성, 소프트웨어 버전, 사용자 수, 업무량, 데이터 규모 등이 변하면 과거에 효과적이었던 대책이 더 이상 충분하지 않을 수 있다.

따라서 중요한 개선 조치는 일정 기간 후 다시 확인할 필요가 있다.

예를 들어

개선 적용 → 일정 기간 관찰 → 새로운 장애 또는 이상 발생 여부 확인 → 개선 효과 재평가

와 같은 방식으로 관리할 수 있다.

이 과정은 재발 방지를 일회성 작업이 아니라 지속적인 운영 개선 과정으로 만든다.

16. 장애 대응 개선의 전체 분석 흐름

장애가 발생한 이후의 분석은 다음과 같은 흐름으로 정리할 수 있다.

장애 발생
→ 긴급 복구
→ 원인 및 발생 조건 분석
→ 근본 원인·직접 조건·기여 요인 구분
→ 원인 제거
→ 재발 방지 조치
→ 탐지·분석·복구 과정 평가
→ 장애 영향 최소화 대책 검토
→ 개선 조치 적용
→ 재현·모니터링을 통한 효과 검증
→ 결과 기록
→ 후속 재검토

이 흐름에서 중요한 것은 장애가 복구되는 순간 분석을 끝내지 않는 것이다.

복구는 장애 대응의 끝이 아니라 개선 분석의 시작점이 될 수 있다.

17. Ⅴ-14 핵심정리

컴퓨터 시스템 장애에서 중요한 것은 단순히 서비스를 다시 작동시키는 것이 아니다.

장애가 왜 발생했는지 확인하고, 같은 원인의 재발 가능성을 줄이며, 다시 장애가 발생하더라도 더 빨리 탐지하고 분석하고 복구할 수 있도록 대응 체계를 개선해야 한다.

핵심은 다음과 같이 정리할 수 있다.

원인 확인 → 원인 제거 → 재발 가능성 감소 → 탐지 개선 → 분석 개선 → 복구 개선 → 영향 최소화 → 효과 검증 → 결과 기록

그리고 모든 장애가 완전히 제거될 수 있는 것은 아니므로,

“장애가 다시 발생하지 않게 하는 것”과 “장애가 발생해도 피해를 작게 만드는 것”을 함께 고려해야 한다.

결국 재발 방지 분석의 목적은 과거의 장애를 단순히 기록하는 것이 아니라,

다음 장애가 발생할 가능성을 낮추고, 발생하더라도 더 빨리 발견하고, 더 정확하게 원인을 찾고, 더 안정적으로 복구할 수 있는 시스템으로 개선하는 것이다.

장애 재발 방지와 대응 개선 분석