온톨로지 설계 실전 가이드: 저장소 선택부터 객체,이력,권한,추론까지

시작 전에, 1부 "AI 시대, 온톨로지가 다시 주목받는 이유 - 왜 팔란티어는 데이터가 아닌 '의미'를 파는가"를 먼저 참고해주세요 ㅎ

(1부 : https://usr-bin-ksh.tistory.com/1)

 

이번 편에서는 온톨로지를 실제 시스템으로 옮길 때 가장 먼저 마주치는 결정들을 살펴봅니다.

• 온톨로지를 어디에 저장할 것인가
• 무엇을 객체로 만들고 무엇을 속성으로 둘 것인가
• 관계와 파생값을 언제 별도 객체로 승격할 것인가

시작하기 전에 한 가지 원칙부터 짚고 가겠습니다.

온톨로지 설계에서 가장 위험한 것은 틀린 결정이 아닙니다. 결정할 것이 있다는 사실조차 모른 채 지나가는 것입니다.

"이력은 남기지 않기로 했다"는 검토를 거친 선택입니다. 반면 "이력을 아무도 생각하지 않았다"는 선택이 아니라 누락이고, 이런 누락은 시스템을 한참 운영한 뒤에야 드러납니다.

그래서 온톨로지를 구축할 때는 결정해야 할 항목의 목록, 말하자면 설계 결정 카탈로그가 필요합니다.

이 글의 소제목들이 바로 그 카탈로그의 목차입니다.

1. 저장소

온톨로지는 저장 기술이 아닙니다.

따라서 온톨로지의 의미 구조를 실제로 저장하고 조회할 저장소를 따로 골라야 합니다.

실무에서 검토하는 대표적인 선택지는 세 가지입니다.

• 관계형 데이터베이스
• 속성 그래프
• RDF/OWL 기반 시맨틱 그래프

각 기술은 단순히 문법만 다른 것이 아니라, 만들어진 목적과 계보부터 다릅니다.

 

구분	RDB (PostgreSQL 등)	속성 그래프 (Neo4j, Neptune, Memgraph 등)	RDF/OWL (Stardog, Neptune RDF 등)
기본 단위	테이블과 행, 관계는 외래키	노드와 엣지	주어, 술어, 목적어로 구성된 트리플
관계의 속성	조인 테이블로 표현	엣지에 직접 저장	RDF-star 또는 관계 재구체화로 표현
다단계 탐색	조인이 누적됨	연결 관계를 직접 따라감	엔진과 모델링 방식에 따라 편차가 큼
스키마 진화	비교적 경직됨	유연함	정형적이지만 복잡도가 높을 수 있음
형식 추론	기본적으로 없음	기본적으로 없음	OWL 추론기 활용 가능
주요 질의어	SQL, 재귀 CTE	Cypher, openCypher, GQL	SPARQL
집계와 보고	강함	보통	보통 이하
강점	정형 업무 처리와 집계	운영 애플리케이션과 관계 탐색	지식 교환, 표준화, 형식 추론

 

속성 그래프에서 자주 언급되는 index-free adjacency는 연결된 노드를 찾아갈 때 전체 데이터 크기에 비례해 다시 검색할 필요가 적다는 의미입니다. 다만 이것이 모든 그래프 쿼리가 항상 빠르다는 뜻은 아닙니다.

한 노드에서 수십만 개의 관계가 뻗어 있거나, 탐색 중 방문해야 할 노드가 폭증하면 성능은 당연히 떨어집니다. 그래프 쿼리의 비용은 전체 데이터량만이 아니라 팬아웃과 실제 방문 범위에 크게 영향을 받습니다.

LPG와 RDF/OWL 중 무엇을 선택할까

두 방식을 단순히 "그래프 DB 제품 비교"로 보면 판단하기 어렵습니다.

먼저 시스템이 해결하려는 문제를 봐야 합니다.

 

RDF/OWL이 적합한 경우

다음 요구가 핵심이라면 RDF/OWL 계열이 유리합니다.

• 여러 기관이나 시스템 사이에서 지식을 교환해야 한다
• 전역 식별자와 공유 어휘가 중요하다
• 표준 온톨로지를 준수해야 한다
• 클래스 계층과 논리적 일관성을 자동으로 검사해야 한다
• 공공, 의료, 제약, 금융처럼 표준화 요구가 강하다

RDF/OWL의 핵심 가치는 특정 애플리케이션의 편의성보다 지식의 교환 가능성과 형식적 의미 표현에 있습니다.

 

속성 그래프가 적합한 경우

다음 요구가 중심이라면 속성 그래프가 더 실용적일 수 있습니다.

• 한 조직 내부의 운영 애플리케이션을 만든다
• 관계 중심 탐색이 주요 기능이다
• 질의 성능과 개발 속도가 중요하다
• 사용자가 그래프를 직접 탐색하는 UI가 필요하다
• GraphRAG나 관계 기반 추천을 구현한다
• 관계 자체에 상태, 시점, 점수 같은 속성이 많다

팔란티어식 운영 온톨로지도 형식적 분류 체계보다는 객체/관계/액션을 운영에 연결하는 방식이라는 점에서 속성 그래프적 사고와 가까운 면이 있습니다.

물론 두 진영의 경계는 점점 흐려지고 있습니다.

RDF-star는 RDF에서도 관계에 속성을 표현하기 쉽게 만들고 있고, GQL 표준화는 속성 그래프 진영의 질의 언어 파편화를 줄이는 방향으로 진행되고 있습니다.

온톨로지를 PostgreSQL에 담기

이미 PostgreSQL로 구축되어 있는데 그래프 DB로의 마이그레이션은 생각보다 부담스럽고, 기존 PostgreSQL을 이용하는 것이 반드시 나쁜 선택도 아닙니다.

그래프 탐색이 시스템의 전부가 아니거나, 운영 복잡도를 줄이는 것이 더 중요하다면 PostgreSQL 안에서도 충분히 온톨로지형 구조를 구현할 수 있습니다.

대표적인 패턴은 세 가지입니다.

 

패턴 1. 범용 노드, 엣지 테이블

의미 계층과 인스턴스 계층을 다음과 같이 나눕니다.

object_types
link_types

nodes
- id
- type
- properties JSONB

edges
- source_id
- target_id
- type
- properties JSONB

object_types와 link_types는 어떤 객체와 관계가 존재하는지를 정의합니다.

nodes와 edges에는 실제 데이터가 들어갑니다.

구조적으로는 PostgreSQL 안에 속성 그래프를 구현하는 방식입니다. 탐색은 WITH RECURSIVE를 이용합니다.

데이터 규모가 아주 크지 않고, 주된 탐색 깊이가 2~3홉 정도라면 현실적인 선택이 될 수 있습니다.

 

패턴 2. 트리플 테이블

모든 사실을 다음 한 장의 테이블에 넣는 방식입니다.

subject | predicate | object

구조는 단순하지만, RDF 표준과의 호환성이 목적이 아니라면 일반적으로 추천하기 어렵습니다.

조금만 복잡한 질문이 생겨도 같은 테이블을 반복해서 self-join해야 하고, 속성 타입과 제약 조건을 별도로 관리하기도 어렵기 때문입니다.

 

패턴 3. Apache AGE

Apache AGE는 PostgreSQL 위에서 그래프 구조와 openCypher 질의를 사용할 수 있게 하는 확장입니다.

다음 조건을 모두 만족해야 하는 환경에서 현실적인 절충안이 될 수 있습니다.

• 데이터베이스 제품은 PostgreSQL로 유지해야 한다
• 그래프형 데이터 모델이 필요하다
• SQL만으로 재귀 탐색을 구현하기에는 복잡하다
• Cypher 계열 질의를 사용하고 싶다

PostgreSQL 그래프 패턴의 실패 모드

PostgreSQL로 시작하는 것 자체가 문제는 아닙니다.

진짜 문제는 모델링 규율이 무너질 때 발생합니다.

처음에는 범용 노드와 엣지 구조로 시작했지만, 개발이 급해질수록 "이번 것만 그냥 외래키로 새기자"는 결정이 반복됩니다.

그 결과 몇 달 뒤에는 온톨로지 구조가 아니라 일반적인 조인 테이블 더미가 남습니다.

그래프 DB의 숨은 가치는 단순한 성능만이 아닙니다. "관계를 데이터 모델의 1급 개념으로 다루도록 강제하는 것"입니다.

관계를 명시적으로 이름 붙이고, 속성을 부여하고, 탐색 가능한 구조로 유지하게 만드는 모델링 규율 자체가 중요한 가치입니다.

저장 기술 결정 트리

저장소 선택을 단순화하면 다음 질문으로 정리할 수 있습니다.

Q1. 기관 간 지식 교환, 표준 어휘, OWL 기반 자동 추론이 필수인가?
 예 -> RDF/OWL
 아니오 -> Q2 이동

Q2. 다단계 탐색과 관계 중심 질문이 시스템의 핵심 가치인가?
 예 -> 속성 그래프 LPG
 아니오 -> Q3 이동

Q3. 그래프 탐색이 얕고 조직 표준 DB를 벗어나기 어려운가?
 예 -> PostgreSQL 그래프 패턴
 아니오 -> 잘 설계된 일반 RDBMS로 충분할 수 있음

 

마지막 경우에는 온톨로지가 정말 필요한지도 다시 물어야 합니다.

관계 탐색이나 의미 통합보다 단순한 정형 업무 처리가 중심이라면, 온톨로지와 그래프 구조를 도입하는 것이 오히려 과설계가 될 수 있습니다.

2. 모델링할 때 마주치는 결정들

2-1. 어느 수준의 온톨로지를 만들 것인가

개별 객체를 논하기 전에 먼저 정할 것이 있습니다. 지금 만들려는 것이 어느 수준의 온톨로지인가 하는 점입니다.

학계에서는 온톨로지를 추상화 수준에 따라 나눕니다.

• 상위 온톨로지: 모든 도메인에 공통인 최상위 개념. 객체, 사건, 과정 같은 것 (BFO, DOLCE, SUMO)
• 도메인 온톨로지: 금융, 의료, 제조처럼 특정 분야의 개념과 관계
• 태스크 온톨로지: 장애 진단, 추천처럼 특정 활동이 어떻게 수행되는가
• 애플리케이션 온톨로지: 특정 시스템에 맞춘 도메인과 태스크의 결합

기업이 실제로 만드는 것은 대부분 도메인~애플리케이션 온톨로지입니다. 상위 온톨로지는 여러 기관의 온톨로지를 맞춰야 하는 경우에만 필요합니다. 형식성에도 스펙트럼이 있습니다.

용어집 -> 택소노미 -> 시소러스 -> 개념 모델 -> 형식 논리 온톨로지(OWL)

 

시맨틱 웹 진영은 오른쪽 끝만 온톨로지라고 부르지만,

산업계에서는 개념 모델 수준도 온톨로지라고 부릅니다.

팔란티어식 운영 온톨로지도 형식 논리가 아니라 개념 모델에 실행 계층을 얹은 위치에 있습니다.

 

여기서 이 장의 첫 번째 결정이 나옵니다.

우리에게 필요한 것이 기계 추론이 가능한 형식 논리인가, 운영에 연결되는 개념 모델인가.

이 답은 1장의 저장소 선택과도 직결됩니다.

2-2. 무엇을 객체로 승격할 것인가

온톨로지를 설계하다 보면 반복적으로 마주치는 질문이 있습니다.

"이것은 객체인가, 아니면 속성인가?"

모든 명사를 객체로 만드는 것은 답이 아닙니다.

객체가 지나치게 많아지면 그래프는 의미 구조가 아니라 잡동사니 창고가 됩니다.

다음 네 가지 신호 중 하나라도 강하게 나타난다면 객체 승격을 검토할 수 있습니다.

 

(1) 버튼을 달아야 한다

그 개념이 액션의 직접적인 대상이라면 객체가 될 가능성이 높습니다.

예를 들어 '배송'에 대해 다음 행동을 수행해야 한다면 배송은 단순 속성보다 객체에 가깝습니다.

• 배송을 취소한다
• 배송지를 변경한다
• 담당 택배사를 바꾼다

속성 자체에는 액션과 권한, 상태 전이를 자연스럽게 연결하기 어렵습니다.

 

(2) 선을 연결해야 한다

여러 객체가 동일한 개념을 공유하거나, 그 개념을 중심으로 탐색해야 한다면 객체로 분리하는 편이 좋습니다.

예를 들어 상품에 붙는 태그를 단순 문자열 배열로 저장할 수 있습니다.

tags = ["캠핑", "방수"]

하지만 다음 질문에 답해야 한다면 태그는 독립 객체가 되어야 합니다.

• 같은 태그를 가진 상품은 또 무엇인가
• 이 태그는 어떤 카테고리에서 많이 쓰이는가
• 비슷한 태그는 무엇인가

(3) 이력을 쌓아야 한다

그 개념 자체가 버전, 상태, 생애주기를 가진다면 객체로 승격할 이유가 생깁니다.

예를 들어 '추천 점수'가 단순한 숫자가 아니라 다음 정보를 가져야 한다면 별도 객체가 적합합니다.

• 계산 시점
• 사용된 신호
• 계산 공식 버전
• 이전 점수와의 비교

(4) 세거나 탐색하는 단위다

그 개념이 독립적인 집계와 탐색의 기준이 된다면 객체일 가능성이 높습니다.

• 유형별 장애 건수
• 지역별 배송 건수
• 카테고리별 상품 수

이런 질문에서 반복적으로 축이 된다면 속성보다 객체로 표현하는 편이 자연스럽습니다.

보너스: 권한 경계가 다르다

같은 대상 안에서도 일부 정보의 권한 경계가 다르다면 객체 분리를 검토해야 합니다.

예를 들어 고객의 기본 프로필은 누구나 볼 수 있게 하되, 결제 정보는 본인과 고객센터만 볼 수 있게 해야 한다면 결제 정보를 별도 객체로 분리할 수 있습니다.

정리하면 버튼, 연결, 이력, 집계 단위. 하나라도 강하면 객체 승격을 검토합니다.

어느 것도 해당하지 않으면 속성으로 남기는 것이 단순하고 효율적입니다.

2-3. 관계가 객체가 되는 순간

처음에는 다음과 같은 단순한 관계로 충분해 보일 수 있습니다.

(고객)-[관심있음]->(상품)

하지만 요구사항이 구체화되면 상황이 달라집니다.

• 추천 점수가 여러 신호의 가중합으로 계산된다
• 왜 이 점수가 나왔는지 설명해야 한다
• 근거(구매 내역, 리뷰)를 보여줘야 한다
• 계산 공식의 버전을 기록해야 한다
• 재계산될 때마다 이전 결과를 남겨야 한다

이 정도가 되면 관계 하나에 모든 정보를 담기 어렵습니다.

이때 관계를 객체로 승격합니다.

(고객)->(추천 평가)->(상품)

 

추천 평가 객체에는 다음 정보를 저장할 수 있습니다.

• 현재 점수
• 평가 시점
• 사용된 계산식
• 근거 신호
• 계산 모델 버전
• 신뢰도
• 이전 평가와의 연결

그리고 평가 객체를 근거 데이터와 연결할 수 있습니다.

(추천 평가)-[근거로 삼음]->(구매 기록)
(추천 평가)-[근거로 삼음]->(리뷰)

 

이처럼 관계나 사실을 별도 객체로 승격하는 방식을 일반적으로 reification, 즉 재구체화라고 부릅니다.

용어를 하나 정리하고 가겠습니다. 속성 그래프 진영(Neo4j 등)에서는 이렇게 승격된 노드를 intermediate node, 즉 중간 노드라고 부릅니다.

RDF에도 reification이라는 용어가 있지만 결이 다릅니다. RDF의 reification은 트리플에 속성을 붙일 수 없다는 표현력 한계를 메우는 문법적 우회이고, 지금은 RDF-star(RDF 1.2)가 그 역할을 대체해가고 있습니다.

반면 여기서 말하는 승격은 문법 문제가 아니라 "이 관계가 사실은 독립적인 사건이나 엔티티인가"를 묻는 모델링 판단입니다. 같은 단어처럼 보여도 목적이 다릅니다.

 

모든 관계를 객체로 만들면 안 된다

그렇다고 모든 관계를 승격하면 그래프가 지나치게 무거워집니다. 계산되거나 추출된 사실(추천 점수, AI가 뽑아낸 관계)만 근거를 붙여 별도 객체로 만들고, 조직이 직접 확인한 안정적인 사실(배송지, 결제 수단)은 가벼운 관계로 남기는 정도로 나누면 충분합니다.

AI나 알고리즘이 만든 사실은 오류나 재계산 가능성이 있으므로, 언제 어떤 모델로 어떤 신뢰도로 만들어졌는지, 사람의 검토를 받았는지를 답할 수 있어야 합니다. 이런 사실들을 Assertion 같은 공통 유형으로 관리하면 근거가 필요한 주장을 한 번에 조회하고 감사할 수 있습니다.

관계를 객체로 승격할지 말지를 가르는 기준도 결국 앞서 본 객체 승격의 네 가지 신호와 같은 결입니다. 버튼을 달아야 하는가, 이력을 쌓아야 하는가. 관계도 그 질문 앞에서는 객체와 다르지 않습니다.

지금까지 - 저장소와 모델링

지금까지 온톨로지를 시스템으로 옮길 때 마주치는 두 부분에 대해 다뤘습니다.
어디에 저장할 것인가, 그리고 무엇을 객체로 세울 것인가.

두 결정 모두 정답이 하나로 정해져 있지 않다는 공통점이 있습니다.
RDF와 속성 그래프 중 어느 쪽이 무조건 낫다고 할 수 없고, 모든 관계를 객체로 승격해야 하는 것도 아닙니다.
조직의 규모와 요구 사항에 따라 다른 답이 나올 뿐입니다.

더불어 온톨로지 구축에 있어서는 액션과 시뮬레이션을 염두에 두고 권한을 어느 계층에 둘지, 기존 시스템과 어떻게 연결할지도 결정해야 합니다.
이번 글에서는 다루지 않았지만, 온톨로지를 실제로 운영해본 조직이라면 결국 마주치게 되는 질문들입니다.

이 글에서 다룬 결정들 역시 그중 일부일 뿐입니다.

결국 좋은 온톨로지는 처음부터 완성되는 것이 아니라, 실제 시스템과 연결하고 운영하는 과정에서 필요한 결정을 하나씩 쌓아가며 만들어지는것 같습니다.