Graft 토큰 42% 절감 직접 실측: Claude Code 코드 지식 그래프는 어디서 효과가 있나

GitHub 트렌딩에 올라온 Graft는 Claude Code 같은 코딩 에이전트의 토큰을 42% 줄여준다고 소개되는 오픈소스입니다. 에이전트가 세션마다 처음부터 하던 코드베이스 탐색을 코드 지식 그래프로 한 번 만들어 두고, Claude Code 훅으로 매 프롬프트에 끼워 넣는 방식이죠. 결론부터 말하면, 이 42%는 조건에 따라 맞기도 하고 틀리기도 합니다.

제 프로젝트 두 개로 직접 재보니 툴콜(tool call, 도구 호출) 횟수와 정답률은 Graft README의 벤치마크 수치가 어느 정도 재현됐습니다. 반면 토큰과 시간 절감은 프로젝트 크기와 작업 무게에 따라 갈렸습니다.

이 글에서는 Graft의 동작 원리와 훅 배선, 설치 방법을 먼저 보고, README 주장 네 가지를 실측으로 하나씩 판정한 뒤, 어떤 작업에 붙이면 좋을지 기준을 정리하겠습니다.

Graft 토큰 절감 실측 핵심 요약

• Graft는 Nanonets가 공개한 MIT 라이선스 오픈소스 CLI입니다. 코드베이스를 tree-sitter로 한 번 읽어 폴더 하나짜리 지식 그래프(JSON 하나와 소스 파일별 마크다운)를 만들고, Claude Code 훅 네 시점에서 관련 맥락을 밀어 넣습니다.
• README의 툴콜 46%, 토큰 42%, 시간 60%는 같은 파일 도구를 쓰는 Claude Sonnet 5 에이전트를 자체 측정 하네스에서 cold와 비교한 값입니다. 정답률 54% → 66%는 SWE-bench Verified 50건으로 따로 잰 결과라, 한 표에 있어도 출처가 다릅니다.
• 툴콜과 정답률은 대체로 재현됐습니다. 탐색형 과제에서 툴콜이 평균 41% 줄었고, 정답률이 크게 떨어진 과제는 없었습니다.
• 토큰과 시간은 조건부였습니다. 작은 프로젝트의 흐름·영향 범위 질문은 토큰이 39~50%, 비용이 20% 남짓 줄었고 시간도 줄었습니다. 큰 프로젝트는 시간이 그대로이거나 늘었고, 비용 감소까지 확인된 건 무거운 조사(토큰 27%, 비용 33%)였습니다.
• 고칠 파일이 정해진 작은 수정에는 그래프가 끼어들 여지가 적었습니다. 툴콜은 그대로였고 토큰은 3~13% 줄었습니다.
• Graft는 텔레메트리가 기본으로 켜져 있고, graft init에서 agents 연동을 고르면 홈 디렉터리의 Codex 설정까지 건드릴 수 있습니다. DO_NOT_TRACK=1로 설치하고 graft init --dry-run으로 쓸 파일부터 확인하는 걸 권합니다.

코딩 에이전트의 코드베이스 탐색이 비싼 이유

Graft가 왜 나왔는지부터 보겠습니다. Claude Code는 기본적으로 세션마다 코드베이스를 다시 뒤지는 구조입니다.

에이전트는 우리 코드베이스를 알고서 시작하지 않습니다. 세션이 열릴 때 알고 있는 건 CLAUDE.md, AGENTS.md 같은 규칙 파일과 스킬 정의 정도입니다. 실제 코드에 대한 맥락은 내장 도구로 찾아갑니다. Grep으로 파일 안의 글자를 찾고, Read로 파일 내용을 읽고, Bash로 터미널 명령을 실행합니다. 도구를 하나 부르고, 결과를 보고, 다음 도구를 정하는 루프를 돌다가 확신이 서면 그제야 코드를 수정하는 단계로 넘어갑니다.

