개념
제조 데이터의 결함은 조용히 쌓인다
기능 결함은 화면에서 티가 난다. 버튼이 안 눌리면 누군가 바로 말한다. 그런데 제조 데이터의 결함은 아무도 즉시 알아채지 못한다. 실적이 2대 더 올라가도 라인은 그대로 돌고, 재공 수량이 5대 틀려도 다음 공정은 제품이 있으니 작업한다. 숫자가 틀린 것이 드러나는 시점은 보통 세 가지다 — 월말 재고 실사, 고객 클레임으로 특정 시리얼을 역추적할 때, 그리고 원가 계산이 작년과 안 맞을 때.
그때가 되면 틀어진 시점을 찾을 수 없다. 로그는 이미 지나갔고, 설비는 그 사이 수천 대를 더 만들었다. 그래서 제조 QA 의 데이터 검증은 "지금 숫자가 맞는가" 를 보는 일이 아니라 "숫자가 틀어지면 틀어진 순간에 드러나는 장치가 있는가" 를 설계하는 일이다.
다섯 종류의 숫자가 서로를 설명한다
예제 공장(한빛정밀 2공장) 의 하루를 숫자로 적으면 이렇다.
| 숫자 | 뜻 | 세는 곳 |
|---|---|---|
| 투입 | 공정에 들어간 수량 | 작업 지시, 자재 출고 |
| 산출(양품) | 공정을 통과한 수량 | 설비 완료 신호, 판정 OK |
| 불량 | 판정 NG 로 빠진 수량 | 설비 판정 결과, 작업자 입력 |
| 재작업 | NG 중 손봐서 다시 넣은 수량 | 재작업 지시, 재투입 기록 |
| 재공(WIP) | 지금 라인 안에 있는 수량 | 계산값 또는 실사값 |
이 다섯 개는 독립적인 값이 아니다. 공정 하나를 두고 보면 반드시 아래 식이 성립해야 한다.
기초 재공 + 투입 = 산출(양품) + 불량 + 기말 재공
재작업이 있으면 식이 한 겹 늘어난다. 재작업품을 다시 투입으로 세는지, 불량에서 빼는지 는 공장마다 정책이 다르고, 그 정책이 문서화돼 있지 않은 경우가 대부분이다. QA 가 가장 먼저 할 일은 코드를 읽는 것이 아니라 이 식의 정의를 합의 문서로 만드는 것 이다. 정의가 없으면 "이 숫자가 틀렸다"는 결함을 제기할 근거가 없고, 개발자는 "그렇게 동작하도록 만들었다"고 답할 수 있다.
수율은 정의가 세 개다
수율(yield) 은 제조 품질 지표의 중심인데, 같은 라인에서 세 가지 값이 나온다.
- 공정 수율 — 공정 하나를 통과한 비율.
OP30 산출 ÷ OP30 투입 - 직행률(FPY, First Pass Yield) — 재작업 없이 한 번에 끝까지 통과한 비율
- 최종 수율 — 재작업을 포함해 최종적으로 출하 가능한 비율
같은 날 OP30 에서 100대 중 95대가 통과하고, 떨어진 5대 중 4대를 재작업으로
살렸다면 공정 수율은 95%, 직행률은 95%, 최종 수율은 99% 다. 경영 보고에는
최종 수율이 올라가고, 개선 활동은 직행률을 봐야 한다. 화면에 "수율" 이라는
이름의 숫자가 하나만 있으면 그것이 어느 정의인지 반드시 확인한다. 이름이
"수율" 인데 계산식이 최종 수율이면, 라인 개선 담당자는 매달 잘못된 숫자로
회의를 한다.
ISO 9000 계열 용어나 식스 시그마 계열 지표 정의(DPMO, RTY 등) 의 정확한 정의 문장은 각 체계의 원문에서 확인한다(해당 규격·교재 원문 확인). 이 레슨에서 중요한 것은 특정 정의가 맞다는 주장이 아니라, 프로젝트 안에서 정의가 하나로 고정돼 있는지 를 QA 가 확인한다는 점이다.
실적이 중복되는 네 가지 경로
실적 1건이 2건으로 올라가는 일은 생각보다 흔하다. 경로는 대개 네 가지다.
1) 설비 재전송 — 설비가 실적을 보냈는데 MES 응답(ACK) 을 못 받아 같은 건을 다시 보낸다. MES 쪽에 멱등 처리 가 없으면 2건이 된다. 멱등의 열쇠는 설비가 보내는 식별자다 — 시리얼 번호, 또는 설비 고유 카운터 값.
2) 작업자 수동 입력 중복 — 통신 장애로 실적이 안 올라간 것을 작업자가 수동 입력하고, 나중에 통신이 복구되면서 설비의 미전송 버퍼가 밀려 올라온다. 자동과 수동이 합쳐져 2배가 된다.
3) 재처리 배치 — "어제 실패한 건을 다시 처리" 하는 배치가 성공한 건까지 다시 넣는다. 실패 판정 기준이 느슨하면 전부 중복된다.
4) 화면 이중 클릭·새로고침 재전송 — 웹 서비스에서 익숙한 그 결함이 그대로 나타난다. 다만 여기서는 돈이 아니라 생산 수량이 틀어진다.
QA 입장에서 중요한 것은 네 경로 각각에 시험 케이스가 있는가 다. 1번과 2번은 모듈 62 레슨 3 의 에뮬레이터로 만들 수 있다. 3번은 실패 건을 인위적으로 만들고 배치를 두 번 돌려 확인한다. 4번은 일반 웹 시험 기법 그대로다.
누락은 중복보다 찾기 어렵다
중복은 "합계가 많다" 로 드러난다. 누락은 아무 신호도 없다. 양품 1,198대가 1,200대여야 했다는 것을 아는 방법은 다른 계층의 숫자와 비교하는 것 뿐이다.
- PLC 의 생산 카운터 값 vs MES 실적 건수
- 설비 자체 로그의 측정 레코드 수 vs MES 측정값 저장 건수
OP50마킹 건수 vs 포장 수량 vs 출고 수량- 투입 자재 수량 ÷ 제품당 소요량 vs 산출 수량
이 비교를 대조 지점(reconciliation point) 이라고 부른다. QA 가 설계할 산출물은 "이 라인에 대조 지점이 몇 개 있고, 각 지점이 몇 분 주기로 비교되며, 벌어졌을 때 누구에게 알림이 가는가" 라는 표다. 대조 지점이 하나도 없는 시스템은 누락을 구조적으로 발견할 수 없다. 이것은 결함 1건이 아니라 설계 지적으로 올린다.
재공이 실물과 벌어지는 길
재공(WIP) 수량은 보통 계산값이다. 그래서 계산의 전제가 깨지면 실물과 벌어진다. 전형적 경로는 이렇다.
- 빼돌린 제품 — 작업자가 설비 밖으로 제품을 빼서 따로 확인한 뒤 다시 넣는다. 시스템에는 흔적이 없다
- 공정 건너뛰기 — 설비 고장으로
OP30을 우회해 수동 시험으로 대체했는데 MES 에는OP30통과 기록이 없다. 그 제품은 영원히OP30재공으로 남는다 - 폐기 미등록 — 떨어뜨려 깨진 제품을 치웠지만 폐기 등록을 안 했다
- 교대 경계 — 교대 마감 시점에 설비 안에 있던 제품이 어느 교대 실적인지 규칙이 없다. 양쪽 교대 합계가 하루 합계와 안 맞는다
- 미래 날짜·과거 날짜 입력 — 작업자가 날짜를 잘못 입력해 어제 재공이 오늘 늘어난다
이 중 교대 경계 와 공정 건너뛰기 는 QA 가 시험으로 반드시 덮어야 한다. 나머지는 운영 규칙 문제이지만, 시스템이 그 상황을 표현할 수 있는지 는 시험 대상이다. 폐기 등록 화면이 없으면 폐기 미등록은 사용자 잘못이 아니라 기능 누락이다.
추적성은 양방향 모두 끊길 수 있다
추적성 시험을 "완성품 시리얼을 넣으면 자재 로트가 나오는가" 로만 하면 절반만 본 것이다. 두 방향이 모두 필요하다.
- 역추적(backward) — 시리얼
EWP24A00731에 들어간 자재 로트, 작업한 설비, 적용한 레시피, 측정값, 작업자, 시각 - 정추적(forward) — 자재 로트
IMP-2409-07이 들어간 완성품 전부. 리콜 범위를 정하는 데 이 방향이 쓰인다
정추적이 더 자주 깨진다. 역추적은 화면이 있어서 누가 한 번은 써 보지만, 정추적은 리콜이 터질 때 처음 쓰이기 때문이다. QA 는 로트 하나를 골라 정추적 결과 건수를 세고, 그 로트의 입고 수량과 비교 한다. 입고 300개인데 정추적 결과가 180대면 120개의 행방이 설명되지 않는다 — 남은 재고일 수도, 기록 누락일 수도 있고, 그 구분을 할 수 있어야 추적성이 성립한다.
시간 축이 데이터를 틀어뜨린다
제조 데이터에는 최소 네 가지 시각이 섞인다.
| 시각 | 뜻 | 틀어지는 이유 |
|---|---|---|
| 설비 시각 | PLC·시험기가 찍은 시각 | 설비 시계가 안 맞음, NTP 미동기 |
| 수집 시각 | 게이트웨이가 받은 시각 | 버퍼에 쌓였다 몰려 올라옴 |
| 저장 시각 | DB 에 들어간 시각 | 배치 처리로 밀림 |
| 업무 시각 | 생산일자·교대 | 자정이 아니라 교대 경계로 나뉨 |
"생산일자" 가 위 넷 중 무엇을 기준으로 하는지가 정해져 있지 않으면 하루 경계의 수량이 매일 조금씩 틀린다. 그리고 설비 시계가 3분 틀어져 있으면 측정값과 작업 지시의 짝이 어긋나 추적성이 끊긴다. QA 는 설비 시계 동기 여부와 허용 오차를 시험 전제로 문서화 하고, 시계를 일부러 틀어 놓은 조건을 시험 케이스에 넣는다.
실무에서 왜 필요한가
제조 현장에서 QA 가 가장 빠르게 신뢰를 얻는 방법은 조회문으로 틀어진 숫자를 찾아 오는 것 이다. 기능 결함은 개발자도 알고 기획자도 알지만, 데이터 정합성 결함은 보통 아무도 보고 있지 않다.
그리고 이 결함들은 비용이 특이하게 크다. 실적이 틀리면 원가가 틀리고, 재공이 틀리면 재고 자산이 틀리고, 추적성이 끊기면 리콜 범위를 좁힐 수 없어 출하한 전량을 회수한다. 기능 결함 하나가 화면 수정으로 끝나는 데 비해, 데이터 결함 하나는 이미 쌓인 과거 데이터까지 보정해야 한다. 보정 작업은 대개 개발보다 비싸다.
QA 가 착수 시점에 만들어 두면 사업 끝까지 쓰이는 산출물이 셋 있다.
- 용어·계산식 정의서 — 투입·산출·불량·재작업·재공·수율의 정의와 식. 합의 서명을 받아 둔다
- 정합성 규칙 목록 — 조회문으로 판정 가능한 형태로 쓴 규칙들. 운영 중에도 정기 점검으로 돌아간다
- 대조 지점 표 — 어느 계층의 어느 숫자를 어느 주기로 비교하는가
이 셋은 QA 산출물로 끝나지 않고 운영 감시 요건으로 이어진다. 시험 때 썼던 정합성 조회문이 그대로 운영 모니터링 쿼리가 되는 경우가 많다. 이 연결을 의식해서 처음부터 재사용 가능한 형태 로 써 두면 일이 두 번 되지 않는다.