Rework loop를 넣었더니 first-pass yield가 올라간 이유

라인은 그대로인데 수율만 좋아졌다

Rework 기능을 MES에 넣은 다음 주, first-pass yield가 93%에서 98%로 올라갔다. 설비도 그대로, 작업자도 그대로, 불량도 그대로였다. 올라간 건 수율이 아니라 fail 이력이 사라진 속도였다. Rework로 보낸 제품이 다시 pass하면서 첫 번째 fail record를 덮어쓰고 있었다.

이게 rework 설계에서 가장 흔한 사고다. MES route를 처음 그리면 보통 직선이다. Step 10에서 시작하고, step 20을 완료하고, step 30에서 검사하고, step 40으로 출하한다. 그 직선 위에 loop 하나를 얹는 순간 route는 상태 기계가 되고, 상태 기계는 이력을 저장하지 않는다.

Rework를 comment field나 수기 Excel 보정으로 처리하면 MES는 결국 이 중 하나를 잃는다.

제품이 지금 물리적으로 어디에 있는가.
다음에 어떤 route step을 수행할 수 있는가.
같은 공정을 몇 번째 방문했는가.
어떤 defect나 disposition 때문에 rework로 갔는가.
이전 process data를 유효하게 볼 것인가.
WIP와 yield report에서 이 제품을 어떻게 셀 것인가.

Rework 처리는 품질 기능만이 아니다. Dispatching, 설비 interlock, label, historian context, 생산 report에 모두 영향을 준다.

현재 위치와 route 이력을 분리한다

제품이 loop를 돌았다고 원래 route history를 덮어쓰면 안 된다. MES는 현재 상태와 지나온 경로를 둘 다 가져야 한다.

최소한 아래 record는 분리하는 편이 좋다.

Record	용도	예
Current WIP state	지금 위치와 허용 action 표시	Unit A가 Assembly Step 20에서 대기 중
Route visit history	각 step 방문 이력 보존	Step 20 1회차, Step 30 fail, Step 20 2회차
Disposition record	왜 경로가 바뀌었는지 설명	Torque test fail로 rework
Quality status	다음 진행 가능 여부 제어	Hold, rework, scrap, release
Genealogy link	자재와 설비 context 유지	두 번의 방문에 사용된 component lot

Current state는 작업자 화면을 움직인다. History는 품질 분석과 yield 분석에 필요하다. 둘을 하나의 수정 가능한 field로 섞으면 나중에 report가 꼬인다.

설비 쪽 표준도 같은 한계를 가진다. SEMI E90(Substrate Tracking)의 SubstrateProcessingState는 NeedsProcessing, InProcess, Processed, Aborted, Stopped, Rejected, Lost, Skipped를 오가는 state machine이다. 재처리하면 상태는 다시 NeedsProcessing으로 돌아가고, 그 전에 Rejected였다는 사실은 state 값 어디에도 남지 않는다. E90은 방문 횟수를 세는 표준이 아니다. 세는 건 MES 몫이다.

같은 step 재방문에는 sequence가 필요하다

제품이 같은 공정으로 돌아오면 두 번째 pass가 첫 번째 pass data를 덮어쓰면 안 된다. Visit number, pass number, route step instance 같은 식별자가 필요하다.

예를 들면 이렇게 남긴다.

Unit	Route step	Visit	결과	설비	시간
SN10045	Press Fit	1	이후 leak test에서 fail	PRS-02	08:14
SN10045	Leak Test	1	Fail	LKT-01	08:22
SN10045	Press Fit	2	Complete	PRS-03	09:05
SN10045	Leak Test	2	Pass	LKT-01	09:18

여기서 PRS-02와 PRS-03이 다르다는 점이 중요하다. 두 번째 pass를 다른 설비에서 돌렸는데 visit 개념이 없으면, 나중에 "PRS-02에서 나온 제품이 leak fail이 많다"는 분석 자체가 성립하지 않는다.

허용된 rework 경로를 정의한다

Rework는 free-text 판단으로 움직이면 안 된다. Route rule로 허용된 path를 만들어야 한다.

현장에서 많이 쓰는 disposition은 이런 형태다.

직전 step으로 돌려 보내 조정한다.
전용 rework station으로 보낸다.
검사 reset 후 같은 test를 다시 수행한다.
Engineering hold로 이동한다.
Scrap 처리하고 더 이상 진행하지 않는다.

각 path에는 누가 선택할 수 있는지, 어떤 reason code가 가능한지, release 전에 어떤 data가 필요한지 정해야 한다. 예를 들어 torque audit fail은 supervisor approval과 새 torque result가 있어야 final test로 돌아갈 수 있다.

모든 작업자가 제품을 아무 이전 step으로나 보낼 수 있으면 MES는 통제 시스템이 아니라 우회 도구가 된다. 반대로 disposition을 두세 개로 너무 좁히면 현장은 scrap을 찍고 제품을 몰래 살려낸다. 실제로 쓰이는 경로를 먼저 관찰하고 나서 rule로 굳히는 순서가 낫다.

WIP와 yield는 의도적으로 센다

Rework loop가 있으면 현장은 정상인데 report만 이상해 보일 수 있다.

자주 나오는 report 문제는 다음과 같다.

Route visit마다 새 unit start로 계산한다.
Rework 제품을 station throughput에 두 번 세면서 설명이 없다.
First-pass fail과 final-pass fail을 같은 지표로 섞는다.
제품이 pass되면 fail 이력을 숨긴다.
같은 unit이 rework step과 원래 fail step WIP에 동시에 보인다.

Metric 정의를 분명히 한다.