여기서 비용은 크게 두 군데에서 생깁니다.

1. 헛짚은 호출이 쌓입니다. 첫 시도에 원하는 파일을 못 찾으면 호출이 계속 늘어납니다.
2. 도구 결과가 컨텍스트 윈도우에 그대로 쌓입니다. 파일 하나를 읽으면 그 내용 전체가 창 안에 들어오고, 다음 도구를 부를 때 지금까지 쌓인 컨텍스트를 요청에 다시 실어 보냅니다. LLM API가 기본적으로 그렇게 동작하니까요.

그래서 턴이 늘수록 한 턴에 보내는 양도 함께 커집니다. 제가 더 중요하게 보는 건, 이 문제는 더 좋은 모델을 써도 해결되지 않는다는 점입니다. 구조의 문제니까요.

게다가 세션을 닫고 새로 열면 이전 세션의 탐색 결과는 전부 사라지고, 다음 세션은 다시 0부터 시작합니다. Graft의 발상은 여기서 출발합니다. 에이전트가 처음 탐색한 결과를 세션 밖에 지식 그래프로 저장해 두자는 겁니다. 이런 도구 카테고리를 코드 지식 그래프(code knowledge graph)라고 부릅니다.

Graft는 어떤 도구인가

Graft는 Nanonets라는 회사가 2026년 7월에 공개한 오픈소스 CLI입니다. MIT 라이선스이고 npm으로 설치합니다. 제가 처음 살펴볼 때 GitHub 스타가 7,300개 정도였는데, 2026년 10월 3일 기준으로는 9,526개입니다. 기존 NanoNets/Graft 주소는 현재 trailhq/Graft 저장소로 연결됩니다. 공개 후 두 달 가까이 거의 이틀에 한 번꼴로 릴리스가 나왔고, 제가 실측할 당시 버전은 0.18, 2026년 10월 3일 기준 npm 최신 버전은 0.21.1입니다.

한 줄로 설명하면 이렇습니다.

코드베이스를 한 번 읽어서 지식 그래프를 만들어 두고, 에이전트가 프롬프트를 칠 때마다 그 그래프에서 필요한 맥락을 자동으로 꺼내 끼워 넣어 주는 도구입니다.

지식 그래프가 폴더 하나인 구조

보통 지식 그래프라고 하면 인프라가 따라옵니다. Neo4j 같은 그래프 DB를 띄우고, 벡터 DB에 임베딩을 넣고, 조회는 서버가 받는 구조가 일반적이죠. 다른 코드 지식 그래프 도구들도 비슷한 구조인 경우가 많습니다.

Graft는 이 부분이 단순합니다. 폴더 구조가 소스 코드를 그대로 따라가고, 소스 파일 하나에 마크다운 파일 하나가 1:1로 생성됩니다. 각 마크다운에는 어떤 함수, 어떤 클래스가 몇 번째 줄에 있는지가 한 줄씩 적혀 있고, 에이전트는 실제 소스 코드를 통째로 읽는 대신 이 마크다운을 읽습니다.

제가 만들고 있는 영상 편집 앱에 Graft를 빌드해 보니 마크다운이 508개 생성됐고, JSON 파일에는 노드 2,851개, 엣지 9,094개가 들어 있었습니다. 정리하면 Graft에는 서버도, 데이터베이스도, 임베딩도 없습니다. 폴더 하나에 JSON 파일 하나와 소스 코드에 매핑된 마크다운 파일 수십에서 수백 개가 전부입니다.

임베딩 없이 노드를 찾는 방법

그럼 임베딩 없이 질문에 맞는 노드를 어떻게 찾을까요. 두 갈래로 찾아갑니다.

