Ⅳ-6. 시스템 장애 조기탐지를 위한 기준선과 탐지 임계값 분석

컴퓨터 시스템의 장애를 조기에 발견하려면 먼저 정상 상태가 어떤 모습인지 판단할 수 있는 기준이 필요하다.

이때 대표적으로 활용되는 개념이 **기준선(Baseline)**과 **탐지 임계값(Threshold)**이다.

기준선은 시스템이 정상적으로 운영될 때 나타나는 성능과 상태의 범위를 이해하기 위한 기준이다. 임계값은 특정 지표가 정해진 조건을 벗어났을 때 추가 확인이나 경보가 필요한지를 판단하기 위한 기준이다.

따라서 두 개념은 같은 의미가 아니다.

기준선이 정상 상태를 이해하기 위한 기준이라면, 임계값은 운영 중 어느 시점부터 주의하거나 대응할 것인지를 결정하기 위한 기준이다.

1. 기준선의 의미

기준선은 시스템이 정상적으로 운영될 때 성능 지표가 어떤 범위에서 변화하는지 파악하기 위해 사용한다.

예를 들어 서버의 CPU 사용률이 평소 다음과 같은 범위에서 움직인다고 가정해 보자.

시간대	일반적인 CPU 사용률
업무시간	50~75%
점심시간	35~60%
야간	10~30%

이 시스템에서 CPU 사용률 70%를 무조건 비정상이라고 판단하기는 어렵다. 업무시간에는 정상적인 사용 범위일 수 있기 때문이다.

반대로 야간에 평소 10~30% 수준이던 CPU 사용률이 갑자기 70%까지 증가했다면, 최종 수치가 다른 시간대의 정상 범위에 들어가더라도 변화 원인을 확인할 필요가 있다.

따라서 기준선은 정상값 하나를 정하는 것이 아니라 정상 상태의 범위와 시간에 따른 변동 특성을 함께 파악하는 과정이다.

2. 기준선은 하나의 숫자가 아니다

실제 시스템의 정상 상태는 항상 일정하지 않다.

시간대, 요일, 업무량, 사용자 수, 정기 작업, 계절적인 사용량 변화 등에 따라 정상적인 성능 수준이 달라질 수 있다.

기준선을 설정할 때는 다음 요소를 함께 고려할 수 있다.

• 평균값과 중앙값
• 상위·하위 백분위수
• 정상적인 변동 범위
• 시간대와 요일에 따른 차이
• 요청량이나 사용자 수에 따른 변화
• 정기 작업과 배치 처리의 영향
• 정상적인 고부하 상황에서의 성능 특성

평균값 하나만 사용하면 일시적인 급변이나 일부 극단적인 값의 영향을 제대로 파악하지 못할 수 있다.

예를 들어 평균 응답시간이 정상 범위에 있더라도 일부 요청의 응답시간이 크게 증가할 수 있다. 이런 경우에는 p95나 p99와 같은 백분위수도 함께 살펴보는 것이 유용하다.

다만 어떤 통계값을 사용할지는 지표의 특성과 분석 목적에 따라 달라져야 한다.

3. 기준선을 만들 때 정상 데이터부터 확인한다

기준선의 정확도는 어떤 데이터를 사용했는지에 따라 달라진다.

장애가 발생하지 않았던 기간의 데이터라고 해서 모든 구간이 정상 상태를 대표하는 것은 아니다. 장애로 이어지지는 않았지만 이미 성능이 저하된 상태가 포함되어 있을 수도 있고, 정기적인 고부하 작업이 정상 운영의 일부일 수도 있다.

따라서 기준선을 만들기 전에 다음 사항을 확인해야 한다.

1. 분석 대상 기간에 실제 장애나 성능 저하가 있었는가?
2. 정기 작업과 정상적인 고부하 구간이 구분되어 있는가?
3. 데이터 수집 누락이나 측정 오류가 있는가?
4. 시스템 구성이나 업무량이 크게 달라진 시점이 있는가?
5. 확보한 데이터가 실제 정상 운영을 충분히 대표하는가?

정상 데이터를 잘못 선정하면 비정상 상태가 정상 범위에 포함되거나, 정상적인 변동이 이상 상태로 분류될 수 있다.

기준선 설정은 통계값을 계산하기 전에 정상 상태를 정의하는 작업부터 시작해야 한다.

4. 고정 임계값의 장점과 한계

고정 임계값은 관리하기 쉽고 이해하기 간단하다.

