Graph 기반 LLM(RAG, Agent)을 위한 RDF / LPG / JSON 비교 분석

최근 GraphRAG가 AI 지식 추출의 핵심 기술로 부상하면서, 지식을 어떤 형태로 저장하고 관리해야 하는지에 대한 전략적 선택이 중요해졌다. 내가 공부했던 분야는 RDF 기반의 트리플 구조의 지식그래프와 온톨로지였지만, 최근의 LLM에서 사용되는 그래프는 다양한 구현체이다. RDF, LPG, JSON(-LD)와 같은 구현에 따라 논문이나 시스템의 이해도가 달라질 수 있어 이번 기회에 정리해보았다.

1. GraphRAG가 요구하는 그래프의 본질

GraphRAG 논문과 Microsoft GraphRAG, NebulaGraph GraphRAG 등의 실제 구현체를 살펴보면 공통적으로 강조하는 지점이 있다. 그것은 그래프가 반드시 엔티티(Node)와 관계(Edge) 구조를 가져야 한다는 것이다.

• 구조적 추론: 무엇(노드)과 무엇(노드)이 어떤 관계(엣지)로 연결되어 있는지 추론 가능한 형태로 존재해야 한다.
• 포맷의 비종속성: 데이터 저장 포맷은 목적을 달성하기 위한 방법일 뿐이다. GraphRAG의 진정한 목적은 LLM이 관계 기반의 추론(Reasoning)을 수행할 수 있도록 구조화된 컨텍스트를 제공하는 것이다.

Note: 실무에서는 흔히 "그래프 DB가 없으면 GraphRAG를 못 하는 것 아니냐"는 오해가 있다. 하지만 본질을 이해한다면, 텍스트 청크 간의 연결 고리를 논리적으로 증명할 수 있는 리스트만 있어도 그래프의 역할을 충분히 수행할 수 있다는 점을 깨닫게 된다.

---

2. 실제 구현에서 사용되는 그래프 형태 비교

현재 연구 및 산업 현장에서 활용되는 주요 그래프 타입의 특징은 다음과 같다.

그래프 타입	구성 요소	활용 및 특징
RDF (Resource Description Framework)	Subject–Predicate–Object (삼중 구조)	삼중 구조는 논리적 추론에 강점이 있다.
LPG (Labeled Property Graph)	노드/엣지에 속성(Property) 포함 가능	대부분의 상용 구현체가 채택하는 형태다.
JSON 기반 그래프	JSON으로 노드와 엣지 표현	구현이 매우 쉽고 유연하다.
LPG DB (Neo4j, TigerGraph 등)	산업용 그래프 데이터베이스	대규모 데이터를 다루는 기업용 GraphRAG 시스템에서 주로 선호된다.
Adjacency List (파이썬 Dict 등)	노드 간 인접 리스트	연구용 논문이나 가벼운 프로토타입에서 종종 사용되는 형태다.

Note: 데이터의 복잡도에 따라 선택지는 달라지겠지만, 결국 LLM에게 전달되는 최종 형태는 자연어와 유사한 구조적 텍스트다. 따라서 특정 DB 엔진의 성능보다 '얼마나 정확한 관계(Relation)를 추출했는가'가 성능을 좌우한다.

RDF vs LPG vs JSON

실제 구현체(Microsoft GraphRAG, Neo4j, LlamaIndex 등)에서 사용되는 세 가지 형식을 실무 관점에서 비교 분석한다.

구조	삼중(triple) 기반	노드·엣지·속성 자유도 ↑	구조는 자유 형식
표현력	관계 중심. 속성 모델링 제약	속성 표현 강력	완전 자유(스키마 없음)
그래프DB	Blazegraph, GraphDB, Stardog	Neo4j, NebulaGraph, JanusGraph	없음(JSON 파일 자체)
쿼리 언어	SPARQL	Cypher, GQL, Gremlin	없음(직접 탐색)
LLM 입력 용이성	triple → 자연어 변환 필요	텍스트화 쉽고 유연	JSON → 자연어 변환 필요
구축 난이도	높음 (스키마 강함)	중간 (직관적)	매우 쉬움
대규모 처리	우수 (표준화)	최고 (산업에서 검증)	대규모는 어려움
GraphRAG 적합성	★★★☆☆	★★★★★	★★★★☆
실제 GraphRAG 사례	학술/정부/의료 등 RDF 기반 데이터 활용	NebulaGraph, Neo4j 기반 GraphRAG 대부분	Microsoft GraphRAG 기본 저장 구조

 

