AIOps 스터디 3주차 — 전통 Anomaly Detection의 기본기와 Forecasting Foundation Model의 등장

Detection → Correlation → RCA 파이프라인에서 가장 앞단에 해당하는 Detection과, 그 탐지 방식이 2024–2025년을 거치며 어떻게 바뀌고 있는지를 정리한 3주차 학습 노트입니다.

---

이번 주차의 위치

2주차에서 AIOps를 observability 위의 의사결정 보조 계층으로 정의하였습니다. 그 의사결정 계층이 실제로 동작하려면, 먼저 무엇이 이상인지를 정확히 골라내는 단계가 확보되어야 합니다. 3주차는 이 Detection 단계를 집중적으로 다룹니다. 4주차의 Correlation, 5주차의 RCA가 의미 있게 동작하려면, 앞단 탐지의 품질이 전제되어야 하기 때문입니다.

flowchart LR
    A[Telemetry<br/>logs · metrics · traces] --> B[Detection]
    B --> C[Correlation]
    C --> D[RCA]
    D --> E[Recommendation]
    E --> F[Remediation]

    style B fill:#ffe4b5,stroke:#333,stroke-width:2px

    B -.이번 주차 범위.-> B

이번 주차는 크게 두 가지 이해를 목표로 합니다.

 

첫째, 전통적 anomaly detection이 고정 임계치 → 동적 baselining으로 진화해 온 이유와 그 한계를 이해합니다.

둘째, Chronos-2·TimesFM 2.5 같은 Forecasting Foundation Model이 왜 "탐지기"가 아니라 "탐지의 입력을 바꿔주는 도구"로 쓰이는지를 이해합니다.

---

1. 사전 지식 정리 — Detection을 이야기하기 전에 짚어야 할 것들