• 관계를 묻는 질문: “이 함수를 누가 부르나”처럼 관계를 묻는 질문이면 그래프의 엣지를 따라갑니다.
• 그 외 내용 질문: 단어 겹침으로 순위를 매깁니다. 질문에 포함된 단어가 노드 이름과 요약에 얼마나 겹치는지를 보고, 그래프에서 많이 연결된 노드에 가산점을 줍니다. 검색엔진의 고전적인 방식과 비슷하죠.

노드를 고를 때 LLM을 쓰지 않고 결정론적으로만 판별하기 때문에 속도가 빠르고, 같은 질문에는 항상 같은 결과가 나옵니다.

두 개의 층과 신선도 유지

지식 그래프는 두 층으로 이루어져 있습니다.

층	만드는 방법	담기는 내용	비용
첫 번째 층	tree-sitter로 코드 구조 추출	함수, 클래스, 누가 누구를 부르는지	없음(LLM 미사용)
두 번째 층	--deep 옵션을 줬을 때 LLM이 생성	파일 요약, 서브시스템 단위로 묶은 마크다운 노드	LLM 호출 비용 발생(선택 옵션)

두 번째 층은 필수가 아니라 필요할 때만 켜면 됩니다. 노드 한 장에는 요약, 로직을 담은 몇 줄, 어느 파일에서 왔는지를 나타내는 해시, 다른 노드로 가는 링크가 들어갑니다.

신선도를 유지하는 장치도 있습니다. 노드를 조회할 때마다 마지막 빌드의 작업 트리 지문(fingerprint)과 현재 상태를 3ms 정도 들여 비교하고, 바뀐 파일만 다시 파싱합니다. 그래프가 코드와 어긋나 있을 걱정을 덜어주는 부분이죠.

Graft가 다른 코드 지식 그래프 도구와 다른 점: 훅 4시점 배선

제가 보기에 Graft가 다른 도구와 갈리는 지점은 그래프 자체가 아니라 그래프를 에이전트에 연결하는 배선입니다.

보통은 규칙 파일에 “이 그래프를 써라”라고 적어 두는 방식인데요. Graft는 에이전트의 훅 레벨에 끼어들어, Claude Code 라이프사이클의 특정 시점에 그래프 결과를 그냥 밀어 넣습니다. Claude Code나 Codex 같은 대부분의 코딩 에이전트에는 특정 이벤트 시점에 스크립트를 실행하는 훅 기능이 있고, Graft는 그중 네 시점에 끼어듭니다.

시점	Claude Code 훅 이벤트	Graft가 하는 일
세션 시작	SessionStart	코드베이스 요약을 바로 넣어 세션이 빈손으로 시작하지 않게 합니다
프롬프트 제출	UserPromptSubmit	입력한 문장으로 그래프를 조회해 관련 노드를 프롬프트 뒤에 붙입니다
도구 사용 직후	PostToolUse	방금 고친 파일의 영향 범위를 알려줍니다
응답 종료	Stop	백그라운드에서 그래프를 다시 빌드합니다

이 중 핵심은 두 번째, 프롬프트 제출 시점입니다. 에이전트가 Grep을 실행하기도 전에 어떤 코드를 봐야 하는지 답이 이미 들어가 있는 셈이니까요. 그리고 턴이 끝날 때마다 그래프를 다시 빌드하니, 다음 프롬프트는 최신 그래프를 바라보게 됩니다.

왜 MCP(Model Context Protocol)가 아니라 훅일까요. Graft 개발진의 설명으로는 Claude Code가 Grep 사용에 이미 잘 훈련돼 있어서, 새로 붙인 CLI나 MCP 도구를 잘 쓰지 않는다고 합니다. 그래서 에이전트가 고르게 두지 않고 훅으로 강제로 밀어 넣는 방식을 택했다는 거죠.

프로젝트에 Graft 붙이는 방법

순서는 설치, 텔레메트리 끄기, 미리 보기, 초기화입니다.

# 1. 텔레메트리를 끈 채로 설치
DO_NOT_TRACK=1 npm install -g @nanonets/graft