1. RDF (Resource Description Framework)

✔ 장점

1) 구조가 엄격해 대규모·다중 출처 데이터를 병합하기 좋음

• 스키마(ontology) 기반 → 데이터 일관성 보장
• 상호운용성 높음 (Wikidata, DBpedia 등 외부 RDF 연결 용이)

2) 관계 중심 추론에 매우 강함

• Triple 기반 → “주어-관계-객체” 구조가 명확
• 복잡한 관계 표현에 뛰어남
  (GraphRAG의 multi-hop reasoning 과제에 적합)

3) SPARQL을 통한 정교한 질의

• triple 패턴 매칭, 경로 질의 등 고급 쿼리 지원

✔ 단점

1) 노드/엣지 속성 표현이 불편

• property graph처럼 자연스럽게 “노드에 여러 속성”을 붙이기 어려움
• 결국 reification 등 복잡한 패턴 필요

2) GraphRAG에서 LLM 입력으로 쓰기에 변환 과정이 번거로움

• LLM은 자연어 이해 → RDF triple은 해석 필요
• "RDF → 자연어 template or prompt→ LLM" 단계가 필요

3) 구축 난이도가 가장 높음

• 온톨로지 설계 필요
• GraphRAG 실무팀에서는 무겁다고 느끼는 경우多

---

2. LPG (Property Graph: Neo4j, NebulaGraph)

✔ 장점

1) GraphRAG에 가장 적합한 구조

• 대다수 산업용 GraphRAG가 LPG 기반
  (Neo4j GraphRAG, NebulaGraph GraphRAG 등)

2) 노드/엣지에 속성을 자유롭게 부여 가능

(node)-[edge {score: 0.85, timestamp: "2024"}]->(node)

→ RAG의 텍스트 chunk, 요약, 토픽, score 등을 쉽게 포함 가능

 

3) Cypher/GQL 등 인간 친화적 쿼리

• 직관적: MATCH (a)-[:friend]->(b)
• LLM에게 쿼리 생성 시키기에도 쉬움

4) 대규모 그래프 처리에 최적화

• 실제 여러 GraphRAG 벤더가 LPG 기반 선택

✔ 단점

1) 표준화 부족

• RDF처럼 웹 표준(global interoperability) 부족

2) 다른 그래프DB 간 호환성 떨어짐

• Neo4j ↔ NebulaGraph ↔ JanusGraph 간 마이그레이션 난이도 있음

---

3. JSON 기반 그래프 (Microsoft GraphRAG 기본)

✔ 장점

1) 구축 쉬움 — JSON 배열 만들면 끝

{
  "nodes": [
    { "id": "n1", "name": "Alice", "type": "Person" }
  ],
  "edges": [
    { "source": "n1", "target": "n2", "relation": "works_at" }
  ]
}

 

2) LLM 입력에 가장 자연스럽게 변환됨

GraphRAG의 "edge table"이나 "natural language summary" 만들기 편함

 

3) GraphDB 없이도 GraphRAG 구현 가능

• 파일 기반으로 community detection, PageRank 등 수행 → Microsoft GraphRAG 방식

4) 소규모 프로젝트에 최적

• 비용 적음
• 관리 용이

✔ 단점

1) 대규모 그래프 처리에 부적합

• JSON 파일이 커지면 탐색이 느려짐
• 온라인 서비스에는 부적합 (그래프DB 필요)

2) 표준 쿼리 언어 없음

• 직접 파이썬/JS로 탐색 로직 구현해야 함

3) 구조적 제약이 없어 데이터 품질 관리 어려움

 

---

LPG에서 스키마란?

개인적으로 궁금했던 부분은 "LPG에는 왜 .owl 같은 표준 스키마 파일이 없는가?"이다. 이는 두 시스템의 철학적 차이에서 기인한다. RDF는 'Schema-First' 방식을 택하여 스키마가 데이터를 정의하는 반면, LPG는 'Schema-Optional' 혹은 'Schema-Less' 방식을 취한다.

1. DB 내부의 제약 조건(Constraints)으로 관리

별도의 파일을 로딩하는 것이 아니라, 데이터베이스(예: Neo4j) 내부에 DDL(Data Definition Language) 명령어를 통해 제약 조건을 걸어 스키마처럼 작동하게 할 수 있다.

