Ⅳ-7. 과거 장애 데이터 기반 장애 예측 가능성 분석

컴퓨터 시스템에서 발생한 과거 장애는 단순한 이력으로 끝나는 것이 아니라 향후 장애를 조기에 발견하기 위한 분석 자료로 활용할 수 있다.

장애 발생 시점의 상태만 기록하는 것보다 장애 이전의 성능 변화, 로그, 오류, 설정 변경, 사용자 요청량 등을 함께 보존하면 장애 직전에 반복적으로 나타나는 특징을 확인할 수 있다.

그러나 과거 장애에서 특정 패턴이 반복되었다고 해서 그것만으로 미래 장애를 정확하게 예측할 수 있는 것은 아니다.

중요한 것은 과거 장애에서 발견한 특징이 정상 상태와 구별되는지, 장애보다 먼저 나타나는지, 새로운 사례에서도 재현되는지를 검증하는 것이다.

1. 과거 장애 데이터는 왜 중요한가

장애가 발생하면 일반적으로 장애 원인과 복구 결과를 기록한다. 하지만 장애 이후의 원인과 조치만 기록하면 무엇이 고장 났는지는 알 수 있어도 장애가 발생하기 전에 어떤 변화가 나타났는지 분석하기 어렵다.

예를 들어 여러 장애에서 다음과 같은 흐름이 반복되었다고 가정해 보자.

특정 오류 증가 → 응답시간 상승 → 처리량 감소 → 서비스 장애

이 관계가 여러 사례에서 반복된다면 특정 오류의 증가는 장애 발생 전에 나타나는 조기탐지 후보 신호가 될 수 있다.

따라서 과거 장애 데이터의 가치는 장애 원인을 저장하는 데만 있는 것이 아니라, 장애 이전의 상태를 시간 순서대로 재구성할 수 있도록 만드는 데 있다.

2. 과거 장애 데이터에는 무엇이 포함되어야 하는가

장애 예측 가능성을 분석하려면 단순히 장애가 발생했다는 결과만 저장해서는 부족하다. 장애 전후의 상태와 운영 환경을 함께 확인할 수 있어야 한다.

가능하면 다음 정보를 확보하는 것이 좋다.

• 장애 발생 시각과 탐지 시각
• 장애 유형과 영향 범위
• 확인된 원인 및 원인 후보
• 장애 이전의 CPU, 메모리, 디스크, 네트워크 등 성능 데이터
• 시스템 로그와 오류 코드
• 시스템 이벤트 기록
• 최근 설정 변경 및 배포 이력
• 운영체제, 소프트웨어, 패치 변경 이력
• 트래픽과 사용자 요청량
• 장애 대응 및 복구 조치
• 복구 시작 시각과 서비스 정상화 시각

특히 장애가 실제로 시작된 시점, 모니터링 시스템이 감지한 시점, 서비스 영향이 확인된 시점은 서로 다를 수 있다. 이 시점들을 구분해 기록해야 어떤 신호가 실제 장애보다 먼저 나타났는지 정확하게 판단할 수 있다.

3. 장애 직전뿐 아니라 충분한 이전 구간을 확보해야 한다

장애가 발생한 순간의 데이터만으로는 조기탐지 가능성을 분석하기 어렵다.

예를 들어 장애가 14시에 발생했다면 13시 59분의 상태만 보는 것이 아니라, 13시 50분, 13시 30분, 13시의 데이터까지 확인할 필요가 있다.

이때 핵심 질문은 다음과 같다.

장애가 발생하기 전 어떤 변화가 시작되었으며, 그 변화는 어떤 순서로 진행되었는가?

다만 모든 장애에 동일한 시간 구간을 적용할 필요는 없다. 수초 또는 수분 안에 급격하게 발생하는 장애와 수시간에 걸쳐 서서히 악화되는 장애는 필요한 분석 구간이 다르기 때문이다.

따라서 장애 유형과 시스템 특성을 고려해 분석 구간을 정하고, 필요하면 서로 다른 길이의 구간을 비교해야 한다.

4. 장애 이전의 정상 상태도 함께 확보해야 한다

장애 직전의 데이터만 보면 정상적인 변화와 장애 전조를 구분하기 어렵다.

예를 들어 CPU 사용률이 장애 직전에 90%까지 증가했다고 하자. 이 수치만 보면 CPU 증가가 장애 전조라고 생각할 수 있다.

