[LLM Wiki 25] Neo4j란 무엇인가: 관계를 따라 답을 찾는 그래프 데이터베이스

비공개로 정리한 GS리테일의 Qdrant 설계 해설에서 Qdrant 옆에 Neo4j라는 데이터베이스가 등장했습니다. Qdrant가 비슷한 문서를 찾는다면 Neo4j는 데이터 사이의 연결을 따라갑니다.

Neo4j는 보통 “네오포제이”라고 읽습니다. 이름의 4j는 Java 생태계에서 시작한 프로젝트 이름에 자주 붙던 표현에서 왔지만, Neo4j를 사용하는 데 Java가 반드시 필요한 것은 아닙니다.

Neo4j는 무엇인가

Neo4j는 데이터를 graph, 그래프 형태로 저장하고 검색하는 graph database, 그래프 데이터베이스입니다.

여기서 그래프는 막대그래프나 선그래프 같은 통계 차트가 아닙니다. 대상과 대상 사이의 관계를 점과 선으로 표현한 구조입니다.

[결제 시스템] ──담당한다──> [재무팀]
      │
    사용한다
      ↓
[정산 프로세스] ──다음 단계──> [승인]

일반 데이터베이스가 “결제 시스템의 이름과 상태는 무엇인가?”를 저장하는 데 집중한다면, 그래프 데이터베이스는 “결제 시스템이 어느 팀과 어느 프로세스에 연결됐는가?”를 직접 표현하는 데 집중합니다.

Node, Relationship, Property

Neo4j의 기본 저장 모델은 property graph, 속성 그래프입니다. 세 가지 요소부터 이해하면 됩니다.

Node, 노드는 그래프 안의 대상입니다. 사람, 부서, 문서, 시스템, 제품, 장애가 노드가 될 수 있습니다.

Relationship, 릴레이션십은 노드 사이의 연결입니다. 흔히 edge, 엣지라고도 부릅니다. Neo4j의 Relationship에는 방향과 타입이 있습니다.

Property, 프로퍼티는 노드나 Relationship에 붙는 이름, 날짜, 상태 같은 부가정보입니다.

위 구조를 글로 쓰면 다음과 같습니다.

Node: 결제 시스템
  label: System
  properties: { name: "결제 시스템", status: "운영 중" }

Relationship: OWNED_BY
  결제 시스템 → 재무팀
  properties: { since: "2025-01-01" }

Label, 레이블은 노드의 종류를 나타냅니다. System, Team, Document 같은 분류입니다. Relationship의 OWNED_BY, USES, NEXT_STEP은 연결의 의미를 나타내는 타입입니다.

Path와 Traversal

노드와 Relationship이 연속해서 이어진 경로를 path, 패스라고 합니다.

장애 → 발생 시스템 → 담당 부서 → 담당자

이 경로를 따라 데이터를 탐색하는 작업이 traversal, 트래버설입니다. Neo4j는 연결 자체를 저장하므로 다음 질문을 자연스럽게 표현할 수 있습니다.

• 이 시스템의 담당 부서는 어디인가?
• 이 장애와 연결된 다른 장애는 무엇인가?
• A 업무 다음에 실행해야 하는 절차는 무엇인가?
• 이 문서와 연결된 시스템과 담당자를 찾아줘.
• 두 사람 사이에는 어떤 프로젝트가 연결돼 있는가?

관계가 여러 단계를 거칠 때는 “몇 번 연결을 따라갈 것인가”도 중요합니다. 너무 멀리 확장하면 결과가 폭발하고 관계가 약해질 수 있으므로, 실무에서는 관계 타입과 탐색 깊이를 제한합니다.

관계형 데이터베이스와 무엇이 다른가

RDBMS, Relational Database Management System, 관계형 데이터베이스 관리 시스템는 데이터를 행과 열로 된 표에 저장합니다. 여기서 “관계형”의 관계는 수학적인 릴레이션을 뜻하며, Neo4j의 Relationship과 같은 의미는 아닙니다.

관계형 데이터베이스에서도 여러 표를 JOIN해서 연결을 찾을 수 있습니다.

systems 표
teams 표
system_owners 연결 표
processes 표
system_processes 연결 표

연결이 한두 단계이고 거래 정합성이 핵심이라면 PostgreSQL, MySQL 같은 관계형 데이터베이스가 매우 적합합니다. 반면 연결 종류가 많고 몇 단계를 연속해서 탐색하는 질문이 중심이면 JOIN 구조가 복잡해질 수 있습니다.

