GraphRAG 시스템을 구축하는 사람들마다 어떤 그래프 데이터베이스를 선택해야 할지 열띤 논쟁을 벌인다. Neo4j인가 Memgraph인가? Cypher인가 openCypher인가? 디스크 기반인가 인메모리인가?

하지만 이들은 완전히 엉뚱한 계층을 두고 다투고 있다.

데이터베이스 선택도 물론 중요하다. 하지만 GraphRAG 프로젝트의 성패를 가르는 지점은 거기가 아니다. 대다수 구현체는 엔티티 해결(Entity Resolution, 개체 식별 및 통합) 단계에서 무너진다. 그리고 이 본질에 대해 이야기하는 이는 거의 없다.

GraphRAG의 장밋빛 약속

GraphRAG의 매력은 명확하다. 순수 벡터 기반 RAG는 단순히 글자나 문맥이 유사한 텍스트 덩어리를 긁어올 뿐이다. 반면 GraphRAG는 엔티티, 관계, 다단계(multi-hop) 경로로 엮인 **‘연결된 맥락(connected context)’**을 가져온다. LLM에게 온도 모니터링에 관한 단편적인 문단 5개를 던져주는 대신, 다음과 같이 잘 짜인 서브그래프를 전달하는 것이다:

변경-123 → 영향(AFFECTS) → 공정-Y → 준수기준(GOVERNED_BY) → SOP-123 → 요구사항(HAS_REQUIREMENT) → 요구사항-87 → 검증증거(VALIDATED_BY) → CSV-VAL-042

LLM은 이러한 구조화된 인과관계와 규제 흐름을 바탕으로 정밀하게 추론할 수 있다. 우연히 ’온도’라는 단어가 들어간 조각글 5개를 읽고는 결코 이런 결론을 내릴 수 없다.

마이크로소프트의 GraphRAG 연구 논문도 이를 뒷받침한다. 복잡한 추론 질문에서 그래프 증강 검색은 순수 벡터 검색보다 10점 이상 높은 성능을 기록했다. Neo4j의 2026년 5월 IDC 보고서에 따르면 지식 그래프로 AI를 접지(grounding)했을 때 환각(hallucination)이 44% 감소했다. 생명과학 분야의 한 고객사는 환각 발생률을 2040%에서 25% 수준으로 떨어뜨렸다.

모두 실재하는 성과다. 하지만 여기에는 치명적인 전제가 깔려 있다: **“그래프가 깨끗하게 정제되어 있다”**는 전제다.

아무도 말하지 않는 지저분한 비밀

순진하게 GraphRAG를 구축하면 대개 이런 절차를 밟는다:

  1. 문서를 청크(chunk) 단위로 자른다.
  2. LLM을 돌려 엔티티와 관계를 추출한다.
  3. 추출된 결과를 그래프 데이터베이스에 저장한다.
  4. 검색 쿼리가 들어오면 그래프를 탐색한다.

여기서 2단계가 문제다. LLM이 추출을 못해서가 아니다. LLM은 표준화된 고유 엔티티가 아니라, 텍스트에 적힌 **‘표면적 표현 형태(surface forms)’**를 그대로 추출하기 때문이다.

동일한 실험실 정보관리시스템(LIMS)을 다룬 문서 3개를 입력하면 다음과 같은 노드들이 마구잡이로 생성된다:

  • “LabVantage”
  • “Lab Vantage”
  • “LabVantage LIMS”
  • “LabVantage 8.9”
  • “LIMS”
  • “the LIMS system”

현실 세계에서는 단 하나의 시스템인데, 그래프 안에는 6개의 서로 다른 노드가 만들어진다.

그 결과 그래프는 하나로 끈끈하게 연결되어야 할 자리에 6개의 파편화된 섬(cluster)을 형성한다. 관계선들이 엉뚱한 변형 노드에 제각각 붙어 있어 경로 탐색은 맥없이 끊어진다. 엔티티 주변의 이웃 노드들은 흩어지고, 커뮤니티 탐지(community detection) 알고리즘은 의미 없는 쓰레기 군집을 뱉어낸다.

2025년의 한 연구에 따르면, 문서 청크에서 LLM으로 자동 추출된 847개의 엔티티는 실제로는 312개에 불과했다. 단순한 엔티티 해결 기법을 적용해 그래프 크기를 약 40% 압축하는 것만으로도, 테스트된 모든 GraphRAG 변형 모델의 질문 답변(QA) 정확도가 일관되게 상승했다.

이 결과를 곱씹어보아야 한다. 노드를 줄였더니 그래프 성능이 좋아졌다. 정보가 틀려서가 아니라 중복되고 찢어져 있었기 때문이다. 그래프가 너무 작아서 문제가 아니라, 너무 파편화되어 있었던 것이다.

엔티티 해결이 진짜 어려운 이유

