그래프 = 노드 + 관계 + 속성

왜 중요한가?

Property Graph는 그래프 데이터베이스의 표준 모델입니다. Neo4j, Amazon Neptune, Memgraph 모두 이 모델을 사용합니다.

이해하면:

• Neo4j의 모든 개념이 자연스럽게 이해됨
• 데이터 모델링 설계가 쉬워짐
• Cypher 쿼리 작성이 직관적으로 됨

핵심 개념

Property Graph의 4가지 구성 요소

1. 노드 (Node) - 엔티티

역할: 사람, 장소, 사물, 개념 등 실체를 표현

비유: 명사 - "사람", "회사", "도시"

2. 관계 (Relationship) - 연결

역할: 두 노드를 방향성 있게 연결

특징:

• 반드시 시작 노드와 끝 노드 필요 (허공에 존재 불가)
• 반드시 타입 필요 (KNOWS, WORKS_AT 등)
• 같은 두 노드 사이에 여러 관계 가능
• Self-loop 가능 (노드가 자기 자신을 가리킴)

비유: 동사 - "알다", "근무하다", "구매하다"

3. 속성 (Property) - 상세 정보

역할: 노드나 관계에 붙는 키-값 쌍

지원 타입 정리표:

타입	예시	참고
String	"Alice"	UTF-8
Integer	30	64-bit
Float	3.14	64-bit
Boolean	true, false
Date	date('2024-01-15')	ISO 8601
DateTime	datetime('2024-01-15T10:30:00')
Duration	duration('P30D')	ISO 8601
Point	point({latitude: 37.5, longitude: 127.0})	공간 데이터
List	["a", "b", "c"]	동일 타입 원소

저장 불가:

• 중첩 객체 (Map/Dict) -> 별도 노드로 분리
• 혼합 타입 List -> 동일 타입으로 통일

4. 레이블 (Label) - 분류

역할: 노드를 카테고리로 분류

용도:

• 노드 그룹핑 및 빠른 필터링
• 인덱스 생성 (검색 최적화의 핵심)
• 스키마 정의 (제약 조건)
• 권한 관리 (Enterprise)

Property Graph를 RDBMS 관점에서 이해하기

자주 하는 실수

자주 하는 실수

실수	문제	올바른 방법
관계에 타입 없이 생성	에러 발생	-[:KNOWS]-> 타입 필수
관계 방향 무시	예상과 다른 결과	방향 고려해서 설계
속성에 객체 저장	지원 안 됨	별도 노드로 분리
레이블 없이 노드 생성	검색 성능 저하	레이블 반드시 부여
레이블을 소문자로	컨벤션 위반	PascalCase 사용
관계 타입을 camelCase로	컨벤션 위반	UPPER_SNAKE_CASE 사용
모든 것을 속성으로	모델 비효율	의미있는 엔티티는 별도 노드

Property Graph vs 다른 그래프 모델

모델	특징	대표 DB	표준
Property Graph	노드/관계에 속성 저장	Neo4j, Memgraph	GQL (ISO 표준화 진행)
RDF (Triple Store)	Subject-Predicate-Object	Stardog, Virtuoso	W3C 표준 (SPARQL)
Hypergraph	관계가 2개 이상 노드 연결 가능	HyperGraphDB	없음

Property Graph 선택 이유:

• 직관적 (현실 세계와 매핑 쉬움)
• 풍부한 속성 (노드/관계 모두)
• 성숙한 생태계 (Neo4j 15년+)
• GQL 국제 표준화 진행중 (ISO/IEC 39075)

Property Graph와 RDF 비교 예시

결론: 관계에 속성을 자연스럽게 붙일 수 있는 Property Graph가 실무에서 더 직관적