# 2. 이후 실행에서도 텔레메트리 끄기
graft telemetry disable

# 3. init이 건드릴 파일 목록만 출력 (아무것도 쓰지 않음)
graft init --dry-run

# 4. 초기화. 이 저장소에만 붙이려면 --no-global
graft init --no-global

graft init은 그래프를 빌드하고 .claude/ 폴더에 훅과 스킬을 써 줍니다. 빌드 결과가 담기는 graft/ 폴더는 .gitignore에 자동으로 등록됩니다. node_modules처럼 내 PC에만 있는 로컬 캐시라고 보면 됩니다.

커밋하는 건 init이 써 준 배선입니다. .claude/ 안의 훅과 스킬, MCP 설정이 여기에 해당하고, AGENTS.md를 읽는 에이전트까지 연결했다면 그 파일도 포함됩니다. 팀원은 pull 받은 뒤 graft build만 한 번 돌리면 각자 로컬에 그래프가 생깁니다.

--dry-run을 먼저 권하는 이유가 있습니다. AGENTS.md를 읽는 에이전트(agents) 연동을 고르면, ~/.codex/가 있을 때 홈 디렉터리의 Codex 설정에도 MCP 서버와 훅이 등록됩니다. 이 설정은 Codex로 여는 모든 저장소에 적용되고, --no-global은 이런 저장소 밖 쓰기를 건너뜁니다. 또 기본 graft init은 프로젝트의 .mcp.json에 Graft MCP 서버도 등록하니, 훅만 쓰고 싶다면 --no-mcp를 붙이면 됩니다.

Graft 텔레메트리 끄는 법

Graft를 설치하고 init하면 텔레메트리가 켜진 상태로 세팅됩니다. 도구 사용 통계를 Graft 쪽 서버로 보내는 기능입니다. 문서에는 코드나 파일 경로는 보내지 않고, 숫자는 전부 구간값(bucket), 문자열은 정해진 목록 안의 값으로만 보낸다고 적혀 있습니다. 그래도 회사 코드나 보안에 민감한 코드를 다룬다면 저는 끄고 쓰시는 걸 권합니다.

DO_NOT_TRACK=1은 앞에 붙인 그 명령에만 적용되니, 이후 실행은 graft telemetry disable로 꺼 둬야 합니다. graft init 선택 화면에서 익명 사용 통계 항목을 해제해도 되고, 현재 상태는 graft telemetry status로 확인합니다.

Graft README의 42%는 어떤 조건에서 나온 수치인가

실측에 들어가기 전에, 42%가 무엇과 비교한 숫자인지 짚어야 합니다.

README는 표의 두 열을 Cold Claude Code와 Claude Code with graft로 표기합니다. 실제 측정은 같은 파일 도구를 쓰는 Claude Sonnet 5 에이전트를 세 방식으로 돌린 자체 측정 하네스(벤치마크 실행 환경)에서 이뤄졌습니다. 처음부터 탐색하는 cold, graft ask --source 결과 묶음을 처음에 밀어 넣는 Graft, 아무것도 주입하지 않고 필요할 때만 Graft 도구를 부르는 pull입니다. 저장소 두 개(Graft 자체 저장소와 Node/Express 인증 서비스)에서 과제마다 세 번씩, 총 162런(run, 실행 1회)을 돌렸고, 아래 효율 수치는 이 중 cold와 Graft의 비교입니다.

README 주장	README 측정값	측정 방식
툴콜 46% 감소	과제당 평균 4.2회 → 2.3회	자체 측정 하네스
토큰 42% 감소	과제당 평균 8,070 → 4,650	자체 측정 하네스
시간 60% 감소	과제당 평균 39.8초 → 15.8초	자체 측정 하네스
정답률 54% → 66%	27/50 → 33/50	SWE-bench Verified 50건