예를 들어 CPU 사용률이 90%를 초과하면 경보를 발생시키는 방식이다. 조건이 명확하므로 구현과 운영이 비교적 단순하다.

그러나 시스템마다 정상적인 사용 특성이 다르기 때문에 같은 값을 일괄 적용하기에는 한계가 있다.

평소 CPU 사용률이 85~90% 수준인 시스템과 20~30% 수준인 시스템은 같은 90%라는 값도 의미가 다를 수 있다.

또한 CPU 사용률이 90% 미만이더라도 응답시간이 크게 증가하거나 오류가 발생할 수 있다.

따라서 고정 임계값은 단순한 운영 기준으로 유용하지만, 시스템의 정상 특성과 실제 서비스 영향을 충분히 반영하지 못할 수 있다.

5. 동적 기준선이 필요한 경우

정상 상태가 시간이나 운영 조건에 따라 달라지는 시스템에서는 상황에 따른 기준선을 사용할 수 있다.

예를 들어 온라인 서비스는 낮에 사용자 수가 증가하고 새벽에는 감소할 수 있다. 월말에는 정산 작업 때문에 평소보다 자원 사용량이 높아질 수도 있다.

다음과 같은 환경에서는 동적 기준선이 유용할 수 있다.

• 평일과 주말의 사용량 차이가 큰 시스템
• 월말·월초에 업무량이 증가하는 시스템
• 정기적인 배치 작업이 있는 시스템
• 시간대에 따라 사용자 수가 크게 달라지는 서비스
• 요청량에 따라 자원 사용량이 달라지는 시스템

다만 동적 기준선이 항상 더 좋은 것은 아니다.

기준선이 현재 상태를 지나치게 빠르게 따라가면 지속적인 성능 저하마저 정상적인 변화로 받아들일 수 있다. 따라서 기준선을 갱신할 때는 장애나 비정상 상태가 학습 데이터에 섞이지 않도록 관리해야 한다.

6. 정상 범위와 경보 기준은 다를 수 있다

정상 범위의 상한선과 실제 경보를 발생시키는 임계값은 반드시 같을 필요가 없다.

예를 들어 CPU 사용률의 일반적인 정상 범위가 30~70%라고 하더라도 70%를 넘는 순간마다 경보를 발생시키면 일시적인 업무량 증가까지 모두 경보로 처리될 수 있다.

반대로 정상 범위를 벗어났더라도 서비스 영향이 없고 곧 정상으로 복귀한다면 즉각적인 대응보다 관찰이 적절할 수 있다.

따라서 다음과 같이 구분할 수 있다.

구분	목적	예시
정상 범위	일반적인 상태 파악	평소 변동 범위
주의 기준	변화 확인 시작	평소 범위를 벗어난 상태
경보 기준	우선적인 점검 필요	이상이 일정 시간 지속
대응 기준	실제 조치 판단	서비스 영향이나 위험 증가

이 단계는 예시이며 모든 시스템에 동일하게 적용되는 표준은 아니다.

핵심은 정상 범위를 벗어났다는 사실과 즉시 대응해야 한다는 판단을 구분하는 것이다.

7. 임계값 초과시간을 함께 고려한다

성능 지표가 임계값을 한 번 넘었다고 해서 곧바로 장애로 판단해서는 안 된다.

예를 들어 CPU 사용률이 90%를 5초 동안 기록한 뒤 정상으로 돌아왔다면 일시적인 작업량 증가일 수 있다. 반면 같은 상태가 장시간 지속되고 응답시간까지 증가한다면 추가 조사가 필요할 수 있다.

따라서 다음과 같이 조건을 구성할 수 있다.

• 임계값 초과 여부
• 초과 상태의 지속시간
• 일정 시간 동안의 초과 횟수
• 정상 범위로 복귀하는 데 걸리는 시간
• 다른 성능 지표의 동반 변화

예를 들어 단순히 ‘CPU 사용률 90% 초과’라고 설정하는 대신 ‘90% 초과 상태가 일정 시간 이상 지속’되는 조건을 사용할 수 있다.

다만 지속시간을 지나치게 길게 설정하면 실제 이상을 늦게 발견할 수 있다.

따라서 오탐을 줄이는 것과 조기탐지 속도를 확보하는 것 사이에서 적절한 기준을 찾아야 한다.

8. 변화율은 현재 값과 다른 정보를 제공한다