대다수 GraphRAG 튜토리얼은 엔티티 해결을 사소한 뒷정리 정도로 취급한다. 이름 필드에 MERGE 쿼리를 날리거나 기껏해야 간단한 퍼지(fuzzy) 문자열 매칭 한 번 돌리고 끝낸다.

그건 엔티티 해결이 아니다. 과대망상에 빠진 단순 문자열 비교일 뿐이다.

진정한 엔티티 해결은 5가지 신호를 입체적으로 결합해야 한다:

1. 어휘 매칭 (Lexical matching): “LabVantage”와 “Lab Vantage”처럼 명백한 오타나 띄어쓰기를 잡아낸다. 편집 거리(edit distance), 대소문자 정규화 등을 쓰며 전체 중복의 약 30%를 해결한다.

2. 임베딩 유사도 (Embedding similarity): 의미적 동의어를 포착한다. “품질관리 플랫폼”과 “QMS”는 같은 대상을 가리킨다. 문장 임베딩의 코사인 유사도 임계치(0.880.92)를 적용해 추가로 2030%를 걸러낸다.

3. 속성 매칭 (Attribute matching): 구조화된 메타데이터를 활용한다. 공급업체가 같고, 시스템 카테고리가 같으며, 설치된 사업장이 같다면 표기된 이름이 달라도 동일한 시스템일 확률이 극도로 높다.

4. 그래프 위상 구조 (Graph topology): 대부분이 완전히 놓치는 가장 강력한 단서다. 만약 엔티티 A가 CAPA-123, 일탈-456, 교육-789라는 세 노드와 연결되어 있고, 엔티티 B 역시 정확히 동일한 세 이웃 노드와 연결되어 있다면 두 엔티티는 동일한 개체다. 공유하는 이웃 노드 간의 자카드 유사도(Jaccard similarity)를 계산하면, 이름은 완전히 딴판이지만 구조적 위치가 100% 일치하는 노드들을 완벽히 식별해 낼 수 있다.

5. LLM 심층 판정 (LLM reasoning): 모호한 경계에 놓인 케이스를 최종 판정한다. 후보 쌍의 속성과 이웃 연결 관계를 프롬프트에 넣고 “이 둘이 동일한 개체인가?“를 판별하도록 한다. 비용 문제로 모든 쌍에 쓸 수는 없으며 앞선 4단계 규칙으로도 결론이 안 난 까다로운 케이스에만 선별 적용한다.

완성된 엔티티 해결 파이프라인은 다음과 같은 구조를 띤다:

후보군 생성 (블로킹/클러스터링)
    → 어휘 및 임베딩 1차 필터링
    → 속성 및 그래프 위상 구조 유사도 채점
    → LLM 심층 판정 (모호한 케이스 한정)
    → 노드 병합 또는 SAME_AS 관계로 연결
    → 온톨로지 제약조건 검증

이것이 바로 Splink나 Senzing 같은 전문 프레임워크가 존재하는 이유다. 그리고 현재 시중의 수많은 GraphRAG 구현체들이 통째로 건너뛰고 있는 위험한 구멍이다.

Neo4j vs Memgraph: 진짜 엔지니어링 트레이드오프

이제 데이터베이스 이야기를 해보자. 단, 논의의 초점을 명확히 해야 한다.

Neo4j와 Memgraph는 둘 다 Cypher 쿼리를 지원하고, 프로퍼티 그래프를 다루며, 벡터 인덱스를 내장하고 있다. 아키텍처적 차이는 ‘디스크 기반인가’ 대 **‘인메모리 기반인가’**에서 비롯된다.

Neo4j는 성숙함의 상징이다. Java/JVM 기반, 페이지 캐시를 갖춘 디스크 저장소, 그래프 업계에서 가장 거대한 생태계를 자랑한다. 65개 이상의 알고리즘을 갖춘 GDS 라이브러리(커뮤니티 탐지, 노드 유사도, FastRP 임베딩, 링크 예측 등)는 독보적이다. 수십억 개의 노드를 저장해야 하거나, 복잡한 그래프 분석 알고리즘을 정기적으로 돌려야 한다면 Neo4j가 답이다.

Memgraph는 속도의 상징이다. C++ 기반, WAL 영속성을 갖춘 순수 인메모리 아키텍처로 1밀리초 미만의 초저지연 탐색을 보장한다. 가장 매력적인 기능은 검색, 서브그래프 확장, 랭킹, 프롬프트 조립을 단 한 번의 Cypher 쿼리로 끝내는 원자적 GraphRAG(Atomic GraphRAG) 지원이다. 파이썬 파이프라인의 복잡한 조율이 필요 없다. 실시간 스트리밍 처리에 최적화되어 있어 NASA가 10년간 쓰던 Neo4j를 Memgraph로 교체한 사례도 있다.

성능 차이는 분명하다. 벤치마크에 따르면 Memgraph는 최대 41배 낮은 지연 시간과 2~5배 높은 처리량을 보여준다. 디스크 I/O를 거치는 JVM과 C++ 인메모리 엔진의 차이는 단순한 튜닝으로 극복할 수 있는 영역이 아니다.

