계측기 열 대를 책상에 늘어놓고 같은 작업을 반복한다. 장비사에서 받은 유틸리티는 한 번에 한 대만 잡는다. 모델이 두 종류라 프로그램도 두 개를 번갈아 띄운다. 값은 화면을 보고 사람이 옮겨 적는다.
전용 프로그램 이야기는 대개 이 자리에서 처음 나온다.
장비 제어 프로그램이란 PC에서 설비를 인식하고 설정을 넣고 동작까지 확인하는 전용 소프트웨어다. 장비사 유틸리티가 한 대를 다루는 도구라면, 제어 프로그램은 여러 대를 같은 규칙으로 다루는 도구다. 목적이 다르니 구조도 다르다.
장비사 유틸리티는 어디서 막히나
유틸리티는 장비를 파는 쪽이 만든 부속품이다. 한 대를 붙여 설정을 보고 바꾸는 데까지가 설계 범위다. 그 범위 밖은 현장이 사람 손으로 메운다.
막히는 자리는 대체로 넷이다. 모델이 늘면 프로그램도 같이 늘어난다. 열 대를 처리하려면 열 번을 반복한다. 누가 언제 무엇을 바꿨는지는 어디에도 남지 않는다. 사내 생산관리 시스템과는 애초에 연결되지 않는다.
마지막 항목이 제일 비싸다.
작업은 끝났는데 기록이 없으니, 불량이 나와도 어느 장비의 어떤 설정에서 시작됐는지 되짚을 길이 없다. 엑셀에 따로 적어두는 현장도 많다. 그 엑셀은 결국 사람의 기억과 성실함에 기대고 있어서, 바쁜 날일수록 칸이 비어 있다. 감사나 클레임이 들어오는 날은 하필 그 비어 있는 날이다.
제어 프로그램이 실제로 해야 하는 일은 뭔가
설비를 움직이는 코드는 이 일의 절반도 안 된다. 나머지 절반은 사람의 실수를 막는 장치다.
| 항목 | 장비사 유틸리티 | 전용 제어 프로그램 |
|---|---|---|
| 대상 | 한 모델, 한 대 | 여러 모델, 여러 대 동시 |
| 설정 투입 | 화면에서 수동 입력 | 모델 자동 매칭 후 검증 |
| 오류 차단 | 작업자 확인에 의존 | 규칙 위반이면 실행 중단 |
| 기록 | 남지 않음 | 작업자·시각·변경 내역 저장 |
| 연동 | 없음 | 기존 ERP·MES로 결과 전달 |
장비 제조사 한 곳은 모델마다 설정과 펌웨어가 달라서 업로드를 사람이 직접 했다. 손이 많이 갔고, 잘못된 파일을 올릴 위험이 늘 따라다녔다. 장비 인식과 자동 매칭, 설정 검증, 일괄 업로드, 이력 관리를 하나의 프로그램으로 묶고 나서야 그 위험이 정리됐다.
여기서 중요한 건 기능 목록이 아니다. 순서다.
장비를 먼저 알아보고, 그 모델에 맞는 값인지 확인하고, 맞을 때만 실행하고, 실행한 내용을 남긴다. 이 네 단계가 한 화면 안에서 끊기지 않아야 사람이 중간에 끼어들 자리가 사라진다. 권한을 나누는 일도 같은 맥락이다. 설정을 바꿀 수 있는 사람과 작업만 돌리는 사람을 구분해두면, 사고가 나기 전에 막히는 경우가 많다.
펌웨어 업로드 자체를 어떻게 관리하느냐는 따로 정리해 두었다. → 펌웨어 개발 외주, 업로드·이력 관리까지 묶어야 하는 이유
데이터를 위로 올린다는 건 무슨 뜻인가
제어 프로그램은 장비 옆에서 끝나기 쉽다. PC 한 대에 설치되고, 그 PC 안에서만 기록이 쌓인다.
그다음 질문이 항상 같다. 이 기록을 생산관리 쪽에서도 볼 수 있나.
여기서부터는 제어가 아니라 연동이다. 작업 결과를 사내 시스템이 읽을 수 있는 형태로 내보내고, 어느 주기로 어디까지 보낼지 정하는 일이다. 기존 ERP나 MES가 이미 돌고 있다면 그쪽 규격에 맞춰야 하고, 아직 없다면 나중에 붙일 자리를 비워두는 편이 낫다. 처음부터 크게 만들 필요는 없다. 다만 데이터를 어디로 보낼지 정하지 않은 채 화면부터 그리면, 나중에 프로그램을 다시 열어야 한다.
설비에서 값을 꺼내는 통신 자체가 막힌다면 그건 다른 문제다. → 시리얼 통신 프로그램, 설비에서 데이터를 꺼내는 가장 빠른 길
어디까지 만들고 시작해야 하나
한 번에 전부 만들 필요는 없다. 손이 제일 많이 가는 작업 하나부터 잡는 편이 낫다.
시작 전에 정해두면 좋은 건 세 가지다. 다루는 모델이 앞으로 몇 종까지 늘어나는가. 잘못된 설정이 들어갔을 때 무엇을 기준으로 막을 것인가. 작업 이력을 누가 언제 꺼내 볼 것인가.
세 번째 질문을 나중으로 미루는 현장이 많다. 그런데 이력 구조는 나중에 끼워 넣기가 가장 어렵다. 이미 돌아가는 프로그램에 기록 항목을 추가하려면 데이터 구조를 다시 손대야 하고, 그 사이에 쌓인 작업분은 복구할 방법이 없다.
장비 하나만 놓고 보면 프로그램 한 개짜리 일이다. 라인 전체로 보면 설비와 데이터, 기존 시스템까지 이어지는 일이 된다. 어느 쪽인지부터 가늠해두면 범위가 덜 흔들린다. → 맞춤 장비 개발, 어디까지 한 팀에 맡겨야 하나
GrowSpace는 이 구간을 한 팀으로 묶어 다룬다. 현장 센서와 컨트롤러 제작부터 제어 프로그램, 기존 ERP·MES 연동, 구축 뒤 운영까지 같은 인력이 이어받는다. → 맞춤 SW·HW 개발
자주 묻는 질문
기존 장비를 바꾸지 않고도 만들 수 있나요? 대부분 가능하다. 장비가 외부로 내주는 통신 규격이 있으면 그 위에 프로그램을 얹는다. 규격 문서가 없으면 실제 신호를 받아보며 확인하는 작업이 앞에 붙는다. 이 확인 단계의 길이가 일정에 가장 크게 영향을 준다.
장비 모델이 계속 늘어나는데 그때마다 프로그램을 고쳐야 하나요? 설계에 따라 갈린다. 모델별 설정을 코드에 박아두면 추가할 때마다 개발이 필요하다. 설정을 데이터로 분리해두면 담당자가 항목만 등록해서 쓴다. 모델이 늘어나는 현장이라면 처음부터 후자로 잡는 편이 낫다.
제어까지는 필요 없고 값만 모으면 되는데요? 그럼 범위가 훨씬 작아진다. 데이터 수집만 하는 프로그램은 설비를 직접 움직이지 않으니 검증과 권한 부담이 줄어든다. 다만 나중에 제어를 붙일 생각이라면 그 가능성은 미리 말해두는 편이 낫다.
먼저 볼 것은 기능 목록이 아니라, 지금 사람 손이 몇 번 들어가는지다. 그 횟수가 그대로 만들 범위가 된다.
