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

컴퓨터 시스템 장애에서 가장 흔한 오류 중 하나는 눈에 먼저 보이는 증상을 실제 원인으로 착각하는 것이다.

시스템이 갑자기 재부팅되었다고 해서 재부팅 자체가 원인은 아니다.

전원 불안정, 과열, 메모리 오류, 드라이버 문제, 운영체제 오류, 하드웨어 장애 등 여러 원인이 재부팅이라는 동일한 증상으로 나타날 수 있다.

따라서 장애를 정확하게 분석하려면 단순히 “무슨 문제가 발생했는가?”에서 끝내지 않고,

증상 → 직접 원인 → 근본원인 → 재발 방지

의 흐름으로 원인을 구분할 필요가 있다.

여기서 중요한 것은 원인을 깊게 추측하는 것이 아니라 로그, 성능 데이터, 구성 상태, 변경 이력, 하드웨어 상태 등의 증거를 통해 각 단계의 관계를 확인하는 것이다.

1. 장애 증상과 원인은 왜 구분해야 하는가

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

대표적인 증상은 다음과 같다.

• 시스템 멈춤
• 갑작스러운 재부팅
• 부팅 실패
• 프로그램 종료
• 네트워크 연결 끊김
• 저장장치 접근 실패
• 응답시간 증가
• 오류 메시지 발생
• 서비스 접속 불가

문제는 이러한 현상이 대부분 최종적으로 나타난 결과일 수 있다는 점이다.

예를 들어 프로그램이 갑자기 종료되었다면 프로그램 자체의 문제일 수도 있지만, 메모리 오류나 운영체제 장애, 저장장치 오류, 다른 서비스의 장애가 영향을 주었을 가능성도 있다.

따라서 장애 기록에 단순히

“프로그램이 종료됨”

이라고만 남기면 다음 장애가 발생했을 때 원인을 추적하기 어렵다.

보다 useful한 기록은 다음과 같이 구분하는 것이다.

구분	확인 내용
증상	사용자가 실제로 경험한 현상
직접 원인	증상을 직접 발생시킨 기술적 사건
근본원인	직접 원인이 발생하게 된 구조적·환경적 원인
기여 요인	장애 발생 또는 확대에 영향을 준 조건
결과	서비스와 사용자에게 발생한 영향

이렇게 구분하면 보이는 현상과 실제 원인을 혼동하는 문제를 줄일 수 있다.

2. 증상 → 직접 원인 → 근본원인으로 내려가 보기

장애 원인을 분석할 때는 한 단계씩 원인을 내려가 보는 것이 유용하다.

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

저장장치에서 오류 발생
→ 운영체제의 파일 읽기 실패
→ 특정 서비스의 정상 처리 실패
→ 사용자 프로그램 오류 또는 서비스 이용 불가

여기서 사용자에게 보이는 것은 프로그램 오류나 서비스 이용 불가일 수 있다.

하지만 그것이 반드시 근본원인이라는 의미는 아니다.

반대로 저장장치 오류가 발견되었다고 해서 그것만으로 모든 장애의 근본원인이라고 확정할 수도 없다.

실제 RCA에서는 다음을 확인해야 한다.

• 저장장치 오류가 실제로 발생했는가?
• 오류 발생 시점이 장애 발생 시점과 맞는가?
• 해당 오류가 문제가 발생한 서비스에 영향을 줄 수 있는가?
• 동일한 오류가 정상 상태에서도 발생했는가?
• 다른 원인만으로도 동일한 증상을 설명할 수 있는가?
• 조치 후 동일한 문제가 다시 발생하지 않았는가?

즉, 원인의 깊이가 아니라 증거와 인과관계가 중요하다.

3. 직접 원인과 근본원인은 같은 의미가 아니다

직접 원인은 장애를 바로 발생시킨 기술적 사건을 의미할 수 있다.

반면 근본원인은 그 직접 원인이 발생하게 된 배경이나 구조적 문제까지 분석한 결과다.

예를 들어 서버가 과열되어 보호 동작으로 종료되었다고 가정해 보자.

단순하게 보면 다음과 같이 기록할 수 있다.

CPU 온도 상승 → 시스템 종료

그러나 RCA에서는 여기서 분석을 끝내지 않는다.

추가로 다음을 확인할 수 있다.

• 냉각팬이 정상적으로 동작했는가?
• 방열 구조에 문제가 있었는가?
• 먼지나 냉각계통 문제가 있었는가?
• 온도 상승을 사전에 감지할 수 있었는가?
• 경고 기준이 적절했는가?
• 경고가 발생했지만 대응되지 않았는가?
• 최근 장비 변경이나 설정 변경이 있었는가?