현재 값이 임계값을 넘었는지만 보는 방법에는 한계가 있다.

예를 들어 메모리 사용률이 60%라고 하자. 이 값 자체만으로 반드시 위험한 상태라고 할 수는 없다.

그러나 짧은 시간에 30%에서 60%로 증가했다면 현재 값뿐 아니라 변화 과정도 확인할 필요가 있다.

이때 살펴볼 수 있는 정보는 다음과 같다.

• 현재 값
• 이전 값과의 차이
• 일정 시간 동안의 변화량
• 단위 시간당 변화 속도
• 변화가 계속되는지 여부
• 변화 이후 정상 상태로 복귀하는지 여부

절대값은 현재 상태의 수준을 보여 주고, 변화율은 상태가 얼마나 빠르게 달라지고 있는지를 보여 준다.

두 정보를 함께 사용하면 현재 수치만으로는 파악하기 어려운 급격한 변화를 발견하는 데 도움이 된다.

다만 변화율이 크다는 사실만으로 장애가 임박했다고 단정해서는 안 된다. 정상적인 작업 시작이나 계획된 처리에서도 급격한 변화가 나타날 수 있기 때문이다.

9. 여러 지표를 함께 사용해 탐지 기준을 구성한다

단일 지표만으로 시스템 상태를 판단하면 정상적인 변동을 이상으로 판단하거나 실제 문제를 놓칠 수 있다.

예를 들어 CPU 사용률만 증가했다면 정상적인 계산 작업일 수 있다. 하지만 CPU 사용률 증가와 함께 응답시간과 오류율이 악화된다면 서비스에 영향을 주는 상황인지 확인할 필요가 있다.

탐지 조건은 다음과 같이 구성할 수 있다.

탐지 방식	조건 예시	활용 목적
절대값	CPU 사용률이 특정 값 초과	높은 사용 수준 확인
지속시간	임계값 초과가 일정 시간 지속	순간적인 변동과 구분
변화율	메모리 사용량이 빠르게 증가	급격한 상태 변화 확인
반복성	일정 시간 동안 이상이 반복	반복 패턴 확인
다중 지표	응답시간과 오류율이 함께 증가	서비스 영향 확인
복합 조건	임계값 초과와 지속시간 증가, 서비스 영향 동반	우선 점검 대상 선정

여러 조건을 결합하면 판단에 도움이 될 수 있지만, 조건이 복잡해질수록 탐지 지연이나 미탐이 발생할 가능성도 함께 검토해야 한다.

또한 지표가 동시에 변했다는 사실만으로 인과관계를 확정해서는 안 된다. 실제 원인 판단에는 로그와 이벤트, 운영 조건을 추가로 확인해야 한다.

10. 기준선과 임계값을 만드는 기본 절차

실제 시스템에 적용할 때는 다음 순서로 접근할 수 있다.

① 정상 데이터 수집

장애와 성능 저하 여부를 확인할 수 있는 충분한 기간의 데이터를 확보한다.

② 정상 상태의 변동 범위 확인

시간대, 요일, 업무량, 정기 작업 등에 따른 차이를 분석한다.

③ 과거 장애 데이터 비교

장애 발생 전 어떤 지표가 언제 변화했는지 확인한다.

④ 탐지 후보 조건 선정

절대값, 지속시간, 변화율, 반복성, 여러 지표의 조합을 검토한다.

⑤ 초기 임계값 설정

시스템 특성과 서비스 중요도를 고려해 초기 기준을 만든다.

⑥ 과거 데이터로 검증

과거 장애와 정상 사례에 기준을 적용해 오탐과 미탐을 확인한다.

⑦ 운영 환경에서 재검증

실제 운영 중 경보가 적절한 시점에 발생하는지 확인한다.

⑧ 기준 수정

새로운 장애 사례와 시스템 변화에 맞춰 기준을 조정한다.

이처럼 임계값은 한 번 설정하고 끝나는 값이 아니다. 실제 운영 데이터와 검증 결과를 통해 지속적으로 관리해야 한다.

11. 오탐과 미탐의 균형

탐지 기준을 너무 민감하게 설정하면 정상적인 변동에도 경보가 발생한다. 이를 오탐(False Positive)이라고 한다.

반대로 기준을 너무 느슨하게 설정하면 실제 이상 상태를 놓칠 수 있다. 이를 미탐(False Negative)이라고 한다.

두 문제는 모두 운영에 영향을 준다.

