온톨로지개념정리

14 Jul 2026 in Blog / AI on 온톨로지

• 1. 전체 개념 구조
  • RDF와 LPG의 공통점
  • 차이점
• 2. 용어 구분
• 3. 온톨로지란?
  • 3.1 Class
  • 3.2 Individual
  • 3.3 TBox와 ABox
  • 3.4 Object Property와 Datatype Property
  • 3.5 Axiom
• 4. Domain과 Range의 의미

1. 전체 개념 구조

온톨로지, RDF, Neo4j, Neptune은 동일한 계층의 개념이 아니다.

‘도메인 지식과 의미 규칙 -> 온톨로지 -> 표현모델: RDF, LPG -> 저장 제품: Neo4j, Neptune -> 질의 언어: Cypher, SPARQL, Gremlin -> 응용: Text-to-Cypher, GraphRAG, Knowledge Graph’

RDF와 LPG는 모두 개체와 관계를 그래프로 표현할 수 있지만 데이터 모델과 목적이 다릅니다. 계약정보 도메인은 관계 속성이 많고 Text-toCypher 기반 애플리케이션 개발이 목적이기 때문에 Neo4j LPG를 선택했지만 표준 온톨로지 연계나 OWL추론이 필요할 경우 RDF모델을 고려할 수 있어야한다고 생각합니다.

RDF와 LPG의 공통점

감액완납 → 요구조건 → 상태조건 상태조건 → 허용상태 → 정상

RDF: aia:감액완납 aia:요구조건 aia:상태조건1 . aia:상태조건1 aia:허용상태 aia:정상 .

Neo4j LPG: (:업무유형 {이름:”감액완납”}) -[:요구조건]-> (:규정조건 {이름:”상태조건1”}) -[:허용상태]-> (:계약상태 {값:”정상”})

둘 다:

• 개체가 있음
• 개체를 관계로 연결함
• 여러 홉을 탐색할 수 있음
• Knowledge Graph를 구축할 수 있음
• GraphRAG에 사용할 수 있음

차이점

RDF는 웹 표준과 의미론 중심이고, LPG는 애플리케이션 탐색과 속성 그래프 중심이야.

구분 RDF LPG ━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 기본 단위 Subject-Predicate-Object Node-Relationship-Node ───────────── ────────────────────────── ─────────────────────────────────── 식별 전역 IRI DB 내부 ID·업무 키 ───────────── ────────────────────────── ─────────────────────────────────── 관계 속성 중간 개체 등으로 표현 관계에 바로 저장 ───────────── ────────────────────────── ─────────────────────────────────── 표준 의미론 RDFS·OWL 별도 구현 ───────────── ────────────────────────── ─────────────────────────────────── 검증 SHACL DB Constraint·코드 ───────────── ────────────────────────── ─────────────────────────────────── 질의 SPARQL Cypher·Gremlin ───────────── ────────────────────────── ─────────────────────────────────── 주된 강점 표준화·데이터 통합·추론 직관적 모델링·빠른 탐색·개발 편의

그래서 다음처럼 이해하면 정확해.

그래프 데이터 모델 ├─ RDF │ ├─ SPARQL │ ├─ RDFS │ ├─ OWL │ └─ SHACL(셰클) │ └─ LPG ├─ Cypher ├─ Neo4j ├─ Node/Relationship Property └─ Constraint/Validator

———

두개의 가장 큰 차이점. RDFS,OWL 기반 추론이 필요할 때 예를 들어 다음 클래스 구조가 있다고 하자. 감액완납 subClassOf 계약변경 계약변경 subClassOf 계약업무

신청1이 감액완납 업무라면 reasoner가 다음도 자동으로 추론할 수 있어. 신청1은 계약변경이다. 신청1은 계약업무이다.

또 다음과 같은 의미 규칙도 표현할 수 있어.

• 역관계
• 대칭 관계
• 전이 관계
• 동치 클래스
• 배타 클래스
• 클래스 조합
• 관계 개수 제한
• 어떤 조건을 만족하는 개체의 자동 분류

