Graphicle 0.1.0: Graphify의 Rust 포트로, 코딩 에이전트를 위한 코드 그래프와 메모리 추가

Graphicle은 저장소의 코드 그래프를 구축하고 프로젝트 메모리(문서, 결정 사항, 과거 에이전트 세션)를 저장한 다음, MCP를 통해 코딩 에이전트에게 인용된 발췌문을 제공하는 단일 Rust 프로그램입니다. Graphify 코드 그래프 엔진의 Rust 포트에 메모리 계층, 앱, 세션 캡처를 추가한 것으로, Apache-2.0 라이선스로 배포되며 KarLex AI, Inc.가 게시했습니다.

이 프로젝트는 Hacker News에 Show HN으로 게시되어 32포인트와 9개의 댓글을 받았습니다. 토론은 빈약했습니다. 9개의 댓글 중 3개는 플래그 처리되었고, 나머지 실질적인 댓글은 이러한 종류의 메모리 시스템이 ripgrep을 사용하는 일반 에이전트 하네스보다 나은지 의문을 제기했습니다.

Graphicle이 하는 일

Graphicle은 일반적으로 별도의 도구인 두 가지 기능(코드 그래프와 메모리 저장소)을 결합합니다. 코드 그래프는 파일, 함수, 클래스, 호출, 가져오기를 다루며 tree-sitter로 파싱하고 모델을 사용하지 않습니다. 메모리 저장소는 Markdown, PDF, Office, HTML 문서, 검토된 결정 사항과 절차, 과거 Claude Code 및 Codex 세션을 다룹니다.

둘 다 함께 검색할 수 있습니다. graphicle context와 MCP 도구는 모델을 호출하지 않고 토큰 예산 내에서 출처와 함께 발췌문을 반환합니다. 모든 발췌문은 파일 이름과 줄 범위를 명시합니다.

README의 실제 예시로, graphicle ask "where is tax added to prices?"를 물으면 3,000토큰 중 598토큰에 해당하는 4개의 인용된 발췌문을 반환합니다. 첫 번째는 shop/pricing.py:1-7, price_with_tax() 함수입니다.

설치 및 설정

설치 경로는 Homebrew 또는 셸 스크립트입니다:

brew install graphicle-ai/tap/graphicle
cd your-repo
graphicle setup

Homebrew가 없으면 README는 curl -fsSL https://github.com/graphicle-ai/graphicle/releases/latest/download/install.sh | sh를 제공합니다. 아직 네이티브 Windows 빌드는 없습니다. README는 Linux 설치가 WSL2에서 작동해야 하지만 테스트되지 않았으며, 네이티브 Windows 지원이 계획되어 있다고 명시합니다.

graphicle setup은 저장소를 인덱싱하고, 코드 그래프를 구축하고, 찾은 코딩 에이전트를 연결하고, 세션 캡처를 켜고, Claude Code의 검색이 먼저 코드 그래프를 가리키도록 하고, AGENTS.md에 짧은 섹션을 추가하고, 프로젝트를 최신 상태로 유지하는 Git 훅을 설치합니다. 변경하는 모든 파일을 나열하고 각 파일을 먼저 <file>.graphicle-bak으로 백업합니다. graphicle disconnect는 setup이 수행한 모든 것을 되돌립니다.

README에 문서화된 다른 명령으로는 터미널 질문용 graphicle ask, 그래프·소스·메모리의 브라우저 보기용 graphicle open, 상태 점검용 graphicle doctor, 심볼에 의존하는 항목을 나열하는 graphicle graph extract . --code-only 후 graphicle graph affected "retry()", 코드 언급과 정의 간의 링크를 나열하는 graphicle call graph.doc_links가 있습니다.

벤치마크: Graphify 대비 속도

약 31,000개 파일의 Kubernetes에서 Graphicle 0.1.0 엔진은 코드 전용 추출을 3분 18초에 실행했고, Graphify 0.9.88은 26분 38초가 걸렸습니다. 둘 다 동일한 그래프(256,329노드, 1,400,392엣지)를 구축했습니다. README는 이를 각각 한 번의 탐색적 실행으로, 동일한 16 CPU와 8 워커를 사용하는 하나의 Linux 호스트에서 수행했으며, 0.1.0 엔진은 릴리스 소스의 Linux 테스트 빌드였다고 설명합니다.

Django에서의 이전 비교는 Graphicle의 사전 릴리스 빌드가 코드 전용 추출에 7.5초, Graphify 0.9.77이 72.8초가 걸렸다고 측정했습니다. 이 수치는 8 워커를 사용하는 하나의 공유 Linux 호스트에서 5회 교대 실행의 중앙값이며, 두 도구 모두 동일한 그래프를 구축했습니다.

