온톨로지 설계
온톨로지란 무엇인가
온톨로지(Ontology)는 원래 철학에서 “존재론” — 존재하는 것들의 본질과 범주를 다루는 학문을 가리키는 말이었다. 이 개념이 컴퓨터 과학, 특히 지식표현(Knowledge Representation) 분야로 넘어오면서 다음과 같이 재정의되었다.
온톨로지란 특정 도메인 안에 존재하는 개념들과 그 개념들 사이의 관계를, 기계가 처리할 수 있는 형태로 명시적이고 형식적으로 정의한 것이다.
이 정의에서 핵심 단어는 세 가지다.
- 명시적(explicit): 암묵적으로 통용되는 지식이 아니라, 누가 봐도 같은 의미로 해석되도록 문서화·구조화되어 있어야 한다.
- 형식적(formal): 사람의 자연어가 아니라, 기계가 파싱하고 추론할 수 있는 형식(클래스, 관계, 제약)으로 표현되어야 한다.
- 공유(shared): 특정 개인의 사고방식이 아니라, 해당 도메인에 속한 사람들(또는 시스템들)이 공통으로 합의한 개념 체계여야 한다.
이 세 가지가 빠지면 그건 온톨로지가 아니라 그냥 개인적인 메모나 마인드맵에 가깝다.
온톨로지와 비슷한 것들 — 정확히 구분하기
온톨로지는 종종 아래 개념들과 혼동되지만, 명확히 다른 계층에 있다.
| 구조 | 표현 가능한 것 | 한계 |
|---|---|---|
| 어휘(Vocabulary) | 용어 목록 | 관계·의미 없음 |
| 택소노미(Taxonomy) | 계층적 분류 (상위-하위) | 오직 is-a 관계만 표현 가능 |
| 시소러스(Thesaurus) | 동의어, 관련어 | 형식적 의미론 없음 |
| 온톨로지(Ontology) | 클래스, 속성, 임의의 관계, 제약, 추론 규칙 | 설계·유지보수 비용이 큼 |
즉 택소노미는 온톨로지의 부분집합이다. “질병 분류 코드표”처럼 순수하게 대분류-소분류 계층만 있는 데이터는 택소노미이지, 그 자체로는 온톨로지가 아니다. 여기에 “이 질병은 어떤 보장 항목과 연결되는가”, “이 분류는 어떤 법적 근거를 따르는가” 같은 택소노미 외부와의 관계가 추가되어야 비로소 온톨로지가 된다.
온톨로지의 구성 요소
전통적인 지식표현 이론(Gruber, 1993; Noy & McGuinness, 2001)에서 온톨로지는 다음 요소로 구성된다.
1. 클래스 (Class / Concept)
도메인 안에서 공통된 성격을 가진 개체들의 집합. “계약”, “피보험자”, “질병분류” 같은 것이 클래스다. 클래스는 계층 구조(is-a, subClassOf)를 가질 수 있다 — 예: 암담보 is-a 질병담보 is-a 담보.
2. 속성 (Property / Attribute)
클래스에 속한 개체가 가지는 데이터 값. “계약”이라는 클래스는 계약일자, 계약상태, 보험료 같은 속성을 가진다. 속성은 클래스 자체에 종속된 스키마 필드이며, 실무에서는 Pydantic 모델의 필드 정의와 정확히 대응된다.
3. 관계 (Relationship / Property, RDF 맥락에서는 “predicate”)
클래스 간, 혹은 개체(Individual) 간의 연결. “계약 — 포함한다 — 특약”, “계약자 — 상이하다 — 수익자” 같은 것이 관계다. 여기서 실무적으로 중요한 구분이 하나 있다.
- 속성(attribute): 개체가 갖는 값 (예: 계약의
보험료= 50000) - 관계(relationship): 개체와 다른 개체를 잇는 연결 (예: 계약 → 특약)
RDF 세계에서는 이 둘을 구분하지 않고 전부 “서술어(predicate)”로 취급하지만, LPG(Neo4j 등)에서는 속성은 노드/관계 내부의 key-value로, 관계는 노드 간 물리적 연결로 구현 방식 자체가 다르다.
4. 제약 (Constraint) — domain/range
관계마다 “누가 주체가 될 수 있고 누가 대상이 될 수 있는가”를 제한하는 것. 예: 보장한다라는 관계의 domain은 보험상품, range는 담보로 제한 — 즉 보험상품 -[보장한다]-> 담보는 허용되지만 담보 -[보장한다]-> 계약자는 스키마 위반이다. OWL/RDFS에서는 rdfs:domain, rdfs:range로 명시하고, SHACL(Shapes Constraint Language)로 검증한다.
5. 개체 (Individual / Instance)
클래스의 실제 인스턴스. “AIA암보험 2024형”이라는 실제 상품은 보험상품이라는 클래스의 개체다. 클래스가 “설계도”라면 개체는 그 설계도로 찍어낸 “실물”이다.
6. 공리·추론 규칙 (Axiom / Inference Rule)
“A가 B의 하위 클래스이고 B가 C의 속성을 가지면, A도 C의 속성을 상속한다”처럼 명시적으로 적지 않아도 논리적으로 도출되는 규칙. RDF/OWL 진영은 이 추론기(Reasoner)가 데이터베이스 자체에 내장되어 있다는 게 핵심 차별점이다.
온톨로지 설계 방법론
온톨로지를 실제로 만드는 절차론은 크게 세 가지 접근으로 나뉜다.
Top-down (하향식)
도메인의 목적과 전문 지식에서 출발해 상위 클래스를 먼저 연역적으로 정의하고, 점차 하위 클래스로 내려가며 구체화하는 방식. 이 방식의 정석은 Competency Question(역량 질문) 기법이다 — “이 온톨로지가 답할 수 있어야 하는 질문이 무엇인가”를 먼저 정의하고, 그 질문에 답하기 위해 필요한 클래스와 관계를 역산한다.
예: “특정 특약의 해지환급금 계산 조건은 무엇인가?”라는 질문에 답하려면 계약, 특약, 해지환급금규정이라는 클래스와 그 사이의 관계가 최소한 필요하다는 결론이 나온다.
이 방식의 장점은 스키마가 일관되고 목적에 부합한다는 것이고, 단점은 실제 현장 데이터와 괴리가 생길 위험이 있다는 것이다.
Bottom-up (상향식)
실제 데이터(문서, 로그, 레코드)를 관찰해 반복되는 개체와 패턴을 귀납적으로 추출하고, 거기서 클래스를 “발견”해 올라가는 방식. 데이터 기반이라 현실 반영도가 높지만, 데이터 자체는 스스로 구조를 정의하는 힘이 없기 때문에 — 같은 개념이 문서마다 “계약자”, “청약자”, “보험가입자”처럼 다르게 표현되어도 이를 하나로 묶을 기준이 없다 — 순수 bottom-up은 스키마가 파편화되기 쉽다.
Middle-out (절충식) — 실무 표준
Top-down과 Bottom-up을 동시에 굴려 중간에서 수렴시키는 방식. 실무에서 가장 널리 쓰이는 접근이다.
- Top-down 트랙: Competency Question으로 최상위 클래스 4~6개를 도메인 지식에서 연역적으로 확정한다. (예: 보험 도메인이라면
계약,당사자,상품/보장,업무프로세스,규정/조건,분류체계) - Bottom-up 트랙: 전체 데이터가 아니라 업무 유형별 대표 샘플만 뽑아, 그 샘플이 top-down 뼈대에 잘 매핑되는지 검증한다. 매핑이 안 되는 개체가 나오면 그때만 뼈대를 보강하거나, 혹은 “이건 별도 클래스가 아니라 하위 속성”이라고 판단해 걸러낸다.
여기서 중요한 원칙은 순서다. 상위 뼈대를 먼저 세우고 데이터로 검증하는 것이지, 데이터를 전부 훑어서 상향식으로 스키마를 발견하는 게 아니다. 실무 구현에서는 이 원칙이 “상위 클래스는 개발자가 Pydantic 등으로 엄격히 정의하고, 문서에서 실제 값을 뽑아 그 스키마에 채워 넣는 반복 작업만 LLM에게 맡긴다”는 형태로 구현된다 — 즉 스키마 결정권은 사람에게, 반복적인 매핑 작업은 LLM에게 분업하는 것이 middle-out 방법론의 실무적 번역이다.
흔한 오해 하나: 설계 방법론과 저장 기술은 별개다
“Top-down이니까 RDF, Bottom-up이니까 LPG(Neo4j)”처럼 설계 방법론과 저장 기술(RDF vs LPG, Neo4j vs Neptune)을 짝짓는 것은 흔한 오해다. 이 둘은 완전히 다른 층위의 결정이다.
- 설계 방법론(top-down/bottom-up/middle-out)은 “어떤 클래스와 관계를 정의할 것인가”를 결정하는 절차다.
- 저장 기술(RDF/LPG)은 “그렇게 정의된 스키마를 물리적으로 어떻게 저장하고 쿼리할 것인가”를 결정하는 구현 선택이다.
Middle-out으로 설계한 동일한 스키마를 Neo4j(LPG)에 넣을 수도, Neptune(RDF)에 넣을 수도 있다. 저장 기술 선택은 설계 방법론이 아니라 별도의 실무적 기준 — 쓰기 일관성 요구 수준, 레거시 RDF 자산의 존재 여부, 팀의 쿼리 언어 숙련도, 클라우드 인프라 통합 필요성 — 으로 결정해야 한다.
정리
온톨로지는 클래스·속성·관계·제약·개체·추론 규칙이라는 구성 요소로 이루어진, 도메인 지식을 기계가 처리 가능한 형태로 명시화한 체계다. 이를 설계하는 절차는 목적(Competency Question)에서 출발해 뼈대를 연역하고, 실제 데이터로 그 뼈대를 검증하는 middle-out 방식이 실무적으로 가장 안정적이다. 그리고 이렇게 설계된 스키마를 어떤 데이터베이스(RDF 기반 vs LPG 기반)에 구현할지는, 설계가 끝난 뒤에 별도로 판단해야 하는 완전히 다른 질문이다.
