Knowledge Graph란 무엇인가: 생성형 검색이 정보를 이해하고 연결하는 방식

생성형 AI 검색은 더 이상 사용자의 검색어와 일치하는 웹페이지를 나열하는 데 그치지 않습니다. 여러 출처에서 정보를 수집하고, 인물·기업·제품과 같은 객체(Entity)를 식별한 뒤, 이들 사이의 관계를 연결하여 하나의 답변을 생성합니다.

이 과정에서 중요한 것은 단순히 많은 정보를 찾는 것이 아니라, 서로 다른 문서에 등장하는 정보가 무엇을 의미하며 어떻게 연결되는지를 파악하는 것입니다. 이러한 정보 이해의 기반이 되는 대표적인 개념이 바로 Knowledge Graph입니다.

이 글에서는 Knowledge Graph가 무엇인지, 생성형 검색이 정보를 이해하고 연결하는 과정에서 어떻게 활용되는지, 그리고 브랜드 관점에서 어떤 시사점을 가지는지를 살펴보겠습니다.

Knowledge Graph란 무엇인가

구글 검색창에 ‘마리 퀴리’를 입력하면 검색 결과와 함께 생몰년, 국적, 배우자, 수상 이력 등이 정리된 정보 카드가 나타납니다. 이 Knowledge Panel을 구성하는 기반 중 하나가 Knowledge Graph입니다.

구글이 2012년 공개한 Knowledge Graph의 본질은 정보를 문서 단위가 아니라 '객체(Entity)와 관계(Relationship)’로 지도처럼 연결하는 데 있습니다.

문서 안에 흩어진 정보를 각각의 객체와 관계로 표현하면, 검색 시스템은 단어가 등장한 문맥뿐 아니라 해당 객체가 다른 객체와 어떤 관계를 맺고 있는지도 파악할 수 있습니다.

덕분에 검색 엔진은 "Apple"이라는 단어가 "아이폰을 개발했다"는 문맥과 함께 쓰였을 때, 이를 과일이 아닌 '기업 Apple'로 정확히 구분(Disambiguation)할 수 있습니다. 같은 이름을 가진 대상을 문맥과 관계를 통해 구별하는 것입니다.

구글은 2014년 Knowledge Vault 연구를 통해 사람이 직접 입력한 정보 뿐만 아니라 웹에 존재하는 문서에서 사실을 자동으로 추출하고, 이를 기존 지식과 연결하는 방식을 발전시켰습니다.

결과적으로 Knowledge Graph는 두 가지 의미를 갖습니다.

• 데이터 구조: 엔티티와 관계를 그래프로 표현하는 방식
• 검색 인프라: 웹에서 사실을 추출·연결하고, 지속적으로 지식을 축적하는 시스템

즉, Knowledge Graph는 단순한 데이터 저장 방식이 아니라 검색 시스템이 세상의 객체를 식별하고, 관계를 이해할 수 있도록 돕는 구조라고 볼 수 있습니다.

생성형 검색에서도 AI가 브랜드를 하나의 명확한 엔티티로 인식하고, 제품·서비스·기업·사람 사이의 관계를 올바르게 연결할수록 관련성 높고 일관된 답변을 생성할 가능성이 커집니다.

그렇다면 이러한 관계 구조는 생성형 검색에서 왜 필요할까요? 생성형 검색은 단순히 하나의 문서를 찾는 것이 아니라, 여러 출처에 흩어진 정보를 연결해 하나의 답변을 만들어야 하기 때문입니다.

생성형 검색은 왜 정보의 관계를 이해해야 하는가

기존 검색이 사용자의 질문과 관련된 문서를 찾아 보여주는 방식이었다면, 생성형 검색은 여러 문서에 흩어진 내용을 종합하여 하나의 답변을 만들어야 합니다.

예를 들어 다음과 같은 질문이 있다고 가정해보겠습니다.

이 제품을 개발한 회사의 대표는 누구인가?

이 질문에 답하려면 검색 시스템은 하나의 문장에서 답을 찾는 것이 아니라 다음 관계를 순서대로 연결해야합니다.

제품 → 개발사 → 대표자