따라서 저장된 사실을 조회하는 것뿐 아니라, 명시되지 않은 사실을 논리 규칙으로 도출해야 하는 요구가 있다면 RDF+OWL을 검토할 만 하다. 다만 RDF를 사용한다고 자동으로 OWL 추론이 실행되는 것은 아니고, OWL을 지원하는 reasoner가 추가로 필요하다

---

## 3. 여러 시스템이 공통 의미를 공유해야 할 때

예를 들어 시스템마다 같은 대상을 다르게 부를 수 있어.

시스템 A: 계약자 시스템 B: 보험계약소유자 시스템 C: PolicyHolder

RDF에서는 각각의 IRI와 개념 간 관계를 정의할 수 있어.

aia:계약자 owl:equivalentClass partner:PolicyHolder .

이처럼 데이터의 컬럼 구조만 맞추는 것이 아니라 개념의 의미까지 정렬해야 하는 데이터 통합에 적합해.

———

## 4. 데이터 교환과 상호운용성이 중요할 때

RDF는 W3C 표준이므로 특정 DB 제품에 덜 종속적이야.

RDF 데이터 ├─ Amazon Neptune ├─ GraphDB ├─ Stardog ├─ Apache Jena └─ RDFox

Turtle이나 N-Triples로 내보내면 다른 RDF 저장소로 이전하거나 다른 기관에 제공하기 편해.

반면 Neo4j LPG는 노드·관계 데이터를 내보낼 수는 있지만 관계 속성, 제약, 프로시저, Cypher 구현이 Neo4j 방식에 더 의존해.

———

## 5. 지식의 출처와 문맥을 세밀하게 관리할 때

RDF Dataset과 Named Graph를 사용하면 출처별로 사실을 구분할 수 있어.

문서 A에서 주장한 사실 문서 B에서 주장한 사실 2024년 규정 2026년 규정

보험·법률·의료처럼 다음 질문이 중요한 영역에 적합해.

• 누가 주장한 사실인가?
• 어느 문서에 있는가?
• 언제부터 유효한가?
• 어떤 규정 버전인가?
• 다른 자료와 충돌하는가?

물론 LPG에서도 출처 노드와 관계로 구현할 수 있지만, RDF는 출처가 다른 그래프를 구분하고 교환하는 표준 체계가 잘 마련돼 있다는 장점이 있어.

———

# 관계 속성이 적으면 RDF가 좋은가?

관계 속성이 적으면 RDF 트리플로 자연스럽게 표현하기 쉬운 것은 맞아.

예를 들어:

감액완납 isA 계약변경 계약자 신청한다 감액완납 감액완납 요구한다 신청서

이런 단순한 이항 관계는 RDF와 잘 맞아.

aia:감액완납 rdfs:subClassOf aia:계약변경 . aia:감액완납 aia:요구서류 aia:신청서 .

하지만 이것은 부가적인 판단 기준이야.

관계 속성이 많아도 RDF를 사용할 수 있어. 다만 중간 개체를 만들어야 해서 모델이 복잡해질 수 있어.

## LPG

(:업무유형 {이름:”감액완납”}) -[:요구서류 { 채널:”전화”, 적용역할:”계약자”, 필수여부:true, 시행일:”2026-01-01”, 출처:”문서5-1” }]-> (:구비서류 {이름:”신청서”})

## RDF

aia:서류요구규칙1 a aia:서류요구규칙 ; aia:대상업무 aia:감액완납 ; aia:요구서류 aia:신청서 ; aia:채널 aia:전화 ; aia:적용역할 aia:계약자 ; aia:필수여부 true ; aia:시행일 “2026-01-01”^^xsd:date ; aia:출처 aia:문서5-1 .

RDF에서도 충분히 표현되지만 감액완납-요구서류-신청서라는 관계를 서류요구규칙1이라는 개체로 승격한 거야.

따라서:

• 관계 속성이 단순함 → RDF 트리플로 간결하게 표현하기 쉬움
• 관계 속성이 복잡함 → RDF에서는 규칙·사건·상황을 별도 개체로 모델링
• 관계 속성이 많음 → LPG가 더 직관적일 수 있음

