Ⅴ-10. 자동화된 컴퓨터 장애 진단과 원인 예측 분석

컴퓨터 시스템의 장애가 복잡해질수록 사람이 모든 로그와 성능 데이터를 직접 확인하면서 원인을 찾는 방식에는 한계가 생긴다.

CPU, 메모리, 저장장치, 네트워크, 프로세스, 운영체제, 애플리케이션 등의 상태가 동시에 변할 수 있고, 하나의 장애가 여러 계층으로 전파되면서 최종적으로 나타나는 증상과 실제 원인이 서로 다른 위치에 존재할 수 있기 때문이다.

따라서 자동화된 장애 진단의 목적은 단순히 이상값을 찾아내는 것이 아니다.

장애와 관련된 데이터를 자동으로 모으고, 시간 순서를 정리하며, 구성요소 간 관계를 분석하고, 여러 원인 후보를 비교하여 사람이 우선적으로 확인해야 할 대상을 좁혀주는 것이 핵심이다.

즉, 자동화는 사람의 판단을 없애는 기술이라기보다 장애 원인을 찾는 데 필요한 증거를 빠르게 정리하고 판단 범위를 줄여주는 분석 체계로 이해하는 것이 적절하다.

1. 자동화된 장애 진단이 필요한 이유

단순한 시스템에서는 장애가 발생했을 때 오류 메시지 하나만 확인해도 원인을 어느 정도 추정할 수 있다.

하지만 서버, 데이터베이스, 스토리지, 네트워크, 가상화 환경 등이 연결된 시스템에서는 하나의 증상이 여러 원인에서 나타날 수 있다.

예를 들어 시스템 응답시간이 증가했다고 하더라도 다음과 같은 가능성을 검토해야 한다.

• CPU 처리량 증가
• 메모리 압박
• 저장장치 응답시간 증가
• 특정 프로세스 이상
• 운영체제 또는 드라이버 문제
• 네트워크 지연
• 애플리케이션 내부 처리 지연
• 하드웨어 상태 변화
• 최근 구성 또는 소프트웨어 변경

사람이 이 모든 데이터를 장애가 발생할 때마다 처음부터 확인한다면 시간이 오래 걸리고 중요한 전조를 놓칠 가능성도 있다.

자동화의 필요성은 바로 이 지점에서 발생한다.

많은 데이터를 사람이 일일이 찾는 구조에서, 시스템이 먼저 관련 증거를 정리하고 사람이 판단하는 구조로 바꾸는 것이다.

2. 자동화 장애 진단은 단순한 이상 탐지와 다르다

자동화된 장애 진단을 단순히 임계값을 넘으면 경고를 보내는 시스템으로 생각해서는 안 된다.

이상 탐지는 진단의 출발점일 뿐이다.

예를 들어 CPU 사용률이 급격하게 증가했다면 시스템은 이를 이상 상태로 표시할 수 있다.

하지만 다음 단계에서 확인해야 할 질문은 달라진다.

• CPU 증가가 장애보다 먼저 발생했는가?
• 어떤 프로세스가 CPU를 사용했는가?
• 동일한 시점에 I/O나 메모리 상태가 변했는가?
• 특정 서비스의 응답시간도 증가했는가?
• 과거 장애에서도 같은 패턴이 나타났는가?
• 정상적인 작업량 증가에서도 동일한 현상이 나타나는가?

따라서 자동화 진단은 다음과 같이 확장된다.

이상 탐지 → 관련 데이터 수집 → 시간축 정렬 → 의존관계 분석 → 원인 후보 생성 → 증거 비교 → 후보 우선순위화 → 사람의 검증

이 차이를 이해하는 것이 자동화 장애 진단의 출발점이다.

3. 정상 상태를 알아야 자동화된 이상 판단이 가능하다

자동화 시스템이 장애를 판단하려면 먼저 정상 상태가 무엇인지 알아야 한다.

CPU 사용률 80%라는 동일한 수치도 시스템에 따라 의미가 달라질 수 있다.

평상시에도 높은 처리량을 유지하는 서버에서는 정상적인 상태일 수 있지만, 평소 30~40% 수준에서 운영되던 시스템에서 특정 프로세스와 함께 급격하게 증가했다면 추가적인 조사가 필요할 수 있다.

따라서 자동화 진단에서는 단순한 고정 임계값만 사용하는 것보다 다음과 같은 정보를 함께 고려하는 것이 중요하다.

• 평상시 값의 범위
• 시간대별 패턴
• 요일별 패턴
• 작업량과 사용자 수
• 정기 작업 여부
• 최근 시스템 변경
• 과거 장애 패턴
• 다른 성능 지표의 변화

