온톨로지(Ontology) 개념과 지식그래프 구축 방법 A to Z

온톨로지의 제약이나 추론을 하기 전에 "그런데 온톨로지가 정확히 뭔데?", "지식그래프는 그래서 어떻게 만드는 건데?"라는 질문이 먼저 나온다. 용어부터 진입장벽이 있고 막상 "만드는 법"을 처음부터 끝까지 보여주는 글은 드물다. 개념 설명은 W3C 명세처럼 딱딱하거나, 튜토리얼은 너무 간단하게 노드와 엣지로 설명하고 끝나는 경우가 있다.

 

그래서 이 글은 하나의 실제 프로젝트를 처음부터 끝까지 따라간다. 합성 의료 데이터(Synthea) CSV 뭉치를 받아서, 온톨로지를 설계하고, 트리플로 변환해 그래프 데이터베이스에 적재하고, 쿼리하는 것까지를 다룬다. 이 과정에서 온톨로지란 무엇인지, 그리고 지식그래프의 대표적인 구조인 RDF와 LPG가 실제로 뭐가 다른지를 정리하고자 한다. 

이 글의 실험 환경 — Docker Compose로 GraphDB(RDF 저장소)와 Neo4j(LPG 저장소)를 띄우고, Python(rdflib, neo4j driver)으로 데이터를 변환·적재했다. 데이터는 Synthea가 생성한 합성 환자 데이터를 사용했다. Synthea는 미국 MITRE가 만든 오픈소스 합성 환자 생성기로, 실제 환자 기록을 익명화한 것이 아니라 공개 통계(인구·질병 유병률)와 임상 진료 가이드라인을 모델링한 모듈로 가상 환자의 생애(출생→진료→진단→처방)를 통째로 시뮬레이션해서 만들어낸다. 결과물은 patients.csv, encounters.csv(진료), conditions.csv(진단) 등의 CSV(또는 FHIR)로 출력된다. 처음부터 가상으로 생성된 데이터라 개인정보 문제가 원천적으로 없으면서도, 실제 의료 데이터의 구조적 복잡함은 그대로 갖고 있다. 두 저장소 모두 무료 에디션으로 충분하며, 다른 선택지들은 5장의 참고 박스에 정리해뒀다.

---

1. 온톨로지란?

용어부터 정리하면, 데이터에 구조를 부여하는 방법은 여러 층위가 있고 온톨로지는 그중 가장 표현력이 높은 쪽 끝에 있다.

• 스키마(Schema): "이 테이블에는 이런 컬럼이 있다." 데이터의 형태를 정의한다. 예: RDB의 DDL
• 분류체계(Taxonomy): "심장질환은 순환기질환의 하위다." 개념 간 상하위 관계까지 정의한다.
• 온톨로지(Ontology): 여기에 더해 개념 간의 관계와 논리 규칙까지 정의한다. "진단(Condition)과 약물(Medication)은 서로 배타적인 개념이다", "모든 진료(Encounter)에는 반드시 1명의 환자가 참석한다" 같은 것들이다.

핵심 차이는 스키마와 분류체계는 데이터를 정리하지만, 온톨로지는 데이터에 대해 추론하고 검증할 수 있게 한다. 기계가 "이 데이터는 규칙에 어긋난다"고 판정하거나, 명시되지 않은 사실을 논리적으로 도출할 수 있는 것은 온톨로지부터다.

실무에서 온톨로지는 보통 두 부분으로 나눈다.

• T-Box (Terminology): 개념의 정의. "환자란 무엇이고, 진료란 무엇이며, 둘은 어떤 관계인가."
• A-Box (Assertion): 실제 데이터. "환자 김OO은 2001년 3월에 만성 부비동염 진단을 받았다." 

지식그래프를 만든다는 것은 결국 T-Box를 설계하고, 원천 데이터를 A-Box로 변환해 채워 넣는 일이다. 

 

 

 

2. 설계는 질문에서 시작한다 - 역량 질문(CQ)

온톨로지 설계에 정해진 출발점이 있는 것은 아니다. 어디서부터 개념을 잡아 나가느냐에 따라 접근법이 갈리는데, 고전적으로는 세 가지로 나눈다.

