연결성은 통합이 아니다 — 연결된 공장이 여전히 올바른 질문에 답하지 못하는 이유

연결된 공장은 기계 신호를 밀리초 단위로 전달할 수 있지만, 실제로 중요한 운영상의 질문에는 답하지 못할 수 있습니다. 포장기가 멈추면 PLC가 고장을 보고하고, OPC UA가 이벤트를 노출하며, MQTT가 이를 배포하고, 대시보드가 즉시 갱신됩니다. 유지보수팀은 알림을 받고 모든 것이 연결되어 있는 것처럼 보입니다. 그러나 계획 담당자가 어떤 고객 출하가 지금 위험에 처했는지 물으면, 답을 얻기 위해 MES 데이터, ERP 기록, 유지보수 이력, 품질 상태, 생산 수량, 납기 약속, 그리고 종종 스프레드시트까지 필요해집니다. 이 간극이 이번 에피소드의 핵심입니다. 연결성은 신호를 옮기고, 통합은 의미, 제약 조건, 책임, 시점, 그리고 결과를 연결합니다.

연결성은 신호를 옮기고 — 통합은 의미를 연결한다
OPC UA, MQTT, 엣지 게이트웨이, 브로커, 그리고 최신 산업용 연결성 플랫폼은 중요한 문제를 해결합니다. 기계 데이터에 접근하기 쉽게 만들고, 전송 방식을 표준화하며, 점대점 연결을 줄이고, 기계·애플리케이션·클라우드 서비스 간에 이벤트가 이동하도록 합니다. 그러나 알람을 전송한다고 해서 그 알람이 가진 업무상의 결과가 설명되지는 않습니다.

고장 코드는 완벽하게 도착하고, 올바른 타임스탬프를 유지하며, 몇 초 안에 모든 구독자에게 도달할 수 있습니다. 그럼에도 계획 담당자에게는 멈춘 기계가 긴급 주문에 영향을 주는지, 승인된 재고가 이미 있는지, 현재 생산물이 품질 보류 상태인지, 또는 다른 자원이 대신 작업을 맡을 수 있는지를 알려주지 못합니다. 이러한 질문에 답하려면 아키텍처에 기계, 활성 작업, 작업 지시서, 제품, 자재 상태, 품질 상태, 유지보수 정보, 고객 수요 사이의 관계가 있어야 합니다.

하나의 알람, 여러 시스템, 완전한 답은 없음
이 에피소드는 포장기 알람 하나가 생산 이야기의 서로 다른 부분을 담고 있는 시스템들을 거쳐 가는 과정을 따라갑니다. PLC는 기계에서 무슨 일이 일어났는지 알고 있습니다. MES는 어떤 작업과 작업 지시서가 활성 상태인지 이해합니다. ERP는 수요, 납기일, 재고, 고객 약속을 압니다. 유지보수는 서비스 이력과 미결 작업을 압니다. 품질은 생산된 결과물을 실제로 출하할 수 있는지 판단합니다.

각 시스템은 올바를 수 있지만, 공장 전체로서는 여전히 운영상의 질문에 답할 수 없습니다. 여기서 사람이 통합 계층이 됩니다. 누군가는 MES를 확인하고, 다른 누군가는 ERP를 열며, 유지보수팀은 서비스 이력을 검색하고, 품질팀은 출하 상태를 확인하며, 결국 누군가가 수동으로 정보를 취합합니다. 이 방식은 의사결정이 빠르게 이루어져야 하거나, 시스템이 바뀌거나, 숨겨진 매핑을 모두 이해하는 사람이 자리를 비울 때까지는 작동합니다.

통합 네임스페이스: 더 나은 고속도로이지 공장의 지도가 아님
통합 네임스페이스(Unified Namespace)는 많은 직접적인 시스템 간 연결을 공유 발행-구독 환경으로 대체함으로써 이 상황을 크게 개선할 수 있습니다. 기계와 애플리케이션은 정보를 한 번 발행하고, 소비자는 필요한 것을 구독하며, 새로운 시스템은 장비와의 또 다른 맞춤형 연결 없이 합류할 수 있습니다.

이는 배관 작업을 줄여주지만, 자동으로 맥락을 만들어 주지는 않습니다. MQTT 토픽 구조는 정보가 어디에서 왔는지 알려줄 수 있지만, 어떤 생산 오더가 활성 상태였는지, 어떤 자재가 관련되었는지, 어떤 품질 상태가 적용되었는지, 또는 어떤 고객 납품이 그 오더에 의존하는지는 결정할 수 없습니다. MES, ERP, 품질, 기계 이벤트를 같은 브로커에 발행한다고 해서 그것들 사이의 관계가 자동으로 생성되지는 않습니다. 그 관계는 여전히 모델링되고 거버넌스가 적용되어야 합니다.

태그 명명 규칙의 함정
좋은 명명 규칙은 사람이 데이터를 찾는 데 도움이 되지만, 이름이 곧 식별자는 아닙니다. 한 시스템은 기계를 Packer7이라고 부르고, 유지보수는 PK07을 사용하며, ERP는 생산 자원 코드를 쓰고, 클라우드 플랫폼은 같은 장비를 디바이스 식별자로 알 수 있습니다. 이 모든 기록은 같은 물리적 자산을 가리킬 수 있습니다.

