파일별 LLM 그래프 vs 벡터 임베딩: 코드 검색 정밀도 비교

AI 코딩 도구를 위한 코드 인덱싱 시스템을 구축한 1년간의 실험에서 명확한 결과가 나왔습니다. 코드 청크의 벡터 임베딩과 Tree-sitter AST 파싱은 모두 치명적인 결함이 있는 반면, Neo4j 그래프에 저장된 파일별 LLM 분석과 의미론적 전문 검색이 가장 효과적이었습니다. 이 결과는 RepoGraph(ICLR 2025) 및 Code-Craft와 같은 최근 논문과 일치합니다.

테스트된 접근법

코드 청크의 벡터 임베딩 – 완전히 폐기됨. 결제 서비스의 process() 함수와 이미지 파이프라인의 process() 함수는 서로 전혀 관련이 없음에도 유사한 벡터로 임베딩됩니다. 벡터는 호출 그래프, 상속, 임포트 등 모든 구조적 관계를 평탄화합니다. 검색 정밀도는 용납할 수 없었습니다.
Tree-sitter AST 파싱 – 정확하고 빠르지만 구조적 정보만 제공합니다. 함수가 존재하고 무엇을 호출하는지는 알 수 있지만, "이 함수는 실패한 Stripe 결제에 대한 웹훅 재시도를 처리합니다"와 같은 질문에는 답할 수 없습니다. 개발자가 비즈니스 언어로 질문할 때 부족함이 드러납니다.
파일별 LLM 분석 → 그래프 – 효과적입니다. 각 파일에 대해 LLM 호출로 purpose, summary, businessContext를 생성하고, 이를 Neo4j의 노드로 저장하며 클래스, 함수, 키워드, 임포트와의 엣지를 추가합니다. 검색은 벡터 유사도 대신 이러한 의미론적 필드에 대한 전문 검색을 사용합니다. SHA-256 diffing으로 변경된 파일만 재인덱싱하여 초기 비용을 관리 가능하게 만듭니다.

문헌의 벤치마크

RepoGraph(ICLR 2025)는 그래프 접근법으로 SWE-bench에서 +32.8% 향상을 보였습니다. Code-Craft는 코드 그래프의 상향식 LLM 요약을 사용하여 상위 1개 검색 정밀도에서 +82%를 달성했습니다.

기존 도구와의 비교

팀은 comparison.md에 상세 비교를 게시했습니다. 주요 차이점:

Bytebell: 파일별 LLM → purpose + summary + businessContext + entities; Neo4j + MongoDB 저장소; SHA-256 diff 인식 재인덱싱.
PageIndex: 긴 PDF/문서를 위한 TOC 추론 트리; 코드별 의미론 없음.
GitNexus: Tree-sitter AST + 커뮤니티 탐지; 선택적 심볼별 의미론; LadybugDB 사용.
GraphRAG: 일반 텍스트(코드 아님)를 위한 청크별 LLM 엔티티 + 커뮤니티 클러스터링.
Sourcegraph/Cody: LSIF/SCIP 검색 인덱스; 노드별 의미론 없음; 배포는 자체 호스팅 또는 SaaS.
Augment: 임베딩을 사용한 독점적 의미론 인덱스; SaaS 전용; 지속적 인덱싱 관리.