GraphRAG의 모든 것 — Part 2 강의 노트
출처: Fast Campus · 공원나연 강사
Ch1. 지식그래프 표현방법 이해하고 그려보기
목차
- 지식그래프가 무엇인지 이해하기
- 지식그래프 표현을 위한 데이터 모델 이해하기
- LPG와 RDF 모델 비교하고 특징 살펴보기
arrows.app사용하여 직접 지식그래프 만들기- 지식그래프를 표현하기 위한 판단 기준 이해하기
1. 지식그래프(Knowledge Graph)란?
서로 연결된 개체들을 의미 기반으로 표현한 데이터 모델로, 데이터를 저장하고, 조직하고, 이해하는 데 사용됨
💡 쉽게 이해하기 일반 데이터베이스가 “표(Table)” 형태로 데이터를 저장한다면, 지식그래프는 사람이 머릿속에서 개념을 연결하는 방식처럼 데이터를 저장한다. 예를 들어 “봉준호는 감독이고, 기생충을 만들었고, 기생충은 드라마 장르다”처럼 사실들을 연결망(그래프) 으로 표현하는 것이다.
| 구성요소 | 설명 | 예시 |
|---|---|---|
| 엔티티 (Entities) | 조직이나 특정 도메인의 데이터를 나타내는 실체 | 사람, 영화, 장소, 개념 등 |
| 관계 (Relationships) | 엔티티 간의 상호작용 또는 연관성을 나타내며, 데이터에 문맥(Context)을 부여 | ”감독했다”, “살고 있다”, “소속이다” 등 |
관계가 핵심인 이유
일반 DB는 “봉준호”와 “기생충”이라는 데이터가 있어도 둘의 관계를 묻는 질문에 여러 테이블을 JOIN해야 한다. 지식그래프는 처음부터 관계 자체를 데이터로 저장하기 때문에, 복잡한 연결 질의를 훨씬 빠르고 자연스럽게 처리할 수 있다.
2. 지식그래프의 장점
| # | 장점 | 설명 |
|---|---|---|
| 01 | 복잡한 관계 파악 | 엔티티 간의 숨겨진 패턴과 연결을 파악해 복잡한 관계를 이해할 수 있음 |
| 02 | 인사이트 발견 | 관계 중심의 탐색을 가능하게 하고, 더 나은 의사결정을 위한 인사이트를 발견할 수 있음 |
| 03 | AI 시스템의 핵심 | 추천 시스템, 의미 검색, AI 에이전트와 같은 AI 기반 시스템의 핵심 요소 |
| 04 | 유연한 탐색 | 관계형 DB에서는 복잡한 관계 탐색을 그래프 DB에서는 유연하게 수행할 수 있음 |
💡 실생활 비유로 이해하기
- 01 복잡한 관계 파악: “A와 B가 친구이고, B와 C도 친구라면, A와 C는 2단계 연결”처럼 SNS의 친구 추천 알고리즘이 지식그래프 원리를 사용한다.
- 03 AI 시스템의 핵심: 넷플릭스 추천(“이 영화를 본 사람은 저 영화도 좋아했어요”)이나 구글 검색의 “지식 패널”도 지식그래프 기반이다.
- 04 유연한 탐색: SQL로 5단계 JOIN을 해야 하는 쿼리를 그래프 DB는 노드를 따라가는 방식으로 간단하게 처리한다.
3. 지식그래프를 표현하는 방식 — 그래프 데이터 모델
두 가지 주요 모델이 존재한다:
RDF (Resource Description Framework) ←→ LPG (Labeled Property Graph)
주어-술어-목적어의 트리플 구조로 표현 노드, 관계, 속성으로 구성
💡 두 방식의 핵심 차이
- RDF: “모든 것을 세 단어로 쪼개서 표현한다” — 매우 엄격하고 표준화된 방식. 마치 법률 문서처럼 정확하지만 복잡하다.
- LPG: “노드에 직접 속성을 붙이고, 관계에도 이름을 붙인다” — 사람이 생각하는 방식과 비슷해서 직관적이다.
RDF 표현 예시 (영화 “기생충”)
영화_1 → rdf:type → 영화 ← "영화_1의 타입은 영화다"
영화_1 → 제목 → 기생충 ← "영화_1의 제목은 기생충이다"
영화_1 → 감독 → 감독_1 ← "영화_1의 감독은 감독_1이다"
감독_1 → rdf:type → 사람 ← "감독_1의 타입은 사람이다"
감독_1 → 이름 → 봉준호 ← "감독_1의 이름은 봉준호다"
영화_1 → 장르 → 장르_1
장르_1 → rdf:type → 장르
장르_1 → 이름 → 드라마
영화_1 → 개봉연도 → 연도_2019
연도_2019 → rdf:type → 연도
연도_2019 → 값 → 2019
RDF는 “개봉연도: 2019”라는 단순한 정보도
연도_2019라는 중간 노드를 만들어서 표현한다. 매우 엄격하고 상세하지만, 표현이 장황해진다.
LPG 표현 예시 (동일한 데이터)
영화_1
제목: 기생충 ← 노드에 속성을 직접 붙임
개봉연도: 2019 ← 중간 노드 없이 바로 값 저장
영화_1 → 감독하다 → 봉준호 ← 관계에 한국어 동사 사용 가능
영화_1 → 장르이다 → 드라마
LPG는 속성(제목, 개봉연도)을 노드에 직접 붙이고, 관계도 자연어에 가까운 이름을 쓸 수 있다. 훨씬 간결하다.
4. RDF vs LPG 비교
| 항목 | RDF | LPG |
|---|---|---|
| 구조 | 주어-술어-목적어 (트리플) | 노드 + 관계 + 속성 |
| 코드 예시 | :Alice :KNOWS :Bob . | (:Person {name: "Alice", age: 30})-[:KNOWS {since: 2020}]->(:Person {name: "Bob"}) |
| 특징 | 온톨로지와 규칙을 통해 추론 및 유추를 지원 | 실시간 그래프 탐색 및 분석에 최적화 |
| 적합한 용도 | 시맨틱 웹과 링크드 데이터 | 간단하고 직관적이며, 인간의 사고 흐름과 일치 |
💡 코드 예시 해석
- RDF
:Alice :KNOWS :Bob .→ “Alice는 Bob을 안다”를 세 단어로 표현. 점(.)으로 문장을 끝냄 - LPG
(:Person {name: "Alice", age: 30})-[:KNOWS {since: 2020}]->(:Person {name: "Bob"})→ Alice 노드(나이 30 포함) → KNOWS 관계(2020년부터) → Bob 노드. 관계에도 속성(since: 2020)을 붙일 수 있다는 게 핵심
언제 어떤 방식을 사용할까?
| 사용 목적 | 권장 모델 | 이유 |
|---|---|---|
| 개념 정의, 의미 체계, 표준화 | RDF | 표준화된 온톨로지(OWL, RDFS)와 결합해 개념 간 규칙과 계층을 정의할 수 있음 |
| 서비스 데이터, 로그, 추천, 탐색 | LPG | 빠른 그래프 탐색과 직관적 모델링에 적합 |
| AI 추론, 온톨로지 기반 추론 (reasoning) | RDF | ”포유류는 동물이다 → 개는 포유류다 → 따라서 개는 동물이다”처럼 논리 규칙으로 새로운 사실을 추론 가능 |
| GraphRAG, 실시간 질의 | LPG | Neo4j 등 그래프 DB와 궁합이 좋고, 실시간 Cypher 쿼리 성능이 우수 |
실무 선택 기준
지식 구조를 “표준화”하고 “추론”해야 한다면 RDF, “빠르게 개발”하고 “실시간으로 조회”해야 한다면 LPG. GraphRAG 프로젝트에서는 대부분 LPG(Neo4j)를 선택한다.
5. LPG의 장점
| 장점 | 설명 | 실무 의미 |
|---|---|---|
| 단순성과 직관성 | 실제 세계의 관계를 반영하는 개발자 친화적인 데이터 모델 | ”사람이 회사에 다닌다”를 그대로 노드-엣지로 표현 가능 |
| 그래프 탐색 성능 | 트리플을 관리하기 위한 복잡한 메커니즘 없이 관계를 직접 모델링 | 연결을 따라가는 탐색(traversal)이 매우 빠름 |
| 스키마 유연성 | 요구 사항 변화에 따라 데이터 모델을 조정 | 새로운 노드 타입이나 관계를 자유롭게 추가 가능 |
| 효율적인 순회(Traversal) | RDF에 비해 간소화된 관계 설계로 저비용 고성능 탐색 수행 | ”친구의 친구의 친구” 같은 다단계 연결 탐색에 특히 강함 |
💡 Traversal(순회)이란? 그래프에서 노드를 연결된 엣지를 따라 탐색하는 것. 예를 들어 “서울에 사는 사람들이 좋아하는 식당의 요리사가 배운 레시피”처럼 여러 단계를 거치는 검색을 빠르게 처리할 수 있다.
6. 지식그래프 설계 도구
arrows.app — 지식그래프 설계를 위한 모델링 툴
- URL: https://arrows.app/
- Neo4j Labs 제공
- LPG 기반 그래프를 시각적으로 설계 가능
💡 어떻게 사용하나? arrows.app은 코드 없이 마우스로 노드(원)를 그리고, 노드 사이에 화살표(관계)를 연결하고, 이름과 속성을 붙일 수 있는 그래프 화이트보드 도구다. 설계한 그래프를 Neo4j Cypher 코드로 내보낼 수 있어서 실제 DB 구축 전 설계 단계에 유용하다.
Ch2. GraphRAG를 위한 지식그래프
1. RAG(Retrieval-Augmented Generation)란?
검색 증강 생성 — LLM이 답변을 생성하기 전 지식 베이스에서 관련 정보를 검색하여 활용하는 기술
💡 왜 RAG가 필요한가? ChatGPT 같은 LLM은 학습 당시의 데이터만 알고 있다. 최신 정보나 회사 내부 문서를 모른다. RAG는 질문이 들어오면 먼저 외부 문서(DB, PDF 등)에서 관련 정보를 검색해서 LLM에게 넘겨주는 방식으로, LLM이 실제 문서를 보고 답변하게 만든다.
RAG 동작 흐름:
① 사용자가 질문 입력 (Prompt + Query)
↓
② 질문으로 Knowledge Sources(문서 DB 등)에서 관련 정보 검색
↓
③ 검색된 관련 정보(Enhanced Context) 반환
↓
④ "원래 질문 + 검색된 정보"를 함께 LLM에 전달
↓
⑤ LLM이 검색된 정보를 참고해서 정확한 답변 생성
RAG의 핵심 아이디어
LLM 자체를 재학습시키는 건 비용이 엄청나다. RAG는 LLM은 그대로 두고, 필요한 정보를 그때그때 꺼내서 주입하는 방식이라 훨씬 실용적이다.
2. Vector RAG vs Graph RAG
| 항목 | Vector RAG | Graph RAG |
|---|---|---|
| 저장 방식 | 문서 → 청크 → 임베딩(숫자 벡터) | 청크 + 엔티티 / 관계 (그래프 구조) |
| 검색 방법 | 벡터 유사도 기반 (의미가 비슷한 청크 찾기) | 그래프 탐색 + 벡터 검색 결합 |
| 제공하는 컨텍스트 | 유사한 청크들의 텍스트 | 연결된 지식 구조 전체 (관계 포함) |
💡 Vector RAG의 한계 문서를 여러 청크로 나눠 벡터로 저장하면, “비슷한 문장”은 잘 찾는다. 하지만 “A가 B와 어떤 관계인지”, “이 개념이 저 개념과 어떻게 연결되는지” 같은 관계형 질문에는 취약하다. 청크는 섬처럼 고립돼 있기 때문이다.
💡 Graph RAG가 더 강한 이유 청크 텍스트를 저장할 때, 그 안에 등장하는 엔티티(사람, 개념, 장소 등)와 관계까지 함께 그래프로 저장한다. 검색 시 유사한 청크를 찾은 후, 그 청크와 연결된 주변 지식(관련 엔티티, 다른 문서의 청크 등)까지 함께 가져올 수 있다.
비유
Vector RAG는 도서관에서 제목이 비슷한 책만 찾는 것. Graph RAG는 그 책의 참고문헌을 따라가며 관련 책들도 함께 가져오는 것.
3. GraphRAG 아키텍처
Question (사용자 질문)
↓
Encoder (질문을 벡터로 변환)
↓
Tool Selection (어떤 검색 도구를 쓸지 결정)
├─ Search (벡터 검색)
├─ Search + Pattern Match (그래프 패턴 매칭 + 벡터)
└─ Query (Cypher 쿼리 등 직접 질의)
↓
┌─────────────────────────────────┐
│ Graph Database │
│ Lexical Graph ←→ Domain Graph│
│ (문서/청크 계층) (도메인 지식) │
└─────────────────────────────────┘
↓
Context (검색 결과 컨텍스트 조합)
↓
LLM + Instruction (지시문 + 컨텍스트로 생성)
↓
Answer (최종 답변)
지식그래프는 GraphRAG 시스템의 핵심 요소로, LLM에게 더욱 정확하고 풍부한 컨텍스트를 제공
💡 Lexical Graph vs Domain Graph의 역할 분담
- Lexical Graph: “이 문서의 어떤 부분에 정보가 있는가?” (문서 탐색)
- Domain Graph: “이 개념은 무엇이고, 다른 개념과 어떤 관계인가?” (지식 탐색)
- 두 그래프가 서로 연결돼 있어서, 텍스트 검색에서 시작해서 도메인 지식으로 확장할 수 있다.
4. GraphRAG에서 지식그래프의 역할
| 역할 | 설명 | 실용적 의미 |
|---|---|---|
| 관계 이해 | 데이터 속 패턴과 관계를 표현 | ”A 약품은 B 질환에 효과적이고, B 질환은 C 증상을 유발한다”처럼 연결된 사실 파악 |
| 의미 검색 | 관련 정보 반환을 위한 데이터 청킹 | 단순 키워드 매칭이 아닌, 의미적으로 연관된 정보를 그래프 경로로 찾음 |
| 주변 관계 | 멀티 홉 탐색 지원 | 직접 연결된 정보뿐 아니라 2~3단계 떨어진 간접 관련 정보도 검색 가능 |
| 효율 검색 | 도메인 지식을 반영한 그래프 구조 | 도메인에 맞는 스키마 설계로 불필요한 데이터 탐색을 줄여 빠른 응답 |
💡 멀티 홉(Multi-hop) 탐색이란? 예: “이 약을 처방한 의사가 근무하는 병원의 전문 분야는?” → 약 → 의사 → 병원 → 전문분야. 이처럼 여러 노드를 거쳐(hop) 답을 찾는 것. 일반 벡터 검색으로는 어렵지만, 그래프 탐색으로는 자연스럽게 처리된다.
5. 그래프의 두 종류
도메인 그래프 (Domain Graph)
특정 비즈니스/지식 도메인의 실제 개념과 관계를 구조화한 그래프
💡 도메인 그래프란 무엇인가? 도메인 그래프는 “우리 서비스에서 중요한 개념들이 무엇이고, 서로 어떻게 연결되는가”를 표현한 것이다. 예를 들어 영화 서비스라면 영화·감독·배우·장르가 핵심 개념이고, 이들 사이의 관계(감독했다, 출연했다, 장르이다)가 도메인 그래프를 이룬다.
| 도메인 | 노드 (엔티티) | 관계 예시 |
|---|---|---|
| 영화 | 영화, 유저, 장르, 감독, 배우 | DIRECTED, ACTED_IN, IN_GENRE, RATED |
| 의료 | 환자, 의사, 진료, 약, 질병 | PRESCRIBED, DIAGNOSED_WITH, TREATS |
| 무역 | 공급업체, 카테고리, 고객, 제품, 주문 | SUPPLIES, ORDERED, BELONGS_TO |
예시 스키마 (영화 도메인):
(Director)-[DIRECTED]->(Movie)<-[ACTED_IN {role: "주연"}]-(Actor)
(Movie)-[IN_GENRE]->(Genre)
(User)-[RATED {rating: 5}]->(Movie)어휘 그래프 (Lexical Graph)
문서를 청크로 나누어 계층적으로 연결한 그래프
💡 어휘 그래프란 무엇인가? RAG에서 문서를 단순히 청크로 잘라 저장하면 각 청크는 섬처럼 고립된다. 어휘 그래프는 “어떤 청크가 어떤 문서의 일부인지”를 그래프로 저장해서, 청크를 찾은 후 원본 문서 전체 맥락을 추적할 수 있게 한다.
Document (원본 문서 노드)
├── PART_OF ← Chunk 1 (문서 앞부분 텍스트)
├── PART_OF ← Chunk 2 (문서 중간 텍스트)
└── PART_OF ← Chunk n (문서 뒷부분 텍스트)
확장된 그래프: Chunk + Entity 포함 (Lexical + Domain 결합)
청크 안의 텍스트에서 엔티티(개체)와 관계를 추출해서 도메인 그래프와 연결
Document
├── PART_OF ← Chunk 1
├── PART_OF ← Chunk 2
└── PART_OF ← Chunk n
↓ HAS_ENTITY
Entity X → RELATES_TO → Entity Y → RELATES_TO → Entity Z
💡 이게 왜 강력한가? 벡터 검색으로 Chunk 2를 찾았다고 하자. 거기서 끝나는 게 아니라:
- Chunk 2가 속한 Document 전체 맥락 파악 가능
- Chunk 2에 언급된 Entity X가 다른 청크에도 등장하는지 추적 가능
- Entity X → Entity Y 관계를 통해 다른 도메인 지식으로 확장 가능
6. 지식그래프 설계 3가지 팁
팁 1 — 어떤 질문이 나올지 생각하기
GraphRAG를 통해 해결할 질문(시나리오)의 조건/맥락으로 사용될 그래프 구조를 설계
- 질문에 답하기 위한 구조를 설계하는 관점으로 접근
- 주어로 질문할 수 있나? → 노드
- 질문의 조건으로 작용하나? → 관계 / 속성
예시: “이 작업은 어떤 부서에서 담당하고, 관련 문서는 뭐야?”
(Task)-[ASSIGNED_TO]->(Department)-[DOCUMENTED_IN]->(Document)💡 실전 접근 방법 그래프를 먼저 설계하지 말고, 먼저 질문 목록을 만들어라. 예상 질문이 10개 있다면, 각 질문에 필요한 노드와 관계가 무엇인지를 역산해서 스키마를 도출한다. 이렇게 하면 불필요한 노드를 만들지 않고, 실제로 쓸 그래프를 설계할 수 있다.
설계 체크리스트
- “이 정보가 노드여야 할까, 속성이어야 할까?” → 다른 것과 독립적으로 연결되어야 한다면 노드, 단순히 설명하는 값이라면 속성
- “이 관계를 나중에 조건으로 검색할 것인가?” → 검색 조건이 된다면 반드시 관계로 명시
팁 2 — 텍스트는 고립시키지 말기
텍스트 청크는 따로 저장하는 것이 아니라, 연결된 개념 혹은 계층적 구조를 함께 저장
| 나쁜 예 ❌ | 좋은 예 ✅ | |
|---|---|---|
| 저장 방식 | Text Chunk만 단독으로 저장 | Text Chunk → Section → Document 계층으로 연결 |
| 검색 후 | 해당 청크 텍스트만 반환 | 청크 + 상위 섹션 + 원본 문서 + 관련 엔티티 함께 조회 |
| 맥락 파악 | ❌ 청크만 보여줌 | ✅ 문서 전체 흐름 속 위치를 파악할 수 있음 |
- 텍스트 청크 = 검색을 위한 진입 노드 (입구일 뿐, 목적지가 아님)
- 벡터 검색으로 진입한 후 그래프를 따라 확장해서 풍부한 컨텍스트를 수집해야 함
💡 비유: 책의 색인 vs 책 구조 전체 Vector RAG는 색인(Index)에서 단어를 찾아 페이지 번호만 알려주는 것. Graph RAG는 그 페이지가 어느 챕터에 있고, 앞뒤 맥락이 뭔지, 관련 개념이 어디 나오는지까지 알려주는 것.
팁 3 — LLM이 읽을 수 있게 하기
LLM이 검색과 생성에 활용할 수 있도록 관계 혹은 속성에 직관적인 이름을 사용
| 나쁜 예 ❌ | 좋은 예 ✅ | |
|---|---|---|
| 관계 이름 | RELATED_TO | BELONGS_TO, EXPLAINS, PART_OF |
| LLM 입장 | ”이 관계가 뭘 뜻하는 거지?” (모호) | “아, 이 청크는 개념을 설명하고, 이 개념은 단원에 속하는구나” (명확) |
💡 왜 LLM이 관계명을 “읽는가”? GraphRAG에서 그래프를 검색한 결과는 결국 LLM의 프롬프트에 텍스트로 삽입된다. 예:
- Chunk_42 EXPLAINS Concept_ReAct
- Concept_ReAct BELONGS_TO Chapter_3
LLM은 이 텍스트를 읽고 “Chunk_42는 ReAct 개념을 설명하는 청크이고, ReAct는 3장에 속한다”고 이해한다. 관계명이 RELATED_TO처럼 모호하면 LLM도 맥락을 파악하기 어렵다.
안티패턴
RELATED_TO,CONNECTED_TO,LINKED_TO같은 범용 관계명은 사용하지 말 것. 관계마다 고유한 의미를 담은 이름을 붙여야 그래프가 진짜 지식을 담게 된다.
Ch3. Neo4j LLM Graph Builder 맛보기
Neo4j LLM Graph Builder
코드 없이 문서를 업로드하면 LLM이 자동으로 지식그래프를 생성해주는 도구
💡 이 도구가 하는 일 PDF나 유튜브 자막 같은 비정형 텍스트를 입력하면, LLM이 내용을 분석해서 자동으로:
- 핵심 엔티티 추출 (사람, 개념, 장소 등)
- 엔티티 간 관계 추출
- 문서 → 청크 → 엔티티의 계층 구조 생성
- Neo4j 그래프 DB에 저장
3 Simple Steps:
① Connect to Neo4j
↓ (Neo4j 데이터베이스 연결)
② Upload Files
↓ (pdf, YouTube, cloud storage, Wikipedia 등 다양한 소스 지원)
③ Generate Graph
↓ (LLM이 자동으로 엔티티·관계 추출 → 그래프 생성)
→ 결과: Document + Entities + Chunks 노드와 관계로 구성된 그래프
- URL: https://neo4j.com/labs/genai-ecosystem/llm-graph-builder/
- 실습에 사용한 영상 링크: https://youtu.be/LP5OCa20Zpg
실습 활용법
직접 코드를 짜기 전에 이 도구로 먼저 그래프를 자동 생성해보면, 내 데이터가 어떤 구조의 그래프로 만들어지는지 감을 잡을 수 있다. 이후 스키마를 직접 설계할 때 참고 기준이 된다.
핵심 요약
지식그래프
├── 구성: 엔티티(노드) + 관계(엣지)
├── 표현 방식
│ ├── RDF: 트리플(주어-술어-목적어)
│ │ → 온톨로지, 시맨틱 웹, AI 추론에 적합
│ │ → 엄격하고 표준화됐지만 복잡
│ └── LPG: 노드+관계+속성
│ → GraphRAG, 실시간 질의, Neo4j에 적합
│ → 직관적이고 빠른 탐색
│
└── GraphRAG에서의 역할
├── Lexical Graph: 문서 → 청크 계층 구조 (텍스트 탐색)
├── Domain Graph: 도메인 지식 구조화 (개념 탐색)
└── 설계 3원칙
├── 질문 시나리오 기반으로 역산 설계
├── 청크를 고립시키지 말고 문서/섹션과 연결
└── LLM이 이해할 수 있는 명확한 관계명 사용
전체 흐름 한 줄 요약
지식그래프(LPG) 로 도메인과 문서를 구조화 → GraphRAG 시스템의 검색 엔진 역할 → LLM 이 풍부한 컨텍스트로 정확한 답변 생성
관련 노트
- 2026-04-14-graphrag-txt2kg — Ch02 실습: 텍스트를 지식그래프로 변환하기
- 2026-04-14-knowledge-graph-lpg-vs-rdf — LPG vs RDF 데이터 모델 비교
- moc-learning-progress — 학습 진도 추적