이 과정에서 실제 근본원인이 냉각계통 문제일 수도 있고, 유지보수 부족이나 잘못된 구성, 감시체계의 부족 등이 기여 요인으로 확인될 수도 있다.

따라서 RCA는 “무엇이 고장 났는가?”만 찾는 작업이 아니라 “왜 그 상태까지 진행되었는가?”를 확인하는 과정이라고 보는 것이 더 정확하다.

4. RCA에서 최근 변경 사항을 확인하는 이유

장애 직전에 발생한 변경은 중요한 조사 대상이다.

예를 들어 다음과 같은 변화가 있었다면 장애 발생 전후의 상태를 비교해야 한다.

• 운영체제 업데이트
• 드라이버 변경
• 장비 교체
• 펌웨어 업데이트
• 보안정책 변경
• 네트워크 구성 변경
• 프로그램 버전 변경
• 설정값 변경
• 저장장치 교체

특히 변경 직후 장애가 발생했다면 해당 변경은 우선적으로 조사할 가치가 있다.

그러나 “변경 후 장애가 발생했다”는 사실만으로 그 변경을 근본원인이라고 확정해서는 안 된다.

시간적으로 가까운 두 사건은 서로 관련이 있을 수도 있지만 우연히 겹쳤을 수도 있다.

따라서 변경 사항은 다음과 같이 검증하는 것이 좋다.

변경 발생
→ 장애 발생
→ 변경된 항목 확인
→ 장애와의 기술적 연관성 확인
→ 변경 전후 상태 비교
→ 동일 조건에서 재현 또는 비교
→ 원인 후보 확정 여부 판단

이러한 검증이 있어야 단순한 시간적 선후관계를 실제 원인으로 잘못 판단하는 것을 줄일 수 있다.

5. RCA에서는 하나의 원인만 찾으려고 하지 않는다

복잡한 컴퓨터 시스템에서는 하나의 원인만으로 장애가 발생하지 않는 경우도 많다.

예를 들어 다음과 같은 상황이 동시에 존재할 수 있다.

• 특정 프로그램의 비정상적인 자원 사용
• 높은 메모리 사용량
• 저장장치 응답 지연
• 장애 감지 지연
• 적절하지 않은 경고 기준

이 경우 어느 하나만 선택하여 “이것이 원인이다”라고 단정하면 장애가 다시 발생했을 때 같은 문제가 반복될 수 있다.

따라서 RCA에서는 필요에 따라 다음과 같이 구분할 수 있다.

직접 원인

장애를 직접 발생시킨 기술적 사건

근본원인

직접 원인이 발생하게 된 구조적 또는 관리적 원인

기여 요인

장애 발생 가능성을 높이거나 장애 범위를 확대시킨 조건

탐지·대응상의 문제

장애를 늦게 발견하거나 영향 범위를 확대시킨 요인

이렇게 보면 장애는 하나의 원인으로만 설명되는 것이 아니라 여러 조건이 결합되어 발생하거나 확대될 수 있다는 점을 확인할 수 있다.

6. 장애 발생 시점보다 이전 상태를 함께 확인해야 한다

RCA에서 중요한 것은 장애가 발생한 순간만 보는 것이 아니다.

장애 직전의 상태를 함께 확인해야 원인이 형성되는 과정을 찾을 수 있다.

예를 들어 다음과 같은 시간축을 구성할 수 있다.

시간	관찰 내용
T-30분	정상 상태
T-20분	특정 성능 지표 변화
T-10분	경고 로그 발생
T-5분	오류 증가
T-1분	서비스 응답 지연
T0	장애 발생
T+5분	복구 작업 시작
T+15분	서비스 정상화

이때 T0의 장애만 확인하면 “서비스가 중단되었다”는 사실만 알 수 있다.

하지만 T-20분부터 성능 변화와 경고가 반복되고 있었다면 장애가 갑자기 발생한 것이 아니라 장애로 이어지는 상태 변화가 이전부터 진행되고 있었을 가능성을 조사할 수 있다.

다만 이러한 선행 변화가 발견되었다고 해서 자동으로 근본원인이 되는 것은 아니다.

먼저 발생했다는 사실은 중요한 단서이지, 그 자체가 인과관계의 증거는 아니다.

7. 로그와 성능 데이터는 RCA의 증거를 연결하는 자료다

Ⅴ-3에서 살펴본 것처럼 로그는 장애 전후의 사건을 시간축으로 확인하는 데 유용하다.

여기에 성능 데이터를 함께 연결하면 원인 후보를 더 구체적으로 검토할 수 있다.

