Ⅴ-1. 컴퓨터 시스템 장애 진단 절차와 원인 추적 분석

컴퓨터 시스템에서 장애가 발생하면 가장 먼저 해야 할 일은 고장난 부품을 추측하는 것이 아니다.

사용자가 경험한 증상만으로 저장장치, 메모리, 운영체제, 네트워크 장치 가운데 하나를 바로 원인으로 지목하면 잘못된 부품을 교체하거나, 일시적으로 증상만 사라진 상태에서 시스템을 다시 운영할 가능성이 있다.

장애 진단에서 중요한 것은 “무엇이 고장났는가?”보다 먼저 “무엇이 언제부터 어떻게 달라졌는가?”를 확인하는 것이다.

특히 장애가 발생하면 사용자가 가장 먼저 경험하는 증상과 실제 원인이 시작된 지점이 서로 다를 수 있다.

따라서 장애 진단은 증상을 확인하고 범위를 좁힌 다음, 시간적인 선후관계를 확인하고, 여러 원인 가설을 세운 뒤 데이터를 이용해 하나씩 검증하는 과정으로 접근하는 것이 적절하다.

1. 장애 진단에서 증상과 원인을 구분해야 하는 이유

장애 진단에서 가장 흔한 오류 중 하나는 증상이 나타난 위치를 원인으로 바로 판단하는 것이다.

예를 들어 운영체제가 멈췄다고 해서 운영체제가 반드시 원인이라는 뜻은 아니다.

저장장치의 읽기 오류, 메모리 오류, 드라이버 문제, 전원 불안정 등으로 인해 운영체제가 정상적인 처리를 수행하지 못한 결과일 수도 있다.

네트워크 연결이 끊긴 경우도 마찬가지다.

사용자에게는 “인터넷이 안 된다”는 하나의 증상으로 나타나지만 실제 원인은 다음과 같이 여러 영역에 존재할 수 있다.

• 네트워크 인터페이스
• 드라이버
• 케이블 또는 링크
• 스위치
• 라우터
• DNS
• 방화벽
• 서버
• 애플리케이션

따라서 진단의 첫 단계에서는 증상 자체와 원인 후보를 분리해서 생각하는 것이 중요하다.

2. 장애가 발생한 시점과 최초 이상을 확인한다

원인 추적에서 시간은 매우 중요한 단서다.

장애가 발생한 시각만 기록하는 것으로는 충분하지 않을 수 있다.

예를 들어 14시 30분에 서비스가 중단되었다면 다음과 같은 질문이 필요하다.

• 14시 30분에 처음 문제가 발생했는가?
• 그보다 먼저 응답시간이 증가했는가?
• 오류 로그가 먼저 발생했는가?
• 특정 프로세스의 상태가 먼저 변했는가?
• 네트워크 오류가 먼저 나타났는가?
• 최근 변경은 언제 이루어졌는가?

이렇게 시간축을 따라가면 장애가 발생한 순간보다 앞선 변화를 찾을 수 있다.

다만 최초로 관측된 이상이 곧바로 근본 원인이라는 뜻은 아니다.

예를 들어 네트워크 오류가 먼저 기록되었더라도 그보다 앞서 드라이버 오류나 장비 상태 변화가 발생했을 가능성이 있다.

따라서 시간 순서는 원인을 확정하는 기준이라기보다 원인 후보의 선후관계를 좁히는 중요한 근거로 활용해야 한다.

3. 장애 증상을 구체적으로 기록한다

“컴퓨터가 이상하다” 또는 “느려졌다”라는 표현만으로는 원인 추적에 필요한 정보가 부족하다.

가능한 한 장애를 관찰 가능한 현상으로 구체화해야 한다.

