공정데이터를 활용한 실전 이상탐지 및 품질 이상 조기 예측_3회차
1. AWS RCF
① RCF개념
| 데이터를 랜덤하게 잘라 나누는 과정(Random Cut)에서 '이상치는 정상보다 더 빨리 분리된다' 는 아이디어로 작동한다. |
- 정상 데이터
- 서로 밀집
- 분리하려면 여러 번 잘라야 함 → 깊은 트리 → 정상
- 이상 데이터
- 멀리 떨어져 있음
- 금방 고립됨 → 얕은 트리 → 이상
트리 깊이가 얕을수록 = 고립 쉬움 = Anomaly Score ↑
② RCF를 이용한 패턴 분석

✔ Shingling (데이터 묶음화)
- 점 하나씩 보지 않고
- → [xₜ , xₜ₊₁ , xₜ₊₂ …] 형태로 연속 구간 단위로 묶음
- 효과
- “값”뿐 아니라 Shape(모양, 흐름) 을 학습
- 상승/하강 패턴 깨짐을 감지 가능
- OpenSearch 설정: shingle_size
③ RCF Forest의 업데이트 및 탐지 설정 개념
- 대표 샘플들을 기준으로 숲(Forest) 업데이트
- 숲이 “정상 패턴”을 학습
- 처음 보는 이상 모양 등장 시 → 이상 탐지
| 설정 | 의미 |
| Interval | 데이터가 찍히는 시간 단위 |
| Frequency | 모델 실행 주기 |
| Window Delay | 최신 데이터 안정화 대기 |
| History | 학습 시작 최소 데이터 수 |
④ 동작 흐름
1) 데이터 스트림 입력
2) Shingling(패턴 단위 변환)
3) Reservoir Sampling(대표 샘플 유지)
4) Forest 업데이트
5) 각 트리에서 고립 난이도 계산
6) 평균점수 → 이상 점수
RCF 예시 코드)
import numpy as np
import rrcf
# 1. 데이터 생성 (정상 + 이상 일부)
np.random.seed(42)
normal1 = np.random.normal(0, 1, 500)
anomaly = np.random.normal(8, 0.5, 20)
normal2 = np.random.normal(0, 1, 500) # 뒤에 붙일 정상 구간을 새로 만듦(원하면 동일 normal 재사용해도 됨)
series = np.concatenate([normal1, anomaly, normal2])
# 2. Forest 생성
num_trees = 40
tree_size = 256
forest = [rrcf.RCTree() for _ in range(num_trees)]
anomaly_scores = np.zeros(len(series))
# 3. 스트리밍처럼 한 점씩 넣으며 점수 계산
for t, value in enumerate(series):
point = np.array([value])
for tree in forest:
# 오래된 데이터 제거 (슬라이딩 윈도우 효과)
old_index = t - tree_size
if old_index >= 0 and old_index in tree.leaves:
tree.forget_point(old_index)
# 새 데이터 삽입
tree.insert_point(point, index=t)
# codisp = RCF anomaly score
anomaly_scores[t] += tree.codisp(t)
anomaly_scores[t] /= num_trees
# 4. 이상구간 확인
print("평균 점수:", anomaly_scores.mean())
print("상위 1% 이상치 인덱스:",
np.where(anomaly_scores > np.quantile(anomaly_scores, 0.99))[0])
평균 점수: 6.089536351399952 상위 1% 이상치 인덱스: [179 209 262 478 500 501 502 503 646 933 977]
이 코드가 보여주는 핵심
- 스트리밍 학습 가능
- 오래된 데이터 자연 제거
- 이상 점수 자동 계산
- 값이 크면 = 이상 가능성 높음
2. 통합 이상탐지 시스템 구축 전략 (Manufacturing Anomaly Detection Blueprint)
2-1. 계층적 방어선(Hierarchical Defense Line) 구축
단 하나의 알고리즘으로 모든 이상을 잡으려 하면 실패합니다.
공정 특성 + 운영 목적에 맞춰 여러 겹의 필터를 설계해야 합니다.
| 방어선 | 담당 역할 | 주요 알고리즘 | 의도 |
| 제1 방어선 (즉각 대응) | 하드웨어 고장, 통신 오류, 급격한 이상 | • Point Anomaly • Derivative(기울기) | “지금 당장 멈춰야 할 문제”를 잡기 위함 |
| 제2 방어선 (공정 관리) | 추세 변화, 품질 흔들림 관리 | • SPC Zone Rules • CUSUM • Moving Avg | 품질 유지 & 관리 기준을 지키기 위함 |
| 제3 방어선 (사전 예지) | 성능 저하, 장비 노후화, 패턴 이상 | • Isolation Forest • LSTM-AE • Feature Grouping, AWS RCF | “망가지기 전” 조기 감지 목적 |
- 실시간 대응용 알고리즘
- 품질 관리용 알고리즘
- 예지보전용 알고리즘
- 목적이 다르므로 설계도 달라야 한다.
2-2. 실전 파이프라인
공정 데이터를 받아, 실제 알람까지 이어지는 4단계 구조
1단계: 도메인 기반 변수 그룹화 (Variable Grouping)
방법
- ‘물리 장치 단위’로 묶기
- 예: 모터부 / 가열부 / 냉각부 / 압력계통 / 로봇 핸들부 …
효과
- 원인 파악 속도 극적으로 단축
- “어디가 문제인지” 명확히 전달
- 유지보수팀 의사결정 속도 ↑
2단계: 데이터 성격에 따른 알고리즘 배치
| 데이터 성격 | 추천 기법 | 이유 |
| 안정적인 수치형 | SPC Rule + Elliptic Envelope | 공정 기준 관리에 최적 |
| 변동성이 큰 데이터 | Isolation Forest + CUSUM | 분포 기반 & 추세 기반 동시 반영 |
| 주기/패턴 존재 | Ruptures / Change Point Detection | 패턴 붕괴 시점 포착 |
포인트
- 모든 곳에 딥러닝 쓸 필요 없음 (실제로는 LSTM AUTOencoder를 정말 많이씁니다..)
- 제조는 “해석 가능한 모델 + 운영 가능성”이 중요
3단계: 앙상블 점수 산출 (Anomaly Scoring)
방식1 – Soft Voting
- 각 모델의 이상 확률 평균
- 안정적이고 오탐 감소
방식2 – Logic Gate
- 예)
- “기울기 급상승 AND 분포 중심 이탈”일 때만 알람
- 실제 현장 적용 시 신뢰도 매우 높음
4단계: 동적 임계치 (Dynamic Threshold)
고정된 임계치는 공정 변화에 약합니다.
추천 방식
- Gaussian Tail Probability
- 최근 30일 기준 Rolling Threshold
- BOCPD 기반 환경 적응형 Threshold
2-3. Early Warning (사전 예지)

