지속적인 메모리를 구현하려다 발견한 코드베이스 최적화 방법
I was trying to build persistent memory but ended up with this!
핵심 요약
코드베이스 탐색 비용을 줄이기 위해 지식 그래프 기반의 사전 주입 방식을 도입한 GrapeRoot 개발기.
- 비용 최적화 — 코드베이스를 반복해서 읽는 대신 지식 그래프를 활용해 API 호출 비용을 40~60% 절감함.
- 사전 주입 방식 — 표준적인 컨텍스트 방식 대신 필요한 파일만 선별적으로 주입하여 LLM의 효율을 높임.
- 성능 벤치마크 — 엔터프라이즈급 비동기 호출 환경에서 기존 Claude Code 대비 품질과 비용 면에서 우위를 점함.
- 오픈소스 공개 — 개발한 도구를 GitHub에 공개하여 누구나 코드베이스 탐색 효율을 개선할 수 있도록 함.
GrapeRoot라는 도구를 만들고 있었어. Claude Code를 엄청나게 사용하고 있었는데, 핵심 아이디어는 LLM이 내 코드베이스를 한 번만 파악하게 해서 계속해서 다시 읽지 않게 만드는 거였지. 그런데 LLM이 실제로 어떻게 작동하는지, 그리고 Claude Code가 컨텍스트를 어떻게 처리하는지 배우고 나니, 이걸 최적화할 방법이 분명히 있어야겠다고 확신했어. 솔직히 코드베이스를 계속 다시 읽게 하려고 매달 200달러를 낼 수는 없잖아. 게다가 그 작업 비용의 거의 50~80%가 파일 찾는 데 들어가거든.
그래서 생각하기 시작했어. 만약 내가 직접 이 파일들을 검색해야 한다면 어떻게 할까? 그냥 모든 걸 grep으로 검색할까? 아니야. 검색을 열고, 개념을 중심으로 검색하고, 관련 파일을 검토하고, VSCode의 LSP를 통해 파일들이 서로 어떻게 연결되는지 따라가겠지. 거기서 지식 그래프 아이디어가 떠올랐고, 그 주변에 여러 MCP 도구를 만들었어. 이걸 Reddit에 올렸더니 빵 터졌지. 사람들이 해결하려고 했던 진짜 고통이 바로 이거였거든. 두 달이 지난 지금, 다른 도구들도 많이 나왔지만 대부분은 여전히 표준적인 방식을 사용하고 있고, 우리는 사전 주입(pre-injection) 방식을 써. 어떤 분이 이걸 아주 잘 분석해 줬어: https://ceaksan.com/en/pre-injection-vs-mcp-context-engineering
다들 제대로 하지 않는 방식으로 진짜 문제를 해결하는 기분이 정말 좋아. 엔터프라이즈급 비동기 호출에 대한 벤치마크도 진행했는데, 품질과 비용 면에서 우리가 더 나았어. 품질이 저하되어서는 안 된다는 걸 항상 인지하고 있었기에 비용에 제한을 두지 않았어. 코드베이스를 검색해야 한다면 제한이나 제약은 없어. 하지만 많은 작업에서 우리는 기존 Claude Code보다 일관되게 40~60% 낮은 비용을 보여주고 있어.
벤치마크는 여기서 볼 수 있어: https://graperoot.dev/benchmarks
문서: https://graperoot.dev/docs
Discord: https://graperoot.dev/
오픈소스 도구: https://github.com/kunal12203/Codex-CLI-Compact
