OntoBricks로 이해하는 온톨로지 ③ 구성 — 설정부터 공개까지

📚 시리즈
① 개념 — 온톨로지와 지식 그래프 첫걸음
② 이해 — OntoBricks란
③ 구성 — 설정부터 공개까지 (현재 글)
④ 데모 — GraphQL·자연어·MCP 질의

이번 편에서는 가상 금융그룹 데이터로 OntoBricks를 배포하고, 온톨로지를 만들고, 테이블에 매핑해 그래프를 만들고, 추론·검증을 거쳐 공개하는 데까지 실제 화면으로 따라갑니다. 화면은 OntoBricks v0.8.1 기준입니다.

---

 

1. 앱 배포와 레지스트리 초기화

OntoBricks 저장소의 배포 스크립트가 앱 두 개(웹 UI, MCP 서버)를 Databricks Apps로 올립니다. 순서는 다음과 같습니다.

git clone https://github.com/databrickslabs/ontobricks && cd ontobricks

# ① Lakebase 프로젝트 준비 (레지스트리용 Postgres)
bash scripts/bootstrap/setup-lakebase.sh --profile <프로파일> --name ontobricks-demo

# ② scripts/deploy.config.sh 에 워크스페이스 값 입력
#    프로파일, SQL Warehouse ID, 레지스트리 catalog/schema/volume, Lakebase 프로젝트·DB·스키마

# ③ 배포 (앱 2개 생성·시작)
make deploy

# ④ 앱 서비스 프린시펄에 Lakebase 권한 부여
make bootstrap-lakebase

앱에 처음 접속하면 레지스트리가 비어 있습니다. Settings → Registry에서 Initialize를 누르면 Lakebase에 레지스트리 테이블이 만들어집니다. 초기화한 뒤에는 make bootstrap-lakebase를 한 번 더 실행해, 새로 생긴 스키마에도 앱 권한을 줍니다.

화면 위쪽은 Unity Catalog 쪽 설정입니다. 트리플 뷰가 만들어질 스키마와, 업로드 문서를 둘 Volume입니다. 아래쪽 Lakebase Connection은 앱 리소스 바인딩으로 연결된 레지스트리 DB입니다. 둘 다 배포 설정에서 정해지므로 화면에서는 읽기 전용입니다.

⚠️ 그래프 백엔드로 Lakehouse를 골라도 레지스트리는 Lakebase에 있으므로, Lakebase를 쓸 수 있는 리전에 배포해야 합니다.

 

2. 원천 테이블 준비

데모 데이터는 가상의 도토리금융그룹입니다. 테이블 6개를 Unity Catalog에 만들었습니다.

테이블	행 수	내용
company	10	회사. 지주·증권·자산운용·보험·캐피탈·은행·부동산·기술
control	9	지배 관계 parent_company_id → child_company_id, 지분율
person	10	인물
executive	10	임원 관계 person_id → company_id, 직위
product	15	금융상품, 위험등급(1~6)
sells	27	판매 관계 company_id → product_id

 

지배 구조는 일부러 두 단계로 만들었습니다. 도토리홀딩스가 7개 회사를 직접 지배하고, 그중 도토리증권이 도토리플러스자산운용과 도토리프리미엄증권을 다시 지배합니다. 임원이 한 명도 없는 회사도 세 곳 넣었습니다. "직·간접 지배"처럼 관계를 여러 단계 따라가는 질문과, "임원이 없는 계열사"처럼 없는 것을 찾는 질문을 시험하기 위해서입니다.

테이블을 만들 때 두 가지를 고려했습니다.

• 테이블·컬럼 COMMENT: 예를 들어 company_type에 '지주/증권/자산운용/보험/캐피탈/은행'처럼 값의 의미를 적었습니다. LLM이 온톨로지와 매핑을 만들 때 가장 많이 참고하는 정보입니다.
• PK/FK 제약: control.parent_company_id → company.company_id 같은 관계를 선언했습니다. Unity Catalog의 PK/FK는 강제되지 않는 정보성 제약이지만, 관계를 추측하는 근거가 됩니다.

 

3. 도메인 만들기와 테이블 연결