확인 항목	확인 내용
발생 시각	처음 증상이 나타난 시간
지속시간	일시적인지 지속적인지
반복 여부	동일 증상이 반복되는지
영향 범위	전체 시스템인지 특정 기능인지
오류 내용	메시지·오류 코드·로그
사용자 영향	어떤 기능을 사용할 수 없는지
재부팅 여부	자동 또는 수동 재부팅 발생 여부
직전 작업	장애 직전에 수행한 작업
최근 변경	업데이트·설정·장비 변경 여부

이 정보가 많을수록 원인 후보를 좁히는 데 유리하다.

특히 “무엇이 안 되는가”와 “무엇은 정상인가”를 함께 기록하는 것이 중요하다.

예를 들어 전체 서버가 중단된 것이 아니라 특정 애플리케이션만 접속되지 않는다면 진단 범위를 크게 줄일 수 있다.

4. 장애 범위를 먼저 한정한다

장애 진단에서는 처음부터 모든 구성요소를 조사할 필요가 없다.

먼저 문제가 어디까지 영향을 미쳤는지 확인해야 한다.

예를 들어 한 대의 컴퓨터에서만 문제가 발생한다면 해당 장비의 하드웨어, 운영체제, 드라이버, 설정 등을 우선적으로 확인할 수 있다.

반대로 같은 네트워크에 연결된 여러 시스템에서 동시에 문제가 발생했다면 개별 컴퓨터보다 공통으로 사용하는 구성요소를 먼저 확인하는 것이 효율적이다.

단일 시스템 → 동일 서비스 → 동일 네트워크 → 공통 인프라

와 같이 장애 범위를 확대해 보면 공통 원인을 찾는 데 도움이 된다.

다만 여러 시스템에서 동시에 발생했다고 해서 반드시 공통 구성요소가 원인이라고 단정해서는 안 된다.

동일한 시간에 배포된 프로그램이나 동일한 정책 변경처럼 공통된 소프트웨어 조건이 원인일 수도 있기 때문이다.

5. 정상 상태와 장애 상태의 차이를 비교한다

장애가 발생한 시점의 값만 보는 것보다 정상 상태와 비교하는 것이 효과적이다.

예를 들어 평소 CPU 사용률이 20~30% 수준인데 장애 직전에 특정 프로세스와 함께 사용률이 급격하게 증가했다면 해당 영역을 조사할 근거가 생긴다.

반대로 CPU 사용률에는 뚜렷한 변화가 없고 저장장치 응답시간과 I/O 대기만 증가했다면 저장장치 또는 해당 I/O 경로를 추가로 확인할 필요가 있다.

여기서 중요한 것은 높은 수치 자체를 장애 원인으로 해석하지 않는 것이다.

CPU 사용률이 높다고 해서 반드시 CPU가 고장난 것은 아니며, 저장장치 응답시간이 증가했다고 해서 저장장치 자체가 고장났다고 확정할 수도 없다.

우리가 찾아야 하는 것은

“정상 상태와 비교했을 때 무엇이 달라졌으며, 그 변화가 장애 증상과 시간적으로 연결되어 있는가?”

이다.

6. 최근 변경 사항을 확인한다

정상적으로 작동하던 시스템에서 장애가 시작되었다면 최근 변경 사항은 중요한 조사 대상이다.

확인할 수 있는 변경 사항은 다음과 같다.

• 운영체제 업데이트
• 드라이버 업데이트
• 프로그램 설치 또는 업데이트
• 하드웨어 교체
• BIOS·UEFI 설정 변경
• 네트워크 구성 변경
• 보안 정책 변경
• 방화벽 정책 변경
• 저장장치 교체
• 시스템 설정 변경

특히 변경 시점과 장애 발생 시점의 관계를 확인해야 한다.

예를 들어 13시에 드라이버를 변경했고 13시 20분부터 문제가 발생했다면 해당 변경은 중요한 원인 후보가 된다.

그러나 시간적으로 가깝다는 이유만으로 원인이라고 확정해서는 안 된다.

동일한 시간에 다른 변경이나 외부 조건의 변화가 있었을 수도 있기 때문이다.