문제는 LLM이 기본적으로 다음에 등장할 가능성이 높은 토큰(단어)을 예측하도록 학습된 모델이라는 점입니다. 일반적인 언어 패턴을 생성하는 데는 뛰어나지만, 서로 다른 문서에 분산된 사실을 항상 정확한 관계로 연결한다고 보장하기는 어렵습니다.

이러한 문제를 설명하기 위해 Microsoft Research의 GraphRAG 연구를 예시로 들어보겠습니다. 이 연구에서는 질문의 성격을 크게 두 가지로 구분합니다.

• Local 질의: 단일 문서나 청크 안에서 해결 가능한 질문
• Global 질의: 여러 문서의 정보를 종합 해야 하는 질문

생성형 검색에서는 일반적으로 질문과 의미적으로 유사한 문서를 검색한 뒤, 이를 바탕으로 답변을 생성하는 Vector RAG가 널리 사용됩니다. 이 방식은 Local 질의에는 효과적입니다. 하지만 여러 문서의 정보를 연결해야 하는 Global 질의에서는 필요한 관계가 검색 과정에서 누락될 수 있습니다.

Knowledge Graph는 이때 서로 다른 문서에서 추출한 엔티티와 관계를 구조적으로 연결해줍니다.

Knowledge Graph의 역할은 LLM 자체에 새로운 지식을 학습시키는 것이 아닙니다. 답변을 생성할 때 필요한 사실과 관계를 보다 명확한 형태로 제공하여, 어떤 정보를 어떤 순서로 연결해야 하는지 안내하는 데 있습니다.

즉, 생성형 검색에서 Knowledge Graph는 모델의 능력을 직접 높이는 기술이라기보다, 정보를 찾고 연결하는 과정에 구조를 제공하는 기반에 가깝습니다.

그렇다면 Knowledge Graph에 표현된 엔티티와 관계를 실제 검색 및 답변 생성 과정에는 어떻게 활용할 수 있을까요? 이를 보여주는 대표적인 접근 방식이 GraphRAG입니다.

Knowledge Graph는 생성형 검색에서 어떻게 활용되는가

GraphRAG는 Knowledge Graph와 검색 증강 생성(RAG)을 결합하는 접근 방식의 총칭입니다. 그중 Microsoft Research가 공개한 GraphRAG는 문서에서 엔티티와 관계를 추출하고, 그래프 커뮤니티를 구성한 뒤 이를 단계적으로 요약합니다.

대표적인 과정은 다음과 같습니다.

• 지식의 그래프화 : 웹 문서와 내부 데이터에서 인물, 기업, 제품, 사건 등과 같은 엔티티를 추출합니다.이후 엔티티 사이의 관계를 찾아 하나의 지식망으로 구성합니다.
• 관련 정보의 그룹화 (Leiden 알고리즘): 서로 밀접하게 연결된 엔티티와 관계를 하나의 커뮤니티 또는 주제 그룹으로 묶습니다. GraphRAG에서는 Leiden 알고리즘 등을 활용해 거대한 그래프 안에서 관련성이 높은 정보 집단을 찾습니다. 라이덴 알고리즘이란, 복잡한 네트워크 데이터(소셜 네트워크, 인용 데이터 등)에서 밀접하게 연관된 노드들의 그룹인 '커뮤니티'를 빠르고 정확하게 찾아내는 그래프 기반 군집화 알고리즘입니다.
• 단계별 통합 요약 (Map-Reduce) : 질문이 입력되면 각 커뮤니티의 요약본을 먼저 만든 뒤, 여러 요약 결과를 종합하여 최종 답변을 완성합니다.

Vector RAG와 GraphRAG의 차이를 간단히 표현하면 다음과 같습니다.

• Vector RAG: 질문과 가장 유사한 문서를 찾는 방식
• GraphRAG: 질문과 관련된 엔티티와 관계를 따라 정보를 연결하고 종합하는 방식

