제일 잘 나온 게 에이전트 출력 토큰의 32% 정도였고, 툴 5개를 동시에 테스트했다는 점을 감안해서 보정해보면, 3개는 효과가 있고 2개는 거의 의미 없는 수준임. CodeGraph가 24.4%로 2등이니까, 여기 있는 툴 중 하나 이상은 확실히 효과가 있다는 게 결론이지.
Serena는 좀 특이함. 툴을 42% 더 많이 호출하는데도 기본 에이전트보다 글을 적게 써. 효율적인 게 아니라 그냥 더 바쁘게 움직이는 꼴임.
인덱싱도 고려해야 할 부분이야. Repowise가 토큰은 제일 많이 아꼈는데 인덱싱 시간은 제일 오래 걸림. 같은 과정에서 지능형 레이어를 여러 개 쌓거든. 단순한 호출 그래프만 따지면 CodeGraph가 22배 더 빠름. 참고로 366.8초라는 건 문장 생성 기능을 껐을 때 기준이고, 기본 설정으로 돌리면 1,058초 걸림.
왜 Claude Code 표는 없는가
Claude Code랑 Sonnet 5, Opus 조합으로 똑같은 질문, 서버, 인덱스 써서 돌려봤거든. 그 표들은 벤치마크 페이지에 따로 있는데, Claude Code 환경에서는 툴들이 거의 호출이 안 됨. code-review-graph는 질문 15개 동안 한 번도 안 불렸고, Graphify는 3번, Serena는 4번 불림. 서버나 질문, 인덱스는 똑같은데 Codex는 모든 질문에서 툴을 다 호출했단 말이지.
아마 환경 차이인 듯. Claude Code는 MCP 스키마를 필요할 때마다 불러오는데, 에이전트가 뭘 호출하기 전에 먼저 찾아야 해서 아예 안 쓰는 경우가 많음. Codex는 처음에 다 올려놓고 시작하거든.
나중에 툴을 강제로 쓰게 만드는 훅(hook) 걸어서 Claude로 다시 돌려볼 생각임. 그래야 진짜 절약 효과가 나오는지 알 수 있을 테니까.
품질
Repowise 포함해서 품질 면에서 압도적인 승자는 없었음.
블라인드 테스트 결과, 내 거 포함해서 모든 툴이 기본 에이전트보다 10점 만점에 0.04~0.25점 낮게 나옴. 이 정도 차이는 오차 범위 내고, 똑같은 벤치마크를 아무것도 안 바꾸고 다시 돌렸을 때 나오는 0.69점 차이보다도 작음.
결정론적 검색 벤치마크
토큰 수는 LLM이 뭘 쓸지 결정하는 거에 따라 달라지니까, ContextBench를 써서 결정론적 벤치마크도 돌려봤음.
각 작업마다 실제 수정에 필요한 파일 목록이 정해져 있거든. 툴이 그 파일들을 제대로 찾아내는지 점수만 매기는 거라 LLM 판정은 없음.
Tool
Gold files found
Precision
Files served
Instances
repowise get_answer
0.876
0.087
19.2
42
repowise search_codebase
0.742
0.168
8.2
42
CodeGraph
0.610
0.093
14.0
42
Graphify
0.546
0.033
34.5
42
code-review-graph
0.445
0.240
5.4
42
Coverage 점수는 파일을 많이 가져올수록 높게 나오는데, 그래서 precision이랑 파일 개수도 같이 적어놨음. get_answer는 제일 많이 찾긴 하는데 파일 19개 정도를 뱉어냄. code-review-graph는 제일 적게 찾지만 표에서 제일 정확함. 파일 5.4개로 0.240점이니까, 토큰당 비용 내는 입장에서는 coverage보다 이쪽이 더 나을 수도 있음. Graphify는 파일 34.5개 던져주고 0.546점 나옴.
이거 하느라 인덱스 748번 빌드했고, 1,129개 인스턴스/툴 쌍 평가하는 데 78시간 걸림. 툴마다 캐시 공유 없이 처음부터 끝까지 다 새로 인덱싱했음.
하마터면 올릴 뻔했던 실수 두 가지
Claude Code가 단 한 번도 호출하지 않은 실행에서 code-review-graph가 기준 대비 43% 더 저렴하다는 비용 표를 올릴 뻔했음.
이유는 프롬프트 캐시 워밍 때문임. 먼저 실행된 쪽이 비용을 다 내고, 나중에 실행된 쪽은 캐시를 재사용하니까.
그래서 표에 API 비용 대신 출력 토큰 수를 적어놓은 거임.
이런 실수의 더 큰 버전은 전체 에이전트 세션이 아니라 검색된 페이로드 하나만 측정하는 거임. repowise로 커밋 하나를 불러오는 데는 393토큰이 들지만, 변경된 파일을 읽는 데는 13,984토큰이 들어서 35.6배 차이가 나는데, 이 분야에서 흔히들 내놓는 수치가 바로 이 쉬운 숫자들임. 전체 세션으로 따지면 Codex에서는 31.6%, Claude Code에서는 15.9% 수준임. 에이전트는 계속 다시 읽고, 되돌아가고, 다시 계획을 짜니까 단일 페이로드에서는 엄청나게 압축된 것처럼 보여도 전체 세션으로 보면 훨씬 작아짐.
테스트해 볼 만한 다른 도구 있으면 언제든 환영함. 하네스(harness)는 공개되어 있으니까 직접 다시 돌려보거나 결과에 이의 제기해도 됨.
세 줄 요약: Codex 환경에서 48개의 Django 작업으로 코드베이스 도구 5개를 벤치마크해 봄. 광고에서 흔히 떠드는 60~90% 절감 효과는 개뿔, 근처도 못 감. repowise가 출력 토큰 31.6%를 아껴서 1등, CodeGraph가 24.4%로 뒤를 이었고, 나머지는 6~15% 수준이었음.
Claude Code에서 같은 질문을 던졌더니 도구 결과가 아니라 하네스 결과가 나옴. 도구 쪽은 바뀐 게 하나도 없는데도 대부분 거의 호출조차 안 됐고, 아예 한 번도 안 쓰인 도구도 있어서 그 표들은 벤치마크 페이지에 따로 박아둠.
답변 품질 차이는 평가자 자체의 오차 범위보다 작았고, repowise를 포함한 모든 도구가 순수 에이전트보다 점수가 살짝 낮았음.
별도의 결정론적 검색 벤치마크에서는 repowise가 약 19개 파일 중에서 실제 수정에 필요한 파일의 87.6%를 찾아냈고, code-review-graph는 5.4개 중에서 44.5%를 찾아냄.
에이전트 세션 전체를 측정하고, 토큰 절감 효과를 말할 때는 항상 하네스, 인덱싱 비용, 캐시 효과를 같이 보고하도록 하셈.
주요 댓글
r/claudecode
사용자들은 벤치마크에 추가할 다른 도구들을 제안하고 있으며, 작성자는 이를 긍정적으로 수용하여 향후 테스트 목록에 포함하겠다고 답변함
7
처리 과정에서의 추론 및 도구 호출 토큰도 출력 토큰으로 계산된다는 점을 참고하세요. Claude가 '네, 맞습니다'라고만 답하더라도, '1800년 이전에는 비행기가 존재하지 않았다는 주장을 검증하기 위해 심층 조사를 수행하고, 다른 설명 없이 오직 '네, 맞습니다' 또는 '아니요, 틀렸습니다'로만 답하세요' 같은 프롬프트라면 100만 토큰이 쉽게 나올 수 있습니다.
3
네, 그래서 제가 선택한 지표가 바로 그것입니다. 그 수치는 추론과 도구 호출 인자를 포함하여 모델이 전체 세션 동안 내뱉은 모든 것을 의미합니다.
1
완전 맞는 말씀입니다!
1
훌륭한 테스트이자 기사이며, 탄탄한 방법론입니다. 실행 가능하고 정말 대단한 작업이네요.
Repowise는 다른 도구들과 무엇이 다르길래 이렇게 좋은 점수를 받았나요?
0
감사합니다. 짧게 말하자면, 대부분의 도구는 호출 그래프를 구축하는 데서 멈추지만, Repowise는 동일한 파싱 결과에서 5개의 계층을 구축합니다.
파일별로 결정론적으로 생성된 위키 페이지가 큰 도움이 됩니다. 자연어 질문이 이미 해당 파일을 설명하는 산문으로 연결되므로 검색에 유리하죠.
나머지는 파일별로 마이닝한 깃 히스토리(핫스팟, 소유권, 동시 변경 쌍, 버스 팩터), 히스토리에서 추출한 의사결정 기록, 코드 상태 점수, 그리고 PageRank와 매개 중심성 등을 포함한 그래프 자체입니다.