하루에 수백 건의 불필요한 경보가 발생하면 운영자가 경보에 익숙해져 중요한 신호를 놓칠 수 있다. 반대로 경보를 거의 발생시키지 않도록 기준을 지나치게 느슨하게 설정하면 조기탐지의 목적을 달성하기 어렵다.

따라서 다음 항목을 함께 평가할 필요가 있다.

• 실제 장애를 얼마나 자주 탐지했는가
• 정상 상태에서 불필요한 경보가 얼마나 발생했는가
• 장애 발생 전에 경보가 얼마나 일찍 나타났는가
• 경보 이후 실제 대응할 시간이 충분했는가
• 운영자가 경보를 확인하고 조치할 수 있는 수준인가

좋은 탐지 기준은 경보를 많이 발생시키는 기준이 아니라, 대응할 가치가 있는 이상을 적절한 시점에 알려 주는 기준이다.

12. 장애 유형과 자원 특성에 따라 기준을 달리한다

CPU, 메모리, 저장장치, 네트워크는 정상적인 변화 특성이 서로 다르다. 따라서 모든 지표에 같은 방식의 임계값을 적용하기보다는 자원의 특성과 장애 유형을 고려해야 한다.

대상	함께 확인할 요소
CPU	사용률, 실행 대기열, 응답시간, 프로세스 변화
메모리	사용량, 가용 메모리, 스왑 및 페이지 활동
저장장치	I/O 지연, 처리량, 오류, 대기열
네트워크	지연, 패킷 손실, 재전송, 처리량, 연결 상태
서비스	응답시간, 오류율, 처리량, 요청 실패

예를 들어 CPU 사용률이 높더라도 서비스 응답이 정상이라면 즉각적인 장애 경보보다 관찰이 적절할 수 있다.

반면 서비스 응답시간과 오류율이 동시에 악화된다면 CPU 사용률이 높지 않더라도 조사가 필요할 수 있다.

중요한 것은 특정 지표에 절대적인 의미를 부여하는 것이 아니라 그 지표의 변화가 해당 시스템에서 어떤 상태와 연결되는지 확인하는 것이다.

13. 잘못된 기준선은 잘못된 임계값으로 이어진다

임계값을 설정한 뒤에도 경보가 계속 발생한다면 임계값만 높이는 방식으로 해결하려 해서는 안 된다.

문제가 기준선에 있을 수도 있기 때문이다.

예를 들어 매일 새벽 2시에 정기 배치 작업으로 CPU 사용률이 증가하는 시스템에서 이 작업의 특성을 고려하지 않고 기준선을 만들면 같은 시간에 불필요한 경보가 반복될 수 있다.

반대로 장애가 발생하기 직전의 비정상 데이터가 정상 데이터에 포함되면 비정상적인 상태가 정상 범위에 섞일 수 있다.

따라서 경보가 부적절하게 발생할 때는 다음을 확인한다.

1. 기준선에 사용한 데이터가 정상 상태를 대표하는가?
2. 정기 작업과 정상적인 고부하가 구분되어 있는가?
3. 최근 시스템 구성과 사용량이 달라졌는가?
4. 임계값이 실제 서비스 영향과 연결되어 있는가?
5. 수집 주기와 데이터 품질에 문제가 없는가?

임계값 조정에 앞서 기준선과 데이터의 적절성을 확인해야 불필요한 수정과 반복적인 경보 문제를 줄일 수 있다.

14. 서비스 중요도와 위험 수준을 반영한다

같은 지표라도 서비스의 중요도에 따라 허용할 수 있는 위험 수준은 달라질 수 있다.

예를 들어 내부 테스트 서버와 핵심 고객 서비스를 제공하는 서버에 동일한 경보 정책을 적용할 필요는 없다.

서비스의 중요도, 장애가 발생했을 때의 영향, 복구에 필요한 시간, 대응 가능한 인력 등을 고려해 경보의 우선순위와 대응 수준을 정할 수 있다.

이때 서비스 중요도가 높다고 해서 모든 지표의 임계값을 무조건 낮추는 것은 적절하지 않다. 불필요한 경보가 늘어날 수 있기 때문이다.

대신 어떤 이상을 먼저 확인해야 하는지, 경보 발생 후 얼마나 신속하게 대응해야 하는지, 자동화된 조치를 허용할 수 있는지를 함께 정하는 것이 중요하다.