“망가지고 나서 알람”이 아니라
“망가지기 직전 신호를 잡는 것”이 목표
핵심 기법
1) 잔차(Residual) 추적
- 정상 모델 예측값 vs 실제값 차이 증가 추적
- AE / Forecasting / Regression 기반 가능
2) 기울기(Derivative) 모니터링
- 값은 정상 범위
- BUT 증가 속도/감소 속도가 평소 1.5배라면 위험
3) 분산(Variance) 변화 감지
- 고장 직전 진동 or 전류 떨림 증가
- Variance Rule 매우 효과적
Early Warning 적용 시 효과
- 다운타임 감소
- 예방 유지보수 가능
- 계획정비 전환 가능
- 불량률 감소 → COPQ 절감
2-4. 운영 시 Best Practice
1) 알람 피로도 관리 (Alarm Fatigue)
“알람이 너무 많으면, 사람은 결국 안 본다”
추천
- SPC Rule 2, 4, 5 위주 설계
- 단순 순간 이상보다
- 지속성 + 패턴 중심 설계
2) 지속적 모델 재학습
- 계절 변화
- 설비 노후
- 금형 마모
- 작업자 습관 변화
➡ 정상의 기준이 변한다
권장
- BOCPD 기반 환경 적응
- Rolling Window 재학습
- 분기별 Calibration
3) 전문가 피드백 반영
“AI가 이상이라는데, 현장은 정상이라 한다면?”
그 데이터 반드시 재학습에 반영해야 함
→ False Positive 지속 감소
현장 친화적 시스템 조건
- 이유가 설명 가능
- 알람이 과하지 않음
- 책임 소재가 명확
- “도움되는 시스템”이라고 현장이 느끼게 해야 함
최종 로드맵
1️⃣ 센서 → 물리적 의미 기준으로 그룹화
2️⃣ 기본 방어선: 기울기 + SPC Rule 먼저 적용
3️⃣ 고도화가 필요한 구간에만
Isolation Forest / ChangeFinder / Ruptures 추가
4️⃣ 모든 알람은 반드시
“어느 영역, 왜 발생했는지” 함께 전달