결국 자동화 시스템이 판단해야 하는 것은 단순히

“값이 높은가?”

가 아니라

“현재 상태가 해당 시스템의 정상적인 변화 범위에서 벗어났는가?”

에 가깝다.

4. 장애 이전의 변화를 자동으로 추적한다

장애가 발생한 순간의 데이터만 분석하면 이미 발생한 결과를 확인하는 데 그칠 수 있다.

원인을 찾기 위해서는 장애가 발생하기 전부터 어떤 변화가 시작되었는지를 함께 확인해야 한다.

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

정상 상태 → 저장장치 응답시간 증가 → I/O 대기 증가 → 서비스 처리 지연 → 사용자 응답시간 증가 → 장애 발생

사용자가 보는 최종 증상은 서비스 지연이지만 실제 분석 대상은 그보다 앞선 상태 변화까지 포함한다.

따라서 자동화 진단에서는 장애 발생 시점만 잘라서 보는 것이 아니라 장애 전후의 일정한 시간 구간을 함께 분석하여 최초 이상과 최종 증상의 관계를 찾는 과정이 필요하다.

5. 시간 순서를 이용해 원인 후보를 좁힌다

장애 분석에서 시간 정보는 중요한 판단 근거다.

예를 들어 다음과 같은 기록이 있다고 하자.

시간	관찰된 변화
10:01	메모리 사용량 증가
10:03	저장장치 I/O 증가
10:05	서비스 응답시간 증가
10:06	서비스 오류 발생

이 기록을 통해 메모리 변화가 먼저 발생했다는 사실은 확인할 수 있다.

하지만 먼저 발생했다는 사실만으로 원인이라고 확정할 수는 없다.

10:00에 별도의 구성 변경이 있었거나 외부 요청량이 급증했다면 다른 설명이 가능하기 때문이다.

따라서 자동화 시스템은 시간 순서를 이용해 후보를 좁히되,

시간적 선후관계 ≠ 인과관계

라는 원칙을 유지해야 한다.

시간 정보는 원인을 확정하는 도구라기보다 어디부터 조사해야 하는지를 좁히는 강력한 단서로 활용하는 것이 적절하다.

6. 구성요소 의존관계를 이용해 장애 전파 경로를 분석한다

컴퓨터 시스템에서는 하나의 구성요소 문제가 상위 계층의 증상으로 나타날 수 있다.

예를 들어 애플리케이션의 파일 처리 과정은 다음과 같이 연결될 수 있다.

애플리케이션 → 운영체제 → 파일시스템 → I/O 경로 → 저장장치 드라이버 → 저장장치

이때 사용자가 애플리케이션의 멈춤을 경험했다고 해서 애플리케이션 자체가 원인이라고 볼 수는 없다.

저장장치의 응답 지연이 상위 계층으로 전달되어 애플리케이션이 멈춘 것처럼 보일 수도 있기 때문이다.

자동화 진단에서는 이러한 의존관계를 사전에 정의하거나 운영 데이터를 통해 파악하여 장애가 발생했을 때 관련 구성요소의 범위를 빠르게 좁힐 수 있다.

중요한 것은 단순히 **“어떤 구성요소가 연결되어 있는가?”**를 보는 것이 아니라,

“어떤 구성요소의 이상이 어떤 경로를 통해 최종 증상으로 나타날 수 있는가?”

를 분석하는 것이다.

7. 로그와 성능 데이터를 하나의 시간축으로 연결한다

로그와 성능 데이터는 각각 다른 정보를 제공한다.

로그는 특정 이벤트나 상태 변화를 보여주고, 성능 데이터는 시스템 상태가 어떻게 변했는지를 보여준다.

예를 들어 저장장치 관련 오류 로그가 기록된 시점과 디스크 응답시간이 급격히 증가한 시점을 비교하면 두 사건의 시간적 관계를 확인할 수 있다.

하지만 두 데이터가 같은 시점에 발생했다고 해서 바로 원인관계가 확정되는 것은 아니다.

자동화 시스템에서는 다음과 같은 순서로 분석하는 것이 바람직하다.

성능 변화 확인 → 관련 로그 검색 → 시간축 정렬 → 선후관계 확인 → 반복 여부 확인 → 다른 원인 후보 비교

여기에 애플리케이션 로그, 프로세스 상태, 하드웨어 상태, 구성 변경 정보 등을 추가하면 단일 데이터에 의존하는 위험을 줄일 수 있다.

8. 여러 원인 후보를 동시에 비교한다

자동화 진단의 중요한 장점은 하나의 원인만 처음부터 가정하지 않고 여러 후보를 동시에 비교할 수 있다는 것이다.

