온톨로지가 무엇인지, 왜 필요한지는 이해했다고 칩시다. 그런데 막상 Ontology Manager 화면을 열면 막막합니다. Object Type을 만들라는데, 정확히 뭘 클릭해야 하는 걸까요.
이 글에서는 “설비(Equipment)”라는 하나의 대상을 예로 잡고, Object Type → Link Type → Action Type을 순서대로 만들어가는 과정을 그대로 따라가 봅니다. 온톨로지를 처음 만드는 설계 방법을, 실제 온톨로지 예시 하나로 통째로 보여주는 셈입니다. 설비가 고장나면 알림이 가고, 정비 이력이 쌓이고, 담당자가 승인하는 흐름까지 완성하는 게 목표입니다.
Ontology Manager는 어디에 있고, 왜 필요한가
파이프라인에서 정제된 데이터는 그 자체로는 그냥 “테이블”입니다. 컬럼과 행일 뿐, AI도 사람도 “이게 설비 정보구나”라고 바로 알아채지는 못합니다.
Ontology Manager는 이 정제된 데이터를 “설비”, “정비 오더”, “담당자” 같은 비즈니스 객체로 바꿔주는 도구입니다. 파이프라인 정제 단계 다음, Workshop이나 Contour 같은 애플리케이션을 만들기 전 단계에 위치합니다. 여기서 정의를 잘 해두면, 이후 어떤 애플리케이션을 얹든 매번 SQL 조인을 다시 짤 필요가 없습니다.
1단계 — Object Type 만들기: ‘설비’를 정의한다
소스 연결. 정제가 끝난 EQUIPMENT_MASTER 데이터셋을 소스로 지정합니다.
Primary Property 지정. 설비를 유일하게 식별할 수 있는 값, 보통 원본 PK인 EQUIP_ID를 기본 키로 지정합니다. 이게 없으면 온톨로지가 “이 레코드가 어떤 설비인지” 구분할 수 없습니다.
Property 정의. EQUIP_NAME(설비명), LOCATION(설치 위치), STATUS(가동상태) 같은 컬럼을 하나씩 속성으로 등록하면서, 옵션을 켤지 말지 결정합니다.
| 옵션 | 영향 | ‘설비’ 예시에서의 활용 |
|---|---|---|
| Searchable | 전문 검색 인덱싱 | 설비명으로 텍스트 검색 |
| Filterable | 필터 조건 가능 | Workshop에서 “가동중” 상태만 필터 |
| Sortable | 정렬 기준 가능 | 최근 점검일 순 정렬 |
여기서 흔히 저지르는 실수가 있습니다. “혹시 몰라서” 모든 속성에 세 옵션을 다 켜두는 겁니다. 설비 30개짜리 테스트 환경에서는 티가 안 나지만, 실제 운영 데이터 3만 건이 쌓이면 인덱싱 비용이 그대로 누적됩니다. 지금 이 화면에서 실제로 검색하거나 필터링할 컬럼이 무엇인지부터 먼저 적어보고, 그 컬럼에만 옵션을 켜는 게 맞습니다.
2단계 — Link Type 만들기: ‘설비’와 ‘담당 부서’를 잇는다
이제 설비 오브젝트를, 이미 만들어져 있는 “부서” 오브젝트와 연결합니다. Link Type을 만들 때 가장 먼저 결정해야 하는 게 카디널리티입니다.
- 1:1 — 사원과 그 사람의 인사기록처럼, 서로 한쪽씩만 매칭되는 경우
- 1:N — 부서 하나에 설비 여러 대가 속하는 경우. 실무에서 가장 많이 씁니다
- N:M — 학생과 과목처럼, 양쪽 다 여러 개씩 연결될 수 있는 경우. 중간 매핑 테이블이 필요합니다
설비-부서 관계는 보통 1:N입니다. “이 부서 소속 설비를 다 보여줘”와 “이 설비의 관리 부서가 어디야”를 양방향으로 다 조회하고 싶다면, 링크를 양방향으로 설정해두는 게 실무에서 훨씬 편합니다. 단방향으로 만들어두면 나중에 반대 방향 조회가 필요할 때 링크를 다시 파야 합니다.
3단계 — Action Type 만들기: ‘고장 신고’를 실행 가능하게 만든다
여기까지는 “설비가 무엇인지”를 정의한 것뿐입니다. 실제로 뭔가 하려면 Action Type이 필요합니다. “고장 신고” Action을 예로 들어보겠습니다.
- 트리거 대상: 설비(Equipment) Object Type
- Validation Rule: 이미 “점검중” 상태인 설비는 중복으로 고장 신고를 못 하도록 조건을 겁니다
- Role 기반 권한: 현장 작업자 Role만 이 Action을 실행할 수 있도록 제한합니다
- Side Effect: 고장 신고가 접수되면 담당 부서에 알림을 보내는 외부 API를 호출합니다
Action Type이 바로 온톨로지에 “쓰기”와 “행동”을 부여하는 부분입니다. Object Type과 Link Type만 있으면 조회만 가능한 정적인 지도인데, Action Type이 붙어야 실제로 업무가 움직입니다.
설계 체크리스트
| 단계 | 확인할 것 |
|---|---|
| Object Type | Primary Property가 실제로 유일한 값인가? |
| Property 옵션 | Searchable/Filterable을 켜기 전에, 실제 조회 화면에 이 필드가 쓰이는가? |
| Link Type | 카디널리티가 향후 바뀔 가능성이 있는가? 있다면 지금 N:M으로 여유 있게 설계할지 검토 |
| Action Type | Validation Rule이 최소 1개는 있는가? |
| Action Type | 이 Action을 실행해도 되는 Role이 명확히 정의되어 있는가? |
자주 하는 실수 3가지
검증 규칙을 나중으로 미룬다. “일단 Action부터 만들고 검증은 나중에”라고 생각하면, 그 사이 잘못된 상태 전이(예: 이미 폐기된 설비에 정비 오더가 또 생성되는 것)가 데이터에 누적됩니다. 처음부터 최소 1개의 검증 조건은 넣어두는 걸 원칙으로 삼으세요.
옵션을 다 켜놓고 시작한다. 앞서 말씀드린 대로, Searchable·Filterable·Sortable을 습관적으로 전부 활성화하면 데이터가 늘어날수록 인덱싱 비용만 커지고 실제 활용도는 낮습니다.
카디널리티를 나중에 바꾼다. 처음에 1:N으로 설계했다가 나중에 “사실 이거 N:M이어야 했네”라고 깨달으면, 이 링크를 참조하는 모든 Workshop 화면, AIP 프롬프트, 다른 Action들을 다 다시 손봐야 합니다. 설계 초반에 “이 관계가 정말 1:N이 맞는지” 한 번 더 의심해보는 게 나중 비용을 크게 줄입니다.
정리하면
Ontology Manager에서 하는 일은 결국 세 가지입니다. 무엇이 있는지(Object Type), 그것들이 서로 어떻게 연결되는지(Link Type), 그리고 그것으로 무엇을 할 수 있는지(Action Type). 이 세 가지를 설비 하나로 끝까지 따라가 보면, 다른 어떤 대상 — 주문이든, 고객이든, 자재든 — 에도 같은 순서로 적용할 수 있습니다.