[Time Series] 이상탐지기는 실제 고장을 잡아내나 — 라벨된 데이터로 재봤다

이상탐지 글은 대개 “이런 알고리즘이 있습니다”로 끝납니다. 그런데 실무의 질문은 하나입니다. 그래서 진짜 고장을 잡나요?

지난 글에서 시계열 파운데이션 모델의 예측 성능을 쟀는데, 예측을 잘한다고 이상탐지도 잘한다는 보장은 없습니다. 실제 고장이 라벨된 데이터에 붙여서 세어봤습니다.

확인 환경과 데이터

Python 3.13.7 · pandas 3.0.2 · numpy 2.4.4 · scikit-learn 1.9.0 · Chronos-2 (torch 2.14.0+cpu)

데이터는 NAB의 realKnownCause 계열입니다. 고장 원인이 실제로 확인된 것만 모아둔 묶음이라 라벨을 믿을 수 있습니다.

데이터셋	행 수	간격	라벨 구간
machine_temperature_system_failure	22,695	5분	4
cpu_utilization_asg_misconfiguration	18,050	5분	1
nyc_taxi	10,320	30분	5
ambient_temperature_system_failure	7,267	1시간	2
rogue_agent_key_updown	5,315	5분	2
ec2_request_latency_system_failure	4,032	5분	3
rogue_agent_key_hold	1,882	5분	2
합계	69,561		19

비교를 공정하게 만드는 장치

여기가 이 글에서 제일 중요한 부분입니다. 임계값을 각자 정하게 두면 비교가 성립하지 않습니다. 많이 울리는 탐지기가 재현율로 이기니까요.

그래서 세 가지를 고정했습니다.

하나, 알람 예산을 맞췄습니다. 각 탐지기는 시점마다 이상 점수만 내고, 임계값은 제가 정합니다. 점수 상위 K개만 알람으로 치는데 K는 전부 같습니다.

둘, 붙어 있는 알람은 한 사건으로 셌습니다. 한 번의 이상에 30개 점이 연속으로 튀면 알람 30회가 아니라 1회입니다.

셋, 전부 인과적입니다. 미래 값을 쓰는 탐지기는 없습니다. 이동통계는 shift(1)로 현재 값을 빼고, IsolationForest는 앞 15%만 학습하고, Chronos는 과거 512점만 봅니다.

NAB의 라벨은 점이 아니라 구간입니다. 구간 안에서 한 번만 울려도 잡은 것으로 칩니다. 조기 탐지를 인정하려는 설계인데, 그만큼 관대한 채점이라는 점은 감안하고 보셔야 합니다.

붙여본 탐지기 넷

탐지기	이상 점수
이동평균 3σ	이동평균에서 몇 표준편차 떨어졌나
롤링중앙값 MAD	중앙값에서 얼마나 떨어졌나 (이상치에 덜 흔들리는 버전)
IsolationForest	값·이동평균·이동표준편차·차분 네 특징으로 고립 정도
Chronos-2 예측오차	다음 32점을 예측해서 실제와 얼마나 빗나갔나

마지막이 이 글의 질문입니다. 예측 모델을 탐지기로 쓰면 어떤가.

알람 예산 0.5%에서

전체 시점의 0.5%만 알람으로 허용했을 때입니다.

탐지기	탐지	재현율	헛알람
Chronos-2 예측오차	15 / 19	78.9%	72
IsolationForest	13 / 19	68.4%	58
이동평균 3σ	12 / 19	63.2%	153
롤링중앙값 MAD	7 / 19	36.8%	116

Chronos가 가장 많이 잡았습니다. 다만 헛알람도 IsolationForest보다 많습니다. 한 지점만 보면 누가 낫다고 말하기 어렵습니다.

그래서 예산을 쓸어봤습니다.

오탐을 더 감수하면 몇 개나 더 잡나

알람 예산을 0.05%에서 3%까지 올려가며 잰 결과입니다

교차가 생깁니다.

헛알람을 적게 유지해야 하는 왼쪽 구간에서는 Chronos가 확실히 앞섭니다. 헛알람 29회에 12개, 41회에 14개를 잡는데 같은 지점에서 IsolationForest는 7개와 10개입니다.

그런데 오른쪽으로 가면 뒤집힙니다. Chronos는 16개에서 멈추고 더 이상 올라가지 않습니다. 예산을 아무리 줘도 못 잡는 구간이 남습니다. IsolationForest는 계속 올라가 18개까지 갑니다.

헛알람 수준	우세한 쪽
30~150회	Chronos-2 (12~16개 vs IsolationForest 7~14개)
200회 이상	IsolationForest (17~18개 vs Chronos 16개)

