Ⅴ-9. 컴퓨터 장애 원인분석 데이터 품질과 불확실성 분석

컴퓨터 장애의 원인을 분석할 때 로그와 성능 데이터는 중요한 근거가 된다.

하지만 기록된 데이터가 항상 완전하거나 정확한 것은 아니다.

로그가 누락될 수 있고, 여러 시스템의 시간이 서로 다를 수 있으며, 측정값에도 수집 주기와 측정 방식에 따른 한계가 존재한다.

또한 장애가 발생한 직후 시스템이 중단되면 오히려 가장 중요한 장애 직전의 데이터가 남지 않을 수도 있다.

따라서 장애 원인을 분석할 때는 단순히 많은 데이터를 확보하는 것보다 그 데이터가 원인 판단에 사용할 수 있을 정도로 신뢰할 수 있는지를 먼저 평가해야 한다.

Ⅴ-8에서는 구성요소 사이의 의존관계와 장애 전파 경로를 분석했다.

Ⅴ-9에서는 그 분석에 사용되는 로그와 측정 데이터 자체의 품질과 불확실성을 검토한다.

즉,

“무슨 데이터가 있는가?”에서 한 단계 더 나아가
“그 데이터를 어느 정도까지 믿을 수 있는가?”

를 판단하는 과정이다.

1. 장애 분석에서 데이터 품질이 중요한 이유

장애 원인분석은 대부분 관찰된 데이터를 바탕으로 이루어진다.

대표적인 데이터는 다음과 같다.

• 시스템 로그
• 이벤트 기록
• 오류 코드
• CPU 사용률
• 메모리 사용량
• 저장장치 I/O
• 온도 데이터
• 네트워크 상태
• 응용프로그램 로그
• 장치 상태 정보
• 사용자 장애 기록

문제는 데이터가 존재한다고 해서 곧바로 신뢰할 수 있는 증거가 되는 것은 아니라는 점이다.

예를 들어 로그가 기록되어 있더라도 시간이 잘못되어 있거나 특정 구간이 누락되어 있다면 장애 발생 순서를 잘못 판단할 수 있다.

따라서 다음 두 가지는 반드시 구분해야 한다.

데이터가 존재한다.

≠

그 데이터를 원인 판단의 근거로 신뢰할 수 있다.

장애 분석에서는 데이터의 양보다 데이터의 품질과 해석 가능성이 중요하다.

2. 데이터의 완전성을 먼저 확인한다

장애 분석을 시작하기 전에 필요한 시간대의 데이터가 충분히 존재하는지 확인해야 한다.

예를 들어 장애가 14시 05분에 발생했는데 시스템 로그가 14시 04분까지만 존재한다면 장애 직전의 상태를 정확하게 확인하기 어렵다.

다음 항목을 확인할 수 있다.

• 장애 발생 전 데이터가 존재하는가?
• 장애 발생 시점의 데이터가 존재하는가?
• 장애 직후 데이터가 남아 있는가?
• 특정 시간대의 로그가 누락되어 있지는 않은가?
• 특정 장치의 데이터만 중단되지 않았는가?
• 로그 저장 공간 부족이나 수집 중단이 있었는가?

특히 장애 직전 데이터의 부재는 중요하다.

원인이 장애 직전에 발생했는데 그 구간의 데이터가 없다면 원인 후보를 직접 확인할 수 없기 때문이다.

따라서 데이터가 없는 구간은 단순히 빈 구간으로 취급하지 말고 왜 데이터가 존재하지 않는지부터 확인해야 한다.

3. 로그가 없는 이유를 확인한다

로그가 없다는 사실만으로 해당 시간에 아무런 이벤트가 없었다고 판단해서는 안 된다.

데이터가 누락되는 원인은 다양할 수 있다.

• 저장 공간 부족
• 로그 서비스 중단
• 시스템 강제 종료
• 장치 장애
• 네트워크 단절
• 로그 수집기 장애
• 로그 보존 기간 만료
• 기록 설정 변경
• 시스템 자체의 심각한 오류

예를 들어 시스템이 갑자기 전원 차단으로 종료되었다면 장애 직전의 일부 로그가 디스크에 기록되기 전에 사라질 수도 있다.

따라서

로그 없음 = 이벤트 없음

이라는 판단은 위험하다.

