개념
실물 설비를 못 쓴다는 것이 기본 조건이다
웹 QA 에서 테스트 환경을 못 쓰는 상황은 사고다. 제조 QA 에서는 정상 이다.
한빛정밀 2공장을 보자. 라인은 2교대로 돌고, 주말에만 보전으로 선다. 그 보전 시간은 설비 정비·금형 교체·청소에 먼저 배정된다. QA 가 받을 수 있는 실설비 시간은 월 몇 시간 단위 다. MES 를 새로 올리는 프로젝트라도 "라인 하루 세워서 통합 시험하자" 는 제안은 받아들여지지 않는다 — 라인 하루 정지는 2,400대의 생산 손실이고, 그 금액이 QA 조직의 한 해 예산을 넘는다.
여기에 더해 설비가 아직 없는 경우 가 흔하다. 신규 라인 프로젝트에서 MES 개발은 설비 입고보다 먼저 시작한다. 설비가 들어오는 시점에 MES 가 처음 동작하면 그때부터 현장에서 디버깅을 하게 되고, 그게 라인 가동 지연으로 이어진다.
그래서 제조 QA 의 실력은 대체 환경을 얼마나 잘 만드는가 로 거의 결정된다. 이 레슨은 그 대체 수단들을 구분하고, 각각의 한계를 분명히 하는 데 목적이 있다.
모듈 46 레슨 5 와의 경계 — 거기서 다룬 MIL·SIL·PIL·HIL 은 제어 로직과 ECU 소프트웨어를 모델·코드·프로세서·하드웨어 수준에서 검증하는 계층이다. 여기서 다루는 것은 공장 운영 소프트웨어(MES·SCADA) 관점에서 설비 쪽을 무엇으로 대신하는가 다. 같은 "시뮬레이션" 이라는 단어를 쓰지만 검증 대상이 다르다.
대체 수단 네 가지
현장에서 섞여 쓰이는 수단을 역할로 나누면 네 가지다.
1) PLC 시뮬레이터 PLC 제조사가 제공하는 개발 도구에 딸린 기능으로, 실제 PLC 하드웨어 없이 래더/ST 프로그램을 PC 에서 실행한다. 입력 비트를 손으로 켜고 끄면서 로직이 의도대로 흐르는지 본다. 제어 로직 자체 를 보기에 적합하다.
2) 소프트 PLC PLC 런타임을 산업용 PC 나 일반 PC 에서 돌리는 제품. 시뮬레이터와 달리 실제 통신 스택을 갖고 OPC UA 서버나 Modbus 서버로 동작한다. MES 쪽에서 보면 실제 PLC 와 거의 구분되지 않는다. 연동 시험의 주력이 여기다.
3) 장비 에뮬레이터(설비 스텁)
리크 테스터나 EOL 시험기처럼 자체 프로토콜을 쓰는 장비를, 프로토콜만 똑같이
흉내 내는 작은 프로그램 으로 대체한다. QA 가 직접 만드는 경우가 많다. 한빛정밀
OP40 EOL 시험기의 TCP 텍스트 프로토콜이라면, 소켓을 열고 정해진 형식으로
측정값을 흘려 보내는 스크립트 100줄이면 된다.
이게 QA 에게 가장 가치가 큰 수단 이다. 이유는 통제력이다. 실설비는 "불량을 10번 연속 내 달라" 고 요청할 수 없지만, 에뮬레이터는 시나리오 파일 한 줄로 만든다.
4) 디지털 트윈 물리 설비·라인의 거동을 모델로 만들어 시간에 따라 돌리는 환경. 공정 시간, 반송, 버퍼, 병목, 간섭을 포함한 라인 전체의 흐름 을 재현하는 쪽에 쓴다. 투자와 전문성이 크게 들어가고, 모델의 정확도가 곧 결과의 신뢰도다.
"디지털 트윈" 이라는 말은 마케팅 용어로도 넓게 쓰여서, 제안서에 적힌 디지털 트윈이 실제로는 3D 시각화에 가까운 경우가 있다. QA 는 그것이 시간을 돌릴 수 있는 모델인지, 그림인지 를 먼저 확인해야 한다.
무엇을 대체하고 무엇을 대체하지 못하는가
이 표가 이 레슨의 중심이다.
| 수단 | 잘 대체하는 것 | 대체 못 하는 것 |
|---|---|---|
| PLC 시뮬레이터 | 제어 로직 분기, 인터락 조건 조합 | 통신 스택, 실제 스캔 타이밍, 물리 응답 |
| 소프트 PLC | 프로토콜·태그 매핑, 끊김·복구, 데이터 흐름 | 센서 노이즈, 설비 기계적 편차, 전원 거동 |
| 장비 에뮬레이터 | 메시지 형식, 비정상 응답, 희귀 시나리오 | 실제 장비의 응답 시간 분포, 장비 내부 상태 |
| 디지털 트윈 | 택트·병목·버퍼 거동, 흐름 시나리오 | 모델에 넣지 않은 모든 것 |
마지막 칸의 "모델에 넣지 않은 모든 것" 이 디지털 트윈의 본질적 한계다. 트윈은 만든 사람이 생각한 것만 재현한다. 실설비의 결함은 보통 아무도 생각하지 않은 데서 나온다.
전체적으로 대체 못 하는 것 을 한 줄로 묶으면 이렇다 — 물리, 타이밍 편차, 사람. 이 셋은 실설비에서만 확인된다.
- 물리 — 압입 하중이 품번에 따라 달라지는 것, 온도에 따라 측정값이 드리프트하는 것, 먼지가 센서를 가리는 것
- 타이밍 편차 — 시뮬레이터는 응답이
10ms로 일정하지만 실설비는8~140ms로 분포한다. 긴 꼬리에서만 생기는 경쟁 조건이 있다 - 사람 — 작업자가 HMI 를 두 번 누르는 것, 바코드를 다른 제품에 찍는 것, 교대 인계 중에 화면을 띄워 둔 채 자리를 비우는 것
시뮬레이터로 통과한 것이 실설비에서 깨지는 전형
실제로 반복되는 패턴을 모아 두면 시험 설계가 달라진다.
타이밍이 달라서 깨진다
에뮬레이터는 요청을 받자마자 응답한다. 실설비는 측정이 끝나야 응답하므로 2초
걸린다. MES 의 수집 로직이 "요청하고 다음 주기까지 응답이 오면 된다" 는 전제로
짜여 있었다면, 주기가 1초 인 순간 깨진다. 에뮬레이터에 의도적으로 지연과
지연 분포를 넣는 것 이 유일한 예방책이다.
초기 상태가 달라서 깨진다 에뮬레이터는 언제나 깨끗한 상태로 시작한다. 실설비는 지난주에 중단된 작업이 남아 있다. 전원을 올리면 이전 레시피, 이전 카운터, 이전 알람이 그대로 있다. "시작 상태" 를 가정한 시험은 여기서 전부 깨진다.
값의 범위가 달라서 깨진다
에뮬레이터 시나리오는 보통 정상 범위를 쓴다. 실설비는 설비 워밍업 중에 측정값이
범위를 벗어나고, 센서가 잠깐 0 을 내고, 교정 직후 음수를 낸다. MES 가 이 값들을
어떻게 처리하는지는 시험되지 않은 채 가동에 들어간다.
개수와 동시성이 달라서 깨진다
에뮬레이터 1대로 시험했는데 실제로는 OP40 EOL 시험기가 2대 병렬이다. 두 대가
같은 초에 실적을 보낼 때의 경쟁 조건, 시리얼 번호 발급 충돌, 같은 지시 수량을
동시에 차감하는 문제가 처음 드러난다. 병렬 설비는 에뮬레이터도 병렬로 띄운다.
설정이 달라서 깨진다 개발 환경의 IP·포트·태그 이름·시간대·문자 인코딩이 현장과 다르다. 특히 시간대와 서버 시계 는 제조에서 치명적이다(l05 에서 다룬다). 에뮬레이터는 UTC 로 돌았는데 설비는 로컬 시각을 보내면 교대 경계 집계가 전부 밀린다.
실설비 시험 시간을 아껴 쓰는 계획
실설비 시간이 4시간 주어졌다고 하자. 그 시간을 어떻게 쓸지가 제조 QA 의 핵심
기술이다.
원칙 1 — 실설비에서만 되는 것만 실설비에서 한다
시험 항목 전체를 놓고 "이건 시뮬레이터로 되는가" 를 먼저 묻는다. 되는 것은 전부
빼낸다. 남는 것이 실설비 몫이다. 보통 전체의 10~20% 로 줄어든다.
원칙 2 — 실설비 항목을 설비 상태별로 묶는다
설비 상태를 바꾸는 데 시간이 든다. 전원 재투입에 10분, 레시피 변경에 5분,
불량품 투입 준비에 15분 이 든다면, 같은 상태에서 할 수 있는 항목을 몰아서
한다. 항목 순서가 아니라 상태 순서 로 계획을 짠다.
원칙 3 — 증거 수집을 자동화해 둔다 현장에서 스크린샷을 찍고 메모를 쓰다 보면 시간이 사라진다. 들어가기 전에 준비할 것 — 태그 값을 주기적으로 기록하는 수집 스크립트, DB 상태를 찍는 조회문 묶음, 로그 수집 경로. 현장에서는 조작하고 기록은 자동으로 쌓이게 한다.
원칙 4 — 실패를 전제로 순서를 정한다 가장 중요한 항목을 맨 앞에 둔다. 중간에 설비 고장이 나거나 생산이 급해져서 "지금 라인 올려야 한다" 는 말이 나오면 시험은 거기서 끝난다. 뒤로 밀린 항목은 다음 달이다.
원칙 5 — 되돌리기 계획을 먼저 쓴다 시험으로 바꾼 설정·투입한 더미 제품·만든 더미 실적 데이터를 어떻게 치울지 정해 둔다. 더미 실적이 그대로 남아 월 집계에 섞이는 사고가 흔하다. 시험 데이터에 식별 가능한 표식(전용 작업 지시 번호, 전용 로트)을 붙여 두면 나중에 걸러낼 수 있다.
원칙 6 — 실설비 접속·조작은 l02 의 선행 조건을 그대로 따른다 승인 문서, 라인 정지 상태, 설비 담당자 동석, 비상정지 위치 확인, 명령 목록 사전 합의. 실설비 시간이 아깝다는 이유로 이 조건을 건너뛰지 않는다.
실무에서 왜 필요한가
대체 환경을 못 만들면 테스트 일정이 설비 일정에 종속된다. 설비가 2주 늦게 들어오면 테스트가 2주 늦고, 그만큼 가동이 늦는다. 반대로 소프트 PLC 와 에뮬레이터를 먼저 세워 두면 설비 입고와 무관하게 연동 시험의 80% 를 끝낼 수 있다. 제조 프로젝트에서 QA 가 일정을 당기는 거의 유일한 방법이다.
에뮬레이터는 재현 가능성 도 만든다. 실설비에서 간헐적으로 나오는 현상은 재현이 안 되면 결함으로 접수되지 않는다. 에뮬레이터로 같은 조건을 만들어 10번 중 10번 재현시키면, 그 결함은 더 이상 "간헐적" 이 아니다. l02 에서 본 통신 품질 결함 대부분이 이 방식으로만 증명된다.
한계를 아는 것도 같은 무게로 중요하다. "시뮬레이터에서 전부 통과했습니다" 라는 보고는 무엇이 아직 검증되지 않았는지 를 함께 적지 않으면 위험하다. 물리·타이밍 편차·사람이 빠져 있다는 사실을 명시하면 조직이 실설비 시간을 배정할 근거가 된다.
디지털 트윈 도입 논의에서도 QA 의 판단이 필요하다. 트윈은 비싸고, 모델 정확도 검증이 또 하나의 검증 과제를 만든다. 트윈으로 답하려는 질문이 명확한가 — "이 라인이 택트 22초를 버티는가" 처럼 흐름에 관한 질문이면 가치가 있고, "실적 데이터가 맞게 올라오는가" 라면 소프트 PLC 가 훨씬 싸고 정확하다.