c-CRAB, 코드 리뷰 에이전트 벤치마크: 그것이 측정하는 것, 발견한 것, 그리고 41.5%가 실제로 의미하는 것

코드 리뷰 에이전트와 인간 리뷰어가 동일한 풀 리퀘스트를 검토하고 동일한 우려를 제기했습니다. 에이전트의 코멘트에 따라 조치를 취하면 버그가 수정되고 테스트가 통과합니다. 하지만 저자들이 계산한 모든 텍스트 유사도 지표는 에이전트의 리뷰를 인간의 리뷰와 본질적으로 무관한 것으로 평가했습니다: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, 임베딩 유사도 54.59. 동일한 우려, 다른 표현, 그리고 표준적인 리뷰 평가 방식은 두 리뷰가 일치한다는 것을 알아채지 못했습니다. 이 한 가지 예가 c-CRAB(“시-크랩”으로 발음), 즉 Code Review Agent Benchmark의 근거가 되며, 이는 arXiv:2603.23448로 발표되었습니다.

c-CRAB은 코드 작성 에이전트가 아닌 코드 리뷰 에이전트를 평가합니다. 풀 리퀘스트(인간이나 코딩 에이전트에서 비롯될 수 있음)가 주어지면 리뷰 에이전트가 리뷰를 생성하고, c-CRAB은 그 리뷰를 따라 조치했을 때 동작적으로 올바른 수정이 산출되는지로 리뷰의 점수를 매깁니다. 이 벤치마크는 소프트웨어 공학 연구자들인 Yuntong Zhang, Zhiyuan Pan, Imam Nur Bani Yusuf, Haifeng Ruan, Ridwan Shariffdeen, Abhik Roychoudhury가 구축했으며, 네 가지 도구(PR-Agent, Devin, Claude Code, Codex)를 평가합니다. 저자 중 한 명은 SonarSource와 관련이 있고, 논문은 이것이 의미하는 바와 의미하지 않는 바를 자체적으로 다음과 같이 명시합니다: “본 논문에 표현된 견해와 결론은 저자들만의 것이며, SonarSource의 공식 정책이나 지지를 대표하지 않습니다. 또한, 여기에 제시된 연구 결과는 독립적이며 SonarSource의 제품 품질에 대한 평가로 해석되어서는 안 됩니다.”

자세한 내용을 다루기 전에 두 가지를 짚고 넘어가겠습니다. 일부 제3자 기사에서는 이 동일한 작업을 “CR-bench”라고 부르기도 하는데, 이는 동일한 벤치마크이며, 이 페이지에서는 전체적으로 c-CRAB이라는 명칭을 사용합니다. 아래의 모든 수치는 논문이 보고한 자체 결과로, 오늘 논문과 복제 패키지에서 확인한 것입니다 — 독립적으로 재실행된 것은 아닙니다 — 해석은 우리의 의견과 논문이 이미 불러일으킨 실무자 논의를 포함합니다. 그 어느 것도 평가된 도구를 제공한 공급업체의 지침이 아닙니다. 그리고 코드 리뷰 에이전트를 실행할지 여부를 아직 결정 중이라면, 코드 리뷰 에이전트에 관한 구매자 가이드가 더 나은 출발점이 될 것입니다. 이 페이지는 그러한 에이전트가 어떻게 측정되는지에 관한 것입니다.

c-CRAB가 LLM 판사가 아닌 테스트로 리뷰를 채점하는 이유

코드 리뷰 에이전트의 성과를 평가하는 일반적인 방법은 해당 리뷰를 인간의 리뷰와 비교하는 것이며, 이때 LLM-as-judge나 텍스트 유사도 지표를 사용한다. c-CRAB의 저자들은 두 가지 모두를 거부한다. 그들은 LLM-as-judge가 편향, 불안정성, 프롬프트 민감성의 문제를 지녀 재현 가능하고 일관된 평가를 어렵게 만든다고 주장한다. 그리고 위의 사례 연구는 문자열 지표가 실제로 측정하는 것이 무엇인지 보여준다: 표현이지 효과성이 아니다. 그 python-telegram-bot 풀 리퀘스트에서 Codex 리뷰는 인간이 한 것과 동일한 말을 했지만, BLEU-4와 ROUGE-L은 그것을 알아보지 못했다.

