Hono에서 CodeGraph를 테스트해 보았습니다. 도구 호출(Tool-Call) 절감 효과는 재현되었으나, 비용 절감 효과는 그렇지

2주 전 CodeGraph가 GitHub 트렌딩에 올랐습니다. tree-sitter + SQLite/FTS5 + Claude Code를 위한 MCP 조합으로, 일주일 만에 19,000개 이상의 별(star)을 획득했습니다. 해당 팀은 7개의 저장소(repo)를 대상으로 한 벤치마크를 발표하며, 기준점(baseline) 대비 **35% 더 저렴하고, 57% 적은 토큰 사용량, 46% 더 빠른 속도, 71% 더 적은 도구 호출(tool calls)**을 보여주었습니다.

이는 매우 큰 수치입니다. 하지만 이 수치들은 해당 도구를 만든 팀이 직접 설계한 벤치마크와 그들이 선택한 저장소에서 나온 결과이기도 합니다. 설계자 편향(Designer bias)은 모든 검색(retrieval) 벤치마크에서 가장 큰 위험 요소입니다. 테스트할 저장소를 직접 선택하고 정답(ground truth)을 작성하게 되면, 의식적이든 무의식적이든 자신의 도구가 가진 강점에 유리하게 작용할 수밖에 없습니다.

그래서 저는 8번째 저장소인 Hono(TypeScript, 약 280개의 소스 파일, CodeGraph가 발표한 7개 저장소 세트나 제가 찾을 수 있는 다른 공개 벤치마크 어디에도 포함되지 않음)를 대상으로 독립적인 테스트를 수행했습니다. 다양한 검색 형태를 다루는 5개의 아키텍처 질문을 준비했으며, 도구가 이겨서는 안 되는 의도적인 대조군 사례(Q5)를 포함했습니다. 두 가지 조건(기준점인 grep+Read+Glob+Explore vs. CodeGraph 활성화)을 설정하고, 조건당 질문별로 4회 반복했습니다. Claude Opus 4.8을 사용하여 총 40회 실행했으며, 결정적으로 모든 CodeGraph 실행 시 연결 상태를 확인하였고, 실행당 실제 codegraph_* 도구 사용량을 기록했습니다 (왜 이 문장이 존재하는지에 대해서는 아래에서 더 자세히 다룹니다).

결과는 단일하게 발표된 헤드라인 수치가 숨기고 있는 방식으로 나뉘었으며, 이 나뉘는 지점이 바로 유용한 부분입니다.

요약 (tl;dr) — Hono에서 CodeGraph는 **도구 호출(tool calls)의 대폭적이고 일관된 감소(-55%, 평균 14.0 → 6.3회)와 소폭의 지연 시간(latency) 개선(-20%)**을 보여주었습니다. 이는 발표된 7개 리포지토리(7-repo)의 경향성이 재현된 결과입니다. 하지만 **비용 측면은 상쇄되었습니다: +6.8%**로, 발표된 -35%와는 달랐습니다. 좁은 범위의 질문(라우트 조회, 미들웨어 추적 등)에서는 CodeGraph가 실제로는 20-43% 더 비쌌는데, 이는 각 구조적 조회(structural lookup) 시마다 그래프 컨텍스트(graph context)의 큰 덩어리를 로드하기 때문입니다. 이 비용은 grep 방식의 왕복(round-trips)보다 캐시된 토큰(cached tokens) 비용이 더 많이 발생합니다. 비용 절감 효과는 광범위한 다중 파일 탐색(multi-file navigation)에서만 나타납니다 (Q3 다중 런타임 어댑터: 비용 -29%, 도구 호출 -80%, 지연 시간 -53%). 두 번째 발견 사항: 기준이 되는 grep+Read 방식은 **높은 분산(high variance)**을 보였습니다. 에이전트가 광범위한 질문에 대해 가끔 47-52회의 도구 호출로 치달으며 루프를 도는 반면, CodeGraph는 16회를 초과하지 않았습니다. Hono 규모에서의 결론: CodeGraph는 에이전트가 더 적은 단계를 거쳐 더 빠르게 작업을 마치게 하지만, 더 적은 비용으로 해결해주지는 않습니다. 40회의 유효한 실행에 대한 총 비용은 Opus 4.8 호출 기준 약 $14였습니다. 원본 실행별 CSV와 5개의 실제 프롬프트는 아래에 있습니다.