그러나 장애가 발생하지 않은 날에도 동일한 시간대에 CPU 사용률이 90%까지 증가한다면, 해당 변화는 정상적인 업무 처리 과정에서 나타나는 현상일 수 있다.

따라서 최소한 다음 두 종류의 데이터를 비교해야 한다.

• 장애가 발생한 사례의 장애 전 데이터
• 동일하거나 유사한 조건에서 장애가 발생하지 않은 사례의 데이터

가능하면 시간대, 트래픽, 배치 작업, 시스템 구성 등 운영 조건도 함께 비교해야 한다. 조건이 크게 다른 사례를 단순 비교하면 실제 장애와 관련 없는 차이를 중요한 신호로 오해할 수 있다.

5. 여러 장애 사례에서 반복되는 패턴을 찾는다

과거 장애 데이터를 시간 순서대로 비교하면 반복되는 특징을 찾을 수 있다.

예를 들어 다음과 같은 흐름이 여러 사례에서 나타날 수 있다.

오류 발생 → 특정 성능 지표 변화 → 응답시간 증가 → 서비스 장애

또는 다음과 같은 변화가 관찰될 수도 있다.

메모리 사용량 증가 → 가용 메모리 감소 → 스왑 활동 증가 → 응답시간 증가

이러한 패턴은 장애 발생 과정을 이해하고 조기탐지 후보를 찾는 데 도움이 된다.

그러나 한두 번의 사례만으로 패턴을 확정해서는 안 된다. 장애마다 발생 조건과 원인이 다를 수 있으며, 우연히 함께 나타난 변화가 반복되는 것처럼 보일 수도 있다.

따라서 반복성뿐 아니라 정상 상태와의 차이, 시간적 선행성, 다른 사례에서의 재현성을 함께 확인해야 한다.

6. 반복된다고 해서 반드시 예측 신호는 아니다

어떤 패턴이 장애 사례에서 반복되었다는 사실만으로 예측력이 있다고 판단하면 안 된다.

예를 들어 특정 배치 작업이 실행될 때마다 CPU 사용률이 크게 증가한다고 하자. 이 변화가 장애가 발생한 날에도 나타났다고 해서 CPU 증가가 장애의 직접적인 원인이나 전조라고 단정할 수는 없다.

장애가 발생하지 않은 날에도 같은 변화가 나타난다면 해당 패턴은 정상적인 작업 특성일 가능성이 있다.

따라서 중요한 질문은 다음과 같다.

장애 사례에서 나타났는가가 아니라, 정상 사례와 비교했을 때 장애 사례에서 더 의미 있게 나타났는가?

장애가 발생한 경우와 발생하지 않은 경우를 함께 살펴야 특정 지표가 실제로 장애를 구분하는 데 도움이 되는지 판단할 수 있다.

7. 장애 사례와 정상 사례를 같은 기준으로 비교한다

예를 들어 특정 지표를 분석했을 때 다음과 같은 차이가 관찰되었다고 가정해 보자.

분석 항목	장애 사례	정상 사례
특정 오류	장애 전에 반복적으로 증가	드물게 발생하거나 짧게 지속
응답시간	지속적으로 증가	일시적으로 증가한 뒤 회복
메모리 사용량	계속 증가하며 회복되지 않음	작업 종료 후 감소
네트워크 지연	장애 전에 증가하는 사례가 반복됨	특정 시간대에만 증가

이 표는 비교 방법을 보여주는 가상의 예시다. 실제 시스템에서는 데이터를 통해 각 특징이 얼마나 자주 나타나는지, 차이가 얼마나 일관적인지 확인해야 한다.

또한 정상 사례에서도 특정 신호가 자주 나타난다면 그 신호 하나만으로 장애를 판단하기는 어렵다. 이때는 지속시간, 변화 속도, 다른 지표와의 관계 등 추가 조건을 검토할 수 있다.

8. 장애 예측 가능성은 여러 단계로 판단한다

과거 데이터에서 패턴을 발견했다고 바로 예측 가능하다고 결론 내리기보다는 다음 기준을 순서대로 확인하는 것이 좋다.

① 반복성

여러 장애 사례에서 비슷한 특징이 나타나는가?

② 정상 상태와의 구별