그래서 c-CRAB은 정반대를 수행합니다. 각 인간 리뷰 코멘트는 근본적인 문제를 포착하는 실행 가능한 테스트로 변환됩니다. 리뷰 코멘트는 그에 따라 조치했을 때 동작적으로 올바른 수정, 즉 테스트를 통과시키는 수정을 만들어내면 정확한 것으로 간주됩니다. 모든 인스턴스는 실행 가능한 Docker 환경을 갖추고 있어서, 통과/실패 결정은 코드를 실행하여 내려지며, 두 텍스트가 얼마나 유사한지 다른 모델에게 묻는 방식이 아닙니다. 이것이 중요한 이유입니다: 리뷰의 역할은 개발자가 하는 행동을 바꾸는 것이며, 테스트는 그러한 변화를 직접 측정하는 유일한 점수 신호입니다.

이 논문은 두 종류의 테스트를 자체적으로 이렇게 정의한다: “동작 테스트는 테스트 대상 코드를 런타임에 임포트하여 실행한다. 특정 입력으로 테스트 대상 함수를 호출하고, 출력을 확인하거나 예외를 검증한다. 반면 구조적 테스트는 소스 코드 텍스트를 검사하고, 패턴을 매칭하며, API 표면을 확인하여 원하는 코드 변경이 이루어졌는지 판단한다.” 최종 분류는 동작 테스트 42개(17.9%)와 구조적 테스트 192개(82.1%)이다. 솔직히 한마디 할 가치가 있다: 오라클의 대부분은 코드를 실행하는 것이 아니라 소스 텍스트의 패턴 매칭에 기반한다. 그러한 편향은 염두에 두어야 할 실제 한계다.

벤치마크가 어떻게 구축되었는지, 그리고 퍼널의 비용은 얼마인지

c-CRAB는 기존 inclusionAI/SWE-CARE 데이터셋을 기반으로 구축되었으며, 이 데이터셋은 커밋 메타데이터가 포함된 pull-request 인스턴스를 제공합니다. c-CRAB 자체의 기여는 PR 코퍼스가 아니라 오라클(oracle)입니다. 큐레이션 파이프라인은 네 개의 필터를 실행하며, 각 필터는 인스턴스를 소모합니다. 논문은 이 퍼널(funnel)을 다음과 같이 보고합니다:

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

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

• 실행 환경 구축 — PR 410개, 코멘트 595개. PR당 Docker 이미지 하나, 자동화가 실패하는 경우 의존성 해결은 코딩 에이전트로 폴백합니다.

• 자연어 주석을 테스트로 변환 — PR 339개, 주석 481개. 테스트는 GPT-5.2로 생성되며, 실행 기반 정제 루프에서 최대 3회까지 시도됩니다. 테스트는 원래 코드에서는 실패하고 수정 후에는 통과하는 경우에만 유지됩니다.

• 코딩 에이전트를 사용한 검증 — PR 184개, 댓글 234개. Sonnet-4.6 백엔드의 Claude Code는 인간 리뷰 코멘트만 받아 코드 수정을 시도합니다. 테스트를 통과시키지 못한 경우는 폐기됩니다. 이것이 최종 세트입니다.

