산업 데이터 모델이란 무엇인가

대부분의 공장은 방대한 양의 데이터를 수집하지만, 여전히 기본적인 운영 질문 하나에 답하기 어려울 때가 많습니다. 바로 "이 사건은 실제로 무엇에 영향을 미치는가?"입니다.

ERP는 고객 주문, 자재, 계획 일정, 재고를 알고 있습니다. MES는 현장에서 실행 중인 작업을 알고 있습니다. PLC와 SCADA는 설비 상태, 알람, 공정 값을 알고 있습니다. 유지보수 시스템은 자산 상태와 정비 이력을 알고 있습니다. 품질 시스템은 검사 및 출하 상태를 알고 있습니다. 엔지니어링 시스템은 제품 정의를 알고 있습니다. 문제는 대개 데이터가 부족하다는 데 있지 않습니다. 문제는 이 시스템들이 서로 다른 이름, ID, 상태, 규칙으로 같은 공장을 묘사한다는 데 있습니다.

산업용 데이터 모델은 이러한 경계를 넘어 공유된 의미를 만들어 줍니다. 중요한 공장 객체를 정의하고, 안정적인 식별자를 부여하며, 제품, 공정, 자원, 주문, 자재, 사람, 도구, 품질 기록, 설비 이벤트가 서로 어떻게 연관되는지 기술합니다. 목표는 ERP, MES, 유지보수 등 원천 시스템을 대체하는 것이 아닙니다. 목표는 이들의 정보를 하나의 연결된 생산 맥락으로 이해할 수 있게 만드는 것입니다.

수많은 시스템, 그러나 공유된 의미는 없음
현대 공장에는 거의 모든 핵심 업무를 담당하는 전문 시스템이 이미 존재합니다. ERP는 수요와 약속을 관리합니다. MES는 실행을 관리합니다. PLC는 설비를 제어합니다. SCADA는 설비 상태를 보여 줍니다. 히스토리언은 공정 데이터를 저장합니다. 유지보수 시스템은 자산과 정비 작업을 관리합니다. 품질 시스템은 검사 기록을 유지하며, Power BI는 이 정보들을 결합해 보고할 수 있습니다.

각 시스템에는 존재 이유가 있습니다. 문제는 같은 실제 대상이 각 시스템에서 서로 다르게 표현될 때 시작됩니다. 하나의 설비가 ERP에서는 작업장, 유지보수 시스템에서는 자산 번호, MES에서는 자원, 제어 시스템에서는 OPC UA 노드 묶음, 현장에서는 또 다른 별칭으로 불릴 수 있습니다.

산업용 모델은 모든 시스템이 하나의 식별자를 쓰도록 강요하지 않습니다. 대신 각 참조가 동일한 물리적 또는 논리적 객체와 어떻게 연관되는지를 기록합니다. 이를 통해 각 원천 시스템이 필요로 하는 로컬 구조를 파괴하지 않으면서도 공장 전체에 안정적인 식별 계층을 제공합니다.

산업용 데이터 모델의 실체
산업용 데이터 모델은 공장에서 무엇이 중요한지, 그리고 그것들이 어떻게 연결되는지를 설명하는 공유 규칙 집합입니다.

생산 주문이란 무엇인지, 제품 리비전이 무엇을 의미하는지, 작업장이 물리 자산과 어떻게 다른지, 자재는 언제 출고되는지, 설비가 '가용' 상태라는 것이 실제로 무엇을 뜻하는지와 같은 실무적 질문에 답합니다.

이 모델은 다음을 기술할 수 있습니다.
• 객체 유형과 식별자
• 속성과 상태
• 공장 객체 간의 관계
• 원천 시스템 참조
• 유효 일자와 버전
• 관계에 붙은 조건
• 정의와 규칙의 소유권

이를 통해 여러 시스템이 하나의 무리한 상태로 뭉개지지 않고 같은 생산 상황의 서로 다른 측면을 설명할 수 있습니다. 주문은 ERP에서 출고 확정되어 있어도 현재 MES 공정에서는 막혀 있을 수 있습니다. 설비는 기계적으로 건강하더라도 필요한 지그가 없어 사용 불가능할 수 있습니다. 이 사실들은 동시에 참일 수 있습니다.

모델은 데이터 플랫폼이 아님
Microsoft Fabric, SQL 데이터베이스, 히스토리언, 데이터 레이크 등 다른 플랫폼은 정보를 저장하고, 이동하고, 거버넌스하고, 분석하는 데 유용합니다. 하지만 기록들을 함께 저장한다고 해서 공장에서 작업장이 무엇을 의미하는지 결정되지는 않습니다.

ERP 주문, MES 실행 기록, 유지보수 이벤트, 품질 결과, 설비 텔레메트리를 하나의 Lakehouse에 적재하더라도, 특정 주문이 교대 시간이 끝나기 전에 다른 설비로 옮겨갈 수 있는지는 답할 수 없을 수 있습니다.
그 답은 관계에 달려 있기 때문입니다.