따라서 변경 사항은 원인을 결정하는 증거가 아니라 우선적으로 검증할 후보를 정하는 단서로 보는 것이 정확하다.

7. 하드웨어·소프트웨어·네트워크 영역을 분리해서 조사한다

컴퓨터 시스템은 여러 계층이 연결되어 있기 때문에 장애 진단에서도 조사 영역을 분리할 필요가 있다.

하드웨어 영역

• CPU
• 메모리
• 저장장치
• 그래픽카드
• 네트워크 인터페이스
• 메인보드
• 전원공급장치
• 케이블 및 연결 상태

소프트웨어 영역

• 운영체제
• 드라이버
• 시스템 서비스
• 응용프로그램
• 보안 프로그램
• 시스템 설정

네트워크 영역

• NIC 상태
• 링크 상태
• 스위치
• 라우터
• 방화벽
• DNS
• 네트워크 경로
• 서버 연결 상태

이렇게 영역을 나누는 목적은 모든 것을 따로 조사하기 위한 것이 아니다.

현재 증상과 가장 관련성이 높은 영역부터 조사 범위를 좁혀가기 위한 것이다.

8. 로그와 성능 데이터를 시간 순서로 연결한다

로그와 성능 데이터는 각각 따로 보는 것보다 시간축을 맞춰 함께 보는 것이 유용하다.

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

14:10 → 정상 상태

14:12 → 저장장치 응답시간 증가

14:13 → I/O 관련 오류 로그 발생

14:15 → 애플리케이션 응답시간 증가

14:16 → 서비스 장애 발생

이 경우 서비스 장애가 발생한 14:16의 증상만 보는 것보다 그 이전에 어떤 변화가 있었는지를 추적할 수 있다.

다만 시간적으로 먼저 발생했다는 이유만으로 원인이라고 확정해서는 안 된다.

여러 사건이 동시에 발생할 수 있고, 로그 기록 자체가 지연될 수도 있기 때문이다.

따라서 시간 순서는 가설을 세우는 근거로 사용하고, 다른 데이터와 함께 검증해야 한다.

9. 하나의 원인을 정하지 말고 여러 가설을 세운다

장애 진단에서 처음부터 하나의 원인을 확정하면 이후의 데이터도 그 원인에 맞춰 해석할 가능성이 있다.

예를 들어 시스템이 반복적으로 멈춘다면 다음과 같은 가설을 동시에 고려할 수 있다.

• 메모리 오류
• 저장장치 오류
• 드라이버 충돌
• 과열
• 전원 불안정
• 운영체제 오류
• 특정 응용프로그램 문제
• 하드웨어 연결 문제

그다음 각 가설을 확인할 수 있는 증거를 찾아야 한다.

원인 가설	확인할 근거
메모리 문제	메모리 오류 기록, 진단 결과, 반복 패턴
저장장치 문제	I/O 오류, 응답시간, 장치 상태
드라이버 문제	드라이버 오류, 업데이트 시점, 충돌 기록
과열	온도 변화, 부하와의 관계
전원 문제	전원 관련 로그, 재부팅 패턴, 전원 상태
응용프로그램 문제	특정 프로그램과 장애의 반복 관계

이렇게 하면 추측 → 확인이 아니라 가설 → 증거 → 검증의 형태로 진단할 수 있다.

10. 원인 후보를 제거하면서 범위를 좁힌다

모든 원인 가설을 끝까지 조사할 필요는 없다.

검증 결과와 맞지 않는 가설은 제외하면서 조사 범위를 좁혀갈 수 있다.

예를 들어 메모리 오류를 의심했지만 동일한 환경에서 메모리 진단 결과가 정상이고 장애와 관련된 로그도 확인되지 않는다면 메모리를 계속 최우선 원인으로 볼 근거는 약해진다.

반대로 특정 드라이버 업데이트 이후 동일한 오류가 반복되고 업데이트 이전에는 문제가 없었다면 해당 드라이버를 우선적으로 검증할 이유가 커진다.

