온톨로지

온톨로지는 기술이 아니라, 회사가 판단하는 방식입니다

문서·행·컬럼이 아니라 관계를 일급 시민으로 올리는 것. 그게 온톨로지의 정의입니다. 도구를 고르기 전에 정해야 할 것이 있고, 그 순서를 뒤집으면 데이터를 아무리 모아도 판단은 그대로입니다.

온톨로지는 IT 프로젝트가 아니다. 그것은 리더가 “우리 회사는 이렇게 판단한다”라고 선언하는 행위다.온톨로지 책 p.261

흔한 오해와, 원문이 다시 세운 정의

전사 데이터 통합부터 시작하면 대개 멈춥니다. 원문이 권하는 출발점은 다섯 가지 관계이고, 대부분의 기업은 ①에서 시작합니다.

①고객 → 행동 → 매출

마케팅이 활동량이 아니라 매출 기여도로 평가됩니다. 영업 보고가 성과 설명에서 전환 구조 분석으로 바뀝니다.

②사건 → 비용

회계는 결과를 기록하지만 원인을 설명하지 않습니다. 즉시비용과 지연비용, 직접비용과 기회비용을 갈라 연결하면 비용 관리가 사후 보고에서 사전 판단으로 옮겨 갑니다.

③결정 → 가정 → 결과

가장 중요한데 가장 자주 사라지는 관계입니다. 왜 그렇게 결정했는지를 객체로 저장하면 시스템이 조직의 기억이 됩니다.

④리스크 → 확률 → 손실

어떤 부서는 리스크를 가능성으로, 어떤 부서는 비용으로 봅니다. 확률과 영향으로 구조화하면 리스크 관리가 감이 아니라 계산이 됩니다.

⑤현재 상태 → 변화 추세 → 미래 결과

설비 상태와 고장 확률, 재고 수준과 납기 실패 확률처럼 시계열 데이터가 온톨로지와 만나는 지점입니다.

원문 p.257–261. “지능형 기업은 데이터를 많이 가진 기업이 아니다. 가장 중요한 관계를 가장 먼저 고정한 기업이다.”

7개 영역에서 더 자주 일어나는 쪽을 고르세요. 정답은 없고 연락처도 묻지 않습니다. 원문 자가진단표(온톨로지 책 p.231–233)를 그대로 옮겼습니다.

0 / 14

원문 p.274–277. 다섯 번째가 가장 위험한 착각으로 지목됩니다.

원문은 ROI 반론에 이렇게 답합니다 — “온톨로지의 ROI는 벌어서 증명되는 게 아니라 잃지 않아서 증명된다.”

01

한 번에 하나의 질문만 고정하라

우리 회사가 매일 반복해서 묻는 질문은 무엇인가.

02

데이터가 아니라 판단을 먼저 구조화하라

숫자는 나중에 붙어도 됩니다.

03

회의에서 싸우는 주제를 시스템에 먼저 넣어라

가장 시끄러운 주제가 가장 가치 있는 관계입니다.

여기까지는 개념이고, 아래는 그 개념이 도구 안에서 무엇이 되는지입니다. 엔티티를 누르면 속성과 관계, 그 엔티티를 조건으로 읽는 규칙이 함께 바뀝니다. 규칙까지 같은 자리에 있다는 것 — 그게 “문서가 아니라 실행되는 시스템”이라는 말의 뜻입니다.

DARVIS Ontology Studio가상 제조사 (주) · Manufacturing 도메인 · v1.2

Read-Only예시 — 가상 데이터

선택연결엔티티 추가관계 추가100%

엔티티를 누르면 속성 · 관계 · 그 엔티티를 쓰는 규칙이 함께 바뀝니다 — 지금은 「Inventory」.

가상 제조사의 예시 모델입니다. 실제 구축에서는 회사가 매일 묻는 질문이 무엇이냐에 따라 엔티티도 규칙도 달라집니다.

여기까지가 개념입니다. 실제로 회사에 적용할 때 무엇을 준비하고 어떤 순서로 가는지는 착수 가이드에 정리해 뒀습니다. 연락처를 남기지 않아도 바로 받을 수 있습니다.

DARVIS 가 이 관계 구조를 제조 현장의 원가·손익 질문 위에 얹은 제품입니다 — 온톨로지 자동 구축이 실제로 어떻게 도는지.