온톨로지 핵심 구성요소 — 오브젝트·링크·액션·Functions로 뜯어보기
도입
온톨로지란 무엇인가에서 온톨로지를 “회사의 현실을 소프트웨어가 이해할 수 있게 옮겨놓은 지도”라고 정리했습니다. 이번 글에서는 한 단계 더 들어가서, 그 지도가 실제로 어떤 부품들로 만들어지는지를 살펴보겠습니다. “온톨로지가 뭔지는 알겠는데, 실제로 만들 땐 뭘 정의해야 하지?”라는 질문에 대한 답입니다.
데이터셋 개념이 온톨로지 개념으로 바뀌는 방식
먼저 익숙한 것부터 시작하겠습니다. 관계형 데이터베이스에 익숙하다면 아래 대응 관계가 이해를 빠르게 해줍니다.
| 데이터셋 개념 | 온톨로지 개념 |
|---|---|
| 데이터셋 | 온톨로지 |
| 행(Row) | 오브젝트 |
| 열(Column) | 속성 |
| 필드(값) | 속성 값 |
| 결합(Join) | 링크 유형 |
즉 테이블의 각 행이 “오브젝트”가 되고, 테이블 간의 조인이 “링크”가 됩니다. 다만 단순히 이름만 바뀌는 게 아닙니다. 온톨로지의 오브젝트·링크에는 데이터베이스 스키마에는 없던 것들이 함께 따라옵니다 — 비즈니스 용어로 된 메타데이터, 필드 단위의 세분화된 권한, 그리고 다음 절에서 다룰 “액션”입니다.
온톨로지를 구성하는 핵심 요소 7가지
온톨로지 하나는 다음 요소들의 조합으로 정의됩니다.
- 오브젝트 유형(Object Type): 사람, 장비, 주문처럼 실제 세계의 개체 유형을 나타내는 정의입니다.
- 속성(Property): 오브젝트 유형이 가지는 개별 데이터 필드입니다.
- 공유 속성(Shared Property): 여러 오브젝트 유형에서 공통으로 쓰이는 속성입니다.
- 링크 유형(Link Type): 두 오브젝트 유형 사이의 관계를 정의합니다.
- 액션 유형(Action Type): 온톨로지 데이터를 생성·수정·삭제하는 작업을 정의합니다.
- 역할(Role): 액션을 수행하거나 데이터에 접근할 수 있는 권한 단위입니다.
- Functions: 온톨로지 위에서 실행되는 비즈니스 로직(코드)입니다.
여기서 실무적으로 중요한 구분은 오브젝트·속성·링크 같은 의미론적 요소와, 액션·Functions 같은 동적 요소가 나뉘어 있다는 점입니다. 전자는 “회사의 현실이 무엇인지”를 정의하고, 후자는 “그 현실을 어떻게 바꿀 수 있는지”를 정의합니다. 온톨로지가 정적인 데이터 카탈로그와 다른 지점이 바로 여기입니다 — 조회만 되는 게 아니라 액션 유형을 통해 실제 업무 시스템의 변경으로 이어질 수 있습니다.
액션 유형과 Functions: 온톨로지가 “움직이는” 부분
액션 유형은 조직의 운영자로부터 데이터를 수집하거나, 기존 시스템에 연결된 의사결정 과정을 조정할 수 있게 해줍니다. 예를 들어 “주문 승인” 같은 업무는 단순 조회가 아니라 실제로 상태를 바꾸는 행위인데, 이걸 온톨로지 안에서 액션 유형으로 정의해두면 승인 권한(역할)·승인 이력(감사 로그)까지 한 번에 체계 안으로 들어옵니다.
Functions는 임의의 복잡도를 가진 비즈니스 로직을 작성하고 발전시킬 방법을 제공합니다. 단순 계산부터 복잡한 조건 분기까지, “이 데이터를 보고 어떻게 판단할 것인가”에 해당하는 로직이 여기에 들어갑니다.
온톨로지 위에 세워지는 애플리케이션들
온톨로지 자체는 데이터 모델이지만, 그 위에는 실제로 사람이 쓰는 여러 애플리케이션이 얹힙니다. 같은 오브젝트와 데이터를 공유하면서도 용도가 서로 다릅니다.
| 애플리케이션 | 주요 용도 |
|---|---|
| Object Views | 오브젝트 유형별 상세 화면. 속성·링크된 오브젝트·시각화를 한 화면에서 확인하는, 현장 사용자가 가장 자주 접하는 진입점 |
| Object Explorer | 오브젝트와 링크를 자유롭게 탐색하는 범용 인터페이스. 검색·필터링·관계 탐색에 사용 |
| Quiver | 오브젝트 데이터 기반의 통계 분석, 차트, 피벗 테이블 작업 |
| Workshop | 코드 없이 위젯을 조합해 운영 애플리케이션을 만드는 로우코드 빌더 |
| Slate | Workshop보다 더 유연한 레이아웃으로 맞춤형 UI를 세밀하게 구성 |
| Map | 오브젝트 데이터를 지리공간적으로 시각화 |
이 목록에서 알 수 있는 점은, 온톨로지를 한 번 잘 설계해두면 “탐색용 화면”, “분석 도구”, “운영 애플리케이션”을 각각 처음부터 새로 만들 필요가 없다는 것입니다. 오브젝트·링크·액션이라는 공통 기반 위에서 용도별 애플리케이션만 갈아 끼우는 구조입니다. 이게 바로 팔란티어가 강조하는 “규모의 경제” — 온톨로지 투자가 여러 유즈케이스에서 재사용되는 방식 — 의 실체입니다.
마무리
온톨로지를 “왜” 쓰는지는 첫 글에서 다뤘고, 이번 글에서는 “무엇으로” 만들어지는지를 다뤘습니다. 오브젝트·링크·속성이 회사의 현실을 의미론적으로 정의하고, 액션 유형·Functions가 그 현실을 실제로 움직이는 통로가 되며, 그 위에 Object Views부터 Workshop까지 다양한 애플리케이션이 얹힙니다. 다음으로 자연스럽게 이어지는 질문은 “그럼 실제로 우리 회사 데이터를 오브젝트·링크로 어떻게 나눌 것인가”이며, 이는 별도 글에서 다루겠습니다.