초기 풀 리퀘스트 중 약 27%가 살아남습니다. 이는 테스트 기반 오라클의 정직한 대가이며, 벤치마크가 방대하지 않고 작은 이유이기도 합니다. 살아남은 집합은 184개의 PR 인스턴스, 234개의 검증된 리뷰 코멘트, 인스턴스당 1.27개의 테스트, PR당 평균 418.1개의 수정 라인, 테스트당 31.8라인입니다. 두 명의 어노테이터는 50개의 샘플 인스턴스에서 생성된 테스트가 인간 리뷰어의 우려를 충실히 반영했는지 독립적으로 판단했으며, 84%의 일치율을 보였습니다.

자세히 읽다 보면 발견하게 될 불일치가 하나 있습니다: 데이터셋 표에는 67개의 저장소가 나열되어 있는 반면, 타당성 위협 섹션에는 “56개 저장소에 걸쳐 234개의 검증 가능한 오라클이 있는 184개의 풀 리퀘스트 인스턴스”라고 나와 있습니다. 논문은 서로 다른 곳에서 두 수치를 모두 제시하며, 우리는 이를 평균 내거나 조용히 편리한 쪽을 선택하지 않을 것입니다. 독자들은 바로 이런 종류의 세부 사항을 통해 벤치마크가 투자할 가치가 있는지 판단하므로, 두 수치 모두 게시된 그대로 여기에 재현됩니다.

결과 및 해석 방법

통과율은 집계된 테스트 통과율입니다. 즉, 각 인스턴스에 대해 해당 PR의 테스트 중 통과한 비율이며, 대표 수치는 인스턴스 전체의 평균입니다. 논문은 도구별로 다음을 보고합니다:

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

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

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

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

• Human — 댓글 234개, PR당 1.3개 — 구조적으로 100%. 사람들이 오라클을 작성했으므로 이 행은 척도 표시자이지 경쟁자가 아닙니다.

해당 행들을 인용하기 전에 주의 깊게 읽으십시오. 초록의 “약 40%에 불과하다”는 것은 합집합입니다: 234개 테스트 중 41.5%가 네 도구 중 적어도 하나에 의해 통과되었습니다. 이는 특정 단일 에이전트의 점수가 아닙니다 — 최고 단일 점수는 Claude Code의 32.1%입니다 — 그리고 네 도구가 함께 실제 결함의 40%를 발견했다는 의미도 아닙니다. 아래 섹션에서 그 이유를 설명합니다.

가장 흥미로운 숫자는 승자가 아니다. Claude Code와 Devin은 각각 1,300개 이상의 댓글(PR당 약 7.3개)을 게시하여 32.1%와 24.8%에 도달했다. Codex는 PR당 약 1.8개인 324개를 게시하여 20.1%를 달성했다. 인간 기준선은 PR당 1.3개의 댓글이다. 계산을 해보라: 댓글 양이 약 4배인데 통과율은 두 배에도 크게 못 미친다. 양이 곧 커버리지는 아니다. 수다스러운 리뷰어가 유용한 리뷰어와 같은 것은 아니며, c-CRAB는 이를 보여주기 위해 설계된 최초의 벤치마크다.

유용성은 반대로 작용한다.

낮은 통과율은 마치 비난처럼 읽히지만, 저자들이 측정한 다른 요소를 살펴보면 그렇지 않다. 그들은 6개의 PR에서 92개의 댓글을 직접 검토했고, 그중 84%(92개 중 77개)가 유용하다고 판단했다 — PR-Agent 94%, Codex 88%, Devin 85%, Claude Code 78%. 따라서 c-CRAB 테스트를 통과하지 못한 대부분의 댓글은 노이즈가 아니라, 인간 리뷰어가 제기하지 않은 무언가에 관한 것이다. 샘플은 92개의 댓글과 6개의 PR로 작으며, 논문에서도 이를 인정했고, 우리도 그렇게 말해야 한다.

