온톨로지
온톨로지는 제품 · 공정 · 원가의 관계와 판단 규칙을 시스템에 정의하는 일입니다
공장은 재고를 수량으로 세고, 회계는 재고를 금액으로 적습니다. 같은 자재인데 두 시스템 안에서는 남남입니다. 이 둘을 같은 것으로 시스템에 묶어 두는 작업이 온톨로지입니다. 그래야 “재료비가 왜 늘었나”를 물었을 때 시스템이 답할 수 있습니다.
온톨로지는 IT 부서의 프로젝트가 아닙니다. 경영진이 “우리 회사는 이렇게 판단한다”를 시스템에 남기는 일입니다.
완벽한 시스템이 왜 안 쓰였나
품목·주문·매출을 빠짐없이 담은 시스템을 만들고도 “매출이 왜 떨어졌나” 앞에서 멈추는 회사가 많습니다. 설계가 데이터 항목에서 출발했지, 현장의 질문에서 출발하지 않았기 때문입니다.
데이터 항목에서 출발하면
- 품목, 빠짐없이 담음
- 주문, 빠짐없이 담음
- 매출, 빠짐없이 담음
- 설비 이력 · 교대 조 · 날씨, 설계에 없음
“매출이 왜 떨어졌나”
시스템이 여기서 멈춥니다
현장의 질문에서 출발하면
“이 라인은 왜 월말마다 불량이 늘까”
생산반장“장마철 수율은 왜 떨어질까”
품질 담당시스템이 진짜 문제를 짚기 시작합니다
DARVIS 구축이 데이터 연결보다 현장 인터뷰를 먼저 하는 이유가 여기 있습니다.
현장을 가장 잘 아는 사람이 설계에 들어오지 않은 온톨로지는 가장 먼저 버려집니다.
흔한 오해와, 다시 세운 정의
| 통념 | 다시 세운 정의 |
|---|---|
| 데이터를 통합하는 기술 | 조직의 사고방식을 고정하는 구조 |
| 많이 모으는 기술 | 먼저 정하는 기술 |
| 문서·산출물 | 합의의 결과 |
| 지식의 저장소 | 현실을 복제한 디지털 트윈 |
| 데이터 모델 | 미래 AI 에이전트의 헌법 |
전사 통합보다 관계 연결이 먼저입니다
전사 데이터 통합부터 시작하면 대개 멈춥니다. 원문이 권하는 출발점은 다섯 가지 관계이고, 대부분의 기업은 ①에서 시작합니다.
①고객 → 행동 → 매출
마케팅이 활동량이 아니라 매출 기여도로 평가됩니다. 영업 보고가 성과 설명에서 전환 구조 분석으로 바뀝니다.
②사건 → 비용
회계는 결과를 기록하지만 원인을 설명하지 않습니다. 즉시비용과 지연비용, 직접비용과 기회비용을 갈라 연결하면 비용 관리가 사후 보고에서 사전 판단으로 옮겨 갑니다.
③결정 → 가정 → 결과
가장 중요한데 가장 자주 사라지는 관계입니다. 왜 그렇게 결정했는지를 객체로 저장하면 시스템이 조직의 기억이 됩니다.
④리스크 → 확률 → 손실
어떤 부서는 리스크를 가능성으로, 어떤 부서는 비용으로 봅니다. 확률과 영향으로 구조화하면 리스크 관리가 감이 아니라 계산이 됩니다.
⑤현재 상태 → 변화 추세 → 미래 결과
설비 상태와 고장 확률, 재고 수준과 납기 실패 확률처럼 시계열 데이터가 온톨로지와 만나는 지점입니다.
데이터를 많이 모은 회사보다, 가장 중요한 관계를 먼저 정해 둔 회사가 AI를 제대로 씁니다.
우리 회사는 어느 쪽인지, 14문항 자가진단
7개 영역에서 우리 회사에 더 가까운 쪽을 고르세요. 결과는 연락처 없이 이 자리에서 바로 보여드립니다.
01문제 인식
02문제 인식
03데이터·보고서
04데이터·보고서
05임원 회의
06임원 회의
07원인 분석
08원인 분석
09AI·시스템
10AI·시스템
11위기 대응·조직 학습
12위기 대응·조직 학습
13CEO 체감
14CEO 체감
시작을 미루게 하는 다섯 가지 착각
다섯 번째가 가장 위험합니다. 도입을 가장 오래 미루게 하기 때문입니다.
- “IT 프로젝트다”조직 사고 체계의 문제다
- “데이터가 부족하다”연결이 부족한 것이다
- “ROI가 불명확하다”리스크를 없애는 것이 곧 ROI다
- “복잡해서 현업이 못 쓴다”현업 언어를 구조화하는 일일 뿐이다
- “지금 안 해도 된다”격차가 누적된다
원문은 ROI 반론에 이렇게 답합니다. “온톨로지의 ROI는 벌어서 증명되는 게 아니라 잃지 않아서 증명된다.” 숫자로 먼저 잡히는 것은 조사 시간입니다. 원인 하나를 찾는 데 몇 주 걸리던 일이, 관계가 고정된 뒤에는 조회 몇 분으로 끝납니다.
무엇부터 할지, 실행 3원칙
한 번에 하나의 질문만 고정하라
우리 회사가 매일 반복해서 묻는 질문은 무엇인가.
데이터보다 판단 기준을 먼저 정합니다
숫자는 나중에 붙어도 됩니다.
회의에서 부딪히는 주제부터 시스템에 넣습니다
부서마다 해석이 갈리는 주제가 먼저 정의해야 할 관계입니다.
고정한 관계는 화면에 이렇게 남습니다
여기까지는 개념이고, 아래는 그 개념이 도구 안에서 무엇이 되는지입니다. 엔티티(제품·공정 같은 대상)를 누르면 속성과 관계, 그 엔티티를 조건으로 읽는 규칙이 함께 바뀝니다. 규칙까지 같은 자리에서 함께 움직입니다. 온톨로지가 문서에 그치지 않고 실행되는 시스템이라는 말의 뜻이 이 화면에 있습니다.
노드를 누르면 직접 연결된 관계만 남습니다. 판단(주장) 하나에 증거·반례·규칙·검토가 어떻게 물려 있는지가 구조로 보입니다.
두 손가락으로 확대·축소, 끌어서 이동합니다.
가상 제조사의 예시 모델입니다. 실제 구축에서는 회사가 매일 묻는 질문이 무엇이냐에 따라 엔티티도 규칙도 달라집니다.
큐레이션 · 검증
원천을 Core 에 맞추고, 손실까지 검증합니다
ERP · MES · 문서가 서로 다르게 부르는 용어를 하나의 기준(Core)으로 정리합니다. 매핑마다 방식·손실률·승인 상태가 남고, 검증 게이트를 통과해야 모델에 반영됩니다.
먼저 읽을 것과, 그다음에 할 것
여기까지가 개념입니다. 실제로 회사에 적용할 때 무엇을 준비하고 어떤 순서로 가는지는 착수 가이드에 정리해 뒀습니다. 간단한 정보를 남기시면 바로 열립니다.
DARVIS 가 이 관계 구조를 제조 현장의 원가·손익 질문 위에 얹은 제품입니다.온톨로지 자동 구축이 실제로 어떻게 도는지 보기 →