Orc Hwang's Wiki

개발 학습 기록과 기술 지식을 체계적으로 관리하는 개인 위키입니다.

그래프 DB와 질의: 속성 그래프·Cypher와 RDF·SPARQL, 무엇을 언제

knowledge-graph graph-database cypher sparql
📖 시리즈: Agentic-Knowledge-Graph (3 / 9)
← 이전: 지식 그래프란 무엇인가: 왜 그래프인가 — 관계형·벡터 DB와의 비교 다음: 지식 그래프 구축 기초: 엔티티·관계 추출, 스키마 설계, 엔티티 해소 →
그래프를 저장·질의하는 두 계열 — 속성 그래프(Cypher)와 RDF 트리플(SPARQL) 같은 사실, 두 가지 저장·질의 속성 그래프 (Neo4j) 노드·엣지에 라벨과 속성을 내장 :PLACED :CONTAINS :고객 김지수 :주문 O-1001 :제품 노트북 MATCH (c:고객)-[:PLACED]->(o:주문) → 질의가 화살표 그림을 닮는다 무엇을 언제? RDF 트리플 (SPARQL) 모든 사실을 주어·술어·목적어로 c:C-042 ex:placed o:O-1001 . o:O-1001 ex:contains p:P-77 . c:C-042 ex:name "김지수" . p:P-77 ex:name "노트북" . 모든 것이 URI로 전역 식별 · 스키마도 데이터 ?c ex:placed ?o . ?o ex:contains ?p → 트리플 패턴을 매칭
같은 사실을 두 계열로 — 속성 그래프는 라벨·속성을 노드/엣지에 내장하고 Cypher의 화살표 문법으로 묻고, RDF는 모든 것을 URI 트리플로 쪼개 SPARQL 패턴으로 묻는다. 실무의 질문은 결국 "무엇을 언제 고르는가".

들어가며

이 글은 Agentic Knowledge Graph Curriculum의 2단계입니다. 1단계에서 “왜 그래프인가” — 관계를 계산하지 말고 저장하라 — 를 세웠으니, 이제 그 그래프를 실제로 저장하고 물어보는 손을 풉니다.

그래프를 다루는 방식은 크게 두 계열로 갈립니다. 하나는 실무 그래프 DB의 주류인 속성 그래프(property graph)와 그 질의어 Cypher, 다른 하나는 시맨틱 웹 계보의 RDF와 질의어 SPARQL입니다. 이 둘의 형식적·이론적 뿌리(트리플, OWL, 기술논리, 추론)는 자매 시리즈 Ontology 형식 기반 편에서 깊게 다뤘습니다. 이 글은 그 이론을 반복하지 않고, “어떻게 저장하고 질의하며, 어떤 것을 언제 고르는가”라는 실용 관점에 집중합니다.

📌 이 글에서 다루는 내용

  • 속성 그래프와 Cypher: 노드·엣지·속성의 구조, MATCH의 화살표 패턴 매칭, 그래프의 진짜 힘인 가변 길이 경로(variable-length path)와 무결성 제약
  • RDF와 SPARQL: 트리플 저장소, 기본 그래프 패턴(BGP) 질의, URI 전역 식별의 장단점, 속성 그래프와의 모델 차이
  • 무엇을 언제: property graph vs RDF 선택 기준(운영·탐색 중심 vs 표준·추론·연합), ISO 표준 GQL의 등장, 대표 그래프 DB 지형도

한눈에 보기 — 두 계열, 하나의 그래프

두 계열은 “세계를 그래프로 저장한다”는 같은 목적을, 서로 다른 우선순위로 구현합니다. 속성 그래프는 저장·탐색의 실용성을, RDF는 표준·의미론·추론을 앞세웁니다.

flowchart TD
    G["지식 그래프를 저장·질의하고 싶다"]

    G --> PG["속성 그래프 계열<br/>노드·엣지에 속성 내장"]
    G --> RDF["RDF 트리플 계열<br/>모든 것을 URI 트리플로"]

    PG --> CY["Cypher / GQL<br/>화살표 패턴·경로 탐색"]
    PG --> PGDB["Neo4j · Memgraph<br/>Neptune · TigerGraph"]

    RDF --> SP["SPARQL<br/>트리플 패턴 매칭"]
    RDF --> RDFDB["트리플스토어<br/>GraphDB · Blazegraph · Neptune"]

    CY --> USE1["운영·개발자 경험·<br/>깊은 탐색이 중요할 때"]
    SP --> USE2["표준·추론·데이터 연합·<br/>공개 어휘가 중요할 때"]