"도구 호출은 감소했지만 비용은 그대로"가 실제로 의미하는 것

CodeGraph가 발표한 7개 리포지토리 제품군(VS Code, Excalidraw, Django, Tokio, OkHttp, Gin, Alamofire)은 Hono보다 규모가 더 크고 아키텍처적으로 더 복잡합니다. Hono는 약 280개의 TypeScript 소스 파일(테스트 및 설정을 포함하여 CodeGraph가 인덱싱한 파일은 362개)로 구성되어 있으며, 디스크 용량은 16MB입니다. 이는 grep + Read를 사용하는 사려 깊은 에이전트가 몇 번의 도구 호출만으로 대부분의 아키텍처 관련 질문을 끝낼 수 있을 만큼 충분히 작은 규모입니다.

흥미로운 결과는 _축(axes)이 분리된다_는 점입니다. CodeGraph는 여러 번의 grep+Read 왕복 과정을 한두 번의 구조적 조회(structural lookups)로 대체하므로, 단계 수(step count)가 급격히 감소합니다 (-55%). 하지만 각 codegraph_context / codegraph_explore 호출은 상당한 양의 그래프 컨텍스트(graph context) 덩어리를 반환하며, 이는 대화 캐시(conversation cache)에 함께 실려 매 턴마다 다시 읽히게 됩니다. Hono의 규모에서는 해당 캐시된 페이로드(payload)를 유지하는 데 드는 비용이 grep 왕복 과정에서 발생하는 비용과 거의 비슷합니다. 따라서 단계 수가 절반 이상 줄어들었음에도 불구하고, 비용(dollars)은 평이하게 유지됩니다 (+7%).

이는 이 미니 시리즈의 이전 포스트에서 다룬 비용 곡선(cost-curve) 가설에 대한 모순이 아니라, 이를 더 정밀하게 읽어낸 결과입니다. Hono는 단계 수 교차점(step-count crossover, 인덱스가 이미 도구 호출을 절약하는 지점)의 위에 있지만, 비용 교차점(dollar crossover, 아직 돈을 절약하지 못하는 지점)의 아래에 위치합니다. 훨씬 더 큰 규모의 리포지토리(repo)에서는 grep 경로가 훨씬 더 많은 파일을 훑어야 하므로, 인덱스가 비용 측면에서도 이득을 가져다줍니다. Hono는 단지 두 교차점 사이의 간극에 걸쳐 있을 뿐입니다.

유용한 보완적 벤치마크는 기존에 발표된 벤치마크가 답하지 못하는 세 가지 질문에 답합니다:

도구 개발팀이 선택하지 않은 리포지토리에 대한 교차 검증 — 발표된 장점들이 일반화될 수 있는가?
질문 유형에 따른 리포지토리 내 분산 — 이득이 특정 질문 형태에 집중되는가? (그렇습니다 — 매우 심하게.)
도구가 이겨서는 안 되는 대조군(control case) — Q5(텍스트 검색)는 grep이 적절한 도구일 때 에이전트가 구조적 엔진 사용을 올바르게 거절(declines) 하는지 테스트합니다.

설정 — CodeGraph 설치, 약 10분 소요

# 설치 (단일 바이너리를 다운로드하며, Node/npm이 필요하지 않음)
curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh

...

Hono에서의 인덱스 빌드 시간 (362개 파일, 4,128개 노드, 8,225개 엣지): 1.7초. 디스크 인덱스: 7.1 MB.

두 실험군을 위한 조건별 설정:

Baseline (대조군): Hono의 깨끗한 복사본을 rsync -a --exclude='.codegraph/'를 사용하여 별도의 디렉터리로 옮겨서 Claude가 실수로 인덱스에 grep하는 것을 방지했습니다. MCP 서버는 등록되지 않았습니다. 에이전트는 네이티브 Glob + Grep + Read + Explore + Task를 사용합니다.
CodeGraph 활성화: .codegraph/가 존재하는 원본 Hono 디렉터리이며, MCP 서버가 등록되었습니다:

{"mcpServers": {"codegraph": {"command": "codegraph", "args": ["serve", "--mcp"]}}}

