지식 그래프란 무엇인가: 왜 그래프인가 — 관계형·벡터 DB와의 비교

같은 데이터를 세 렌즈로 — 관계형은 조인으로 관계를 계산하고, 벡터는 의미 유사도로 비슷한 조각을 찾고, 지식 그래프는 연결 그 자체를 데이터로 저장해 여러 홉을 따라간다. 셋은 상보적이며, 질문의 성질이 어느 렌즈가 빛날지를 정한다.

들어가며

이 글은 Agentic Knowledge Graph Curriculum의 1단계입니다. 시리즈의 종착점은 “그래프를 도구·기억으로 쓰는 에이전트”지만, 그 여정의 첫걸음은 아주 단순한 질문에서 시작합니다 — “왜 하필 그래프인가?”

우리에겐 이미 관계형 DB가 있고, 요즘 RAG의 주력인 벡터 DB도 있습니다. 그런데도 사기 탐지, 추천, 지식 Q&A, 에이전트 기억 같은 문제에서 사람들이 자꾸 지식 그래프(Knowledge Graph)로 돌아오는 이유가 있습니다. 이 글은 그 이유를 세 렌즈를 나란히 놓고 밝힙니다. 이 “왜”를 손에 쥐지 못한 채 GraphRAG나 에이전트부터 손대면, 그저 유행하는 블랙박스를 돌리는 일이 됩니다.

지식 그래프는 세상을 노드(개체)와 관계(엣지)로 표현한 사실의 망입니다. “일론 머스크 — (창업) → 테슬라 — (출시) → Model 3”처럼 사실을 삼각형(트리플)으로 이어 붙여 거대한 지식 망을 만듭니다. 이 발상의 형식적 뿌리 — RDF의 트리플, 시맨틱 웹의 계보 — 는 자매 시리즈인 Ontology Essential의 형식 기반 편에서 이미 깊게 다뤘으므로, 이 글은 그 어휘를 빌려 쓰되 “왜 그래프이며, 언제 그래프를 골라야 하는가”라는 실용적 질문에 집중합니다.

📌 이 글에서 다루는 내용

왜 그래프인가: 노드·엣지·트리플이라는 최소 구조, “관계를 조인으로 계산”하는 관계형과 달리 “관계를 데이터로 저장”한다는 것의 의미, 그리고 다중 홉(multi-hop) 질의에서 그래프가 빛나는 이유
vs 관계형 · vs 벡터 DB: 조인 폭발(join explosion)로 본 관계형의 한계, 의미 유사도만으로는 놓치는 벡터 RAG의 빈틈, 세 저장소가 각자 잘하는 질문과 왜 상보적인가
활용의 큰 그림: Google Knowledge Graph, 추천, 사기 탐지, 에이전트 기억까지 — “연결이 답인 문제”라는 공통 성질, 그리고 이 시리즈가 이후 어디로 향하는가

한눈에 보기 — 질문이 렌즈를 고른다

이 글의 스파인을 한 장으로 그리면 이렇습니다. 어떤 저장소도 만능이 아닙니다 — 질문의 성질이 어느 렌즈가 빛날지를 정합니다. 정형 집계는 관계형이, 의미 검색은 벡터가, 그리고 연결을 따라가야 답이 나오는 질문은 그래프가 답합니다.

flowchart TD
    Q["던지고 싶은 질문"]

    Q --> A{"무엇을 묻는가?"}

    A -->|"정형 집계 · 트랜잭션<br/>이 고객의 총 주문액은?"| REL["관계형 DB<br/>테이블 · 조인 · SQL"]
    A -->|"의미 유사도<br/>이 문장과 비슷한 문단은?"| VEC["벡터 DB<br/>임베딩 · top-k 검색"]
    A -->|"연결 · 경로 · 다중 홉<br/>3다리 건너 연결된 계좌는?"| GRAPH["지식 그래프<br/>노드 · 관계 · 탐색"]

    GRAPH --> WIN["연결이 답인 문제에서<br/>압도적 · 설명가능"]

    REL -.->|"홉이 깊어지면 조인 폭발"| GRAPH
    VEC -.->|"흩어진 사실 연결엔 약함"| GRAPH