이 과정의 목적은 “가장 그럴듯한 원인을 빨리 찾는 것”이 아니라, 틀린 원인을 가능한 한 빠르게 제외하는 것이기도 하다.

11. 부품 교체는 진단의 시작이 아니라 검증 수단으로 사용한다

장애가 발생하면 문제가 의심되는 부품부터 교체하는 방식이 빠르게 보일 수 있다.

하지만 교체 후 증상이 사라졌다고 해서 그 부품이 반드시 원인이었다고 단정할 수는 없다.

부품을 교체하는 과정에서 케이블이 다시 연결되거나 시스템이 재부팅되거나 다른 설정이 변경되었을 수 있기 때문이다.

따라서 가능하다면 교체 전후의 상태를 기록해야 한다.

• 교체 전 증상
• 교체한 부품
• 교체 시각
• 함께 변경된 조건
• 교체 후 증상 변화
• 동일 장애 재발 여부

이렇게 기록해야 부품 교체가 실제 원인 제거에 영향을 주었는지 판단할 수 있다.

12. 장애가 사라졌다고 원인이 확정된 것은 아니다

장애 대응에서는 시스템을 다시 정상 상태로 만드는 것과 원인을 규명하는 것을 구분해야 한다.

예를 들어 서버를 재부팅한 후 정상적으로 작동한다고 해서 재부팅이 원인을 해결했다고 볼 수는 없다.

재부팅은 일시적으로 상태를 초기화했을 뿐 실제 원인이 남아 있을 수도 있다.

따라서 복구 후에는 다음을 확인해야 한다.

• 동일 증상이 다시 발생하는가?
• 장애를 발생시켰던 조건이 제거되었는가?
• 관련 로그가 다시 나타나는가?
• 성능 상태가 정상 범위로 돌아왔는가?
• 서비스 기능이 정상적으로 수행되는가?

복구는 “다시 작동하는 것”이고, 원인 규명은 “왜 문제가 발생했는지를 설명할 수 있는 것”이다.

두 가지를 혼동하면 같은 장애가 반복될 가능성이 높아진다.

13. 원인과 결과의 연결을 검증한다

원인 후보를 찾았다고 해서 바로 원인으로 확정해서는 안 된다.

최종적으로는 해당 원인이 실제 증상을 설명할 수 있는지 확인해야 한다.

예를 들어 특정 드라이버를 원인으로 의심한다면 다음과 같은 질문을 할 수 있다.

• 드라이버 변경 이후 장애가 발생했는가?
• 관련 오류가 실제로 기록되어 있는가?
• 동일한 조건에서 장애가 반복되는가?
• 드라이버를 이전 버전으로 변경했을 때 문제가 사라지는가?
• 다른 조건에서도 같은 문제가 발생하는가?

이러한 검증을 통해 원인 후보와 실제 장애 사이의 연결관계를 확인할 수 있다.

가능하다면 동일한 조건에서 결과가 반복되는지도 확인하는 것이 좋다.

14. 장애 진단의 실제 절차

지금까지의 내용을 실제 장애 진단 흐름으로 정리하면 다음과 같다.

① 증상 기록

→ 언제, 무엇이, 어떻게 실패했는지 기록

② 장애 범위 확인

→ 단일 시스템인지 여러 시스템인지 확인

③ 시간축 구성

→ 장애 발생 전후의 이벤트와 상태 변화 정리

④ 정상 상태 비교

→ 평상시와 무엇이 달라졌는지 확인

⑤ 최근 변경 확인

→ 업데이트·설정·하드웨어·정책 변경 조사

⑥ 원인 후보 분류

→ 하드웨어·소프트웨어·네트워크·외부 조건으로 구분

⑦ 가설 수립

→ 가능한 원인을 여러 개 설정

⑧ 데이터 검증

