컴퓨터 장애가 발생했을 때 가장 먼저 확인되는 증상이 실제 원인이라고 단정할 수는 없다.

시스템이 느려졌다고 해서 CPU가 원인이라고 할 수 없고, 애플리케이션이 멈췄다고 해서 애플리케이션 자체에 문제가 있다고 확정할 수도 없다.

하나의 증상이 여러 구성요소에서 발생할 수 있고, 하나의 장애가 여러 계층을 거쳐 최종적인 증상으로 나타날 수 있기 때문이다.

따라서 장애 진단에서는 처음부터 하나의 원인을 확정하기보다 원인 가설을 세우고, 각 가설이 맞다면 나타나야 할 증거를 확인한 뒤 실제 데이터와 비교하는 과정이 필요하다.

Ⅴ-10에서 자동화된 장애 진단이 원인 후보를 빠르게 좁혀주는 방법을 살펴봤다면, Ⅴ-11에서는 그 후보를 실제 장애 원인으로 확정하기 전에 어떻게 검증해야 하는가를 다룬다.

1. 장애 진단에서 원인 가설이 필요한 이유

장애가 발생하면 사람이 가장 먼저 확인하는 것은 눈에 띄는 증상이다.

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

• 시스템 응답시간 증가
• 애플리케이션 멈춤
• CPU 사용률 증가
• 메모리 사용량 증가
• 저장장치 응답시간 증가
• 네트워크 지연
• 특정 프로세스 오류

문제는 이 중 어느 하나가 나타났다고 해서 바로 원인을 확정할 수 없다는 것이다.

예를 들어 CPU 사용률 증가가 관찰되었다고 하자.

CPU가 원인일 수도 있지만 저장장치 지연으로 작업이 밀리면서 CPU 관련 지표가 변했을 가능성도 있고, 특정 프로세스의 비정상적인 동작이 다른 장애의 결과로 나타났을 수도 있다.

따라서 장애 분석은 다음과 같은 구조로 접근하는 것이 안전하다.

관찰된 증상 → 원인 가설 생성 → 가설이 맞다면 나타날 증거 정의 → 실제 데이터 비교 → 가설 검증 또는 기각 → 원인 후보 압축 → 최종 검증

이 과정을 거쳐야 처음 눈에 띈 현상을 실제 원인으로 착각하는 것을 줄일 수 있다.

2. 원인 가설과 실제 원인은 구분해야 한다

장애 발생 직후에는 대부분 정확한 원인이 확정되어 있지 않다.

예를 들어 서버 응답시간이 갑자기 증가했다면 다음과 같은 가설을 세울 수 있다.

• CPU 처리량 부족
• 메모리 압박
• 저장장치 지연
• 네트워크 지연
• 데이터베이스 처리 지연
• 특정 프로세스 이상
• 드라이버 또는 운영체제 문제
• 애플리케이션 내부 오류

이때 중요한 것은 가설을 세우는 것 자체가 원인을 찾았다는 의미가 아니라는 점이다.

가설은 현재까지 확인된 증상을 설명할 수 있는 후보일 뿐이다.

따라서 다음 단계에서는 각각의 가설에 대해

“이 가설이 실제 원인이라면 어떤 데이터가 먼저 나타나야 하는가?”

를 생각해야 한다.

예를 들어 저장장치 문제를 의심한다면 단순히 I/O가 높았는지만 보는 것이 아니라 장애 이전의 I/O 지연, 관련 오류, 장치 상태, 동일 조건에서의 반복성 등을 함께 확인해야 한다.

3. 가설을 검증할 때 확인해야 할 데이터

원인 검증에서는 하나의 지표만 확인하기보다 여러 데이터를 같은 시간축에서 비교하는 것이 중요하다.