여기서 눈여겨볼 건 마지막 행입니다. README 첫 화면에는 네 수치가 한 표로 묶여 있지만, 정답률 향상은 별도로 돌린 SWE-bench Verified 결과입니다. 같은 자체 측정 하네스 안에서는 정답률이 cold와 Graft 모두 93%로 같았고, 이 채점은 Claude Opus 4.8 판정 모델이 필수 키워드 기준을 두고 매겼다고 적혀 있습니다. SWE-bench Verified 쪽 효율 수치는 토큰 23%, 툴콜 25%, 시간 32% 감소로 첫 화면보다 폭이 작습니다.

실측 조건: 두 프로젝트, 과제 4종(A~C 5회, D 3회)

제 실제 프로젝트 두 개로 측정했습니다.

구분	프로젝트	규모
작은 프로젝트	유튜브 분석 CLI 도구	코드 2,000줄 정도
큰 프로젝트	영상 편집 앱	전체 10만 줄 정도

조건은 아무것도 붙이지 않은 cold와 Graft를 붙인 조건 두 가지이고, 모델은 Claude Sonnet 5로 고정했습니다. 외부 MCP는 끄고, Graft도 MCP 없이 훅과 스킬로만 붙였습니다. 과제 A, B, C는 조건마다 다섯 번, 큰 프로젝트에만 추가한 무거운 조사 과제 D는 세 번 돌려 평균을 냈습니다.

과제	유형	내용
A	다중 파일 흐름 질문	”report 명령이 어떤 파일을 거쳐서 실행되나”
B	영향 범위 조사	”이 함수 시그니처를 바꾸면 고쳐야 할 파일 범위를 다 나열해”
C	작은 단일 파일 수정	파일 하나의 특정 범위만 수정
D	무거운 조사	큰 프로젝트에만 추가(3회)

비교 기준: 절대값이 아니라 감소율

측정 단위부터 밝혀 두겠습니다. 토큰은 컨텍스트 토큰(context tokens) 기준이고, 정답률은 런마다 매긴 100점 만점 점수의 평균입니다.

절대값은 README와 비교하지 않습니다. README의 과제당 평균 토큰은 cold 기준 8,070인데, 제 실측은 cold 토큰이 가장 적었던 큰 프로젝트 영향 범위 조사도 19만 7천으로 20배가 넘고, 작은 프로젝트 흐름 질문(40만 5천)은 약 50배입니다. README의 Graft 조건은 결과 묶음을 처음에 밀어 넣는 방식이고, 제 실측은 훅과 스킬로 붙인 조건이라 환경부터 다릅니다. 토큰을 같은 기준으로 셌다는 근거도 없습니다. 그래서 이 글은 감소율끼리만 비교합니다.

변화율은 반올림 전 측정값으로 계산했습니다. 표에 적은 반올림 값으로 다시 계산하면 최대 3%p 정도 어긋날 수 있습니다.

Graft 벤치마크 주장 4가지 실측 검증

README가 내세운 네 가지 수치를 하나씩 제 실측과 견줘 보겠습니다.

주장 1. 툴콜 46% 감소: 탐색형 과제에서는 근접

과제	cold	Graft	변화
작은 프로젝트 A (흐름)	7.0회	3.6회	49% 감소
작은 프로젝트 B (영향 범위)	3.8회	1.8회	53% 감소
큰 프로젝트 A (흐름)	18.6회	14.4회	23% 감소
큰 프로젝트 B (영향 범위)	2.0회	1.2회	40% 감소
작은 프로젝트 C (작은 수정)	5.4회	5.4회	변화 없음

탐색형 과제 네 케이스 평균으로 툴콜이 41% 줄었습니다. README의 46%와 거의 비슷한 수준이죠. 감소 폭은 작은 프로젝트에서 더 컸고, 호출이 가장 많았던 큰 프로젝트 흐름 질문은 23% 감소에 그쳤습니다.