벤치마크: 7개 메모리 시스템 대비 메모리

README는 7개 메모리 시스템과의 비교를 보고합니다. 이 비교는 어떤 답변도 채점되기 전에 등록되었고, 하나의 공개 모델이 모든 시스템의 읽기 및 판정 역할을 수행했습니다. Graphicle의 사전 릴리스 빌드는 해당 비교에서 "세 가지 개발 세트에서 어떤 것에도 뒤처지지 않습니다". README는 전체 점수와 방법 및 주의 사항을 링크합니다.

코드 심볼에 고정된 메모리

Graphicle의 독특한 설계 선택은 검토된 메모리가 관련된 함수에 묶여 있다는 것입니다. 해당 코드가 변경되면 메모리는 오래되지만, 같은 파일의 다른 곳을 편집하면 일반적으로 메모리는 최신 상태로 유지됩니다. README는 크레이트 문서의 정확한 규칙을 링크합니다.

Hacker News 댓글 작성자 dmos62는 이 점을 프로젝트의 가장 중요한 부분으로 지목하며 메모리 시스템의 오랜 문제를 해결한다고 주장했습니다:

메모리를 코드 조각(예: 함수)에 묶는 무효화 방식이 여기서 핵심이라고 생각합니다. 하지만 왜 전면에 내세우지 않았는지 이해는 됩니다. 저는 항상 메모리 시스템이 불편했습니다. 메모리가 여전히 유효한지 판단하기 어렵기 때문입니다. 또한 발견 가능성도 항상 문제입니다(메모리가 언제 관련이 있는지). 코드 그래프와 메모리 시스템(겉보기에 관련 없는 것들)을 결합한 이 방식은 실제로 이 문제를 새롭게 해결합니다.

에이전트가 제안한 메모리는 자동으로 적용되지 않습니다. 앱에서 승인을 기다리며, graphicle open이 바로 그곳으로 안내합니다.

아키텍처: 하나의 프로그램, 하나의 SQLite 파일

Graphicle은 코드 그래프, 메모리, 하나의 MCP 서버, 웹 앱, 명령줄을 하나의 설치로 제공하며 하나의 SQLite 파일로 지원합니다. README는 이를 일반적인 대안(코드 그래프 도구 + 메모리 서버, 일반적으로 서로 다른 런타임의 두 도구, 각 에이전트에 별도로 구성된 두 MCP 서버, 별도 저장소)과 대조합니다.

MCP 서버는 graphicle mcp로 시작되며, 메모리 도구와 함께 Graphify의 도구 이름(query_graph, get_neighbors, shortest_path 포함)으로 코드 그래프 도구를 제공합니다. 워크스페이스에서 여러 저장소에 걸친 검색은 graphicle context --workspace 또는 워크스페이스 MCP 엔드포인트를 통해 가능합니다.

소스는 세 개의 크레이트로 나뉩니다: 프로그램(명령줄, 앱, HTTP 및 MCP 서버)용 crates/graphicle/, 코드 그래프 엔진용 crates/graphicle-graph/, 메모리 라이브러리용 crates/graphicle-memory/. Python 및 TypeScript SDK가 포함되며 deploy/에 팀 서버 레시피가 있습니다. 각 크레이트는 독립적으로 빌드됩니다.

클라이언트 지원

graphicle setup은 찾은 모든 클라이언트를 MCP로 연결합니다. README에 따르면 연결 지점은 다음과 같습니다:

클라이언트	setup이 연결하는 위치	세션 캡처
Claude Code	저장소의 .mcp.json	.claude/settings.local.json의 훅
Codex	~/.codex/config.toml	~/.codex/hooks.json의 훅 (Codex가 신뢰를 요청함)
Cursor	~/.cursor/mcp.json	—
VS Code	저장소의 .vscode/mcp.json	—
Claude Desktop	Claude 설정 폴더의 claude_desktop_config.json	—
기타 MCP 클라이언트	짧은 JSON 항목	—

개인정보 보호 및 로컬 우선 동작

Graphicle은 계정이 필요 없고 텔레메트리를 보내지 않습니다. 소스, 메모리, 코드 그래프는 macOS의 ~/Library/Application Support/Graphicle 및 Linux의 ~/.local/share/graphicle에 있는 하나의 SQLite 저장소에 저장됩니다. graphicle graph extract는 그래프 파일을 프로젝트의 .graphicle/에 씁니다. 앱과 HTTP 및 MCP 엔드포인트는 기본적으로 127.0.0.1에서 수신합니다.