예를 들어 시스템 응답시간이 증가했다면 다음과 같은 후보를 구성할 수 있다.

원인 후보	확인할 주요 증거
CPU 처리 문제	CPU 사용률, 실행 프로세스, 처리시간 변화
메모리 관련 문제	메모리 사용량, 압박 상태, 스왑·페이지 활동
저장장치 문제	I/O 대기, 응답시간, 오류 이벤트, 장치 상태
네트워크 문제	지연, 연결 상태, 오류·재전송
프로세스 문제	특정 프로세스의 상태, 실행시간, 자원 사용
드라이버 문제	장치 이벤트, 드라이버 오류, 변경 이력
애플리케이션 문제	애플리케이션 로그, 요청 처리시간, 오류 패턴

이 표의 목적은 하나의 지표가 높다고 바로 원인을 확정하는 것이 아니다.

각 후보를 설명할 수 있는 증거가 실제로 존재하는지 비교하는 것이 목적이다.

9. 원인 후보의 우선순위를 자동으로 정한다

자동화 진단에서는 가능한 원인을 모두 같은 수준으로 나열하는 것보다 조사 우선순위를 정하는 것이 실무적으로 더 유용하다.

예를 들어 특정 장애에서

• 장애 직전에 저장장치 응답시간이 반복적으로 증가했고
• 동일한 시간대에 관련 오류가 발생했으며
• 과거 동일 장애에서도 같은 패턴이 나타났고
• 정상 시스템에서는 해당 패턴이 나타나지 않았다면

저장장치 관련 원인을 우선 조사할 이유가 커진다.

반대로 CPU 사용률이 높았지만 정상적인 작업량 증가 때에도 동일하게 나타났다면 CPU를 원인 후보의 최우선 대상으로 볼 근거는 약해진다.

따라서 자동화 시스템의 출력은 단순한

“원인은 저장장치입니다.”

보다

“저장장치 관련 이상이 현재 장애와 시간적·반복적 관계를 보여 우선 확인할 필요가 있습니다.”

와 같은 형태가 더 적절하다.

자동화의 가치는 확정되지 않은 원인을 확정하는 것보다 조사 순서를 합리적으로 좁혀주는 것에 있다.

10. 장애 예측과 원인 예측을 구분한다

장애 예측과 원인 예측은 서로 관련되어 있지만 동일한 개념은 아니다.

장애 예측은 앞으로 장애가 발생할 가능성이 높아지는지를 판단하는 것이다.

반면 원인 예측은 장애가 발생했거나 발생할 가능성이 있는 상황에서 어떤 구성요소 또는 조건을 우선적으로 조사해야 하는지를 판단하는 과정이다.

예를 들어 저장장치 응답시간이 장기간 증가하고 관련 오류 이벤트가 반복된다면 향후 저장장치 관련 장애 위험을 감시할 필요가 있다고 판단할 수 있다.

하지만 이것만으로 저장장치 고장을 확정할 수는 없다.

따라서 예측 결과는 다음과 같이 활용하는 것이 적절하다.

예측 결과 → 위험 대상 선정 → 추가 데이터 확인 → 담당자 검증 → 대응 결정

즉, 예측은 결론이 아니라 다음 판단을 위한 우선순위 정보다.

11. 오탐과 미탐을 자동화 진단의 품질 기준으로 관리한다

자동화 시스템의 정확도를 평가할 때 단순히 “얼마나 많이 탐지했는가”만 보면 안 된다.

정상 상태를 장애로 판단하는 **오탐(False Positive)**이 많으면 불필요한 경보가 증가하고 담당자의 경보 피로가 커질 수 있다.

반대로 실제 장애를 놓치는 **미탐(False Negative)**이 많으면 장애 대응이 늦어질 수 있다.

따라서 자동화 진단의 품질은 다음 요소를 함께 살펴봐야 한다.

• 실제 장애 탐지 여부
• 오탐 발생 빈도
• 미탐 발생 여부
• 장애 발생 전 확보된 대응 시간
• 경보의 실제 활용 가능성
• 운영자가 경보를 처리할 수 있는 수준인지 여부

특히 자동화 시스템에서는 탐지율을 높이는 것과 실무에서 사용할 수 있는 경보를 만드는 것이 동일하지 않다.

경보가 많다고 좋은 시스템도 아니고, 경보가 적다고 좋은 시스템도 아니다.

12. 자동 진단 결과는 입력 데이터의 품질에 영향을 받는다

자동화된 분석이 아무리 정교해도 입력 데이터에 문제가 있다면 결과 역시 영향을 받을 수밖에 없다.