하지만 관계 속성 개수만 보고 RDF/LPG를 결정하면 안 돼.

———

# 실질적인 선택 기준

요구사항 RDF가 유리 LPG가 유리 ━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━ ━━━━━━━━━━━━ 기존 RDF 데이터 활용 ✓ ───────────────────────── ──────────── ──────────── 표준 온톨로지 재사용 ✓ ───────────────────────── ──────────── ──────────── 여러 기관과 데이터 교환 ✓ ───────────────────────── ──────────── ──────────── IRI 기반 개념 통합 ✓ ───────────────────────── ──────────── ──────────── OWL 추론 ✓ ───────────────────────── ──────────── ──────────── SPARQL 활용 ✓ ───────────────────────── ──────────── ──────────── 관계 속성이 많음 ✓ ───────────────────────── ──────────── ──────────── 애플리케이션 중심 개발 ✓ ───────────────────────── ──────────── ──────────── 경로 탐색이 핵심 ✓ ───────────────────────── ──────────── ──────────── Cypher 개발 편의성 ✓ ───────────────────────── ──────────── ──────────── 빠른 PoC ✓ ───────────────────────── ──────────── ──────────── Neo4j Vector 결합 ✓ ───────────────────────── ──────────── ──────────── 외부 표준 연계가 없음 ✓

———

# 보험 프로젝트에 적용하면

현재 네 프로젝트의 핵심 요구는:

• 내부 문서 21개에서 규칙 추출
• 업무유형·상태·채널·서류 관계 탐색
• 관계에 허용여부, 채널, 적용역할, 효과유형 저장
• Text-to-Cypher
• Neo4j Vector Index
• 빠른 평가와 수정

그래서 현재는 LPG가 더 실용적인 선택이야.

반대로 다음 요구가 생기면 RDF 전환 또는 RDF 병행을 검토할 수 있어.

• 전사 공통 보험 온톨로지를 여러 시스템에서 공유
• 다른 보험사·공공기관 표준 데이터와 연결
• 상품·계약·고객 개념을 IRI로 통합
• OWL로 개체 자동 분류 및 규정 모순 검출
• RDF/SPARQL 기반 시스템과 연계
• 데이터 교환 표준 준수
• 별도 reasoner를 이용한 논리 추론

이사님께는 이렇게 답하면 정확해.

RDF는 기존 RDF 데이터나 표준 온톨로지를 재사용하고, 여러 시스템 간 의미를 IRI로 통합하거나 OWL 기반 추론이 필요한 경우 특히 적합하다고 이해했습니다. 관계 속성이 적으 면 기본 트리플로 간결하게 표현할 수 있다는 장점은 있지만, 그것만이 선택 기준은 아닙니다. 관계에 부가 정보가 많아도 규칙이나 사건을 별도 개체로 승격해 RDF로 표현할 수 있습니다. 현재 프로젝트는 관계 속성이 많고 Text-to-Cypher와 애플리케이션 탐색이 중심이어서 LPG를 선택했지만, 향후 표준 온톨로지 연계나 의미 추론 요구가 커지면 RDF 또 는 두 모델의 병행을 검토할 수 있습니다.

2. 용어 구분

용어	의미	현재 프로젝트 예시
Vocabulary	표준 단어 목록	감액완납, 실효, 부활보험료
Taxonomy	상위·하위 분류 구조	계약변경 → 감액 → 감액완납
Schema	데이터가 가질 구조와 타입	업무유형-요구조건-규정조건
Ontology	개념, 관계, 제약, 의미 규칙을 명시한 모델	어떤 상태에서 어떤 업무가 허용되는가
Knowledge Graph	온톨로지나 스키마에 따라 실제 사실을 연결한 그래프	감액완납-요구조건-정상상태
Graph DB	그래프를 저장·조회하는 제품	Neo4j, Amazon Neptune
GraphRAG	그래프 검색 결과를 LLM 답변 근거로 사용	Text-to-Cypher 결과로 답변 생성

온톨로지는 DB 제품이 아니다.

