Ⅵ-11. 컴퓨터 시스템 장애 해결과 복구 최적화를 위한 네트워크 장애 데이터 분석과 원인 상관관계 분석

네트워크 장애가 발생하면 장비 로그, 트래픽 정보, 패킷 손실, 지연시간, 인터페이스 상태, 서버 자원 사용량 등 다양한 데이터가 동시에 남는다.

문제는 장애가 발생한 순간에는 여러 지표가 함께 변하기 때문에 어떤 데이터가 원인이고 어떤 데이터가 결과인지 바로 구분하기 어렵다는 것이다.

예를 들어 사용자 접속이 느려진 시점에 네트워크 지연, 서버 CPU 사용률, 트래픽, 패킷 재전송이 모두 증가했다면 단순히 “모두 증가했다”는 사실만으로 원인을 판단할 수 없다.

따라서 네트워크 장애 데이터 분석에서는 각각의 수치를 따로 보는 것보다 시간적 선후관계, 변화 방향, 정상 상태와의 차이, 실제 장애 경로를 함께 비교하여 원인 후보를 검증하는 과정이 필요하다.

1. 장애 데이터는 특정 값보다 변화 과정으로 봐야 한다

장애 분석에서 특정 시점의 CPU 사용률이나 트래픽이 높다는 사실만으로 원인을 확정할 수는 없다.

중요한 것은 장애 발생 전후에 무엇이 먼저 변했고 이후 어떤 변화가 이어졌는가이다.

예를 들어 다음과 같은 흐름이 확인되었다고 가정해 보자.

트래픽 증가 → 인터페이스 사용률 증가 → 패킷 Drop 증가 → 재전송 증가 → RTT 증가 → 서비스 지연

이 경우 각각의 데이터가 독립적으로 존재하는 것이 아니라 하나의 장애 과정으로 연결되는지 검토할 수 있다.

따라서 장애 데이터 분석의 첫 단계는 숫자를 나열하는 것이 아니라 변화의 흐름을 만드는 것이다.

2. 서로 다른 데이터를 같은 시간축으로 맞춰야 한다

장애 원인을 추적하려면 네트워크 장비, 서버, 방화벽 등 서로 다른 시스템에서 수집된 데이터를 같은 시간 기준으로 비교해야 한다.

분석 대상에는 다음과 같은 정보가 포함될 수 있다.

• 네트워크 장비 로그
• 서버 로그
• 방화벽 이벤트
• 트래픽 사용량
• 인터페이스 오류
• 패킷 손실률
• RTT 및 지연시간
• 서버 CPU·메모리 사용량
• 연결 및 세션 수
• 사용자 장애 신고 시간

예를 들어 사용자가 15시 20분부터 접속 지연을 경험했다면 15시 20분의 데이터만 보는 것이 아니라 장애 발생 전후 일정 시간의 변화를 함께 확인해야 한다.

특히 서로 다른 장비의 시간이 정확하게 맞지 않으면 실제로는 순서가 있는 사건이 동시에 발생한 것처럼 보일 수 있다.

따라서 장애 데이터 분석에서는 시간 기준의 일관성 자체가 분석 품질에 영향을 준다.

3. 최초 변화와 최종 장애를 구분해야 한다

장애 분석에서 중요한 질문 중 하나는 **“무엇이 먼저 발생했는가?”**이다.

예를 들어

서버 CPU 증가 → 서버 처리 지연 → 네트워크 응답 지연 → 사용자 접속 지연

이라는 순서가 확인된다면 네트워크 지연은 최초 원인이 아니라 서버 처리 지연의 결과일 가능성을 검토해야 한다.

반대로

네트워크 패킷 손실 → TCP 재전송 증가 → 서버 응답 지연 → 사용자 접속 실패

라면 네트워크 문제가 먼저 발생했을 가능성을 확인할 수 있다.

따라서 장애가 발생한 순간에 가장 크게 나타난 현상을 원인으로 판단하기보다 변화가 시작된 순서를 먼저 확인해야 한다.

4. 상관관계와 원인관계를 구분해야 한다

장애 분석에서 특히 주의해야 할 부분이다.

두 지표가 같은 시간에 증가했다고 해서 하나가 다른 하나의 원인이라고 단정할 수는 없다.

예를 들어 트래픽 증가와 서버 CPU 증가가 동시에 나타났다면 다음과 같은 가능성을 모두 검토해야 한다.

• 트래픽 증가가 서버 CPU 부하를 높였는가?
• 서버의 작업 증가가 네트워크 트래픽을 발생시켰는가?
• 백업이나 배치 작업과 같은 제3의 요인이 두 지표를 동시에 증가시켰는가?

즉,

동시에 발생했다 = 원인관계가 확인되었다

라고 볼 수 없다.

상관관계는 원인을 찾기 위한 단서이고, 실제 원인이라고 판단하려면 시간 순서, 장애 경로, 정상 상태와의 비교, 재현 여부 등의 추가 검증이 필요하다.

5. 정상 상태와 장애 상태를 비교해야 변화의 의미를 알 수 있다