관리되는 식별자가 없으면 조직은 점차 매핑 테이블, 맞춤형 스크립트, 보고서별 변환, 문서화되지 않은 가정을 쌓아가게 됩니다. 그러다 기계가 이동하거나, 재구성되거나, 이름이 바뀌거나, 새 컨트롤러를 받게 되면 데이터는 계속 흐르지만 관계는 조용히 틀어집니다. 친숙한 이름은 사람에게 유용하지만, 시간이 지나도 시스템을 연결된 상태로 유지하는 것은 안정적인 식별자입니다.

ERP와 MES는 서로 다른 역할을 한다
ERP와 MES는 관련이 있지만 같은 시스템으로 취급해서는 안 됩니다. ERP는 수요, 공급, 재고, 고객 약속, 생산 오더, 재무적 결과를 다루는 업무 및 계획 수준에서 작동합니다. MES는 작업, 생산 자원, 작업자, 설비 정지, 수량, 자재 소비, 그리고 현장에서 실제로 진행되는 작업의 진척에 더 가까운 실행 수준에서 작동합니다.

이러한 책임을 명확히 유지하고 시스템을 의도적으로 연결할 때, 하나의 플랫폼이 모든 것을 소유하도록 강요하는 대신 아키텍처는 더 신뢰할 수 있게 됩니다. 기계는 생산이 완료되었다고 보고할 수 있지만, 품질은 여전히 그 결과물을 보류 상태로 둘 수 있습니다. MES는 작업이 완료되었다고 표시할 수 있지만, ERP는 아직 완제품 입고를 기록하지 않았을 수 있습니다. 이러한 상태들은 모두 같은 생산 과정의 서로 다른 시점을 설명하므로 모두 유효할 수 있습니다.

데이터는 신호이고 — 맥락은 그 주변의 공장이다
온도 값은 데이터입니다. 맥락은 어떤 센서가 그 값을 생성했는지, 어떤 기계가 그 센서를 포함하는지, 어떤 제품이 가동 중이었는지, 어떤 레시피가 적용되었는지, 어떤 단위가 사용되었는지, 센서가 교정되었는지, 그리고 그 생산 실행에서 허용 가능한 운전 범위가 무엇이었는지를 설명합니다.

설비 정지 이벤트도 마찬가지입니다. 신호는 무언가 멈췄다는 것을 알려줍니다. 맥락은 어떤 작업이 영향을 받았는지, 어떤 오더가 가동 중이었는지, 어떤 자재가 사용되고 있었는지, 생산된 결과물이 실제로 사용 가능한지, 다른 자원이 대신 맡을 수 있었는지, 그리고 어떤 고객 약속이 이제 위험에 처했는지를 알려줍니다.

유용한 산업 맥락에는 보통 다음이 포함됩니다.
• 자산 맥락 — 물리적 대상이 무엇이며 어디에 위치하는지
• 공정 맥락 — 해당 자원이 실제로 무엇을 할 수 있는지
• 오더 맥락 — 현재 어떤 작업이 진행 중인지
• 자재 맥락 — 어떤 로트와 부품이 관련되는지
• 품질 맥락 — 결과물이 출하 가능, 제한, 또는 보류 상태인지
• 시간 맥락 — 이벤트가 발생했을 때 어떤 관계가 유효했는지

이러한 관계가 존재하면, 같은 기계 이벤트도 계획 수립과 의사결정에 훨씬 더 유용해집니다.

스키마, 온톨로지, 그래프는 서로 다른 것이다
스키마는 레코드의 형태를 정의합니다. 자산 ID, 이벤트 타임스탬프, 고장 코드, 작업 지시서 ID, 또는 공학 단위와 같은 필드를 요구할 수 있습니다. 온톨로지는 공장 전반에서 사용되는 개념과 관계의 공유된 의미를 정의합니다. 그래프는 그러한 연결된 엔티티를 저장하고 질의하는 실용적인 방법을 제공합니다.

예를 들어, 기계는 생산 라인에 속할 수 있고, 센서는 부품을 측정할 수 있으며, 작업은 작업 지시서에 속할 수 있고, 자재 로트는 그 작업 중 소비될 수 있으며, 완성된 결과물은 품질 상태를 가질 수 있습니다. 그래프는 이러한 연결을 쉽게 탐색하게 해주지만, 단순히 그래프 데이터베이스를 선택한다고 해서 의미 있는 관계가 만들어지지는 않습니다. 품질은 그 링크를 둘러싼 모델, 책임, 시점, 식별, 거버넌스에서 나옵니다.

기계 알람에서 유용한 생산 답변까지
이러한 관계가 모델링되어 있다면, 포장기 알람은 더 넓은 생산 맥락을 통해 추적될 수 있습니다. 고장 이벤트는 물리적 자산을 식별하고, 자산은 생산 자원에 연결되며, 자원은 활성 작업에 연결되고, 작업은 작업 지시서에 연결되며, 작업 지시서는 제품, 수량, 수요, 납품 약속에 연결됩니다.
자재 관계는 무엇이 소비되었는지를 보여줍니다. 품질 관계는 완료된 생산물이 실제로 사용 가능한지를 보여줍니다. 유지보수 관계는 서비스 이력과