이 그림에서 쥐어야 할 좌표는 하나입니다 — 셋은 경쟁 관계가 아니라 상보적이며, 실전의 답은 대개 이들을 함께 쓰는 하이브리드입니다. 다만 이 시리즈는 지금까지 덜 익숙했을 그래프 렌즈를 집중해서 벼립니다.

왜 그래프인가 — 관계를 계산하지 말고 저장하라

노드 · 엣지 · 트리플

지식 그래프의 구조는 놀랄 만큼 단순합니다. 세 가지뿐입니다.

노드(node): 세상의 개체 하나 — 사람, 회사, 제품, 사건, 유전자.
엣지(edge): 두 노드를 잇는 방향 있는 관계 — 근무한다, 출시했다, 상호작용한다.
속성(property): 노드나 엣지에 붙는 값 — 사람의 이름, 근무 관계의 시작일.

이 셋으로 “김지수가 누리테크에서 근무하고, 누리테크가 미리내를 출시했다”는 사실을 그립니다.

(김지수:사람) ─[근무]→ (누리테크:회사) ─[출시]→ (미리내:제품)

각 화살표가 하나의 트리플(주어–술어–목적어)입니다. 트리플을 계속 쌓으면 주어·목적어가 노드가 되고 술어가 엣지가 되어 자연스럽게 하나의 그래프로 자랍니다. “지식 그래프”라는 말의 실체가 바로 이것입니다 — 개별 사실의 집합이 이루는 거대한 연결망.

핵심 전환: 관계를 데이터로 저장한다

여기서 관계형 DB와의 결정적 차이가 드러납니다. 관계형 세계에서 “김지수가 어디서 근무하는가”는 employees 테이블과 companies 테이블을 외래키로 조인해 그때그때 계산합니다. 관계는 데이터가 아니라 질의 시점의 연산입니다.

그래프는 정반대입니다 — 관계 그 자체를 물리적으로 저장합니다. 근무 엣지는 두 노드 사이에 실제로 존재하는 포인터이고, 이웃으로 건너가는 데 조인이 필요 없습니다(이를 index-free adjacency라 부릅니다). 그래서 “김지수의 동료의 동료가 관여한 프로젝트”처럼 관계를 여러 번 따라가는 다중 홉(multi-hop) 질의에서, 그래프는 관계형이 감당하기 힘든 성능과 표현력을 냅니다.

이 한 문장이 이 시리즈 전체의 씨앗입니다 — “관계를 계산하지 말고 저장하라.” 다음 두 절은 이 전환이 관계형·벡터 각각에 대해 무엇을 바꾸는지 구체적으로 봅니다.

vs 관계형 DB — 조인 폭발이라는 벽

관계형 DB는 정형 데이터의 집계·트랜잭션에서는 왕입니다. “이 고객의 이번 달 총 주문액”은 관계형이 그래프보다 낫습니다. 문제는 관계를 여러 번 따라가는 질문입니다.

“김지수와 3다리 건너 같은 계좌로 연결된 사람들을 찾아라” 같은 질문을 SQL로 쓰면, 홉 하나마다 자기 자신과의 조인(self-join)이 붙습니다.

-- 3-홉 연결 탐색: 홉마다 조인이 하나씩 — 홉이 늘면 기하급수로 비싸진다
SELECT DISTINCT p3.name
FROM   people p0
JOIN   transfers t1 ON t1.from_id = p0.id
JOIN   people p1     ON p1.id = t1.to_id
JOIN   transfers t2 ON t2.from_id = p1.id
JOIN   people p2     ON p2.id = t2.to_id
JOIN   transfers t3 ON t3.from_id = p2.id
JOIN   people p3     ON p3.id = t3.to_id
WHERE  p0.name = '김지수' AND p3.id <> p0.id;