확인 대상	주요 데이터	확인 목적
CPU	사용률, Load, 실행 큐, 프로세스별 CPU	실제 처리 부담과 프로세스 관계 확인
메모리	사용량, 가용 메모리, Swap, 메모리 압박 관련 지표	단순 사용량 증가와 실제 메모리 부족 구분
저장장치	IOPS, 처리량, 지연시간, 오류 이벤트	I/O 지연과 장치 상태 확인
네트워크	지연시간, 오류, 손실, 연결 상태, 처리량	통신 경로 이상 여부 확인
프로세스	CPU·메모리 사용량, 상태, 실행시간	특정 프로세스와 장애의 관계 확인
운영체제	이벤트 로그, 시스템 오류, 상태 변화	OS 수준의 이상 여부 확인
애플리케이션	오류 코드, 요청 처리시간, 예외, 응답 상태	서비스 수준의 장애 확인
데이터베이스	Query 지연, Connection 상태, 오류	데이터 처리 계층의 문제 확인
변경 이력	업데이트, 설정 변경, 배포, 작업	장애 직전 환경 변화 확인

여기서 중요한 것은 데이터가 존재하는 것과 그 데이터가 원인을 설명하는 것은 서로 다르다는 점이다.

CPU가 높았다는 사실은 관찰 결과이고, CPU가 장애를 발생시켰다는 것은 별도의 검증이 필요한 판단이다.

4. 시간 순서가 원인 판별에 중요한 이유

장애 분석에서는 단순히

“무엇이 높았는가?”

보다

“무엇이 먼저 변했는가?”

가 중요할 수 있다.

예를 들어 다음과 같은 순서가 확인되었다고 하자.

저장장치 지연 증가 → 애플리케이션 응답 지연 → CPU 관련 대기 증가 → 서비스 타임아웃

이 경우 CPU 관련 지표의 변화만 보고 CPU를 최초 원인으로 판단하면 잘못된 결론에 도달할 수 있다.

반대로 다음과 같은 흐름이 반복적으로 확인된다면 상황이 달라진다.

특정 프로세스 CPU 급증 → 시스템 처리 지연 → 서비스 응답시간 증가 → 타임아웃

이 경우 해당 프로세스는 중요한 원인 후보가 된다.

그러나 이 경우에도 시간 순서만으로 원인을 확정해서는 안 된다.

시간적 선후관계는 원인 검증에 중요한 증거이지만, 그 자체가 인과관계의 증명은 아니다.

5. 각 가설이 맞다면 나타나야 할 증거를 먼저 정한다

원인 가설을 검증할 때 단순히 관련 데이터를 모으는 것보다 가설별 예상 증거를 먼저 정의하는 것이 효과적이다.

예를 들어 CPU 과부하를 가설로 세웠다면 다음과 같은 증거를 예상할 수 있다.

가설 A — CPU 처리 부담 증가

확인할 내용

• 장애 직전 CPU 사용량 변화
• 특정 프로세스의 CPU 사용량 증가
• 실행 큐 또는 처리 지연 변화
• CPU 증가와 서비스 지연의 시간 관계
• 정상 상태와 비교했을 때의 차이

반대로 CPU 사용률이 높았지만 평소에도 같은 수준이었고 장애 직전에 특별한 변화가 없다면 CPU 가설의 우선순위를 낮출 수 있다.

가설 B — 메모리 관련 문제

확인할 내용

• 가용 메모리 변화
• 메모리 압박 관련 지표
• Swap 또는 페이지 활동
• 특정 프로세스의 메모리 증가
• 메모리 상태 변화와 장애 발생의 시간 관계

단순히 메모리 사용률이 높다는 이유만으로 메모리 부족을 확정해서는 안 된다.

가설 C — 저장장치 지연

확인할 내용

• 저장장치 지연시간 변화
• I/O 대기 변화
• IOPS와 처리량 변화
• 장치 오류 이벤트
• 특정 장치 또는 경로에 집중된 이상 여부

이처럼 가설마다 예상되는 증거를 먼저 정해 놓으면 분석자가 보고 싶은 데이터만 선택하는 오류를 줄일 수 있다.

6. 원인 후보를 제거할 때도 반대 증거를 확인해야 한다

장애 진단에서는 가설과 일치하는 데이터만 찾으면 안 된다.

오히려 가설과 맞지 않는 데이터가 있는지 확인하는 것도 중요하다.

예를 들어 CPU 과부하를 의심하고 있는데

