앱 안에서 어떤 부품이 어떤 일을 하는지, 데이터가 어디에 있고 어떻게 흐르는지 그림 한 장으로 정리합니다. 이 장을 알아 두면 뒤의 실습에서 “지금 무엇을 건드리는지”가 보입니다.
부품 지도#
┌──────────────────────── Ontological Studio (데스크톱 앱) ────────────────────────┐
│ │
│ 화면: 홈 · 온톨로지 구축 · 질의·액션 · 데이터소스 · 온톨로지 앱 · 시스템 등록 │
│ Ontological Portal (Cypher 콘솔) │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ Studio 백엔드·에이전트 ──Bolt──▶ Ontological DB ◀──Bolt── 포털 액션 실행기 │
│ (구축·질의·대시보드) (그래프 엔진 = PostgreSQL 확장) (kinetic-action) │
│ │ 데이터 패브릭 │ │
│ ▼ ▼ │
│ 원천 DB: ERP · WMS · CRM ◀── 고친다 ── 예제 업무 시스템 │
│ (복사하지 않고 그 자리에서 읽음) (ERP·WMS·CRM API) │
└────────────────────────────────────────────────────────────────────────────────────┘
| 부품 | 하는 일 |
|---|---|
| Ontological DB | 온톨로지를 저장하고 Cypher를 실행하는 그래프 데이터베이스입니다. PostgreSQL의 확장이라, 그래프 질의가 PostgreSQL의 SQL로 번역되어 실행됩니다. 바이템포럴(시간 여행), 권한, 스키마 진화도 여기서 처리합니다. |
| 데이터 패브릭 | Ontological DB 안의 기능입니다. 다른 데이터베이스의 테이블을 복사하지 않고 그래프의 노드처럼 보이게 합니다(가상 노드). |
| Bolt 게이트웨이 | Neo4j와 같은 Bolt 프로토콜 입구입니다. Studio와 포털은 모두 이 길로 그래프를 읽고 씁니다. |
| Studio | 온톨로지 구축·질의·대시보드 화면과 그 뒤의 에이전트입니다. |
| 액션 실행기 | 액션을 계획하고, 정책을 판정하고, 사람의 승인을 받아 업무 시스템 API를 부르고, 취소하면 역순으로 되돌립니다. |
| 예제 업무 시스템 | 구매 ERP·물류 WMS·고객 CRM. 각자 다른 인증 방식을 쓰는 작은 REST 서비스입니다. 액션이 이들을 부르면, 원천 DB의 값이 바뀝니다. |
그래프가 두 개 있습니다#
Ontological DB 안에는 여러 그래프(독립된 데이터 공간)를 둘 수 있습니다. 처음 설치하면 두 개가 보입니다.
| 그래프 | 무엇이 들어 있나 | 주로 쓰는 곳 |
|---|---|---|
sample |
예제 원천 DB의 테이블을 그대로 노출한 가상 노드와 가상 관계 | 데이터소스 탭, 포털의 Cypher 실습(4부) |
ontology |
Studio가 구축한 온톨로지: 클래스 정의, 인스턴스, 관계, 액션 정의 | 질의·액션, 온톨로지 앱(5~7부) |
sample은 “원천을 있는 그대로 비춘 거울”이고, ontology는 “업무 관점으로 정리한 지식”입니다. 예를 들어 ontology에는 원천에 없는 SHIPPED_BY(선적→협력사) 관계가 있고, 클래스와 속성마다 설명이 붙어 있으며, 액션이 달려 있습니다.
왜 나눠 두나요?
원천의 테이블 이름과 온톨로지의 클래스 이름이 같은 일이 많습니다(Supplier). 둘을 한 그래프에 두면 읽기 전용 가상 노드와 구축한 노드가 부딪힙니다. 그래서 예제는 가상 노드를 sample 그래프에 따로 둡니다.
질문 하나가 지나가는 길#
“3일 넘게 늦은 선적은?”이라는 질문이 질의·액션 탭에 들어오면:
- 에이전트가 발행된 온톨로지의 스키마를 읽습니다(어떤 클래스·관계·속성이 있나).
- Cypher를 만들어 Bolt로 Ontological DB에 보냅니다.
- Ontological DB가 Cypher를 SQL로 번역해 실행합니다. 데이터 패브릭이 걸린 부분은 원천 DB에 필요한 조건만 붙여 보냅니다.
- 결과와 함께 “어느 노드의 어떤 사실을 근거로 삼았는지”를 답에 적습니다.
지시 하나가 지나가는 길#
“그 선적을 긴급 처리해 줘”라는 지시는 다르게 흐릅니다.
- 에이전트가 이 지시에 맞는 액션(
Shipment.expediteShipment)을 찾습니다. - 액션 실행기에 계획을 요청합니다. 실행기는 대상 선적을 고르고, 대상마다 정책으로 허용·거부를 판정합니다. 아직 아무것도 바뀌지 않습니다.
- 사람이 계획 카드에서 승인합니다.
- 실행기가 업무 시스템 API를 차례로 부릅니다(WMS 우선순위 변경 → ERP 납기 독촉).
- 원천 DB 값이 바뀌고, 데이터 패브릭이 그것을 그대로 읽으므로 그래프에서도 바로 보입니다.
- “취소해 줘”라고 하면 성공한 단계를 역순으로 되돌립니다(보상).
에이전트도, 앱도 업무 시스템을 직접 부르지 않습니다. 언제나 이 실행기를 거칩니다.
확인 문제
- 포털에서
MATCH (s:Supplier) RETURN s를 실행했는데, 그래프 선택이ontology일 때와sample일 때 결과가 어디서 오는지 각각 설명해 보세요. - 액션을 실행한 결과를 확인하려면 업무 시스템에 따로 로그인해야 할까요?
정답 보기
sample이면 ERP의erp.supplier테이블을 그 자리에서 읽은 가상 노드가,ontology면 구축 때 온톨로지에 적재된Supplier인스턴스가 나옵니다.- 아니요. 업무 시스템은 원천 DB를 고치고, 데이터 패브릭은 그 원천을 질의할 때마다 읽으므로 데이터소스 탭이나 포털(
sample그래프)에서 바로 확인할 수 있습니다.