이 그림의 좌표는 하나입니다 — 속성 그래프는 “이 애플리케이션의 그래프를 빠르게 짓고 탐색하고 싶다”에, RDF는 “여러 출처의 데이터를 표준 어휘로 합치고 추론하고 싶다”에 강합니다. 실무 신규 프로젝트의 다수는 속성 그래프에서 출발하므로, 이 글도 Cypher를 먼저 손에 익힙니다.

속성 그래프와 Cypher — 질의가 화살표를 닮는다

노드 · 엣지 · 속성

속성 그래프(정확히는 labeled property graph)는 Neo4j로 대표되는 실무 주류 모델입니다. 구성은 셋입니다.

  • 노드: 실체 하나. 라벨로 종류를 표시하고(:Customer), 속성 키–값을 내부에 담습니다({name: "김지수", tier: "VIP"}).
  • 엣지: 방향 있는 관계. 타입을 갖고(:PLACED), 결정적으로 — 엣지 자신도 속성을 가질 수 있습니다({placedAt: date("2026-07-13")}).
  • 속성: 노드·엣지 양쪽에 붙는 값. RDF처럼 별도 트리플로 풀지 않고 실체 안에 내장됩니다.

Cypher로 주문 도메인을 만들어 보면 모델의 감촉이 바로 옵니다. Cypher는 화살표 ASCII 아트로 그래프 모양을 그대로 적는 질의어입니다.

// 노드 생성 — 라벨과 내장 속성
CREATE (c:Customer {id: "C-042", name: "김지수", tier: "VIP"})
CREATE (o:Order    {id: "O-1001", amount: 1200000})
CREATE (p:Product  {id: "P-77",  name: "노트북"})

// 엣지 생성 — 엣지에도 속성이 붙는다
CREATE (c)-[:PLACED   {placedAt: date("2026-07-13")}]->(o)
CREATE (o)-[:CONTAINS {quantity: 1}]->(p);

MATCH — 패턴 매칭 질의

질의도 같은 화살표 문법입니다. 묻고 싶은 관계의 모양을 그대로 그리면, 그래프에서 그 패턴에 들어맞는 조합을 찾아 줍니다.

// "노트북을 포함한 주문을 낸 고객과 주문액은?"
MATCH (c:Customer)-[:PLACED]->(o:Order)-[:CONTAINS]->(p:Product {name: "노트북"})
RETURN c.name, o.amount
ORDER BY o.amount DESC;

(c)-[:PLACED]->(o)라는 문법 자체가 화살표 그림입니다. 관계형 SQL이라면 3중 조인으로 썼을 질문이, 여기서는 도메인의 관계 구조를 그대로 옮긴 패턴이 됩니다. “질의가 모델을 닮는다” — 이것이 그래프 질의의 핵심 감각입니다.

그래프의 진짜 힘 — 가변 길이 경로

1단계에서 본 다중 홉의 강점이 Cypher에서는 * 문법 하나로 표현됩니다. 홉 수를 미리 못 박지 않고 데이터가 정하게 둡니다.

// 추천 — 나와 구매가 겹치는 다른 고객 (2홉 왕복)
MATCH (me:Customer {id: "C-042"})-[:PLACED]->()-[:CONTAINS]->(prod)
      <-[:CONTAINS]-()<-[:PLACED]-(other:Customer)
WHERE other <> me
RETURN other.name, count(prod) AS overlap
ORDER BY overlap DESC LIMIT 5;

// 사기 탐지 — 1~4홉 안의 자금 이동 경로 (홉 수는 열려 있다)
MATCH path = (a:Account {flagged: true})-[:TRANSFER*1..4]->(b:Account)
RETURN path LIMIT 20;

// 최단 경로 — 두 사람이 어떻게 연결되는가
MATCH p = shortestPath(
  (x:Person {name:"김지수"})-[:KNOWS*]-(y:Person {name:"이서준"}))
RETURN p;

TRANSFER*1..4, KNOWS*, shortestPath(...) 같은 표현은 관계형 SQL로는 옮기기 지극히 어렵거나 불가능합니다. 추천·사기 탐지·소셜 그래프가 그래프 DB의 대표 워크로드인 이유가 여기 있습니다.