Ⅴ-9에서 살펴본 것처럼 다음과 같은 문제가 발생할 수 있다.

• 로그 누락
• 시간 동기화 문제
• 수집 지연
• 측정 주기 차이
• 장애 직전 데이터 부족
• 센서 측정 한계
• 서로 다른 시스템의 시간 기준 차이
• 장애 과정에서 데이터 자체가 손실되는 경우

따라서 자동화 진단에서는 단순히 **“데이터가 있다”**는 것만으로 충분하지 않다.

그 데이터가

정확한가 → 시간상 맞는가 → 필요한 구간을 포함하는가 → 다른 자료와 모순되지 않는가 → 실제 판단에 적합한가

를 함께 확인해야 한다.

자동화에서는 사람이 매번 데이터를 검토하지 않기 때문에 데이터 품질 문제가 반복적으로 잘못된 판단으로 이어질 가능성도 고려해야 한다.

13. 자동화가 모든 장애를 진단할 수 있는 것은 아니다

자동화 진단에는 분명한 한계가 있다.

과거에 발생하지 않았던 새로운 장애 유형이나 갑작스러운 전원 장애처럼 사전에 충분한 데이터가 없는 경우에는 과거 패턴을 이용한 판단이 어려울 수 있다.

또한 동일한 증상이 여러 원인에서 나타나는 경우에도 자동화 결과만으로 하나의 원인을 확정하기 어려울 수 있다.

예를 들어 서비스 응답시간이 증가했다는 사실만으로 CPU, 메모리, 저장장치, 네트워크 중 어느 하나를 바로 원인으로 결정할 수 없다.

자동화 시스템은 관측 가능한 데이터 범위 안에서 판단한다는 한계를 가지고 있다.

따라서 자동화되지 않은 영역이 존재한다는 사실 자체를 시스템의 실패로 볼 필요는 없다.

오히려 어떤 부분을 자동으로 판단할 수 있고 어떤 부분은 사람의 추가 검증이 필요한지를 구분하는 것이 중요하다.

14. 사람이 최종 원인을 검증해야 하는 이유

자동화 시스템은 대량의 데이터를 빠르게 비교하고 반복적인 패턴을 찾는 데 강하다.

하지만 실제 운영환경에서는 계획된 작업, 긴급 변경, 사용자 증가, 외부 시스템 장애 등 데이터만으로 완전히 파악하기 어려운 조건이 존재할 수 있다.

따라서 현실적인 구조는 다음과 같다.

자동 데이터 수집
→ 이상 탐지
→ 원인 후보 생성
→ 증거 비교
→ 우선순위 결정
→ 담당자 검토
→ 현장 조건 확인
→ 원인 검증
→ 복구
→ 결과 기록

여기서 중요한 것은 사람이 모든 데이터를 처음부터 다시 보는 것이 아니다.

자동화 시스템이 이미 정리한 핵심 증거와 원인 후보를 사람이 검증하는 구조로 만드는 것이다.

이렇게 하면 자동화의 속도와 사람의 상황 판단 능력을 함께 활용할 수 있다.

15. 장애 대응 결과를 다음 진단에 다시 활용한다

장애가 한 번 발생하고 복구되었다고 해서 분석 과정이 끝나는 것은 아니다.

실제 장애 결과가 다음 장애 진단에 활용될 수 있도록 기록해야 한다.

예를 들어 다음과 같은 내용을 축적할 수 있다.

• 장애 발생 시각
• 최초 이상 시각
• 주요 성능 변화
• 관련 로그
• 영향받은 서비스
• 확인된 원인
• 기여 요인
• 복구 방법
• 복구에 걸린 시간
• 재발 여부
• 당시 자동 진단 결과
• 실제 원인과 자동 진단 결과의 차이

이 자료가 축적되면 이후 장애가 발생했을 때 과거 사례와 비교할 수 있다.

특히 중요한 것은 자동 진단이 잘못 판단했던 사례도 데이터로 남기는 것이다.

오탐과 미탐 사례가 축적되어야 진단 기준을 개선할 수 있기 때문이다.

16. 자동화 장애 진단을 단계적으로 적용한다

처음부터 모든 구성요소를 자동 분석 대상으로 만들 필요는 없다.

오히려 핵심 지표와 반복적으로 발생하는 장애부터 적용하면서 범위를 확대하는 것이 현실적이다.

1단계 — 데이터 수집

CPU, 메모리, 저장장치, 네트워크, 주요 로그 등 기본 데이터를 확보한다.

2단계 — 정상 상태 기준 구축

시간대, 작업량, 정기 작업 등을 고려하여 정상 상태를 정의한다.

