코드 리뷰 에이전트 벤치마크: 리뷰어를 평가하는 방법과 자신의 코드에서 c-CRAB 실행하기

코드 리뷰 에이전트가 좋은지 어떻게 알 수 있을까? 이 분야의 짧은 역사 대부분에서 그 답은 "그 댓글이 인간 리뷰어의 댓글에 얼마나 가까운지 측정하는 것"이었다. 실제로 해보기 전까지는 그럴듯하게 들리는데, 두 리뷰어가 같은 문제를 완전히 다른 말로 제기할 수 있기 때문이다. Code Review Agent Benchmark — 논문은 arXiv:2603.23448, 데이터셋은 c-CRAB — 는 리뷰의 표현이 아니라 그 리뷰에 따라 행동했을 때 무엇을 만들어내는지로 리뷰를 평가하려는 최초의 진지한 시도다. 이 벤치마크는 인간 리뷰 코멘트 234개를 실행 가능한 테스트로 변환하고, 널리 쓰이는 네 가지 리뷰어 — PR-Agent, Devin, Claude Code, Codex — 를 그 테스트에 실행했으며, 네 가지를 모두 합쳤을 때 그 테스트의 41.5%를 통과했다. 논문의 표현을 빌리면 "약 40%에 불과하다"고 한다. 이 페이지는 플레이북이다. 그 결과를 왜곡하지 않고 읽는 방법, c-CRAB를 직접 실행하는 방법, 그리고 코드베이스가 벤치마크에 전혀 포함되지 않았을 때 해야 할 일을 설명한다.

이 페이지에서 헤드라인 숫자는 가장 쓸모없는 정보입니다. 유용한 것은 방법과 실패 모드입니다: 왜 모든 이전 채점 방식이 잘못된 것을 측정하고 있었는지, 대신 실행 가능한 테스트로 리뷰를 채점하는 데 드는 비용이 얼마인지, 그리고 왜 "리뷰 에이전트는 버그의 40%만 잡아낸다"라는 말이 실제 결과에 대한 삼중 오독인지가 그것입니다. 여기의 모든 내용은 공개된 벤치마크와 이를 실행한 실무자들의 경험에 대한 커뮤니티의 해석입니다 — 관련 도구 제작자들의 벤더 안내가 아닙니다.

왜 명백한 지표는 작동하지 않는가

c-CRAB 이전에는 코드 리뷰 에이전트에 대한 평가가 소수의 계열로 나뉘었으며, 논문 자체의 비교 표(표 1)가 그 계보를 보여준다. 가장 오래된 것은 텍스트 중복이다. BLEU, ROUGE, chrF 등이 여기에 속하며, CodeReviewer 및 ContextCRBench 같은 벤치마크에서 사용된다. 핵심 아이디어는 에이전트의 코멘트가 인간의 코멘트와 n-그램이 일치할 때 좋은 것이라는 것이다. 그러나 이 아이디어는 코드 리뷰에서 어디에나 존재하는 한 가지 경우, 즉 동일한 결함을 다른 표현으로 서술하는 경우에는 무너진다.

