[온톨로지 기반 GraphRAG] (1) 온톨로지의 스키마란?

내가 온톨로지를 공부하던 시절에는 지금 같은 시대가 올 줄 몰랐다.

대학원에서는 AI보다는 온톨로지 표준을 만드는 일에 집중했고, 연구실에서 공동으로 TTA 데이터맵 표준 제정 작업에도 참여했다. 주로 공공데이터를 분석하고 데이터 카탈로그의 메타데이터를 다루는 일이었다. 그러다 LLM이 등장하고, 알음알음 알고만 있던 팔란티어가 이렇게까지 뜨면서 온톨로지는 갑자기 뜨거운 감자가 됐다.

 

다만, 다들 온톨로지를 말하는데, 해석하는 방식이 너무 다르다. 팔란티어는 일종의 플랫폼이고 온톨로지 자체는 이론이자 표준 모델인데, 이 둘이 혼용되면서 이상한 기대가 생긴다. 특히 공공 분야에서는 "AI가 안 되는 걸 온톨로지를 쓰면 해결된다"거나, 표준도 스키마도 없이 추론으로 환각을 줄여달라는 사업을 여러 번 봤다. 그게 되려면 일단 LPG가 아니라 RDF/OWL 수준의 제약조건이 있는 스키마부터 필요하지만,,, 개념을 설명하는 것부터 항상 어려운일이었다.

 

정리해보면 시장의 요구는 두 부류로 갈리는 것 같다.

• 스키마·규칙·제약조건부터 만들어야 하는 분야: 데이터는 흩어져 있고 지식 체계가 정리 안 된 경우
• 데이터와 규칙은 이미 있는데, 자동화와 서비스가 목적인 분야: 제조·의료·금융·보험처럼 복잡한 도메인 지식이 있는 경우. 사실 의료·바이오 쪽은 온톨로지가 아니어도 표준 코드 체계가 이미 잘 잡혀 있다

후자에서 어려운 건 오히려 이런 질문이다. 규칙은 있는데 온톨로지에 어떻게 반영할 것인가? 반영하면 정말 정확도가 올라가는가? 자동화는 어디까지 가능한가? 이 시리즈는 이 질문들을 생각하다가 작성해보는 글이다. 나도 답을 다 알고 시작하는 게 아니라, 조사하면서 기록하는 공부에 가깝다.

---

1. RAG의 한계

LLM 도입의 전형적인 흐름이 있다. 할루시네이션 방지를 위해 RAG를 붙인다. 문서를 청크로 쪼개 임베딩하고, 질문이 오면 비슷한 청크를 찾아 프롬프트에 넣는다. 처음엔 괜찮지만 조금 지나면 다른 종류의 오답이 생긴다.

• "A팀 김OO이 담당한 프로젝트의 발주처는?" → 김OO 청크와 발주처 청크는 각각 잘 찾았는데, 둘을 잘못 이어 붙인 답이 나온다
• "이 규정과 저 계약 조항이 충돌하나?" → 두 문서를 관계 지어 추론해야 하는데, 청크끼리는 서로를 모른다

벡터 검색은 "비슷한 문장"을 찾을 뿐 개체 간 관계를 모른다. 관계를 묻는 질문에 관계를 모르기 때문에 LLM에 맡겨진다.

RAG vs. GraphRAG

GraphRAG는 이 문제를 풀기 위해 나왔다. 문서를 청크가 아니라 지식그래프로 만들어 두고, 질문이 오면 관련 서브그래프나 경로를 검색해 LLM에 넘긴다. Microsoft GraphRAG가 유명해지면서 하나의 장르가 됐고, 경로를 따라가며 추론하는 Think-on-Graph 계열, LLM이 간선을 골라 탐색하는 에이전트형까지 변형이 쏟아지고 있다.

 

2. GraphRAG의 성능 검증의 필요성

GraphRAG 자료를 읽다 보면 "얼마나 좋아지는가"에 대한 답이 자료마다 다르다. 어떤 벤치마크에선 극적으로 좋아지고, 어떤 실험에선 vanilla RAG와 별 차이가 없거나 오히려 나빠진다.

왜 그럴까 생각해봤는데, "GraphRAG가 좋은가?"라는 질문 안에 서로 다른 세 질문이 섞여 있어서인 것 같다.