• CPU 증가가 장애 이후에만 나타났고
• 장애 이전에는 정상 범위였으며
• 다른 시스템에서는 같은 CPU 수준에서도 장애가 없었고
• 특정 저장장치 오류가 먼저 발생했다면

CPU를 원인으로 볼 근거는 약해진다.

따라서 가설 검증은 다음 두 가지를 함께 봐야 한다.

가설을 지지하는 증거 + 가설과 맞지 않는 증거

이 과정을 거쳐야 특정 원인에만 집중하는 확증 편향을 줄일 수 있다.

7. 정상 상태와 장애 상태를 비교해야 한다

장애가 발생한 순간의 데이터만 보면 어떤 값이 평소와 다른지 판단하기 어렵다.

따라서 가능하다면 정상 상태와 장애 상태를 비교해야 한다.

항목	정상 상태	장애 상태	해석
CPU	40%	85%	증가 확인
메모리	55%	78%	증가 확인
저장장치 지연	낮음	급증	추가 확인 필요
네트워크 지연	정상 범위	증가	추가 확인 필요
특정 프로세스	안정적	CPU 급증	원인 후보
오류 로그	없음	반복 발생	시간 관계 확인

여기서도 단순히 장애 상태에서 값이 높아졌다는 이유만으로 원인을 확정해서는 안 된다.

중요한 것은

정상과 장애 사이에서 무엇이 달라졌는가 → 그 변화가 언제 시작되었는가 → 실제 장애와 반복적으로 연결되는가

를 확인하는 것이다.

8. 단일 지표보다 여러 증거의 일치 여부를 확인한다

하나의 지표만으로 원인을 확정하면 오판 가능성이 높아진다.

예를 들어 저장장치 지연시간이 증가했다고 해서 반드시 저장장치 자체의 고장이라고 볼 수는 없다.

상위 애플리케이션의 요청 증가나 다른 시스템 상태 변화가 I/O 증가에 영향을 주었을 가능성도 있기 때문이다.

반대로 다음과 같은 자료가 같은 시간축에서 함께 나타난다면 저장장치 관련 가설의 우선순위를 높일 수 있다.

• 저장장치 지연 증가
• I/O 대기 증가
• 관련 장치 오류 이벤트
• 특정 저장장치에 집중된 현상
• 장애 직전부터 반복되는 패턴

이것 역시 원인 확정이 아니라 여러 독립적인 증거가 같은 방향을 가리키는지 확인하는 과정이다.

단, 여러 데이터가 같은 원천에서 파생된 값이라면 단순히 데이터 개수가 많다고 증거가 독립적으로 증가하는 것은 아니므로 이 점도 주의해야 한다.

9. 원인 가설을 비교표로 관리하면 진단이 쉬워진다

복잡한 장애에서는 머릿속으로 여러 가설을 관리하기 어렵다.

따라서 다음과 같이 가설별 증거를 기록하면 판단 과정이 명확해진다.

원인 가설	지지 증거	반대 증거	현재 판단
CPU 과부하	특정 프로세스 CPU 급증	장애 직전 CPU는 정상	우선순위 낮춤
메모리 문제	메모리 압박 증가	장애와 직접적인 시간 관계 부족	추가 확인
저장장치 지연	I/O 지연과 오류가 선행	장치 자체 오류는 미확인	우선 확인
네트워크 문제	지연 증가	내부 서비스도 동일 증상	추가 검증

이 방식의 장점은 왜 특정 가설의 우선순위를 높이거나 낮췄는지를 나중에도 설명할 수 있다는 것이다.

장애 분석은 결과만큼이나 판단 과정이 중요하다.

10. 재현과 조건 변경으로 가설을 검증한다

데이터 분석만으로 결론이 충분하지 않을 경우에는 장애가 발생하는 조건을 비교할 수 있다.

예를 들어 특정 작업량에서만 장애가 발생한다면

• 작업량을 변경했을 때 증상이 달라지는지
• 특정 기능을 제외했을 때 장애가 사라지는지
• 의심되는 구성요소를 다른 환경에서 확인했을 때 같은 현상이 나타나는지
• 특정 설정을 변경했을 때 장애 조건이 달라지는지