• 탑다운(Top-down): 가장 일반적인 상위 개념에서 출발해 아래로 구체화한다. 상위 온톨로지(BFO, DOLCE 등)에 도메인 개념을 정렬하는 방식이 이 계열이고, 기본 상식을 위에서부터 정의하려는 방법이다.
• 바텀업(Bottom-up): 이미 있는 데이터·용어집·문서에서 출발해 위로 일반화한다. 텍스트에서 개념과 관계를 자동 추출하는 온톨로지 학습(ontology learning), 요즘의 LLM 기반 추출도 이 계열이다.
• 미들아웃(Middle-out): 도메인에서 가장 중요한 핵심 개념부터 잡고 위·아래 양방향으로 확장한다. 온톨로지 공학 초기 문헌(Uschold & King)이 권한 절충안으로, 실무에서는 결국 이 형태로 수렴하는 경우가 많다.

그리고 어느 방향으로 가든 설계의 범위를 잡아주는 장치로 널리 쓰이는 것이 역량 질문(Competency Questions, CQ)으로, 그래프가 답해야 할 질문 목록이다. 1990년대 TOVE 방법론에서 도입된 개념이고, 이후 NeOn 방법론에서는 목적·범위·사용자·CQ를 묶어 ORSD(Ontology Requirements Specification Document, 요구사항 명세서)로 문서화하는 것이 표준이 됐다.

 

이번 프로젝트는 CQ를 쓰는 것부터 시작했다. Synthea CSV라는 데이터가 이미 있으니 바텀업 재료는 충분했지만, 데이터가 시키는 대로만 따라가면 "테이블을 그래프 모양으로 옮긴 것"이 되기 쉽다. 그래프가 무엇에 답해야 하는지를 먼저 설계하고 싶었다. 

• 목적: Synthea 의료 데이터를 지식그래프로 변환하여 다중 홉(multi-hop) 질의에 대응한다.
• 핵심 CQ (예시): "특정 진단(Condition)을 받은 환자의 최신 검사 수치(Observation)와 처방약(Medication)은?"

이 질문에서 파악할 수 있는 건 다음과 같다. 환자·진단·검사·약물이라는 클래스가 필요하고, 이들을 잇는 허브(진료 세션)가 필요하며, "최신"에 답하려면 시간 속성이 필수라는 것까지 생각할 수 있다. 즉, CQ는 설계의 범위를 정해주고, 나중에 구축이 끝났을 때 검증 기준이 되어준다. 

3. 표준의 재사용

CQ가 나왔으니 이제 클래스와 속성을 정의할 차례다. 여기서 초심자가 가장 많이 하는 실수가 모든 것을 직접 정의하는 것이다. my:Patient, my:hasAge, my:livesIn... 이렇게 만든 온톨로지는 내 프로젝트 안에서는 돌아가지만, 외부 데이터와 결합하는 순간 매핑 지옥이 열린다.

물론 최근에는 범용 데이터가 아닌 내부 데이터를 AI와 함께 사용하는 것이 주된 목표가 많아서, 직접 정의하는 경우가 많다.

 

만약 상호운용성을 생각한다면 표준 어휘를 재사용하는 것이 좋다. 다만, 클래스만 표준을 따르고 속성은 임의로 정의하는 경우가 많은데, 속성까지 재사용해야 효과가 온전히 나온다.

그럼 재사용할 어휘를 어디서 찾는가. 이런 게 있다는 것조차 감을 못잡는 경우가 많은데, 다행히 어휘의 검색엔진 역할을 하는 서비스들이 있다.

• LOV (Linked Open Vocabularies): 재사용 가능한 시맨틱 어휘의 큐레이션 카탈로그. "birthDate"처럼 개념 이름으로 전문 검색하면 그 개념을 정의한 어휘들이 사용 빈도·상호 참조 지표와 함께 나온다. 어휘 간 연결 관계까지 보여주기 때문에 "다들 뭘 쓰는지"를 확인하는 데 이만한 곳이 없다.
  • 가끔 안들어가지거나 굉장히 느릴때가 많음...서비스 유지가 어려운걸까
  • 소개글: https://datos.gob.es/en/blog/linked-open-vocabularies-lov
