온톨로지 모델러 워크플로 개요
온톨로지가 포털의 어디에 1급 표면으로 자리하는지, 모델러가 머무는 두 메뉴(Modeling · 그래프 탐색기)와 분석가·엔지니어 표면과의 연결을 한 표로 정리합니다.
분석가는 이미 있는 데이터 위에 화면을 그립니다. 엔지니어는 그 데이터가 어떻게 거기 있게 되는지를 책임집니다. 그 사이에서 온톨로지 모델러는 그 데이터들이 서로 어떤 의미로 이어지는가 — 곧 엔티티와 관계의 그래프 — 를 정의합니다. 포털에서 이 작업은 별도 1급 표면 위에서 이뤄집니다.
사이드바에서 온톨로지의 자리 — 별도 1급 섹션
좌측 사이드바에는 Applications 섹션과 별도로 ONTOLOGY 섹션 이 있고, 그 안에 두 메뉴가 들어 있습니다.
- Modeling (모델링 빌더) — 엔티티와 관계를 정의하고 편집합니다. 노드와 엣지가 캔버스 위에 떠 있는 그래프 뷰, 또는 대량 관리를 위한 테이블 뷰 두 모드를 전환합니다.
- 그래프 탐색기 (Graph Explorer) — 정의된 모델 위에 적재된 인스턴스 데이터를 시각적으로 탐색합니다. Cypher 쿼리, 라벨 클릭, 더블클릭 이웃 확장이 여기서 일어납니다.
이 위계 분리가 강제하는 점은 두 가지입니다.
- 컬렉션 트리에는 엔티티 · 관계가 leaf 로 노출되지 않습니다. 온톨로지 자원은 ONTOLOGY 섹션의 페이지에서만 관리합니다.
- 1 컬렉션 = 1 온톨로지 스코프. 컬렉션을 만들면 그에 대응하는 온톨로지 스코프가 자동 생성되고, 엔티티/관계 생성 시 소속 컬렉션(
collection_id)을 반드시 지정해야 합니다. 누락 시 422.
"온톨로지는 도구가 아니라 데이터의 의미 레이어입니다" 라는 멘탈 모델을 사이드바 위계 자체가 강제하는 셈입니다.
온톨로지의 세 구성 요소
본 코스의 모든 레슨은 다음 세 가지를 반복해서 다룹니다.
- 엔티티(Entity) — 현실 세계의 객체(고객 · 제품 · 주문 · 기계 · 센서) 를 추상화한 단위. 기반 데이터셋(backing dataset) 위에 의미 레이어로 올라갑니다.
- 관계(Relationship) — 두 엔티티 사이의 연관성(고객이 제품을 주문함, 센서가 기계를 측정함). 방향성과 타입(
PURCHASED,IOT_reads_from)을 가지며 그래프 데이터베이스에 저장됩니다. - 스키마 메타데이터 — 각 엔티티/관계의 Identity Keys (인스턴스 고유 식별 키) 와 Display Column (UI 1차 라벨). 둘이 비어 있으면 그래프 탐색기에서 노드가 익명으로 보이고, 파이프라인의 Entity I/O 가 페이로드 검증에서 실패합니다.
익숙한 어휘와의 대응 (1 회만)
ER 모델 · Neo4j · RDF 로 같은 흐름을 다뤄 봤다면, 처음 30 분만 다음 표를 머리에 두고 포털을 봐도 충분합니다. 02 레슨부터는 포털 어휘로만 진행합니다.
| 익숙한 어휘 | 포털에서의 대응 |
|---|---|
| ER 모델의 entity | 엔티티(Entity) |
| Primary key (PK) | Identity Keys |
| 사람이 읽는 라벨 컬럼 | Display Column |
| ER 모델의 relationship · Neo4j 의 relationship type | 관계(Relationship) — source · target · type |
Neo4j :Label | 엔티티 이름(name) |
| 그래프 DB 인스턴스 | 그래프 탐색기에서 보이는 노드 한 개 |
| Cypher | 그래프 탐색기 하단 쿼리 에디터 (그대로 사용) |
기존 어휘와 다른 점 두 가지만 미리 짚어 둡니다.
- 모델과 인스턴스의 표면이 분리됐습니다. Modeling 은 클래스 정의, 그래프 탐색기는 인스턴스 탐색. 두 화면을 자주 오갑니다.
- Sink UI 는 없습니다. 매핑이 완료되면 백엔드 인프라가 그래프 데이터베이스로 자동 적재합니다. 이전 버전의 EntitySink / RelationSink 버튼은 제거됐습니다.
두 도메인 예시 — 작은 그래프와 큰 그래프
본 코스의 레슨 본문은 다음 두 시나리오를 번갈아 인용합니다.
- 제조 IoT — 작은 그래프(3 + 2):
IOT_Machine,IOT_Sensor,IOT_MaintenanceEvent세 엔티티와IOT_reads_from(센서→기계),IOT_triggers(기계→유지보수 이벤트) 두 관계. 한 화면에 다 보이는 가장 작은 의미 단위. - 리테일 공급망 — 큰 그래프(4 + 3):
RI_Product,RI_Branch,RI_Region,RI_Supplier네 엔티티와RI_STOCKED_AT(상품→지점),RI_LOCATED_IN(지점→지역),RI_SUPPLIED_BY(상품→공급업체) 세 관계. 관계 다양성과 카디널리티 차이를 한 번에 보여 줍니다.
작은 그래프와 큰 그래프 두 패턴을 레슨 별로 번갈아 봐 두면, 본인 도메인을 그릴 때 어디서 멈춰야 적당한 크기인지 감이 잡힙니다.
분석가 · 엔지니어와의 책임 경계
같은 포털 안에서 세 역할이 부딪치지 않으려면 누가 무엇을 책임지는지에 대한 합의가 필요합니다.
| 책임 | 보통 누구의 일 |
|---|---|
| 외부 시스템에서 데이터를 가져와 데이터셋으로 떨어뜨리기 | 엔지니어 |
| 데이터셋 위에 의미 레이어 (엔티티 · 관계) 정의 | 모델러 |
| Identity Keys · Display Column · 카디널리티 결정 | 모델러 |
| 데이터셋 컬럼과 엔티티 속성 매핑 | 모델러 (엔지니어와 한 자리에서) |
| 그래프 위에 위젯 · 대시보드 만들기 | 분석가 |
| 그래프 탐색기에서 거버넌스 · 감사 흔적 추적 | 모델러 + 분석가 |
조직 규모에 따라 한 사람이 두 역할 또는 세 역할을 겸하기도 합니다. 본 코스는 모델러 시점에서 어떤 표면 위에서 무엇을 결정하는지를 기준으로 모든 레슨을 진행합니다.
이 레슨에서 익혀야 할 것
- ONTOLOGY 섹션의 두 메뉴(Modeling · 그래프 탐색기)와 각각이 답하는 질문
- 엔티티 · 관계 · 스키마 메타데이터 세 구성 요소
- 익숙한 어휘(ER · Neo4j · Cypher) 와 포털 어휘의 대응
- 1 컬렉션 = 1 온톨로지 스코프 규칙, 그리고 분석가 · 엔지니어와의 경계
다음 레슨
다음 레슨에서 첫 표면인 Modeling 빌더 로 들어가 엔티티 한 개를 직접 정의합니다. 이름 · 별칭 · Identity Keys · Display Column · 속성 타입 6 종이 한 자리에 모입니다.