슐라이히, 그래프 데이터 모델로 시맨틱 PDM을 구현하다

• Cypher & GQL

오늘 이야기해볼 내용은 독일 장난감 제조사 슐라이히에서 어떻게 그래프 데이터 모델을 사용해서 장난감 생산과 관련된 모든 요소를 추적하는지 알아볼 거예요.

저는 지난 25년 동안 독일에서 엔지니어로 일했고, 지난 7년은 독일 장난감 제조업체인 Schleich에서 근무했어요. 스머프처럼 유명한 장난감을 많이 만들어서, 많은 분들이 이미 이 회사에 대해 잘 알고 계실 텐데요.

저는 그곳에서 운영을 담당하면서 다양한 공장에서 나오는 데이터를 관리하고 있어요. Schleich는 독일 회사이지만, 대부분의 생산은 중국, 루마니아 등 다른 나라에서 이루어지죠. 모든 Schleich 조각상은 손으로 칠해지고, 물류, 제품 개발, 구매 등 무대 뒤에서 정말 많은 일들이 일어나고 있답니다.

아래는 전형적인 손으로 그린 Schleich 제품이에요.

Schleich는 다른 많은 회사들처럼 새로운 과제들에 직면해 있어요. 몇 년 전만 해도 주요 관심사는 제품 적합성이었죠. 그 직후에는 화학적 안전성과 화학적 위험 평가 문제가 제기되었고요. 이러한 문제들을 해결하기 위해 다양한 소프트웨어가 등장했답니다.

데이터 모델 개발

기업들은 때때로 데이터 관리에 어려움을 겪으면서 제품 개발에 집중하지 못하게 될 수 있어요. 효과적인 데이터 모델에서 매우 중요한 세 가지 주요 기능은 추적성(traceability), 추적가능성(trackability), 그리고 투명성(transparency)이에요. 이는 장난감 산업뿐만 아니라 화장품, 식품 산업에도 매우 중요하죠. 특히 소비자 안전과 관련된 규정이 관련되어 있기 때문이에요.

새로운 시스템을 만들 때 데이터 사일로를 피하기 위해 주의를 기울여야 했어요. 우리는 "이 제품에 중요한 물질, 즉 제한 화학물질이 들어있나요?"와 같은 질문에 대답하기 위해 시스템을 고안했죠. 이 질문에 효과적으로 답하려면 많은 데이터를 정렬해야 해요.

턱수염룡 장난감을 한번 살펴볼까요? 첫 번째 단계는 프로세스부터 시작하는 거예요.

• 무엇이 생산되었나요?
• 어떻게 생산되었나요?
• 어디서 생산되었나요?
• 그리고 생산에는 어떤 재료가 사용되었습니까?

이는 일반적으로 SAP 시스템에 포함되지만 ERP(Enterprise Resource Planning) 시스템에는 포함되지 않아요.

그런 다음 더 깊이 들어가 화학적 수준에서 물질을 살펴보고 실험실에서 테스트해야 하는 납, 비소 등의 물질이 있는지 확인해야 해요. 그리고 창출된 가치는 이러한 수준에 제한을 두는 입법 규칙의 적용을 받으며, 이는 지역 상황에 따라 달라지죠. 이를 위해서는 수많은 데이터 체인을 관리해야 해요.

그러기 위해서는 간단하고 비용 효율적이며 유연하고 확장 가능한 데이터 네트워크를 구축해야 해요. 이러한 네트워크를 구축할 때 고려해야 할 사항은 다음과 같아요.

첫 번째로 매우 중요한 점은 기업 전체에 걸쳐 전체 가치 사슬에 걸쳐 데이터를 수집해야 한다는 것이에요. 어떤 ERP 시스템을 사용하든 상관없이 안정적인 데이터 모델이 필요해요. 이해와 사용이 간편해야 하고, 확장 가능해야 하며, 필요에 따라 확장할 수 있어야 하죠.

