온톨로지가 관계까지는 잇는데, 시간에서 깨집니다

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

그런데 그 다음에 조용히 깨지는 자리가 있습니다. 시간입니다.

관계는 제대로 잡혔는데 추적이 안 되거나, 지난달 판정이 왜 그렇게 나왔는지 재현이 안 되거나, 계획과 실적의 편차가 어느 순간 사라져 있는 식입니다. 원인은 대개 하나입니다. 객체마다 시간이 다르게 흘러야 하는데 전부 같은 규칙으로 다뤘기 때문입니다.

먼저 객체를 여섯 개로 줄입니다

시간 이야기를 하려면 무엇에 시간이 붙는지부터 정해야 합니다. 공장 운영을 문장으로 쓸 수 있는 최소 객체는 여섯 개입니다.

여섯 개가 최소이자 최대인 이유는 단순합니다. 앞 글에서 정리한 다섯 가지 일을 전부 이 여섯으로 쓸 수 있고, 하나라도 빼면 그중 한 문장이 써지지 않습니다. 반대로 흔히 추가하는 것들 — 고객, 공급사, 창고, 라인, 비용 — 은 전부 위 여섯의 하위 유형이거나 관계에 붙는 값이라 별도 객체가 필요 없습니다.

자원의 성질 하나만 짚고 갑니다. 자원은 저장되지 않습니다. 오늘 쓰지 않은 설비 시간은 내일로 넘어가지 않고 그냥 사라집니다. 품목은 보존되는데 자원은 증발한다는 이 차이가 계획과 재고를 서로 다른 문제로 만듭니다.

시간이 셋 다 다릅니다

여섯 중 셋이 시간을 서로 다르게 다룹니다. 이걸 같게 만들면 반드시 사고가 납니다.

약속은 여섯 중 유일하게 미래를 담습니다. 주문도 작업지시도 구매발주도, 아직 일어나지 않은 일에 대한 확정입니다.

사건은 유일하게 과거만 담고, 수정되지 않습니다. 실적·정지·불량·판정은 이미 일어난 일이라 고칠 수 있는 대상이 아닙니다. 정정이 필요하면 원래 사건을 고치는 것이 아니라 정정이라는 새 사건을 하나 더 남깁니다.

기준은 유일하게 시간이 없습니다. 규격은 "언제의 규격"이 아니라 그냥 규격입니다. 대신 유효일자를 갖습니다. 2월 3일부터 이 규격, 그 전까지는 저 규격.

이 셋을 지키지 않으면 아래 세 가지가 순서대로 일어납니다.

사건을 고칠 수 있게 만들면 증명이 죽습니다. 실적을 나중에 수정할 수 있는 시스템은 추적성을 제공하지 못합니다. 기록이 언제든 바뀔 수 있다면 그 기록으로는 아무것도 증명하지 못하니까요. 화면에서 실적 수량을 직접 고칠 수 있는지 한 번 확인해 보시면 됩니다.

기준에 유효일자가 없으면 과거 판정을 재현하지 못합니다. 규격을 덮어써 버리면 "그때 그 판정이 옳았는가"를 물을 방법이 없습니다. 자재명세서도 마찬가지입니다. 개정을 유효일자나 시리얼 단절점 없이 덮어쓰면 자동 피킹이 신제품에 구자재를 집어넣고, 나중에 품질 사고가 났을 때 어느 물량부터 섞였는지를 특정하지 못합니다.

약속과 사건을 같은 표에 넣으면 편차가 사라집니다. 계획 수량 칸을 실적으로 덮는 순간 "얼마나 어긋났는가"가 없어지고, 편차가 없어지면 표준시간을 고칠 근거도 함께 없어집니다. 그러면 스케줄러가 지키지 못할 계획을 계속 뿌리고, 사람이 매일 엑셀로 다시 짭니다.

방향은 곧 금지입니다

관계에는 방향이 있고, 방향의 진짜 역할은 역방향을 금지하는 것입니다.

공정이 품목을 소비하지, 품목이 공정을 소비하지 않습니다. 작업지시가 고객주문을 이행하지, 그 반대가 아닙니다. 지시는 의도이고 사건은 사실이라, 사건이 지시를 증명하지 지시가 사건을 증명하지 않습니다.

