Graph-DB

grahp와 관련한 기술을 한번 공부하고 정리해보려고 한다. 

원래도 학부연구생때 석사친구의 분야가 graph로 하는 머신러닝이였는데,, graph가 워낙 어려워야지.. 

개념자체는 쉬운데 이게 데이터를 다루기가 상당히 까다롭다. 근데 요즘 안티그래비티에서도 그래프로 다루고 기업에서도 Rag를 그래프로 다룬다하니 한번 공부해보려고 한다. 실상은 LLM이 성능이 너무 좋아져서 필요가 있을까 하는데,, 뭐 공부하면 언젠가 득이되지 않을까.. 

 

 

그래프란? 

 

그래프는 자료구조중에 하나이다. 

사실 여기서 딥하게 다루면 끝도 없어서 간단하게 정리하자면 

간선(edge)와 정점(vertex)로 이루어져 있다. 일단 이 자료구조의 장점은 형상이없다. 

무슨뜻이나면 각 노드들의 관계를 간선으로 이어서 구조가 보다 자유롭고 간선에 가중치나 방향을 부여함으로 노드관의 관계를 나타낼 수 있다. 

 

이는 무조건적인 장점이지만 단점으로는 해석이 어렵다는 단점이 있다. 

당장은 우리가 그림으로 보고있지만, 실제로 비선형적인 자료구조이기 때문에 시각화하지 않고 보려면 이해하기 난해하다. 또한 구조가 타고 타고 가는거다보니 구조가 복잡해서 메모리를 많이 먹는다는 단점이 있다. 

 

당장 그림에서 i가 시작이라하고 a를 찾으려면  i - c - a 로 가야하는데 이 길을 탐색을 해야한다. 

그래서 이런 그래프에서 데이터를 찾기 위해서는 bfs라던지 dfs라던지 알고리즘을 사용해야한다. 그런데 그래프 db에는 이런게 알아서 탑재되어 있긴하다. 

 

 

그래프 db 특징 

1. 직접 구현하지 않는 탐색 (Query Language)

가장 큰 차이점은 BFS나 DFS를 직접 코드로 짤 필요가 없다는 점입니다. 대신 Cypher(Neo4j용) 같은 그래프 전용 쿼리 언어를 사용합니다.

• RDB (SQL): "A와 B가 친구고, B와 C가 친구인 관계를 찾으려면 JOIN을 두 번 해라." (복잡함)
• Graph DB (Cypher): (A)-[:FRIEND]->(B)-[:FRIEND]->(C)라고 화살표만 그리면 DB가 알아서 최적의 탐색(내부적으로는 BFS/DFS 변형)을 수행합니다.

2. 그래프 DB의 핵심 강점: 인덱스 없는 인접성 (Index-free Adjacency)

그래프 DB가 왜 빠른지 이해하는 것이 중요합니다.

• 일반 DB는 데이터를 찾을 때마다 '인덱스'라는 색인을 뒤져야 하지만,
• 그래프 DB는 각 노드가 물리적으로 옆 노드의 주소를 들고 있습니다. 즉, 한 노드에서 다른 노드로 이동하는 속도가 데이터 양이 많아져도 느려지지 않습니다.

3. 어떤 그래프 DB를 고민 중이신가요?

현재 가장 많이 쓰이는 것들은 다음과 같습니다.

• Neo4j: 가장 대중적이고 배우기 쉽습니다. (Cypher 언어 사용)
• AWS Neptune: 지금 AWS SAA 공부 중이시라면 익숙하실 텐데, AWS에서 제공하는 완전 관리형 그래프 DB입니다. 대규모 서비스에 유리하죠.
• Memgraph: 메모리 기반이라 속도가 엄청 빠르고 파이썬과 호환성이 좋습니다.

 

 

RDB vs Graph DB

1. RDB의 방식 (엄격한 스키마)

