온톨로지 기반 검색이란? — 벡터 검색만으로 부족했던 이유

안녕하세요, 자바파커입니다.

"RAG 만들어봤는데, 비슷한 문장은 잘 찾는데 정작 원하는 답이 안 나옵니다."

지난달 사이드 프로젝트로 블로그 RAG 검색을 만들어보면서 제가 직접 느낀 답답함입니다. 임베딩 벡터 검색까지 붙였는데도, "Claude Code 훅으로 자동 커밋하는 글"을 물어보면 자동화·훅·커밋이 들어간 엉뚱한 글을 섞어서 가져옵니다. 비슷한 경험, 혹시 하고 계신가요?

결론부터 말씀드리면 — 벡터 검색은 '의미가 비슷한 것'은 잘 찾지만, '관계가 맞는 것'은 못 찾습니다. 그리고 이걸 해결하기 위한 오래된 도구가 다시 주목받고 있습니다. 바로 온톨로지(Ontology)입니다.

이번 시리즈에서는 6편에 걸쳐 온톨로지를 이용한 검색 기능을 직접 설계하고 구현해보려 합니다. 이번 1편은 그 첫 단추로, "왜 굳이 온톨로지인가?"부터 풀어봅니다.

벡터 검색만으로 왜 부족할까?

지난 2년간 RAG(Retrieval Augmented Generation)는 거의 "임베딩 + 벡터 DB"의 동의어처럼 쓰였습니다. 텍스트를 벡터로 바꿔 코사인 유사도로 가까운 문서를 찾는 방식이죠. 충분히 강력하지만, 실제로 써보면 세 가지 한계가 반복적으로 부딪힙니다.

1) 의미는 알지만 관계는 모른다

벡터는 비슷한 단어가 많이 등장하는 문서를 잘 찾습니다. 하지만 그 문서들 사이의 관계는 표현하지 못합니다.

벡터는 "비슷함"만 알지 "~의 작성자", "~의 1편", "~를 인용함" 같은 관계를 모릅니다.

2) Hallucination을 막을 사실 구조가 없다

LLM이 환각(hallucination)을 일으키는 핵심 이유 중 하나는, 검색된 문서에 사실 관계가 명시되어 있지 않기 때문입니다. 벡터로 가져온 문서 5개에서 LLM이 "아마 이런 뜻일 거야"라고 추론해버리는 거죠.

반대로 "X is-a Y", "A authored-by B" 같은 명시적 사실(triple)이 검색 결과에 들어오면, LLM은 그걸 그대로 인용할 수 있습니다. 추측할 여지가 줄어듭니다.

3) 도메인 어휘의 정합성을 보장 못 한다

블로그 검색을 예로 들면, "AI", "인공지능", "LLM", "생성형 AI"는 사람에겐 비슷한 의미지만 벡터 공간에서는 거리감이 제각각입니다. 그렇다고 모든 동의어를 데이터로 학습시킬 수도 없습니다.

온톨로지로 LLM ⊑ GenerativeAI ⊑ AI 같은 위계를 한 번만 정의해두면, "AI" 질의에 LLM 글까지 자연스럽게 포함됩니다.

그래서 온톨로지가 뭐길래?

온톨로지(Ontology)는 원래 철학 용어로 "존재론"을 뜻합니다. 컴퓨터 과학에서는 이렇게 정의합니다.

어떤 도메인에 존재하는 개념(클래스), 그 개념의 속성, 개념들 사이의 관계를 형식적으로 명세한 것.

용어가 무겁지만, 사실 우리가 매일 쓰는 것입니다. 블로그를 예로 들어볼게요.

클래스(Class)        : Post, Author, Tag, Series, Category
속성(Property)       : title, publishedAt, slug, description
관계(Relation)       : writtenBy, hasTag, belongsToSeries, cites

이걸 한 번에 그리면 아래와 같습니다.

[Post] --writtenBy--> [Author]
  |  \--hasTag-------> [Tag]
  |  \--belongsToSeries-> [Series]
  |  \--cites--------> [Post]
[Series] --hasCategory--> [Category]

클래스·속성·관계 세 가지만 잘 잡아도 "Claude Code 시리즈의 1편을 쓴 저자가 인용한 다른 글" 같은 질의를 처리할 수 있게 됩니다. 단순한 비슷함을 넘어 관계 탐색이 가능해지는 거죠.

온톨로지 vs 지식 그래프, 헷갈리는 두 단어

둘은 같은 듯 다릅니다.

쉽게 말해 온톨로지는 스키마, 지식 그래프는 그 스키마에 데이터를 채워 넣은 그래프입니다. 이 시리즈에서는 둘을 같이 만듭니다.

왜 지금 다시 주목받는가? — GraphRAG의 부상