이와 같은 패턴은 리뷰어들이 논의하는 내용에서도 나타난다. 인간 리뷰어는 유지보수성, 설계, 문서화에 중점을 둔 반면, 도구는 견고성, 테스트, 오류 처리에 중점을 두었다. 논문은 이를 인간-에이전트 협력(대체가 아닌)을 지지하는 논거로 해석한다. 또한 이는 점수가 낮게 보이는 이유에 대한 가장 설명력 있는 설명이기도 한데, 에이전트와 인간은 종종 동일한 대상을 보지 않으며, 오라클은 오직 인간의 목록만 보상하기 때문이다.

c-CRAB가 볼 수 없는 것

벤치마크는 자신의 맹점에 대해 명확히 밝히고 있으며, 우리도 마찬가지입니다. c-CRAB는 인간 리뷰어가 제기하지 않은 유효한 문제에 대해 점수를 주지 않습니다. 오라클은 인간 리뷰 의도입니다. 즉, 아무도 언급하지 않은 실제 버그를 찾아내는 에이전트는 그 버그에 대해 0점을 받습니다. 논문은 이를 직접적으로 말합니다. 자동 리뷰 도구가 인간 리뷰어가 식별하지 못한 다른 유용한 코멘트를 생성할 수 있지만, "다른 기존 벤치마크와 마찬가지로 c-CRAB는 이러한 추가 코멘트를 직접 평가하지 않는다."

그 한 문장이 이 결과에 대한 대부분의 보도를 정정한다. “리뷰 에이전트는 40%만 해결한다”고 인용하면서, 그 수치가 에이전트들이 실제로 잡아내는 결함의 수를 측정한 것처럼 말하는 사람은 그 숫자를 잘못 읽고 있는 것이다. 그 수치는 인간이 제기한 우려 사항을 에이전트들이 공동으로 해결한 수를 측정한다 — 더 좁고 훨씬 더 정직한 주장이다.

직접 실행하기

숫자를 재현하거나 자신의 리뷰어를 추가하려면, 복제 패키지는 c-CRAB-Benchmark/dataset에 공개되어 있습니다. README는 실제 문서이며, 그 실체에 대해 솔직하게 설명합니다. 설정은 code>uv sync/code>; Docker와 code>OPENAI_API_KEY/code> 또는 code>ANTHROPIC_API_KEY/code>가 필요하며, Claude Code는 자격 증명을 code>~/.claude/.credentials.json/code>에서 추가로 읽습니다. 이 조직은 또한 환경을 위한 사전 빌드된 Docker 이미지를 게시합니다.

구성: code>pipeline//code>에는 파이프라인 로직과 프롬프트가, code>execution//code>에는 Docker 이미지 빌더와 런타임 헬퍼가, code>results_preprocessed//code>에는 공개된 벤치마크 하위 집합(전처리된 인스턴스 410개)이, code>results_pipeline_funnel//code>에는 stage0–stage4 JSONL 파일과 퍼널 요약이, 그리고 code>raw_results_compressed//code>에는 원시 실험 출력이 들어 있습니다.

전체 실행을 재현하는 것은 다섯 단계입니다: Docker 환경을 빌드하고 (code>execution.build_swe_care/code>), 테스트를 생성하고 (code>run_testgen_full.sh/code>), 베이스라인 리뷰를 수집하고 (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>), 에이전트 해결을 실행하고 (code>run_batch_agent_resolution.py/code>), 그런 다음 평가합니다 (code>run_batch_tool_eval.py --tool <name>/code>). 다섯 번째 리뷰어를 추가하려면, 확장 지점이 플러그인 인터페이스가 아니라는 점을 유의하세요: 모든 도구에 대한 베이스라인 리뷰 프롬프트는 code>run_batch_baselines.py/code>에 있으며, README에는 더 깔끔한 방법이 문서화되어 있지 않습니다 — 그 스크립트를 편집하면 됩니다.