반면 작은 단일 파일 수정 과제 C는 cold와 Graft 모두 평균 5.4회로 차이가 없었습니다. 고칠 파일이 이미 정해진 작업에는 그래프가 끼어들 여지가 별로 없다고 봅니다. 툴콜 절감은 “어디를 봐야 하는지 모르는” 탐색형 작업에서 나온다고 정리할 수 있습니다.

주장 2. 시간 60% 감소: 작은 프로젝트에서만

과제	cold	Graft	변화
작은 프로젝트 A (흐름)	34초	26초	23% 감소
작은 프로젝트 B (영향 범위)	22초	12초	46% 감소
작은 프로젝트 C (작은 수정)	36초	35초	1% 감소
큰 프로젝트 A (흐름)	98초	91초	8% 감소
큰 프로젝트 B (영향 범위)	15초	26초	76% 증가
큰 프로젝트 C (작은 수정)	42초	39초	6% 감소
큰 프로젝트 D (무거운 조사)	75초	95초	28% 증가

작은 프로젝트의 탐색형 과제에서는 시간이 확실히 줄었습니다. 다만 60%까지 줄어든 과제는 없었고, 영향 범위 조사가 22초에서 12초로 46% 줄어든 게 README 수치에 가장 가까웠습니다. 작은 수정 과제 C는 두 프로젝트 모두 1~3초 차이로 사실상 같았습니다.

큰 프로젝트에서는 시간이 그대로이거나 오히려 늘었습니다. 영향 범위 조사는 15초에서 26초로, 무거운 조사는 75초에서 95초로 늘었고, 흐름 질문은 98초에서 91초로 거의 그대로였습니다. 시간이 늘어난 원인은 이 측정만으로는 알 수 없습니다.

주장 3. 토큰 42% 감소: 프로젝트 크기와 작업 무게에 따라 갈림

이 글의 핵심입니다.

과제	cold	Graft	변화
작은 프로젝트 A (흐름)	40만 5천	24만 8천	39% 감소
작은 프로젝트 B (영향 범위)	30만	14만 9천	50% 감소
작은 프로젝트 C (작은 수정)	39만 6천	34만 3천	13% 감소
큰 프로젝트 A (흐름)	107만	약 130만	22% 증가
큰 프로젝트 B (영향 범위)	19만 7천	15만 5천	21% 감소
큰 프로젝트 C (작은 수정)	41만 4천	40만 1천	3% 감소
큰 프로젝트 D (무거운 조사)	132만	97만 3천	27% 감소

작은 프로젝트의 탐색형 과제(A, B)에서는 README 주장과 비슷하게 토큰이 39~50% 줄었고, 비용은 그보다 작은 20% 남짓 줄었습니다. 작은 수정 과제 C는 작은 프로젝트 13%, 큰 프로젝트 3% 감소로 폭이 작았습니다.

큰 프로젝트에서는 결과가 갈렸습니다. 흐름 질문은 토큰이 오히려 22% 늘었고, 영향 범위 조사는 21% 줄었습니다. 무거운 조사 과제 D는 토큰이 27% 줄었고, 비용도 80센트에서 54센트로 33% 줄었습니다. 큰 프로젝트에서 비용 감소까지 확인한 건 이 과제입니다.

토큰 감소율과 비용 감소율은 과제마다 달랐습니다. 작은 프로젝트 탐색형 과제는 비용이 토큰보다 덜 줄었고, 큰 프로젝트 D는 비용이 토큰보다 더 줄었습니다. README도 캐시 읽기(약 0.1배)와 쓰기(1.25배) 단가를 반영해 비용을 계산했는데, 토큰 42%, 비용 32%로 감소 폭이 달랐습니다. 제 실측에서 그 차이의 원인은 따로 분석하지 않았으니, 비용을 줄이려는 목적이라면 토큰과 별개로 비용을 직접 기록해 보시는 게 좋겠습니다.

주장 4. 정답률 향상: 대체로 재현, 향상 폭은 미확인