오히려 로그가 어느 시점부터 사라졌는가, 왜 사라졌는가를 확인하는 것이 장애 분석의 중요한 단서가 될 수 있다.

4. 시간축의 신뢰성을 확인한다

Ⅴ-8에서 살펴본 것처럼 장애 원인을 추적할 때 시간 순서는 매우 중요하다.

예를 들어 다음 두 가지는 원인 해석이 완전히 달라질 수 있다.

저장장치 오류 → I/O 지연 → 프로그램 오류

또는

프로그램 오류 → I/O 이상 → 저장장치 오류

하지만 서로 다른 시스템의 시간이 맞지 않으면 실제 발생 순서를 잘못 판단할 수 있다.

따라서 로그를 비교하기 전에 다음을 확인해야 한다.

• 시스템 시간이 정확한가?
• 시간대(time zone)가 동일한가?
• 로그의 타임스탬프 기준이 무엇인가?
• 서로 다른 장비의 시간이 동기화되어 있는가?
• 수집 과정에서 시간 변환이 발생했는가?
• 이벤트 발생과 로그 기록 사이에 지연이 있을 수 있는가?

특히 로그에 기록된 시간이 실제 이벤트가 발생한 시간과 항상 동일하다고 볼 수는 없다.

이벤트가 발생한 뒤 로그가 생성되고 저장되거나 다른 시스템으로 전달되는 과정에서 시간 차이가 발생할 수 있기 때문이다.

따라서

로그 기록 시간 = 실제 장애 발생 시간

이라고 항상 단정해서는 안 된다.

시간 정보가 불확실한 경우에는 정확한 시각 하나만 기준으로 판단하기보다,

발생 구간 → 선후관계 → 다른 데이터와의 일치 여부

를 함께 확인하는 것이 안전하다.

5. 성능 데이터의 측정 한계를 확인한다

CPU, 메모리, I/O, 온도, 네트워크 등의 성능 데이터도 측정값이라는 점을 잊어서는 안 된다.

예를 들어 CPU 사용률이 90%라고 해서 CPU 자체에 장애가 있다는 의미는 아니다.

정상적인 고부하 작업에서도 높은 CPU 사용률이 나타날 수 있다.

마찬가지로 다음과 같은 값도 단독으로 원인을 확정할 수 없다.

• 높은 메모리 사용량
• 높은 CPU 사용률
• 높은 저장장치 I/O
• 높은 온도
• 높은 네트워크 사용량

중요한 것은 값 자체보다 정상 상태와 비교했을 때 얼마나 달라졌는지, 그리고 장애와 어떤 시간 관계를 가지고 있는지이다.

따라서 측정값을 볼 때는 다음을 함께 확인해야 한다.

• 평상시 수준
• 장애 발생 전 변화
• 장애 발생 시점의 변화
• 장애 이후 변화
• 다른 데이터와의 관계

6. 수집 주기와 측정 방식의 한계를 확인한다

성능 데이터는 연속적으로 기록되는 것처럼 보이더라도 실제로는 일정한 간격으로 수집되는 경우가 많다.

예를 들어 1분마다 데이터를 수집한다면 10초 동안 발생한 짧은 이상 현상이 기록되지 않을 수 있다.

반대로 순간적인 이상이 평균값으로 표현되면 실제 변화의 크기가 작게 보일 수도 있다.

따라서 다음 사항을 확인해야 한다.

• 데이터 수집 주기
• 순간값인지 평균값인지
• 최대값 또는 최소값인지
• 샘플링이 이루어지는지
• 짧은 이상 현상이 누락될 가능성이 있는지
• 측정 데이터의 시간 단위가 장애 현상의 시간 규모와 적절한지

예를 들어 수 초 동안 발생한 장애를 1분 단위 평균값만으로 분석한다면 장애 순간의 중요한 변화가 데이터에 나타나지 않을 수 있다.

따라서 측정 데이터의 분해능이 분석하려는 장애 현상을 설명하기에 충분한지도 확인해야 한다.

7. 상관관계와 원인관계를 구분한다

장애 분석에서 흔히 발생하는 오류 중 하나는 같은 시간에 발생한 현상을 원인으로 판단하는 것이다.

예를 들어 시스템이 느려지는 순간 CPU 사용률도 증가했다고 가정하자.

가능성은 두 가지 이상이다.

CPU 사용량 증가 → 시스템 지연

일 수도 있고,