Neo4j에서는 연결이 데이터 모델의 일급 요소입니다. 즉, Relationship 자체에 타입, 방향, Property를 붙이고 관계 패턴을 직접 검색합니다.

질문	관계형 데이터베이스	Neo4j
주문 한 건의 금액 조회	매우 적합	가능하지만 장점이 작음
시스템과 담당 부서 조회	JOIN으로 처리	Relationship으로 직접 표현
여러 단계의 영향 범위 분석	JOIN이나 재귀 쿼리가 복잡해질 수 있음	Path 탐색으로 표현하기 쉬움
관계가 자주 추가되는 데이터	스키마와 연결 표 변경 필요	새 노드와 Relationship 추가가 유연함

Neo4j가 관계형 데이터베이스를 무조건 대체하는 것은 아닙니다. 핵심 업무 거래는 관계형 데이터베이스에 두고, 연결 분석이 필요한 일부 데이터를 Neo4j에 동기화하는 구성도 흔히 사용합니다.

Cypher, 그래프에 질문하는 언어

Neo4j는 Cypher, 사이퍼라는 선언형 그래프 질의 언어를 사용합니다. SQL이 표에서 조건에 맞는 행을 찾는다면, Cypher는 노드와 Relationship이 연결된 모양인 pattern, 패턴을 찾습니다.

다음 질의는 “결제 시스템을 담당하는 팀의 이름”을 찾습니다.

MATCH (s:System {name: "결제 시스템"})-[:OWNED_BY]->(t:Team)
RETURN t.name

기호를 나눠 보면 어렵지 않습니다.

(s:System)       System 레이블을 가진 노드
[:OWNED_BY]      OWNED_BY 타입의 Relationship
->               Relationship의 방향
(t:Team)         Team 레이블을 가진 도착 노드
MATCH            이 연결 패턴을 찾는다
RETURN           찾은 데이터 중 무엇을 돌려줄지 정한다

WHERE를 붙여 Property 조건을 제한할 수도 있습니다.

MATCH (s:System)-[:HAS_INCIDENT]->(i:Incident)
WHERE i.severity = "critical"
RETURN s.name, i.title

Cypher는 원하는 연결 패턴을 선언하고, 실제 탐색 방법은 데이터베이스의 질의 계획기가 선택합니다. 애플리케이션에서는 문자열을 직접 이어 붙이기보다 매개변수를 사용해 질의를 전달하는 것이 안전합니다.

Qdrant와 Neo4j의 차이

Qdrant와 Neo4j는 서로 대체재라기보다 기본적으로 잘하는 질문이 다릅니다.

Qdrant는 문서나 이미지의 의미를 나타내는 vector, 벡터를 저장하고, 질문 벡터와 가까운 대상을 찾는 데 특화된 벡터 데이터베이스입니다.

Neo4j는 노드와 Relationship을 저장하고, 어떤 대상이 무엇과 어떻게 연결됐는지 탐색하는 데 중심을 둔 그래프 데이터베이스입니다.

도구	중심 데이터	잘하는 질문
Qdrant	벡터와 payload	“침수 대응과 의미가 비슷한 문서를 찾아줘”
Neo4j	노드와 Relationship	“침수 사고의 담당 부서와 다음 보고 단계는?”

Neo4j에도 벡터 인덱스가 있으므로 벡터 검색을 전혀 못 하는 것은 아닙니다. 반대로 Qdrant의 payload로 일부 연결 정보를 표현할 수도 있습니다. 차이는 기능의 유무보다 제품의 중심 모델과 운영 목적에 있습니다.

벡터 검색 규모와 필터링을 Qdrant가 맡고, 복잡한 관계 탐색을 Neo4j가 맡도록 역할을 분리할 수 있습니다. 반대로 규모와 요구가 단순하다면 Neo4j 하나로 벡터와 그래프를 함께 처리하는 설계도 검토할 수 있습니다.

Qdrant와 함께 GraphRAG 만들기

GraphRAG, 그래프 RAG는 문서의 의미 검색에 지식 그래프의 관계 탐색을 결합하는 RAG 방식입니다.

예를 들어 “결제 장애의 담당자와 다음 대응 절차를 알려줘”라는 질문을 처리해 보겠습니다.

1. 질문을 임베딩으로 바꿉니다.
2. Qdrant에서 의미가 가까운 장애 문서와 시스템 문서를 찾습니다.
3. 검색된 문서에 연결된 Neo4j 노드를 찾습니다.
4. 담당한다, 다음 단계, 연결된다 같은 관계를 제한된 깊이로 탐색합니다.
5. 문서 근거와 관계 근거를 LLM에 함께 제공합니다.
6. LLM이 출처를 표시하며 답변합니다.

