Ⅴ-7. 장애 격리와 원인 구성요소 식별

컴퓨터 시스템에서 장애가 발생하면 원인을 바로 특정하기 어려운 경우가 많다.

하나의 구성요소가 다른 구성요소와 연결되어 있기 때문에 실제 원인이 발생한 곳과 사용자가 처음 증상을 발견한 곳이 다를 수 있기 때문이다.

Ⅴ-6에서는 장애가 어느 계층에서 시작되었는지를 좁혀가는 방법을 살펴보았다.

이번에는 그다음 단계로 해당 계층 안에서 어떤 구성요소가 실제 원인 후보인지 분리하고 비교하는 과정을 분석한다.

핵심은 특정 부품을 먼저 의심하는 것이 아니라,

정상 영역과 이상 영역을 나누고 → 구성요소를 격리하고 → 조건을 비교하고 → 변경 전후의 증거를 확인하면서 원인 후보를 줄여가는 것이다.

1. 장애 격리란 무엇인가

장애 격리는 여러 구성요소가 연결된 시스템에서 문제의 범위를 단계적으로 좁혀 원인 후보를 분리하는 과정이다.

예를 들어 컴퓨터가 갑자기 멈췄다고 해서 CPU나 메모리 중 하나를 바로 고장이라고 판단하는 것은 적절하지 않다.

다음과 같이 범위를 줄여갈 수 있다.

전체 시스템 → 장애 기능 → 해당 계층 → 장치 → 구성요소 → 연결 경로

이 과정에서 중요한 것은 단순히 의심 대상을 찾는 것이 아니다.

정상적으로 작동하는 영역을 확인하여 조사 대상에서 제외하는 것도 장애 격리의 중요한 역할이다.

따라서 장애 격리는 다음과 같은 두 방향으로 진행된다.

• 이상이 확인되는 범위를 좁힌다.
• 정상임이 확인된 범위를 조사 대상에서 제외한다.

결국 장애 격리의 목적은 가능한 원인의 수를 줄이는 것이다.

2. Ⅴ-6의 계층 분리와 Ⅴ-7의 구성요소 격리는 다르다

두 과정은 연결되어 있지만 같은 작업은 아니다.

Ⅴ-6에서는 다음과 같은 질문이 중심이었다.

“장애가 어느 계층에서 시작되었는가?”

예를 들어 응용프로그램에서 오류가 나타났더라도 실제 시작점이 운영체제, 드라이버, 저장장치 또는 네트워크 경로에 있을 수 있다는 점을 확인했다.

Ⅴ-7에서는 한 단계 더 들어간다.

“그 계층 안에서 실제로 어떤 구성요소가 원인 후보인가?”

예를 들어 저장장치 계층이 의심된다면 다시 다음과 같이 범위를 좁혀야 한다.

SSD → 인터페이스 → 케이블 또는 슬롯 → 저장장치 드라이버 → I/O 경로

따라서 Ⅴ-6이 장애 발생 계층을 좁히는 과정이라면, Ⅴ-7은 그 계층 내부의 구성요소와 연결 조건을 분리하여 원인 후보를 검증하는 과정이라고 볼 수 있다.

3. 장애 범위를 먼저 확인한다

구성요소를 분리하기 전에 장애가 어느 정도 범위에서 발생하는지 확인해야 한다.

특정 프로그램에서만 발생

특정 프로그램에서만 문제가 발생한다면 응용프로그램 자체, 해당 프로그램의 라이브러리, 설정, 사용하는 시스템 자원 등을 우선 비교할 수 있다.

여러 프로그램에서 발생

여러 프로그램에서 동시에 문제가 발생한다면 특정 응용프로그램만의 문제로 보기 어렵다.

운영체제, 메모리, 저장장치, 드라이버, 공통 서비스 등의 영향을 함께 확인해야 한다.

전체 시스템에서 발생

화면 정지, 강제 재부팅, 전원 차단처럼 전체 시스템에 영향을 주는 경우에는 운영체제뿐 아니라 하드웨어, 전원, 열, 펌웨어 등도 조사 범위에 포함할 필요가 있다.

여기서 중요한 것은 영향 범위가 넓다고 해서 하드웨어가 원인이라고 확정할 수는 없다는 것이다.

영향 범위는 원인 확정이 아니라 조사 범위를 정하는 단서다.

4. 정상 구성요소를 확인하여 조사 범위를 줄인다