홉이 하나 늘 때마다 조인 테이블이 하나씩 붙고, 중간 결과가 폭발합니다 — 이것이 조인 폭발(join explosion)입니다. 홉 수가 미리 정해져 있지 않은 질문(“연결이 끊길 때까지 따라가라”)은 아예 SQL로 표현하기 어렵습니다.

같은 질문을 그래프 질의어(Cypher, 2단계에서 다룹니다)로 쓰면 이렇게 짧아집니다.

// 가변 길이 경로 *1..3 — 홉 수를 데이터가 정하게 둔다
MATCH (me:Person {name: '김지수'})-[:TRANSFER*1..3]->(other:Person)
WHERE other <> me
RETURN DISTINCT other.name;

*1..3이 “1~3홉을 따라가라”를 그대로 표현합니다. 관계가 데이터로 저장돼 있으니 이웃으로 건너가는 비용이 조인 연산이 아니라 포인터 추적이고, 깊은 탐색에서도 성능이 완만하게 유지됩니다. 금융 사기 탐지(자금세탁 고리 찾기), 추천(구매 이력이 겹치는 사용자), 소셜 네트워크(친구의 친구)가 모두 이 다중 홉 패턴 위에 있습니다.

조인 폭발 vs 포인터 홉 — 관계형은 홉이 깊어질수록 self-join이 하나씩 붙어 중간 결과가 ×N → ×N² → ×N³으로 폭발한다. 그래프는 관계를 데이터로 저장하므로 이웃으로 건너가는 비용이 포인터 추적에 그쳐, 깊은 탐색에서도 완만하게 유지된다.

오해 방지 — 그래프가 관계형을 대체하는 것이 아닙니다. 원장·재무·재고 같은 정형 트랜잭션은 여전히 관계형이 정답입니다. 그래프는 관계 자체가 1급 질문이 되는 워크로드를 위한 것입니다.

vs 벡터 DB — 유사도가 놓치는 연결

요즘 RAG의 주력은 벡터 DB입니다. 문서를 임베딩(의미를 담은 벡터)으로 바꿔 저장하고, 질문과 의미가 가까운 조각(top-k)을 찾아 LLM에 넘깁니다. “환불 정책이 뭐야?”에 관련 문단을 찾아 주는 데 탁월합니다.

그런데 벡터 검색에는 구조적 빈틈이 있습니다.

다중 홉 질문에 약하다: “우리 회사에 투자한 VC가 투자한 다른 회사 중 우리 경쟁사는?” — 답이 한 문단에 있지 않고 여러 사실을 연결해야 나오는 질문은, 아무리 의미가 비슷한 조각을 모아도 그 연결을 스스로 잇지 못합니다.
전역(global) 질문에 약하다: “이 문서 코퍼스 전체를 관통하는 핵심 리스크는?” — top-k는 일부 조각만 볼 뿐, 전체 구조를 요약하지 못합니다.
설명가능성이 약하다: “왜 이 답이 나왔는가”가 벡터 거리로만 남습니다. 그래프는 답에 이른 경로(A→B→C)를 근거로 제시할 수 있습니다.

그래프는 이 빈틈을 정확히 메웁니다. 명시적으로 연결된 사실을 따라가고, 전체 구조를 클러스터로 요약하고(5단계 GraphRAG), 경로로 근거를 댑니다. 그래서 실전의 답은 대개 벡터 + 그래프의 하이브리드입니다 — 벡터로 관련 개체를 찾아 그래프에 진입하고, 그래프로 연결을 따라가 답을 완성합니다. 이 결합이 바로 5단계 GraphRAG의 핵심 발상입니다.

연결이 답인 질문 — 벡터 검색은 의미가 비슷한 조각을 top-k로 모으지만 그 조각들을 스스로 잇지 못한다. 그래프는 우리 회사 → VC → 경쟁사처럼 명시적 연결을 따라가 답을 완성하고, 지나온 경로가 곧 근거가 된다. 그래서 실전에선 벡터로 진입해 그래프로 잇는 하이브리드(GraphRAG)가 강력하다.