장애가 발생하지 않은 경우와 비교했을 때 해당 특징이 더 뚜렷하게 나타나는가?

③ 시간적 선행성

그 특징이 실제 장애 발생보다 먼저 나타나는가?

④ 재현성

분석에 사용하지 않은 다른 장애 사례에서도 해당 특징이 나타나는가?

⑤ 대응 가능한 선행시간

신호를 발견한 뒤 실제 장애가 발생하기까지 대응할 시간이 충분한가?

이 기준을 충족할수록 해당 패턴을 조기탐지에 활용할 가능성이 높아진다. 다만 모든 기준을 충족하더라도 미래의 모든 장애를 예측할 수 있다는 뜻은 아니다.

9. 시간적 선후관계를 확인해야 한다

장애와 관련된 지표라도 장애가 발생한 이후에 나타난다면 조기탐지 신호로 활용하기 어렵다.

예를 들어 다음과 같은 순서라면 CPU 증가가 장애를 미리 알려 주었다고 보기 어렵다.

서비스 장애 발생 → CPU 사용률 증가

반대로 여러 사례에서 다음과 같은 순서가 관찰된다면 CPU 증가를 후보 신호로 검토할 수 있다.

CPU 사용률 증가 → 오류 증가 → 응답시간 상승 → 서비스 장애

여기서도 순서가 반복된다는 사실만으로 CPU 증가가 장애의 원인이라고 단정해서는 안 된다. CPU 증가와 오류가 모두 다른 근본 문제에서 비롯되었을 수도 있기 때문이다.

따라서 과거 장애 분석에서는 단순히 두 현상이 함께 나타났는지뿐 아니라 어느 현상이 먼저 나타났고, 그 간격이 얼마나 일관적인지를 확인해야 한다.

10. 장애 발생까지 남은 시간이 충분한지 평가한다

조기탐지에서는 이상을 발견하는 것만큼 발견 이후에 대응할 시간이 있는지도 중요하다.

예를 들어 장애 발생 1초 전에 신호가 나타난다면 해당 신호가 장애와 관련되어 있더라도 운영자가 대응하기에는 시간이 부족할 수 있다.

반면 장애 발생 10분 전에 신호가 반복적으로 나타난다면 운영자 확인이나 자동화된 대응을 통해 피해를 줄일 가능성이 있다.

이때 사용하는 개념이 **경보 선행시간(lead time)**이다. 이는 조기 경보가 실제 장애 발생보다 얼마나 앞서 나타났는지를 의미한다.

선행시간은 단순히 길수록 좋은 것이 아니다. 너무 일찍 발생한 경보가 불필요하게 많아질 수도 있고, 실제 대응에 필요한 시간은 장애 유형과 복구 절차에 따라 다르다.

따라서 선행시간과 함께 경보의 신뢰도, 대응에 필요한 시간, 실제 피해를 줄였는지도 검토해야 한다.

11. 하나의 신호보다 여러 신호의 조합이 유용할 수 있다

단일 지표만으로 장애를 구분하기 어려운 경우에는 여러 신호의 조합을 검토할 수 있다.

예를 들어 CPU 사용률 증가만으로는 정상적인 업무량 증가인지 장애 전조인지 판단하기 어려울 수 있다.

그러나 다음과 같은 변화가 일정한 순서로 함께 나타난다면 장애 전조를 구분하는 데 도움이 될 수 있다.

CPU 사용률 증가 + 특정 오류 증가 + 응답시간 상승

이때 중요한 것은 여러 지표가 동시에 변했다는 사실만이 아니다. 각 지표의 변화 순서, 지속시간, 발생 조건이 과거 장애 사례와 얼마나 일치하는지를 함께 살펴야 한다.

또한 지표의 수가 많다고 반드시 예측력이 높아지는 것은 아니다. 서로 중복되는 지표를 지나치게 많이 사용하면 분석이 복잡해지고 우연한 관계를 중요한 패턴으로 오해할 가능성도 커진다.

12. 데이터 품질이 분석 결과의 신뢰도를 결정한다

분석 방법이 아무리 정교해도 데이터가 부정확하면 결과를 신뢰하기 어렵다.

대표적인 문제는 다음과 같다.