그리고 결국에는 고객뿐만 아니라 정부 관계자의 질문에 답할 수 있는 모든 데이터를 확보해야 해요. 이러한 모든 요구 사항이 우리를 관계형 데이터베이스 모델에서 벗어나게 만들었어요.

Schleich는 위와 유사한 질문으로 매년 감사를 받아요. 우리는 기존 시스템을 넘어서는 개념이 필요하다는 것을 금방 깨달았죠.

우리의 주요 과제 중 하나는 다양한 회사의 여러 언어를 하나로 모으는 것이었어요.

여기에는 제품과 프로세스를 다루는 ERP 시스템의 언어와 긴 PDF 형식의 법률이 포함되어 있어요. 이 둘을 합쳐 '입법의 세계'라고 할 수 있는데, 이걸 합쳐서 국회의원들의 질문에 답할 수 있게 되는 거죠. 그리고 중요한 물질과 화학물질도 있고요. 두 개의 개별 데이터 영역을 위해 중간에 하나의 일관된 데이터 모델이 필요했던 거예요.

하지만 어디서부터 시작해야 할지 확신이 안 섰어요. PDF 파일의 경우 내용을 읽고 분석해야 하고, 수동으로 데이터를 추출해서 적어도 한 번은 데이터 모델에 넣어야 하니까요.

Schleich 온톨로지 개발

왜 의미론이냐고요? 의미론은 의미에 대한 연구잖아요. 데이터가 어떻게 하면 더 의미를 가질 수 있을까 고민한 거죠.

저희가 얻은 가장 큰 통찰력 중 하나는 관계를 기반으로 데이터 개체에 부가적인 가치가 있다는 거였어요. 즉, 관계에 집중하고 이를 전용 데이터 개체로 처리하고 이름을 지정하고, `Query` 및 비즈니스 로직에서 검색 가능하게 만들어야 한다는 거죠.

아래는 Schleich가 제품 개발부터 출시까지 어떻게 제품을 개발하는지를 그래프로 나타낸 거예요.

모든 것은 제품에 대한 파워포인트 형식의 마케팅에서 제품 아이디어로 시작돼요. 팀이 관련 데이터를 첨부하는 기존 `Node`(제품 아이디어)가 있는 거죠.

우리가 추가하는 첫 번째 것은 브리핑 보드예요. 여기에는 플레이 가치, 가격 및 시장 부문에 대한 추가 데이터가 있죠. 승인이 필요한 경우 더 자세한 개념을 생각해내고요.

엔지니어에게 중요한 데이터 입력인 이 모든 데이터는 이전에는 PowerPoint 형식으로 서버에 있었어요. 그러나 이 데이터를 동일한 장소의 다른 `Node`로 추가함으로써 엔지니어는 이 중요한 시장 데이터에 액세스하여 회사의 모든 사람이 고품질 데이터를 사용할 수 있도록 보장하는 거죠.

제품 아이디어가 승인된 후 우리는 프로젝트를 시작하고 그 결과는 제품이에요. 각 프로젝트에는 데이터 모델에 포함된 재정적 제약을 비롯한 다양한 제약 조건이 있어요. 각 프로젝트를 말과 같은 물리적 모델로 시작하여 손으로 또는 매우 전문적인 소프트웨어를 통해 모델링되었는지 확인해야 해요. 각 말 모델마다 모델러가 있으며 마감일과 모양 및 색상 승인이 있어요. 이 모든 점은 위에 보이는 `Node`에 연결되어 있죠.

독일이나 중국 등 다른 국가에서 생산되는 제품은 재료, 세부 사항 등이 다르기 때문에 다른 제품으로 간주돼요.

다음으로, 좀 더 깊이 들어가서 "이 자료는 특정 물질로 구성되어 있거나, 일부 물질을 포함하고 있다"는 정보를 추가할 수 있어요. 이걸 '실체 명세서'라고 부른답니다.

