Ⅴ-5. 컴퓨터 장애 재현성과 발생 조건 분석

컴퓨터 장애를 정확하게 진단하려면 장애가 발생했다는 사실만 확인해서는 부족하다.

중요한 것은 어떤 조건에서 장애가 발생했는지, 그리고 동일하거나 유사한 조건을 다시 만들었을 때 같은 증상이 반복되는지를 확인하는 것이다.

특히 간헐적으로 발생하는 장애는 증상만으로 원인을 판단하기 어렵다.

평소에는 정상적으로 작동하다가 특정 부하, 온도, 사용시간, 프로그램 조합, 장치 상태 등이 겹쳤을 때만 문제가 발생할 수 있기 때문이다.

따라서 장애 재현성 분석은 단순히 장애를 다시 발생시키는 테스트가 아니라,

장애 발생 조건 확인 → 조건 분리 → 재현 여부 비교 → 원인 후보 축소 → 원인 검증

으로 이어지는 진단 과정으로 보는 것이 적절하다.

1. 장애 재현성이 중요한 이유

장애 재현성이란 특정 조건에서 동일하거나 유사한 장애가 반복적으로 나타나는 특성을 의미한다.

예를 들어 다음과 같은 현상이 반복될 수 있다.

• 특정 프로그램 실행 후 시스템 멈춤
• 대용량 파일 복사 후 저장장치 오류
• 고부하 상태에서 시스템 재부팅
• 장시간 사용 후 화면 출력 이상
• 특정 USB 장치 연결 후 시스템 오류
• 메모리 사용량 증가 후 프로그램 종료
• 특정 네트워크 환경에서 연결 끊김

이러한 현상이 비슷한 조건에서 반복된다면 장애와 해당 조건 사이에 연관성이 있을 가능성이 높아진다.

그러나 재현된다는 사실만으로 원인이 확정되는 것은 아니다.

예를 들어 특정 프로그램을 실행할 때마다 시스템이 멈춘다면 프로그램 자체가 원인일 수도 있지만, 프로그램 실행 과정에서 특정 드라이버나 저장장치, 메모리, 네트워크 기능이 함께 사용되면서 문제가 발생할 수도 있다.

따라서 재현성은 원인을 확정하는 증거라기보다 원인 후보를 좁히고 검증하기 위한 강력한 단서로 활용해야 한다.

2. 장애 발생 조건을 구체적으로 기록한다

“컴퓨터가 멈췄다”라는 기록만으로는 재현 실험을 설계하기 어렵다.

장애가 발생한 당시의 조건을 여러 항목으로 나누어 기록해야 한다.

구분	확인할 내용
시스템 상태	CPU, 메모리, 저장장치, GPU, 네트워크 상태
환경 조건	주변 온도, 냉각 상태, 전원 상태
작업 조건	실행 프로그램, 데이터 크기, 동시 작업
장치 상태	연결된 USB, PCIe 장치, 외부 장비
시간 조건	부팅 후 경과시간, 장애 발생 시각
소프트웨어 상태	OS, 드라이버, 프로그램 버전
변경 사항	최근 업데이트, 설정 변경, 장비 교체
장애 직전 상태	지연, 오류, 화면 이상, 연결 불안정 등

이렇게 기록해야 나중에 정상 상태와 장애 상태를 비교할 수 있다.

특히 장애 발생 순간의 값 하나보다 장애 직전부터 어떻게 변화했는지가 더 중요한 경우가 많다.

3. 장애 발생 조건은 하나의 값으로만 보지 않는다

컴퓨터 장애는 반드시 특정 숫자 하나를 넘었을 때 발생하는 것은 아니다.

예를 들어 CPU 사용률이 높다고 해서 반드시 장애가 발생하는 것은 아니다.

다음과 같은 여러 조건이 함께 작용할 수 있다.

높은 CPU 부하 + 높은 온도 + 장시간 운전

또는

높은 메모리 사용량 + 특정 프로그램 + 저장장치 지연

처럼 여러 조건이 동시에 존재할 수 있다.

따라서 재현성 분석에서는 다음을 구분해야 한다.

• 단일 조건으로 발생하는 장애
• 두 개 이상의 조건이 함께 있을 때 발생하는 장애
• 특정 순서로 조건이 발생할 때 나타나는 장애
• 일정 시간 이상 조건이 유지될 때 발생하는 장애
• 특정 환경에서만 발생하는 장애

이렇게 분석하면 단순한 “장애 발생 여부”에서 장애를 발생시키는 조건의 조합으로 분석 범위를 넓힐 수 있다.