복제하기 전에 두 가지 사실을 더 말씀드리겠습니다. 논문은 CC BY 4.0으로 라이선스가 부여되어 있습니다. 저장소 페이지에는 코드에 대한 라이선스가 명시되어 있지 않으므로, 라이선스가 있다고 가정하지 마십시오. 또한 논문에는 벤치마크 실행에 드는 비용이나 토큰 사용량 수치가 공개되어 있지 않습니다. 그런 수치는 게재된 바가 없으므로, 우리가 임의로 만들어 내지 않겠습니다. 파이프라인이 암시하는 바는 다음과 같습니다. 184개 인스턴스에 걸쳐 PR마다 하나의 Docker 이미지를 만들고 에이전트 해결 패스를 추가로 수행하는 작업은, 노트북 하나로 오후에 끝낼 수 있는 규모가 아닙니다.

이것이 리뷰 파이프라인을 제공하는 모든 사람에게 의미하는 바

c-CRAB의 핵심 주장은 LLM 판정자가 신뢰할 수 없는 오라클이라는 것이다. 실행 가능한 오라클을 구축할 수 없다면 — 대부분의 팀이 그럴 수 없지만 — 가장 좋은 완화책은 판정자가 리뷰를 생성한 모델에서 실행되지 않도록 하는 것이다. 리뷰어와 같은 모델을 사용하는 판정자는 자기 자신과 동의하게 되며, 검증 과정은 여전히 숫자를 반환하는 형식적인 도장 찍기로 전락한다.

That is exactly the failure the routing recipe behind the reviewer we ship guards against — and it is a design parallel with c-CRAB’s critique, not a benchmark result. The harness runs an LLM judge anyway, as a second pass that clusters findings, scores each cluster 0–1 for whether it is a concrete defect in this change, and drops everything under a threshold. The recipe that governs it, code>recipes/orcacode-review.dsl.yaml/code>, is a public file. The Action never names a model: it calls a router alias, and the recipe decides. As provisioned, the recipe is four lines — the reviewer default is code>deepseek/deepseek-v4-flash-0731/code>, and a rule matching the header code>x-cr-lens: judge/code> sends the judge pass to code>z-ai/glm-5.3/code>, a different vendor. The recipe’s own words require that the judge “MUST NOT NAME THE DEFAULT’S MODEL”, because on the reviewer’s own model it “agrees with itself, so the pass goes inert while still reporting success”.

다른 공급업체의 심사자는 자가 일치도를 낮출 뿐이며, LLM 심사자를 테스트로 바꾸지는 않습니다. c-CRAB은 우리 리뷰어를 테스트하지 않았으며, 우리도 테스트했다고 암시하지 않겠습니다. OrcaCode Review는 리뷰 패스와 독립적인 검증 심사자를 실행하며, 시트(seat) 단위가 아닌 토큰 단위로 작동합니다. 모든 프롬프트가 공개되어 있으므로, 이와 같은 벤치마크에 적용하면 저희 수치가 아닌 직접 얻은 수치를 확인할 수 있습니다.

결론

c-CRAB은 점수가 실제로 의미하는 바를 대체로 신뢰할 수 있는 최초의 코드 리뷰 벤치마크입니다. 리뷰가 통과하려면 그 리뷰에 따라 조치했을 때 코드가 실제로 고쳐져야 합니다. 헤드라인 수치는 실제로 낮습니다. 최고 단일 도구는 32.1%, 통합은 41.5%입니다. 하지만 이 수치는 리뷰의 품질이 아니라 인간이 제기한 우려와의 겹침을 측정한 것이며, 유용성 데이터를 보면 대부분의 코멘트가 실제 신호임을 알 수 있습니다. 오래 지속되는 교훈은 논문 자체가 주장하는 바와 같습니다. 즉, 볼륨은 커버리지가 아니며, 에이전트와 인간은 서로 다른 것을 보며, 올바른 배포 방식은 인간-에이전트 협업입니다. 그리고 이 벤치마크는 공개되어 있으므로, 정직한 다음 단계는 자신의 리뷰어를 실행해 자신만의 수치를 얻는 것입니다.