등을 확인할 수 있다.

하지만 여기서도 주의할 점이 있다.

장애가 재현되었다고 해서 재현 조건 자체가 곧 원인이라는 뜻은 아니다.

재현 조건은 원인과 관련된 환경을 좁혀주는 증거이며, 실제 원인을 확정하려면 다른 가능성과의 비교가 필요하다.

또한 운영 중인 시스템에서 검증할 경우 서비스 중단이나 데이터 손상을 유발하지 않도록 별도의 테스트 환경이나 안전한 검증 방법을 우선해야 한다.

11. 가설 검증과 근본원인 확인은 같은 단계가 아니다

장애 분석 과정에서 원인 후보가 상당히 좁혀졌다고 해서 바로 근본원인이라고 확정해서는 안 된다.

예를 들어 특정 저장장치에서 오류가 반복적으로 발생했다고 하자.

이것으로 저장장치가 중요한 원인 후보라는 판단은 가능하지만,

• 장치 자체 결함인지
• 연결 경로 문제인지
• 전원 문제인지
• 컨트롤러 문제인지
• 펌웨어 문제인지

를 추가로 확인해야 할 수 있다.

따라서 장애 분석에서는 다음을 구분해야 한다.

증상 확인 → 원인 후보 → 직접 원인 후보 → 기여 요인 → 근본원인 검증

특히 여러 원인이 동시에 작용한 장애라면 하나의 원인만 찾아내고 분석을 끝내서는 안 된다.

12. 진단 정확도를 높이는 것은 ‘더 많은 데이터’가 아니다

장애 분석에서 흔히 발생하는 오해는 데이터를 많이 수집하면 진단 정확도도 자동으로 높아진다는 생각이다.

그러나 데이터의 양과 진단 정확도는 동일한 개념이 아니다.

중요한 것은 다음과 같은 조건이다.

• 장애 전후 구간이 충분히 확보되어 있는가
• 시간 정보가 서로 일치하는가
• 정상 상태와 비교할 수 있는가
• 측정 주기가 적절한가
• 중요한 짧은 변화가 데이터에 묻히지 않았는가
• 서로 다른 데이터가 실제로 독립적인 증거인가
• 해당 데이터가 현재 가설을 검증하는 데 적합한가

예를 들어 1분 단위로 수집된 CPU 데이터만 가지고 5초 동안 발생한 급격한 이상을 분석한다면 필요한 정보가 이미 사라졌을 수 있다.

따라서 진단 정확도를 높이는 핵심은 데이터를 무조건 많이 모으는 것이 아니라 질문에 맞는 데이터를 적절한 시간 해상도로 확보하는 것이다.

13. 자동화된 진단 결과도 가설로 취급해야 한다

Ⅴ-10에서 살펴본 자동화된 장애 진단 시스템이 특정 원인을 높은 우선순위로 제시했다고 하더라도 그것을 곧바로 실제 원인으로 확정해서는 안 된다.

자동화 시스템이 할 수 있는 것은 대량의 데이터를 비교하여

• 어떤 이상이 먼저 발생했는지
• 어떤 구성요소가 관련되어 있는지
• 과거 장애와 유사한 패턴이 있는지
• 어떤 원인 후보가 현재 증상을 잘 설명하는지

등을 빠르게 정리하는 것이다.

하지만 최종적으로는 사람이 다음을 확인해야 할 수 있다.

자동 분석 결과 → 원인 가설 → 실제 시스템 상태 확인 → 추가 증거 확보 → 필요 시 재현 → 최종 판단

따라서 자동화 결과 역시 검증해야 할 가설 중 하나로 취급하는 것이 안전하다.

14. 진단 정확도를 높이기 위한 실무 절차

실제 장애 분석에서는 다음과 같은 절차를 사용할 수 있다.

① 장애 증상을 정확하게 정의한다.

무엇이 느려졌는지, 어떤 기능이 실패했는지, 전체 시스템인지 일부 기능인지 구분한다.

② 장애 발생 시간을 정한다.

사용자 신고 시간, 로그 시간, 성능 데이터 등을 비교하여 분석 범위를 설정한다.