4. 재현 실험에서는 비교 가능한 조건을 만들어야 한다

원인을 확인하기 위해 여러 조건을 동시에 변경하면 어떤 변화가 장애에 영향을 주었는지 판단하기 어렵다.

따라서 가능하면 비교 대상이 명확하도록 실험 조건을 설계해야 한다.

예를 들어 고부하 상태에서 시스템이 재부팅되는 문제가 있다면 다음과 같이 비교할 수 있다.

① CPU 부하 증가

→ 재부팅 여부 확인

② 메모리 사용량 증가

→ 재부팅 여부 확인

③ 저장장치 I/O 증가

→ 재부팅 여부 확인

④ CPU + 메모리 부하

→ 재부팅 여부 확인

⑤ CPU + 메모리 + 저장장치 부하

→ 재부팅 여부 확인

⑥ 동일 부하를 장시간 유지

→ 재부팅 여부 확인

이렇게 조건을 나누면 어떤 조건에서 증상이 나타나는지 비교하기 쉬워진다.

다만 실제 장애가 여러 조건의 결합으로 발생한다고 판단되는 경우에는 단일 조건만 고집하지 않고 복합 조건 실험도 함께 수행해야 한다.

핵심은 모든 실험에서 무엇을 변경했고 무엇을 그대로 유지했는지를 기록하는 것이다.

5. 장애 재현성과 원인 확정은 구분해야 한다

재현성이 높아지면 원인 후보의 신뢰도는 높아질 수 있다.

하지만 다음 두 문장은 서로 다르다.

“이 조건에서 장애가 반복된다.”

“이 조건이 장애의 근본원인이다.”

첫 번째는 관찰 결과다.

두 번째는 추가적인 검증이 필요한 판단이다.

예를 들어 높은 온도에서 시스템이 반복적으로 종료된다고 하자.

이 경우 조사 대상에는 다음이 포함될 수 있다.

• CPU 또는 GPU 온도
• 냉각팬 상태
• 방열 구조
• 전원공급장치 상태
• 메인보드 전원부
• 온도 센서의 정확성
• 운영체제 또는 드라이버 상태
• 보호 동작 발생 여부

따라서 재현 실험에서는 증상이 발생하는 조건과 실제 장애를 발생시킨 구성요소를 구분해서 확인해야 한다.

6. 장애 발생 조건을 하나씩 제거해 본다

재현 조건을 찾았다면 반대로 특정 조건을 제거했을 때 장애가 사라지는지도 확인할 수 있다.

예를 들어 다음과 같은 조건에서 장애가 발생한다고 가정한다.

고부하 + 고온 + 장시간 운전

이때 각각의 조건을 제거하면서 비교할 수 있다.

조건	장애 발생
고부하 + 고온 + 장시간	발생
고부하 + 정상 온도 + 장시간	미발생
낮은 부하 + 고온 + 장시간	미발생
고부하 + 고온 + 짧은 시간	미발생

이 결과만으로 근본원인을 확정할 수는 없지만, 온도·부하·지속시간이 장애 발생에 관여할 가능성을 좁혀갈 수 있다.

이후 실제 구성요소의 상태와 로그, 성능 데이터를 연결하여 원인을 검증해야 한다.

7. 장애 발생 임계조건을 찾는다

일부 장애는 특정 수준을 넘어선 뒤 발생한다.

예를 들어 다음과 같은 패턴이 나타날 수 있다.

정상 부하 → 정상

부하 증가 → 정상

추가 부하 → 성능 저하

특정 수준 이상 → 오류 발생

부하 감소 → 정상 복귀

이 경우 중요한 것은 단순히 “부하가 높았다”는 사실이 아니다.

어느 범위에서 상태가 변하기 시작했는지, 그리고 그 변화가 반복되는지를 확인하는 것이 중요하다.

다만 특정 임계값을 찾았다고 해서 그 값 자체를 시스템의 근본원인으로 볼 수는 없다.

임계값은 장애가 나타나기 시작하는 조건을 설명하는 기준일 수 있으며, 그 아래에 실제 원인이 존재할 수 있다.

8. 간헐적 장애는 ‘재현되지 않음’도 중요한 정보다

가장 어려운 장애 중 하나는 같은 작업을 반복해도 쉽게 발생하지 않는 간헐적 장애다.

예를 들어 일주일에 한 번 발생하는 장애를 짧은 시간 동안 몇 번 테스트했다고 해서 재현되지 않았다는 이유만으로 문제가 해결되었다고 판단해서는 안 된다.