가변 길이 경로 — [:TRANSFER*1..4] 가 홉마다 부채꼴로 넓혀 가며 경로를 찾는다 가변 길이 경로 — 홉 수는 데이터가 정한다 시작 1홉 2홉 3홉 4홉 계좌 flagged 목표 계좌 b (a:Account {flagged:true})-[:TRANSFER*1..4]->(b:Account) *1..4 = 1홉에서 4홉까지 — 굵은 금색이 목표까지 실제로 찾아낸 한 경로
*1..4는 홉 수를 못 박지 않고 데이터가 정하도록 열어 둔다 — 그래프는 홉마다 부채꼴로 넓혀 가며(회색), 목표까지 이어지는 경로(금색)를 찾아낸다. 관계형 조인으로는 옮기기 어려운 탐색이다.

스키마와 무결성 제약

속성 그래프는 기본적으로 스키마 선택적(schema-optional)입니다 — 아무 라벨·속성이나 자유롭게 붙이고, 필요한 만큼만 제약으로 조입니다.

// 최소한으로 조이는 제약 — 유일성(기본키 역할)과 존재성(필수 속성)
CREATE CONSTRAINT customer_id_unique IF NOT EXISTS
FOR (c:Customer) REQUIRE c.id IS UNIQUE;

CREATE CONSTRAINT order_amount_exists IF NOT EXISTS
FOR (o:Order) REQUIRE o.amount IS NOT NULL;

이 유연함은 스키마가 자주 진화하는 초기 그래프 구축에 유리합니다 — 3단계에서 지저분한 소스에서 그래프를 짓기 시작할 때 이 성질이 고맙습니다.

RDF와 SPARQL — 모든 것을 트리플로

트리플 저장소

RDF 계열은 정반대 극단을 택합니다 — 모든 사실을 주어–술어–목적어 트리플로 쪼개고, 모든 리소스와 술어를 URI로 전역 식별합니다. 속성을 노드 안에 내장하지 않고, 이름조차 별도 트리플입니다.

@prefix ex: <http://example.org/ontology#> .
@prefix c:  <http://example.org/customer/> .
@prefix o:  <http://example.org/order/> .

c:C-042  a ex:Customer ;          # "a" = rdf:type (클래스 소속)
         ex:name   "김지수" ;
         ex:placed o:O-1001 .
o:O-1001 a ex:Order ;
         ex:contains ex:P-77 .

이 극단적 균질성이 RDF의 힘이자 값입니다. 힘 — 이름이 전역적으로 유일하므로 서로 다른 데이터셋의 트리플을 그냥 합쳐도 같은 URI는 같은 실체로 병합됩니다(데이터 연합, linked data). 값 — 같은 사실을 표현하는 데 트리플 수가 많아지고, 엣지에 속성을 직접 붙이지 못해(관계에 값을 달려면 관계를 노드로 승격하는 reification이 필요) 표현이 장황해집니다.

SPARQL — 트리플 패턴 매칭

SPARQL의 발상은 Cypher와 형제입니다 — 변수를 품은 트리플 패턴을 그래프에 매칭합니다. 다만 화살표 대신 트리플 문장을 나열합니다.

PREFIX ex: <http://example.org/ontology#>

# "노트북을 포함한 주문을 낸 고객의 이름은?"
SELECT ?customerName
WHERE {
  ?customer ex:name     ?customerName ;
            ex:placed   ?order .
  ?order    ex:contains ?product .
  ?product  ex:name     "노트북" .
}

WHERE 절의 각 줄이 그래프에서 매칭돼야 할 엣지입니다. Cypher와 마찬가지로 “질의가 모델을 닮되”, 표현 단위가 화살표가 아니라 트리플이라는 점만 다릅니다. RDF의 진짜 차별점은 질의 문법이 아니라 그 위에 얹히는 OWL 추론(선언한 공리로 새 사실을 자동 도출)인데, 이는 Ontology 형식 기반 편에서 다룹니다.