• 장애 발생 시각이 부정확하거나 기준이 일관되지 않은 경우
• 로그마다 시간 기준이 달라 순서를 정확하게 비교하기 어려운 경우
• 일부 성능 데이터가 누락된 경우
• 장애 유형과 원인 분류가 일관되지 않은 경우
• 정상 데이터가 충분하지 않은 경우
• 발생했지만 기록되지 않은 장애가 있는 경우
• 모니터링 설정이 변경되어 과거와 현재의 데이터 수집 방식이 다른 경우

이러한 문제는 실제로 존재하지 않는 패턴을 만들어 내거나 중요한 신호를 놓치게 할 수 있다.

따라서 분석을 시작하기 전에 데이터가 실제 장애 상황과 운영 환경을 정확하게 반영하고 있는지부터 확인해야 한다.

13. 과거와 현재의 시스템 환경이 달라질 수 있다

과거에 동일한 장애가 반복되었다고 해도 미래에 같은 방식으로 발생한다고 보장할 수는 없다.

다음과 같은 변화는 과거 패턴의 의미를 바꿀 수 있다.

• 서버 교체 또는 CPU·메모리 증설
• 운영체제 및 소프트웨어 업데이트
• 애플리케이션 구조 변경
• 네트워크 구성 변경
• 데이터베이스 구조 변경
• 사용자 수와 트래픽 패턴 변화
• 작업 일정 및 배치 처리 방식 변경
• 모니터링 정책이나 데이터 수집 방식 변경

예를 들어 과거에는 메모리 사용량이 일정 수준을 넘으면 장애가 발생했더라도, 메모리를 증설한 이후에는 같은 수치가 더 이상 동일한 위험을 의미하지 않을 수 있다.

따라서 과거 데이터를 활용할 때는 다음 질문을 먼저 확인해야 한다.

이 과거 데이터가 현재 시스템의 구성과 운영 조건을 얼마나 잘 반영하고 있는가?

환경이 크게 달라졌다면 기존 패턴을 그대로 적용하기보다 새로운 데이터를 확보해 다시 검증해야 한다.

14. 예측 모델을 적용하기 전에 확인할 사항

충분한 데이터가 있다면 통계적 분석이나 머신러닝을 이용해 장애 가능성을 추정할 수 있다. 하지만 복잡한 모델을 적용하는 것 자체가 예측 성능을 보장하지는 않는다.

모델을 만들기 전에 다음 사항을 확인해야 한다.

• 장애의 정의와 판정 기준이 일관적인가
• 장애 사례와 정상 사례가 충분히 확보되어 있는가
• 데이터 누락과 시간 정보 오류가 얼마나 있는가
• 장애 유형이 한두 종류에 지나치게 편중되어 있지 않은가
• 학습에 사용한 데이터와 검증용 데이터가 적절하게 분리되어 있는가
• 과거와 현재의 시스템 환경에 차이가 있는가
• 예측 결과를 실제 운영에서 어떻게 활용할 것인가

특히 장애가 드물게 발생하는 시스템에서는 정상 상태를 대부분 정상으로만 분류해도 겉보기 정확도가 높게 나올 수 있다. 그러므로 전체 정확도만 보지 말고 실제 장애를 얼마나 찾아내는지, 정상 상태를 장애로 잘못 판단하는 경우는 얼마나 되는지도 함께 확인해야 한다.

즉, 좋은 예측은 복잡한 알고리즘보다 신뢰할 수 있는 데이터와 적절한 검증에서 시작한다.

15. 분석에 사용하지 않은 데이터로 검증한다

과거 장애 데이터에서 패턴을 찾아 기준을 만들었다면, 그 기준이 실제로 활용 가능한지 별도의 데이터로 검증해야 한다.

분석에 사용한 데이터에만 기준을 적용하면 해당 사례에 지나치게 맞춰진 결과가 나올 수 있기 때문이다.

가능하다면 다음 순서로 진행한다.

과거 데이터 수집 → 후보 패턴 탐색 → 탐지 기준 설정 → 별도 데이터로 검증 → 실제 성능 평가

시간의 흐름에 따라 새로운 장애가 발생하는 시스템에서는 과거 시점의 데이터로 기준을 만들고, 그보다 나중에 수집된 데이터로 검증하는 방식이 현실적인 평가에 도움이 된다.

이때 같은 장애 사건에서 나온 데이터가 학습용과 검증용 양쪽에 섞이지 않도록 주의해야 한다. 동일 사건의 유사한 기록이 양쪽에 포함되면 새로운 장애에서도 성능이 유지되는 것처럼 결과가 과대평가될 수 있다.