→ 로그·성능 데이터·진단 결과와 비교

⑨ 원인 후보 제거

→ 근거가 부족하거나 조건과 맞지 않는 원인 제외

⑩ 조치 후 검증

→ 증상 제거와 원인 제거가 실제로 이루어졌는지 확인

⑪ 재발 여부 확인

→ 동일 조건에서 문제가 다시 발생하지 않는지 확인

이 순서를 지키면 처음부터 특정 부품을 의심하고 불필요한 교체를 반복하는 일을 줄일 수 있다.

15. 장애 진단에서 특히 주의해야 할 판단 오류

장애 진단에서는 다음과 같은 판단 오류가 자주 발생할 수 있다.

① 증상이 나타난 위치를 원인으로 판단

운영체제가 멈췄다고 운영체제가 원인이라고 단정하는 경우다.

② 가장 눈에 띄는 수치를 원인으로 판단

CPU 사용률이 높다는 이유만으로 CPU 문제라고 판단하는 경우다.

③ 최근 변경을 바로 원인으로 판단

업데이트 직후 장애가 발생했다고 업데이트 자체를 원인으로 확정하는 경우다.

④ 부품 교체 후 정상화된 것을 원인 확정으로 판단

교체 과정에서 다른 조건도 함께 변경되었을 가능성을 무시하는 경우다.

⑤ 일시적인 복구를 근본적인 해결로 판단

재부팅이나 서비스 재시작 후 정상화된 상태를 최종 해결로 보는 경우다.

이러한 오류를 피하려면 모든 판단에 “어떤 증거가 있는가?”와 “다른 원인으로도 설명할 수 있는가?”라는 질문을 붙이는 것이 좋다.

16. 장애 진단과 근본 원인 분석은 구분해야 한다

장애가 발생한 순간에는 서비스 복구가 우선일 수 있다.

따라서 초기 장애 진단에서는 정확한 근본 원인을 완전히 규명하기 전에 서비스 복구를 위해 우선적인 조치를 취할 수도 있다.

이후 서비스가 안정되면 보다 자세한 원인 분석을 수행할 수 있다.

즉,

장애 진단 → 원인 후보 확인 → 긴급 대응 → 서비스 복구 → 추가 분석 → 근본 원인 확인

과 같이 실제 운영에서는 여러 과정이 겹치거나 순서가 달라질 수 있다.

여기서 중요한 것은 “복구를 위해 임시로 취한 조치”와 “최종적으로 확인된 원인”을 기록상 구분하는 것이다.

그래야 이후 같은 장애가 발생했을 때 더 정확하게 대응할 수 있다.

17. 핵심 정리

컴퓨터 시스템 장애 진단의 출발점은 고장난 부품을 추측하는 것이 아니라 증상을 정확하게 정의하는 것이다.

그다음 장애 범위와 시간축을 확인하고, 정상 상태와 비교하며, 최근 변경 사항을 조사한다.

이후 여러 원인 가설을 세우고 로그·성능 데이터·진단 결과를 이용해 하나씩 검증하면서 원인 후보를 좁혀간다.

특히 다음 세 가지는 반드시 구분해야 한다.

증상이 나타난 위치 ≠ 원인이 시작된 위치

최초로 관측된 이상 ≠ 반드시 근본 원인

시스템이 다시 작동함 ≠ 원인이 해결됨

결국 좋은 장애 진단은 “무엇을 교체했더니 다시 작동했다”에서 끝나는 것이 아니라, 왜 장애가 발생했는지 데이터와 시간적 근거를 이용해 설명할 수 있는 상태까지 도달하는 것이다.

마지막으로 자신의 시스템을 진단한다고 생각해 보자.

우리는 장애가 발생했을 때 가장 먼저 눈에 띄는 증상을 원인으로 판단하고 있지는 않은가?

그리고 시스템을 다시 작동시키는 것과 장애의 원인을 실제로 제거한 것을 구분하고 있는가?