장애가 발생했다고 해서 모든 구성요소를 동일한 수준으로 의심할 필요는 없다.

정상적으로 작동하는 구성요소와 장애가 발생하는 구성요소를 비교하면 원인 후보를 줄일 수 있다.

예를 들어 저장장치 오류가 의심되는 경우 다음과 같은 차이가 반복되는지 확인할 수 있다.

비교 항목	정상 구성요소	의심 구성요소
동일 작업	정상 수행	오류 또는 지연
오류 기록	특이사항 없음	오류 증가
I/O 지연	정상 범위	반복적인 지연
장애 재현	발생하지 않음	반복 발생
상태 변화	안정적	장애 전 변화 확인

이러한 차이가 반복된다면 의심 구성요소의 원인 가능성을 높일 수 있다.

그러나 차이가 있다는 것과 원인이라는 것은 같은 의미가 아니다.

다른 조건이 함께 달라졌다면 그 조건이 영향을 주었을 가능성도 있기 때문이다.

5. 구성요소를 가능한 범위에서 분리한다

장애 격리에서 가장 직접적인 방법 중 하나는 의심되는 구성요소를 분리하고 결과를 비교하는 것이다.

예를 들어 여러 외부 장치가 연결된 시스템에서 장애가 발생한다면 다음과 같이 접근할 수 있다.

전체 구성 확인 → 장치 하나씩 분리 → 동일 조건에서 테스트 → 장애 발생 여부 비교

특정 장치를 제거했을 때 장애가 반복적으로 사라진다면 해당 장치는 중요한 원인 후보가 된다.

하지만 여기서 바로 “이 장치가 고장났다”고 결론 내리면 안 된다.

장치를 제거하는 과정에서 다음과 같은 조건도 함께 변할 수 있기 때문이다.

• 포트
• 케이블
• 전원 연결
• 슬롯
• 드라이버 상태
• 시스템 재부팅 여부
• 온도
• 부하 상태

따라서 구성요소를 분리했다면 무엇이 함께 변했는지도 기록해야 한다.

6. 대체 구성요소와 비교하여 원인 후보를 좁힌다

의심되는 구성요소를 정상적으로 작동하는 구성요소와 비교하는 방법도 사용할 수 있다.

예를 들어 특정 메모리 모듈이 의심된다면 가능한 범위에서 동일한 조건으로 다른 모듈을 사용하여 결과를 비교한다.

의심 구성요소 → 장애 발생

정상 구성요소 → 장애 미발생

이 차이가 동일 조건에서 반복된다면 원인 후보를 좁히는 데 중요한 근거가 된다.

하지만 여기에서도 한 번의 결과만으로 결론을 내리기보다 반복성을 확인하는 것이 중요하다.

특히 메모리, 저장장치, 전원, 냉각장치처럼 다른 구성요소와 상호작용하는 부품은 단순 교체 결과만으로 원인을 확정하기 어려울 수 있다.

7. 부품 교체 후 정상화됐다는 사실만으로 원인을 확정하지 않는다

장애가 발생하여 부품을 교체했더니 시스템이 정상으로 돌아왔다고 가정해 보자.

이 결과는 중요한 단서이지만 원인을 증명한 것은 아니다.

부품을 교체하는 과정에서 다음과 같은 변화가 동시에 발생했을 수 있다.

• 케이블을 다시 연결했다.
• 슬롯 위치가 바뀌었다.
• 접촉 상태가 달라졌다.
• 전원 연결 상태가 달라졌다.
• 시스템을 재부팅했다.
• 장치 온도가 달라졌다.
• 일시적인 오류 상태가 초기화됐다.

따라서 정확한 분석을 위해서는

교체 전 상태 → 교체 과정에서 변경된 조건 → 교체 후 상태 → 동일 장애의 재현 여부

를 함께 기록해야 한다.

특히 “교체 후 정상”과 “교체한 부품이 원인”을 구분하는 것이 중요하다.

8. 조건을 통제해야 비교 결과를 해석할 수 있다

구성요소를 비교할 때 조건이 계속 달라지면 어떤 변화가 장애에 영향을 주었는지 알기 어려워진다.

예를 들어 특정 GPU가 원인인지 확인하려면 가능한 범위에서 다음 조건을 일정하게 유지하는 것이 좋다.