README는 Graphicle이 네트워크에 연결하는 경우를 나열합니다: 사용자가 구성한 모델 또는 커넥터, 전체 graphicle graph extract(찾은 API 키를 사용하는 LLM에 문서와 이미지를 보냄), graphicle graph add, clone 및 그래프 서버의 풀 리퀘스트 도구용 GitHub CLI, 그리고 사용자가 지정한 피드로 graphicle update. 소스에서 빌드하면 파서 소스도 한 번 다운로드합니다.

동기화는 .gitignore를 존중하고 .env 파일, 키, 자격 증명을 건너뜁니다. 세션 캡처는 <private>…</private> 범위를 제거하고 자격 증명을 편집합니다. 메모리 또는 캡처된 세션을 삭제하면 파생된 항목도 제거되고 해시 체인 삭제 영수증이 생성됩니다.

모델이 필요한 것과 그렇지 않은 것

코드 그래프(--code-only), 동기화, context, MCP 서버, 세션 캡처 또는 앱에는 API 키나 모델이 필요 없습니다. graphicle ask의 답변 작성, 소스에서 메모리 제안, 전체 graphicle graph extract 중 문서 및 이미지 읽기에는 모델이 필요합니다.

모델은 graphicle config set model anthropic, openai 또는 ollama로 구성됩니다. Ollama 또는 OpenAI 호환 서버를 통한 로컬 모델이 지원됩니다. 모델이 구성되지 않으면 graphicle ask는 작성된 답변 대신 검색된 증거를 계속 표시합니다.

제한 및 라이선스

기본적으로 프로젝트는 최대 100,000개의 텍스트 파일과 1GiB의 텍스트를 보유할 수 있으며 두 제한 모두 높일 수 있습니다. 매우 큰 파일은 부분적으로 분석되거나 동기화를 중단하는 대신 검색 가능한 텍스트로 유지됩니다.

Graphicle은 Apache-2.0이며 무료로 사용, 수정, 상업적 배포가 가능합니다. 코드 그래프 엔진은 Safi Shamsi와 Graphify 기여자들의 Graphify를 Rust로 포팅한 것으로, Graphify 릴리스와 보조를 맞추고 파일 헤더와 NOTICE 파일에 크레딧을 명시합니다. 패리티 검사는 따르는 릴리스를 명명합니다. 메모리, 메모리 도구, 앱, 세션 캡처는 Graphify의 일부가 아닙니다. Graphify에서의 마이그레이션이 지원됩니다: graphicle setup은 저장소 전환을 제안하고 각 파일을 백업하며 graphify-out/을 절대 삭제하지 않습니다.

기여는 Apache-2.0에 따라 Developer Certificate of Origin 서명(git commit -s)으로 수락되며 CLA는 없습니다. 팀용 상용 에디션은 비공개 미리 보기 중입니다.

Hacker News 토론이 의문을 제기한 것

스레드에서 가장 실질적인 반론은 댓글 작성자 theLiminator의 것으로, 자신의 테스트에서 메모리 시스템이 더 단순한 기준선보다 성능이 떨어졌다고 보고했습니다:

실제로 이걸로 좋은 결과를 얻은 사람이 있나요? 제가 실행한 평가(과학적이지는 않지만)에서 이러한 메모리 시스템은 ripgrep이 있는 원시 하네스보다 성능이 나빴습니다.

댓글 작성자 pjm331은 그 주장 뒤에 있는 방법론적 질문을 던졌습니다:

에이전트에게 이런 종류의 도구를 주는 평가를 실행하는 사람이 누구이며 어떻게 하고 있나요?

스레드에서 아무도 두 질문에 답하지 않았습니다. 댓글 작성자 blackspacx는 벤치마크가 어떻게 유지되는지와 도구가 AI 지원으로 작성되었는지 물었지만, 보이는 댓글에서 답변되지 않았습니다. 제출자 계정 KarLexAI의 댓글을 포함한 나머지 댓글은 플래그 처리되었습니다.

스레드에서 얻은 실질적인 교훈은 프로젝트 자체 메모리 벤치마크(7개 시스템, 하나의 공개 모델이 읽기 및 판정, 채점 전 등록)가 지금까지 제시된 유일한 평가 증거이며, ripgrep-플러스-하네스 기준선에 대한 독립적 재현이 공개적으로 입증되지 않았다는 것입니다.