[AI] 온톨로지에서 Agentic GraphRAG까지 - “관계 기반 AI”가 필요한 이유

 

 

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해

 

ㅁ 들어가며

요즘 RAG는 거의 기본 옵션이 되었다. 문서를 임베딩하고, 벡터 검색으로 관련 내용을 찾아 LLM에 넘긴다.

그런데 이상하다.

  검색은 되는데, 답은 종종 부정확하다.
  문장은 가져오지만, 맥락은 놓친다.
  관련 문서는 찾는데, “왜”라는 질문에는 약하다.

이번 세미나는 이 문제를 정면으로 다뤘다.

 

핵심 메시지는 단순했다.

텍스트 중심 RAG의 한계를 넘기려면,
의미를 문장이 아니라 ‘개념과 관계’로 설계해야 한다.

 

그리고 그 흐름은 이렇게 정리된다.

Ontology → Knowledge Graph → GraphRAG → Agentic GraphRAG

 

이 글은 그 전체 파이프라인을 시스템 관점에서 정리한 기록이다.

 

ㅁ 한 장으로 보는 전체 구조

강의에서 반복적으로 강조된 흐름은 다음과 같다.

Ontology (설계도) → Knowledge Graph (실제 데이터) → GraphRAG (관계 기반 검색) → Agentic GraphRAG (질문별 전략 선택)

• 온톨로지는 의미의 설계도다.
• 지식 그래프는 그 설계도 위에 실제 데이터를 얹은 구조다.
• GraphRAG는 관계를 따라 정보를 찾는다.
• Agentic GraphRAG는 질문을 보고 어떻게 찾을지까지 스스로 결정한다.

중요한 건, 이 네 단계가 서로 독립된 기술이 아니라는 점이다.
앞 단계가 부실하면, 뒤 단계는 성립하지 않는다.

 

ㅁ Ontology — 사람이 아는 것을, 시스템이 알게 만드는 방법

온톨로지는 단순한 데이터 모델이 아니다.

  사람들 사이에서 이미 합의된 개념과 규칙을

  컴퓨터가 이해할 수 있도록 명시적으로 구조화한 의미 모델이다.

예를 들면 이런 것들이다.

• 고객이 무엇인지
• 문서가 어떤 단위로 구성되는지
• 어떤 개념이 다른 개념의 선행 조건인지

사람에게는 상식이지만,
  시스템에게는 반드시 설계가 필요한 영역이다.

  강의에서 인상 깊었던 부분은 이것이었다.

 

온톨로지는 단순 스키마가 아니라,

추론 가능한 규칙 집합

   이라는 점이다.

 

   A가 B에 속하고,
   B가 C에 속하면,
   시스템은 A가 C에 속한다고 “추론”할 수 있어야 한다.

   이게 바로 온톨로지가 필요한 이유다.

 

ㅁ Knowledge Graph — 설계도가 데이터가 될 때

온톨로지가 설계도라면,
  지식 그래프는 그 설계도를 실제 데이터로 채운 상태다.

 

Entity, Relation, Property.

이 세 가지를 중심으로 도메인을 그래프로 표현한다.

 

여기서 중요한 포인트는 이것이다.

그래프 DB(예: Neo4j)를 쓰는 것이 목적이 아니라, 도메인을 구조화하는 것이 목적이다.

 

 그래프는 기술이 아니라 표현 방식이다.

 어떤 개체가 있고, 그 사이에 어떤 관계가 있으며, 그 관계가 어떤 의미를 갖는지를 드러내는 방식.

  이 구조가 명확해야, 이후 단계가 가능해진다.

 

ㅁ GraphRAG — Vector 검색이 놓치는 것들

기존 Vector RAG는 이렇게 동작한다.

1. 문서를 청크로 나눈다
2. 임베딩한다
3. 질문과 가장 가까운 벡터를 찾는다

문제는 이 구조가 관계를 모른다는 것이다.

Vector RAG는 “비슷한 문장”은 찾지만,
“연결된 의미”는 추론하지 못한다.

 

GraphRAG는 다르다.

• 감독 → 영화 → 배우
• 문서 → 섹션 → 개념
• 컴포넌트 → 라이선스 → 원본 URL

이처럼 관계를 따라가며 정보를 찾는다.

그래서 multi-hop 질문이 가능해진다.

 

정리하면 이렇게 표현할 수 있다.

Vector RAG가 “가까운 문장”을 찾는다면,
GraphRAG는 “연결된 의미”를 따라간다.

 

ㅁ Agentic GraphRAG — 검색 방식까지 AI에게 맡기다

여기서 한 단계 더 나아간 것이 Agentic GraphRAG다.

기존 GraphRAG는 파이프라인이 고정돼 있다.

하지만 Agentic GraphRAG는 다르다.

질문을 보고,

• 문서 그래프를 쓸지
• 도메인 그래프를 쓸지
• Cypher를 몇 번 실행할지

이 모든 걸 에이전트가 판단한다.

즉, AI는 이제 답만 생성하지 않는다.

어떻게 찾을지도 스스로 결정한다.

이를 위해 Tool Calling, Planning, Retry Loop 같은 구조가 도입되고,
LangChain, LangGraph 같은 프레임워크가 활용된다.

 

이 단계부터 RAG는 단순 검색 시스템이 아니라,
동적 의사결정 파이프라인이 된다.

 

ㅁ 내가 느낀 가장 중요한 인사이트

 

ㅇ Graph는 코딩 문제가 아니라 도메인 문제다

온톨로지에서 Agentic GraphRAG까지 — “관계 기반 AI”가 필요한 이유

그래프 품질은 코드가 아니라 도메인 이해도에서 나온다.

어떤 관계가 중요한지,
어떤 질문이 들어올지,

이걸 설계하는 사람이 결국 시스템 정확도를 결정한다.

 

 

ㅇ Chunking + Embedding 이후의 세계

Vector는 의미 좌표다.
Graph는 의미 구조다.

둘은 대체 관계가 아니라 보완 관계다.

Embedding으로 “가까움”을 만들고, Graph로 “이유”를 만든다.

 

3. Agent는 자동화가 아니라 전략화다

Agent는 단순히 일을 대신 해주는 존재가 아니다.

질문마다 검색 전략을 바꾸는
 지능형 오케스트레이터에 가깝다.

 

ㅁ 이 구조가 실무에서 의미하는 것

이 구조는 단순 챗봇 이야기가 아니다.

  문서 검증, 정책 판단, 컴플라이언스, 기술 의사결정 등
  모두 같은 패턴으로 확장된다.

예를 들면:

• 컴포넌트 → 라이선스 → 원본
• 문서 → 섹션 → 개념
• 규칙 → 조건 → 결과

이제 RAG는 검색 시스템이 아니라, 의사결정 파이프라인이 된다.

 

ㅁ 마무리

Vector 다음은 Graph, 그 다음은 Agent

 

정리하면 이렇게 이어진다.

• Ontology: 사고 구조
• Graph: 기억 구조
• Agent: 판단 구조

LLM이 똑똑해지는 시대가 아니라,
우리가 AI를 설계해야 하는 시대가 왔다.