Ontology Manager가 왜 필요한가
Primary Property를 잘못 잡거나 카디널리티를 나중에 바꾸려고 하면, Foundry에서는 되돌리는 비용이 생각보다 큽니다. 처음 Ontology Manager로 설계할 때 놓치기 쉬운 지점부터 짚고 시작하겠습니다. Ontology Manager는 이 정제된 데이터를 “고객”, “장비”, “주문” 같은 비즈니스 언어의 객체로 변환해서, 뒤이은 애플리케이션(Workshop, Contour 등)과 AIP가 SQL 조인 없이 그 객체를 바로 다루게 만드는 도구입니다.
온톨로지 핵심 구성요소 글에서 Object Type·Link Type·Action Type이 개념적으로 무엇인지 다뤘다면, 이 글은 그 세 요소를 Ontology Manager 화면에서 실제로 어떻게 만드는지에 집중합니다.
Object Type 만들기
Object Type은 Dataset(정제된 데이터)을 온톨로지의 객체로 매핑하는 작업에서 시작합니다.
- 소스 Dataset 연결: Object Type을 만들 때 기반이 될 Dataset을 지정합니다. 이 Dataset은 이미 파이프라인을 거쳐 정제된 상태여야 합니다 — Ontology Manager 단계에서 데이터를 다시 정제하려 하면 작업이 뒤엉킵니다.
- Primary Property 지정: 모든 Object Type은 고유 식별자 역할을 하는 Primary Property를 반드시 가져야 합니다. 원본 테이블의 PK 컬럼을 그대로 지정하는 경우가 많습니다.
- Property 정의: 각 컬럼을 Property로 등록하면서 데이터 타입(String, Integer, Timestamp, Geopoint 등)을 지정하고, Searchable·Filterable·Sortable 여부를 설정합니다.
| 설정 | 의미 | 켜두면 좋은 경우 |
|---|---|---|
| Searchable | 전문 검색 인덱싱 대상 여부 | Object Explorer에서 텍스트로 찾아야 하는 필드 |
| Filterable | 필터 조건으로 쓸 수 있는지 | Workshop 위젯에서 드롭다운·조건 필터로 쓸 필드 |
| Sortable | 정렬 기준으로 쓸 수 있는지 | 목록 화면에서 정렬 옵션으로 노출할 필드 |
이 세 옵션은 하위 애플리케이션의 쿼리 성능에 직접 영향을 주기 때문에, 필요한 필드에만 선택적으로 켜는 것이 좋습니다. 모든 Property에 세 옵션을 다 켜두면 인덱싱 부담만 늘어나고 실제로는 안 쓰이는 경우가 많습니다.
Link Type 만들기
Link Type은 Object Type 사이의 관계를 정의합니다. 관계의 카디널리티(Cardinality)를 먼저 정하는 것이 순서입니다.
- 1:1 — 예: 사원 – 인사기록
- 1:N — 예: 부서 – 사원 (가장 흔한 형태, 외래키 기반)
- N:M — 예: 학생 – 과목 (중간 조인 테이블 기반)
Link는 단방향(Unidirectional)과 양방향(Bidirectional) 중 선택할 수 있습니다. 대부분의 경우 양방향으로 만들어 양쪽 Object Type 어디서든 관계를 탐색할 수 있게 하는 편이 Workshop이나 Object Explorer에서 쓰기 편합니다.
Action Type 만들기
Action Type은 온톨로지에 “쓰기”와 “행동”을 부여하는 요소입니다. Object Type과 Link Type이 정의된 이후에나 의미를 갖습니다.
- 트리거 대상 정의: 어떤 Object Type에 대한 행위인지 지정합니다 (예: 주문 취소, 장비 점검 등록).
- Validation Rule 설정: 액션 실행 전 조건을 검증합니다 — 예를 들어 재고 수량이 0 이하일 때는 “출고” Action이 실행되지 않도록 막는 규칙입니다.
- 권한 연결: Role 기반 접근 제어와 결합해서, 특정 권한을 가진 사용자만 해당 Action을 실행하도록 제한할 수 있습니다.
- Side Effect 구성: Action 실행 후 온톨로지 내부 데이터 수정에 그치지 않고, 외부 API 호출이나 알림 발송(Slack, Email) 같은 후속 작업을 파이프라인으로 이어 붙일 수 있습니다.
자주 하는 실수
- Validation Rule을 나중으로 미루기: Action Type을 일단 만들고 검증 규칙은 “나중에 추가하자”고 미루면, 그사이 잘못된 상태 전이가 실제 데이터에 쌓입니다. Action을 처음 설계할 때부터 최소 하나의 검증 조건은 함께 정의하는 편이 안전합니다.
- Searchable/Filterable을 전부 켜기: 앞서 설명했듯, 필요 이상으로 옵션을 켜두면 인덱싱 비용만 커지고 실제 활용도는 낮습니다. Workshop이나 Object Explorer에서 실제로 어떤 필드를 필터·검색에 쓸지 먼저 정하고 그 필드만 켜는 순서가 낫습니다.
- Link의 카디널리티를 나중에 바꾸려 하기: 1:N으로 만든 Link를 N:M으로 바꾸는 작업은 이미 이 Link를 참조하는 Workshop 앱이나 Action Type을 전부 다시 손봐야 합니다. 관계가 명확하지 않다면 Ontology Manager 단계에서 시간을 들여 카디널리티를 검토하는 편이, 나중에 되돌리는 비용보다 훨씬 적게 듭니다.
다음 단계
Object Type과 Link Type이 만들어졌다면, 이 온톨로지를 실제 화면으로 보여주는 단계로 넘어갑니다 — 다음 편에서는 Workshop으로 이 온톨로지를 화면에 바인딩하는 과정을 다룹니다. Ontology Manager 단계에서 Searchable/Filterable을 설정해둔 Property는 Workshop의 위젯 구성에 그대로 반영됩니다.
자주 묻는 질문
Q. Object Type을 만들려면 Dataset이 먼저 정제되어 있어야 하나요?
네. Ontology Manager는 이미 정제된 Dataset을 Object Type으로 매핑하는 도구이므로, 원본 데이터가 파이프라인을 거쳐 정제·표준화된 이후에 Object Type을 만드는 것이 일반적인 순서입니다.
Q. Searchable, Filterable, Sortable을 전부 켜면 안 되나요?
기술적으로는 가능하지만 인덱싱 비용과 쿼리 성능에 영향을 줍니다. 실제로 검색·필터·정렬에 쓰이는 Property에만 선택적으로 켜는 것이 권장됩니다.
Q. Link Type의 카디널리티는 나중에 바꿀 수 있나요?
변경할 수는 있지만 이미 이 Link Type을 참조하는 애플리케이션과 Action이 있다면 함께 수정해야 하므로, 초기 설계 단계에서 신중하게 정하는 것이 좋습니다.
Q. Action Type은 언제 만드는 게 좋나요?
Object Type과 Link Type이 안정된 이후에 만드는 것이 좋습니다. 데이터 구조가 바뀌는 동안 Action의 검증 규칙까지 함께 계속 수정하게 되기 때문입니다.
Q. Ontology Manager와 Pipeline Builder는 뭐가 다른가요?
Pipeline Builder는 원천 데이터를 정제해 Dataset을 만드는 도구이고, Ontology Manager는 그 Dataset을 온톨로지의 Object·Link·Action으로 매핑하는 도구입니다. 파이프라인이 선행 단계입니다.