• 온톨로지: 의미를 어떻게 정의할 것인가
• RDF/LPG: 의미를 어떤 구조로 표현할 것인가
• Neo4j/Neptune: 어디에 저장하고 어떻게 조회할 것인가

3. 온톨로지란?

온톨로지는 단순히 키워드를 추출해 클래스와 관계로 만드는 작업이 아닌 특정 도메인의 개념, 개념 간 관계, 속성, 제약, 공리와 해석 규칙을 명시적으로 정의한 지식 모델

3.1 Class

같은 특성을 가진 개체의 집합이다.

• 계약
• 당사자
• 업무유형
• 계약상태
• 규정조건
• 신청채널
• 구비서류

ex. 업무유형은 클래스이고 감액완납은 해당 클래스의 인스턴스이다.

업무유형                    Class
 ├─ 감액완납                Individual
 ├─ 연장정기                Individual
 └─ 일반부활                Individual

3.2 Individual

클래스에 속하는 실제 개체다.

감액완납 rdf:type 업무유형
실효     rdf:type 계약상태
전화     rdf:type 신청채널

3.3 TBox와 ABox

• TBox: 클래스와 관계 정의, 즉 지식의 뼈대
• ABox: 실제 개체와 사실

TBox
업무유형 -[요구조건]-> 규정조건
규정조건 -[허용상태]-> 계약상태

ABox
감액완납 -[요구조건]-> 감액완납_상태조건
감액완납_상태조건 -[허용상태 {허용여부:true}]-> 정상

schema.py의 CLASSES, RELATIONS, domain, range는 주로 TBox 역할을 하고, Neo4j에 적재된 감액완납·정상·전화 등은 ABox 역할을 한다.

3.4 Object Property와 Datatype Property

Object Property는 개체와 개체를 연결한다.

감액완납 → 요구조건 → 상태조건1
상태조건1 → 허용상태 → 정상
감액완납 → 접수채널 → 전화

Datatype Property는 개체와 문자열·숫자·날짜 같은 값을 연결한다.

계약 → 계약번호 → "10002634"
규정조건 → 내용 → "정상 계약에서만 가능"
계약 → 보험료 → 100000

Neo4j에서는 보통 Object Property를 관계로, Datatype Property를 노드 속성으로 구현한다.

3.5 Axiom

온톨로지를 단순 스키마보다 강하게 만드는 부분이다.

감액완납은 계약변경의 하위 클래스이다.
실효상태와 정상상태는 동시에 성립할 수 없다.
계약자이다의 역관계는 계약을소유한다이다.
진행하지않는다는 방향성이 있다.
모든 감액완납 업무는 최소 하나의 요구조건을 가져야 한다.

대표적인 공리는 다음과 같다.

• subClassOf: 하위 클래스
• equivalentClass: 동치 클래스
• disjointWith: 서로 동시에 속할 수 없는 클래스
• inverseOf: 역관계
• TransitiveProperty: 전이 관계
• SymmetricProperty: 대칭 관계
• Cardinality: 관계의 최소·최대 개수
• Domain/Range: 관계 주체와 대상의 의미

---

4. Domain과 Range의 의미

현재 스키마에는 다음과 같은 정의가 있다.

{
    "name": "요구조건",
    "domain": "업무유형",
    "range": "규정조건",
}

현재 애플리케이션은 이를 다음 모양만 허용하는 검증 제약으로 사용한다.

(:업무유형)-[:요구조건]->(:규정조건)

그러나 RDF/OWL의 domain·range는 반드시 검증 제약으로 작동하는 것은 아니다.

A 요구조건 B라는 사실과 요구조건 domain 업무유형이 정의되어 있으면, OWL reasoner는 A는 업무유형이다라고 추론할 수 있다. A가 업무유형이 아니라고 즉시 오류를 발생시키는 것이 아니다.

• OWL/RDFS domain-range: 의미와 추론
• SHACL domain-range 제약: 데이터 검증
• Pydantic validator: 애플리케이션 수준 검증
• Neo4j constraint: DB 수준의 일부 무결성 검증

현재 domain/range validator는 OWL 추론보다 SHACL의 검증 역할에 더 가깝다.

---