예를 들어 다음과 같이 비교할 수 있다.

자료	확인할 내용
시스템 로그	오류와 상태 변화 발생 시점
애플리케이션 로그	프로그램 내부 처리와 오류
CPU 데이터	사용량과 변화 추세
메모리 데이터	사용량과 압박 상태
디스크 데이터	지연시간, 오류, I/O 상태
네트워크 데이터	연결 상태, 오류, 지연, 손실
하드웨어 상태	온도, 전원, 장치 상태
변경 이력	장애 직전 변경 사항

중요한 것은 특정 로그 하나를 발견하고 RCA를 끝내는 것이 아니다.

서로 다른 자료가 동일한 시간축에서 어떤 관계를 보여주는지 확인하는 것이 중요하다.

예를 들어 ERROR 로그가 가장 마지막에 기록되었다고 해서 그 ERROR가 근본원인이라고 단정할 수 없다.

앞에서 발생한 다른 문제가 해당 ERROR를 발생시킨 결과일 수도 있기 때문이다.

8. RCA에서 ‘원인’과 ‘결과’를 뒤집지 않기

장애가 발생하면 오류가 연속적으로 발생하는 경우가 많다.

예를 들어 하나의 장애가 발생한 이후 다음과 같은 로그가 연속해서 기록될 수 있다.

장치 오류
→ 파일 접근 실패
→ 서비스 오류
→ 연결 실패
→ 사용자 프로그램 오류

이때 가장 많은 오류를 발생시킨 마지막 단계가 반드시 근본원인은 아니다.

오히려 최초 장애가 이후의 여러 오류를 연쇄적으로 발생시켰을 가능성이 있다.

따라서 RCA에서는 각 사건에 대해 다음 질문을 던지는 것이 좋다.

• 이것은 원인인가?
• 이전 사건의 결과인가?
• 다른 사건과 독립적인 문제인가?
• 장애를 확대시킨 요인인가?
• 정상 상태에서도 발생하는 현상인가?

이 과정을 통해 원인과 결과가 뒤바뀌는 오류를 줄일 수 있다.

9. RCA의 목적은 원인을 찾는 데서 끝나지 않는다

RCA의 최종 목적은 보고서에 원인을 적는 것이 아니다.

중요한 것은 같은 장애가 다시 발생할 가능성을 낮추는 것이다.

예를 들어 단순히 서버를 재부팅하여 서비스가 정상화되었다고 하자.

서비스는 복구되었지만 원인이 제거되었다고 볼 수는 없다.

따라서 RCA 결과에 따라 다음과 같은 개선을 검토할 수 있다.

• 설정 수정
• 드라이버 또는 펌웨어 변경
• 고장 부품 교체
• 냉각계통 개선
• 모니터링 항목 추가
• 경고 기준 조정
• 백업 구성 개선
• 장애 대응 절차 변경
• 변경관리 절차 보완
• 용량 또는 성능 계획 수정

여기서 중요한 것은 모든 RCA 결과에 동일한 개선책을 적용하는 것이 아니라 확인된 원인과 기여 요인에 맞는 조치를 선택하는 것이다.

10. 조치 후에는 원인이 실제로 제거되었는지 확인한다

RCA에서 자주 발생하는 또 하나의 문제는 조치를 수행한 뒤 분석을 종료하는 것이다.

예를 들어 부품을 교체한 후 시스템이 정상적으로 작동했다고 해서 그 부품이 반드시 근본원인이었다고 확정할 수 있는 것은 아니다.

다음 사항을 확인할 필요가 있다.

• 동일 증상이 다시 발생하지 않는가?
• 관련 로그가 사라졌는가?
• 성능 상태가 정상 범위로 돌아왔는가?
• 변경한 구성요소가 실제 문제와 연결되어 있었는가?
• 다른 환경에서는 동일한 문제가 발생하지 않는가?
• 일정 기간 동안 정상 상태가 유지되는가?

즉,

조치 완료 ≠ 원인 확인 완료

로 구분해야 한다.

특히 부품 교체나 재부팅처럼 시스템을 일시적으로 정상화시키는 조치는 복구와 원인 제거를 구분해서 평가해야 한다.

11. RCA 결과는 다음 장애를 위한 지식으로 남겨야 한다

장애 분석 결과가 일회성 보고서로 끝나면 같은 유형의 장애가 다시 발생했을 때 처음부터 조사해야 한다.

따라서 장애 이력을 일정한 형식으로 기록하는 것이 좋다.