따라서 임계값은 단순한 기술 수치만이 아니라 서비스의 위험 수준과 운영 대응 체계를 반영하는 판단 기준이다.

15. 단계적인 경보 체계를 구성한다

모든 이상을 하나의 경보로 처리하기보다 위험 수준에 따라 단계를 나눌 수 있다.

예를 들면 다음과 같다.

단계	상태	운영 방향
정상	기준선 내에서 변동	일반적인 모니터링
관심	평소와 다른 변화 발생	추세와 관련 지표 확인
주의	이상이 지속되거나 반복	원인 조사 시작
경보	여러 지표 악화 또는 영향 증가	우선 점검 및 대응 준비
장애 대응	실제 서비스 장애나 중대한 영향 확인	장애 대응 절차 수행

이 단계는 이해를 돕기 위한 예시이며, 실제 단계와 조건은 시스템에 맞춰 설계해야 한다.

특히 경보가 발생했다는 이유만으로 자동으로 시스템을 재시작하거나 서비스를 중단하는 등의 조치를 수행해서는 안 된다. 자동 조치는 오히려 장애를 확대할 수 있으므로, 충분한 검증과 안전장치를 갖춘 경우에만 적용해야 한다.

16. 과거 장애 사례로 탐지 기준을 검증한다

좋은 기준인지 판단하려면 실제 장애 데이터에 적용해 볼 필요가 있다.

예를 들어 과거 장애 20건을 대상으로 다음 사항을 확인할 수 있다.

• 장애 전에 기준선을 벗어난 사례가 몇 건인가?
• 최초 이상 신호는 언제 나타났는가?
• 경보가 실제 장애보다 얼마나 먼저 발생했는가?
• 정상 상태에서도 동일한 조건이 얼마나 자주 나타났는가?
• 경보가 발생한 뒤 실제 대응에 필요한 시간이 확보되었는가?
• 특정 장애 유형에서만 효과가 나타나는가?

여기서 중요한 것은 과거 장애를 얼마나 많이 탐지했는지만 보는 것이 아니다.

경보가 너무 늦게 발생해 대응할 시간이 없거나, 정상 상태에서도 같은 경보가 반복된다면 실무적인 효과가 낮을 수 있다.

따라서 탐지율, 오탐 수준, 미탐 사례, 경보 발생 시점, 대응 가능 시간을 함께 평가해야 한다.

17. 실제 운영 데이터로 재검증한다

과거 데이터에서 효과가 있었던 기준도 실제 운영 환경에서는 다르게 작동할 수 있다.

서비스 이용량과 시스템 구성, 사용자 행동, 외부 의존 서비스 등이 달라지기 때문이다.

따라서 초기 기준을 적용한 뒤에는 다음 사항을 지속적으로 확인해야 한다.

• 경보가 발생하는 빈도
• 경보 이후 실제 이상이 확인되는 비율
• 경보가 발생하지 않았지만 장애가 발생한 사례
• 경보 발생부터 장애까지의 시간
• 경보에 대응하는 데 필요한 작업량
• 특정 시간대나 작업에서 반복되는 오탐

필요하다면 기준을 조정하고, 변경 이후에도 이전보다 탐지 성능이 개선되었는지 확인한다.

기준을 변경할 때는 변경 이유와 적용 시점, 검증 결과를 기록해 두는 것이 좋다. 그래야 이후 장애가 발생했을 때 당시의 판단 기준을 재검토할 수 있다.

18. 기준선과 임계값을 실제 장애 대응에 연결한다

기준선과 임계값을 만드는 것 자체가 최종 목표는 아니다. 실제 장애 대응으로 연결되어야 의미가 있다.

운영 흐름은 다음과 같이 구성할 수 있다.

정상 범위 파악 → 이상 변화 탐지 → 경보 발생 → 관련 지표 확인 → 영향 범위 판단 → 필요 시 대응 → 결과 기록

예를 들어 CPU 사용률이 임계값을 넘었다면 즉시 장애라고 확정하기보다, 지속시간과 실행 대기열, 응답시간, 오류율 등을 확인할 수 있다.

여러 지표가 함께 악화되고 실제 서비스 영향까지 나타난다면 대응 우선순위를 높일 수 있다.

반대로 일시적인 변화이고 서비스 영향이 없다면 원인을 기록하고 추세를 관찰하는 방식이 적절할 수 있다.

이처럼 임계값 초과는 장애 확정 신호가 아니라 확인과 판단을 시작하게 하는 신호로 활용해야 한다.