이 논문의 사례 연구가 가장 깔끔한 예입니다. python-telegram-bot의 풀 리퀘스트(PR #3514)에서 인간 리뷰어와 Codex 모두 동일한 중첩 인덱싱 견고성 버그를 지적했습니다. Codex의 리뷰는 행동적으로 올바른 것이었습니다. 이를 실행한 코딩 에이전트는 실행 테스트를 통과하는 수정을 만들어냈습니다. 그러나 텍스트 지표는 이를 BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, 임베딩 유사도 54.59로 채점했습니다. n-gram 중복은 0이었지만 리뷰는 옳았습니다. 같은 우려를 다른 말로 표현했을 뿐인데, 문자열 지표는 이를 알아채지 못했습니다. 임베딩 유사도는 부분적인 개선입니다. 확정된 통과 사례에 대한 54.59는 여전히 실용적인 임계값에 한참 못 미치며, 더 약한 형태로 같은 문제를 물려받습니다.

LLM-as-judge, 즉 모델이 에이전트의 리뷰를 인간의 리뷰와 비교하여 투표하는 방식은 어휘 문제를 해결하지만, 논문이 직접 이름을 붙인 세 가지 새로운 문제를 가져온다: 편향, 불안정성, 그리고 프롬프트 설계에 대한 민감성. 동일한 비교를 두 번 실행하면 판정자가 다른 결과를 내놓을 수 있고, 판정 프롬프트를 바꾸면 순위가 움직인다. 같은 벤치마크에서 세 점 차이를 보이는 두 리뷰어 중 하나를 선택해야 할 때, 그런 변동성을 가진 판정자는 결정을 뒷받침할 수 없다 — 그리고 재현할 수 없는 점수는 점수가 아니다.

실행 가능한 오라클이 가져다주는 것 — 그리고 그 비용

c-CRAB이 기반으로 하는 아이디어는 단순하면서도 급진적입니다: "리뷰가 인간의 것처럼 들리는가?"라고 묻는 대신, "리뷰에 따라 행동하면 코드가 수정되는가?"라고 물어보세요. 유지된 각 인간 리뷰 코멘트는 근본적인 문제를 포착하는 실행 가능한 테스트로 변환됩니다. 리뷰 코멘트는 그것에 따라 행동했을 때 테스트를 통과시키는 동작적으로 올바른 수정이 생성된다면 올바른 것으로 간주됩니다. — 그리고 모든 인스턴스는 실행 가능한 Docker 환경과 함께 제공되므로, "테스트 통과"는 판단이 아니라 사실입니다.

이 논문은 두 가지 종류의 테스트를 정의한다. 동작 테스트는 "런타임에 테스트 대상 코드를 임포트하여 실행"하며, "특정 입력"으로 함수를 호출하고 "출력 또는 예외를 검증"한다. 구조적 테스트는 "소스 코드 텍스트를 검사하고, 패턴을 매칭하며, API 표면을 확인하여 원하는 코드 변경이 이루어졌는지 판단"한다. 최종 분할은 동작 테스트 42개(17.9%)와 구조적 테스트 192개(82.1%)이다 — 그리고 그 편향에 대해서는 솔직한 문장 하나가 필요하다: 이 오라클의 대부분은 소스 텍스트의 패턴 매칭이지 코드를 실행하는 것이 아니다. 가장 이상적인 기준은 동작 테스트이며, 데이터셋의 대부분은 그 실용적인 버전이다.

오라클 구축은 4단계 깔때기이며, 모든 단계에서 무언가를 버린다:

• 초기 데이터셋 — PR 671개, 리뷰 댓글 1,313개.

• 리뷰 필터링 — PR 410개, 댓글 595개. 수동으로 주석이 달린 댓글 100개로 구성된 골드 세트를 기준으로 보정된 LLM 분류기는 객관적으로 검증 가능한 이슈만 유지하고, 대화형 또는 주관적 피드백은 제외합니다.

• 실행 환경 구축 — PR 410건, 댓글 595건. PR당 Docker 이미지 하나, 자동화가 실패하는 경우 종속성 해결은 코딩 에이전트에 폴백.

- 자연어 주석을 테스트로 변환 — PR 339개, 댓글 481개. 실행 기반 정제 루프(최대 3회 시도)를 통해 GPT-5.2으로 생성됨; 테스트는 변경 전 버전에서는 실패하고 변경 후 버전에서는 통과하는 경우에만 유지됩니다.

• 코딩 에이전트를 통한 검증 — PR 184개, 댓글 234개(최종). Sonnet-4.6 백엔드의 Claude Code는 인간 리뷰어의 댓글만 제공받은 채 코드를 수정하려 시도하며, 테스트를 통과시키지 못한 경우는 제외된다.

시작 풀 리퀘스트 중 약 27%만 살아남는다. 그것을 있는 그대로 분명히 밝혀야 한다. 테스트 기반 오라클의 정직한 대가이기 때문이다. 댓글이 실패하는 테스트가 될 만큼 실행 가능하지 않거나, 환경을 빌드할 수 없거나, 유능한 코딩 에이전트가 댓글만으로 코드를 고칠 수 없다면, 해당 인스턴스는 폐기된다. 이것이 벤치마크가 작은 이유이기도 하다. 184개의 PR 인스턴스와 234개의 검증된 댓글은 읽을 수 있는 데이터셋이지, 빠져 죽을 만한 말뭉치가 아니다. 그리고 실제 Docker 환경을 실행해야 하는 오라클에게 작음은 하나의 특징이다.

참고로, 평균 인스턴스는 418.1개의 수정된 라인을 건드리며, 테스트는 평균 31.8라인이고, 인스턴스당 테스트는 1.27개입니다. 두 명의 어노테이터는 생성된 테스트가 인간 리뷰어의 우려를 충실히 반영했는지에 대해 50개의 샘플 인스턴스 중 84%의 경우 일치했습니다.

논문을 직접 읽다 보면 부딪히게 될 한 가지 참고문헌상의 흠이 있습니다: 데이터셋 표(표 4)에는 67개의 저장소가 나열되어 있는 반면, 타당성 위협(Threats to Validity) 섹션에서는 "56개 저장소에 걸쳐 234개의 검증 가능한 오라클이 있는 184개의 풀 리퀘스트 인스턴스"라고 말합니다. 논문은 두 수치를 서로 다른 곳에 제시하며 조정하지 않습니다. 어느 한쪽을 선택하지 말고 평균도 내지 마십시오. 각 수치가 나타나는 곳에 그대로 인용하십시오. 이와 같은 불일치는 독자들이 벤치마크가 시간을 투자할 가치가 있는지 판단할 때 사용하는 바로 그 세부 사항입니다.

독립성에 대한 실사 차원에서: 이 논문은 한 저자가 SonarSource와 관련이 있음을 공개하고, 연구 결과가 "SonarSource 제품의 품질에 대한 평가"로 해석되어서는 안 된다고 밝히고 있습니다. 이것은 그들의 고지 사항으로, 의역이 아닌 인용입니다.

c-CRAB에서 점수를 잘못 인용하지 않고 읽는 방법

핵심 지표는 통과율입니다: 각 인스턴스에 대해, 해당 PR의 테스트 중 통과한 비율을 184개 인스턴스에 걸쳐 평균한 값입니다. 다음은 논문에 실린 전체 결과 표로, 리뷰어당 한 줄입니다. 인간 행은 경쟁자가 아니라 척도 표시입니다 — 인간이 오라클을 작성했으므로, 구조상 100%를 기록합니다:

• Claude Code — 댓글 1,336개, PR당 7.3개, 전체 32.1% (행동적 38.1%, 구조적 30.7%).

• Devin — 댓글 1,344개, PR당 7.3개, 전체 24.8% (행동적 31.0%, 구조적 23.4%).

• PR-Agent — 댓글 524개, PR당 2.8개, 전체 23.1% (행동적 38.1%, 구조적 19.8%).

• Codex — 댓글 324개, PR당 1.8개, 전체 20.1% (행동적 38.1%, 구조적 16.1%).

• 인간 — 234개 댓글, PR당 1.3개, 구성상 100%.

세 가지 정정이 필요합니다. 지금 이 AI 코더 논의 영역에서 초록의 "약 40%에 불과"라는 숫자가 가장 많이 잘못 인용되고 있기 때문입니다. 첫째, 41.5%라는 수치 — 234개 테스트 중 97개가 적어도 하나의 도구로 통과 — 는 네 명의 리뷰어 전체에 걸친 합집합입니다. 어떤 에이전트라도 통과시키면 그 테스트는 한 번으로 집계됩니다. 어떤 단일 에이전트도 41.5%를 기록하지 못했습니다. 최고 단일 점수는 Claude Code의 32.1%입니다. 둘째, 인간 행(row)은 기준(oracle)이지 경쟁자가 아닙니다. 이를 "인간이 봇을 이겼다"고 반복하는 것은 범주 오류입니다. 셋째, 가장 중요한 점: c-CRAB는 인간 리뷰어가 제기하지 않은 유효한 문제에 대해서는 점수를 주지 않습니다. 기준(oracle)은 인간 리뷰의 의도입니다. 아무도 언급하지 않은 실제 버그를 발견한 에이전트는 그 버그에 대해 0점을 받습니다. 따라서 "AI 리뷰 에이전트는 버그의 40%만 잡아낸다"는 말은 세 가지로 틀렸습니다. 이는 합집합이고, 버그 포착률이 아니며, 인간 리뷰어와의 일치를 측정하는 것이지 전체 정확성을 측정하는 것이 아닙니다.

댓글 수가 함정이다.

결과에서 가장 흥미로운 수치는 최고 점수가 아니다. Claude Code와 Devin은 각각 1,300개 이상의 댓글(PR당 약 7.3개)을 게시하여 32.1%와 24.8%를 기록했다. Codex는 324개의 댓글(PR당 약 1.8개)을 게시하여 20.1%에 도달했다. 인간 기준선은 PR당 1.3개의 댓글이다. 양이 곧 커버리지는 아니다. 댓글 수가 약 5배여도 통과율은 두 배에도 훨씬 못 미친다. 리뷰어를 선택한다면, 그 추가 댓글들의 실제 비용은 인간 리뷰 피로다. 에이전트가 게시하는 모든 댓글은 사람이 분류해야 하는 판단 사항이기 때문이다.

유용성 관련 발견은 반대 방향을 시사하며, 이것이 이 이야기를 싸구려 '봇들은 시끄럽다' 류의 이야기로 전락시키지 않게 하는 핵심이다. 저자들은 6개 PR의 92개 댓글을 직접 검토하여 84%(77/92)가 유용하다고 판단했다 — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. 따라서 테스트를 통과하지 못한 대부분의 댓글은 잡음이 아니라 인간 리뷰어가 제기하지 않은 무언가에 관한 것이다. 표본은 작다 — 댓글 92개, PR 6개 — 그리고 이는 백분율과 같은 맥락에서 언급할 가치가 있다.

두 측이 실제로 이야기하는 내용이 결과의 형태를 설명한다. 인간 검토자는 유지보수성, 설계, 문서화 쪽으로 치우쳤고, 도구는 견고성, 테스트, 오류 처리 쪽으로 치우쳤다. 이 논문은 이를 인간-에이전트 협력이지 대체가 아니라는 주장의 근거로 읽는다 — 그리고 이는 점수가 낮아 보이는 이유에 대한 가장 설득력 있는 설명이기도 하다. 경계 사례에는 날카롭지만 설계에는 조용한 검토자는 인간이 지적하는 범주를 체계적으로 놓칠 것이며, 오라클은 전적으로 인간의 지적으로만 구축된다.

{{1}}이 과정을 겪어 본 실무자들은 모두 같은 결론에 도달한다.{{/1}} {{2}}다니엘 본(Daniel Vaughan)이 CR-bench라고 명명한 작업에 대한 상세한 글도 같은 결론에 도달하며 이를 워크플로로 전환한다:{{/2}} {{3}}에이전트가 견고성과 정확성 검사를 수행하게 하고, 인간은 설계, 규칙, 아키텍처—에이전트가 가장 낮은 점수를 받는 분야—를 담당하게 하며,{{/3}} {{4}}약점 분야를 명시한 검토 지침으로 에이전트를 이끌어야 한다.{{/4}} {{5}}리더보드를 읽는 모든 이에게 그가 남긴 가장 유용한 경고는 다음과 같다:{{/5}} {{6}}유용성은 통과율과 같지 않다.{{/6}} {{7}}테스트 스위트가 인간이 의도한 수정과 일치해야 하며, 유효한 대안 수정은 테스트를 통과하지 못하기 때문이다.{{/7}} {{8}}그의 해석에 따르면, 20%에서 의미 있게 더 높은 점수로 가는 길은 모델 업그레이드가 아니라 구성 작업이다.{{/8}}

c-CRAB을 직접 실행하기

위의 모든 내용은 다른 사람들의 결과를 읽은 것입니다. 복제 패키지는 벤치마크를 실행 가능하게 만듭니다. 그 패키지는 c-CRAB-Benchmark/dataset라는 GitHub 저장소에 있으며, README는 실행에 필요한 사항을 솔직하게 설명합니다.

요구 사항: code>uv sync/code>; Docker; 그리고 code>OPENAI_API_KEY/code> 또는 code>ANTHROPIC_API_KEY/code> (Claude Code는 추가로 다음 위치에서 자격 증명을 읽습니다: code>~/.claude/.credentials.json/code>, 기본적으로 컨테이너에 마운트됩니다). 레이아웃은 다섯 개의 디렉터리로 구성됩니다: code>pipeline//code> (파이프라인 로직 및 프롬프트), code>execution//code> (Docker 이미지 빌더 및 런타임 헬퍼), code>results_preprocessed//code> (공개된 벤치마크 하위 집합), code>results_pipeline_funnel//code> (stage0–stage4 JSONL 파일 및 퍼널 요약), 그리고 code>raw_results_compressed//code> (원시 실험 출력). 다섯 단계는 순서대로 다음과 같습니다:

1. Docker 환경을 빌드합니다 — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. 사전 빌드된 이미지는 c-CRAB-Benchmark GitHub packages org에서도 게시되어 있으므로, 빌드를 건너뛰고 싶다면 이를 사용할 수 있습니다.

2. 테스트를 생성합니다 — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. 기준선 리뷰 수집 — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>. 이 단계를 수행하기 전에 해당 외부 도구의 자격 증명을 구성하세요.

4. 에이전트 해석 실행 — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. 평가 — 도구마다 한 번씩 반복: code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

README에서 언급하지 않는 두 가지가 있다. 다섯 번째 리뷰어를 추가한다는 것은 code>run_batch_baselines.py/code>를 편집하는 것을 의미한다. 즉, 도구별 기준 리뷰 프롬프트가 바로 그 파일에 있으며, 플러그인 인터페이스는 없다. README에는 더 깔끔한 확장 지점도 문서화되어 있지 않다. 또한 저장소에는 명시적인 라이선스 파일이 없으므로 코드가 MIT나 Apache라고 가정해서는 안 된다. 논문은 CC BY 4.0이지만 코드 자체의 사용 조건은 명시되어 있지 않다.

비용은 또 다른 공개되지 않은 항목입니다. 이 논문은 파이프라인 실행에 대한 토큰 수나 달러 수치를 공개하지 않으므로, 온라인에서 인용된 비용 수치는 검증되지 않은 것으로 취급하세요. 구조가 시사하는 바는 충분히 명확합니다. 184개 인스턴스에 걸쳐 PR당 하나의 Docker 이미지가 있으며, 도구마다 코딩 에이전트 해결 패스와 평가 패스가 각각 있습니다. 이는 노트북 규모의 오후 작업이 아닙니다. 실제 컴퓨팅 자원에 대한 예산을 책정하십시오.

실행 가능한 오라클을 사용할 여유가 없을 때

대부분 팀의 솔직한 입장은 이렇다: 벤치마크는 LLM 판정자가 리뷰를 채점할 수 없다는 점에서 옳지만, 자체 PR을 위한 테스트 기반 오라클을 구축하는 것은 큰 부담이다. 구분해야 할 점은 LLM 판정자를 채점자로 사용하는 것과 필터로 사용하는 것 사이의 차이다. c-CRAB이 판정자를 오라클로 거부하는 것은 리뷰어 내부에서 판정자가 쓸모없게 만드는 것이 아니다 — 중복 발견을 클러스터링하고 약한 발견을 버리는 판정자는 여전히 정밀도를 높일 수 있다. 설계 시 방어해야 할 실패 모드는 독립성이다.

리뷰어의 자체 모델에서 실행되는 판정자는 자기 자신과 동의합니다. 즉, 리뷰를 읽고 그럴듯하다고 판단한 뒤 아무것도 변경하지 않은 채 성공을 보고합니다. 다른 공급업체의 판정자는 그러한 자기 동의를 줄여 줍니다. 판정자를 테스트로 바꾸지는 않지만, 도장 찍기식 승인은 막아 줍니다. 우리 자체 하네스가 공개되어 있기 때문에 이 안전장치의 구체적이고 검증 가능한 사례를 정확히 보여드릴 수 있습니다: Orca-Code-Review는 GitHub에서 MIT 라이선스로 제공되며, 그 라우팅 레시피는 저장소 자체의 표현으로 규칙을 명시합니다. 판정자는 "기본 모델의 이름을 언급해서는 안 된다"고 말합니다. 왜냐하면 "리뷰어의 자체 모델에서는 판정자가 자기 자신과 동의하므로, 통과는 무의미해지면서도 여전히 성공을 보고하기" 때문입니다. Action은 모델 이름을 절대 언급하지 않으며, 레시피가 결정합니다. 프로비저닝된 대로 리뷰어 기본값은 deepseek/deepseek-v4-flash-0731이며, 다음 헤더와 일치하는 규칙이 있습니다: code>x-cr-lens: judge/code> 헤더. 그 규칙은 판정자 패스를 다른 공급업체인 z-ai/glm-5.3으로 보냅니다. 이는 c-CRAB의 논증과 평행한 설계이지 결과가 아닙니다. 우리는 벤치마크에 포함되어 있지 않으며 우리 리뷰어에 대한 c-CRAB 점수도 없습니다. 그러나 이것은 실행 가능한 오라클을 구축할 수 없는 사람이라면 누구나 사용할 수 있는 실용적 완화 조치이며, 판정자와 리뷰어가 하나의 키 뒤에서 서로 다른 공급업체에 존재할 수 있다면 비용도 저렴합니다. 바로 그것이 라우터의 용도입니다. OrcaRouter에서는 리뷰어와 그 판정자가 라우팅 DSL의 두 줄에 불과하며, 공급업체 목록 가격을 마크업 없이 지불하게 됩니다.

코드가 벤치마크에 없을 때

56개 또는 67개의 공개 저장소에 걸친 184개의 PR은 여러분의 코드베이스가 아니며, 애초에 그럴 수도 없었습니다. 이전할 수 있는 부분은 방법론이며, 여러분은 이를 훨씬 더 작은 규모로 자신의 히스토리에 적용할 수 있습니다. 인간 리뷰 코멘트가 있었던 병합된 PR을 선택하세요. 그 코멘트들의 표본에 대해, 리뷰가 반영되기 전에는 실패하고 반영된 후에는 통과하는 테스트를 작성하세요. 실패-후-통과라는 속성이 곧 이 게임의 전부입니다. 후보 리뷰어를 리뷰 이전의 diff에 실행하세요. 그런 다음 그 코멘트를 반영했을 때 테스트가 통과하는지 확인하세요. 이를 통해 얻는 것은 실제로 배포하는 코드에 대해 계산된 숫자이며, 리더보드 순위보다 더 가치 있습니다. 그 비용은 정확히 그 논문이 부딪힌 벽입니다. PR별로 재현 가능한 환경이 필요합니다. 노트북에서만 통과하는 테스트는 오라클이 아니기 때문입니다.

234개의 테스트가 필요하지 않습니다. 팀이 실제로 논쟁했던 PR에 대해 잘 선별된 12개 정도의 테스트가 벤치마크 점수보다 리뷰어에 대해 더 많은 것을 알려줍니다. 그리고 이 벤치마크 계열에 대한 병행 실무자 분석은 관문에 대해 솔직합니다: 댓글이 유효하고 검증 가능한 이슈인지에 대한 LLM 분류기의 정밀도는 66%~85% 사이에 머물므로, 머신 필터링을 후보 목록으로 취급하고 무엇이든 테스트가 되기 전에 인간의 판정 단계를 유지하세요. 같은 글은 독립적으로 동일한 댓글-투-테스트 아이디어로 구축된 LangChain의 ReviewBench가 기준선 이슈의 약 30%만을 최대로 회수한다고 지적합니다 — 이는 c-CRAB의 20~32%와 같은 범위이며, 도구 간 한 자릿수 리더보드 차이가 종종 자체 설정의 노이즈보다 작다는 것을 상기시켜 줍니다.

리뷰 도구를 구매할지 여부를 결정하는 것 자체는 다른 문제입니다. 코드 리뷰 에이전트 구매자 가이드에서는 봇 대 에이전트, 좌석당 대 토큰당 가격, 그리고 자체 호스팅이 유리한 경우를 다룹니다. 일단 도구를 하나 갖게 되면 모든 푸시에서 리뷰 하네스를 실행하는 운영 비용은 자동 코드 리뷰 설명서에서 다룹니다. 이 페이지는 측정에만 관한 것이며, 이에 대한 동반 문서에서는 벤치마크의 구조(구성 퍼널, 데이터셋 통계, 전체 결과 표)를 설명합니다.

자주 묻는 질문

41.5%가 최고 에이전트의 점수인가요? 아닙니다. 41.5%는 네 가지 도구 모두에 걸친 합집합입니다 — 테스트는 그중 하나라도 통과하면 한 번으로 계산됩니다. 최고 단일 점수는 Claude Code의 32.1%입니다.

c-CRAB는 리뷰어가 얼마나 많은 버그를 잡았는지 측정하나요?아니요. 이는 리뷰가 인간 리뷰어가 제기한 내용과 얼마나 잘 일치하는지를 측정하며, 이를 실행 가능한 테스트로 변환합니다. 인간이 언급하지 않은 실제 결함은 아무리 타당하더라도 0점으로 처리됩니다.

인간 검토자들이 봇을 "이겼을까"? 100% 인간 행은 오라클 자체입니다. 인간이 테스트를 작성했으므로 이는 경쟁자가 아니라 척도 표시입니다.

c-CRAB와 CR-bench는 같은 것인가요? 네. 데이터셋은 c-CRAB입니다. 일부 서드파티 보도에서는 이를 CR-bench라고 부르지만, 여기에는 벤치마크가 하나뿐입니다.

실행하는 데 비용이 얼마나 드나요? 논문은 비용 수치를 공개하지 않습니다. 184개 인스턴스에 걸쳐 PR당 Docker 이미지 하나와 에이전트 해석 패스가 필요하다는 것은 실제 컴퓨팅 자원을 의미합니다 — 노트북으로 한 오후에 끝낼 수준이 아닙니다.

결론

c-CRAB의 기여는 리더보드가 아니라, 리뷰가 그 조언을 실행함으로써 점수를 매길 수 있다는 것과, 그 이전의 텍스트 유사도 및 LLM-심사 방식들이 잘못된 것을 평가하고 있었다는 것을 입증한 것이다. 한 가지만 얻어 간다면, 그것은 세 부분으로 된 정정이다: 41.5%는 합집합이고, 인간 행은 오라클이며, 벤치마크는 인간이 제기하지 않은 결함에 대해서는 어떤 점수도 부여하지 않는다는 것이다. 그리고 행동에 옮길 수 있는 수치를 원한다면, 그 방법은 이식 가능하다. 즉, 직접 병합한 PR에 대해 실패 후 통과 테스트를 적용하고, 인간 판정 단계를 거치며, 실행 가능한 오라클을 구축할 수 없다면 적어도 리뷰어의 모델과 독립적인 모델을 사용하는 심사를 사용하는 것이다.

논쟁하기보다 리뷰어를 측정하고 싶다면, 직접 읽을 수 있는 하네스에서 시작하세요. OrcaCode Review는 시트(좌석) 단위가 아닌 토큰 단위로 리뷰 패스와 독립적인 검증 심사자를 실행하며, 그 안의 모든 프롬프트는 공개되어 있습니다. 따라서 이와 같은 벤치마크에 적용하면 저희 수치 대신 여러분만의 수치를 얻을 수 있습니다.