새로운 데이터에서 패턴이 재현되지 않는다면 분석 기준을 다시 검토해야 한다. 이는 분석의 실패라기보다 해당 패턴이 특정 환경이나 일부 장애 사례에만 유효했음을 확인한 결과일 수 있다.

16. 오탐과 미탐을 함께 평가한다

장애를 많이 찾아내는 것만으로 좋은 예측 기준이라고 할 수는 없다.

정상 상태를 장애로 잘못 판단하는 오탐이 지나치게 많으면 운영자가 불필요한 경보를 계속 처리해야 한다. 반대로 실제 장애를 놓치는 미탐이 많으면 조기탐지의 목적을 달성하기 어렵다.

따라서 다음 항목을 함께 평가해야 한다.

• 실제 장애 중 경보가 발생한 비율
• 정상 상태에서 잘못 발생한 경보의 빈도
• 경보가 실제 장애보다 얼마나 먼저 발생했는지
• 경보 이후 실제 대응이 가능했는지
• 새로운 장애 사례에서도 성능이 유지되는지

또한 장애가 드문 시스템에서는 단순한 예측 정확도만으로 판단하지 않는 것이 중요하다. 경보가 실제 장애와 얼마나 관련 있는지, 운영자가 감당할 수 있는 수준으로 경보가 발생하는지도 함께 살펴야 한다.

결국 좋은 탐지 기준은 장애를 가능한 한 많이 찾아내는 동시에 불필요한 경보를 줄이고 실제 대응에 도움이 되는 정보를 제공하는 기준이다.

17. 예측 가능성과 원인 규명은 구분해야 한다

특정 패턴이 장애 전에 반복적으로 나타난다고 해서 그 패턴이 장애의 직접적인 원인이라는 뜻은 아니다.

예를 들어 특정 오류가 장애 직전에 반복적으로 발생한다고 하자. 그 오류가 장애를 일으키는 원인일 수도 있지만, 더 근본적인 문제로 인해 함께 나타나는 결과일 수도 있다.

따라서 다음 두 질문을 구분해야 한다.

① 이 신호는 장애보다 먼저 나타나는가?

② 이 신호가 장애를 발생시키는 원인인가?

첫 번째 질문에 대한 근거가 충분하다면 해당 신호는 조기탐지에 활용할 가치가 있을 수 있다. 하지만 두 번째 질문에 답하려면 추가적인 원인 분석과 검증이 필요하다.

이 구분은 중요하다. 장애를 미리 알리는 데 유용한 신호와 장애를 실제로 해결하기 위해 조치해야 할 원인이 반드시 같지는 않기 때문이다.

18. 실제 운영에 적용하는 분석 절차

과거 장애 데이터를 이용한 예측 가능성 분석은 다음과 같은 순서로 진행할 수 있다.

1단계. 과거 장애 사례 수집

장애 발생 시각, 유형, 영향 범위, 원인 및 복구 결과를 정리한다.

2단계. 장애 이전 데이터 확보

성능 지표와 로그, 이벤트, 변경 이력을 시간 순서대로 확보한다.

3단계. 정상 사례 확보

트래픽과 작업 조건 등이 유사한 상황에서 장애가 발생하지 않은 데이터를 확보한다.

4단계. 데이터 품질 확인

시간 기준, 누락, 분류 오류, 수집 방식의 차이를 확인한다.

5단계. 공통 패턴 탐색

여러 장애 사례에서 반복되는 변화와 지표 간 관계를 찾는다.

6단계. 정상 사례와 비교

해당 패턴이 정상 운영에서도 나타나는지 확인한다.

7단계. 시간적 선행성 평가

후보 신호가 장애보다 먼저 나타나는지, 선행시간이 얼마나 되는지 확인한다.

8단계. 후보 탐지 기준 설정

지속시간, 변화 속도, 반복성, 복수 지표의 관계 등을 고려해 기준을 만든다.

9단계. 별도 데이터로 검증

분석에 사용하지 않은 데이터에 기준을 적용해 재현성을 확인한다.

10단계. 실제 활용 가치 평가

오탐, 미탐, 경보 선행시간, 대응 가능성을 함께 검토한다.

11단계. 지속적인 재평가