하지만 성능이 전부는 아니다. 수십 년 치의 전사적 규제 이력 — 모든 SOP, 일탈, 밸리데이션 기록 — 을 영구 적재하고 대규모 분석 알고리즘을 돌려야 하는 엔터프라이즈 환경에서는 Neo4j의 탄탄한 생태계와 GDS 라이브러리를 무시할 수 없다.

결국 질문은 “누가 더 빠른가”가 아니라 **“어떤 워크로드를 다루는가”**여야 한다.

규제 대상 AI(GxP) 환경에서 엔티티 해결이 치명적인 이유

제약, 의료기기 등 규제 준수(GxP) 환경에서 지식 그래프는 단순한 검색 도구가 아니라 법적 책임을 지는 감사 추적(audit trail) 그 자체다.

그래프의 모든 엣지는 메타데이터를 담고 있어야 한다:

  • 누가 작성/승인했는가 (Part 11 전자서명)
  • 언제 생성되었는가 (타임스탬프)
  • 어떤 문서 버전을 근거로 하는가
  • 변경 사유는 무엇인가 (변경 제어 번호)

이러한 규제 환경에서는 엔티티 해결의 실수가 단순한 검색 품질 저하를 넘어 치명적인 규제 위반으로 직결된다. 두 개의 서로 다른 일탈(deviation) 기록을 동일한 것으로 착각해 합쳐버리면 어떻게 될까? 감사 추적이 조작되고 출처 체인이 끊어진다. 실사관이 합쳐진 문서를 확인하는 순간, 서로 다른 두 사건의 증거가 하나로 뒤섞여 있는 치명적 결함을 발견하게 된다.

따라서 규제 환경에서의 엔티티 해결은 “LLM이 같다고 하니 그냥 합치자” 식이어선 절대 안 된다:

  • 명확한 임계치를 가진 신뢰도 점수(confidence score) 부여
  • 모호한 케이스에 대한 인간 전문가 검토(Human-in-the-loop)
  • 원본 노드를 파괴적으로 병합(destructive merge)하지 않고 보존하는 SAME_AS 엣지 연결
  • 시간 경과에 따른 개정 이력 추적
  • 모든 해결 결정에 대한 완벽한 감사 증적 보존

실무에서 구축해야 할 4계층 아키텍처

내가 제안하는 올바른 시스템 아키텍처는 다음과 같다:

계층 1: 엔티티 해결 엔진 (Entity Resolution Engine): 데이터 인제스천(수집) 시점에 즉각 실행된다. 어휘, 임베딩, 속성, 그래프 위상, LLM 판정을 조합하여 신뢰도 점수가 매겨진 표준 엔티티 ID를 발급한다. 모호한 데이터는 인간 검토 큐로 보낸다.

계층 2: 지식 그래프 (Knowledge Graph): 표준 엔티티, 타입이 정의된 관계선, 출처 메타데이터, 증거 체인을 저장한다. 전사 분석용 백본에는 Neo4j를, 에이전트 서빙용 초저지연 캐시에는 Memgraph를 활용하는 이원화 구성도 훌륭하다.

계층 3: 하이브리드 검색 (Hybrid Retrieval): 의미적 진입점을 잡는 벡터 검색과 구조적 맥락을 확보하는 그래프 탐색의 결합. 규제 환경에서는 LLM이 런타임에 즉흥적으로 Cypher를 짜게 두지 않고, 버전 관리되는 파라미터화된 템플릿(Parameterized Cypher)을 사용한다.

계층 4: AI 에이전트 (AI Agents): 그래프를 검증된 템플릿으로 탐색하여 답을 도출한다. 에이전트는 절대 그래프의 데이터를 직접 수정하지 않는다.

그래프가 단일 진실 원천(System of Record)이고, LLM은 그 위에서 구조화된 지식을 읽어내는 해석가일 뿐이다.

맺으며

그래프 데이터베이스는 인프라일 뿐이다. GraphRAG는 이를 활용하는 애플리케이션 패턴이다. 그리고 엔티티 해결은 이 둘이 실제로 제 기능을 하도록 만드는 절대적인 전제 조건이다.

엔티티 해결을 건너뛴 시스템은 GraphRAG가 아니다. 그저 잘못된 정보들을 매우 자신감 넘치게 서로 연결해 놓은 **‘탐색 가능한 환각 기계’**에 불과하다.

Neo4j와 Memgraph 사이의 선택은 중요한 기술적 고민이다. 하지만 당신의 GraphRAG 시스템이 신뢰할 수 있고, 감사에 통과할 수 있으며, 정확한 답을 내놓을지를 결정하는 진짜 승부처는 데이터베이스 브랜드가 아니다.

다른 어떤 화려한 기능보다 먼저, 엔티티 해결에 시간과 자원을 투자했는가? 바로 그 질문에 모든 것이 달려 있다.