다른 장애 발생 → 처리 방식 변화 → CPU 사용량 증가

일 수도 있다.

따라서

CPU 사용률 증가와 시스템 지연이 동시에 발생했다.

라는 사실만으로

CPU가 원인이다.

라고 결론 내릴 수 없다.

시간 순서와 관련 로그, 다른 성능 데이터, 구성요소 상태, 장애 재현 결과 등을 함께 확인해야 한다.

즉,

같이 발생했다는 사실과 원인이라는 판단은 구분해야 한다.

8. 서로 다른 데이터의 일치성을 확인한다

하나의 데이터만으로 판단하기보다 서로 다른 출처의 자료를 비교하면 원인 판단의 신뢰도를 높일 수 있다.

예를 들어 특정 장애가 발생했을 때 다음 자료를 함께 확인할 수 있다.

• 사용자 장애 발생 기록
• 운영체제 로그
• 응용프로그램 로그
• 하드웨어 상태
• 성능 모니터링 데이터
• 네트워크 기록

만약 여러 자료가 비슷한 시간대에 서로 연결되는 변화를 보여준다면 하나의 자료만 사용했을 때보다 원인 후보에 대한 근거가 강해질 수 있다.

반대로 자료들이 서로 다른 시간을 가리키거나 서로 모순되는 결과를 보인다면 어느 데이터가 잘못되었거나 서로 다른 기준으로 수집되었는지부터 확인해야 한다.

데이터가 서로 일치하지 않는다는 사실도 중요한 분석 결과다.

9. 정상 데이터와 장애 데이터를 비교한다

장애 데이터만 보면 무엇이 비정상인지 판단하기 어려울 수 있다.

따라서 가능하면 동일 시스템의 정상 상태 데이터를 함께 비교해야 한다.

항목	정상 상태	장애 상태	추가 확인
CPU 사용률	40%	92%	작업 부하 변화
메모리 사용량	55%	94%	실제 메모리 압박 여부
SSD I/O	낮음	급증	I/O 지연과 오류 기록
온도	안정적	상승	부하·냉각 상태
오류 로그	없음	반복 발생	발생 시점과 선후관계

이렇게 비교하면 장애 시점의 변화가 보다 명확해진다.

하지만 정상과 장애 사이에 차이가 있다는 것 자체가 원인을 증명하지는 않는다.

그 차이가 장애보다 먼저 나타났는지, 장애와 반복적으로 연결되는지, 다른 원인으로도 설명할 수 있는지를 추가로 확인해야 한다.

10. 데이터의 증거 수준을 구분한다

모든 데이터를 동일한 수준의 증거로 취급하지 않는 것이 중요하다.

다음과 같이 단계적으로 구분할 수 있다.

1단계 — 관찰

특정 현상이 실제로 기록되었다.

예:

“14시 05분에 저장장치 오류 로그가 기록됨.”

2단계 — 연관성

특정 현상과 장애가 같은 시간대에 나타나거나 반복적으로 함께 나타난다.

예:

“저장장치 오류가 발생할 때 I/O 지연도 증가하는 경향이 확인됨.”

3단계 — 원인 후보

여러 데이터와 시간 관계를 종합했을 때 특정 구성요소가 원인 후보로 좁혀진다.

4단계 — 검증

구성요소 격리, 조건 변경, 반복 테스트 등을 통해 장애 상태의 변화가 재현되는지 확인한다.

5단계 — 원인 판단

다른 가능한 설명까지 검토한 뒤 해당 원인이 장애를 가장 일관되게 설명하는지 판단한다.

이러한 단계 구분은 확인된 사실과 분석자의 판단을 섞지 않도록 하는 데 도움이 된다.

11. 데이터의 불확실성을 명확하게 기록한다

실제 장애 분석에서 모든 정보를 완벽하게 확보하는 것은 어렵다.

따라서 좋은 분석은 모든 것을 확정하는 분석이 아니라 확실한 것과 확실하지 않은 것을 구분하는 분석이다.

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

• 장애 발생 사실: 확인됨
• 장애 발생 시간: 약 ±수 초 오차 가능
• 저장장치 오류: 확인됨
• I/O 지연 증가: 확인됨
• 저장장치와 프로그램 장애의 연결: 높은 가능성
• 저장장치 자체가 근본원인인지 여부: 추가 검증 필요