이 구조에서 Qdrant는 “무엇을 읽어야 하는가?”를 찾고, Neo4j는 “그 대상과 무엇이 연결돼 있는가?”를 확장합니다.

Neo4j가 관계를 자동으로 알아내는 것은 아니다

가장 흔한 오해는 Neo4j를 설치하면 문서 관계가 자동으로 생긴다는 생각입니다. Neo4j는 저장과 탐색을 담당합니다. 어떤 노드와 Relationship을 넣을지는 별도의 수집 파이프라인이 결정해야 합니다.

문서에서 관계를 만드는 방법은 여러 가지입니다.

• 업무 시스템의 기존 데이터베이스에서 확정된 관계를 가져옵니다.
• 문서의 링크와 계층 구조를 관계로 변환합니다.
• 규칙으로 담당자, 시스템명, 절차 번호를 추출합니다.
• LLM이나 개체명 인식 모델로 후보 관계를 추출합니다.
• 중요한 관계는 사람이 검수합니다.

LLM이 추출한 관계는 틀릴 수 있습니다. “A 문서에서 B 시스템을 언급했다”와 “A가 B를 담당한다”는 전혀 다른 관계입니다. 출처, 추출 시각, 신뢰도, 유효 기간을 Property로 남기고 검증되지 않은 관계가 답변에 바로 사용되지 않도록 해야 합니다.

그래프를 무작정 확장하면 안 되는 이유

시작 노드 하나에서 관계를 여러 단계 따라가면 후보 수가 급격하게 늘어날 수 있습니다. 이를 흔히 graph explosion, 그래프 폭발이라고 표현합니다.

1단계, 연결 10개
2단계, 최대 100개
3단계, 최대 1,000개

실제 그래프는 중복 연결이 있어 단순 곱셈과 같지는 않지만, 탐색 범위를 제한해야 한다는 점은 같습니다.

• 허용할 Relationship 타입을 제한합니다.
• 탐색 깊이를 1단계나 2단계로 제한합니다.
• 사용자의 접근 권한을 모든 단계에 적용합니다.
• 날짜와 상태가 유효한 관계만 사용합니다.
• 관계 근거가 답변 품질을 실제로 높였는지 평가합니다.

그래프 후보를 추가했는데 응답이 느려지거나 관련 없는 근거가 늘어난다면 GraphRAG를 전체 답변에 켜지 않는 편이 낫습니다. GS리테일 사례처럼 별도 평가 경로에서 벡터 검색만 사용한 결과와 비교한 뒤 특정 질문부터 적용할 수 있습니다.

Neo4j가 잘 맞는 문제

다음처럼 관계 자체가 답인 문제에 잘 맞습니다.

• 조직과 담당자 구조
• 시스템 의존성과 장애 영향 범위
• 공급망과 물류 경로
• 사기 거래 연결망
• 상품, 고객, 행동을 연결한 추천
• 문서, 개념, 근거를 연결한 지식 그래프
• 네트워크와 접근 권한 분석

반면 단순한 문서 저장, 주문 거래, 집계 보고서만 필요하다면 기존 관계형 데이터베이스나 검색 엔진이 더 단순할 수 있습니다.

한 번에 정리하기

Neo4j를 이해하는 핵심은 네 문장입니다.

Node         = 사람, 시스템, 문서 같은 대상
Relationship = 대상 사이의 방향 있는 연결
Property     = 이름, 상태, 날짜 같은 부가정보
Cypher       = 연결 패턴을 찾는 그래프 질의 언어

Qdrant와의 관계도 한 문장으로 정리할 수 있습니다.

Qdrant는 의미가 가까운 문서를 찾고, Neo4j는 그 문서와 연결된 사람, 시스템, 절차를 따라간다.

두 도구를 함께 쓴다고 항상 더 좋은 답이 나오는 것은 아닙니다. 정확한 관계 데이터, 권한 필터, 제한된 탐색 깊이, 실제 질문을 이용한 평가가 갖춰질 때 GraphRAG의 장점이 살아납니다.

참고 자료

• Neo4j 공식 문서, What is a graph database
• Neo4j 공식 문서, What is Cypher
• Neo4j Cypher Manual, MATCH
• Neo4j Cypher Manual, Core concepts
• Qdrant란 무엇인가, FAISS와 HNSW의 관계