이 경우에는 장애가 발생했던 사례와 정상 사례를 비교해야 한다.

항목	정상 사례	장애 사례
CPU 사용률	35%	95%
메모리 사용량	48%	91%
SSD 온도	42℃	68℃
네트워크 사용량	낮음	높음
시스템 가동시간	5시간	72시간

이러한 비교에서 특정 조건이 장애 사례에서 반복적으로 나타난다면 해당 조건은 중요한 조사 대상이 된다.

반대로 재현 실험에서 장애가 발생하지 않았다는 사실 역시 기록해야 한다.

왜냐하면 “현재 조건에서는 재현되지 않았다”는 것은 “장애가 존재하지 않는다”와 같은 의미가 아니기 때문이다.

특히 간헐적 장애에서는 재현 실패 횟수와 실험 시간 자체가 판단에 영향을 줄 수 있다.

9. 장애 직전의 변화와 재현 조건을 함께 본다

장애가 발생하는 조건을 찾는 것만으로 충분하지 않을 수도 있다.

그 조건에 들어가기 전에 어떤 변화가 있었는지도 확인해야 한다.

예를 들어 다음과 같은 흐름이 반복될 수 있다.

정상 상태
→ 메모리 사용량 증가
→ 저장장치 접근 증가
→ 응답시간 증가
→ 오류 발생
→ 서비스 중단

이때 단순히 “메모리 사용량이 높았다”는 사실만 보는 것보다 각 변화가 어떤 순서로 발생했는지를 확인하는 것이 중요하다.

Ⅴ-4의 RCA와 연결하면,

증상 → 발생 조건 → 선행 변화 → 직접 원인 후보 → 근본원인 검증

의 구조로 분석할 수 있다.

10. 장애 발생 후 정상 복귀 과정도 재현한다

장애가 발생하는 순간만큼 중요한 것이 장애 이후의 상태 변화다.

예를 들어 다음과 같은 흐름이 나타날 수 있다.

부하 증가
→ 시스템 지연
→ 오류 발생
→ 재부팅
→ 정상 작동

여기서 재부팅 후 정상 작동했다고 해서 문제가 해결되었다고 판단할 수는 없다.

재부팅으로 메모리 상태나 프로세스 상태, 장치 상태 등이 초기화되어 문제가 일시적으로 사라졌을 가능성도 있기 때문이다.

따라서 재현 실험에서는 다음도 함께 확인하는 것이 좋다.

• 장애 후 어떤 상태가 초기화되었는가?
• 재부팅 없이 정상 상태로 돌아오는가?
• 동일 조건에서 다시 장애가 발생하는가?
• 관련 로그가 남아 있는가?
• 성능 지표가 정상 범위로 돌아왔는가?
• 일정 시간 후 같은 문제가 반복되는가?

이렇게 해야 장애 발생과 일시적인 정상 복귀를 분리해서 판단할 수 있다.

11. 재현 실험은 시스템 보호를 고려해야 한다

장애를 재현한다고 해서 실제 운영 환경에서 무리하게 동일한 조건을 만들어서는 안 된다.

특히 다음과 같은 실험은 주의가 필요하다.

• 과도한 CPU 부하
• 과도한 메모리 사용
• 저장장치에 대한 지속적인 고부하
• 높은 온도를 의도적으로 유도하는 테스트
• 네트워크 장비에 대한 과도한 트래픽
• 장애 가능성이 있는 설정의 무분별한 변경

가능하다면 테스트 환경이나 별도 장비에서 수행하고, 운영 환경에서는 서비스 영향과 데이터 손상 가능성을 먼저 평가해야 한다.

재현성 분석의 목적은 장애를 많이 발생시키는 것이 아니라 안전하게 원인을 좁히는 것이다.

12. 재현성 분석 결과를 RCA와 연결한다

재현성 분석은 RCA 자체가 아니라 RCA를 검증하기 위한 중요한 자료가 될 수 있다.

전체적인 흐름은 다음과 같다.

장애 증상 확인

↓

발생 조건 기록

↓

정상 상태와 장애 상태 비교

↓

재현 가능성 확인

↓

조건 분리 및 비교 실험

↓

복합 조건 검증

↓

로그·성능·하드웨어 상태 비교

↓

원인 후보 축소

↓

원인 검증

↓

재발 방지 조치

여기서 핵심은 재현된 조건을 곧바로 근본원인으로 기록하지 않는 것이다.

재현성은 원인 후보를 좁히는 데 강력하지만, 최종 원인 판단에는 다른 증거와의 일치 여부가 필요하다.