19개를 다 잡은 탐지기는 없습니다.

어디서 울렸나

설비 온도 데이터 하나만 펼쳐보면 성격 차이가 보입니다.

같은 예산에서 각 탐지기가 울린 위치입니다

2월 초의 온도 급락은 셋 다 잡았습니다. 눈으로 봐도 이상하니까요.

차이는 헛알람의 성격입니다. Chronos는 9회로 가장 적고, IsolationForest는 16회인데 대신 구간 하나를 더 잡았습니다. 3σ는 14회를 울리면서 2개만 잡았습니다.

뜻밖이었던 것

“이상치에 강한” MAD가 제일 못했습니다. 중앙값과 MAD는 이상치가 통계량을 오염시키는 걸 막아주는데, 이상탐지에서는 그게 오히려 손해였습니다. 찾아야 할 대상 자체를 눌러버리는 셈이니까요. 어느 예산에서도 4등이었습니다.

3σ는 일찍 정체합니다. 예산 0.005부터 0.015까지 12개에서 멈춰 있습니다. 헛알람만 153회에서 431회로 늘고 잡는 건 그대로입니다. 알람을 더 울려도 소용없는 구간이 있다는 뜻입니다.

Chronos는 싸게 잡고 일찍 멈춥니다. 적은 알람으로 많이 잡지만 상한이 낮습니다. 예측이 잘 되는 종류의 이상은 오차로 잘 드러나는데, 예측 모델이 이미 잘 맞히고 있는 이상은 오차가 안 커집니다.

비용

Chronos로 69,561행 전체를 채점하는 데 CPU에서 46.3초 걸렸습니다. 나머지 셋은 1초 미만입니다.

실시간 탐지라면 5분마다 32점을 채점하는 것이니 부담이 아닙니다. 다만 모델 하나 띄우는 값어치가 있느냐는 별개 문제입니다.

한계

여기부터 반드시 붙여야 할 단서입니다.

표본이 19개입니다. 1~2개 차이는 의미 없습니다. “Chronos 15 vs IsolationForest 13”을 성능 차이로 읽으면 안 됩니다. 곡선의 경향만 보시는 게 맞습니다.

하이퍼파라미터를 데이터셋별로 맞추지 않았습니다. 창 크기 288, 컨텍스트 512 같은 값을 전부 고정했습니다. 데이터셋마다 튜닝하면 순위가 바뀔 수 있습니다.

NAB 라벨 구간이 넉넉합니다. 전체 시점의 10%가 구간 안이고, 그 안 어디서든 울리면 정답입니다. 실제 운영에서 요구하는 정밀도와는 다릅니다.

그리고 이 비교의 전제가 현실에 없습니다. 알람 예산을 맞추려면 점수 분포 전체를 미리 알아야 하는데, 실시간에서는 그게 불가능합니다. 임계값을 어떻게 정할 것인가가 실제로는 알고리즘 선택보다 중요할 수 있습니다.

정리

넷을 같은 조건에 놓고 세어본 결론입니다.

예측 모델을 탐지기로 쓰는 건 실제로 통합니다. 다만 만능은 아니고, 헛알람을 적게 유지해야 하는 조건에서 강합니다.

단순한 방법이 무의미하지도 않습니다. IsolationForest는 특징 네 개짜리 모델인데 높은 예산에서 가장 많이 잡았습니다. 파운데이션 모델을 띄우기 전에 이걸 먼저 돌려보는 게 순서로 맞습니다.

“이상치에 강하다”가 이상탐지에 유리하다는 뜻은 아닙니다. MAD가 그 반례입니다.

그리고 무엇보다 — 혼자 돌려보고 “잘 맞네” 하면 안 됩니다. 기준선 없이는 잘하는지 알 수 없고, 알람 예산을 맞추지 않으면 비교 자체가 성립하지 않습니다. 이 글에서 가장 오래 걸린 것도 알고리즘이 아니라 비교를 공정하게 만드는 부분이었습니다.

참고

• numenta/NAB — 라벨된 이상탐지 벤치마크. realKnownCause 7종과 combined_windows.json 을 썼습니다 (2026-09-08 확인)
• sklearn.ensemble.IsolationForest — 공식 문서
• amazon/chronos-2 — 예측오차 탐지기에 쓴 모델
• 시계열 파운데이션 모델을 진짜로 돌려봤다 — 예측 성능 편. 이 글이 그 후속입니다
• 시계열에도 파운데이션 모델이 왔다 — 개념 편