ERP, MES, IoT를 교체하지 않고 연결하기

공장의 핵심 병목 설비가 교대 중간에 멈추면, 생산 라인은 익숙한 반응형 대응 모드로 들어갑니다. 작업자는 즉시 정비팀을 호출하고, 감독자는 마스터 생산 일정을 확인하며, 팀원들은 여러 디지털 시스템을 교차 조회하기 시작합니다.

누군가는 제조실행시스템(MES)을 열고, 다른 누군가는 전사적자원관리(ERP) 플랫폼을 조회하며, 공장 현장의 위기는 또 다른 화면을 요구하는 것처럼 보이기 때문에 새로운 대시보드가 어김없이 등장합니다.

• 다중 시스템의 단절: 여러 시스템이 실제로 동작하고 있더라도, 그것들이 정확히 같은 운영 상황을 설명하는 경우는 드뭅니다.
• ERP 관점: ERP는 고객 주문이 존재한다는 사실을 인식하며, 필요한 자재, 계획 수량, 약속된 납기일, 상업적 우선순위를 재무적 결과를 동반한 계획 작업으로 추적합니다.
• MES 관점: MES는 현장의 실행 상태를 추적하며, 어떤 공정이 진행 중인지, 지금까지 보고된 수량은 얼마인지, 어떤 작업자가 배정되었는지, 품질 보류 상태의 부품이 어디에 있는지를 식별합니다.
• IoT/PLC 관점: IoT 및 센서 계층은 알람, 정지된 사이클 카운터, 설비 상태 변화와 같은 물리적 이벤트를 관측하며, 종종 ERP나 MES 기록보다 훨씬 정밀한 기술적 타임스탬프를 제공합니다.
• 궁극적인 실패: 세 시스템 모두 각자의 데이터 영역에서는 완전히 정확할 수 있음에도 불구하고, 공장은 여전히 "지금 공장은 무엇을 해야 하는가?"라는 단순한 질문에 대한 완전하고 통합된 답을 갖지 못합니다.

시스템 소유권 정의: ERP, MES, 그리고 IoT 계층
Microsoft Fabric, 엣지 게이트웨이, 메시지 브로커와 같은 고급 통합을 구현하기 전에, 엔지니어는 각 개별 시스템이 이미 수행하고 있는 고유한 운영 역할을 존중해야 합니다. 모든 플랫폼을 범용 데이터 저장소로 취급하면 조직적 혼란과 부정확한 보고를 초래합니다.

• 상업적 진실로서의 ERP: ERP 플랫폼은 고객 주문, 자재명세서(BOM), 재고 현황, 구매 데이터, 원가 기록, 재무 전기 등 상업적 약속에 대한 구조화된 기록의 역할을 합니다.
• ERP 의도의 한계: ERP 주문은 이론적으로 무엇이 일어나야 하는지를 나타내지만, 공정이 실제로 시작되었는지, 올바른 공구가 장착되었는지, 부품이 검사를 통과했는지는 증명할 수 없습니다.
• 통제 수단으로서의 MES: 제조실행시스템은 ERP의 계획 작업을 받아 통제된 현장 실행으로 전환하며, 작업 배정, 작업자 추적, 전자 배치 기록, 제품 이력(제품 계보)을 관리합니다.
• 세분화된 생산 상태: 생산 상태를 "완료"와 같은 일반적인 단어로 획일화해서는 안 됩니다. 부품이 물리적으로는 제작되었더라도 검사 대기, 자재 전기 대기, 또는 재작업 루프로 전환된 상태일 수 있기 때문입니다.
• IoT와 물리적 증거: 산업용 IoT는 물리적 설비에 가장 가까이 위치하여 실시간 모터 상태, 컨베이어 정지, 진동 변화, 사이클 펄스를 포착하지만, 상업적인 고객 우선순위는 알지 못합니다.
• 통제의 경계: PLC는 결정론적 제어, 인터록, 로컬 안전 동작에 대한 절대적인 소유권을 유지하며, 클라우드 또는 엣지 서비스가 기계의 즉각적인 고장 대응 루프 중간에 놓여서는 절대 안 됩니다.

맥락의 간극 극복: 시간, 명칭, 데이터 모델
ERP, MES, IoT 계층의 원시 데이터를 단일 클라우드 플랫폼으로 가져온다고 해서 공장 운영에 대한 공유된 이해가 자동으로 만들어지지는 않습니다. 적절한 시맨틱 데이터 모델이 없다면, 서로 나란히 놓인 이질적인 테이블은 명확성이 아니라 혼란을 만들어냅니다.

