기업 데이터 온톨로지란? 문서·ERP 사례로 이해하기

기업 데이터 온톨로지는 현실의 대상과 관계를 데이터로 표현하기 위한 공통 모델입니다. 어떤 종류의 대상을 다루는지, 각 대상에는 어떤 속성이 있는지, 서로 어떻게 연결되는지를 정의합니다. 제품과 설비, 고객과 조직, 문서와 업무 프로세스까지 다룰 수 있습니다.

자료가 많이 모여 있다고 업무 전체가 보이는 것은 아닙니다. 어떤 설비의 상태가 어느 작업에 영향을 주는지, 어떤 제품이 주문과 연결되는지, 어느 팀이 업무를 맡고 어떤 지침을 따르는지는 데이터 항목만으로 드러나지 않을 수 있습니다. 온톨로지는 이 의미와 연결을 명시하는 데 쓰입니다.

대상·속성·관계·기준으로 이해하기

구성	정하는 내용	예시
대상	다루는 종류와 의미	제품, 설비, 조직, 업무, 문서
속성	대상을 설명하는 정보	위치, 수량, 상태, 시점
관계	대상들이 연결되는 방식	작업에 쓰이는 설비, 주문에 포함된 제품
기준	함께 이해할 의미와 조건	완료의 의미, 대상 구분, 관계의 적용 조건

‘설비’라는 종류를 정의하는 것과 ‘설비 B’라는 실제 기록을 연결하는 것은 구분할 수 있습니다. 먼저 공통 의미를 정하고, 그 모델에 맞춰 실제 자료를 연결합니다. W3C OWL 2는 이를 형식적으로 표현하는 언어의 한 예입니다. 기업의 모든 온톨로지가 OWL을 사용해야 하는 것은 아닙니다.

특정 산업이나 데이터에 한정되지 않습니다

모델에 담을 대상과 관계는 업무 질문에 따라 달라집니다. 시설 운영에서는 자산·작업·점검 이력을, 제품 공급에서는 공급사·제품·재고·주문을, 조직의 지식 활용에서는 업무·담당 조직·지침을 연결할 수 있습니다. 제조 공정이나 서비스 처리 과정처럼 여러 단계로 이루어진 프로세스도 단계, 순서, 투입 대상과 상태를 모델링하는 방식으로 다룰 수 있습니다.

이 모델은 관련 근거를 찾고 상태나 영향을 분석하는 기반이 될 수 있습니다. 다만 모델을 만들었다고 분석, 예측이나 업무 실행 기능까지 자동으로 생기지는 않습니다. 필요한 데이터와 활용 기능은 따로 설계해야 합니다.

회사마다 설명이 다른 이유

온톨로지의 공통 핵심은 의미와 관계를 정의하는 모델입니다. 제품에 따라 이 말에 포함하는 기능 범위는 달라집니다. 예를 들어 팔란티어의 Ontology는 데이터와 모델을 실제 업무의 대상에 연결하고, 액션과 함수 등 업무 실행 기능까지 포괄합니다. 온톨로지라는 이름만으로 특정 플랫폼의 기능 전체를 기대하기보다는 모델링, 연동, 분석과 실행 범위를 나누어 확인하는 것이 좋습니다.

문서·ERP로 보는 한 가지 활용 예시

가상 고객 A의 설비 개선 프로젝트를 생각해 보겠습니다. 계약서에는 고객 A라는 이름이 있고, ERP에는 거래처 C-104라는 코드가 있습니다. 프로젝트 목록과 센서 부품 발주 내역은 다른 화면에 보관돼 있습니다.

자료	기록된 대상	먼저 확인할 항목
유지보수 계약서	고객 A, 계약 조건	고객 식별자, 계약 버전과 유효기간
ERP 거래처 목록	거래처 C-104	공식 명칭과 공통 식별자
프로젝트 목록	설비 개선 프로젝트	관련 계약과 담당자
ERP 발주 내역	센서 부품 발주	프로젝트 코드, 품목과 검수 상태