OntoBricks에서 온톨로지·매핑·그래프를 묶는 단위를 도메인이라고 합니다. Domain → Information에서 이름(Dotori)과 LLM 엔드포인트를 정하고 저장합니다.

위쪽 카드에 엔티티·관계·매핑 개수, 상태(Draft/Published), 버전이 보입니다. 아래 탭에서 기본 정보(Global), LLM 설정(AI), 그래프 백엔드(Knowledge Graph), MCP 공개 범위(MCP)를 정합니다.

Knowledge Graph 탭에서 그래프 백엔드를 고릅니다. 이 데모는 Lakehouse(UC Delta)로 진행했습니다.

다음은 원천 테이블 연결입니다. Domain → Data Sources → Add Data Source에서 catalog와 schema를 고르면 테이블 구조와 설명을 읽어 옵니다.

Table Descriptions와 Column Descriptions 게이지가 설명이 채워진 비율을 보여 줍니다. 이 데모는 테이블 설명이 100%, 컬럼 설명이 71%(28개 중 20개)입니다. 설명이 빈 컬럼은 이 화면에서 바로 채울 수 있습니다.

 

4. 온톨로지 생성과 검토

 

4.1 Wizard로 초안 만들기

Ontology → Generate가 LLM으로 온톨로지 초안을 만드는 화면입니다.

탭	넣은 것
Data Sources	테이블 6개 전부
Documents	없음 (올린 문서가 있으면 참고 자료로 쓴다)
Guidelines	원하는 클래스와 관계를 짧게 적었다 (아래)
Options	기본값 (속성·관계·상속 생성)

 

Financial group ontology. Classes: Company (with FinancialCompany as subclass for
securities/asset management/insurance/capital/bank), Person, Product.
Relationships: controls (Company→Company, from the control table; transitive),
isControlledBy (inverse of controls), executiveOf (Person→Company, from executive),
sells (Company→Product, from sells).
Datatype properties: riskGrade (Product, integer), sharePct on control.
Use Korean names as rdfs:label.

Generate Ontology를 누르고 1~2분 기다리면 초안이 나옵니다.

 

4.2 결과 확인: Designer와 Entities

Designer는 온톨로지를 그래프로 보여 줍니다. 클래스는 노드, 관계는 화살표, 상속은 점선입니다. 노드를 클릭하면 오른쪽 패널에서 이름, 라벨, 상속, 설명, 속성을 바로 고칠 수 있습니다.

생성 결과를 정리하면 다음과 같습니다.

구분	결과
클래스 (5)	회사(Company), 금융회사(Financialcompany), 지주회사(Holdingcompany), 인물(Person), 상품(Product)
상속	금융회사·지주회사 ⊂ 회사. 지주회사는 가이드라인에 없었는데, LLM이 company_type 값을 보고 추가했습니다
관계 (4)	controls, iscontrolledby, executiveof, sells
속성	riskgrade, sharepct, companytype 등 20개

 

control, executive, sells 테이블은 클래스가 아니라 관계가 됐습니다. 연결 테이블을 관계로 해석한 것으로, 의도한 결과입니다.

Entities는 클래스를 상속 계층으로 보여 줍니다.

 

4.3 관계의 성질 정하기: Transitive와 역관계

"지배의 지배는 지배"라는 성질은 사람이 확인하고 정해야 합니다. ②편에서 말한 "LLM이 만들고 사람이 승인한다"에서 사람이 확인할 부분이 바로 여기입니다.

• Transitive: Relationships → controls → Constraints의 Property Characteristics에서 켭니다.
• 역관계: Expr. & Axioms → + Axiom → Inverse Of에서 iscontrolledby를 controls의 역관계로 지정합니다. 관계의 Description에 "Inverse of controls"라고 적혀 있어도 그것은 설명일 뿐이고, 추론기가 쓰는 공리는 Axiom으로 따로 넣어야 합니다.

결과는 OWL 메뉴에서 Turtle로 확인할 수 있습니다.

⚠️ 위쪽에 Resume editing 버튼이 보이고 Save가 회색이면 보기 모드입니다. Resume editing을 눌러야 편집과 저장이 됩니다.

 