실제 벤치마크에서도 이 차이는 뚜렷합니다. 아마존 전자제품 리뷰 데이터를 활용한 연구에 따르면, "어떤 브랜드에 충전 불만이 가장 많은가?"와 같이 여러 문서의 맥락을 연결해야 하는 질문에서 GraphRAG를 정답과 직접 대조하여 도출했더니 73.5%의 정확도를 보인 반면, 일반 Vector 검색은 18.5%에 그쳤습니다.

또한 통신 기술(Open RAN) 분야 연구에서도 그래프 기반 시스템이 변동성이 적고 신뢰도가 더 높은 안정적인 응답을 일관되게 생성하는 것으로 나타났습니다.

어떤 방식이 항상 우수하다기보다 질문의 성격에 따라 적합한 접근이 달라집니다.특정 문서에서 정확한 문장을 찾는 질문에는 Vector RAG가 효율적일 수 있습니다. 반면 여러 문서에 흩어진 사실을 연결하거나 전체 데이터의 흐름과 주제를 파악해야 하는 질문에는 GraphRAG가 더 적합할 수 있다는 것입니다.

GraphRAG가 구글 AI 검색의 작동 방식을 그대로 설명하는 것은 아닙니다. 다만 생성형 검색이 여러 출처를 탐색하고, 엔티티를 식별하며, 정보를 관계에 따라 종합한다는 공통 과제를 이해하는 데 유용한 사례입니다.

구글 AI 검색과 Gemini 환경에서 지식 그래프(KG)가 가지는 의미와 역할

그렇다면 이러한 관계 기반 정보 구조는 구글의 생성형 검색 환경에서는 어떤 의미를 가질까요? GraphRAG는 특정한 검색·생성 프레임워크이고, 구글 AI 검색이나 Gemini의 전체 작동 방식과 동일한 기술은 아닙니다.다만 생성형 검색이 여러 검색 결과를 종합하고, 질문을 세분화하며, 객체 간 관계를 파악해야 한다는 점에서는 공통된 문제를 다룹니다.

이러한 환경에서 Knowledge Graph는 크게 세 가지 역할을 할 수 있습니다.

Google은 AI Mode가 질문을 여러 하위 주제로 나누어 관련 검색을 동시에 수행한다고 설명합니다. 이 과정의 세부 구조가 모두 공개된 것은 아니지만, Knowledge Graph와 같은 엔티티 기반 정보는 질문에 포함된 대상을 식별하고 관련 개념을 확장하는 데 활용될 수 있습니다.

• 이때 지식 그래프는 핵심 객체(Entity)와 연결된 주변 정보를 탐색하는 이정표가 됩니다.
• 덕분에 AI는 단순 키워드 매칭을 넘어, 브랜드와 긴밀히 연결된 정교한 연관 쿼리를 파생시키고 가장 관련성 높은 맞춤형 커스텀 코퍼스(Custom Corpus)를 수집합니다.

여러 문서의 정보를 종합해야 하는 복합 질의(Global 질의)에서 AI는 논리적 추론 체인(Reasoning Chains)을 설계해야 합니다.

• LLM은 다음 토큰을 확률적으로 예측하는 특성상, 파편화된 문서를 연결하는 과정에서 흐름을 잃거나 환각을 일으키기 쉽습니다.
• 예를 들어, "A 제품 ➔ 개발사 B ➔ B사의 대표 C"와 같이 Knowledge Graph는 엔티티 사이의 관계를 명시적인 경로로 표현합니다. 검색 시스템은 이 관계를 따라가며 서로 다른 출처에서 수집된 정보를 연결할 수 있습니다.이는 생성형 검색이 복합 질문에 답하거나 여러 사실을 바탕으로 문맥을 구성할 때 중요한 기반이 됩니다.

생성형 검색은 검색, 요약, 비교, 정보 추출 등 여러 단계를 거쳐 답변을 구성합니다. 이 과정에서 생성된 내용이 기존에 확인된 엔티티와 관계에 부합하는지 검증하는 절차가 필요합니다. Knowledge Graph는 주어-관계-목적어 형태로 정리된 사실을 제공하여, 생성된 답변을 구조화된 지식과 대조할 수 있는 기준이 됩니다. Knowledge Graph는 생성형 검색이 정보를 수집하고 답변을 조합하는 과정에서 다음과 같은 기반을 제공합니다.