• prefix.cc: 네임스페이스 접두사 조회 서비스. schema:가 무슨 URI인지, foaf:는 어디서 왔는지 궁금할 때 쓴다. 크라우드소싱 기반이라 가볍고 빠르다.
• BioPortal: 의료·생명과학 도메인이라면 여기부터. SNOMED CT, LOINC, ICD 등 1,000개가 넘는 바이오 온톨로지를 검색·비교할 수 있다.
• W3C 표준 어휘들: 출처(PROV-O), 분류체계(SKOS), 데이터 카탈로그(DCAT)처럼 도메인을 가리지 않는 관심사는 W3C 권고 표준이 이미 있다. 직접 만들기 전에 반드시 확인할 것.
• Schema.org: 구글·마이크로소프트·야후·얀덱스가 공동 설립한 범용 어휘. 검색엔진이 웹페이지의 구조화 데이터(SEO)를 해석하는 표준이라 어휘 중 가장 널리 알려져 있고, Person·Organization·Event 같은 일상 개념부터 의료 확장(MedicalEntity 계열)까지 커버한다. 사이트 자체가 계층 브라우저 역할을 해서, 클래스에서 속성으로 타고 들어가며 바로 탐색할 수 있다.
• DBpedia·Wikidata: 어휘(T-Box)보다는 인스턴스(A-Box) 차원의 거대 지식베이스지만, 내 그래프의 개체를 외부 세계와 연결(owl:sameAs 등)하는 앵커로 쓸 수 있다.

이번 프로젝트에서는 이 중 Schema.org를 기반으로 삼았다. 실제 웹에서 소비되는 어휘라 문서화와 예제가 압도적으로 풍부하고, 의료 확장까지 갖추고 있기 때문이다. 도메인이 깊어지면 SNOMED CT 같은 전문 체계로 내려가야 하지만, 학습과 프로토타이핑 단계에서는 Schema.org가 가장 낮은 진입장벽으로 표준 재사용의 효과를 보여준다.

구분	클래스	상위 클래스	역할
표준 차용	ex:Patient	schema:Patient	환자
표준 차용	ex:Provider	schema:Physician	의료진
도메인 확장	ex:Encounter	schema:MedicalEvent	진료 세션 (허브 역할)
도메인 확장	ex:Condition	schema:MedicalCondition	진단
도메인 확장	ex:Observation	schema:Observation	검사 수치
도메인 확장	ex:Medication	schema:Drug	약물

 

클래스를 상속받는 것처럼 속성도 상속받아서 확장할 수 있다. 환자의 생년월일은 my:birthDate가 아니라 schema:birthDate를 그대로 쓰고, 직접 정의해야 하는 속성은 표준 속성의 하위로 건다.

# 진료(Encounter)와 환자의 관계 — 표준 속성 schema:attendee의 하위로 정의
ex:hasPatient a owl:ObjectProperty ;
    rdfs:subPropertyOf schema:attendee ;
    rdfs:domain ex:Encounter ;
    rdfs:range ex:Patient ;
    rdfs:label "진료 참석 환자"@ko .

 

이렇게 하면 세 가지가 좋아진다. 첫째, 외부 시스템이 내 데이터를 즉시 해석할 수 있다(상호운용성). 둘째, schema:attendee라는 상위 속성으로 "이 이벤트에 참여한 사람"을 통합 쿼리할 수 있다(추론의 일관성). 셋째, 나중에 다른 도메인 데이터가 들어와도 Schema.org라는 공통 분모로 연결된다(확장성).

Schema.org의 경우, MedicalEvent는 이미 performer(수행자), attendee(참석자), location(장소) 속성을 갖고 있어서 encounters.csv의 구조와 거의 그대로 맞아떨어졌다. 덕분에 커스텀 속성 정의를 70% 이상 줄일 수 있었다. 

 

여기에 논리 제약을 얹으면 T-Box가 완성된다. 에이전트나 파이프라인이 만들어낼 수 있는 오류를 그래프 수준에서 막기 위한 장치들이다.

• Disjointness: ex:Condition과 ex:Medication은 상호 배타. 예: 진단이 약물로 분류되는 사고를 원천 차단
• Cardinality: 모든 Encounter는 반드시 1명의 Patient를 가짐
• Functional Property: ex:startTime 등은 값이 유일함을 보장

참고: 온톨로지의 실제 구현체는 어떻게 만들 수 있을까?

이번 프로젝트에서는 Turtle 파일을 직접 작성했지만(LLM 에이전트와 함께라면 생각보다 쉽다), 시각적 도구를 쓰고 싶다면 선택지가 여럿 있다.