• 동일한 운영체제
• 동일한 드라이버 조건
• 동일한 전원 조건
• 유사한 작업 부하
• 유사한 온도 조건
• 동일한 테스트 절차

이렇게 해야 구성요소의 변경과 장애 상태의 변화 사이의 관계를 보다 명확하게 비교할 수 있다.

다만 실제 시스템에서는 모든 조건을 완전히 동일하게 유지하기 어려울 수 있다.

따라서 중요한 것은 완벽한 통제가 아니라 어떤 조건이 변경되었는지를 명확하게 기록하고 해석에 반영하는 것이다.

9. 장애 격리와 로그·성능 데이터를 함께 확인한다

장애 격리는 단순히 부품을 빼고 연결하는 작업이 아니다.

구성요소를 분리한 결과를 로그와 성능 데이터와 함께 확인하면 원인 후보를 더 정확하게 평가할 수 있다.

예를 들어 다음과 같은 관계가 반복적으로 확인되었다고 가정하자.

저장장치 오류 증가 → I/O 지연 증가 → 응용프로그램 응답 지연 → 프로그램 중단

이 경우 단순히 프로그램 자체의 오류로 판단하기보다 저장장치와 I/O 경로를 함께 조사해야 한다.

반대로 저장장치를 교체했는데 문제가 사라졌더라도 교체 과정에서 케이블이나 슬롯이 함께 변경되었다면 그 부분도 확인해야 한다.

즉,

격리 결과 + 시간 정보 + 로그 + 성능 데이터

를 함께 봐야 한다.

10. 시간축을 맞추면 원인 후보의 선후관계를 확인할 수 있다

장애가 발생한 시간은 구성요소를 식별하는 데 중요한 정보가 된다.

예를 들어 다음과 같은 기록이 있다고 하자.

14:05:10 저장장치 오류 기록

14:05:12 I/O 지연 증가

14:05:15 프로그램 응답 중단

이 경우 저장장치 오류가 프로그램 중단보다 먼저 발생했다는 사실을 확인할 수 있다.

하지만 이것만으로 저장장치가 근본원인이라고 확정할 수는 없다.

더 앞선 시점에 컨트롤러나 전원, 드라이버 등의 문제가 발생했고 저장장치 오류가 그 결과로 나타났을 가능성도 있기 때문이다.

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

11. 구성요소가 연결된 경로를 함께 확인한다

특정 구성요소에서 오류가 확인되더라도 그 구성요소만 조사해서는 부족할 수 있다.

예를 들어 저장장치 문제를 조사한다면 다음과 같은 연결 경로를 함께 살펴볼 필요가 있다.

SSD → 인터페이스 → 슬롯·케이블 → 저장장치 드라이버 → 운영체제 I/O → 파일 시스템 → 응용프로그램

네트워크 역시 단순히 NIC 하나만 확인해서 끝나는 것이 아니다.

응용프로그램 → OS 네트워크 처리 → 드라이버 → NIC → 스위치·라우터 → 외부 네트워크 → 목적지 시스템

처럼 실제 통신 경로 전체에서 어디까지 정상이고 어디에서 이상이 시작되었는지를 비교해야 한다.

따라서 구성요소 격리는 부품 하나를 떼어내는 작업이 아니라 연결된 경로에서 원인 후보의 범위를 줄이는 작업으로 이해하는 것이 정확하다.

12. 장애가 사라지는 조건과 발생하는 조건을 비교한다

장애 격리에서 특히 중요한 것은 장애가 발생한 상태만 보는 것이 아니라 장애가 사라지는 조건도 함께 보는 것이다.

예를 들어

• 특정 장치 연결 → 장애 발생
• 장치 제거 → 장애 미발생
• 다시 연결 → 장애 재발

이 반복된다면 해당 장치와 장애 사이에 강한 연관성이 있다는 판단을 할 수 있다.

그러나 여기에서도 장치 자체가 원인인지, 장치가 연결된 포트나 케이블 또는 드라이버가 원인인지는 추가로 분리해야 한다.

따라서 다음과 같은 비교가 필요하다.

조건	장애 결과	해석
A 구성요소 + 동일 조건	발생	원인 후보
A 구성요소 제거	미발생	A와 장애의 연관성 증가
B 구성요소로 대체	미발생	비교 근거 증가
A 재장착	재발	반복성 확인
연결 경로 변경	결과 변화	포트·케이블 등 추가 조사