과제	cold	Graft
작은 프로젝트 A (흐름)	100점	97점
작은 프로젝트 B (영향 범위)	100점	100점
작은 프로젝트 C (작은 수정)	80점	100점
큰 프로젝트 A (흐름)	80점	97점
큰 프로젝트 B (영향 범위)	98점	97점
큰 프로젝트 C (작은 수정)	100점	100점

정답률이 크게 떨어진 과제는 없었습니다. 여섯 과제 중 두 과제는 같았고, 작은 프로젝트 흐름 질문과 큰 프로젝트 영향 범위 조사는 Graft가 1~3점 낮았습니다. 반대로 작은 프로젝트 작은 수정과 큰 프로젝트 흐름 질문은 Graft가 20점, 17점 높았습니다.

큰 프로젝트 흐름 질문의 차이는 cold가 다섯 번 중 한 번 정도 탐색을 거의 하지 않고 바로 답해 틀린 영향이 컸습니다. Graft를 붙였을 때는 그런 건너뛰기가 없었고 점수도 더 높았습니다. 작은 수정 과제의 차이는 원인을 따로 확인하지 못했습니다.

그래서 저는 이 항목을 대체로 재현으로 판정합니다. README의 자체 측정 하네스도 정답률이 cold와 같았고, 제 실측도 크게 떨어지지 않았다는 점에서 맞아떨어집니다. 다만 54%에서 66%로 오른 향상 폭은 SWE-bench Verified 결과라 이 실측으로는 확인할 수 없습니다. 에이전트를 더 똑똑하게 만들어 주는 도구라고 말하기는 아직 애매하다고 봅니다.

실측 결과 한눈에 보기

네 가지 주장을 제 실측과 한 표로 모으면 다음과 같습니다.

README 주장	제 실측	판정
툴콜 46% 감소	탐색형 네 케이스 평균 41% 감소, 작은 수정은 변화 없음	탐색형 과제에서 대체로 재현
시간 60% 감소	작은 프로젝트 탐색형 과제는 감소(최대 46%), 큰 프로젝트는 그대로이거나 증가	작은 프로젝트에서만 유효
토큰 42% 감소	작은 프로젝트 탐색형 과제 39~50% 감소. 큰 프로젝트는 흐름 질문 22% 증가, 영향 범위 21% 감소, 무거운 조사 27% 감소(비용 33% 감소)	조건부 유효
정답률 향상	같거나 1~3점 차이, 두 과제는 Graft가 17점, 20점 높음	큰 하락 없음, 대체로 재현(향상 폭은 미확인)

이 실측의 한계

숫자를 그대로 가져가시기 전에 한계도 같이 보셔야 합니다.

• 제 환경에서만 잰 결과입니다. 프로젝트 두 개, 모델은 Claude Sonnet 5 하나, Graft 버전은 0.18 기준이라 이후 버전에서는 결과가 달라질 수 있습니다.
• 기본 설치와 조건이 다릅니다. MCP를 끄고 훅과 스킬만 쓴 조건에서 쟀습니다. 기본 graft init은 MCP 서버도 등록하므로, 같은 조건으로 재려면 --no-mcp를 붙여야 합니다.
• 표본이 작습니다. 과제 A, B, C는 조건마다 다섯 번, D는 세 번 돌린 평균이라 런 하나가 평균을 크게 흔들 수 있습니다.
• 정답률은 README와 같은 잣대로 보기 어렵습니다. README의 93%는 판정 모델이 매긴 값이고, 제 점수는 100점 만점 점수의 런 평균입니다. 채점 방식이 같다고 볼 근거가 없으니 정답률은 방향만 참고해 주세요.
• 과제 유형이 제한적입니다. 흐름 질문, 영향 범위, 작은 수정, 무거운 조사 네 종류만 봤습니다.

어떤 상황에서 Graft를 붙이면 좋을까