이름이 비슷하다고 자동으로 동일 고객으로 처리하면 다른 법인이나 지점을 잘못 연결할 수 있습니다. 공통 거래처 코드, 사업자 식별자 또는 관리자가 승인한 대응표처럼 무엇을 동일 대상의 근거로 사용할지 먼저 정해야 합니다.

이 사례의 질문은 단순히 발주 내역을 찾는 데서 끝나지 않습니다. **“이 발주가 연결된 프로젝트와 적용할 계약 조건은 무엇인가?”**를 확인하려면 대상의 식별과 관계, 원문 자료가 함께 필요합니다. 모든 기록은 설명을 위한 가상 예시입니다.

이 예시에서 정의할 내용

대상과 속성은 고객, 계약, 프로젝트, 발주와 담당자, 그리고 계약 버전·유효기간·발주 상태 같은 정보입니다. 각 대상의 의미와 구분 기준을 정합니다.

관계는 대상이 이어지는 방식입니다. 고객이 계약을 체결하고, 프로젝트가 계약에 따라 진행되며, 발주가 프로젝트에 속한다는 관계를 정의할 수 있습니다. 관계를 표시할 때 연결의 근거와 유효 시점도 함께 고려해야 합니다.

기준은 의미를 해석하고 결과를 확인할 조건입니다. 어떤 계약 버전을 적용할지, ‘검수 완료’를 어느 기록으로 확인할지, 관계가 불명확하면 누가 검토할지를 정합니다.

거래처의 동일성을 확인하는 것은 이 예시의 한 부분입니다. 온톨로지의 목적이 중복 고객을 찾는 데 한정되는 것은 아닙니다. 연결된 업무와 적용 조건을 함께 이해할 수 있도록 모델을 정하는 것이 핵심입니다.

용어집이나 데이터 연결만으로 충분할 때도 있습니다

같은 단어의 정의를 공유하는 것이 목적이라면 용어집부터 시작할 수 있습니다. 정형 보고서의 집계 기준을 맞추려면 지표 정의와 데이터 모델 정리가 더 직접적인 과제일 수 있습니다.

여러 자료를 넘나드는 질문에서 대상의 동일성과 관계, 예외를 반복적으로 확인해야 한다면 온톨로지 적용을 검토할 이유가 있습니다. 처음부터 회사 전체를 모델링하기보다 고객·계약·발주 같은 하나의 업무 범위를 선택하는 것이 검증 기준을 세우기 쉽습니다.

관계를 정의했다고 답변이 보장되지는 않습니다

오래된 계약, 잘못된 거래처 대응표, 누락된 프로젝트 코드는 관계 모델을 만들더라도 남는 문제입니다. 연결이 없는 것과 관련 자료를 아직 확인하지 못한 것도 구분해야 합니다.

원문 출처, 갱신 시점과 사용자 권한은 별도로 확인해야 합니다. 예를 들어 프로젝트를 볼 수 있다는 이유만으로 그 프로젝트의 제한된 계약 문서까지 노출할 수는 없습니다. 결과의 정확성은 모델의 표현뿐 아니라 실제 데이터와 검색·검증 방식에 영향을 받습니다.

도입 검토를 시작할 때 준비할 것

한 가지 업무 질문, 그 질문에 필요한 자료 목록, 대상들을 연결할 식별자, 기준을 확인할 담당자를 준비하세요. ‘센서 부품 발주에서 프로젝트와 계약 조건을 찾는다’처럼 범위를 구체적으로 적으면 어떤 연결이 필요한지 논의하기 좋습니다.

온톨로지·지식 그래프·RAG의 차이와 온톨로지 도입 준비 체크리스트를 함께 읽어보세요. Wissly 온톨로지 Beta에서는 자산·운영, 제품·공급, 조직·지식의 활용 예시와 적용 검토 항목을 안내합니다.