• 모든 행(Row)의 동일 구조화: 테이블에 컬럼(Column)을 하나 추가하면, 해당 테이블의 모든 데이터에 그 자리가 생김.
• NULL 값 발생: 특정 데이터에 해당 속성이 없더라도 칸을 비워둔 채(NULL)로 유지해야 함. 이는 메모리 낭비와 관리의 복잡성을 초래함.

2. 그래프 DB의 방식 (유연한 속성 모델)

• 개별 노드/엣지 독립성: 각 엣지(관계)는 서로 다른 속성을 가질 수 있음.
• 선택적 속성 부여: A와 B의 관계에는 '친밀도' 속성을 넣고, B와 C의 관계에는 아무 속성도 넣지 않아도 됨.
• 데이터 효율성: 값이 있는 경우에만 속성을 생성하므로 불필요한 빈 공간(NULL)을 저장하지 않음.

실제 사례로 

• 관계 1: (나) - [:연습경기를_함 {점수: "11:9", 날짜: "2026-03-10"}] -> (멤버A)
  • 여기에는 '점수'와 '날짜'를 기록함.
• 관계 2: (나) - [:연습경기를_함] -> (멤버B)
  • 여기에는 단순히 경기했다는 사실만 연결하고 속성은 하나도 넣지 않음.

이렇게 데이터마다 넣고 싶은 정보가 제각각일 때 그래프 DB는 아무런 제약 없이 작동함.

• RDB: "모두가 같은 규격의 양복을 입어야 함." (안 맞으면 빈 공간으로 둠)
• 그래프 DB: "각자 자기 몸에 맞는 옷을 자유롭게 입음." (필요 없으면 안 입어도 됨)

 

그렇다면 분석 할때 어렵지 않을까? 왜냐면 데이터가 자유롭다는것은 그만큼 정제가 분석하기가 어렵다는 뜻 

1. 집계 및 통계의 복잡성

• 전체 평균 계산의 어려움: 엑셀은 열 하나만 잡고 평균을 내면 되지만, 그래프 DB는 "이 속성을 가진 노드들만 골라내라"는 필터링 과정을 거쳐야 함.
• 데이터 누락 파악: 특정 속성이 빠진 데이터가 많을 경우, 분석 결과가 왜곡될 위험이 있음.

2. 쿼리 성능의 예측 불가능성

• 탐색 범위의 가변성: 어떤 노드는 관계가 수천 개고, 어떤 노드는 1개라면, 쿼리를 날렸을 때 어떤 건 0.1초 만에 끝나고 어떤 건 10초가 걸릴 수 있음. 이를 '슈퍼 노드(Super Node)' 문제라고 함.

3. 데이터 품질 관리(Governance)의 부재

• 강제성 없음: '나이' 속성을 누구는 숫자(27)로 넣고, 누구는 문자열("27세")로 넣어도 DB가 막지 않음. 나중에 분석할 때 데이터 정제(Cleaning)에 시간이 많이 소요됨.

---

그럼에도 왜 그래프 DB로 분석을 할까?

전통적인 '수치 분석'은 어렵지만, '구조 분석'에서는 비교 불가능한 강점을 가짐.

• 커뮤니티 탐지: "누가 누구랑 친한가?"가 아니라, "이 거대한 네트워크에서 끼리끼리 뭉친 그룹이 어디인가?"를 분석함. (알고리즘: Louvain, PageRank 등)
• 중심성 분석: "누가 가장 영향력이 큰가?"를 찾음. (예: 탁구 동호회에서 이 사람만 없으면 모임이 깨지는 핵심 인물 찾기)
• 추천 로직: "A와 비슷한 패턴으로 연결된 B를 찾아라" 같은 복잡한 관계 패턴을 분석함

 

 

 어느정도 graph db의 장단점을 알아봤다. 다음 포스트에서는 공공데이터 포털의 api를 토대로 그래프 db를 구축하는 실습을 해보겠다.