Grafeo 리뷰: Rust로 짠 초고속 그래프 DB, 그런데 이제 AI 코딩을 곁들인

그래프 데이터베이스(Graph Database)는 엔지니어들에게 일종의 애증의 대상입니다. 복잡한 관계 데이터를 쿼리할 때는 마법처럼 보이지만, 프로덕션 스케일로 넘어가고 노드 수가 억 단위로 넘어가기 시작하면 n^3의 지옥에 빠지기 십상이죠. 최근 Hacker News에서 흥미로운 프로젝트 하나가 눈에 띄었습니다. Rust로 작성된 초고속 내장형(embeddable) 그래프 DB, Grafeo 입니다.

스펙만 보면 완벽한 최신 DB 아키텍처

공식 문서가 주장하는 스펙은 가히 환상적입니다. LDBC 벤치마크 1위를 기록했으며, 최근 OLAP 및 HTAP 데이터베이스 씬에서 유행하는 모든 최적화 기법을 때려 넣었습니다.

  • Morsel-driven parallelism: 파이프라인 브레이커를 최소화하고 멀티코어를 극한으로 활용하는 실행 모델입니다.
  • Columnar storage & Zone maps: 데이터를 컬럼 기반으로 압축하고, 불필요한 I/O를 건너뛰는(Data skipping) 현대적인 접근법입니다.
  • MVCC & Snapshot Isolation: 단순한 장난감이 아니라 ACID 트랜잭션을 지원합니다.

게다가 GQL, Cypher, GraphQL 등 다양한 쿼리 언어를 지원하며, LPG(Labeled Property Graph)와 RDF 모델을 동시에 품고 있습니다. 백엔드 생태계에서 사랑받는 Rust로 작성되어 메모리 안전성까지 챙겼죠.

다음은 파이썬으로 작성된 간단한 사용 예시입니다. 임베디드 모드로 동작하는 모습이 DuckDB를 연상케 합니다.

import grafeo

# 인메모리 DB 생성
db = grafeo.GrafeoDB()

# 노드 및 엣지 생성
db.execute("""
INSERT (:Person {name: 'Alix', age: 30})
INSERT (:Person {name: 'Gus', age: 25})
""")

db.execute("""
MATCH (a:Person {name: 'Alix'}), (b:Person {name: 'Gus'})
INSERT (a)-[:KNOWS {since: 2024}]->(b)
""")

# 그래프 쿼리
result = db.execute("""
MATCH (p:Person)-[:KNOWS]->(friend)
RETURN p.name, friend.name
""")

for row in result:
    print(f"{row['p.name']} knows {row['friend.name']}")

1주일에 20만 줄의 커밋? 코끼리를 삼킨 보아뱀

하지만 Hacker News 스레드를 뜨겁게 달군 건 아키텍처의 우수성이 아니었습니다. 커밋 히스토리를 뜯어본 엔지니어들이 경악할 만한 사실을 발견했기 때문입니다. 단일 컨트리뷰터가 프로젝트 초기 일주일 만에 무려 20만 줄 의 코드를 푸시했습니다.

이게 무엇을 의미할까요? 십중팔구 LLM(GenAI)을 극한으로 활용해 생성해 낸 결과물이라는 뜻입니다.

저는 AI 어시스턴트를 활용한 코딩을 적극 찬성하는 편입니다. 하지만 데이터베이스 엔진 은 다릅니다. DB 엔진은 수많은 edge case, 동시성 문제, 쿼리 옵티마이저의 미묘한 버그들이 숨어있는 지뢰밭입니다. LLM이 최신 논문을 바탕으로 그럴싸한 아키텍처와 보일러플레이트를 찍어낼 수는 있지만, MVCC의 미묘한 Race condition이나 복잡한 Join 순서 최적화 문제를 꼼꼼하게 설계하고 검증했을 리 만무합니다.

HN의 한 유저가 남긴 코멘트가 제 생각을 정확히 대변합니다. “그래프 데이터베이스 엔진은 정교한 설계 없이는 수많은 날카로운 모서리(sharp edges)를 숨기고 있는 것으로 악명 높습니다. 여기에 필요한 수준의 디테일한 주의가 기울여졌는지 전혀 명확하지 않아요.”

쏟아지는 그래프 DB, 우리는 어떻게 대응해야 할까

최근 AI와 LLM 트렌드에 편승해 수많은 그래프 DB와 벡터 DB들이 쏟아져 나오고 있습니다. Kuzu, LadybugDB 등 DuckDB의 내부 구조를 차용해 관계형 스토리지의 한계를 극복하려는 시도들도 활발하죠.

Grafeo는 ‘LLM을 활용해 혼자서 어디까지 거대한 시스템을 부트스트랩 할 수 있는가’를 보여주는 놀라운 기술 데모임은 틀림없습니다. 하지만 당장 내일 프로덕션에 이걸 올리겠냐고 묻는다면, 제 대답은 ‘절대 아니오’입니다.

만약 여러분의 서비스에서 당장 그래프 분석이 필요하다면 어떻게 해야 할까요? 새로운 하이프(Hype)에 휩쓸리기보다는, 메인 데이터는 Postgres에 안전하게 보관하고, 복잡한 그래프 알고리즘 분석이 필요할 때만 데이터를 서브셋으로 추출해 Grafeo나 Kuzu 같은 임베디드 DB에 올려서 분석하는 방식을 추천합니다. 신기술은 이렇게 격리된 환경에서 찍어 먹어보는 것이 엔지니어의 올바른 생존 방식입니다.

References