납과 같은 특정 물질에 대해 더 자세히 알아보면, 시스템에서 유럽 장난감 안전 지침 EN 71.3/3의 제한 값을 확인할 수 있다는 거죠.

이제 구성 요소에 대한 좀 더 기술적인 부분을 살펴볼까요? 해당 네트워크 내에서 접근 가능한 생산된 금형과 사출 금형 정보가 있어야 해요. 그리고 각 모델에는 여러 기술 사양과 문서들이 함께 따라오죠.

결국 생산 과정 전체가 시스템의 일부가 되는 거예요. 이렇게 해서 우리는 높은 수준의 데이터 품질을 갖춘 투명한 시스템을 완성하게 됩니다.

Semantic PDM 사용의 장점

저희는 아주 작은 규모로 시작할 수 있는 Semantic PDM(제품 데이터 관리) 시스템을 사용하기로 결정했어요. 품질 관리(QC) 부서에서 시작했는데, 그곳에서 화학자들은 열 이름을 지정하는 방식에 일관성이 없이 몇 주마다 새로운 Excel 시트를 만들고 있었거든요. 첫 번째 단계는 Schleich 특정 온톨로지를 개발하는 것이었어요.

QC 부서를 거쳐 기술 및 제품 관리 부서로 이동했는데, 여기에는 모델링할 새로운 Node와 객체를 추가하는 작업이 포함되었어요. 해당 구조를 사용하면 장비로 아주 쉽게 수행할 수 있었죠.

데이터베이스에서 답변 얻기

마케팅과 같은 제품 관리 Node에 앉아 기술적인 답변을 찾고 있다면, 이전에는 자세한 Excel 시트를 확인해서 답변을 제공하는 엔지니어에게 전화를 걸었어야 했어요.

하지만 Graph 데이터 모델을 사용하면 답은 항상 경로(path)이고, 일관된 모델이 있으면 쉽게 찾을 수 있어요.

처음 시작할 때 저희는 Oracle 데이터베이스에서 이미 SAP 형태로 제공되는 데이터를 사용하려고 했어요. 이를 위해서는 일종의 매핑을 사용하여 커넥터를 만들어야 했죠. 중국과 보스니아의 동료들은 이미 시스템 작업을 하고 있었지만 SAP에 액세스할 수 없었어요. 그들은 마이크로 애플리케이션을 통해 Excel을 통해 대화형으로 작업하고 있었고요.

마이크로 애플리케이션

매우 전용 기능을 갖춘 마이크로 애플리케이션은 매일 수백 번 발생하는 일에 특화되어 있어요. 이는 매우 작은 애플리케이션이며 해당 애플리케이션의 데이터는 온라인에 직접 배치되죠.

저희는 또한 SVHC(고위험 우려 물질) 목록을 사용하는데요. 이러한 "조심" 물질은 데이터베이스로 가져온 Excel 파일에 있어요. 그런 다음 데이터베이스에서 재료 명세서(BOM)와 물질 명세서(BOS)를 반환하려고 하는 거죠.

일반적인 회사를 보면, 여러 애플리케이션이 있고 각자 알려진 데이터베이스를 가지고 있죠. 애플리케이션이 특정 기능에 집중하기 때문에 이런 구조가 필요한 거예요.

제가 대화를 나눴던 대부분의 회사들은 추가적인 Graph Database를 마련하려고 노력하더라고요. 바로 메타데이터를 처리하기 위해서죠. 그리고 데이터 사일로와 메타데이터 사이에는 연결이 조금씩 존재해요.

그런데, 이 구조를 완전히 뒤집어보면 어떨까요?

제품 개발 프로세스 중에 데이터 네트워크 생성을 시작하면, 이미 기본적인 계층에서 Semantic한 제품 데이터 관리가 이루어지는 거죠. Schleich에서는 이 기능을 위해 Microsoft의 일부 미들웨어를 도입했대요. 패키지 형태의 기능 중심 소프트웨어 제품도 있지만, 미들웨어를 통한 데이터 인터페이스가 존재하죠.

