반도체 제조 데이터로 푸는 다섯 가지 문제를, 데이터 생성부터 검증까지 전부 재현 가능하게 만든 저장소.
아래 명령이 만들어낸 결과를 그대로 웹에서 볼 수 있다. 프레임워크도 CDN 도 쓰지 않은 정적 페이지다.
pip install -r requirements.txt
python build_all.py이 한 줄이면 5개 데이터셋(약 28만 행)을 만들고, 각 데이터가 설계한 성질을 실제로 갖고 있는지 검증하고, 분석 파이프라인을 돌려 리포트까지 뽑는다. 검증에 실패하면 거기서 멈춘다.
반도체 공정 데이터로 뭔가를 해보려 하면 항상 같은 벽에 부딪힌다. 데이터가 없다. 공개 데이터는 구조가 지나치게 단순해서, 실제 팹 데이터가 갖는 어려움이 전부 빠져 있다.
그 "어려움" 이 사실 문제의 본질이다.
- 계측은 전수로 하지 않는다. 그리고 무작위로 고르지도 않는다. 위험해 보이는 것만 골라 잰다.
- 공정 파라미터는 단조가 아니다. 최적 구간이 있고 양쪽으로 벗어나면 나빠진다.
- Lot 건강도가 나쁘면 계측값도 불량률도 같이 나빠진다. 상관계수만 보면 전부 원인처럼 보인다.
- 열화는 스펙을 넘지 않는다. 스펙 위반 알람으로는 하나도 안 잡힌다.
- 가장 강하게 상관된 변수가 사람이 돌릴 수 있는 손잡이가 아닌 경우가 많다.
그래서 이 성질들을 의도적으로 심어 넣은 합성 데이터를 만들고, 그걸 실제로 푸는 코드를 붙였다. 정답을 알고 있으니 검출 성능을 precision/recall 로 정직하게 잴 수 있다는 게 핵심이다.
| 프로젝트 | 문제 | 데이터 | 핵심 결과 | |
|---|---|---|---|---|
| 1 | YieldLens | 24단 공정에서 수율을 떨어뜨리는 진짜 원인 인자 찾기 | 12,000 웨이퍼 × 84열 | 교란 제거 후 precision 1.00 / recall 1.00, 오탐 0 |
| 2 | EtchPilot | Etch 레시피 품질 사전 예측과 파라미터 조정 추천 | 4공정 24,360 사이트 | 미학습 레시피 CD 예측 기준선 대비 −38.7% |
| 3 | DiceGuard | 스펙 안에서 진행되는 장비 열화 조기 감지 | 60,000 스트립 × 120일 | 주입 열화 재현율 100% / 정밀도 100%, 판정 구간 하한 21일 규명 |
| 4 | CellHealth | 대용량 스토리지 헬스 데이터 자연어 질의 + 마모 예측 | 200,000행 (10만 대 × 2회차) | 질의 7/7 해석, 위험 선별 lift 23.4배 |
| 5 | RelyLab | 신뢰성 불합격이 설계 마진 탓인가 특정 설비 탓인가 | 1,200 웨이퍼 + 9,600 시험 | 설비 정보 추가로 AUC +0.104, 문제 설비 recall 1.00 |
각 프로젝트 폴더에 generate.py(데이터 + 자체 검증), analyze.py(분석), README.md,
data/, outputs/(리포트)가 들어 있다.
semicon-ai-lab/
├─ build_all.py 전 프로젝트 생성 + 검증 + 분석
├─ common/
│ ├─ synth.py U자 응답 / MNAR 마스킹 / Lot 바이어스 / 사이트 배치
│ └─ validate.py 데이터 불변식 검증기
├─ projects/
│ ├─ yieldlens/ 다단 공정 수율 · 원인 인자
│ ├─ etchpilot/ Etch 레시피 평가
│ ├─ diceguard/ 레이저 다이싱 열화 감지
│ ├─ cellhealth/ 스토리지 필드 헬스
│ └─ relylab/ FinFET 신뢰성 · 설비 귀인
├─ site/ 결과 대시보드 (GitHub Pages)
└─ docs/DATA_LINEAGE.md 데이터 출처와 합성 방침
데이터 생성기는 스스로를 검증한다.
합성 데이터는 조용히 망가진다. 행 수는 맞는데 상관이 사라졌다거나, 계측 편향이 반대로
걸렸다거나 하는 식이다. 그래서 generate.py 는 저장 직전에 common/validate.py 로
자기 데이터를 검사하고, 하나라도 어긋나면 파일을 쓰지 않고 죽는다.
"너무 깨끗한" 데이터는 실패로 처리한다. 검증기에는 상관계수 하한뿐 아니라 상한이 있다. 유효 인자의 Spearman rho 가 0.72 를 넘으면 검증이 실패한다. rho 0.9 짜리 데이터로 낸 모델 성능은 아무 의미가 없기 때문이다. 실제로 개발 중에 이 상한에 여러 번 걸렸고, 그때마다 잡음 파라미터를 다시 잡았다.
평가는 누설 없이 한다. Lot 단위 GroupKFold, 레시피 단위 LeaveOneGroupOut 을 쓴다. 같은 Lot 이나 같은 레시피가 train/test 양쪽에 섞이면 성능이 뻥튀기된다. 설비 귀인 검정은 Lot 평균으로 집계한 뒤 돌린다 — 설비가 Lot 단위로 배정되므로 웨이퍼를 독립 표본으로 보면 유의성이 과대평가된다.
안 되는 것은 안 된다고 적는다. EtchPilot 의 pad 공정은 Bottom CD 와 Depth 모두 기준선보다 나쁘다. 예측 실패다. CellHealth 에서는 무릎이 있는데도 트리 모델이 로지스틱을 못 이겼다 (PR-AUC 0.393 vs 0.416). RelyLab 의 설비 귀인은 p<0.05 만으로 자르면 오탐이 절반이다. 셋 다 리포트와 README 에 수치 그대로 적혀 있다.
전부 이 저장소의 코드가 만든 합성 데이터다. 실제 기업 데이터나 타인의 데이터셋을 포함하지 않는다. 도메인 구조(계측 사이트 배치, 신뢰성 시험 항목, FDC 변수 구성 등)는 공개된 기술 문헌과 일반적인 반도체 공정 지식을 참고했다.
자세한 방침은 docs/DATA_LINEAGE.md.
Python 3.10+ / pandas · numpy · scipy · scikit-learn. 그 외 의존성 없다. LightGBM·XGBoost 를 쓰지 않은 이유는 설치 없이 바로 돌아가야 하기 때문이다.
MIT