• 질문에 포함된 대상 식별
• 관련 엔티티 탐색
• 여러 단계의 관계 연결
• 생성된 답변의 사실 검증

브랜드 관점에서도 이 구조는 중요합니다. AI가 특정 브랜드를 하나의 엔티티로 정확히 인식하려면 공식 웹사이트, 보도자료, 뉴스, SNS 등에 등장하는 브랜드명과 제품명, 인물 정보가 일관되어야 합니다. 또한 각 객체 사이의 관계가 문서 안에 명확하게 표현되어야 합니다.

지금까지는 Knowledge Graph가 생성형 검색에서 어떤 역할을 하는지 살펴보았습니다. 그렇다면 엔티티와 관계로 구성된 이 지식 구조는 실제 시스템에서 어떤 형태로 저장되고 탐색될까요?

Knowledge Graph는 어떻게 저장되고 활용되는가

Knowledge Graph는 단순한 개념적 지도가 아닙니다. 문서에서 추출한 엔티티와 관계는 실제 데이터 구조로 저장되어야 검색과 탐색에 활용할 수 있습니다.

대표적인 저장 방식은 다음과 같습니다.

• RDF Triple Store: 모든 사실을 주어(Subject)-관계(Predicate)-목적어(Object)의 트리플 형태로 저장하는 방식입니다. 예를 들면, 마리 퀴리 - 배우자 - 피에르 퀴리 RDF는 W3C 표준을 기반으로 하며, Wikidata와 같은 오픈 지식 생태계나 공공 데이터 연결에 널리 활용됩니다.

마리 퀴리 - 배우자 - 피에르 퀴리

RDF는 W3C 표준을 기반으로 하며, Wikidata와 같은 오픈 지식 생태계나 공공 데이터 연결에 널리 활용됩니다.

• Labeled Property Graph(LPG): 엔티티를 노드로, 관계를 연결선으로 표현하고 각 노드와 관계에 속성값을 추가하는 방식입니다.Neo4j와 같은 그래프 데이터베이스가 대표적인 구현 사례입니다. 제품, 고객, 기업, 거래처럼 속성이 다양한 비즈니스 데이터를 비교적 유연하게 표현할 수 있습니다.

RDBMS의 JOIN과 Graph DB의 관계 탐색

관계형 데이터베이스는 정보를 테이블에 나누어 저장합니다. 여러 단계의 관계를 찾으려면 테이블 사이에서 JOIN 연산을 반복해야 합니다. 반면 Graph DB는 노드 사이의 관계를 직접 저장하고, 연결된 경로를 따라 데이터를 탐색합니다.

예를 들어 ‘브랜드 → 제품 → 제조사 → 대표자’로 이어지는 관계를 조회할 때 관계형 데이터베이스(RDBMS)는 여러 테이블을 연결해야 합니다. Graph DB에서는 각 노드 사이에 저장된 관계를 따라 탐색할 수 있기 때문에, 여러 단계로 연결된 관계를 표현하고 조회하는 데 적합합니다. 하지만 Graph DB가 관계를 빠르게 탐색한다고 해도, 처음부터 엔티티와 관계가 정확하게 추출되지 않았다면 필요한 경로는 존재하지 않습니다.

그래프 데이터베이스에 저장되는 엔티티와 관계는 처음부터 자동으로 완벽하게 만들어지는 것이 아닙니다. 검색 시스템은 웹 문서와 구조화된 데이터에서 객체와 관계를 추출해 그래프를 구성합니다. 따라서 원천 콘텐츠에서 주체와 관계가 불분명하면 그래프에도 정확한 연결이 만들어지기 어렵습니다.

따라서 콘텐츠를 작성할 때도 다음처럼 관계가 명확한 문장을 사용하는 것이 중요합니다.

제품 A는 B사에서 개발했으며, B사의 대표는 C이다.

이처럼 주체와 관계, 대상이 명시되면 검색 시스템은 텍스트에서 엔티티와 관계를 보다 쉽게 추출할 수 있습니다.

마무리