실측을 기준으로 판단 기준을 세 갈래로 나눠 보겠습니다.

1. 붙일 만한 경우: 2,000줄 규모 저장소의 흐름·영향 범위 질문. 어디를 봐야 할지 모르는 탐색에서 툴콜, 시간, 토큰이 모두 줄었습니다. 작은 프로젝트 영향 범위 조사는 토큰 50%, 시간 46%가 줄었습니다.
2. 효과가 작은 경우: 고칠 파일이 정해진 단일 파일 수정. 작은 프로젝트에서 툴콜은 5.4회로 같았고, 토큰 감소는 두 프로젝트에서 3~13%였습니다. 정답률은 작은 프로젝트에서 80점에서 100점으로 올랐고 큰 프로젝트에서는 같았습니다. 효율 면에서는 붙여도 얻는 게 적은 작업입니다.
3. 직접 재보고 정할 경우: 10만 줄 규모 저장소, 응답 시간이 중요한 작업. 같은 큰 프로젝트 안에서도 과제마다 얻는 것과 잃는 것이 달랐습니다. 제 실측에서 효과가 가장 분명했던 건 무거운 대규모 탐색 작업이었고, 가벼운 작업보다 무거운 작업에서 토큰과 비용이 함께 줄었습니다.

큰 프로젝트 과제	토큰	비용	시간	정답률
흐름 질문 (A)	22% 증가	수치 없음	98초 → 91초	80점 → 97점
영향 범위 (B)	21% 감소	수치 없음	15초 → 26초	98점 → 97점
무거운 조사 (D)	27% 감소	33% 감소	75초 → 95초	수치 없음

큰 저장소에서는 줄이고 싶은 게 토큰인지, 비용인지, 응답 시간인지부터 정하고 재보는 게 맞다고 봅니다.

에이전트 도구의 효과를 작업 크기별로 나눠 잰 실험으로는 AI에게 “덜 만들어”라고 시키는 스킬 Ponytail 실험도 있습니다. 작은 컴포넌트에서는 코드량이 baseline의 약 40% 수준으로 줄었지만, 대규모 칸반 보드에서는 11% 감소에 그쳤죠. 브라우저 도구의 토큰을 직접 비교한 Aside 토큰 측정 글도 같은 관점에서 읽어보시면 좋겠습니다.

마무리

Graft는 코드 지식 그래프 자체보다, 그 그래프를 Claude Code 훅으로 에이전트에게 강제로 쥐여주는 배선이 핵심인 도구입니다. 서버도 DB도 임베딩도 없이 폴더 하나로 돌아가니 붙이는 부담도 적습니다. 한 줄로 줄이면 파일을 통째로 읽던 탐색을 그래프 조회로 바꾸는 도구라, 가벼운 탐색에서는 호출 수가 줄고 무거운 조사에서는 토큰이 줍니다.

그래서 “토큰 42% 절감”은 조건부 숫자입니다. README 수치와 비슷한 부분도 있었고, 조금 과장됐다고 볼 만한 부분도 있었다고 봅니다. 결국 중요한 건 README의 벤치마크가 아니라 내 저장소에서의 숫자입니다. 여러분 저장소에서 직접 재보실 때는 이렇게 해보면 좋겠습니다.

1. 텔레메트리를 끄고 graft init --dry-run으로 무엇을 건드리는지 먼저 봅니다.
2. 같은 과제를 cold와 Graft 조건에서 여러 번 돌려 평균을 냅니다. 런 하나의 실패가 결과를 크게 흔들 수 있습니다.
3. 툴콜, 토큰, 시간, 비용, 정답 여부를 따로 기록합니다. 토큰이 줄어도 비용과 시간은 다르게 움직였습니다.
4. 흐름 질문, 영향 범위 조사, 작은 수정처럼 작업 유형을 나눠서 봅니다. 평균 하나로 합치면 득실이 가려집니다.