이렇게 기록하면 분석 결과를 과도하게 확정하는 것을 방지할 수 있다.

중요한 것은 불확실성을 없애는 것이 아니라 어디까지 알고 있고 어디부터 모르는지를 명확하게 만드는 것이다.

12. 데이터가 부족하면 결론의 범위를 줄인다

데이터가 부족한 상황에서 가장 위험한 것은 부족한 증거를 이용해 지나치게 구체적인 결론을 만드는 것이다.

예를 들어 저장장치 오류 로그 하나만 존재한다면

“SSD 자체의 하드웨어 고장으로 프로그램 장애가 발생했다.”

라고 확정하기보다,

“저장장치 관련 이상이 확인되었으며 프로그램 장애와의 연결 가능성이 있으므로 저장장치 및 I/O 경로에 대한 추가 검증이 필요하다.”

라고 판단하는 것이 더 정확하다.

즉,

증거가 부족할수록 결론도 그 범위에 맞게 제한해야 한다.

이것이 불확실성을 관리하는 중요한 원칙이다.

13. 데이터가 부족할 때 다른 자료로 불확실성을 줄인다

실제 장애에서는 데이터가 충분하지 않은 경우가 많다.

이때 분석을 중단해야 하는 것은 아니다.

하나의 데이터가 부족하다면 다른 독립적인 자료를 이용해 현재의 불확실성을 줄일 수 있다.

예를 들어 장애 직전 로그가 없다면 다음과 같은 자료를 추가로 확인할 수 있다.

• 다른 시스템의 로그
• 원격 로그
• 네트워크 장비 기록
• 하드웨어 이벤트
• 사용자 장애 발생 시간
• 응용프로그램 기록
• 장애 이후 상태 변화
• 동일 장애의 과거 사례

다만 자료를 추가했다고 해서 자동으로 신뢰도가 높아지는 것은 아니다.

각 자료의 시간 기준과 수집 방식, 누락 가능성도 함께 검토해야 한다.

14. 장애 분석에서 ‘모르는 것’을 기록한다

전문적인 장애 분석에서는 확인된 사실뿐 아니라 확인하지 못한 부분도 기록할 필요가 있다.

예를 들어 다음과 같이 구분할 수 있다.

확인된 사실

• 14시 05분경 서비스 응답 지연 발생
• 동일 시점에 I/O 지연 증가
• 저장장치 오류 로그 확인

추정되는 내용

• 저장장치 관련 이상이 서비스 지연에 영향을 주었을 가능성

확인하지 못한 내용

• 저장장치 자체의 물리적 고장 여부
• 인터페이스 또는 드라이버의 영향
• 장애 직전 10초간의 상세 상태

이렇게 구분하면 나중에 추가 자료가 확보되었을 때 어떤 부분을 다시 검증해야 하는지 명확해진다.

모르는 것을 기록하는 것은 분석의 부족함을 인정하는 것이 아니라, 추가 검증이 필요한 영역을 명확하게 표시하는 것이다.

15. 데이터 품질을 높이는 방법

장애가 발생한 뒤 데이터를 수집하는 것만으로는 한계가 있다.

평상시부터 필요한 데이터를 안정적으로 기록해야 장애가 발생했을 때 정상 상태와 비교할 수 있다.

대표적으로 다음과 같은 관리가 필요하다.

• 주요 시스템 로그 보존
• 핵심 성능지표 기록
• 장치 상태 모니터링
• 온도 및 전원 상태 기록
• 오류 이벤트 보존
• 시스템 시간 동기화
• 로그 수집 상태 점검
• 충분한 저장 공간 확보
• 장애 발생 시점 기록
• 정상 상태의 기준 데이터 확보

특히 중요한 것은 장애 데이터뿐 아니라 정상 데이터도 함께 보존하는 것이다.

정상 상태를 모르면 장애 시점의 변화가 실제로 비정상인지 판단하기 어렵기 때문이다.

16. 데이터 품질 점검표를 활용한다

장애 원인분석을 시작하기 전에 다음과 같은 질문을 확인하면 데이터 품질 문제를 빠르게 찾을 수 있다.