Knowledge Graph, GraphRAG, Graph DB는 서로 동일한 기술은 아니지만, 생성형 검색이 정보를 관계 중심으로 이해하고 활용하는 과정을 설명하는 하나의 흐름으로 연결됩니다.

Knowledge Graph는 현실의 인물, 기업, 제품과 같은 대상을 엔티티로 정의하고, 엔티티 사이의 관계를 구조화합니다. GraphRAG는 이러한 관계 구조를 검색과 답변 생성 과정에 활용하는 접근 방식이며, Graph DB는 엔티티와 관계를 실제로 저장하고 탐색하기 위한 기술입니다.

생성형 검색 시대에 브랜드가 반드시 직접 Knowledge Graph를 구축해야 하는 것은 아닙니다.

더 중요한 것은 AI가 브랜드를 하나의 명확한 엔티티로 식별하고, 제품·서비스·기업·인물 사이의 관계를 일관되게 추출할 수 있도록 디지털 정보를 구성하는 것입니다.

이를 위해 점검해야 할 핵심 기준은 두 가지입니다.

브랜드와 주요 객체 사이의 관계가 명확하게 표현되어야 합니다.문장 안에서 주체, 관계, 대상이 분명하게 드러나야 하며, 필요한 경우 Schema.org와 같은 구조화된 마크업을 함께 활용할 수 있습니다.관계가 명시되어야 검색 시스템도 이를 하나의 사실로 인식하고 다른 정보와 연결할 수 있습니다.

브랜드명, 제품명, 서비스명, 대표자명 등이 채널마다 다르게 표현되면 검색 시스템은 이를 서로 다른 객체로 인식할 수 있습니다.공식 웹사이트, 보도자료, 뉴스, SNS 등 여러 채널에서 동일한 명칭과 설명을 일관되게 사용하는 것이 중요합니다.

결국 GEO(생성형 엔진 최적화)는 단순히 키워드를 반복하거나 콘텐츠의 양을 늘리는 작업이 아닙니다. AI가 브랜드를 하나의 신뢰할 수 있는 엔티티로 식별하고, 제품·서비스·기업·인물 사이의 관계를 정확하게 연결할 수 있도록 디지털 정보를 명확하고 일관되게 구성하는 전략에 가깝습니다. 앞으로의 검색 노출 경쟁력은 콘텐츠의 생산량뿐 아니라, 브랜드의 정보와 관계를 AI가 얼마나 쉽게 이해할 수 있도록 표현했는가에 따라 달라질 것입니다.

브랜드 엔티티 구조화 체크리스트

---

자주 묻는 질문

Knowledge Graph는 LLM에 새로운 지식을 학습시키는 기술인가요?

아니요. 본문에서 밝힌 대로 Knowledge Graph의 역할은 LLM 자체에 새로운 지식을 학습시키는 것이 아니라, 답변 생성에 필요한 사실과 관계를 명확한 형태로 제공해 어떤 정보를 어떤 순서로 연결해야 하는지 안내하는 데 있습니다.

Vector RAG와 GraphRAG 중 무엇이 더 나은가요?

질문 성격에 따라 다릅니다. 특정 문서에서 정확한 문장을 찾는 Local 질의에는 Vector RAG가 효율적이고, 여러 문서에 흩어진 사실을 연결해야 하는 Global 질의에는 GraphRAG가 더 적합할 수 있습니다.

GraphRAG가 구글 AI 검색의 실제 작동 방식인가요?

아니요. 본문에서 명시하듯 GraphRAG는 특정한 검색·생성 프레임워크이며, 구글 AI 검색이나 Gemini의 전체 작동 방식과 동일한 기술은 아닙니다. 다만 생성형 검색이 다루는 공통 과제를 이해하는 데 유용한 사례로 소개됩니다.

RDF Triple Store와 Labeled Property Graph는 어떻게 다른가요?

RDF Triple Store는 모든 사실을 주어-관계-목적어의 트리플 형태로 저장하는 W3C 표준 방식이고, Labeled Property Graph(LPG)는 엔티티를 노드로, 관계를 연결선으로 표현하며 각 노드와 관계에 속성값을 추가하는 방식입니다. Neo4j가 LPG의 대표적인 구현 사례입니다.