항목	기록 내용
장애 증상	사용자에게 나타난 현상
최초 이상 시점	정상 상태에서 처음 변화가 확인된 시점
장애 발생 시점	서비스 영향이 발생한 시점
직접 원인	장애를 직접 발생시킨 기술적 사건
근본원인	직접 원인이 발생한 구조적 원인
기여 요인	장애 발생·확대에 영향을 준 조건
영향 범위	시스템·서비스·사용자 영향
복구 방법	실제 서비스 복구에 사용한 조치
원인 제거 조치	근본원인에 대한 개선
검증 결과	조치 후 재발 여부와 상태
추가 개선	모니터링·절차·구성 등의 개선사항

이렇게 기록하면 과거 장애가 단순한 이력이 아니라 다음 장애의 진단 시간을 줄이는 자료가 될 수 있다.

12. 장애 분석에서 흔히 발생하는 RCA 오류

RCA를 수행할 때 다음과 같은 판단은 주의해야 한다.

• 마지막으로 기록된 ERROR를 근본원인으로 판단
• 가장 먼저 발견된 이상을 원인으로 확정
• 최근 변경 사항을 무조건 원인으로 판단
• 부품 교체 후 정상화된 것을 원인 확인으로 판단
• 재부팅 후 정상화된 것을 문제 해결로 판단
• 하나의 원인으로 복합 장애를 설명
• 로그가 없다는 이유로 해당 사건이 없었다고 판단
• 성능 지표 하나만으로 원인을 확정
• 장애가 재발하지 않았다는 이유만으로 조치가 적절했다고 판단

이러한 오류를 피하려면 원인 후보를 세우고, 시간·상태·로그·성능 데이터·변경 이력 등을 이용해 하나씩 검증하는 과정이 필요하다.

13. V-1부터 V-4까지의 장애 분석 흐름

앞에서 다룬 내용을 연결하면 각 글의 역할이 명확해진다.

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

장애가 발생했을 때 무엇부터 확인하고 어떻게 범위를 좁혀갈 것인가를 다룬다.

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

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

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

로그와 성능 데이터를 시간축으로 연결하여 장애 전후의 사건 관계를 어떻게 추적할 것인가를 다룬다.

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

앞선 분석 결과를 바탕으로 증상, 직접 원인, 근본원인, 기여 요인을 구분하고 재발 방지까지 연결하는 방법을 다룬다.

따라서 Ⅴ-4는 단순히 RCA의 정의를 설명하는 글이 아니라 “장애를 복구한 뒤, 정말 무엇이 문제였는지를 어떻게 판단할 것인가”에 초점을 맞추는 것이 적절하다.

14. 실제 RCA에서 마지막으로 확인해야 할 질문

장애 분석이 끝났다고 판단하기 전에 다음 질문을 확인해 볼 필요가 있다.

① 우리가 확인한 것은 증상인가, 원인인가?

② 직접 원인과 근본원인을 구분했는가?

③ 시간적 선후관계만으로 원인을 확정하고 있지는 않은가?

④ 로그와 성능 데이터가 원인 판단을 실제로 뒷받침하는가?

⑤ 다른 원인으로도 동일한 장애를 설명할 수 있는가?

⑥ 조치 후 시스템이 정상화된 것과 원인이 제거된 것을 구분했는가?

⑦ 같은 조건이 다시 발생했을 때 동일한 장애가 재발할 가능성은 줄었는가?

이 질문에 답할 수 있어야 RCA 결과를 단순한 추측이 아니라 검증된 장애 분석 결과에 가깝게 만들 수 있다.

15. 핵심정리

장애 분석에서 가장 먼저 보이는 현상이 반드시 원인은 아니다.

증상 → 직접 원인 → 근본원인 → 기여 요인 → 재발 방지

의 구조로 분석하면 장애를 단순히 복구하는 것과 장애의 원인을 제거하는 것을 구분할 수 있다.

특히 RCA에서는 “먼저 발생했다”는 사실과 “원인이다”라는 판단을 구분하는 것이 중요하다.

로그, 성능 데이터, 하드웨어 상태, 변경 이력을 하나의 시간축으로 연결하고 각각의 관계를 검증해야 한다.

결국 좋은 RCA는 원인을 하나 골라내는 작업이 아니라,

“왜 이 장애가 발생했고, 왜 더 일찍 발견하거나 막지 못했으며, 무엇을 바꾸면 다시 발생할 가능성을 줄일 수 있는가?”

까지 확인하는 과정이다.

그리고 마지막으로 스스로 물어볼 필요가 있다.

우리는 장애가 발생했을 때 시스템을 다시 살리는 데서 끝내고 있는가, 아니면 같은 장애가 다시 발생하지 않도록 원인까지 제거하고 있는가?