단순 벡터 검색을 넘어선 지식의 연결: Rust로 구현한 초고속 GraphRAG, 'EdgeQuake' 심층 해부
1. 또 엉뚱한 문서 물고 왔네: RAG 만능주의의 민낯
최근 현업에서 LLM(대형 언어 모델)을 활용해 사내 지식 기반 챗봇이나 코파일럿을 구축해보신 분이라면, 이 탄식을 백 번쯤은 내뱉어 보셨을 겁니다. “문서를 청킹(Chunking)해서 임베딩하고, 벡터 DB에 넣은 다음 코사인 유사도로 검색해라.” 시중에 널리 퍼진 이 ‘RAG(검색 증강 생성) 만능주의’ 공식은 막상 프로덕션 환경에 배포하는 순간 처참하게 무너집니다.
벡터 기반의 유사도 검색은 ‘사과’라는 단어와 ‘과일’이라는 단어가 의미적으로 가깝다는 것은 기가 막히게 찾아내지만, “A 부서의 김철수 책임이 B 프로젝트의 보안 이슈를 어떻게 해결했는가?” 같은 다단계 추론(Multi-hop reasoning)이나, “이번 분기 기술 문서들을 관통하는 주요 테마는 무엇인가?” 같은 구조적 질문 앞에서는 꿀 먹은 벙어리가 됩니다. 문서를 잘게 쪼개는 순간, 문장과 문장, 개념과 개념 사이에 존재하던 ‘관계(Relationship)’라는 귀중한 맥락이 고차원 벡터 공간의 파편으로 산산조각 나버리기 때문이죠.
최근 이런 RAG의 근본적 한계에 염증을 느끼고 있던 찰나, 제 레이더망에 몹시 흥미로운 오픈소스 프로젝트 하나가 걸려들었습니다. 바로 Raphaël Mansuy가 주도하여 개발한 EdgeQuake입니다. 단순히 또 다른 파이썬(Python) 기반의 래퍼(Wrapper) 라이브러리겠거니 하고 코드를 열어봤다가, 철저하게 Rust로 작성된 아키텍처와 그 이면에 깔린 날카로운 철학을 보고 밤늦게까지 공식 문서를 파헤치게 되었습니다. 오늘 커피 한잔과 함께 이 요물 같은 프레임워크에 대해 진지하게 논의해볼까 합니다.
2. TL;DR: 지식 그래프와 벡터 검색의 결합
EdgeQuake는 기존 RAG가 잃어버린 ‘맥락’을 되찾기 위해, 텍스트에서 지식 그래프(Knowledge Graph)를 추출하고 이를 벡터 검색과 융합(Hybrid Retrieval)하여 다단계 추론을 가능하게 하는 Rust 기반의 초고속 GraphRAG 프레임워크입니다.
3. Under the Hood: 아키텍처 심층 해부
본격적으로 뚜껑을 열어보죠. EdgeQuake는 학계에서 화제가 된 LightRAG 알고리즘을 코어로 삼고 있습니다. 하지만 이를 단순히 구현한 것에 그치지 않고, 엔터프라이즈 환경에서 실제로 버틸 수 있도록 아키텍처를 완전히 재설계했습니다.
🧩 파편화를 막는 인덱싱 파이프라인 (The Extraction Pipeline)
기존 시스템이 문서를 텍스트 덩어리로만 취급했다면, EdgeQuake는 문서를 ‘엔티티(Entity)’와 ‘관계(Relationship)’의 네트워크로 분해합니다. 데이터가 입력되면 다음과 같은 무시무시한 파이프라인을 거칩니다.
- Chunk & Extract: 문서를 약 1200 토큰 단위(100 토큰 오버랩)로 나눈 뒤, LLM을 호출해 각 청크에서
(주체, 타입, 설명)및(출발지, 도착지, 키워드, 설명)형태의 튜플을 맹렬하게 뽑아냅니다. json 포맷의 취약점을 피하기 위해 튜플 기반의 추출을 사용한 점이 눈에 띕니다. - Gleaning (이삭 줍기): 이 기능이 정말 재미있습니다. LLM이 한 번에 모든 엔티티를 완벽히 찾지 못한다는 점을 쿨하게 인정하고, 선택적인 2차 패스를 통해 누락된 엔티티를 다시 긁어모읍니다. 공식 문서에 따르면 이 과정만으로 재현율(Recall)이 약 18% 상승한다고 합니다.
- Normalize: “Apple Inc.”와 “apple”, “애플” 등 중구난방으로 추출된 엔티티들을 대소문자 정규화와 설명 병합을 통해 중복을 약 36~40%까지 줄여버립니다. 지식 그래프의 품질은 여기서 결정된다고 해도 과언이 아니죠.
이 과정을 거치면 단순한 텍스트 파일이 거대한 지식의 거미줄(Graph)로 변모합니다. 질문이 들어오면 벡터 유사도만 보는 게 아니라 이 거미줄을 타고 넘나들며(Graph Traversal) 답변의 근거를 수집하는 하이브리드 검색이 이루어집니다.
🗄️ 우아하고 실용적인 인프라: PostgreSQL 하나로 끝내기
보통 ‘지식 그래프’를 쓴다고 하면 Neo4j 같은 무거운 전용 그래프 DB를 띄워야 하나 지레 겁부터 먹게 됩니다. 인프라 관리 포인트가 늘어나는 건 현업 개발자들에게 악몽이니까요. 그런데 EdgeQuake는 아주 실용적인 선택을 했습니다. 우리에게 너무나도 친숙한 PostgreSQL 위에 그래프 처리를 위한 Apache AGE 확장 모듈과 벡터 검색을 위한 pgvector를 결합했습니다. 단일 데이터베이스 환경에서 벡터와 그래프라는 두 가지 상이한 데이터 구조를 완벽하게 제어합니다. 이건 인프라를 직접 운영해 본 사람만이 할 수 있는 영리한 설계입니다.
🦀 왜 하필 Rust인가? (성능과 메모리 제어)
파이썬 기반의 기존 GraphRAG 시스템들은 대량의 문서를 병렬로 처리할 때 GIL(Global Interpreter Lock)과 엄청난 메모리 누수로 인해 서버가 뻗어버리는 일이 다반사입니다. EdgeQuake는 Rust의 제로 코스트 추상화와 소유권(Ownership) 기반의 정교한 메모리 관리를 통해 불필요한 데이터 복사를 원천 차단했습니다. 동시성 처리(async/await)를 극대화해 수많은 API 호출과 DB 트랜잭션을 병목 없이 처리하며, 시스템 자원 소모를 기존 파이썬 프레임워크 대비 획기적으로 낮췄습니다.
4. Hands-on: 실무엔 어떻게 써먹을까?
그렇다면 당장 내일 출근해서 이 녀석을 어디에 써먹을 수 있을까요?
가장 추천하는 시나리오는 복잡한 사내 규정집이나 레거시 코드베이스 분석입니다. 예를 들어 수십 개의 마이크로서비스로 얽힌 아키텍처에서 “결제 모듈의 트랜잭션 타임아웃이 발생했을 때 영향을 받는 하위 서비스들을 모두 찾고 요약해 줘”라고 질문한다고 가정해 봅시다. 기존 벡터 검색은 ‘트랜잭션’, ‘결제’가 포함된 파편화된 코드 스니펫 몇 개를 던져주고 끝날 겁니다. 하지만 EdgeQuake는 인덱싱 단계에서 이미 ‘결제 모듈(Entity)’이 ‘알림 서비스(Entity)’를 ‘호출(Relationship)’한다는 지식 그래프를 구축해 두었기에 정확한 맥락을 추적합니다.
여기에 최근 4.0 업데이트로 내장된 PDF Vision Pipeline (Embedded pdfium) 기능을 활용하면, 스캔된 아키텍처 다이어그램이나 복잡한 표가 포함된 PDF 문서까지 시각-언어 모델(VLM)을 통해 노드로 연결해 냅니다. 더 나아가, 제공되는 MCP (Model Context Protocol) 서버 기능을 통해 Claude나 Cursor 같은 AI 에이전트와 직접 연동할 수 있습니다. 에이전트가 코딩을 하다가 막히면, 스스로 EdgeQuake의 지식 그래프를 탐색해 도메인 컨텍스트를 주입하는 환상적인 워크플로우가 완성됩니다.
5. Honest Review: 도입 전 반드시 알아야 할 진짜 단점
엔지니어링에 은탄환은 없습니다. 극찬을 늘어놓았지만, 이 기술을 프로덕션에 도입하려 한다면 반드시 각오해야 할 뼈아픈 트레이드오프(Trade-off)가 있습니다.
- 무자비한 초기 인덱싱 비용 (API Cost): 문서를 청크로 나눈 뒤, 모든 청크마다 LLM을 호출해 엔티티와 관계를 추출해야 합니다. 심지어 ‘Gleaning’ 기능으로 2번씩 훑기도 하죠. 수만 장의 사내 문서를 인덱싱하려고 GPT-4o나 Claude 3.5 Sonnet 같은 무거운 모델을 무턱대고 사용했다가는, 클라우드 비용 청구서를 보고 문자 그대로 ‘Quake(지진)’를 경험하게 될 겁니다. 초기 구축 시에는 상대적으로 저렴한 모델이나 로컬 모델(Ollama 연동 지원)로 파이프라인을 타협하는 작업이 필수적입니다.
- 그래프 튜닝의 난해함 (Garbage In, Garbage Out): 엔티티 추출 프롬프트가 도메인에 완벽히 맞지 않으면, 아무 의미 없는 노드(“것”, “사항”, “해당 문서”)가 그래프를 뒤덮어버립니다. 도메인에 특화된 프롬프트 엔지니어링과 정규화 룰을 세팅하는 데 상당한 시행착오가 필요합니다.
- 가파른 러닝 커브: Rust 언어 자체의 진입장벽과 더불어, PostgreSQL의 AGE 확장 및 pgvector를 동시에 다루는 인프라 구성은 파이썬 생태계에만 익숙한 데이터 사이언티스트들에게 트러블슈팅의 난이도를 급격히 높이는 요인이 될 수 있습니다.
6. Closing Thoughts: 엔지니어링의 본질로 돌아가다
EdgeQuake는 “LLM 컨텍스트 윈도우가 커졌으니 텍스트를 통째로 쑤셔 넣으면 다 알아서 해주겠지”라는 나이브한 접근에서 벗어나, “우리가 데이터를 어떻게 구조화하여 LLM에게 떠먹여 줄 것인가”라는 시스템 아키텍처의 본질로 돌아가게 해주는 훌륭한 프로젝트입니다.
단순한 1차원적 RAG의 시대는 저물고 있습니다. 이제 AI 시스템은 문서를 단순 조회하는 것을 넘어, 개념을 ‘연결’하고 ‘추론’하기 시작했습니다. 만약 여러분의 팀이 환각 현상(Hallucination)과 파편화된 검색 결과 사이에서 길을 잃고 있다면, 이번 주말을 활용해 EdgeQuake의 make dev 명령어를 돌려보시길 권합니다. 터미널 위로 쏟아지는 깔끔한 Rust의 빌드 로그와, 프론트엔드 UI를 통해 눈앞에 펼쳐지는 지식의 거미줄을 보는 순간, 여러분의 RAG 아키텍처에 대한 고민도 새로운 돌파구를 찾게 될 것입니다.
References
- https://github.com/raphaelmansuy/edgequake
- https://medium.com/codex/why-classic-rag-doesnt-work-and-what-to-do-about-it-by-raphael-mansuy-126
- https://dasroot.net/architecting-rag-pipelines-in-rust
- https://sjramblings.io/building-your-own-ai-agent-stack-lessons-from-10-open-source-projects