두 실험군 모두 claude --print --output-format stream-json --model opus를 실행하여 모델과 나머지 에이전트 루프가 동일하도록 했습니다. 유일하게 달라지는 입력은 CodeGraph MCP 서버가 루프에 포함되는지 여부입니다. 각 실행은 이전 컨텍스트가 없는 새로운 세션으로 진행됩니다.

도구가 실제로 실행되었는지 검증 (이는 선택 사항이 아닙니다)

검색(retrieval) 도구 벤치마크는 도구가 실제로 루프에 포함되어 있을 때만 유효합니다. 저는 이 점을 힘든 경험을 통해 배웠습니다. 제가 처음 수행한 이 벤치마크는 CodeGraph의 MCP 서버가 절대 연결되지 않은 상태로 조용히 실행되었습니다. 설정에서 --mcp 플래그가 누락되었고, Claude Code는 오류를 발생시키기보다는 시간 내에 핸드셰이크(hand-shake)에 실패하는 서버 없이 진행됩니다. 모든

이 포스트에 포함된 20번의 CodeGraph 실행은 모두 연결되었습니다. 에이전트는 Q1-Q4에서 CodeGraph를 호출했으며(각 4회 반복), Q5 대조군(control)에서는 — 올바르게 — grep을 선택했습니다(0/4). 대부분의 벤더 벤치마크(vendor benchmarks)는 이러한 검증을 보고하지 않습니다. 제 실험이 이를 조용히 실패하는 것을 본 이후로, 저는 이러한 검증 없이는 검색(retrieval) 벤치마크를 발표하지 않을 것입니다.

5가지 질문

전체 프롬프트(prompts) 전문은 부록(Appendix)에 있습니다. 간략한 개요는 다음과 같습니다:

#	질문	테스트 항목	CodeGraph에 대한 가설
Q1	경로 해석(Route resolution): `GET /users/:id` → 핸들러	경로 인식 추출 (Route-aware extraction)	강력한 승리
...
Q5는 대조군(CONTROL)입니다. 여기서 도구가 선택되어서는 안 되며, 에이전트가 도구를 호출하려고 시도하는지 여부 자체가 하나의 신호가 됩니다.

데이터

각 행은 4회 반복의 평균값입니다. 비용(Cost)은 Claude 자체의 total_cost_usd(API의 공식 수치이며, 제가 직접 계산한 것이 아님)이며, 지연 시간(wall latency)은 요청부터 마지막 토큰까지의 시간입니다. 도구 호출(tool calls)은 트랜스크립트(transcript) 내의 고유한 tool_use 블록을 기준으로 계산되었습니다. 토큰은 입력 + 출력이며, 캐시 토큰(cache tokens)은 CSV에서 별도로 추적됩니다.

비용 / 토큰

Q	기준 비용 (Baseline cost)	CodeGraph 비용	Δ 비용	기준 토큰	CodeGraph 토큰	Δ 토큰
Q1 경로	$0.321	$0.393	+22.5% ❌	10,115	6,045	−40.2%
...

도구 호출 / 지연 시간

Q	기준 호출 횟수	CodeGraph 호출 횟수	Δ 호출 횟수	기준 지연 시간	CodeGraph 지연 시간	Δ 지연 시간
Q1 경로	7.8	6.8	−12.9%	49.8s	51.2s	+2.8%
...

두 가지 핵심적인 결과가 있습니다: 도구 호출 55% 감소 (실제적이고 일관됨 — CodeGraph는 모든 질문에서 더 적은 도구를 사용함)와 비용 6.8% 증가 (Hono 환경에서 CodeGraph는 더 저렴하지 않음)입니다. 지연 시간에서의 이점(−20%)은 실제적이지만 특정 구간에 집중되어 있습니다. 거의 대부분이 Q3에서 발생하며, Q1/Q2/Q4에서의 지연 시간은 ±5% 이내입니다.

변동성 이야기 — CodeGraph는 최악의 경우를 제한함

평균값은 가장 흥미로운 결과를 가립니다. 반복당 기준 도구 호출 횟수는 다음과 같습니다:

Q	Baseline (4 repeats)	CodeGraph (4 repeats)
Q3 multi-runtime	14, 23, 52, 52	5, 6, 8, 9
Q4 refactor	9, 10, 13, 47	9, 10, 12, 16