온톨로지·시맨틱 웹은 사실 2000년대 초반부터 있었습니다. OWL, RDF, SPARQL — 학교에서 한 번쯤 들어보셨을 단어죠. 한동안 "이론은 좋은데 현업에 잘 안 쓰임"이라는 평가가 많았습니다.

그런데 2024년 즈음부터 분위기가 바뀌었습니다.

• Microsoft GraphRAG 공개 (2024) — 벡터 RAG + 지식 그래프 결합
• Neo4j + LangChain/LlamaIndex 통합 본격화
• LLM이 Cypher/SPARQL을 자동 생성할 수 있게 되면서, 그래프 질의의 진입 장벽이 급격히 낮아짐

요약하면, LLM이 그래프 질의어를 대신 써주는 시대가 오면서 온톨로지·지식 그래프의 인프라 비용이 확 떨어진 겁니다. 직접 SPARQL을 외워서 쓸 필요가 없으니, 남는 건 어떤 온톨로지를 잘 설계하느냐의 문제만 됩니다.

그리고 그 결과는 꽤 인상적입니다. 한 번 보시죠.

물론 만능은 아닙니다. 온톨로지 설계와 유지보수 비용이 분명히 들고, 그래서 6편(회고)에서 한계도 솔직히 다루겠습니다.

이 시리즈에서 만들 것 — 블로그 자체 검색

추상적으로만 이야기하면 와닿지 않습니다. 이 시리즈에서는 제가 운영 중인 blog.javapark.kr의 글 검색을 실제 예제로 삼겠습니다. 자기 블로그를 자기가 검색하는 다소 코믹한 그림이지만, 누구나 따라 해볼 수 있는 도메인이라는 게 장점입니다.

이번 시리즈의 목표는 단순합니다.

1. 블로그 글들을 온톨로지로 모델링한다.
2. 글·태그·시리즈·저자를 지식 그래프에 적재한다.
3. GraphRAG로 "Claude Code 시리즈의 첫 글에서 인용된 외부 자료" 같은 질의를 처리한다.
4. 운영하며 배운 점을 다음 사람을 위해 정리한다.

스택은 아직 확정하지 않았습니다. 3편에서 Neo4j, GraphDB, Memgraph를 비교한 뒤 선택하려 합니다. 1~2편은 스택 무관한 개념·설계 단계라 어느 스택을 쓰든 그대로 가져갈 수 있습니다.

다음 편 예고 — 검색을 위한 온톨로지 설계

다음 편에서는 본격적인 온톨로지 설계에 들어갑니다.

• 도메인 분석 — 무엇을 검색할 것인가?
• 클래스 후보 뽑기 — Post / Author / Tag / Series / Category
• 속성과 관계 도출 — 어떤 질의를 처리해야 하는가에서 거꾸로 시작
• 흔히 빠지는 함정 — 분류 vs 관계, 어느 쪽으로 모델링할까?

설계는 늘 가장 어렵고, 잘못 잡으면 3편 구현이 통째로 뒤집힙니다. 다음 편을 꼼꼼히 잡고 가겠습니다.

자주 묻는 질문 (FAQ)

Q1. 그냥 SQL 데이터베이스로 관계 모델링 하면 안 되나요? 가능합니다. 실제로 작은 도메인에서는 그 편이 훨씬 빠릅니다. 하지만 관계가 다단계로 깊어지거나(예: "A를 인용한 글의 저자가 쓴 시리즈"), 동의어·상위어 같은 위계 추론이 필요한 순간 SQL JOIN은 급격히 무거워집니다. 그래프 DB는 그 지점부터 의미가 생깁니다.

Q2. 온톨로지가 너무 무겁다는 인상이 있는데, 작은 프로젝트에도 가치가 있나요? 1인 블로그 정도는 솔직히 오버킬일 수 있습니다. 다만 LLM이 Cypher·SPARQL을 대신 생성해주는 지금은 설계 비용이 가장 큽니다. 도메인이 명확하고 관계 질의가 많다면, 작아도 충분히 효과를 봅니다. 6편 회고에서 더 솔직히 다루겠습니다.

Q3. Microsoft의 GraphRAG와 이 시리즈의 방향이 같은가요? 큰 그림은 같습니다. 다만 Microsoft GraphRAG는 LLM이 자동으로 그래프를 만들어내는 접근이고, 이 시리즈는 온톨로지를 사람이 먼저 설계하고 데이터를 채우는 전통적 접근에 더 가깝습니다. 4편에서 두 흐름을 비교합니다.

여러분은 RAG 검색을 만들면서 어떤 한계에 부딪히고 계신가요? 댓글로 어떤 도메인을 다루시는지 알려주시면, 시리즈를 풀어가며 참고하겠습니다.

다음 편에서 본격 설계 들어갑니다.