장애가 발생한 시점의 데이터만 보면 수치가 높은지 낮은지 판단하기 어려운 경우가 많다.

따라서 정상 상태와 장애 상태를 비교하는 것이 중요하다.

항목	정상 상태	장애 상태
트래픽	250Mbps	850Mbps
패킷 손실	거의 없음	증가
RTT	15ms	120ms
인터페이스 Drop	거의 없음	지속 증가
서버 CPU	35%	85%

이렇게 비교하면 장애 시점에 여러 지표가 동시에 변했다는 사실을 확인할 수 있다.

하지만 이것만으로 트래픽이 원인이라고 확정할 수는 없다.

정상과 장애의 차이를 찾는 것은 원인 분석의 출발점이지 최종 결론은 아니다.

6. 변화의 크기보다 변화의 시작 시점이 더 중요한 경우가 있다

장애 데이터에서는 얼마나 많이 변했는지도 중요하지만 언제부터 변하기 시작했는가도 중요하다.

예를 들어

트래픽 10% 증가

→ RTT 20ms → 30ms

→ 패킷 Drop 급증

→ 서버 응답시간 증가

라는 흐름이 있다면 초기의 작은 변화가 이후 장애와 연결되는지 확인할 필요가 있다.

반대로 서버 CPU가 먼저 증가하고 그 이후 트래픽이 증가했다면 다른 방향의 원인관계를 검토해야 한다.

따라서 장애 분석에서는 변화량 + 변화 속도 + 변화 시작 시점을 함께 보는 것이 좋다.

7. 여러 장비의 로그를 시간순으로 연결해야 장애 경로가 보인다

네트워크 장애는 하나의 장비에서만 기록되지 않는 경우가 많다.

예를 들어 다음과 같은 데이터가 남을 수 있다.

스위치 로그

→ 라우터 로그

→ 방화벽 로그

→ 서버 로그

각 로그를 따로 보면 단순한 오류 목록처럼 보인다.

하지만 동일한 시간축에 배치하면

스위치 인터페이스 오류 발생

→ 패킷 손실 증가

→ 방화벽 세션 변화

→ 서버 응답 지연

→ 사용자 접속 실패

와 같은 장애 경로를 확인할 수 있다.

이렇게 여러 장비의 데이터를 연결하면 장애가 어디에서 시작되어 어느 방향으로 영향을 확산시켰는지를 분석하기 쉬워진다.

단, 이러한 흐름 역시 로그가 보여주는 시간적 연속성을 의미할 뿐, 각 단계의 인과관계가 자동으로 확정되는 것은 아니다.

8. 반복되는 데이터 패턴은 장애 조건을 찾는 강한 단서가 된다

같은 장애가 반복된다면 이전 장애 데이터와 현재 장애 데이터를 비교하는 것이 효과적이다.

예를 들어 매주 특정 시간대에

링크 오류 증가 → 인터페이스 Down → 링크 복구 → RTT 증가 → 사용자 접속 지연

이 반복된다면 단순한 우연으로 보기보다 해당 시간대에 발생하는 작업이나 특정 장비 상태를 조사할 필요가 있다.

반복 패턴을 비교하면 다음과 같은 질문을 할 수 있다.

• 항상 같은 장비에서 시작되는가?
• 항상 같은 인터페이스에서 발생하는가?
• 특정 시간대와 연결되는가?
• 동일한 트래픽 조건에서 발생하는가?
• 같은 오류 코드가 반복되는가?
• 장애 발생 전 공통적으로 나타나는 변화가 있는가?

반복 장애에서는 한 번의 장애에서 나타난 현상보다 여러 번의 장애에서 공통적으로 확인되는 변화가 더 강한 증거가 될 수 있다.

9. 원인·직접 원인·증상을 분리해서 기록해야 한다

장애 분석 결과를 단순히 오류 목록으로 기록하면 다음 장애에서 활용하기 어렵다.

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

증상
사용자 웹서비스 접속 지연

직접적인 장애 조건
특정 네트워크 구간의 패킷 손실 증가

원인 후보
특정 인터페이스의 CRC 오류 증가

영향
TCP 재전송 증가 및 응답시간 상승

검증 결과
정상 장비와 비교했을 때 동일 조건에서 해당 인터페이스 오류가 반복 발생

여기서 특히 중요한 것은 원인 후보와 확인된 원인을 구분하는 것이다.

확인되지 않은 내용을 근본원인이라고 기록하면 이후의 예방 조치 역시 잘못된 방향으로 갈 수 있다.

10. 원인 후보는 추가 검증을 통해 좁혀야 한다

데이터에서 특정 인터페이스 오류가 발견되었다고 해서 바로 해당 장비를 교체하는 것은 적절하지 않을 수 있다.

다음과 같은 검증이 필요할 수 있다.

• 동일 조건에서 오류가 반복되는가?
• 다른 포트에서도 동일 현상이 발생하는가?
• 케이블이나 연결 장비를 변경했을 때 증상이 사라지는가?
• 정상 장비와 비교했을 때 차이가 있는가?
• 오류 발생 시간이 사용자 장애 시간과 일치하는가?
• 해당 인터페이스가 실제 장애 서비스의 통신 경로에 포함되는가?