• Protégé: 스탠퍼드에서 만든 이 분야의 표준 오픈소스 에디터. 20년 넘게 살아남은 데는 이유가 있다 — OWL 2 완전 지원, 추론기 내장, 플러그인 생태계. 협업이 필요하면 웹 버전인 WebProtégé를 쓰면 된다.
• Microsoft Ontology Playground: 2025년 말에 나온 무료 오픈소스 웹앱. 도메인별(의료·제조·금융 등) 사전 구축 온톨로지를 그래프로 탐색하고, 시각적으로 설계해서 RDF/XML로 내보낼 수 있다. 백엔드 없는 정적 사이트라 설치도 가입도 필요 없어서, 온톨로지가 처음인 사람에게 권하기 가장 좋은 입구가 됐다. Microsoft가 Fabric IQ와 함께 온톨로지를 전면에 내세우기 시작했다는 신호이기도 하다.
• OWLGrEd: UML 스타일로 OWL을 그리는 그래픽 에디터. UML에 익숙한 개발자에게 진입장벽이 낮다.
• VocBench: SKOS 시소러스·다국어 어휘 중심의 웹 협업 플랫폼. 기관 단위의 어휘 관리라면 이쪽.

 

4. URI와 시맨틱 매핑

 

T-Box(설계도)가 나왔으니 CSV의 각 행을 A-Box(실제 지식)로 변환할 차례다. 여기서 일반적인 ETL과 시맨틱 매핑의 차이가 드러난다.

• 일반 ETL: patients.csv의 Id 컬럼을 DB의 PK로 저장한다.
• 시맨틱 매핑: Id를 전 세계적으로 고유한 주소인 URI로 변환하고, 이 리소스가 ex:Patient 클래스의 인스턴스임을 명시하고, 표준 어휘와 연결한다.

그래서 코드를 짜기 전에 두 가지 규칙 문서를 먼저 만들었다.

첫째, URI 명명 규칙. 모든 리소스의 주소 체계다. 예시로 {Base}/{Category}/{ID} 구조의 환자 1번은 http://example.org/healthcare/patient/1d604da9...가 된다. 

 

둘째, 시맨틱 매핑 명세서. "어떤 컬럼이 어떤 클래스·속성으로 가는가"를 코드 이전에 문서로 확정한 것이다. 여기서 실무적으로 가장 중요했던 두 가지가 있다.

• 복합 키(Composite Key): conditions.csv 같은 임상 기록에는 고유 ID가 없다. {PatientID}-{ConditionCode}-{StartDate}를 조합해 고유 URI를 만드는 규칙으로 해결했다. 이게 없으면 재적재할 때마다 중복 데이터가 쌓인다.
• 관계 정의(Relational Join): 테이블을 그냥 쌓는 게 아니라 Encounter → Patient(ex:hasPatient), Condition → Encounter(ex:partOfEncounter)처럼 리소스 간 관계를 명시했다. 지식그래프의 가치는 이 간선들에서 나온다.

URI 설계는 경험상 전체 과정에서 품질을 가장 크게 좌우하는 단계다. 매핑 명세 없이 코드부터 짜면, 변환 로직 곳곳에 암묵적 결정이 흩어지고 나중에 아무도 그 이유를 모르게 된다.

참고 매핑·변환을 도와주는 도구
이번 프로젝트는 Python 코드로 직접 변환했지만, 코드를 덜 쓰고 싶다면 아래와 같은 것도 검토할 수 있다.

• OpenRefine + RDF Transform 확장: 데이터 정제 도구의 고전. 지저분한 CSV를 클러스터링·정규화로 청소한 뒤, 확장을 붙이면 GUI에서 컬럼→RDF 골격 매핑까지 할 수 있다. 
• Ontotext Refine: OpenRefine을 RDF 변환·GraphDB 적재에 특화시킨 버전. GraphDB를 쓴다면 자연스러운 조합이다.
• RML / RMLMapper: "어떤 컬럼이 어떤 트리플이 되는가"를 코드가 아니라 선언적 매핑 언어로 기술하는 W3C 계열 접근(R2RML의 확장). 매핑 규칙 자체가 문서이자 실행물이 된다는 게 철학이다. 사람이 쓰기 편한 YAML 문법인 YARRRML로 작성해서 변환하는 워크플로우가 일반적이다.

그래도 나는 이 규모(수십만 트리플)까지는 Python 직접 구현을 권한다. RDF와 LPG 양쪽에 같은 비즈니스 로직을 적용해야 하는 이번 케이스처럼, 매핑 도구의 표현력을 벗어나는 요구가 하나라도 생기면 결국 코드로 돌아오게 되기 때문이다.