같은 질문, 두 문법 — Cypher 화살표 패턴 ↔ SPARQL 트리플 패턴 같은 질문, 두 문법 "노트북을 포함한 주문을 낸 고객은?" Cypher — 화살표 패턴 SPARQL — 트리플 패턴 (c)-[:PLACED]->(o) ?c ex:placed ?o . (o)-[:CONTAINS]->(p) ?o ex:contains ?p . (p {name:"노트북"}) ?p ex:name "노트북" . ≡ ≡ ≡ 둘 다 "질의가 모델을 닮는다" — 변수를 품은 관계 패턴을 그래프에 매칭 차이는 표현 단위뿐: 화살표 대 트리플 문장
같은 질문이 Cypher 화살표 패턴과 SPARQL 트리플 패턴으로 한 줄씩 짝을 이룬다. 두 문법의 발상은 형제 — 변수를 품은 관계 패턴을 그래프에 매칭한다. 다른 것은 표현 단위(화살표 vs 트리플)뿐이다.

무엇을 언제 — 선택 기준과 지형도

property graph vs RDF

기준 속성 그래프 (Cypher/GQL) RDF (SPARQL)
데이터 단위 라벨·속성을 품은 노드/엣지 균질한 URI 트리플
엣지에 속성 직접 지원 reification 필요(장황)
개발자 경험 직관적, 앱 개발 친화 학습 곡선, 표준 엄격
데이터 연합·병합 애플리케이션이 처리 URI로 자연스럽게 병합
추론 기본은 없음(질의로 구현) OWL 논리 추론 표준
잘 맞는 곳 운영 앱·깊은 탐색·추천·사기 공개 지식·데이터 통합·표준 어휘

거칠게 요약하면 — “내 애플리케이션의 그래프를 빠르게 짓고 탐색하겠다”면 속성 그래프, “여러 기관·출처의 데이터를 표준 어휘로 통합하고 추론하겠다”면 RDF입니다. 의료·생명과학·정부·도서관처럼 공개 표준 온톨로지와 데이터 연합이 중요한 분야에서 RDF가, 스타트업·제품 팀의 추천·탐지·지식 그래프에서 속성 그래프가 흔히 선택됩니다. LLM으로 그래프를 짓는 4단계 이후의 흐름에서도 실무 예제는 대개 속성 그래프(Neo4j)를 씁니다.

GQL 표준과 그래프 DB 지형도

오랫동안 속성 그래프 질의어는 벤더마다 달랐지만(Cypher, Gremlin, …), 2024년 ISO가 GQL(Graph Query Language)을 SQL에 이은 두 번째 ISO 표준 데이터베이스 언어로 제정하며 Cypher 계열 문법을 표준화했습니다. 그래프 질의가 SQL처럼 이식 가능한 표준을 갖기 시작한 것입니다.

대표 지형도를 좌표로만 짚어 둡니다.

  • 속성 그래프 DB: Neo4j(사실상 표준), Memgraph(인메모리·실시간), TigerGraph(대규모 분석), Amazon Neptune(관리형, 속성 그래프+RDF 모두)
  • 트리플스토어(RDF): Ontotext GraphDB, Blazegraph, Amazon Neptune, Apache Jena
  • 질의어: Cypher/GQL(속성 그래프), SPARQL(RDF), Gremlin(TinkerPop 계열, 다중 DB)

어느 것을 고르든, 1단계에서 세운 “관계를 데이터로 저장한다”는 발상과 이 글에서 익힌 “질의가 모델을 닮는다”는 감각은 그대로 이어집니다.

정리

  • 두 계열, 하나의 그래프입니다. 속성 그래프는 저장·탐색의 실용성을, RDF는 표준·의미론·추론을 앞세웁니다.
  • Cypher는 화살표를 그린다: MATCH (a)-[:REL]->(b) 문법이 그래프 모양을 그대로 옮깁니다. 그래프의 진짜 힘은 *1..n 가변 길이 경로와 최단 경로 — 관계형이 감당 못 하는 탐색입니다.
  • RDF는 모든 것을 URI 트리플로 균질화해 데이터 연합과 추론에 강하지만, 표현이 장황하고 엣지 속성에 reification이 필요합니다.
  • 선택 기준은 목적입니다 — 운영 앱·깊은 탐색이면 속성 그래프, 표준·통합·추론이면 RDF. GQL 표준화로 속성 그래프 질의도 이식 가능한 표준을 갖기 시작했습니다.

다음 글에서는 이 저장소를 무엇으로 채울지 — 비정형 텍스트에서 개체와 관계를 뽑아 그래프를 짓는 구축 기초(NER/RE·스키마·엔티티 해소) — 를 다룹니다.

다음 학습 (Next Learning)