이런 방식으로 구성요소 자체와 연결 조건을 분리해 보는 것이 중요하다.

13. 장애 격리 결과는 증거로 남긴다

장애 분석 결과를 단순히

“부품 교체 후 정상”

이라고 기록하면 다음 장애가 발생했을 때 활용할 수 있는 정보가 부족하다.

최소한 다음과 같은 내용을 남기는 것이 좋다.

• 장애 발생 시간
• 장애 증상
• 영향 범위
• 당시 시스템 상태
• 의심 구성요소
• 분리 또는 교체한 구성요소
• 변경된 조건
• 테스트 방법
• 테스트 결과
• 관련 로그
• 성능 변화
• 정상 상태와의 차이
• 반복 재현 여부
• 최종 판단 근거

이 기록이 남아 있으면 동일한 장애가 다시 발생했을 때 처음부터 모든 검사를 반복하지 않고 이전 분석 결과를 활용할 수 있다.

14. 장애 격리와 근본원인 분석은 구분해야 한다

장애 격리는 RCA를 위한 중요한 과정이지만 그 자체가 RCA의 완료를 의미하지는 않는다.

예를 들어 특정 SSD를 제거했더니 장애가 사라졌다면,

“SSD를 제거하자 장애가 사라졌다.”

까지는 장애 격리의 결과다.

그다음에는

“왜 SSD를 제거했을 때 장애가 사라졌는가?”

를 확인해야 한다.

SSD 자체의 오류인지, 인터페이스 문제인지, 드라이버 문제인지, 전원이나 온도 조건인지 확인해야 최종적인 원인 판단에 가까워진다.

따라서 흐름은 다음과 같이 연결된다.

장애 증상 확인 → 영향 범위 확인 → 계층 분리 → 구성요소 격리 → 조건 비교 → 증거 확인 → 원인 검증 → 재발 방지

여기서 반드시 구분해야 할 것이 있다.

장애가 사라진 것 ≠ 원인이 증명된 것

15. 장애 격리에서 가장 중요한 판단 기준

장애 격리의 핵심은 특정 부품을 빨리 찾아내는 것이 아니다.

다음 네 가지 질문에 답할 수 있어야 한다.

① 무엇이 변경되었는가?

구성요소, 연결 상태, 설정, 드라이버, 전원, 부하 등이 무엇 때문에 달라졌는지 확인한다.

② 무엇은 그대로 유지되었는가?

비교 조건을 유지해야 변경된 요소의 영향을 평가할 수 있다.

③ 변경 후 장애 상태가 어떻게 달라졌는가?

장애 발생, 미발생, 빈도 변화, 지속시간 변화 등을 비교한다.

④ 그 결과가 반복되는가?

한 번의 결과보다 동일 조건에서 반복되는 결과가 훨씬 강한 판단 근거가 된다.

결국 장애 격리는 다음과 같은 비교 구조로 이해할 수 있다.

변경 요소 → 장애 상태 변화 → 반복 확인 → 다른 원인 후보 배제 → 원인 검증

16. 장애 격리의 실제 분석 흐름

실제 장애 상황에서는 다음과 같은 순서로 접근할 수 있다.

① 증상 정의

무엇이 정상과 달라졌는지 명확하게 기록한다.

② 영향 범위 확인

특정 프로그램인지, 여러 프로그램인지, 전체 시스템인지 확인한다.

③ 장애 계층 확인

Ⅴ-6에서 다룬 방법을 이용하여 어느 계층부터 조사할지 범위를 좁힌다.

④ 구성요소 목록화

해당 계층에 연결된 장치와 경로를 확인한다.

⑤ 정상 구성요소와 비교

정상 상태와 장애 상태의 차이를 확인한다.

⑥ 구성요소 격리

가능한 경우 하나의 구성요소 또는 연결 조건을 분리한다.

⑦ 조건 통제

테스트 과정에서 변경된 조건을 기록하고 불필요한 변화를 줄인다.

⑧ 로그·성능 데이터 확인

구성요소 변경 전후의 데이터 변화를 비교한다.

⑨ 반복 검증

동일한 결과가 반복되는지 확인한다.

⑩ 원인 후보 확정

단순 연관성이 아니라 여러 증거가 일관되게 같은 구성요소를 가리키는지 판단한다.

⑪ 복구 후 재발 여부 확인

장애가 사라진 뒤에도 동일 조건에서 다시 문제가 발생하지 않는지 확인한다.

