PART 0 · 개념 기초

데이터를 '저장'하는 것과
'이해'하는 것의 차이

지식 그래프가 왜 필요한지 이해하려면, 먼저 기존 데이터베이스가 무엇을 못 하는지 알아야 합니다.

1. 도서관 비유로 시작하기

두 개의 도서관이 있다고 상상해봐요.

첫 번째 도서관 — 전통적인 RDB

책이 정해진 자리에 꼼꼼히 정리되어 있어요. "3번 선반, 12번째 책"이라고 하면 바로 꺼내줍니다.
하지만 사서에게 "지구 온난화와 관련된 경제적 영향에 대해 알고 싶어"라고 하면,
어떤 책들이 서로 어떤 관계인지 모르기 때문에 도움을 주기 어렵습니다.

두 번째 도서관 — 지식 그래프

사서가 책의 내용을 이해하고, 책들 사이의 관계를 알고 있어요.
"지구 온난화 → 해수면 상승 → 해안 도시 침수 → 부동산 가치 하락 → 경제적 손실"
이렇게 개념들이 연결된 지식망을 갖고 있기 때문에, 복잡한 질문도 맥락 있게 답변할 수 있습니다.

2. 같은 데이터, 다른 관점

아래 세 가지 사실이 있다고 가정해봐요.

원시 데이터 (Raw Data)

① 홍길동은 서울에 산다.
② 홍길동은 카카오에 다닌다.
③ 카카오 본사는 판교에 있다.

RDB의 시각 — "사실의 저장"

세 개의 테이블(사람, 회사, 도시)에 각각 행(row)으로 저장합니다.
"홍길동이 출퇴근을 하는가?"라는 질문에 답하려면,
세 테이블을 JOIN 해서 서울 ≠ 판교임을 직접 계산해야 합니다.
관계는 있지만, 의미는 없습니다.

지식 그래프의 시각 — "관계의 이해"

홍길동 —[거주]→ 서울
홍길동 —[근무]→ 카카오
카카오 —[위치]→ 판교

이 구조에서는 "홍길동의 거주지와 직장 소재지가 다르다"는 사실을
관계를 따라가는 것만으로 자연스럽게 파악할 수 있습니다.
RDB처럼 여러 테이블을 JOIN할 필요 없이, 관계 자체가 곧 탐색 경로가 됩니다.
데이터 자체가 의미를 품고 있습니다.

3. RDB vs 지식 그래프 — 핵심 비교
구분 RDB (관계형 데이터베이스) 지식 그래프 / 온톨로지
핵심 질문 "이 데이터가 있는가?" "이 데이터는 무엇을 의미하는가?"
데이터 구조 테이블 · 행 · 열 (고정 스키마) 노드 · 관계 · 속성 (유연한 구조)
관계 표현 외래키(FK) + JOIN으로 연결 관계 자체가 1등 시민 (직접 표현)
추론 능력 없음 (명시된 것만 조회) Property Graph: 관계 탐색으로 패턴 발견
온톨로지(OWL): 추론기로 자동 도출 가능
스키마 변경 어려움 (ALTER TABLE 필요) 쉬움 (새 노드/엣지 추가만)
질의 언어 SQL Cypher (Neo4j) / SPARQL (온톨로지)
잘 맞는 상황 정형 데이터, 대량 트랜잭션, 정확한 조회 복잡한 관계망, 추론, 맥락 이해, 검색
데이터베이스 질의 언어 설명
MySQL, PostgreSQL (RDB) SQL 테이블 기반 조회 언어. 가장 널리 쓰임
Neo4j (그래프 DB) Cypher 노드와 관계를 직관적으로 표현. 우리가 실습에서 주로 사용
OWL/RDF (온톨로지) SPARQL W3C 표준. 학술·연구 분야에서 주로 사용
4. 그래서 지식 그래프가 LLM에 왜 필요한가?

LLM(GPT, Claude 등)은 언어를 유창하게 생성하지만, 두 가지 근본적인 약점이 있어요.

① 환각(Hallucination) — 없는 사실을 그럴듯하게 만들어냄

LLM은 "확률적으로 그럴듯한 다음 단어"를 생성합니다.
사실 여부를 검증하는 메커니즘이 없기 때문에, 잘못된 정보를 자신 있게 말할 수 있어요.

② 최신 정보 부재 — 학습 데이터 이후의 세계를 모름

LLM의 지식은 학습 시점(cutoff)에서 멈춥니다.
어제 일어난 일, 사내 문서, 실시간 데이터는 알 수 없어요.

지식 그래프는 LLM의 "사실 확인 장치"이자 "장기 기억"입니다.
구조화된 지식 그래프를 LLM에 연결하면, LLM은 그래프에서 검증된 사실을 꺼내 답변을 생성합니다.
이것이 바로 GraphRAG의 핵심 아이디어입니다.

5. 핵심 정리

다음 페이지에서는 RDB · GraphDB · 온톨로지, 세 가지 세계관을 비교하며
각각이 데이터를 바라보는 관점이 어떻게 다른지 살펴봅니다.