지식 그래프의 정의와 역사, 벡터 검색의 한계를 그래프가 어떻게 보완하는지, GraphRAG의 35% 정확도 향상 사례까지 Knowledge Graph와 AI 결합의 전체 그림을 소개합니다.
**Knowledge Graph(지식 그래프)**는 현실 세계의 정보를 Entity(엔티티), Relationship(관계), **Property(속성)**의 세 가지 요소로 구조화하여 표현하는 데이터 모델입니다. 단순한 테이블이나 문서가 아닌, 개체 간의 연결을 명시적으로 표현한다는 점에서 기존 데이터 저장 방식과 근본적으로 다릅니다.
위 다이어그램은 기술 도메인의 간단한 지식 그래프 예시입니다. 각 노드는 엔티티이고, 화살표는 관계를 나타냅니다. 이런 구조를 통해 "Python은 어떤 프레임워크에 사용되는가?", "Neo4j에 연결하는 라이브러리는 무엇인가?" 같은 질문에 그래프 순회만으로 답할 수 있습니다.
지식 그래프의 세 가지 핵심 구성 요소를 정리하면 다음과 같습니다.
| 구성 요소 | 설명 | 예시 |
|---|---|---|
| Entity(엔티티) | 그래프의 노드. 고유한 개체를 나타냄 | Python, Neo4j, GraphRAG |
| Relationship(관계) | 엔티티 간 연결. 방향성을 가짐 | USED_IN, QUERIES, HAS_LIBRARY |
| Property(속성) | 엔티티나 관계에 부착된 메타데이터 | version: "3.12", since: 2024 |
이 세 요소의 조합으로 **Triple(트리플)**이라 불리는 (주어, 술어, 목적어) 형태의 지식 단위가 만들어집니다. 예를 들어 (Python, USED_IN, GraphRAG)는 하나의 트리플입니다.
지식 그래프의 뿌리는 2001년 Tim Berners-Lee가 제안한 Semantic Web(시맨틱 웹) 비전까지 거슬러 올라갑니다. 웹 페이지의 정보를 기계가 이해할 수 있도록 구조화하자는 아이디어였습니다. 당시에는 **RDF(Resource Description Framework)**와 OWL(Web Ontology Language) 같은 표준이 제정되었지만, 실제 웹에서의 채택률은 높지 않았습니다.
그러나 대중적으로 "Knowledge Graph"라는 용어가 널리 알려진 것은 2012년 Google이 Knowledge Graph를 발표하면서부터입니다. 검색 결과 옆에 나타나는 정보 패널 -- 인물의 생년월일, 관련 인물, 주요 업적 등 -- 이 바로 지식 그래프의 산물입니다. Google은 당시 약 5억 개의 엔티티와 35억 개의 관계를 보유하고 있었으며, 이를 통해 "단순한 문자열이 아닌 사물(things, not strings)을 이해한다"고 선언했습니다.
이후 Facebook, Amazon, LinkedIn 등 주요 테크 기업들이 자체 지식 그래프를 구축하기 시작했습니다. Facebook의 Social Graph는 사용자 간 관계를, Amazon의 Product Graph는 상품-속성-카테고리 간 관계를 표현합니다. 지식 그래프는 더 이상 학술적 개념이 아닌, 실전에서 검증된 데이터 인프라가 되었습니다.
2020년대에 들어서면서 지식 그래프는 완전히 새로운 국면을 맞이합니다. **LLM(Large Language Model, 대규모 언어 모델)**의 부상과 함께, 단순한 검색 보조 도구를 넘어 AI 시스템의 핵심 인프라로 재조명되고 있습니다.
LLM은 방대한 텍스트 데이터에서 학습한 언어 능력을 보유하지만, 특정 도메인의 최신 지식이나 정확한 사실 관계에서는 한계를 보입니다. 지식 그래프는 이러한 LLM의 약점을 구조화된 지식으로 보완하는 역할을 합니다. 이 결합이 바로 이 시리즈의 핵심 주제입니다.
**RAG(Retrieval-Augmented Generation, 검색 증강 생성)**는 LLM의 환각(Hallucination) 문제를 해결하기 위해 외부 지식을 검색하여 컨텍스트로 제공하는 방식입니다. 가장 일반적인 구현은 문서를 벡터로 변환하여 유사도 기반 검색을 수행하는 **Vector RAG(벡터 RAG)**입니다.
그러나 벡터 검색만으로는 해결하기 어려운 구조적 한계가 있습니다.
"Python으로 만들어진 프레임워크 중 Neo4j를 사용하는 것은?"이라는 질문에 답하려면 최소 두 단계의 관계를 추적해야 합니다. 먼저 Python 기반 프레임워크를 찾고, 그 중에서 Neo4j를 사용하는 것을 필터링해야 합니다. 벡터 검색은 문서 단위의 유사도만 계산하므로, 이런 **Multi-hop Reasoning(다중 홉 추론)**에 취약합니다. 벡터 공간에서 "Python"과 "Neo4j"를 모두 포함하는 문서를 찾을 수는 있지만, 그것이 "Python으로 만들어진 프레임워크가 Neo4j를 사용한다"는 관계를 의미하는지는 판단할 수 없습니다.
벡터 임베딩은 텍스트의 의미적 유사성을 포착하는 데 탁월하지만, 엔티티 간의 명시적 관계는 소실됩니다. "A가 B의 상위 개념"이라는 계층 구조, "X는 Y의 원인"이라는 인과 관계, "P가 Q에 의존한다"는 의존성 관계는 벡터 공간에서 정확하게 표현되지 않습니다. 두 개의 벡터가 가까이 있다는 것은 의미가 비슷하다는 뜻이지, 특정한 관계가 있다는 뜻이 아닙니다.
벡터 검색은 쿼리와 가장 유사한 문서 조각을 상위 K개 반환합니다. 이 방식은 구체적인 사실을 찾을 때는 효과적이지만, 전체 데이터셋에 걸친 주제 분포, 커뮤니티 구조, 핵심 개념 간 관계 같은 **Global Context(전역 맥락)**를 파악하기에는 근본적으로 부적합합니다. "이 문서 컬렉션에서 가장 자주 언급되는 기술은 무엇이며, 기술 간 주요 관계는 어떻게 구성되어 있는가?"와 같은 질문에는 벡터 검색만으로는 답할 수 없습니다.
벡터 검색이 "나쁜" 기술이라는 의미가 아닙니다. 의미적 유사도 검색에서는 여전히 강력합니다. 핵심은 벡터와 그래프를 결합했을 때 각각의 약점을 보완할 수 있다는 것입니다.
**GraphRAG(그래프 기반 검색 증강 생성)**는 기존 벡터 RAG에 지식 그래프의 구조적 정보를 결합한 접근법입니다. Microsoft Research가 2024년에 발표한 연구에 따르면, GraphRAG는 기존 벡터 전용 RAG 대비 최대 35%의 정확도 향상을 달성했습니다.
GraphRAG의 핵심 아이디어는 질문의 유형에 따라 최적의 검색 전략을 선택하는 것입니다.
실전에서의 GraphRAG는 세 가지 검색 방식을 결합합니다.
| 검색 방식 | 강점 | 약점 |
|---|---|---|
| 벡터 검색 | 의미적 유사도 | 구조 정보 부재 |
| 키워드 검색 (BM25) | 정확한 용어 매칭 | 동의어 처리 약함 |
| 그래프 순회 | 관계 추적, 다중 홉 | 비정형 텍스트 처리 약함 |
이 세 가지를 조합한 **Hybrid Retrieval(하이브리드 검색)**이 현재 GraphRAG의 표준적인 구현 패턴입니다.
대규모 기술 문서를 지식 그래프로 구조화하면, "이 API의 의존성은 무엇인가?", "버전 3에서 변경된 함수 목록은?"과 같은 구조적 질문에 정확하게 답할 수 있습니다. 특히 API 문서, SDK 레퍼런스, 아키텍처 설계서처럼 엔티티 간 관계가 복잡한 문서에서 지식 그래프의 효과가 극대화됩니다. 이 시리즈의 10장에서 실제로 기술 문서 KG를 구축하는 프로젝트를 진행합니다.
약물 간 상호작용, 질병-증상-치료법의 관계를 그래프로 표현하면, "이 약물과 상호작용하는 다른 약물은?"이라는 다중 홉 질문에 안전하게 답할 수 있습니다. 의료 분야는 잘못된 정보가 생명에 직결되므로, LLM의 환각을 최소화하고 근거를 추적할 수 있는 지식 그래프의 설명 가능성이 특히 중요합니다.
거래 네트워크를 그래프로 구성하면, 순환 거래, 이상 패턴, 연관 계정 등을 그래프 알고리즘으로 탐지할 수 있습니다. PageRank로 비정상적으로 많은 연결을 가진 계정을 식별하거나, 커뮤니티 감지로 공모 그룹을 발견하는 것이 대표적인 패턴입니다.
사용자-아이템-속성의 관계를 그래프로 표현하면, 단순 협업 필터링을 넘어 "왜 이 아이템을 추천하는가"에 대한 설명 가능한 추천이 가능합니다. "이 기술에 관심이 있으시다면, 같은 카테고리에 속하며 유사한 사용 사례를 가진 다른 기술도 살펴보세요"와 같은 맥락 기반 추천을 제공할 수 있습니다.
지식 그래프의 가장 큰 장점 중 하나는 **설명 가능성(Explainability)**입니다. AI가 어떤 경로를 따라 답을 도출했는지 그래프 경로로 추적할 수 있어, 블랙박스 문제를 완화합니다.
이 시리즈는 총 10장에 걸쳐 Knowledge Graph와 AI의 결합을 이론부터 실전까지 다룹니다.
| 장 | 내용 |
|---|---|
| 2장 | 그래프 데이터 모델링 기초 |
| 3장 | Neo4j -- 프로퍼티 그래프 데이터베이스 |
| 4장 | Amazon Neptune과 기타 그래프 DB |
| 5장 | LLM 기반 엔티티 추출과 관계 생성 |
| 6장 | GraphRAG -- 그래프 기반 검색 증강 생성 |
| 7장 | 지식 그래프 임베딩 |
| 8장 | 지식 그래프 쿼리와 추론 |
| 9장 | 프로덕션 파이프라인 구축 |
| 10장 | 실전 프로젝트 -- Knowledge Graph + AI 시스템 |
이번 장에서는 Knowledge Graph의 정의, 역사, 그리고 AI 시대에서의 역할을 살펴보았습니다. 핵심 내용을 요약하면 다음과 같습니다.
다음 장 미리보기: 2장에서는 그래프 데이터를 어떻게 설계하는지, 프로퍼티 그래프와 RDF의 차이, 온톨로지 설계 원칙 등 모델링의 기초를 다룹니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
프로퍼티 그래프와 RDF의 차이, 노드/엣지/속성 설계 원칙, 온톨로지 설계부터 실전 도메인 모델링까지 지식 그래프의 데이터 모델링 기초를 다룹니다.
Neo4j의 아키텍처, Cypher 쿼리 언어, 벡터 인덱스, GDS 라이브러리, Python 드라이버까지 지식 그래프 구축에 필요한 Neo4j의 핵심 기능을 다룹니다.
Amazon Neptune의 아키텍처와 Bedrock 통합, 그리고 TigerGraph, JanusGraph, Memgraph 등 주요 그래프 데이터베이스를 비교하며 프로젝트에 맞는 선택 가이드를 제공합니다.