시스템 환경이나 장애 유형이 바뀌면 기존 기준의 유효성을 다시 확인한다.

이 절차의 목적은 과거 장애와 비슷한 현상을 무조건 찾아내는 것이 아니다. 실제 장애를 구분하는 데 도움이 되는 신호를 찾아내고, 새로운 상황에서도 그 가치가 유지되는지 확인하는 것이다.

19. 분석을 시작할 때 먼저 던져야 할 질문

과거 장애 데이터를 분석할 때 처음부터 어떤 알고리즘을 사용할지 결정할 필요는 없다. 먼저 데이터가 어떤 질문에 답할 수 있는지 확인하는 편이 효과적이다.

① 장애 전에 반복되는 변화가 있었는가?

② 그 변화는 정상 상태에서도 발생했는가?

③ 장애보다 얼마나 먼저 나타났는가?

④ 서로 다른 장애 사례에서도 재현되었는가?

⑤ 현재 시스템에서도 같은 조건이 유지되는가?

⑥ 해당 신호를 발견했을 때 실제로 대응할 시간이 있었는가?

이 질문에 충분히 답할 수 있다면 통계 분석이나 머신러닝을 적용할 근거가 마련된다. 반대로 기본적인 데이터와 비교 사례가 부족하다면 복잡한 모델부터 만드는 것보다 데이터 수집과 기록 체계를 개선하는 일이 우선일 수 있다.

20. Ⅳ-6, Ⅳ-7, Ⅳ-8의 역할 구분

이 장은 앞에서 설정한 탐지 기준을 과거 장애 데이터에 비추어 검토하는 단계다.

각 장의 역할을 다음과 같이 구분할 수 있다.

• Ⅳ-6: 정상 상태를 파악하고 기준선과 탐지 임계값을 어떻게 설정할 것인가?
• Ⅳ-7: 과거 장애 데이터에서 발견한 패턴이 조기탐지에 활용될 가능성이 있는가?
• Ⅳ-8: 설정한 탐지 기준이 실제 데이터에서 얼마나 잘 작동하는지 어떻게 평가할 것인가?

즉, 기준을 설정하는 것과 과거 데이터에서 유망한 신호를 찾는 것, 실제 탐지 성능을 평가하는 것은 서로 연결되어 있지만 동일한 작업은 아니다.

이렇게 역할을 나누면 다음 장에서는 과거 장애 패턴을 다시 설명하기보다 탐지 기준의 성능을 평가하는 방법에 집중할 수 있다.

21. 과거 장애 데이터의 진짜 가치는 예언이 아니라 검증에 있다

과거 장애 데이터만으로 미래의 장애를 정확하게 예언하기는 어렵다. 시스템 환경과 사용량은 변하고, 장애의 원인과 진행 과정도 매번 같지 않을 수 있기 때문이다.

그러나 장애가 발생하기 전에 어떤 변화가 나타났는지 분석하면 조기탐지에 활용할 후보 신호를 찾을 수 있다.

그 신호가 정상 상태와 구별되고, 여러 장애에서 반복되며, 분석에 사용하지 않은 데이터에서도 재현되고, 실제 대응에 필요한 선행시간까지 제공한다면 운영상의 가치가 높아진다.

따라서 과거 장애 데이터는 미래 장애를 확정적으로 예측하는 자료라기보다 미래 장애를 더 일찍 발견할 가능성을 검토하고 탐지 기준을 개선하는 자료로 이해하는 것이 적절하다.

22. 핵심정리

과거 장애 데이터에서 중요한 것은 장애가 발생했다는 사실 자체가 아니라 장애 이전에 어떤 변화가 있었으며, 그 변화가 정상 상태와 어떻게 달랐는지를 재구성하는 것이다.

또한 과거 장애에서 반복된 패턴이라고 해서 자동으로 예측 기준이 되는 것은 아니다. 반복성, 정상 상태와의 구별, 시간적 선행성, 새로운 데이터에서의 재현성, 실제 대응 가능한 선행시간을 함께 확인해야 한다.

마지막으로 우리 시스템에 던져볼 질문은 이것이다.

“과거 장애에서 발견한 패턴은 과거 사례에만 맞는 특징인가, 아니면 현재 시스템에서도 실제 장애보다 먼저 나타나 대응할 시간을 제공하는 유효한 조기탐지 신호인가?”