5. RDF와 LPG 구축

구현은 2개 유형의 그래프를 구축했다.

• RDF (Resource Description Framework): W3C 표준. 모든 지식을 주어-술어-목적어 트리플로 표현한다. 온톨로지(OWL) 기반 논리 추론과 표준 어휘 연동이 강점. 저장소는 GraphDB를 썼다.
• LPG (Labeled Property Graph): 노드와 간선에 속성(property)을 직접 붙이는 모델. 경로 탐색과 그래프 알고리즘이 강점. Neo4j를 사용했다.

참고. 무료로 시작할 수 있는 그래프 저장소
이 프로젝트는 GraphDB Free와 Neo4j Community를 썼지만, 선택지는 더 넓다.

RDF 저장소(트리플스토어):

• GraphDB Free: Ontotext의 무료 에디션. 추론 지원이 좋고 워크벤치 UI가 친절해서 학습용으로 무난하다.
• Apache Jena Fuseki: 완전한 오픈소스(Apache 2.0). Java 생태계의 표준이고 SPARQL 서버를 가장 빨리 띄울 수 있는 방법 중 하나다.
• Virtuoso Open Source: DBpedia를 서빙하는 것으로 유명한 고성능 저장소. 수십억 트리플 규모까지 검증돼 있다.
• Oxigraph: Rust로 만든 경량 오픈소스 저장소. 라이브러리로 임베드할 수 있어 작은 프로젝트에 좋다.
• QLever: 프라이부르크 대학의 초고속 오픈소스 엔진. Wikidata 전체를 노트북급 장비에서 돌리는 걸로 유명하다.

LPG 저장소:

• Neo4j Community Edition: 학습 자료가 가장 풍부하고 단일 인스턴스 용도로는 기능 제약도 크지 않다. 처음이라면 여기서 시작하는 게 정석.
• Memgraph: C++ 인메모리 엔진으로 실시간·스트리밍 워크로드에 강하다. Cypher 호환이라 Neo4j 지식이 그대로 이전된다. 단, 라이선스는 BSL이라 엄밀한 의미의 오픈소스는 아니다.
• FalkorDB: 구 RedisGraph. Redis 위에서 도는 초경량 그래프 DB로, 이미 Redis를 운영 중이라면 고려할 만하다(source-available 라이선스).
• 참고로 임베디드 그래프 DB로 주목받던 Kuzu는 2025년 10월 Apple에 인수되면서 저장소가 아카이브됐다. 새 프로젝트에는 권하지 않는다.

 

하나의 매핑 명세서에서 두 갈래의 코드가 나간다. RDF 쪽은 Python rdflib으로 트리플을 생성한다.

# 성별 매핑: Raw(M/F) -> Semantic(Male/Female)
gender = "Male" if row['GENDER'] == 'M' else "Female"
g.add((p_uri, SCHEMA.gender, Literal(gender, datatype=XSD.string)))

# 표준 어휘 바인딩
g.add((p_uri, SCHEMA.givenName, Literal(row['FIRST'], datatype=XSD.string)))
g.add((p_uri, SCHEMA.birthDate, Literal(row['BIRTHDATE'], datatype=XSD.date)))

 

결과물은 약 32만 개의 트리플이 담긴 Turtle 파일(healthcare_instances.ttl)이다. LPG 쪽은 Neo4j 드라이버와 Cypher의 UNWIND를 활용한 배치 적재다.

UNWIND $rows AS row
MERGE (p:Patient {id: row.Id})
SET p.givenName = row.FIRST,
    p.gender = CASE row.GENDER WHEN 'M' THEN 'Male' WHEN 'F' THEN 'Female' ELSE row.GENDER END

 

사전에 Unique Constraint를 걸어 중복 적재를 방지했고, 6만 개 이상의 노드와 관계가 1분 이내에 적재됐다.

여기서 배운 것 하나. 데이터 모델은 달라도 비즈니스 로직은 공유해야 한다는 점이다. 복합 키 생성 규칙, 성별 변환, 날짜 형식 처리 같은 로직을 Python 한 곳에 두고 양쪽 엔진이 같이 쓰게 했다. 이걸 안 하면 두 그래프가 미묘하게 다른 지식을 갖게 되고, 나중에 연동(federation)이 불가능해진다.

6. 쿼리를 활용한 검증