Metric	권장 정의
First-pass yield	지정 inspection에서 rework 없이 한 번에 pass한 unit 비율
Rolled throughput yield	Rework나 scrap 없이 전체 step을 통과할 확률
Final yield	모든 disposition 후 최종 완료 또는 출하된 good unit 비율
Station workload	Rework visit을 포함해 station이 처리한 visit 수
Physical WIP	현재 특정 location에서 대기 또는 처리 중인 실제 unit 수

설비 가동률 지표만 보고 있으면 rework는 아예 보이지 않는다. SEMI E10은 rework를 Productive time 아래에 둔다 — 정규 생산, engineering run과 같은 칸이다. 표준 관점에서는 맞는 분류다. 설비는 실제로 일하고 있으니까. 다만 그래서 rework가 두 배로 늘어도 E10 utilization은 꿈쩍하지 않는다. Rework를 보는 지표는 수율 쪽에 있어야 한다.

Station supervisor는 visit workload를 보고 싶어 한다. 품질 엔지니어는 first-pass yield를 본다. Finance는 최종 good unit을 본다. 정의 없이 하나의 report로 모두 만족시키기는 어렵다.

설비 event를 올바른 route instance에 붙인다

SCADA, PLC, test equipment가 MES로 event를 보낼 때는 어느 visit에 붙일지 판단할 수 있는 context가 필요하다.

좋은 event context는 아래 값을 포함한다.

Unit ID 또는 carrier ID.
Operation 또는 route step ID.
가능하면 route step instance 또는 visit number.
Equipment ID.
Start, complete timestamp.
Recipe 또는 program revision.
Test result와 defect code.
Operator 또는 automated station identity.

SECS/GEM 설비라면 이 context는 S6F11 report body에 들어갈 SVID 목록을 정하는 문제로 바뀐다. Report 내용은 S2F33로 define하는 시점에 고정되므로, 나중에 "visit number도 넣어주세요"는 설비 vendor의 소프트웨어 변경 요청이 된다. 그 싸움은 대부분 진다. Vendor가 관리하지 않는 개념을 SVID로 만들어 달라는 요구이기 때문이다.

이길 수 있는 쪽은 host다. 같은 unit에 대해 열려 있는 route step instance를 항상 하나로 유지하고, 들어온 S6F11을 timestamp가 아니라 그 열린 instance에 귀속시킨다. Move transaction이 instance를 열고 닫는 유일한 주체가 되면 설비는 visit 개념을 몰라도 된다. 이 규칙이 깨지는 유일한 경우는 MES가 move를 받기 전에 설비 event가 먼저 도착할 때인데, 그건 rework 문제가 아니라 S6F11은 전부 받았는데 lot 이력에 구멍이 남는 이유에서 다루는 순서 문제다.

설비가 unit ID와 result만 보내고 host도 instance를 관리하지 않으면 MES는 추정할 수밖에 없다. 같은 shift 안에 같은 unit이 같은 station으로 돌아오는 순간 그 추정은 깨진다.

Rework 사용 전 field test

Go-live 전에 scripted unit 하나로 loop를 끝까지 돌려 본다.

정상 route에서 unit을 시작하고 첫 공정을 완료한다.
실제 defect reason code로 inspection fail을 만든다.
설정된 rework path로 보낸다.
Rework station 또는 이전 공정에서 repair data를 수집한다.
다시 inspection으로 보내 pass 처리한다.
모든 순간 WIP가 한 current location에만 보이는지 확인한다.
첫 번째 visit과 두 번째 visit data가 모두 남아 있는지 확인한다.
First-pass yield에는 첫 fail이, final yield에는 이후 pass가 반영되는지 본다.
Label, recipe, equipment interlock이 current route state를 쓰는지 확인한다.
권한 없는 role이 제한된 disposition을 선택할 수 없는지 확인한다.

이 test는 production에서 쓸 scanner, HMI 화면, 설비 interface로 해야 한다. Admin MES 화면에서만 되는 rework loop는 작업자용으로 준비된 것이 아니다.

8번은 특히 넘어가기 쉽다. 화면에서 다 맞아 보여도 yield report는 보통 별도 view나 야간 집계로 만들어지고, 그 SQL이 route history의 마지막 record만 읽고 있는 경우가 많다. 첫 문단의 98%가 정확히 그 버그였다.

자주 나오는 실패 형태

실패 형태	보이는 증상	조치
Route history가 덮어써짐	최신 pass만 보임	Route step visit을 별도 record로 저장
WIP 중복	Unit이 두 queue에 동시에 보임	하나의 authoritative current state와 transaction move 사용
Defect reason 유실	Rework에 root cause가 없음	Route 변경 전 disposition reason 필수 입력
설비 result가 잘못된 pass에 붙음	Test data가 첫 visit 아래에 표시됨	Host에서 열린 route instance를 하나로 유지
Yield가 좋아진 것처럼 보임	Rework 후 첫 fail이 사라짐	First-pass yield와 final yield를 분리
작업자가 route를 우회	필요한 repair data 없이 manual move	Role과 route rule로 disposition 제한

작업자 화면은 단순해야 한다

내부 모델은 자세해도 작업자에게는 다음 action이 분명해야 한다.

현재 unit과 현재 route state.
이 unit이 왜 rework 위치에 왔는지.
필요한 repair 또는 inspection step.
반드시 입력해야 하는 data field.
Supervisor approval 필요 여부.
Pass 또는 fail 후 다음 이동 위치.

Visit number는 이 목록에 없다. 작업자가 몇 번째 방문인지 알아야 할 이유는 거의 없고, 화면에 띄우면 "2회차니까 대충 해도 되겠지" 같은 판단이 따라온다. Visit은 report와 traceability를 위한 것이지 작업 지시를 위한 게 아니다.