GitHub 트렌딩 Graft, 실측 결과는?

세션이 시작될 때 코딩 에이전트는 코드베이스에 대한 아무런 정보도 가지지 못하며, 오직 규칙 파일 및 하네스 정의만 참조한다.

이러한 구조는 그랩(grep), 리드(read), 배시(bash)와 같은 도구를 활용하여 루프 탐색 방식으로 코드베이스를 이해하게 만든다.

결과적으로 대화 턴이 늘어날수록 입력 토큰량이 비례하여 증가하는 오버헤드가 발생한다.

이는 세션이 종료될 때 기존 코드 탐색 결과가 삭제되기 때문이며, 다음 세션에서 코드베이스 탐색을 0부터 다시 시작해야 하는 비효율을 초래한다.

이 지식 그래프는 에이전트가 매 프롬프트마다 관련 맥락을 자동으로 주입할 수 있도록 하며, 이를 통해 코드 탐색의 반복을 줄이고 효율성을 높인다.

Graft는 별도의 그래프 DB나 벡터 DB를 필요로 하지 않는 경량 아키텍처를 가진다.

폴더 구조는 소스 코드를 그대로 따라가는 형태로, Graft 폴더 내부에는 소스 파일 하나당 마크다운 파일 하나가 1:1 구조로 생성된다.

이 마크다운 파일에는 함수와 클래스의 위치 정보가 줄 단위로 기록되며, 실제 소스 코드 대신 이 마크다운 파일을 조회하여 코드 정보를 얻는다.

실제 Graft 빌드 시 마크다운 파일 508개가 생성되었으며, JSON 파일을 통해 노드(node) 개수는 2,851개, 엣지(edge) 개수는 9,094개가 만들어진 것을 확인했다.

Graft는 마크다운 파일로 코드베이스를 매핑하여 지식 그래프를 구성한다.

'이 함수를 누가 부르냐'와 같이 관계를 묻는 질문에는 그래프의 엣지를 따라가며 탐색하고, 그 외의 내용에 대한 질문은 특정 단어들의 겹침을 기반으로 순위를 매긴다.

이러한 방식은 LLM을 사용하지 않아 검색 속도가 빠르며, 결과가 일관적이라는 장점이 있다.

지식 그래프 생성은 두 가지 층으로 이루어진다.

첫 번째 층은 트리시터(Tree-sitter)를 사용하여 함수, 클래스, 호출 관계 등 코드 구조만을 분석하며, LLM 모델을 사용하지 않으므로 별도의 비용이 발생하지 않는다.

두 번째 층은 `--deep` 옵션을 부여했을 때 활성화되며, 이 경우 LLM이 파일을 요약하고 서브 시스템 단위로 묶어 마크다운 노드를 생성하는 방식으로 동작한다. Graft는 또한 작업 트리 변경 사항을 실시간으로 비교하고 업데이트하는 기능을 제공한다.

Graft는 툴콜(tool call)을 46% 더 적게 사용하고, 토큰 사용량도 42% 감소시키며, 작업 시간을 60% 절약할 수 있다고 주장한다.

또한, 정확도(Correctness) 면에서도 54%에서 66%로 개선되는 효과를 기대할 수 있다고 제시한다.

구체적으로 세션 시작 시 코드베이스 요약을 제공하고, 프롬프트 제출 시 관련 노드를 뒷단에 추가한다.

또한, 도구 사용 직후 영향력을 분석하고, 세션 종료 시 그래프를 재빌드하는 방식으로 작동하여 코딩 에이전트의 효율을 극대화한다.

커밋 대상에는 훅 파일과 스키마 파일만 포함되며, 로컬 캐시는 제외된다.

이는 로컬 환경별로 개별적인 빌드 방식을 사용하도록 설계되었기 때문이다.

Graft를 설치하고 초기화하면 기본적으로 텔레메트리(telemetry) 기능이 활성화되는 구조로 되어 있다.

그러나 기업 코드나 보안에 민감한 정보가 유출될 위험이 있으므로, 개발자는 텔레메트리 기능을 비활성화하고 Graft를 사용할 것을 권장한다.

Graft 설치 후 텔레메트리 기능을 비활성화하려면 `graft telemetry disable` 명령어를 입력하면 된다.

Graft 벤치마크를 위해 두 가지 유형의 프로젝트를 구성했다.

첫 번째는 약 2,000줄 규모의 유튜브 분석 CLI 도구이며, 두 번째는 약 10만 줄 규모의 영상 편집 앱 프로젝트이다.

모든 테스트 조건에서 LLM 모델은 Claude 3.5 Sonnet으로 고정하여 진행했다.

과제 A는 다중 파일 흐름에 대한 질문으로, '레포트 명령이 어떤 파일을 거쳐 실행되는가'를 물었다.

과제 B는 함수 시그니처 변경 시 영향 범위를 탐색하는 과제였고, 과제 C는 특정 단일 파일의 작은 범위 수정에 관한 과제였다.

툴콜 감소 실측 결과, 작은 프로젝트에서는 Graft를 사용하지 않았을 때 7회였던 툴콜이 3.6회로, 3.8회였던 것이 1.8회로 줄어들었다.

큰 프로젝트에서도 19회에서 14회, 2회에서 1.2회로 감소하는 경향을 보였다.

이 네 가지 케이스를 종합했을 때 평균적으로 41%의 툴콜 감소가 확인되었으며, 이는 Graft가 주장한 46% 감소 수치와 대체로 유사한 결과이다.

시간 감소 성능을 확인한 결과, 작은 프로젝트에서는 34초가 26초로, 21초가 12초로 줄어들어 Graft 적용 시 시간이 감소했다.

그러나 큰 프로젝트에서는 오히려 시간이 늘어나는 패턴을 보였다.

예를 들어 15초가 걸리던 것이 26초로, 75초가 걸리던 것이 95초로 증가하여, 큰 프로젝트에서는 Graft 적용 시 시간이 그대로거나 조금 더 늘어나는 경향을 확인했다.

Graft 적용 여부와 관계없이 정답률은 비슷하거나 약간 낮은 수준을 보였다.

이는 Graft가 에이전트를 더 똑똑하게 만들기보다는, 기존의 파일 전체 읽기 방식을 그래프 조회 방식으로 개선하여 에이전트의 효율성을 높이는 보조 도구로서 적합하다는 결론을 뒷받침한다.

최종적으로 Graft가 주장한 툴콜 감소와 정답률은 벤치마크 수치에서 어느 정도 재현되었지만, 시간 감소 효과는 프로젝트 규모에 따라 차이를 보였다.