기술

설비 수십 대가 맞물려 돌아가는 생산 라인을 3D로 재현하는 시뮬레이터를, 밤새 사람 없이 15라운드 돌렸습니다. 빌드 → 검증 → 수정 → 릴리스를 한 묶음으로 두고 그 묶음을 반복하게 한 것입니다. 아침에 결과를 열어 봤습니다.

저희는 공장의 현황을 항목별로 매기는 진단 도구를 만듭니다. 값은 담당자에게 묻는 대신 회의 기록과 기존 자료로 자동으로 채워집니다.

저희는 공장을 짓거나 바꾸기 전에 컴퓨터 안에서 먼저 돌려 보는 가상공장 소프트웨어를 만들고 있습니다. 지난 글에서는 왜 만드는지를 적었는데, 이번 글은 그 반대쪽에 있는 이야기입니다.

공장 라인을 컴퓨터 안에서 미리 돌려 보는 도구를 만들고 있습니다. 로봇 팔이 교시된 경로로 움직일 때 옆 설비와 부딪히는지 재는 기능을 먼저 만들었는데, 그 기능이 생기자마자 다음 요청이 따라왔습니다. 부딪힌다고 알려만 주지 말고, 피해 가는 경로도 만들어 달라는 요청입니다.

팀이 사용하는 도구에 규칙을 하나 넣었다고 해 봅시다. 위험한 명령을 실행하기 전에 한 번 물어보는 확인, 파일을 고치기 전에 사본을 떠 두는 백업, 작업을 끝낼 때 빠뜨린 것이 없는지 훑는 점검 같은 것들입니다. 코드를 쓰고, 테스트를 돌리고, 초록불을 확인하고, 팀에 공지합니다.

제조 온톨로지를 만들어 본 곳은 이제 꽤 됩니다. 품목이 어느 공정에 투입되고, 그 공정이 어느 설비에서 돌고, 그 설비 상태가 품질에 어떻게 영향을 주는지. 관계를 표준으로 박아 두는 작업은 방법이 알려져 있고, 도구도 나와 있습니다.

자율형공장을 설명할 때 가장 자주 나오는 문장은 "AI가 공장을 인지하고 판단해서 실행한다"입니다. 맞는 말인데, 이 문장만으로는 무엇을 사야 하는지도 무엇을 확인해야 하는지도 알 수 없습니다. 인지가 카메라를 다는 일인지, 아니면 데이터 형식을 맞추는 일인지부터 갈립니다.

앞선 글에서 자율형공장·다크팩토리·무인공장 3가지 말을 갈라 두었습니다. 정의가 문서로 확정된 말은 자율형공장 하나뿐이고, 나머지 둘은 방향을 가리키는 말이지 합격을 판정하는 말이 아니라는 내용이었습니다.

앞선 글에서 상관은 알람을 만들고 인과는 결정을 만든다는 이야기를 했습니다. 이 글은 그 구분을 제품에서 어떻게 구현했는지에 대한 기록입니다. 개념이 아니라 구성과 순서, 그리고 아직 안 된 것까지 적었습니다.

공장 데이터는 밖으로 못 나갑니다. 공정 조건, 수율, 설비 파라미터는 그 자체가 영업기밀이라, 제조기업이 AI를 검토할 때 가장 먼저 부딪히는 요구가 "우리 서버 안에서 돌아야 한다"입니다. 이 요구가 오픈소스(정확히는 오픈웨이트) LLM 채택의 1차 동력입니다.

며칠 전 저희 데모 공장 트윈을 보던 대표가 물었습니다. "이게 완전한 자동 시뮬레이션 공장이 된 건가?"

예지보전 이야기는 보통 감지에서 시작해 감지에서 끝납니다. 어떤 알고리즘이 고장 징후를 며칠 먼저 잡아내는지, 거짓 경보를 얼마나 줄였는지. 저희도 그 이야기를 한 적이 있습니다. 고장은 새벽 3시에 옵니다라는 글에서 성격이 다른 탐지기 5종을 겹쳐 사각지대를 메우는 방법을 다뤘습니다.