온톨로지 도입 전 확인할 데이터와 업무 기준
기업 온톨로지 도입 전에 업무 목표, 대상과 속성, 데이터 출처, 관계, 기준, 권한과 갱신 방식을 점검하세요. 운영 데이터와 문서·ERP 예시의 평가 항목도 함께 정리합니다.
온톨로지 도입 검토는 회사 전체의 데이터를 모으는 일보다, 해결할 업무 질문 하나를 정하는 데서 시작하는 것이 좋습니다. 질문에 필요한 대상, 관계, 업무 기준과 실제 자료를 함께 확인해야 연결의 유용성을 평가할 수 있습니다.
질문은 ‘이 자산과 연결된 작업과 이력은 무엇인가’, ‘공급 상태가 바뀌면 어떤 주문을 확인해야 하나’, ‘이 업무는 누가 맡고 어떤 지침을 따라야 하나’처럼 다양할 수 있습니다. 산업보다 업무 목표가 먼저이며, 대상의 상태나 프로세스 변화를 다룬다면 시간과 갱신 방식도 함께 살펴봐야 합니다.
아래에서는 하나의 구체적인 예시로 가상 고객 A의 설비 개선 프로젝트를 사용합니다. **“이 센서 부품 발주가 연결된 프로젝트와 적용할 계약 조건은 무엇인가?”**를 확인하기 위해 계약서, ERP 거래처 C-104, 프로젝트 목록과 발주 내역을 살펴봅니다. 이 사례는 설명을 위한 것이며, 점검 항목은 자산·제품·조직·프로세스 등 다른 대상에도 맞춰 적용할 수 있습니다.
1. 질문과 확인할 결과를 정합니다
‘회사 데이터를 모두 연결한다’는 목표는 범위와 완료 기준을 정하기 어렵습니다. 어떤 발주에서 어느 프로젝트와 계약 조건을 확인할지처럼 질문을 구체화하세요.
결과에 필요한 항목도 적어야 합니다. 프로젝트 식별자, 적용 계약 버전, 관련 조항, 발주 담당자와 원문 위치가 필요한지 정합니다. 결과를 확인할 사람과 승인 기준을 함께 지정하면 PoC에서 서로 다른 기대를 줄일 수 있습니다.
2. 데이터 목록과 책임자를 확인합니다
| 확인할 항목 | 준비할 내용 | 예시 |
|---|---|---|
| 데이터 출처 | 시스템, 문서 위치, 접근 방법 | ERP 발주 내역과 유지보수 계약서 |
| 대상과 속성 | 대상의 종류, 상태와 필요한 정보 | 제품, 작업, 위치, 수량, 진행 상태 |
| 식별자 | 대상별 고유 코드와 대응 기준 | 거래처 C-104, 프로젝트 코드 |
| 관계의 근거 | 어떤 기록으로 연결을 확인하는지 | 발주에 기록된 프로젝트 코드 |
| 업무 기준 | 용어, 상태, 적용 시점과 예외 | 검수 완료를 확인하는 항목 |
| 데이터 책임자 | 의미와 오류를 확인할 담당자 | 구매 담당자와 계약 관리 담당자 |
| 갱신과 시간 | 변경 주기, 발생 시점, 보관 이력 | 상태 변경 시각과 기록 갱신 시각 |
초기 상담에서는 민감한 실제 자료를 전부 전달하기보다 데이터 종류와 구조, 필요한 업무를 설명하는 것부터 시작할 수 있습니다. 자료 공유 방식과 범위는 접근 환경에 맞춰 정합니다.
3. 이름 대신 식별 근거를 점검합니다
계약서의 고객 A와 ERP 거래처 C-104를 연결할 공통 코드가 있는지 확인하세요. 없다면 승인된 대응표나 확인 절차가 필요할 수 있습니다. 비슷한 이름의 다른 법인, 지점과 계열사를 어떻게 구분할지도 정해야 합니다.
프로젝트 코드가 누락된 발주, 여러 계약을 따르는 프로젝트, 담당자 변경 같은 예외도 목록에 넣으세요. 모든 자료가 깔끔하게 맞는 사례만으로 평가하면 운영에서 어려움을 놓치기 쉽습니다.
4. 관계와 기준의 유효 시점을 정합니다
계약이 개정되거나 프로젝트 담당자가 바뀌면 연결과 적용 조건도 달라질 수 있습니다. 원문 버전, 관계의 적용 시점, 최신 데이터를 확인하는 방법을 함께 정리하세요.
‘발주 완료’, ‘입고 완료’, ‘검수 완료’가 같은 뜻인지도 점검해야 합니다. 부서별 상태 정의가 다르다면 하나의 이름으로 합치기 전에 차이를 기록해야 합니다. 확인되지 않은 상태와 실제로 해당하지 않는 상태를 구분하는 것도 필요합니다.
5. 권한과 갱신 방식을 확인합니다
사용자가 발주를 볼 수 있다고 연결된 모든 계약을 열람할 수 있는 것은 아닙니다. 관계 탐색과 답변에서 원문 권한이 어떻게 적용돼야 하는지 확인하세요. 자료가 삭제되거나 접근 권한이 바뀌었을 때 결과에서 어떻게 반영할지도 정합니다.
사내망이 필요한 조직은 데이터 접근 방식, 처리 구성, 모델 환경과 운영 주체를 함께 검토해야 합니다. 배포 위치만 정했다고 연동과 권한 관리가 모두 해결되는 것은 아닙니다.
운영 기록이나 측정값을 사용한다면 실제 발생 시각과 수집 시각, 단위, 누락 데이터, 이력 보관 방식을 확인하세요. 프로세스를 다룬다면 단계의 순서, 분기 조건, 완료 기준과 예외를 정리합니다. 디지털 트윈이나 시뮬레이션이 목표라면 필요한 데이터 갱신과 분석 모델의 검증까지 별도 범위로 살펴봐야 합니다.
6. 정상 사례와 예외를 나누어 평가합니다
| 평가 상황 | 확인할 행동 |
|---|---|
| 올바른 대상과 관계가 존재함 | 프로젝트·계약과 원문 근거를 정확히 연결 |
| 이름이 비슷한 다른 고객이 있음 | 다른 거래처를 잘못 결합하지 않음 |
| 프로젝트 코드나 계약이 누락됨 | 확인할 자료가 부족하다는 점을 식별 |
| 계약이 개정됨 | 질문 시점에 적용할 버전을 확인 |
| 사용자가 계약 권한이 없음 | 제한된 계약 정보와 관계를 노출하지 않음 |
문서 검색과 답변 생성도 함께 사용한다면 RAG PoC 평가 방법처럼 검색·답변·출처·권한을 나누어 점검할 수 있습니다. 관계 구조를 활용하는 방식은 Microsoft GraphRAG 로컬 검색 문서에서도 확인할 수 있습니다. 특정 도구의 도입과 회사 업무 기준의 합의는 별도로 검토해야 합니다.
도입 문의에 적을 내용
‘ERP와 계약 문서에서 발주가 연결된 프로젝트와 계약 조건을 확인하고 싶다. 거래처 코드와 프로젝트 코드가 있고, 구매 담당자가 기준을 확인할 수 있다’처럼 현재 환경을 설명해 보세요.
다른 업무라면 ‘설비별 작업과 점검 이력을 연결해 현재 상태를 파악하고 싶다’ 또는 ‘제품의 공급·재고·주문 관계를 함께 보고 싶다’처럼 적어도 됩니다. 온톨로지라는 용어에 익숙하지 않아도, 기대하는 결과와 사용 중인 자료를 설명하면 필요한 모델과 도입 범위를 논의할 수 있습니다.
적용 범위가 명확하면 어떤 자료와 관계를 먼저 확인할지 정하기 좋습니다. 기업 데이터 온톨로지의 개념과 온톨로지·지식 그래프·RAG 비교를 읽고, Wissly 온톨로지 Beta에서 도입 가능성을 함께 검토할 수 있습니다.