③ 원인 후보를 여러 개 만든다.

처음부터 하나의 원인을 정답으로 정하지 않는다.

④ 가설별 예상 증거를 정한다.

각 가설이 맞다면 어떤 변화가 나타나야 하는지를 먼저 정한다.

⑤ 정상 상태와 비교한다.

평소에도 나타나는 변화인지 장애에 특유한 변화인지 확인한다.

⑥ 시간축을 맞춘다.

각 데이터의 시간 기준과 수집 지연을 고려하여 선후관계를 확인한다.

⑦ 지지 증거와 반대 증거를 함께 확인한다.

가설을 뒷받침하는 자료만 찾지 않는다.

⑧ 가설의 우선순위를 조정한다.

설명력이 낮은 후보를 제외하고 추가 검증이 필요한 후보를 남긴다.

⑨ 재현 또는 독립적인 방법으로 검증한다.

가능하다면 다른 환경, 다른 데이터 또는 조건 변경을 통해 확인한다.

⑩ 최종 원인을 기록하고 재발 방지에 연결한다.

무엇이 원인이었는지뿐 아니라 왜 기존 진단에서 놓쳤는지도 기록한다.

15. 진단 과정 자체를 평가해야 정확도가 높아진다

장애 분석이 끝났다면 실제 원인만 기록하고 끝내지 않는 것이 좋다.

왜 처음에 다른 원인을 의심했는가?

어떤 데이터가 잘못된 판단을 유도했는가?

어떤 증거가 실제 원인을 확인하는 데 가장 중요했는가?

어떤 데이터가 부족해서 검증에 시간이 오래 걸렸는가?

이러한 질문까지 기록하면 다음 장애에서 같은 오진을 반복할 가능성을 줄일 수 있다.

예를 들어 과거 장애에서 CPU 사용률만 보고 CPU 문제로 판단하는 경우가 반복되었다면 이후에는 CPU 수치뿐 아니라 프로세스별 CPU 사용량, 시간축, I/O 상태 등을 함께 확인하도록 진단 기준을 개선할 수 있다.

즉, 장애 진단의 정확도는 단순히 한 번의 올바른 판단으로 끝나는 것이 아니라 과거의 오진과 검증 결과를 다음 진단 절차에 반영하면서 지속적으로 개선되는 것이다.

16. 컴퓨터 장애 원인 가설 검증의 최종 구조

전체 과정을 정리하면 다음과 같다.

장애 증상 확인

↓

영향 범위 확인

↓

원인 가설 생성

↓

가설별 예상 증거 설정

↓

장애 전후 데이터 수집

↓

정상 상태와 비교

↓

시간축 정렬

↓

지지 증거와 반대 증거 비교

↓

가설별 우선순위 조정

↓

재현·독립 검증

↓

근본원인 후보 확정

↓

복구 및 결과 확인

↓

진단 과정 개선

이 구조에서 가장 중요한 것은 처음부터 정답을 맞히는 것이 아니다.

틀릴 수 있는 가설을 세우고, 실제 증거를 통해 하나씩 검증하면서 잘못된 판단을 제거해 가는 과정이 장애 진단의 핵심이다.

17. Ⅴ-11 핵심정리

컴퓨터 장애에서 가장 먼저 보이는 현상은 원인일 수도 있지만 결과일 수도 있다.

따라서 CPU 사용률, 메모리 사용량, I/O 지연, 로그 오류 등 하나의 지표만으로 원인을 확정하지 말고,

원인 가설 → 예상 증거 → 시간축 비교 → 지지·반대 증거 확인 → 재현 또는 독립 검증

의 과정을 거쳐야 한다.

그리고 진단 정확도를 높이는 가장 중요한 방법은 데이터를 무조건 많이 수집하는 것이 아니라 어떤 가설을 검증하기 위해 어떤 데이터를 어떤 시간 해상도로 확보해야 하는지를 명확하게 만드는 것이다.

결국 좋은 장애 진단은

“무엇이 이상했는가?”에서 끝나는 것이 아니라
“그것이 정말 원인이 맞는가?”를 증거로 다시 확인하는 과정이다.