5. 매핑

Mapping → Auto-Map → Start Auto-Map을 누르면, LLM 에이전트가 클래스·관계마다 SQL을 만들고 실제로 실행해 검증합니다. 진행 중에 Agent activity log를 펼치면 에이전트가 어떤 도구를 불러 무엇을 확인하는지 볼 수 있습니다.

끝나면 Information의 세 게이지(엔티티·속성·관계)가 100%가 되고, 위쪽 Mapping 표시가 초록으로 바뀝니다.

Mapping → Designer에서는 매핑 상태가 색으로 보입니다. 초록은 매핑 완료, 주황은 일부 속성 누락, 빨강은 매핑 안 됨입니다. 노드를 클릭하면 실제 SQL을 보고 고칠 수 있습니다.

💡 하위 클래스 매핑 주의: Auto-Map은 회사(Company)와 하위 클래스(금융회사, 지주회사)를 각각 매핑했습니다. 그 결과 도토리홀딩스가 Company/1, Financialcompany/1, Holdingcompany/1이라는 서로 다른 URI 세 개로 만들어졌습니다. 같은 회사를 한 노드로 두려면 하위 클래스 매핑도 같은 URI 규칙(예: Company/{company_id})을 쓰도록 SQL을 고쳐야 합니다.

 

6. 빌드

Knowledge Graph → Build 화면의 오른쪽 위 Build 버튼을 누르면 매핑 SQL이 실행되어 트리플이 만들어집니다.

이 데모는 297개 트리플이 만들어졌습니다. 관계별로 보면 controls 9개, iscontrolledby 9개, executiveof 10개, sells 27개이고, 나머지는 타입·라벨·속성 값입니다. 결과는 triplestore_dotori_V1_data Delta 테이블에 저장됩니다.

원천 테이블에는 직접 지배만 들어 있으므로, 이 단계의 그래프에서 도토리홀딩스와 간접 자회사(도토리프리미엄증권, 도토리플러스자산운용)는 직접 연결되어 있지 않습니다. 이 둘을 잇는 방법은 7장의 추론과 ④편의 질의에서 봅니다.

 

7. 추론

Knowledge Graph → Inference에서 Run을 누르면 여러 추론 단계가 차례로 실행됩니다.

단계	하는 일	이번 결과
T-Box (OWL 2 RL)	온톨로지 정의 자체에 OWL 2 RL 규칙을 적용	81개. 모두 스키마 수준 사실(예: domain·range 정리, subClassOf Thing)
SWRL Inference	사용자가 정의한 IF-THEN 규칙	규칙이 없어 건너뜀
Graph Inference	전이(Transitive)·대칭(Symmetric) 관계를 그래프 데이터에 적용	새 사실 없음
Decision Tables, SPARQL CONSTRUCT, Aggregate Rules	표 형식 규칙, 그래프 패턴 규칙, 집계 규칙	정의가 없어 건너뜀

 

"지배의 지배는 지배"라는 규칙으로 기대한 "도토리홀딩스 → 도토리플러스자산운용" 같은 간접 지배 사실은 만들어지지 않았습니다.

⚠️ v0.8.1에서 확인한 동작 - controls의 Transitive 설정은 온톨로지의 제약 목록(constraints)에 저장되고, OWL 출력에도 owl:TransitiveProperty로 나옵니다. - 그런데 Graph Inference 단계는 관계 정의의 다른 필드(characteristics)에서 전이 관계를 찾습니다. 이 필드는 비어 있어서, 전이 관계가 하나도 없는 것으로 처리됩니다. - T-Box 단계는 온톨로지 정의에만 추론을 적용하고, 그래프의 인스턴스(회사 사이의 사실)에는 적용하지 않습니다. - 그래서 화면에서 Transitive를 켜도, 이 버전에서는 간접 지배가 그래프에 사실로 추가되지 않았습니다.

간접 지배를 묻는 질문에 어떻게 답하는지는 ④편의 자연어 질의(Chat)에서 봅니다.

 

8. 검증 (SHACL)