광범위한 질문들에 대해, Baseline (grep+Read) 방식은 가끔씩 통제 불능 상태로 치솟았습니다 (spiraled) — 인덱스(index)가 없는 에이전트는 파일을 추적하며 47~52회의 도구 호출 (tool calls)까지 방황했습니다. 총 40회의 실행 전체에서 Baseline은 2회에서 52회 사이의 도구 호출을 기록한 반면, CodeGraph는 1회에서 16회 사이를 기록했습니다. 여기서 CodeGraph의 가치는 평균값이 아니라, 최악의 경우를 제한한다는 점에 있습니다. 구조적인 정답이 그래프 쿼리(graph query) 한 번으로 해결될 수 있을 때, 에이전트는 방황할 수 없습니다. 이는 단순한 효율성(efficiency)의 문제가 아니라 신뢰성(reliability)의 특성이며, 단일 평균값으로는 나타나지 않습니다.

표본 크기에 대한 주의사항: 이것은 하나의 저장소(repo)에 대해 4회 반복한 결과입니다. 수치는 지표로서의 의미를 갖되, 방향성은 견고한 것으로 간주하십시오 — CodeGraph는 모든 질문과 거의 모든 반복 실행에서 더 적은 도구 호출을 사용했으며, 비용의 방향성 또한 각 셀 내에서 일관되었습니다 (Q1/Q2/Q4에서는 더 비쌌고, Q3에서만 더 저렴했습니다). 제가 과하게 해석하지 않을 부분은 정확한 백분율입니다. Q4에서 Baseline의 범위가 47 대 9라는 것은, n=4인 상황에서도 질문당 평균값에 상당한 불확실성이 존재함을 의미합니다.

질문별 상세 분석

Q1 (route resolution) — CodeGraph를 사용했으나, 비용은 더 높았습니다. 두 방식 모두 app.fetch → #dispatch → this.router.match()를 추적하고 SmartRouter → RegExpRouter를 읽었습니다. CodeGraph는 codegraph_context + codegraph_trace (실행당 2회 호출)를 사용하였고, 도구 호출은 13%, 토큰(tokens)은 40% 절감했습니다. 하지만 비용은 22.5% 상승했으며 지연 시간(latency)은 변화가 없었습니다. CodeGraph가 사전에 로드한 구조적 컨텍스트(structural context)가 절약한 1~2회의 grep 단계보다 더 무거웠기 때문입니다. Hono의 라우터는 전체 그림을 파악하는 데 필요한 파일이 5~6개 정도로 충분히 작아서, grep만으로도 직접 찾아낼 수 있습니다.

Q2 (middleware chain trace) — 사용됨, 비용 43% 증가. CodeGraph는 app.use → 미들웨어 배열 → compose() 체인을 베이스라인의 5회 호출 대비 4회의 도구 호출 (tool calls)로 찾아냈지만, 비용은 43% 급증했습니다. Q1과 동일한 메커니즘이지만 더 두드러지게 나타났습니다. 즉

Q5 (텍스트 검색, 제어) — 에이전트가 도구 호출을 거부했으며, 이것이 핵심입니다. 순수하게 리터럴 'Content-Type' 검색을 수행할 때, 에이전트는 4회의 반복 시도 중 단 한 번도 CodeGraph를 호출하지 않았습니다. 대신 곧바로 grep을 사용했습니다. 결과: 거의 대등한 수준(비용 -5%, 지연 시간(latency) -15%, 모두 오차 범위 내)을 보였습니다. 이 포스트의 이전 버전에서는 여기서 "FTS5 폴백(fallback)" 승리라고 주장했으나, 이는 첫 번째 실행 오류로 인한 결과물이었습니다. 진실은 더 단순하고 훌륭합니다: CodeGraph가 연결되어 사용 가능한 상태임에도, 에이전트는 grep 형태의 작업에 대해 grep을 선택하는 올바른 판단을 내렸습니다. 과도한 엔지니어링(over-engineering)이 없었습니다. 이것이 바로 검색 도구(retrieval tool)에서 실제로 기대하는 기본 동작(table-stakes behavior)이며, 조작된 1단계 절감 효과보다 훨씬 가치 있는 결과입니다.