17. 장애 격리에서 자주 발생하는 판단 오류

장애 격리 과정에서는 다음과 같은 오류가 자주 발생한다.

“교체했더니 해결됐으니 그 부품이 원인이다.”

→ 교체 과정에서 다른 조건도 변경되었는지 확인해야 한다.

“오류 로그가 발생한 장치가 원인이다.”

→ 해당 오류가 원인인지 결과인지 시간축과 다른 데이터를 함께 확인해야 한다.

“특정 장치를 제거하자 문제가 사라졌다.”

→ 장치 자체뿐 아니라 포트, 케이블, 드라이버, 전원 등의 영향도 확인해야 한다.

“한 번 정상화됐으니 원인이 해결됐다.”

→ 일시적인 상태 초기화일 가능성을 배제하고 재현 여부를 확인해야 한다.

“문제가 재현되지 않는다.”

→ 문제가 없다는 의미가 아니라 장애 조건이 다시 만들어지지 않았을 가능성도 고려해야 한다.

이러한 오류를 피해야 장애 격리가 단순한 시행착오가 아니라 검증 가능한 분석 과정이 된다.

18. 장애 격리의 핵심은 ‘제거’가 아니라 ‘비교’다

장애 격리를 단순히

“의심되는 부품을 하나씩 빼본다.”

라고 이해하면 정확하지 않다.

진짜 중요한 것은 무엇을 변경했을 때 장애 상태가 어떻게 달라졌는지를 비교하는 것이다.

예를 들어

A 구성 → 장애 발생

A 제거 → 장애 미발생

이라는 결과만으로는 부족하다.

다음과 같이 비교가 이어져야 한다.

B 구성 → 장애 미발생

A 재장착 → 장애 재발

A를 다른 포트에 연결 → 결과 변화 확인

이처럼 비교 조건을 늘려가면 원인 후보를 구성요소 자체와 연결 조건으로 나누어 볼 수 있다.

따라서 장애 격리의 본질은

“무엇을 바꾸었는가?”보다 “그 변경 때문에 장애 상태가 어떻게 달라졌으며, 그 결과가 반복되는가?”

에 있다.

19. V-1부터 V-7까지의 연결

지금까지의 장애 진단 과정은 서로 다른 역할을 가지고 연결된다.

V-1. 장애 진단 절차

전체적인 장애 조사 흐름을 설정한다.

V-2. 하드웨어·소프트웨어 구분

원인 후보가 어느 영역에 가까운지 범위를 좁힌다.

V-3. 로그 기반 원인 추적

시간축에 따라 장애 전후의 사건을 연결한다.

V-4. 근본원인 분석

증상, 직접 원인, 근본원인, 기여 요인을 구분한다.

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

어떤 조건에서 장애가 발생하는지 확인한다.

V-6. 계층별 장애 진단

어느 계층에서 이상이 시작되었는지 범위를 좁힌다.

V-7. 장애 격리와 원인 구성요소 식별

해당 계층 안에서 구성요소와 연결 조건을 분리하고 비교하여 실제 원인 후보를 검증한다.

따라서 V-7은 앞선 내용을 반복하는 것이 아니라,

“어느 계층인가?”에서 “그 계층 안에서 무엇이 원인인가?”로 분석 범위를 한 단계 더 좁히는 과정이다.

20. 핵심정리

장애 격리는 의심되는 부품을 무작정 교체하는 작업이 아니다.

정상 영역과 이상 영역을 구분하고, 구성요소와 연결 조건을 분리한 뒤, 변경 전후의 상태와 로그·성능 데이터를 비교하여 원인 후보를 줄여가는 과정이다.

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

장애가 사라졌다는 사실은 해결의 단서이지, 원인을 증명한 결과가 아니다.

구성요소를 찾는 것보다 중요한 것은 그 구성요소의 변경과 장애 상태의 변화가 반복적으로 연결되는지를 확인하는 것이다.

이제 다음 단계에서는 하나의 구성요소만 따로 보는 것을 넘어, 여러 구성요소가 서로 의존하면서 하나의 장애를 만들어내는 구조를 분석할 필요가 있다.

우리 시스템에서 장애가 발생했을 때,

“어떤 구성요소가 이상했는가?”에서 멈추지 않고 “그 구성요소의 이상이 다른 구성요소에 어떻게 영향을 주었는가?”까지 추적할 수 있는가?