OWL 추론이 새 사실을 만든다면, SHACL은 규칙 위반을 찾습니다. OntoBricks에서는 Ontology → Data Quality에서 규칙을 정하고, Knowledge Graph → Data Quality에서 실행합니다.

규칙은 여섯 범주로 나뉩니다.

범주	검사하는 것	예
Completeness	필수 값이 있는가	모든 상품에 위험등급이 있다
Cardinality	값의 개수	전화번호는 최대 3개
Uniqueness	중복이 없는가
Consistency	관계 대상의 타입이 맞는가	sells의 대상은 상품이다
Conformance	형식·범위	위험등급은 1~6 사이다
Structural	그래프 구조	전이·반사 관계의 정합성

 

이번에는 두 규칙을 넣었습니다. Add Rule을 누르고 대상 클래스와 속성을 고르면 SHACL Turtle이 자동으로 만들어집니다.

범주	대상	규칙
Completeness	Product.riskgrade	반드시 있어야 한다 (sh:minCount 1)
Conformance	Product.riskgrade	1 이상 6 이하 (sh:minInclusive 1, sh:maxInclusive 6)

 

Knowledge Graph → Data Quality → Run으로 실행하면 규칙마다 통과율이 나옵니다. 규칙은 SQL로 바뀌어 트리플 뷰에 실행되고, 위반이 있으면 해당 엔티티가 표시됩니다.

상품 15개가 모두 규칙을 지켜 두 규칙 모두 100%가 나왔습니다. 검증 대상은 원천 테이블에서 매핑된 트리플뿐이고, 추론으로 만든 트리플은 검사하지 않습니다.

 

9. 공개 (Publication)

온톨로지는 버전(v1, v2 …)으로 관리되고, API와 MCP는 Published 상태인 최신 버전만 내보냅니다. 이 절차를 거치는 이유는 세 가지입니다.

• 작업본과 서비스본을 나눕니다. 편집 중인 온톨로지가 에이전트 답변에 섞이지 않습니다.
• 잘못된 규칙이 퍼지기 전에 막습니다. domain/range나 전이 관계를 잘못 정하면 그래프 전체에 틀린 사실이 추론됩니다. 공개 전에 업무를 아는 사람이 확인합니다.
• 승인 기록이 남습니다. 누가 언제 제출하고 승인했는지가 Audit trail에 남습니다.

상태는 Domain → Publication에서 바꿉니다.

단계	버튼	조건
Draft → In Review	Submit	빌드가 한 번 이상 성공해야 한다
In Review → Published	승인 후 Publish	승인 수가 Sign-off quorum(이번에는 1명)을 채워야 한다

 

In Review가 되면 온톨로지와 매핑 편집이 잠깁니다. 빌드, 추론, Explorer, 질의는 계속 쓸 수 있습니다. 화면의 Consistency checks는 온톨로지 유효성, 매핑 완료, 웨어하우스 설정, 그래프 빌드 여부를 보여 주고, Audit trail에는 제출·승인·공개 기록이 남습니다.

⚠️ 빌드가 성공했는데도 Publication 화면에 "This version has never been built"가 나오면, 레지스트리의 버전 행에 빌드 시각(last_build)이 기록되지 않은 것입니다. 이번 데모에서 이 경우가 생겨, 레지스트리(Lakebase)의 해당 행에 마지막 성공 빌드 시각을 직접 기록한 뒤 진행했습니다.

---

 

정리

단계	사람이 한 일	LLM·앱이 한 일
배포	설정 파일 작성, 스크립트 실행, 레지스트리 초기화	앱 2개 배포
테이블	COMMENT와 PK/FK 작성	—
온톨로지	가이드라인 작성, 관계 성질(Transitive·역관계) 확인	클래스·관계·속성 초안 생성
매핑	결과 확인	매핑 SQL 생성·검증
빌드	Build 클릭	트리플 297개 생성
추론·검증	관계 성질 확인, SHACL 규칙 작성	추론 실행, 규칙을 SQL로 바꿔 검사
공개	제출·승인·Publish	승인 기록, API·MCP 공개

 

다음 글 ④ 데모에서는 공개된 그래프를 Explorer로 탐색하고, GraphQL, 자연어(Chat), MCP로 질의합니다.