1. 구조의 효과: 청크 대신 그래프 구조로 검색해서 좋아진 건가?
2. 데이터 정제 효과: 그래프를 만드는 과정에서 정보가 정제된 덕분인가?
3. 제약의 효과: 그래프에 논리 규칙(스키마, 제약)이 있어서 좋아진 건가?

대부분의 비교 실험은 이 셋을 분리하지 않는다. 내가 개인적으로 관심있는 건 제약의 효과다. 온톨로지를 해온 입장에서 결국 핵심은 스키마를 만들고, 스키마대로 쿼리를 잘 짜거나 잘 생성하는 것으로 보이는데 그게 기존 text2SQL과 뭐가 다르냐는 질문에 답할 수 있어야 하기 때문이다.

3. 대부분의 GraphRAG에는 스키마 제약이 없다

실무에서 GraphRAG는 대개 Neo4j 같은 LPG 위에 만든다. LPG는 유연하다는 장점이 있지만, 말그대로 아무 노드나 만들고 아무 간선이나 이을 수 있다.

• "직원은 부서에 반드시 1개 소속" 같은 규칙을 그래프 수준에서 강제할 수 없다 (애플리케이션 코드 어딘가에서 처리하게 된다)
• 의미적으로 말이 안 되는 경로(프로젝트→생년월일→...)를 따라가도 검증하기 어렵다

즉, 주류 GraphRAG는 그래프의 형태는 갖췄지만 논리 제약은 없는 상태로 돌아간다. 검색이 잘못된 경로를 타도, LLM이 규칙에 어긋난 답을 합성해도, 그 위반을 판정할 검증 계층(validation layer)이 스키마에서는 없다.

 

4. OWL과 SHACL

반면 LPG가 아닌 RDF, OWL 스키마로 넘어가면 검증 계층에 해당하는 도구들이 존재한다.

개인적으로, LPG로 공부를 시작한 것이 아니라서 이러한 구조를 설명해야한다는 생각해본 적이 없었는데 최근 온톨로지에 대해 질문을 많이 받다보니 정리할 필요가 있다고 느꼈다. 오히려 온톨로지를 접해보지 않았던 분들에게 장점이라고 설명해야 한다는 사실 자체를 잊을 때가 있다.

• OWL: "Person과 Project는 서로소다", "manages의 주어는 반드시 Person이다" 같은 개념 수준의 공리. 여기에 상속, 전이 속성, 역속성 같은 추론 장치가 딸려 온다. 부서의 상위 부서를 재귀 쿼리 없이 전이 속성 하나로 묻는 건 다른 쿼리 언어에는 없는 이점이다
• SHACL: "직원 노드는 부서 속성을 정확히 1개 가져야 한다" 같은 데이터 형태 검증 규칙. 위반을 리포트로 뽑아준다
• SWRL: "자격증 A 보유 + 경력 3년 이상이면 직무 B 적격" 같은 도메인 규칙 추론

문제는 이 도구들이 LLM 파이프라인과 따로 논다는 것이다. 쓰이더라도 대개 데이터 적재 전의 오프라인 정제 용도지, 검색과 생성이 일어나는 루프 안에는 들어와 있지 않다.

 

그래서 이 시리즈에서 설명하려는 내용은 아래와 같다.

온톨로지를 그래프 옆의 설명서가 아니라, 검색이 어느 방향으로 탐색할지 허가하고(OWL), 가져온 근거가 규칙에 맞는지 검증하고(SHACL), 답변의 추론 경로를 재검증 가능하게 만드는(provenance) 런타임 구성요소로 활용하는 것. 이게 정말 정확도를 올리는지, 가능한지 확인해보는 것이 시리즈의 목표다.

 

5. 한계점

분명 이 접근에도 한계가 있다. 온톨로지와 SHACL은 공짜로 생기지 않고(수동 설계가능성 높음), 온라인 검증은 지연을 더하며(성능 비용), 잘못 만든 규칙은 멀쩡한 근거를 오류로 판단한다(규칙 품질 리스크).

온톨로지라는 개념만으로는 AI가 A-Z를 할 순 없다..

 

다음 글은 데이터 최신성 문제, 그리고 변환 적재(ETL)와 OBDA 가상화라는 선택지들을 비교한다.