Observability Engineering(Majors, Fong-Jones, Miranda, O'Reilly)의 맥락을 빌려 몇 가지 전제를 짧게 정리합니다. 이 전제들을 짚지 않으면 뒤에서 다룰 baselining·anomaly detection의 한계가 왜 "구조적"인지 이해하기 어렵습니다.

1.1 메트릭은 사전 집계된 수치라는 점

메트릭은 특정 시간 윈도우 내의 관측을 하나의 수치로 집계한 결과입니다. SNMP 시절부터 이어져 내려온 가장 오래된 텔레메트리 형태이며, 저장·집계·시계열 조회에 유리한 대신 집계된 시점 이하의 해상도는 영원히 복원되지 않습니다. page_load_time의 5초 평균값에서, 그 5초 안의 어느 요청이 튀었는지는 알아낼 수 없습니다(Observability Engineering, Ch.2). Detection은 대부분 이 집계된 메트릭 위에서 이뤄지기 때문에, Detection 결과의 해상도는 메트릭의 해상도를 초과할 수 없습니다.

1.2 Cardinality와 Dimensionality

• Cardinality: 하나의 키가 가질 수 있는 고유 값의 수 (예: user_id, container_id).
• Dimensionality: 이벤트에 붙을 수 있는 키의 개수.

TSDB 기반 모니터링은 고 cardinality를 다루는 데 구조적으로 취약합니다. 탐지 대상이 "이 pod", "이 trace" 수준이 되면 메트릭만으로는 질문을 던질 수 없고, 결국 이상을 찾아도 어느 요청의 이상인지 역추적이 어렵습니다. 이 제약은 3주차 Detection의 한계뿐 아니라 4주차 Correlation·5주차 RCA에도 이어지는 전제입니다.

1.3 Alert fatigue와 normalization of deviance

모니터링 기반 알림은 특정 임계치 위반을 탐지합니다. 이 임계치는 과거에 겪은 실패 모드를 기준으로 설정되기 때문에, 본질적으로 알려진 실패(known-unknown)만 잡아냅니다. 분산 시스템에서 novel failure가 꾸준히 발생하면 알림은 계속 늘어나고, 팀은 "또 그거야"라며 알림을 무시하기 시작합니다. Challenger 사고 조사에서 유래한 normalization of deviance 개념이 그대로 소프트웨어 운영에 적용됩니다. Observability Engineering은 이 현상을 AIOps의 존재 이유 중 하나로 지적하면서, 동시에 "AIOps로 해결한다"는 접근 자체를 비판적으로 바라봅니다(Ch.12).

---

2. 전통적 AIOps의 기본기 (Hands-on AIOps 기반)

Sabharwal·Bhardwaj의 Hands-on AIOps(Apress, 2022)는 AIOps의 핵심 use case를 세 개의 단계로 제시합니다. Deduplication → Automated Baselining → Anomaly Detection. 각 단계가 하는 일과, 책에서 확인할 수 있는 실습 내용을 정리합니다.

flowchart TB
    subgraph Trad["전통적 AIOps의 성숙도 사다리"]
        direction LR
        D[Deduplication<br/>규칙 기반] --> B[Automated Baselining<br/>회귀/시계열]
        B --> A[Anomaly Detection<br/>비지도 학습]
    end

    D -.노이즈 감소.-> out1[알람 볼륨 ↓]
    B -.정상 범위 학습.-> out2[정적 임계치 탈피]
    A -.이상 패턴 포착.-> out3[Proactive 탐지]

2.1 Deduplication — 가장 기본이자 가장 자주 놓치는 단계

동일 CI(Configuration Item)에서 반복적으로 올라오는 같은 이벤트를 하나로 묶어, 이벤트 콘솔이 덮어쓰기식으로 쌓이지 않도록 하는 단계입니다. 머신러닝이 개입하지 않는 순수 rule-based correlation에 해당합니다.

 

책의 실습 내용

• Anaconda 기반 환경 구성, SQLite로 dedup/archive 테이블 분리
• 들어오는 이벤트가 dedup 테이블에 이미 존재하면 카운트만 증가시키고, archive 테이블로 원본을 이관
• 예제 데이터셋에서 약 70.6%의 중복 이벤트가 걸러지고 실제 이슈는 29.4%만 남는다는 결과를 파이차트로 확인 (Hands-on AIOps, Ch.6)
• 상위 10개의 "noisy host"를 집계해 capacity/problem management 팀에 전달할 수 있는 포맷 생성

2.2 Automated Baselining — 정적 임계치로는 더 이상 안 되는 이유

CPU·메모리·DB 응답 시간 같은 메트릭은 시간대·요일·월 단위로 일정한 패턴을 보이는 경우가 많습니다. "80% 이상이면 알람"과 같은 정적 임계치는 이 패턴을 무시하기 때문에 주말 저녁 정상 피크를 이상으로 오인하거나, 새벽의 비정상 스파이크를 정상으로 놓치는 문제를 만듭니다. Automated baselining은 회귀 또는 시계열 모델로 현재 시점의 정상 범위를 예측해 동적 임계치를 만드는 접근입니다.

 

책의 실습 내용

Hands-on AIOps Ch.7은 다음 순서로 진행됩니다 (Ch.7 요약).

1. Linear regression: 단순 선형 관계의 한계 확인
2. ARIMA: Box-Jenkins 방식의 AR(p), I(d), MA(q) 기반 모델링. ADF 검정으로 정상성 확인, ACF/PACF 플롯으로 차수 결정, pmdarima.auto_arima로 최적 p,q 탐색. CPU 데이터 기준 MAPE ≈ 24%
3. SARIMA: 계절성을 고려한 확장. seasonal_decompose로 주간 시즌성 확인 후 m=7로 설정, auto_arima가 SARIMA(3,0,2)(0,1,1)[7]을 선택. 책은 "MAPE ≈ 38%"를 개선으로 서술하지만, MAPE는 낮을수록 좋은 지표이므로 ARIMA 24% → SARIMA 38%는 수치상 악화로 읽힙니다. 원서 서술 자체의 불일치이므로 수치를 그대로 인용할 때 해석에 주의가 필요합니다
4. 예측 구간을 그대로 동적 임계치로 사용해 정적 전역 baseline을 대체

실무적 활용 포인트.

• APM·SecOps 데이터의 특수성: 보안 메트릭은 대부분 0 근처에 머물다 드물게 스파이크가 발생하는 불균형 분포입니다. 책은 이 경우에 평소값을 예측하는 대신 예측값 대비 스파이크의 이탈을 보는 접근이 타당하다고 짚고 있는데, 이것이 바로 다음 절에서 다룰 Foundation Model 기반 탐지의 기본 아이디어와 같습니다.
• SARIMAX 확장: 외생 변수(배포 이벤트, 프로모션 등)를 입력으로 받을 수 있는 SARIMAX는 전통적 exogenous forecasting의 대표 형태로, 현재 Chronos-2의 covariate-informed forecasting과 문제의식을 공유합니다(구조·학습 방식은 전혀 다르므로 "원형"이라기보다 선행 개념으로 이해하는 것이 정확합니다).

한계 — 책이 명시하는 Dynamic Thresholding의 채택 어려움.

Hands-on AIOps는 매우 솔직하게 동적 임계치 도입의 현실적 난관을 적고 있습니다 (Ch.7).

• 초기 학습 구간의 신뢰 문제: 모델이 충분한 데이터를 쌓기 전의 예측 정확도를 운영 팀이 신뢰하지 않음
• 오픈소스/네이티브 모니터링 도구의 미지원: Prometheus, Zabbix 등 대부분의 기본 도구에는 동적 임계치 기능이 내장되지 않음
• 충분한 데이터 기간 요구: 주간 시즌성 학습에만도 최소 몇 주 분량의 데이터가 필요

이 세 가지는 실제로 조직 내 AIOps PoC가 막히는 지점 그대로입니다.

2.3 Anomaly Detection — K-means부터 Topology Correlation까지

개념. 책은 anomaly detection을 "정상 이벤트와 유의미하게 다른 포인트를 찾아내는 과정"으로 정의하고, 라벨 없는 데이터에 대한 비지도 학습(주로 클러스터링)을 중심 기법으로 제시합니다.

책의 실습 내용.

• K-means 클러스터링: N개의 데이터 포인트를 K개 군집으로 분할. Elbow method로 K 결정
• 클러스터로부터 먼 포인트를 이상치로 플래깅
• CPU utilization 파라미터에 대한 적용 예제

책의 전체 correlation 체계.

Hands-on AIOps는 anomaly detection을 correlation 체계의 하위 구성으로 다룹니다 (Ch.2).

flowchart TB
    C[AIOps Correlation Engine] --> C1[Rule-based<br/>CMDB · maintenance window]
    C --> C2[Topology-based<br/>network · application]
    C --> C3[ML-based]
    C3 --> C3a[Anomaly Detection]
    C3 --> C3b[Clustering-based Correlation]
    C3 --> C3c[Association Rules]

    style C3a fill:#ffe4b5

Topology-based correlation은 4주차 주제의 전초이므로 여기서는 "탐지가 혼자 서 있지 않다"는 점만 짚고 넘어갑니다. 책의 예시 그대로 — 스위치 하나가 다운되면 그 뒤의 서버 수십 대에서 timeout 알람이 터지는데, topology 정보가 없다면 전통 anomaly detection은 수십 개의 독립적 이상을 보고할 뿐입니다.

 

실무적 한계 — Concept Drift.

전통 기법들의 가장 본질적 한계는 "정상이 무엇인가"가 시간에 따라 바뀐다는 점입니다. 이를 concept drift라고 부릅니다 (Park et al., 2025). Drift에는 세 가지 유형이 있습니다.

• Gradual drift: 서비스 사용량이 서서히 바뀜 (계절적 유저 성장)
• Abrupt drift: 배포, 피처 플래그, 트래픽 재라우팅으로 인한 급격한 기준선 변경
• Cyclic drift: 예측 가능한 주기적 변화

K-means나 ARIMA 기반 모델은 학습 시점의 분포를 정상으로 가정하기 때문에, drift가 일어나면 "정상이 된 새 패턴"을 계속 이상으로 보고하거나 반대로 모델을 재학습한 뒤에는 과거의 진짜 이상을 놓칠 수 있습니다. Concept drift와 anomaly를 구분하는 것 자체가 독립된 연구 주제로 다뤄지고 있습니다.

또 하나 짚어야 할 것은 Observability Engineering이 제기한 상황 의존적 정상 개념입니다 (Ch.8, AIOps 비판). 현대 환경에서는 새 배포, 기능 플래그 전환, 성능 최적화 자체가 "이상"으로 보일 수 있습니다. 모델이 "박스"를 너무 작게 그리면 정상 변화를 이상으로 오인하고, 너무 크게 그리면 실제 이상을 놓칩니다. 이 trade-off는 알고리즘 튜닝으로 완전히 해소되지 않는 구조적 한계입니다.

---

3. Forecasting Foundation Model의 등장 — 탐지 방식이 바뀌는 방식

2024–2025년을 거치며 시계열 foundation model이 실전 투입 가능한 수준까지 올라왔습니다. 이 모델들은 Chronos(Amazon), TimesFM(Google), Moirai(Salesforce), Toto(Datadog) 등 여러 계열로 갈라져 있습니다. 중요한 것은 이들이 이상 탐지기가 아니라 forecaster라는 점입니다. 탐지는 "예측 대비 이탈"이라는 간접 경로로 이뤄집니다.

flowchart LR
    M[Metric<br/>time series] --> FFM[Forecasting<br/>Foundation Model<br/>Chronos-2 · TimesFM 2.5]
    FFM --> Q[Quantile forecast<br/>P10 · P50 · P90]
    Q --> R[Residual<br/>actual - predicted]
    Q --> OOB[Out-of-band check<br/>actual &gt; P90 or &lt; P10]
    R --> A[Anomaly signal]
    OOB --> A

    COV[Covariates<br/>deploy events · topology] --> FFM

    style FFM fill:#b5d8ff
    style A fill:#ffe4b5

3.1 Chronos-2 — Univariate에서 Universal로

Chronos-2는 Amazon의 시계열 foundation model로, arXiv에는 2025-10-17에 제출되고 Amazon Science 블로그로는 2025-10-20에 공개되었습니다 (Ansari et al., 2025, arXiv:2510.15821). 120M 파라미터의 encoder-only 구조(T5 인코더 계열)로, univariate·multivariate·covariate-informed forecasting을 단일 모델에서 zero-shot으로 처리합니다. 공식 모델 카드 기준 최대 context 길이는 8,192, 최대 prediction 길이는 1,024입니다 (Hugging Face 모델 카드). Chronos-Bolt와의 head-to-head에서 90% 이상의 승률을 기록했다고 보고되어 있습니다 (amazon-science/chronos-forecasting).

핵심 아이디어는 group attention입니다. 관련된 여러 시계열(동일 서비스의 CPU·Memory·I/O 같은 공변 시계열이나, target과 covariate)을 하나의 group으로 묶어 in-context learning으로 공동 예측합니다. Amazon은 블로그에서 "클라우드 운영팀이 CPU·메모리·스토리지 I/O를 공동 예측해 리소스 병목을 미리 탐지"하는 시나리오를 직접 예시로 들고 있습니다 (Amazon Science, 2025).

AIOps 관점에서 중요한 것은 covariate입니다. Chronos-2는 과거만 알 수 있는 covariate(예: 지나간 트래픽)와 미래까지 알 수 있는 covariate(예: 스케줄된 배포, 알려진 프로모션, 날씨 예보)를 모두 받아들입니다. 범주형 covariate(예: 특정 휴일 유형)도 지원됩니다. 이것이 의미하는 바는, 배포 이벤트와 토폴로지 의존성 같은 외생 변수가 forecaster의 입력이 될 수 있다는 것입니다. 과거의 ARIMA·SARIMAX가 수작업 feature engineering을 통해 겨우 반영하던 외생 변수를, 사전학습된 모델이 zero-shot으로 받아들입니다.

3.2 TimesFM 2.5 — 더 작고 더 긴 컨텍스트

TimesFM 2.5는 Google Research의 decoder-only 시계열 foundation model로 2025-09에 공개되었습니다. 2.0 대비 파라미터는 500M → 200M으로 60% 축소되었고, 컨텍스트는 2K → 16K 포인트로 8배 확장되었습니다 (TimesFM 2.5 공식 문서; TimesFM 2.0 모델 카드). GIFT-Eval 제로샷 벤치마크에서 MASE·CRPS 양쪽 기준으로 1위를 기록한 바 있습니다.

AIOps 관점에서 특히 의미 있는 변화 두 가지를 짚어두시면 좋습니다.

• Optional quantile head: 확률적 예측을 네이티브로 지원. P10~P90 분위 예측이 별도 후처리 없이 나옵니다. 이것이 뒤에서 다룰 "예측 구간 이탈"을 임계 정의로 쓰는 방식의 출발점이 됩니다.
• 16K 컨텍스트: 시간당 데이터라면 약 1년치를 단일 forward pass에 넣을 수 있습니다. 연간 시즌성을 단일 호출로 포착할 수 있다는 의미이고, 이는 SARIMA 시절의 m=7, m=52, m=365 같은 수작업 seasonal period 설정을 상당 부분 생략할 수 있게 만듭니다.

Google Cloud의 BigQuery에는 이미 AI.FORECAST와 AI.DETECT_ANOMALIES 함수로 TimesFM이 통합되어 있어, 메트릭을 BQ로 적재만 하면 SQL 한 줄로 예측·탐지가 가능한 수준까지 상용화가 진행되었습니다 (Google Cloud Blog, 2025).

3.3 탐지의 "간접화" — 무엇이 바뀌는가

여기서 반드시 짚어야 할 것은, 이 모델들이 anomaly detection model이 아니라 forecasting model이라는 점입니다. 이상 판정은 다음과 같은 간접 경로로 이뤄집니다.

flowchart TD
    subgraph Path1["간접 탐지 경로 1: Residual"]
        P1a["실제값 y_t"] --> P1c["잔차: y_t 빼기 예측값"]
        P1b["예측값 y_hat_t"] --> P1c
        P1c --> P1d["잔차 분포에 임계 적용"]
    end

    subgraph Path2["간접 탐지 경로 2: Prediction Interval"]
        P2a["실제값 y_t"] --> P2c{"y_t가 Q_low 이상 Q_high 이하 범위 바깥인가"}
        P2b["예측 구간 P10-P90"] --> P2c
        P2c --> P2d["이탈 횟수/심각도 집계"]
    end

• 경로 1 (Residual-based): 점 예측 대비 잔차가 정상 범위를 벗어나면 이상. 정상 잔차의 분포(예: 3σ)를 별도로 학습해야 합니다.
• 경로 2 (Prediction interval-based): P10~P90 같은 분위 예측에서 실제값이 바깥으로 벗어난 비율·지속시간을 이상 지표로 사용. TimesFM 2.5의 quantile head와 맞닿는 접근입니다.

이 두 경로 모두 "정상이 무엇인가"를 모델이 직접 판정하지 않습니다. 모델은 "이 시계열의 미래 분포"를 예측할 뿐이고, 이상 판정 로직은 그 예측을 소비하는 측에 남습니다. 이 구조상 concept drift에 대한 상대적 내성이 기대됩니다(이 장점은 모델 카드나 논문이 직접 측정한 결과는 아니고, in-context 구조에서 논리적으로 유도되는 추론입니다). 모델이 최신 context를 받아 예측하기 때문에, 정상 기준이 점진적으로 움직여도 예측 자체가 따라 움직입니다. 다만 급격한 abrupt drift(예: 대규모 배포 직후)에는 여전히 일시적인 오탐이 늘어나므로, covariate로 배포 이벤트를 공급해 주는 설계가 필요합니다.

3.4 한계 — 여전히 남는 것들

Foundation model이 만능은 아니라는 점도 같이 기억해 둘 필요가 있습니다.

• Transfer learning의 본질적 한계: 시계열 패턴은 언어처럼 일반화가 잘 되지 않는다는 비판이 존재합니다. M-Competition 같은 전통 벤치마크에서는 여전히 LightGBM·ARIMA 앙상블이 foundation model을 상회한다는 보고가 있으며, 이는 GIFT-Eval/fev-bench 상의 제로샷 성능이 M-Competition 스타일 데이터로 바로 이전되지 않음을 시사합니다. 데이터셋별 승자가 달라진다는 지적은 TSB-AD·mTSBench에서도 반복적으로 나타납니다.
• TimeSeriesBench의 지적 (Si et al., 2024, arXiv:2402.10802): 실제 대규모 시스템에서는 수만 개의 시계열이 존재하는데, 시계열마다 별도 모델을 쓰는 것은 운영상 불가능하고, 단일 통합 모델의 성능은 별개 이슈로 검증되어야 합니다.
• CrossAD (NeurIPS 2025)의 관점 (Li et al., 2025, arXiv:2510.12489): 다중 스케일(분/시/일)에서 이상 패턴이 다르게 나타나는 현상, 고정 슬라이딩 윈도우의 한계를 다룬 최근 연구. foundation model도 single-scale 가정 위에 올려두면 이 한계를 그대로 상속합니다.

---

4. 실무 활용 관점의 통합 정리

4.1 언제 무엇을 쓸 것인가

flowchart TD
    Start[메트릭에 대한<br/>이상 탐지가 필요함] --> Q1{시즌성이<br/>강한가}
    Q1 -->|예| Q2{외생 변수<br/>배포 · 토폴로지<br/>를 쓰고 싶은가}
    Q1 -->|아니오| Q3{임계치만으로<br/>충분한가}

    Q2 -->|예| FM[Forecasting FM<br/>Chronos-2 covariate 모드]
    Q2 -->|아니오| SARIMA[SARIMA 또는<br/>TimesFM 2.5 단일 변수]

    Q3 -->|예| Static[정적 임계치<br/>+ maintenance window]
    Q3 -->|아니오| Cluster[K-means 기반<br/>비지도 클러스터링]

    style FM fill:#b5d8ff
    style SARIMA fill:#d4e9ff

핵심은 "Foundation model이 정답이다"가 아니라, 문제의 구조에 맞추는 것입니다. 안정된 시즌성이 분명하고 외생 변수가 없으면 SARIMA가 여전히 경제적이고 설명 가능합니다. 반면 배포 이벤트·프로모션·토폴로지 상태가 시계열에 크게 영향을 주는 환경이라면, covariate를 받아들일 수 있는 Chronos-2가 유의미한 이득을 줍니다.

4.2 임계를 어떻게 정할 것인가 — 토론 질문에 대한 정리

3주차의 두 번째 토론 질문이 바로 이것입니다. Forecasting 모델의 예측 구간 이탈을 이상으로 정의할 때, 임계를 어떻게 정해야 하는가.

실무에서 자주 쓰이는 접근을 정리합니다.

1. Quantile 기반 band 설정: 예를 들어 P5–P95를 정상 대역으로 두고, 그 바깥을 이상으로 정의. 모델의 불확실성이 바로 band 폭에 반영되기 때문에, 예측이 어려운 구간은 자연스럽게 관대해집니다.
2. Consecutive breach 요건: 단일 포인트 이탈은 false positive가 많기 때문에, N분 연속 이탈 또는 M개 중 K개 이탈 같은 조건을 결합합니다. Prometheus for: 절과 같은 개념입니다.
3. Severity-based 이중 임계: P10–P90 이탈은 warning, P1–P99 이탈은 critical 같은 2-tier 구조. Alert fatigue를 줄이는 방향입니다.
4. 동적 임계 재조정: NVIDIA의 Segmented Confidence Sequences 같은 기법은 regime shift를 감지하면 임계 자체를 재조정합니다 (Li & Gautam, 2025, arXiv:2508.06638).

4.3 첫 번째 토론 질문 — 어떤 서비스에서 먼저 시도할 것인가

동적 baselining을 가장 먼저 시도할 후보의 조건을 정리합니다.

• 메트릭에 명확한 시즌성이 있을 것 (평일/주말, 주간/야간 패턴)
• 정적 임계치로 인한 오탐이 실제로 기록되어 있을 것 (베이스라인의 개선 효과를 측정할 수 있어야 함)
• 배포 주기가 너무 짧지 않을 것 (초기 모델 학습 기간에 개념이 요동치면 검증이 어려움)
• SLO와 직접 연결된 메트릭이 아닐 것: 처음부터 SLI에 적용하면 오탐 한 번에 신뢰가 깨집니다. 내부 리소스 메트릭(CPU, memory)으로 시작하는 것이 안전합니다.

이 기준으로 보면 대시보드·검색 서비스의 QPS나 CPU 같은 "주기적이지만 SLO 지표는 아닌" 후보가 통상 첫 대상으로 타당합니다.

 

---

5. 참고 자료

도서

• Sabharwal & Bhardwaj, Hands-on AIOps, Apress, 2022. Springer Link
• Majors, Fong-Jones, Miranda, Observability Engineering, O'Reilly, 2022. O'Reilly

논문

• Ansari et al., "Chronos-2: From Univariate to Universal Forecasting," 2025. arXiv:2510.15821
• Das et al., "A decoder-only foundation model for time-series forecasting" (TimesFM 계열), ICML 2024. arXiv:2310.10688
• Li et al., "CrossAD: Time Series Anomaly Detection with Cross-scale Associations and Cross-window Modeling," NeurIPS 2025. arXiv:2510.12489
• Si et al., "TimeSeriesBench: An Industrial-Grade Benchmark for Time Series Anomaly Detection Models," 2024. arXiv:2402.10802
• Liu et al., "The Elephant in the Room: Towards A Reliable Time-Series Anomaly Detection Benchmark (TSB-AD)," NeurIPS 2024. OpenReview
• Park, Chiang, Milani, "Adaptive Anomaly Detection in the Presence of Concept Drift," 2025. arXiv:2506.15831
• Li & Gautam (NVIDIA), "Segmented Confidence Sequences and Multi-Scale Adaptive Confidence Segments for Anomaly Detection in Nonstationary Time Series," 2025. arXiv:2508.06638

오픈소스 · 도구

• amazon-science/chronos-forecasting — Chronos-2 공식 구현
• amazon/chronos-2 on Hugging Face — 체크포인트
• google/timesfm-2.5-200m-transformers — TimesFM 2.5 모델 카드
• decisionintelligence/CrossAD — CrossAD 공식 구현
• TheDatumOrg/TSB-AD — 시계열 이상 탐지 벤치마크
• AICoE/prometheus-anomaly-detector — Prometheus 기반 이상 탐지
• resmoio/kubernetes-event-exporter — Kubernetes 이벤트 exporter
• KEDA — Kubernetes Event-Driven Autoscaling

관련 블로그 · 문서

• Amazon Science, "Introducing Chronos-2: From univariate to universal forecasting," 2025. Link
• Google Cloud Blog, "TimesFM models in BigQuery and AlloyDB," 2025. Link
• MarkTechPost, "Google AI Ships TimesFM-2.5," 2025. Link