가장 큰 장점은 필요한 PDF, Word, Excel 파일들을 시스템의 node로 간단하게 첨부할 수 있어서, 제품 개발을 위한 문서 관리 측면에서 문서 관리 시스템이 필요 없어졌다는 점이에요.

저희 QC 부서에서는 실험실 정보 관리(LIM) 시스템을 도입하고 싶어 했는데요. 대신에, 이 시스템을 위해 설계한 마이크로 애플리케이션을 통해 그들의 요구 사항을 충족할 수 있었답니다.

단순히 ERP를 사용하면 안 될까요? ERP 시스템에 모든 것이 있지 않나요?

다음 예를 한번 살펴볼까요? 제 ERP의 녹색 `Node`(아래)는 원자재를 나타내요. 하지만 저에게 원자재는 공급자를 위한 제품이고, 공급자에게 원자재는 하위 공급업체를 위한 제품이죠.

다음 두 예는 하나의 완전한 데이터 세트를 보여주지만 서로 다른 관점을 보여주는 것이죠. 다음은 우리 회사의 체인 뷰입니다.

아래는 제 하위 공급업체의 견해입니다.

그래서 ERP를 사용하는 대신 일관된 하나의 데이터 체인을 사용하면서 뷰를 변경하는 방식을 택한 거죠. 그럼 슐라이히는 왜 이런 선택을 했을까요? 여러 이유가 있어요.

일단 간단하고, 안정적이고, 이해하기 쉬워요. 제품에 대한 데이터는 앞으로 10년 동안도 지금과 크게 다르지 않을 거예요. 하지만 프로세스와 소프트웨어 측면에서 데이터를 분석하는 방식은 새로운 기술이 등장하면서 계속 발전하겠죠. 프로세스는 바뀌어도 데이터는 그대로 유지되는 거예요.

이 모델은 확장성이 뛰어나요. 처음엔 작게 시작했지만, 필요에 따라 얼마든지 확장할 수 있었죠. 우리 회사는 역할이나 위치에 상관없이 데이터에 접근할 수 있어요. 소프트웨어 공급업체, 하드웨어, SAP 업데이트에 종속되지 않고, 복사본이 아닌 원본 데이터로 작업하는 게 정말 중요해요. 데이터는 중심에 있고, 원하는 소프트웨어 패키지로 자유롭게 접근하고 조작할 수 있는 거죠.

이 모델은 협업적이고 이동성이 뛰어나서, 시간과 장소에 구애받지 않고 동시에 작업할 수 있는 환경을 제공해요. 다양한 국가에 공급망이 있는 경우 특히 중요하죠. 그리고 부하 공유는 화학 물질의 규제 한계값과 같은 특별한 주제를 다룰 때 유용해요.

Schleich 사용 사례

관련 데이터에 집중

아래는 Schleich에서 만든 장난감 중 하나인 Joe Cool의 스크린샷이에요.

왼쪽에는 제품 상세 정보가 보이고, 오른쪽에는 아코디언 상자가 있어요. Cypher 쿼리가 백그라운드에서 네트워크의 데이터를 가져오죠. 빨간색 원으로 표시된 Den 73을 클릭하면 관련 설명 경로를 보여줘요.

이 장난감에 사용된 그림 색상은 그래프에 표시되어 있는데, 그 중 일부에는 법적 한계값이 있는 중요 물질인 화학적 사이클로헥사놀이 포함되어 있어요. 이건 제 전체 데이터 네트워크 중 하나의 경로일 뿐이지만, 저에게 필요한 유일한 정보였다는 점을 기억하는 게 중요하죠.

데이터를 저장할 위치

저는 종종 사람들로부터 데이터베이스의 데이터를 어디에 저장할 것인지 묻는 질문을 받아요. 제가 답변을 주지 않으면 결국 자신의 컴퓨터에 저장하는 Excel에 답변을 넣게 되죠. 팀이 데이터를 어디에 배치할지 이해하는 것이 정말 중요한 이유예요.