브랜드가 반드시 직접 Knowledge Graph를 구축해야 하나요?

아니요. 본문에서 강조하듯 더 중요한 것은 AI가 브랜드를 하나의 명확한 엔티티로 식별하고 관계를 일관되게 추출할 수 있도록, 관계의 완결성과 엔티티 표기의 일관성을 갖춰 디지털 정보를 구성하는 것입니다.

---

용어 설명

1. Knowledge Graph — 정보를 문서 단위가 아니라 객체(Entity)와 관계(Relationship)로 지도처럼 연결하는 구조. 구글이 2012년 공개. 본문의 핵심 개념.
2. Entity(엔티티) — 인물, 기업, 제품, 사건 등 검색 시스템이 식별하는 개별 객체.
3. GraphRAG — Knowledge Graph와 검색 증강 생성(RAG)을 결합한 접근 방식의 총칭. Microsoft Research가 공개한 버전은 엔티티·관계 추출, Leiden 알고리즘 기반 그룹화, Map-Reduce 요약의 3단계로 구성.
4. Vector RAG — 질문과 의미적으로 유사한 문서를 임베딩 기반으로 검색해 답변을 생성하는 방식. Local 질의에 효과적.
5. Local 질의 / Global 질의 — Local 질의는 단일 문서나 청크 안에서 해결 가능한 질문, Global 질의는 여러 문서의 정보를 종합해야 하는 질문.
6. Leiden 알고리즘 — 복잡한 네트워크 데이터에서 밀접하게 연관된 노드들의 커뮤니티를 빠르고 정확하게 찾아내는 그래프 기반 군집화 알고리즘.
7. RDF Triple Store — 모든 사실을 주어-관계-목적어의 트리플 형태로 저장하는 W3C 표준 기반 방식. Wikidata 등에 활용.
8. Labeled Property Graph(LPG) — 엔티티를 노드로, 관계를 연결선으로 표현하고 속성값을 추가하는 그래프 저장 방식. Neo4j가 대표 사례.
9. Index-Free Adjacency — Graph DB가 노드 사이의 연결 포인터를 직접 추적해, 관계 깊이와 상관없이 선형적으로 탐색할 수 있게 하는 설계 원리.

참고 출처 (References)

• [Dong et al., Google Research, SIGMOD 2014] Knowledge Vault: A Web-Scale Approach to Probabilistic Knowledge Fusion(구글 Knowledge Graph의 후속 연구로, 수작업 없이 웹 전체에서 사실을 자동 추출하고 신뢰도를 매기는 방식을 규명)
• [Edge et al., Microsoft Research, 2024] From Local to Global: A Graph RAG Approach to Query-Focused Summarization(GraphRAG의 원 논문. Local/Global 질의 구분 및 Leiden 알고리즘을 통한 커뮤니티 탐지, Map-Reduce 요약 구조 설명)
• [arXiv:2506.06331] How Significant Are the Real Performance Gains? An Unbiased Evaluation Framework for GraphRAG(GraphRAG 평가 방식인 LLM-as-judge의 위치·길이·시행 편향을 과학적으로 검증하고 보정한 연구)
• [Diffbot, FalkorDB Blog] KG-LM Accuracy Benchmark(지식 그래프 유무에 따른 LLM 정확도 격차를 기업 실무 질의를 통해 측정한 실증 데이터)
• [AIMultiple] Graph RAG vs Vector RAG Benchmark(아마존 리뷰 데이터를 기반으로 질의 유형별 정확도를 대조한 벤치마크)
• [arXiv:2507.03608] Benchmarking Vector, Graph and Hybrid RAG Pipelines for Open RAN(특정 도메인 데이터셋 하에서 Vector, Graph, Hybrid 파이프라인의 환각 저항성 및 신뢰도를 종합 비교)
• [Neo4j 공식 블로그] It's All in the Relationships: 15 Rules of a Native Graph Database(네이티브 그래프 DB의 근간이 되는 Index-Free Adjacency의 상세 설계 원리 정의)