19. 기준선과 임계값 분석의 한계

기준선과 임계값을 적절하게 설정하더라도 모든 장애를 사전에 발견할 수 있는 것은 아니다.

갑작스러운 하드웨어 고장이나 외부 서비스 장애처럼 사전 변화가 거의 나타나지 않는 경우도 있다. 또한 정상적인 변동과 장애 전조가 비슷하게 나타나 구분하기 어려울 수도 있다.

다음 사항에 주의해야 한다.

• 과거에 발생하지 않은 유형의 장애는 기존 기준으로 탐지하기 어려울 수 있다.
• 기준선이 현재 시스템의 특성을 반영하지 못하면 판단이 부정확해질 수 있다.
• 지나치게 복잡한 조건은 운영자가 이해하고 관리하기 어려울 수 있다.
• 기준선과 임계값이 적절해도 데이터 수집 오류가 있으면 탐지에 실패할 수 있다.
• 경보가 정확하더라도 실제 대응 절차가 없으면 장애 예방 효과가 제한될 수 있다.

따라서 기준선과 임계값은 독립적인 해결책이 아니라 성능 데이터 분석, 로그 확인, 장애 대응 절차와 함께 작동하는 운영 체계의 일부로 이해해야 한다.

20. 앞선 분석을 실제 탐지 기준으로 연결한다

앞의 세 장에서는 장애 발생 전 변화의 내용과 순서, 지속시간과 반복성, 여러 성능 지표 사이의 관계를 살펴봤다.

이번 장에서는 이러한 분석 결과를 실제 운영에서 활용할 수 있도록 정상 범위와 경보 조건을 설정하는 방법을 다뤘다.

각 장의 역할은 다음과 같이 정리할 수 있다.

장	핵심 질문
Ⅳ-3. 장애 발생 전 성능 변화 패턴 분석	어떤 변화가 장애 전에 나타났는가?
Ⅳ-4. 장애 전조 데이터의 지속시간과 반복성 분석	그 변화는 얼마나 지속되고 어떻게 반복되었는가?
Ⅳ-5. 다중 성능 지표를 이용한 시스템 이상 상태 분석	여러 지표는 어떤 관계를 보였는가?
Ⅳ-6. 기준선과 탐지 임계값 분석	어느 시점부터 확인하거나 경보해야 하는가?

이 흐름을 통해 단순한 성능 데이터 관찰에서 벗어나 실제 운영에서 활용할 수 있는 조기탐지 기준을 구성할 수 있다.

21. 최종 판단은 임계값 자체보다 근거에 있다

시스템 장애 조기탐지에서 중요한 질문은 단순히 “CPU가 몇 퍼센트를 넘으면 장애인가?”가 아니다.

더 중요한 질문은 다음과 같다.

• 이 시스템의 정상 상태는 어떤 범위인가?
• 정상적인 변동과 비정상적인 변화를 어떻게 구분하는가?
• 어느 정도의 변화가 발생하면 확인할 필요가 있는가?
• 그 변화가 얼마나 지속되어야 의미가 있는가?
• 다른 지표에서도 관련된 변화가 나타나는가?
• 과거 장애에서 같은 조건이 반복되었는가?
• 경보가 발생했을 때 실제 대응할 시간이 충분한가?

이 질문에 답할 수 있어야 임계값을 단순한 숫자가 아니라 실제 운영에 활용할 수 있는 판단 기준으로 만들 수 있다.

결국 기준선과 임계값 분석의 핵심은 정상 상태를 충분히 이해하고, 실제 장애 데이터와 비교해 검증하며, 운영 환경의 변화에 맞춰 기준을 지속적으로 개선하는 것이다.

22. 핵심정리

첫째, 기준선은 정상 상태를 이해하기 위한 기준이고, 임계값은 추가 확인이나 대응이 필요한 시점을 판단하기 위한 기준이다. 두 기준은 연결되어 있지만 같은 의미는 아니다.

둘째, 좋은 조기탐지 기준은 정상적인 변동을 과도하게 경보하지 않으면서 실제 이상에는 충분히 빠르게 반응하고, 그 효과가 실제 데이터로 검증되어야 한다.

마지막으로 확인해야 할 질문은 이것이다.

“우리 시스템의 임계값은 단순히 정해 놓은 숫자인가, 아니면 정상 데이터와 장애 데이터를 비교하고 실제 운영에서 검증한 판단 기준인가?”