3단계 — 이상 탐지

정상 상태에서 벗어나는 변화와 장애 전조를 탐지한다.

4단계 — 장애 사례 연결

실제 장애와 어떤 이상 패턴이 연결되는지 확인한다.

5단계 — 원인 후보 분석

로그, 성능 데이터, 의존관계, 변경 이력을 이용해 후보를 좁힌다.

6단계 — 결과 검증

자동 분석 결과와 실제 원인을 비교한다.

7단계 — 자동화 범위 확대

검증된 분석 기준을 다른 서비스와 시스템으로 확대한다.

이 방식의 장점은 자동화 시스템을 한 번에 완성하려 하지 않고 실제 장애 데이터를 이용하면서 점진적으로 정확도를 높일 수 있다는 것이다.

17. 자동화 장애 진단의 핵심은 ‘자동 판단’이 아니라 ‘판단 범위의 축소’다

자동화 시스템을 도입할 때 흔히 “장애 원인을 자동으로 찾아주는 시스템”을 기대하기 쉽다.

하지만 실제 운영에서 더 현실적인 목표는 사람이 확인해야 할 범위를 크게 줄이는 것이다.

예를 들어 1,000개의 로그와 수십 개의 성능 지표를 사람이 모두 확인해야 하는 상황에서 자동화 시스템이 다음과 같이 정리해 준다고 하자.

“장애 발생 5분 전 저장장치 응답시간이 반복적으로 증가했고, 동일 시점에 관련 오류가 발생했으며, 과거 3건의 동일 장애에서도 같은 패턴이 확인되었습니다.”

이 정도의 정보만 제공되어도 담당자는 어디부터 확인해야 할지 빠르게 판단할 수 있다.

여기서 자동화 시스템이 해야 할 일은 최종 결론을 대신 내리는 것이 아니라 사람이 가장 먼저 확인해야 할 증거를 앞으로 가져오는 것이다.

이것이 자동화 장애 진단의 실질적인 가치다.

18. 자동화된 장애 진단과 원인 예측의 최종 의미

컴퓨터 시스템의 장애는 하나의 오류 메시지나 하나의 성능 지표만으로 설명되지 않는 경우가 많다.

따라서 자동화된 장애 진단은 다음과 같은 분석 흐름으로 연결되어야 한다.

데이터 수집
→ 정상 상태 비교
→ 이상 징후 탐지
→ 장애 이전 변화 추적
→ 시간축 정렬
→ 구성요소 의존관계 분석
→ 원인 후보 생성
→ 증거 비교
→ 후보 우선순위화
→ 사람의 검증
→ 실제 원인 기록
→ 다음 장애 분석에 재활용

이 과정에서 자동화가 잘하는 것은 대량의 데이터를 빠르게 비교하고, 반복적인 패턴을 찾으며, 사람이 확인해야 할 범위를 줄이는 것이다.

반면 실제 원인의 최종 확정에는 시스템의 운영 조건, 변경사항, 재현 결과, 추가 검증 등 자동화된 데이터만으로 판단하기 어려운 요소가 포함될 수 있다.

따라서 자동화된 장애 진단의 목표를

“사람 없이 장애 원인을 결정하는 것”

으로 설정하는 것은 적절하지 않다.

더 현실적이고 중요한 목표는

“장애가 발생했을 때 무엇을 먼저 확인해야 하는지, 어떤 원인 후보를 우선 검증해야 하는지, 어떤 증거가 서로 연결되어 있는지를 빠르고 체계적으로 제시하는 것”

이다.

결국 좋은 자동화 진단 체계는 사람의 판단을 없애는 시스템이 아니라 사람이 더 빠르고 정확하게 판단할 수 있도록 장애의 증거와 원인 후보를 정리해 주는 시스템이다.

핵심정리

자동화 장애 진단의 핵심은 **‘원인을 대신 결정하는 것’이 아니라 ‘원인을 찾기 위한 탐색 범위를 줄이는 것’**이다.

이상 탐지 → 시간축 분석 → 의존관계 분석 → 원인 후보 비교 → 우선순위화 → 사람의 검증

이 연결되어야 자동화가 실제 장애 대응 능력으로 이어진다.

그리고 자동화의 품질은 탐지 기능만으로 결정되지 않는다.

정상 상태 기준, 입력 데이터의 품질, 오탐·미탐, 과거 장애 기록, 사람의 최종 검증까지 함께 관리해야 한다.

결국 자동화는 사람을 대신하는 것이 아니라, 사람이 중요한 판단에 더 많은 시간을 사용할 수 있도록 반복적인 탐색과 증거 정리를 대신하는 것에 의미가 있다.