이 과정을 통해

데이터에서 발견된 이상

→ 원인 후보

→ 추가 검증

→ 검증된 원인

으로 판단 수준을 높일 수 있다.

11. 장애 데이터의 관계를 하나의 흐름으로 정리하면 판단이 쉬워진다

복잡한 장애일수록 데이터를 각각 설명하기보다 하나의 흐름으로 연결하는 것이 좋다.

예를 들어

트래픽 급증

→ 인터페이스 사용률 상승

→ 패킷 Drop 증가

→ TCP 재전송 증가

→ RTT 증가

→ 서버 응답 지연

→ 사용자 접속 실패

와 같이 정리할 수 있다.

이때 각각의 화살표는 “반드시 원인관계가 확인되었다”는 의미가 아니다.

각 단계가 실제로 다음 단계에 영향을 주었는지를 로그, 정상 상태 비교, 장애 경로, 재현 또는 비교 테스트 등을 통해 검증해야 한다.

즉 장애 분석의 목적은 그럴듯한 이야기를 만드는 것이 아니라 데이터로 장애 경로를 확인하는 것이다.

12. 분석 결과는 재발 방지 조치로 연결되어야 한다

장애 데이터 분석의 최종 목적은 과거 장애를 설명하는 데 있지 않다.

분석 결과를 다음 장애를 줄이는 데 활용해야 한다.

분석 결과	후속 조치
반복되는 인터페이스 오류	포트·케이블·장비 점검
지속적인 트래픽 증가	용량 계획 검토
특정 시간대의 혼잡	작업 시간 및 트래픽 조건 검토
반복되는 CPU 상승	처리량 및 자원 구조 검토
반복되는 패킷 손실	장애 구간 집중 점검
동일 장애 반복	모니터링 및 경보 기준 개선
단일 경로 장애	이중화 구조 검토

이렇게 분석 결과가 실제 조치로 연결되어야 장애 데이터의 가치가 생긴다.

13. 장애 데이터 분석은 복구 후 검증까지 끝나야 한다

장애 원인을 수정했다고 해서 분석이 끝나는 것은 아니다.

복구 이후에는 장애 당시 문제가 되었던 지표가 실제로 정상 범위로 돌아왔는지 확인해야 한다.

예를 들어 장애 당시

패킷 Drop 증가 → RTT 증가 → 서비스 지연

이 발생했다면 복구 후에도 동일한 지표를 다시 확인해야 한다.

• 패킷 Drop이 정상화되었는가?
• RTT가 정상 범위로 돌아왔는가?
• 인터페이스 오류가 다시 증가하지 않는가?
• 서버 응답시간이 정상화되었는가?
• 동일 조건에서 문제가 재현되지 않는가?

이 과정을 통해 조치가 실제 장애 조건을 제거했는지를 확인할 수 있다.

14. 네트워크 장애 데이터 분석의 전체 흐름

네트워크 장애 데이터 분석은 다음과 같은 순서로 정리할 수 있다.

장애 데이터 수집

→ 시간축 정렬

→ 정상·장애 상태 비교

→ 최초 변화 확인

→ 관련 데이터 간 변화 비교

→ 장애 경로 확인

→ 원인 후보 설정

→ 추가 검증

→ 원인 확정

→ 복구 조치

→ 복구 후 정상 상태 검증

→ 재발 방지 조치

여기서 중요한 것은 각 단계가 자동으로 다음 단계의 결론을 의미하지 않는다는 것이다.

예를 들어 패킷 손실이 증가했다는 사실만으로 특정 장비가 원인이라고 확정할 수 없다.

데이터 → 관계 → 원인 후보 → 검증 → 확인된 원인

이라는 판단 단계를 거쳐야 한다.

핵심정리

• 장애 데이터는 특정 순간의 값보다 시간에 따른 변화 과정을 봐야 한다.
• 네트워크·서버·방화벽 등의 데이터를 같은 시간축으로 맞춰야 장애 흐름을 연결할 수 있다.
• 최초 변화와 최종 증상은 다를 수 있다.
• 동시에 증가한 두 지표가 반드시 원인과 결과라는 뜻은 아니다.
• 상관관계는 원인 후보를 찾는 단서이며, 실제 원인은 추가 검증을 통해 확인해야 한다.
• 반복되는 장애에서 공통적으로 나타나는 변화는 중요한 원인 분석 자료가 될 수 있다.
• 분석 결과는 원인 후보와 확인된 원인을 구분하여 기록하고 재발 방지 조치까지 연결해야 한다.
• 복구 후에는 문제가 되었던 지표가 실제로 정상화되었는지 다시 확인해야 한다.

기억할 한 가지

장애 데이터 분석의 핵심은 “같이 변한 것”을 찾는 데서 끝나지 않는다.
무엇이 먼저 변했고, 그 변화가 실제 장애와 연결된다는 근거가 있는지를 검증하는 것이 핵심이다.