점검 항목	확인 질문
완전성	장애 전후의 필요한 데이터가 존재하는가?
시간	시스템과 로그의 시간이 일치하는가?
기록 지연	실제 발생과 기록 사이의 지연 가능성이 있는가?
수집 주기	짧은 이상 현상이 누락될 가능성이 있는가?
측정 방식	순간값·평균값·최대값 등 데이터의 성격을 알고 있는가?
일관성	서로 다른 데이터가 같은 현상을 가리키는가?
정상 기준	비교할 정상 상태 데이터가 있는가?
누락	데이터가 사라진 구간과 그 원인을 확인했는가?
반복성	동일한 현상이 다른 사례에서도 확인되는가?
대체 설명	다른 원인으로도 현재 결과를 설명할 수 있는가?
불확실성	현재 확인하지 못한 부분은 무엇인가?

이 표의 목적은 데이터를 단순히 많이 확보하는 것이 아니라 원인 판단에 사용하기 전에 데이터 자체를 검증하는 것이다.

17. 데이터 품질과 RCA를 연결하는 방법

RCA를 수행할 때 데이터 품질 검토는 별도의 마지막 단계가 아니라 초기부터 함께 이루어져야 한다.

전체 흐름은 다음과 같이 구성할 수 있다.

장애 데이터 수집

↓

데이터 완전성 확인

↓

시간 정보 검증

↓

측정·수집 방식 확인

↓

정상 상태와 비교

↓

데이터 간 일치성 확인

↓

원인 후보 설정

↓

구성요소 격리 및 반복 검증

↓

불확실성 평가

↓

근본원인 판단

초기 데이터가 잘못되어 있으면 이후의 분석이 아무리 정교해도 잘못된 결론에 도달할 수 있다.

따라서 RCA의 품질은 분석 방법뿐 아니라 분석에 사용하는 데이터의 품질에도 영향을 받는다.

18. V-1부터 V-9까지의 장애 진단 흐름

지금까지의 내용은 다음과 같이 연결된다.

• V-1. 장애 진단 절차 — 전체적인 장애 조사 흐름 설정
• V-2. 하드웨어·소프트웨어 구분 — 원인 후보 영역 좁히기
• V-3. 로그 기반 원인 추적 — 시간축에 따른 사건 추적
• V-4. 장애 증상과 근본원인 분석 — 증상·직접원인·근본원인·기여요인 구분
• V-5. 장애 재현성과 발생 조건 분석 — 장애가 발생하는 조건 확인
• V-6. 계층별 장애 진단 — 이상이 시작된 계층의 범위 축소
• V-7. 장애 격리와 원인 구성요소 식별 — 원인 후보 구성요소를 분리·비교
• V-8. 구성요소 의존관계와 장애 원인 연결 분석 — 구성요소 간 연결과 장애 전파 경로 분석
• V-9. 데이터 품질과 불확실성 분석 — 앞선 판단에 사용된 데이터 자체의 신뢰성 검토

따라서 V-9는 앞선 분석을 반복하는 단계가 아니다.

앞에서 찾아낸 원인 후보와 장애 경로가 신뢰할 수 있는 데이터에 의해 뒷받침되고 있는지 확인하는 단계다.

19. 핵심정리

장애 원인분석에서 데이터는 중요한 증거지만, 데이터가 존재한다는 사실만으로 그 데이터가 정확한 증거가 되는 것은 아니다.

데이터를 사용하기 전에 다음을 확인해야 한다.

완전성 → 시간 정확성 → 측정 한계 → 데이터 간 일치성 → 정상 상태 비교 → 반복성 → 대체 설명 → 불확실성

특히 기억해야 할 두 가지가 있다.

로그가 없다는 것은 반드시 이벤트가 없었다는 뜻이 아니다.

데이터가 장애와 함께 변했다는 것은 반드시 그 데이터가 장애의 원인이라는 뜻도 아니다.

결국 정확한 장애 분석은

데이터 확보 → 데이터 품질 검토 → 시간축 검증 → 정상·장애 비교 → 원인 후보 설정 → 추가 검증 → 불확실성 기록

의 과정을 거쳐야 한다.

그리고 분석 과정에서 확인할 수 없는 부분을 억지로 확정하지 않는 것도 전문적인 분석의 일부다.

우리 시스템의 장애 분석 기록을 다시 살펴본다면,

“우리는 장애 원인을 찾을 때 데이터의 내용만 보고 있는가, 아니면 그 데이터를 원인 판단에 사용할 수 있을 만큼 신뢰할 수 있는지도 함께 확인하고 있는가?”