• 방식: "모든 User 노드는 반드시 email 속성을 가져야 하며, 이는 유일(Unique)해야 한다"와 같은 규칙을 DB에 직접 선언gks다.
• 파일 형태: 이 제약 조건들을 모아둔 .cypher 스크립트 파일이나 마이그레이션 스크립트(Python, Java 등)가 사실상의 스키마 파일 역할을 한다.
• 예시 (Cypher):

  CREATE CONSTRAINT FOR (p:Person) REQUIRE p.name IS UNIQUE;
  CREATE CONSTRAINT FOR (p:Person) REQUIRE p.age IS NOT NULL;
  

2. 메타데이터 그래프(Meta-Graph) 또는 온톨로지 레이어 구축

LPG에는 표준 스키마 파일이 없으므로, '데이터를 설명하는 데이터(메타데이터)'를 그래프의 일부로 저장하거나 별도의 레이어로 관리할 수 있다.

• 팔란티어(Palantir) 방식: 팔란티어는 '온톨로지 매니저(Ontology Manager)'라는 도구를 통해 객체(Object Types)와 링크(Link Types)를 정의한다. 이 정의는 시스템 내부의 독자적인 메타데이터 저장소에 관리되며, 사용자는 UI를 통해 이를 정의한다.
• 자체 메타 노드 생성: 그래프 내에 별도의 Class, Property라는 라벨을 가진 노드를 따로 만들어, 실제 데이터 노드들이 이 메타 노드를 참조하게 하는 방식으로 RDF의 온톨로지 구조를 LPG 안에서 유사하게 구현할 수 있다

3. 애플리케이션 레벨의 코드/설정 파일 (JSON/YAML)

LPG를 사용하는 애플리케이션(예: GraphRAG) 단에서 스키마를 정의하고, 데이터를 넣기 전에 검증(Validation)하는 방식이다.

• JSON/YAML: GraphRAG와 같은 시스템은 entity_types나 relation_types를 정의한 JSON이나 YAML 파일을 스키마로 활용할 수 있다. 이는 DB가 강제하는 것이 아니라, 데이터를 생성하는 파이프라인이 참조하는 '가이드라인'으로 작용한다.
• GraphQL: 최근에는 Neo4j 등에서 GraphQL Schema (.graphql) 파일을 사용하여 그래프의 타입과 관계를 정의하고, 이를 기반으로 API를 자동 생성하는 방식을 사용할 수 있다. 

4. GQL (Graph Query Language) 표준화 흐름

현재 ISO 표준으로 제정 중인 GQL은 LPG에서도 RDF처럼 명시적인 스키마 정의(Graph Type Definition)를 표준화하려고 시도하고 있다. 향후에는 LPG도 표준화된 스키마 파일을 갖게 될 가능성이 있다.

요약: RDF vs LPG 스키마 관리 방식 비교

특징	RDF (Semantic Web)	LPG (Neo4j, Palantir 등)
스키마 파일	.owl, .rdf, .ttl (필수 및 표준화됨)	없음 (필요시 .cypher, .graphql, .json 등으로 관리)
성격	Prescriptive (규범적): 스키마가 데이터를 정의함	Descriptive (서술적): 데이터가 곧 스키마가 됨 (Schema-free)
관리 위치	파일 자체 (Import 방식)	DB 내부 제약조건(Constraints) 또는 애플리케이션 코드
강제성	추론(Reasoning)을 통해 논리적 모순 발견	애플리케이션 로직이나 DB 제약조건으로 입력 차단

 

결론: 프로젝트 성격에 따른 선택 전략

GraphRAG에서 그래프란 특정 포맷이 아닌 '구조' 그 자체다. RDF는 표준화와 논리적 추론에 강점이 있고, LPG는 실무적인 모델링과 성능에 강점이 있으며, JSON은 실제 구현의 편의성이 높다.

GraphRAG 시스템 구축 시, 포맷은 도구일 뿐 핵심은 '관계의 질'에 있다.

• 빠른 프로토타이핑: 구축 비용이 적은 JSON 기반 그래프를 추천
• 고성능 온라인 서비스: 대규모 데이터 처리와 Cypher 쿼리의 이점을 살릴 수 있는 LPG(Neo4j 등)가 사실상 표준이다.
• 지식 융합 및 표준 지식 베이스: 외부 온톨로지와의 결합 또는 복잡한 도메인의 규칙이 중요하다면 RDF가 유리하다.

결론적으로 GraphRAG는 특정 형식을 요구하지 않으며, 관계 기반의 구조적 정보를 요구한다. 개발자는 자신의 도메인 규모와 요구되는 추론의 깊이에 따라 적절한 관리 방식을 선택해야 한다.