def cusum_alarm(values, mu0, sigma0, k=0.5, h=5.0):
    """표준화된 관측값에 대한 양방향 CUSUM.
    k = slack (표준 편차 단위), h = 알람 임계값.
...```

시간 경과에 따른 프롬프트별 메트릭을 입력하십시오. 이제 "느낌상 나빠졌다" 대신, "#14번 프롬프트의 json_success_rate가 화요일부터 하락했다"라는, 티켓(ticket)에 기재할 수 있는 날짜가 포함된 주장을 할 수 있게 됩니다. (`h=5.0`, `k=0.5`는 표준화된 데이터에 대한 합리적인 시작점이며, 자신의 이력에 따라 조정하십시오. 사후 확률(posterior probabilities)을 원한다면 베이지안 온라인 변화점 탐지(Bayesian Online Change-Point Detection)가 더 정교한 대안이 될 수 있습니다.)

이것만으로도 당신은 단순한 일화(anecdote) 수준에 머물러 있는, "모델이 나빠졌다"라고 주장하는 스레드의 약 95%보다 앞서 나가게 됩니다.

## 4단계 — 혼자만의 생각인지 절대 답할 수 없는 부분: "나만 그런 걸까?"

당신이 마주하게 될 한계는 다음과 같습니다. 완벽한 변화 지점(change-point) 신호가 있더라도, **공급자 측의 변경과 자체적인 드리프트(drift)를 구분할 수 없습니다.** 한 곳의 관점에서는 두 현상이 동일하게 보이기 때문입니다. CUSUM(누적합) 신호가 발생했을 때, 그것이 모델 때문인지, 지난주에 수행한 LlamaIndex 업데이트 때문인지, 아니면 불안정한 리전(region) 때문인지 알 수 없습니다.

이 둘을 분리할 수 있는 유일한 방법은 **독립적인 관찰자들 간의 상관관계(correlation)**입니다. 만약 당신의 카나리(canary)가 화요일에 작동했고, *동일한* 모델을 *동일한* 지표로 관찰하고 있는 *다른* 여러 조직들도 화요일쯤 신호를 보냈다면, 그 일치성이 바로 이것이 당신의 테스트 환경(harness)이 아닌 공급자 측의 문제라는 신호가 됩니다. 단일 관찰자는 영원히 N=1에 머물러 있으며, 이것이 바로 이러한 스레드들이 결론에 도달하지 못하는 이유입니다. 이것은 진정으로 다른 종류의 탐지 방식입니다. 즉, "내 앱을 모니터링한다"(모든 관측성(observability) 도구가 하는 일)가 아니라, "이 변화가 *모두에게* 일어났는가? 플릿(fleet) 전체에서 비공개적으로 확인되었는가?"를 묻는 것입니다.

이러한 교차 관찰자(cross-observer) 관점이 바로 [SEISMOGRAPH](https://github.com/Tania-coder/SEISMOGRAPH)가 구축된 핵심 원리입니다. 경량 프로브(probe)가 카나리 스위트(canary suite)를 실행하고, 변화 지점 탐지기(change-point detector)가 로컬에서 변화를 표시하며, 프롬프트나 출력값은 절대 공유하지 않고 오직 개인정보를 보호하는 분포 특징(distributional features)만을 공유합니다. 따라서 공개적인 "모델 날씨(model weather)" 경보가 울리는 경우는 오직 *여러 독립적인 관찰자들이 일치할 때*뿐입니다. 단일 조직의 신호는 비공개로 유지됩니다.

## 이것이 실제로 작동할까요? 실제 사례

이 방법은 가설에 그치지 않습니다. 2025년 9월 Anthropic 사고를 예로 들어보겠습니다. 일정 기간 동안 `claude-sonnet-4`의 성능이 저하되었는데, 이는 모델 업데이트가 아니라 인프라 버그 — 특히 컨텍스트 윈도우(context-window) 라우팅 오류 — 때문이었습니다 (Anthropic은 [사후 분석 보고서(postmortem)](https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues)에서 이를 명시적으로 밝혔습니다). 이는 이 글 전체가 다루고 있는 "모델 문제인가, 인프라 문제인가?"라는 안개와 정확히 일치하는 사례입니다.

위에서 설명한 CUSUM 방법을 사용하여 해당 기간 동안 카나리 스위트 (canary suite)를 다시 실행해 본 결과: **시드(seeded)를 설정한 백테스트 (backtest)는 사후 분석 (postmortem)이 이루어지기 38일 전에 이를 감지했습니다.** 실시간 포착은 아니었지만 — 시드가 설정된 공개적이고 재현 가능한 백테스트였지만 — 이는 공식적인 인정이 있기 훨씬 전부터 저렴한 분포 지표 (distributional metrics) 안에 신호가 머물고 있었음을 보여줍니다.

## 직접 해보기

-   **Probe (오픈 소스, Apache-2.0):** `pip install seismograph-probe`
-   **실시간 "모델 날씨" 대시보드:** [https://driftdefense.dev?utm_source=devto&utm_medium=article&utm_campaign=evergreen_howto](https://driftdefense.dev?utm_source=devto&utm_medium=article&utm_campaign=evergreen_howto)
-   **코드 + 방법론:** [https://github.com/Tania-coder/SEISMOGRAPH](https://github.com/Tania-coder/SEISMOGRAPH)

시작하는 데 이 모든 것이 필요한 것은 아닙니다. 위의 네 단계는 크론 잡 (cron job), CSV, 그리고 10줄의 CUSUM만으로도 작동합니다. 하지만 "단순히 나만의 문제인가?"라는 질문에 대한 답을 얻고 싶다면, 한 명 이상의 관찰자가 필요하며, 바로 그 부분이 연합 (federating)할 가치가 있는 부분입니다.

## FAQ

**GPT / Claude / Gemini가 최근에 실제로 성능이 저하되었나요?**  
때로는 그렇기도 하고, 때로는 사용자의 설정 문제일 수도 있으며, 많은 경우 "더 나쁜 모델"이 아니라 제공업체 측의 인프라 (infra) 변경 때문입니다. 이 글의 핵심은 느낌 (vibes)에 따라 답하지 말고, 계측 (instrument)을 통해 날짜가 명시된 신호를 얻어야 한다는 것입니다.

**호스팅된 모델이 변경되었다는 것을 어떻게 증명할 수 있나요?**  
단일 계정만으로는 이를 "증명"할 수 없지만, 강력한 객관적 증거를 확보할 수는 있습니다. 고정된 카나리 스위트 (canary suite) + 베이스라인 (baseline) + 변화점 테스트 (change-point test)를 결합하면 날짜가 기록된 변화를 얻을 수 있습니다. 제공업체 측 드리프트 (provider-side drift)와 로컬 드리프트 (local drift)는 여러 독립적인 관찰자들 사이의 일치 여부를 통해서만 분리할 수 있습니다.

**이것은 단순히 LLM 관측성 (observability) / 평가 (evals) 아닌가요?**  
관련은 있지만 다릅니다. 평가 (Evals)는 특정 시점의 품질을 점수화하고, 관측성 (observability)은 "사용자의" 트래픽을 모니터링합니다. 이것은 당신이 제어할 수 없는 호스팅된 종속성 (dependency)에서 발생하는 "시간에 따른 변화"를 감지하는 것에 관한 것이며, 독특하게도 "단순히 나만의 문제"를 배제하기 위해 조직 간에 해당 변화를 상관 분석 (correlating)하는 것에 관한 것입니다.

**어떤 지표를 추적해야 할까요?**
품질 변화에 따라 함께 움직이는 가장 저렴한 지표부터 시작하세요: 스키마/JSON 유효성 (schema/JSON validity), 출력 길이 (output length), 그리고 카나리 (canary)당 단일 고정 통과/실패 (pass/fail) 여부입니다. 더 높은 해상도 (resolution)를 원한다면 나중에 루브릭 점수 (rubric score)를 추가하세요.