13. 장애 재현성 분석에서 흔히 발생하는 오류

재현성 분석에서도 몇 가지 잘못된 판단이 발생할 수 있다.

• 한 번 재현되었다고 원인을 확정
• 같은 조건에서 재현되지 않았다고 원인이 아니라고 판단
• 장애 발생 당시의 조건을 기록하지 않음
• 여러 조건을 동시에 변경하고 결과만 확인
• 특정 수치 하나만 장애 조건으로 판단
• 정상 복귀 후 문제가 해결되었다고 판단
• 테스트 환경과 실제 운영 환경의 차이를 무시
• 장애 재현 과정에서 다른 변수를 통제하지 않음
• 재현 실험 자체가 시스템에 추가적인 문제를 발생시킴

따라서 재현성 분석에서는 재현 횟수보다 조건과 비교 방법의 품질이 중요하다.

14. 재현성 분석의 핵심은 ‘장애를 만드는 조건’을 찾는 것이다

장애 분석에서 단순히

“장애가 다시 발생했는가?”

만 확인하는 것은 충분하지 않다.

보다 중요한 질문은 다음과 같다.

“장애가 발생하기 위해 반드시 필요한 조건은 무엇인가?”

그리고 한 단계 더 나아가

“그 조건 중 어떤 요소가 장애 발생에 실제로 영향을 주고 있는가?”

를 확인해야 한다.

예를 들어

높은 CPU 부하 + 높은 온도 + 장시간 운전

에서만 장애가 발생한다면 세 조건을 각각 따로 보는 것과 동시에 세 조건이 함께 존재할 때 장애가 나타나는지도 확인해야 한다.

이를 통해 장애를 단순한 증상이 아니라 특정 조건에서 발생하는 사건으로 분석할 수 있다.

15. V-1부터 V-5까지의 장애 분석 흐름

Ⅴ-1부터 Ⅴ-5까지는 서로 다른 역할을 가진다.

Ⅴ-1. 장애 진단 절차와 원인 추적

장애가 발생했을 때 전체적으로 어떤 순서로 진단할 것인가를 다룬다.

Ⅴ-2. 하드웨어 장애와 소프트웨어 장애의 구분

원인 후보를 하드웨어와 소프트웨어 영역으로 어떻게 좁혀갈 것인가를 다룬다.

Ⅴ-3. 시스템 로그 기반 장애 원인 추적

로그와 성능 데이터를 시간축으로 연결하여 장애 전후의 사건을 추적한다.

Ⅴ-4. 장애 증상과 근본원인(RCA) 분석

증상, 직접 원인, 근본원인, 기여 요인을 구분하고 재발 방지로 연결한다.

Ⅴ-5. 장애 재현성과 발생 조건 분석

장애가 어떤 조건에서 발생하는지 확인하고, 조건을 통제·비교하여 원인 후보를 검증할 수 있는 수준으로 좁힌다.

즉,

Ⅴ-3은 무엇이 언제 발생했는지를 추적하고,
Ⅴ-4는 그것이 어떤 원인 관계를 가지는지 분석하며,
Ⅴ-5는 그 관계를 조건을 재현하고 비교하여 검증하는 단계라고 볼 수 있다.

16. 핵심정리

장애 재현성은 단순히 같은 장애를 다시 발생시키는 것이 아니다.

장애가 발생한 조건을 기록하고 → 정상 상태와 비교하고 → 조건을 분리하고 → 재현 여부를 확인하고 → 원인 후보를 검증하는 과정이다.

특히 간헐적 장애에서는 재현되지 않았다는 사실만으로 문제가 없다고 판단해서는 안 된다.

중요한 것은 장애가 발생한 순간의 부하, 온도, 메모리, 저장장치, 전원, 프로그램, 네트워크, 사용시간, 변경 상태 등을 정상 사례와 비교하는 것이다.

그리고 재현성이 높아졌다고 해서 그것을 곧바로 근본원인으로 판단해서도 안 된다.

재현성은 원인을 확정하는 것이 아니라 원인을 검증할 수 있는 조건을 만들어 주는 것이다.

결국 Ⅴ-5의 핵심은 이것이다.

“장애가 다시 발생했는가?”보다
“어떤 조건이 충족되었을 때 장애가 발생하며, 그 조건을 제거하거나 변경했을 때 장애도 함께 달라지는가?”

이 질문까지 확인할 수 있어야 장애 분석이 단순한 경험적 추측에서 조건과 증거를 기반으로 한 진단으로 발전한다.