• 명칭 충돌: 하나의 설비가 ERP에서는 "Press Line 2", MES에서는 "PRS02", PLC 프로그램에서는 고유한 제어 태그로 불릴 수 있으며, 조직은 이러한 차이를 연결하기 위해 명시적인 자산 식별 매핑을 유지해야 합니다.
• 시간대 및 클록 불일치: PLC, MES 애플리케이션, ERP 회계 기간의 타임스탬프가 동기화되지 않으면, 하나의 물리적 이벤트가 세 개의 분리된 사건으로 잘못 나타날 수 있습니다.
• 비공식 스프레드시트의 위험: 공식 시스템이 복잡한 맥락적 관계를 자주 포착하지 못하기 때문에, 공장은 비공식 통합 계층으로서 취약한 로컬 스프레드시트에 크게 의존합니다.
• 진정한 데이터 품질: 제조 데이터 품질은 데이터베이스 필드에 값이 있는지 확인하는 데서 멈출 수 없습니다. 그 값이 올바른 자산, 공정, 작업, 단위, 그리고 정확한 시각을 가리키는지 검증해야 합니다.

실무 공장 시나리오: 병목 고장 이후의 재계획
구조적 통합이 왜 중요한지 이해하기 위해, 고수요 제품군의 출력을 제한하는 병목 가공 센터를 운영하는 공장을 떠올려 봅시다. 오후 교대 중 스핀들 알람으로 인해 설비가 갑자기 멈춥니다.

• 다층적 대응: 정비팀은 설비 텔레메트리를 통해 스핀들 냉각 고장을 확인하고, MES는 설비가 활성 생산 오더의 중간 지점에 있었음을 강조하며, ERP는 해당 오더가 긴급한 고객 납품 약속을 뒷받침하고 있음을 보여줍니다.
• 대체 자원 평가: 남은 작업을 대체 설비로 옮기는 것은 간단해 보이지만, 계획 담당자는 공구 호환성, 지그 가용성, 작업자 자격, 셋업 가능 시간대, 라우팅 제약을 검증해야 합니다.
• 의사결정 프레임: 성숙한 통합 아키텍처는 이러한 상호 연결된 사실들을 보여주는 신뢰할 수 있는 의사결정 프레임을 제공하여, 자동화된 시스템 우선 적용을 강요하지 않고 사람인 계획 담당자와 엔지니어가 트레이드오프를 저울질할 수 있게 합니다.

점대점 통합의 함정 피하기
새로운 시스템 소비자마다 직접적인 점대점 연결을 구축하면, 시간이 지나면서 무너지는 지속 불가능한 맞춤형 매핑 로직의 거미줄이 만들어집니다.

• 스파게티 통합의 함정: 정비, 품질, 에너지, 보고 시스템이 각각 원시 데이터 소스에서 맞춤형 추출을 구축하면서 유지보수 부담이 기하급수적으로 늘어납니다.
• 조용한 통합 실패: 인터페이스가 완전히 끊어지면 즉각적인 주목을 받지만, 자산 ID나 측정 단위를 조용히 바꾸는 잘못된 매핑은 몇 주 동안 실행되어 확신에 찬 잘못된 결과를 만들어낼 수 있습니다.
• 비즈니스 데이터 계약의 필요성: 기술적 통합은 데이터가 이동할 수 있는지를 답하지만, 비즈니스 데이터 계약은 메시지가 무엇을 의미하는지, 누가 필드를 소유하는지, 허용된 값은 무엇인지, 지연 도착 데이터는 어떻게 처리하는지를 규정합니다.
• 시스템 경계 보호: 데이터 플랫폼과 로우코드 애플리케이션은 승인된 워크플로 밖에서 사용자가 실시간 생산 오더나 재고 잔액을 자유롭게 변경할 수 있는 그림자 시스템이 되어서는 안 됩니다.

아키텍처 패턴: 통합 네임스페이스(UNS)와 엣지 컴퓨팅
점대점 연결의 유지보수 부담에서 벗어나기 위해, 현대 공장은 데이터 발행자와 시스템 소비자를 분리하는 아키텍처 패턴에 주목하고 있습니다.

• 통합 네임스페이스(UNS): UNS는 발행-구독 메시징(일반적으로 MQTT 브로커 사용)을 통해 거버넌스가 적용된 공유 이벤트 공간을 제공하므로, 데이터 발행자가 누가 메시지를 소비하는지 알 필요가 없습니다.
• 논리적 토픽 계층 구조: 잘 설계된 UNS는 토픽을 공정 영역, 라인, 셀, 설비별로 논리적으로 구성하여, 엔지니어가 토픽 경로만으로 데이터의 출처를 이해할 수 있게 합니다.
• UNS가 대체하지 않는 것: 브로커는 현재 이동 중인 이벤트를 배포하지만, ERP의 거래 전기 검증, 장기 과거 데이터 아카이브, 원천 데이터 관리 규율을 대체하지는 않습니다.
• 기존(브라운필드) 설비의 안전한 연결: 구형 기계는 수동형 전류 센서와 디지털 I/O 탭을 사용하여 연결해야 합니다.