Schleich의 각 제품에는 프랜차이즈, 예측 및 출시 데이터와 함께 카탈로그 번호와 가격이 있어요. 제품 버전과도 1:N 관계를 맺고 있고요.

다시 말하지만, 제품 버전은 구체적인 "made in China" 제품이에요. 여기에서 QC, 공급업체, 포장, 라벨, 모델 및 부품에 대한 모든 비용, 테스트 시나리오를 찾을 수 있죠. 앞서 언급했듯이 모든 제품에는 제품 버전의 기반이 되는 제품 모델과의 연결도 있으며 모델러, 페인팅 지침 등과 같은 더 많은 세부 정보가 있어요.

모든 데이터가 모델에 입력되면 광범위한 승인 프로세스를 거쳐요. 출시일부터 비용까지 모든 것이 승인되어야 하죠.

패키지 라벨처럼 단순해 보이는 것도 모든 구성 요소(포일과 접착제의 화학 성분, 바코드)가 승인을 받아야 하기 때문에 광범위한 승인 프로세스를 거쳐요. 이러한 모든 승인은 아래 확인 표시로 표시되어 있답니다.

우리 데이터베이스에는 Node가 선택되면 관련된 모든 승인에 대한 개요를 제공하는 "승인" 탭도 포함되어 있어요.

제품 전체에 사용된 소재와 색상을 자세히 살펴보면서 모든 승인을 모을 수 있어요. 초록색 거품은 해당 구성 요소가 승인되었음을 나타내죠. 그런 다음 해당 초록색 거품을 가져와 전체 BOM 구조를 열어볼 수 있고요.

오른쪽에는 BOM 데이터를 입력하고 관리하기 위해 만든 마이크로 애플리케이션의 일부가 표시되어 있네요.

상황 기반 문서 관리

문서 관리를 제거한 이유는 다음과 같아요.

아래에는 "문서" `Node` 유형이 있어요. Schleich는 공급업체가 우리에게 배송한 제품(예: 안료)에 대한 약속이 포함된 설문지를 보냈어요. 이제부터 해당 `Node`에 연결된 모든 `Property`, 매개변수 및 추가 데이터를 사용하여 문서를 찾을 수 있는 거죠.

공급업체나 안료 B로 이동하면 설문지 문서에서 단 한 번의 클릭만으로 이동할 수 있어요. 메타데이터를 관리해야 하는 별도의 사용자 인터페이스를 갖춘 별도의 문서 관리 시스템을 사용하는 것보다 훨씬 효율적이죠.

엔지니어들은 특정 기간(예: 2016년 1월) 동안 제품 출시 상태를 추적할 수 있는 "작업 목록"이라는 BOM 승인 목록과 유사한 목록을 만들었어요.

신제품 출시 컬럼이 있고, 필터를 설정해서 제품, 금형, 사출금형을 모두 볼 수 있어요. 9월에 완료될 예정이었던 세트에 작은 플라스틱 부품을 넣을 예정인데, 마케팅 담당자가 7월에 출시하기를 원하면 보류될 것이기 때문에 이는 중요해요. 빨간색 거품으로 표시된다고 하네요.

권장사항

 

다음은 자신만의 사용자 인터페이스를 개발할 때 권장되는 사항들이에요.

This Schleich에서 잘 작동했어요. 앞으로의 작업은 유사한 개념을 구현하는 데 중점을 둘 거라고 해요. 다른 회사들도 이 컨셉을 따라갔으면 좋겠네요.

Weber 박사의 강연에서 영감을 받으셨나요? 이 백서를 통해 Neo4j가 글로벌 기업의 마스터 데이터 관리(MDM) 솔루션을 어떻게 강화하는지 자세히 알아보려면 아래를 클릭하세요.마스터 데이터에 대한 재고: 연결이 MDM의 미래를 정의하는 방식

• 그래프 데이터 모델
• 제품 데이터 관리
• SAP

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지