개념은 알겠는데, 실제로 뭘 정의해야 하나
온톨로지가 “회사의 현실을 소프트웨어가 이해할 수 있게 바꾼 지도”라는 설명은 여러 번 들었을 겁니다. 그런데 막상 “그래서 실제로 만들 땐 뭘 정의해야 하지?”라는 질문 앞에서는 다시 막막해집니다. 이 글에서는 온톨로지를 구성하는 7가지 요소를, 설비 하나가 고장나고 수리되는 하나의 이야기에 전부 대입해서 설명합니다.
데이터셋의 개념이 온톨로지의 개념으로 바뀌는 방식
먼저 대응 관계부터 짚고 갑니다.
| 데이터셋 개념 | 온톨로지 개념 |
|---|---|
| 행(Row) | 오브젝트 |
| 열(Column) | 속성 |
| 필드 값 | 속성 값 |
| 결합(Join) | 링크 유형 |
여기에 온톨로지는 세 가지를 더 얹습니다. 비즈니스 용어 기반 메타데이터, 필드 단위로 세분화된 권한 관리, 그리고 액션(Action) 기능입니다. 단순히 테이블을 예쁘게 부르는 게 아니라, “행동할 수 있는” 구조로 바꾸는 겁니다.
7가지 구성요소: 설비 이야기로 풀어보기
핵심 4요소
Object Type — “설비”라는 개체. 우리 공장에 있는 모든 설비를 하나의 Object Type으로 정의합니다. 사람, 장비, 주문처럼 실제 세계의 개체 유형을 정의하는 게 Object Type입니다.
Link Type — “설비”와 “담당 부서”의 관계. 이 설비가 어느 부서 소속인지, 어떤 정비 오더와 연결되는지를 정의합니다. 두 오브젝트 유형 사이의 관계를 정의하는 게 Link Type입니다.
Action Type — “고장 신고”라는 행동. 설비 상태를 “정상”에서 “고장”으로 바꾸는 것, 이게 바로 Action Type입니다. 데이터를 생성·수정·삭제하는 작업을 정의합니다.
Functions — “수리 비용을 자동으로 계산한다”. 고장 신고가 접수되면, 과거 유사 고장 이력을 바탕으로 예상 수리 비용과 소요 시간을 계산하는 로직이 필요합니다. 이런 비즈니스 로직(코드)을 실행하는 게 Functions입니다.
보조 3요소
Property — 설비의 개별 데이터 필드. 설비명, 설치 위치, 최근 점검일처럼 Object Type이 갖는 개별 필드입니다.
Shared Property — 여러 Object Type이 공유하는 속성. 예를 들어 “관리 부서 코드”는 설비뿐 아니라 차량, 시설물 같은 다른 Object Type에서도 똑같이 쓰일 수 있습니다. 이렇게 여러 Object Type에서 공통으로 쓰는 속성이 Shared Property입니다.
Role — “누가 고장 신고를 접수할 수 있는가”. 현장 작업자는 고장 신고를 접수할 수 있지만, 신고 내용을 삭제하는 건 관리자만 가능해야 합니다. 이렇게 Action 수행과 데이터 접근 권한의 단위가 Role입니다.
실무적으로 나누면
의미론적 요소(오브젝트, 속성, 링크)는 “회사 현실이 무엇인지”를 정의합니다. 동적 요소(액션, Functions)는 “그 현실을 어떻게 변경할 수 있는지”를 정의합니다. 설비 이야기로 치면, 앞의 세 가지는 “설비가 무엇이고 어디 소속인지”를 정의하고, 뒤의 두 가지는 “설비에 무슨 일이 생겼을 때 무엇을 할 수 있는지”를 정의합니다.
Action Type과 Functions: 온톨로지가 “움직이는” 부분
Action Type은 조직 운영자로부터 데이터를 수집하고, 기존 시스템의 의사결정 과정을 조정하는 역할을 합니다. “고장 신고 접수”는 단순 조회가 아니라 상태를 바꾸는 행위이고, 이 과정에서 누가 승인했는지, 언제 실행됐는지가 감사 로그로 체계 안에 통합됩니다.
Functions는 임의의 복잡도를 가진 비즈니스 로직을 작성하는 곳입니다. “예상 수리 비용 계산”처럼 단순 계산부터, “이 설비가 3개월 내 두 번째 고장이면 자동으로 우선순위를 높여라” 같은 복잡한 조건 분기까지 다 여기서 처리합니다.
온톨로지 위에 세워지는 애플리케이션들
설비 온톨로지를 한 번 잘 설계해두면, 그 위에 목적별로 다른 애플리케이션을 얹을 수 있습니다.
| 애플리케이션 | 설비 이야기에서의 쓰임 |
|---|---|
| Object Views | 설비 하나를 클릭하면 속성, 연결된 부서, 최근 정비 이력을 한 화면에서 보여줌 |
| Object Explorer | “이번 달 고장난 설비를 전부 찾아줘”처럼 자유롭게 탐색·필터링 |
| Quiver | 설비별 고장 빈도, 부서별 정비 비용을 통계로 분석 |
| Workshop | 현장 작업자가 쓰는 “고장 신고” 화면을 로우코드로 빠르게 구축 |
| Slate | 임원 보고용으로 설비 현황을 맞춤 UI로 정교하게 구성 |
| Map | 여러 공장에 흩어진 설비 위치를 지도 위에 시각화 |
핵심은, 온톨로지를 한 번 설계해두면 탐색용·분석용·운영용 애플리케이션을 매번 새로 만들 필요가 없다는 점입니다. 용도별로 애플리케이션만 갈아 끼우면 됩니다. 이게 팔란티어가 강조하는 “규모의 경제”가 실제로 구현되는 방식입니다.
정리하면
온톨로지를 “왜” 쓰는지는 개념의 영역이고, “무엇으로” 만드는지는 이 7가지 구성요소의 영역입니다. 오브젝트·링크·속성은 의미론적 정의를 담당하고, 액션·Functions는 현실을 실제로 변경하는 통로를 담당합니다. 그 위에 목적에 맞는 애플리케이션이 켜켜이 쌓입니다.
자주 묻는 질문
Q1. Object Type과 Dataset은 뭐가 다른가요? Dataset은 파이프라인이 만든 정제 데이터 테이블이고, Object Type은 그 Dataset을 업무 개념으로 매핑한 것입니다. Object Type 하나가 여러 Dataset을 참조할 수도 있습니다.
Q2. Link Type의 카디널리티는 어떤 종류가 있나요? 1:1, 1:N, N:M 세 가지를 지원합니다. 단방향으로 할지 양방향으로 할지도 설정할 수 있습니다.
Q3. Action Type은 언제 만드는 게 좋나요? Object Type과 Link Type이 안정적으로 정의된 이후에 만드는 걸 권합니다. 데이터 구조가 아직 유동적인 단계에서 Action부터 만들면, 검증 규칙을 계속 반복해서 수정하게 됩니다.
Q4. Functions는 정확히 어떤 역할을 하나요? Object, Link, Action이 다루지 못하는 복잡한 계산이나 조건 로직을 처리합니다. Action의 검증 로직이나 Workshop 위젯의 계산식에 자주 쓰입니다.
Q5. 설계 순서는 어떻게 잡아야 하나요? Object Type부터 시작하세요. 이후 Link, Action, Functions 설계가 모두 Object Type을 기준으로 이어집니다.
Q6. Shared Property는 언제부터 도입해야 하나요? 여러 Object Type이 늘어나면서 같은 속성(예: 관리 부서 코드, 담당자 사번)을 반복해서 각각 따로 정의하고 있다는 걸 느끼는 시점이 도입 신호입니다. 초기 설계 단계부터 무리하게 도입할 필요는 없습니다.