그중 실무에서 가장 자주 뒤집히는 방향이 하나 있습니다.

기준이 사건을 판정합니다. 사건이 기준을 판정하지 않습니다.

그런데 현장에서는 나온 결과에 맞춰 규격을 조정하는 일이 생깁니다. 한 번은 특채로, 두 번은 관행으로. 온톨로지에서 방향을 고정해 두면 그때마다 예외 기록이 남습니다. 막아 주지는 못하지만, 몇 번 일어났는지는 셀 수 있게 됩니다.

두 가지 함정

관계 이름은 저절로 늘어납니다. 문서에서 자동으로 관계를 뽑으면 같은 뜻인데 이름만 다른 관계가 쌓입니다. has_customer와 is_customer_for는 결국 "주문과 고객의 관계" 하나인데 둘로 존재합니다. 공개된 실습 사례에서 관계 타입을 정리하자 15종이 4종으로 줄었습니다. 3분의 2 이상이 중복이었다는 뜻입니다. 새 관계를 만들기 전에 기존 관계에 값을 하나 붙이면 되는 것은 아닌지 먼저 보시는 편이 좋습니다.

그리고 그보다 앞에 채번이 있습니다. 같은 설비가 ERP·MES·설비보전·에너지 시스템에서 각각 다른 번호로 존재하면, 온톨로지는 그 넷을 서로 다른 설비로 봅니다. 이걸 나중에 합치는 일은 실무적으로 거의 불가능합니다. 어느 것과 어느 것이 같은 실물인지를 알고 있는 사람이 하나씩 짝지어 주는 수밖에 없기 때문입니다. 온톨로지 이전에 식별자입니다.

그래서 왜 표가 아니라 그래프인가

표로 충분하다면 이 고생을 할 이유가 없습니다. 근거를 하나 붙여 두겠습니다.

기업 데이터베이스 질의 벤치마크(Sequeda 외, arXiv:2311.07509 → ACM GRADES-NDA 2024)에서, 대규모 언어모델이 관계형 데이터베이스에 직접 질의했을 때 정확도는 16.7%, 지식그래프를 거쳤을 때는 54.2% 였습니다. 그리고 차이가 벌어지는 구간은 질문의 어려움이 아니라 스키마의 복잡도였습니다. 답을 내는 데 테이블이 5개를 넘게 필요하면 직접 질의 정확도는 0%로 떨어집니다.

공장 질문은 거의 전부 그 구간에 있습니다. "이 설비가 서면 어느 고객의 어느 주문이 며칠 뒤 밀리나"는 자원·공정·품목·자재명세서·재고·지시·약속 일곱 개를 지납니다.

다만 인용할 때 반드시 함께 적어야 할 것이 있습니다. 54.2%는 절반이 틀린다는 뜻이고, 이 벤치마크의 저자들은 지식그래프 제품을 만드는 회사 소속이며, 문항은 43개에 도메인은 보험 하나입니다. 온톨로지는 답을 맞히게 하는 장치가 아니라 질문이 성립하게 하는 장치입니다. 이 구분을 흐리면 "온톨로지를 붙이면 AI가 틀리지 않는다"는 잘못된 기대로 돌아갑니다.

정리하면

• 객체는 여섯이면 됩니다 — 자원·품목·공정·약속·사건·기준.

• 시간이 셋 다 다릅니다. 약속은 미래, 사건은 과거이며 수정 불가, 기준은 시간 밖이고 유효일자로만 바뀝니다.

• 사건을 고칠 수 있게 만들면 증명이 죽고, 기준에 유효일자가 없으면 과거 판정을 재현하지 못하며, 약속과 사건을 한 표에 담으면 편차가 사라집니다.

• 관계 이름은 저절로 늘어납니다. 그리고 그보다 먼저 식별자를 정리해야 합니다.

다음 글에서는 여섯 개를 다 만들고도 여전히 물어볼 수 없는 질문 하나를 다룹니다.

관련 글: 공장을 이루는 것을 하나씩 지워 봤습니다 · 데이터가 모자란 게 아니라 따로 노는 거였습니다

(주)웨이스는 공장이 스스로 판단하고 멈추지 않게 하는 제조 AI 운영체제 VEXPLOR를 만듭니다. wace.me