Anomaly detection을 QC fail보다 먼저 쓰는 전략

– “판정”이 아니라 “조기 징후 탐지”로 위치를 바꿔라

1️⃣ QC fail은 ‘사후 판정’, anomaly detection은 ‘사전 신호’다

먼저 개념부터 분리해야 합니다.

QC fail의 본질

• 명확한 acceptance criteria
• binary decision (pass / fail)
• 규제 문서에 직접 들어감
• 되돌릴 수 없는 판정

Anomaly detection의 본질

• 정상 패턴 대비 상대적 이탈
• 연속적인 위험 신호
• 판단 보조용 정보
• 되돌릴 수 있는 경고

👉 이 둘을 같은 레벨에 두는 순간,
anomaly detection은 규제적으로 즉시 탈락합니다.

2️⃣ 실패하는 팀의 공통 착각: “AI가 QC를 더 잘할 것”

PoC에서 자주 나오는 문장:

“기존 QC rule보다 anomaly detection이 더 민감합니다”

이 말이 운영 단계에서는 치명적인 이유:

• QC는 명시적 기준
• anomaly는 통계적 상대성

QA 입장에서는 이렇게 들립니다.

“기준 없는 fail을 하나 더 만들자는 건가요?”

그래서 살아남는 전략은 단 하나입니다.

👉 Anomaly detection은 QC fail을 대체하지 않는다
👉 QC fail 이전에 위험 신호를 정리해 주는 역할이다

3️⃣ 이상적인 위치: “QC pre-screening layer”

운영 구조로 보면 이렇게 배치해야 합니다.

 

Raw LC-MS data

↓

Basic system suitability check

↓

Anomaly detection (pre-QC layer)

↓

Human review / root cause hypothesis

↓

Formal QC rule evaluation

↓

Pass / Fail

 

여기서 anomaly detection의 역할은 딱 하나입니다.

“이번 batch는 평소와 다르니
QC 결과를 더 조심해서 보세요”

 

4️⃣ Anomaly detection이 먼저 작동해야 하는 이유 (현실적)

① QC는 이미 늦은 신호다

QC fail이 발생했다는 건:

• 이미 데이터는 만들어졌고
• 재분석, 재주입, CAPA가 시작됨

Anomaly detection은:

• run 초반
• sequence 중간
• trend 단계

에서 문제가 커지기 전에 신호를 준다.

② QC는 point, anomaly는 trajectory를 본다

QC:

• 특정 metric이 기준 초과했는가?

Anomaly detection:

• 최근 N batch 대비 이동 방향이 이상한가?
• drift가 누적되고 있는가?

👉 fail은 없지만, 망해가는 중인 상황을 잡는 건
QC가 아니라 anomaly detection이다.

③ QC fail은 설명이 필요 없고, anomaly는 설명이 필요하다

이게 중요하다.

• QC fail: “기준 초과 → fail”
• anomaly: “왜 이상한가?”

그래서 anomaly detection은 반드시:

• feature-level explanation
• deviation 방향성
• historical 비교

를 포함해야 한다.

👉 그렇지 않으면 쓸모없는 알람이 된다.

5️⃣ 잘 설계된 anomaly detection의 output 형태

운영 가능한 시스템은 절대 이렇게 말하지 않는다.

❌ “Anomaly score = 0.91”

대신 이렇게 말해야 한다.

✅

• Golden batch 대비 RT drift ↑
• IS response variability ↑
• 최근 5 batch 중 4개에서 동일 패턴 반복

이 문장은:

• QA에게 설명 가능하고
• analyst에게 action을 주고
• QC 판단을 왜곡하지 않는다

6️⃣ QC fail 이전에 쓰는 대표적인 성공 시나리오

시나리오 A: batch fail 방지

• anomaly detection이 RT drift trend 감지
• analyst가 column 상태 확인
• column 교체 후 재주입
• QC fail 자체가 발생하지 않음

👉 보고서에는 anomaly detection 기록이 남지 않아도 된다
(중요한 포인트)

시나리오 B: QC fail 해석 보조

• QC fail 발생
• anomaly detection 결과 확인
• “이건 sudden error가 아니라 누적 drift”

👉 CAPA 방향이 완전히 달라진다.

시나리오 C: QC pass지만 release 보류

• QC는 통과
• anomaly signal은 high
• analyst 판단으로 추가 확인

👉 QC rule을 깨지 않고 품질을 올리는 방식

7️⃣ SOP에서 anomaly detection을 다루는 올바른 문장

실제 SOP에 들어갈 수 있는 문장은 이 정도가 한계다.

• “Anomaly detection 결과는 QC 판정에 영향을 주지 않는다”
• “Anomaly signal이 높을 경우 추가 검토를 수행할 수 있다”
• “최종 판정은 기존 QC 기준에 따른다”

👉 이 문장 구조를 지키지 않으면
audit에서 바로 걸린다.

8️⃣ 핵심 요약

• Anomaly detection은 fail을 만드는 도구가 아니다
• QC보다 앞에 두되, QC를 침범하지 말아야 한다
• 역할은 단 하나:
• “QC가 fail을 내기 전에
  사람이 눈을 뜨게 만드는 것”

마지막 한 문장

Anomaly detection이 QC fail보다 먼저 와야 하는 이유는
더 엄격해지기 위해서가 아니라,
덜 실패하기 위해서다.

Anomaly detection을 QC fail보다 먼저 쓰는 전략