적재가 끝나면 만들었던 역량 질문(CQ)으로 돌아간다. 그래프가 그 질문에 답하는지 직접 물어보는 것이다.

SPARQL(GraphDB)로 "여성 환자들의 이름을 조회하라"는 아래와 같은 쿼리를 만들 수 있다.

SELECT ?name WHERE {
  ?p a ex:Patient ;
     schema:gender 'Female' ;
     schema:givenName ?name .
} LIMIT 5

 

온톨로지 설계대로 매핑된 데이터가 정확히 나온다. Cypher(Neo4j)로는 관계를 타고 가는 질문을 던진다. "특정 환자의 진료 기록과 그 시점의 진단명을 연결하라":

MATCH (p:Patient {id: '...'})<-[:HAS_PATIENT]-(e:Encounter)<-[:PART_OF_ENCOUNTER]-(c:Condition)
RETURN p.givenName, e.startTime, c.description

 

한 환자의 2001년 진료 기록과 당시 진단된 만성 부비동염(Chronic sinusitis)이 연결되어 나왔다. 원천 CSV에서는 세 개의 파일에 흩어져 있던 사실이, 그래프에서는 하나의 경로로 이어진다. 테이블의 나열이 아니라 관계 기반으로 탐색이 가능하다.

8. RDF와 LPG, 만들어보고 정리한 차이

같은 데이터를 양쪽에 넣어보면 두 모델의 차이가 추상론이 아니라 손끝으로 느껴진다. 정리하면 이렇다.

	RDF(GraphDB)	LPG(Neo4j)
기본 단위	트리플 (주어-술어-목적어)	노드·간선 + 속성(property)
식별자	전역 URI (전 세계 고유)	DB 내부 ID + 제약조건
스키마	OWL 온톨로지 — 논리 제약·추론 가능	사실상 스키마리스 (uniqueness 등 최소 제약)
표준 어휘 연동	자연스러움 (schema:, owl: 그대로 사용)	별도 관례 필요 (레이블·속성명 규칙)
속성 표현	속성도 트리플 — 다소 장황	노드에 직접 부착 — 직관적
쿼리 언어	SPARQL	Cypher
체감 강점	상호운용성, 논리 검증, 추론	경로 탐색의 직관성, 적재 속도, 도구 생태계

 

구축 단계에서의 체감을 솔직하게 말하면 만들기는 LPG가 편하고, 의미를 보장하기는 RDF가 강하다. Neo4j는 제약이 느슨한 만큼 데이터가 잘 들어가고 Cypher의 경로 패턴((a)-[:REL]->(b))이 직관적이다. 반면 RDF는 URI 체계와 온톨로지를 갖추는 비용이 들지만, 그 대가로 "이 데이터가 규칙에 맞는가"를 기계가 판정할 수 있는 기반이 생긴다. Disjointness나 Cardinality 같은 제약은 LPG에는 대응물이 없거나 애플리케이션 코드로 밀려난다.

 

논리적 정합성과 표준 연동이 중요하면 RDF, 탐색·분석과 빠른 구축이 중요하면 LPG처럼 유연하게 사고하는 것이 중요하다고 생각한다. 그리고 이번 프로젝트처럼 하나의 매핑 명세에서 둘 다 뽑아내는 하이브리드도 충분히 현실적인 선택지다. 로직을 공유하면 유지 비용이 생각보다 크지 않다.

9. 마치며

과정을 한 줄로 요약하면 다음과 같다. 질문을 정하고(CQ) → 표준 위에 설계도를 그리고(T-Box) → 데이터에 주소와 의미를 붙여(매핑) → 그래프로 변환·적재하고(A-Box) → 처음의 질문으로 검증한다. 

 

이렇게 만든 지식그래프를 LLM과 결합하면 어떤 일이 생기는지 — 온톨로지의 제약이 검색을 조종하고, 생성된 쿼리를 검증하고, 답변의 근거를 재검증 가능하게 만드는 내용은 온톨로지 제약 기반 GraphRAG 시리즈에서 다뤘다. 

 

그리고 사실 나는 주로 RDF 기반으로 공부하거나 작업했기 때문에 LPG는 이번에 처음 제대로 만져봤다. Neo4j의 그래프 알고리즘 생태계(GDS)라든가, 커뮤니티가 LPG로 GraphRAG를 만드는 방식은 아직 제대로 파보지 못했다. 그쪽 세계가 왜 주류가 됐는지는 다음에 별도의 글로 확인해볼 생각이다.