렌즈	저장하는 것	잘 답하는 질문	약한 지점
관계형 DB	행·열, 관계는 외래키	정형 집계·트랜잭션	깊은 다중 홉(조인 폭발)
벡터 DB	의미 임베딩	의미 유사 검색·벡터 RAG	연결·전역·설명가능성
지식 그래프	노드·관계(연결)	다중 홉·경로·전역·근거	순수 유사도·대량 정형 집계

활용의 큰 그림 — “연결이 답인 문제”

지식 그래프가 빛나는 문제들에는 공통점이 있습니다 — 답이 개별 데이터가 아니라 데이터 사이의 연결에 있다는 것. 대표 사례를 큰 그림으로 훑어봅니다(각 도메인은 8단계에서 아키텍처와 함께 집대성합니다).

웹 검색 (Google Knowledge Graph): 2012년 구글은 검색을 “문자열이 아니라 실체(things, not strings)”로 전환하며 이 용어를 대중화했습니다. “레오나르도 다빈치”를 검색하면 생몰년·작품·동시대 인물이 연결된 패널로 뜨는 것이 지식 그래프입니다.
금융 — 사기·자금세탁 탐지: 계좌·거래·소유 관계를 그래프로 놓으면, 정상 거래처럼 보이는 개별 이체 뒤에 숨은 순환 고리와 위장 계좌 네트워크가 드러납니다.
헬스케어·바이오 — 신약 발견: 약물–질환–유전자–논문을 잇는 그래프에서 “이 약물이 작용하는 경로에 걸린 다른 질환”을 추론해 약물 재창출(drug repurposing) 후보를 찾습니다.
추천·이커머스: 사용자–상품–속성 그래프에서 “나와 취향이 겹치는 사람이 산 것”, “이 상품과 함께 사는 것”을 경로로 찾고, 그 경로가 설명 가능한 추천 근거가 됩니다.
엔터프라이즈 지식·고객지원: 사내 문서·티켓·제품을 그래프로 엮어, 흩어진 문서를 연결해야 답이 나오는 질문에 근거 있는 답변을 냅니다(GraphRAG).
에이전트 기억: 대화·관찰에서 얻은 사실이 시간과 함께 쌓여 자라는 시간적 지식 그래프가, 장기 기억을 가진 어시스턴트의 토대가 됩니다(7단계).

이 사례들이 관계형이나 벡터가 아니라 그래프를 부르는 이유는 하나로 수렴합니다 — 연결을 따라가는 것이 문제의 본질이기 때문입니다.

정리

지식 그래프 = 노드·관계로 표현한 사실의 망입니다. 트리플을 쌓으면 하나의 거대한 연결망이 됩니다.
핵심 전환은 “관계를 계산하지 말고 저장하라”입니다. 관계형이 조인으로 관계를 매번 계산한다면, 그래프는 관계를 데이터로 저장해 다중 홉 탐색을 값싸게 만듭니다.
관계형·벡터·그래프는 상보적입니다. 정형 집계는 관계형, 의미 검색은 벡터, 연결이 답인 질문은 그래프 — 질문의 성질이 렌즈를 고릅니다.
그래프가 빛나는 문제의 공통 성질은 “연결이 답”이라는 것입니다. 사기 탐지·신약·추천·지식 Q&A·에이전트 기억이 모두 여기에 속합니다.

다음 글에서는 이 그래프를 실제로 저장하고 질의하는 손을 풉니다 — 속성 그래프의 Cypher와 RDF의 SPARQL, 그리고 어떤 그래프 DB를 언제 고를지를 다룹니다.

다음 학습 (Next Learning)

2단계 · 그래프 DB와 질의: Neo4j·Cypher / RDF·SPARQL — 방금 본 그래프를 실제로 저장하고 물어보기
지식 그래프와 RDF/OWL·속성 그래프 (Ontology 시리즈) — 트리플·시맨틱 웹의 형식적 계보를 더 깊게
Agentic Knowledge Graph Curriculum — 전체 8단계 로드맵으로 돌아가기