어떤 제품 리비전이 관련되어 있는가? 다음에 어떤 공정이 수행되어야 하는가? 그 공정에 어떤 자원이 승인되어 있는가? 필요한 치공구는 무엇인가? 작업자는 자격이 있는가? 현재 설비 상태가 작업을 허용하는가? 대체 라우팅에 검사 규칙이 붙어 있는가?
플랫폼은 그러한 관계를 호스팅하고 질의할 수 있지만, 관계 자체는 공장이 정의해야 합니다.

테이블만으로는 어려워지는 이유
관계형 테이블 자체가 문제는 아닙니다. ERP, MES, 유지보수 및 많은 제조 애플리케이션은 트랜잭션과 구조화된 기록에 탁월하기 때문에 관계형 모델에 의존합니다.

어려움은 시간에 따라 변하는 여러 관계를 가로지르는 생산 질문이 등장할 때 나타납니다.
제품 리비전은 여러 공정을 필요로 할 수 있습니다. 한 공정은 여러 자원에서 승인될 수 있습니다. 한 설비는 특정 제품 버전, 치공구 조합, 치수 범위, 검사 요건에만 대응할 수 있습니다. 작업자 자격은 만료될 수 있습니다. 설계 변경으로 이전에 승인된 라우팅이 무효화될 수도 있습니다.

이 모든 것은 테이블로 표현할 수 있지만, 로직이 보고서, SQL 쿼리, 스프레드시트, 로컬 예외 목록에 흩어지는 경우가 많습니다. 그러면 서로 다른 보고서들이 같은 공장 관계를 제각각 재구성하게 됩니다.

산업용 모델은 공유된 관계 계층을 제공하여, 어려운 생산 질문이 나올 때마다 매번 다시 찾아내는 대신 규칙을 한 번 정의하고, 거버넌스하고, 재사용할 수 있도록 합니다.

PPR — 제품, 공정, 자원

실무적인 출발점 구조는 PPR, 즉 Product(제품), Process(공정), Resource(자원)입니다.
제품은 "무엇을 만들고 있는가?"에 답합니다.
공정은 "작업이 어떻게 이루어져야 하는가?"에 답합니다.
자원은 "실제 생산 조건에서 그 작업을 무엇이 수행할 수 있는가?"에 답합니다.

PPR은 고립된 기록들을 생산 모델로 연결하는 단순한 뼈대를 제공합니다. 전사 전체를 한 번에 모델링하려 하지 않고, 작업이 실제로 가능한지를 결정하는 관계에 초점을 맞춥니다.

제품은 품번 이상의 의미
제품 정의에는 제품군, 특정 변형(variant), 리비전, BOM, 고객 구성, 자재 요건, 검사 요건, 품질 규칙이 포함될 수 있습니다.
이것이 중요한 이유는 같은 대분류 품번을 가진 두 기록이 상호 교환 가능하지 않을 수 있기 때문입니다. 새 리비전은 더 엄격한 공차, 다른 공정 파라미터, 추가 검사 단계, 더 높은 능력의 설비를 요구할 수 있습니다.

PLM 같은 엔지니어링 시스템은 설계 의도를 소유할 수 있습니다. ERP는 자재 마스터와 계획 버전을 보유할 수 있습니다. MES는 생산 정의를 보유할 수 있습니다. 품질 시스템은 검사 계획을 관리할 수 있습니다.
산업용 모델은 이러한 참조들을 연결하여, 생산이 "이 품번은 무엇인가?"보다 훨씬 중요한 질문에 답할 수 있게 합니다.

그 질문은 이것입니다. 현재 적용되는 규칙 아래에서 올바른 리비전을 만들고 있는가?

공정은 작업이 어떻게 이루어져야 하는지를 정의
공정 측면은 생산을 거치는 승인된 경로를 기술합니다. 이는 설비 목록 이상의 것을 포함합니다.

공정 순서, 셋업 요건, 검사 지점, 대기 시간, 재작업 경로, 승인, 인계, 작업이 계속되기 전에 충족되어야 하는 조건을 기술할 수 있습니다.
계획된 공정 정의는 작업이 어떻게 이루어져야 하는지를 설명하고, MES 실행 데이터는 특정 주문에 대해 실제로 무슨 일이 일어났는지를 기록합니다.
둘 다 중요합니다.

계획된 공정이 없으면 실행이 승인된 경로를 따랐는지 판단할 수 없습니다. 실행 이력이 없으면 생산 중 실제로 무슨 일이 일어났는지 알 수 없습니다.

자원은 설비가 아니라 능력을 의미
생산 자원은 설비, 라인, 작업대, 도구, 지그, 작업자, 테스트 리그, 운반 시스템, 또는 작업 수행에 필요한 기타 능력이 될 수 있습니다.
이 구분은 매우 중요합니다. 설비는 기술적으로 가용하더라도 공정은 여전히 불가능할 수 있기 때문입니다.

필요한 지그가 다른 곳에서 사용 중일 수 있습니다. 도구가 교정 기한을 넘었을 수 있습니다. 현재 교대에 유일한 자격 작업자가 없을 수 있습니다. 설비가 제품군은 지원하지만 현재 리비전은 지원하지 않을 수도 있습니다.