AI 코드 리뷰 벤치마크를 신뢰해도 될까요?

이것들을 도구가 다른 사람의 테스트에서 무엇을 했는지 기록으로 볼 뿐, 순위로 봐서는 안 됩니다. 아래 표에 있는 모든 공급업체별 비교는 해당 작성자가 자신의 제품을 가장 먼저 배치하며, 같은 경쟁사라도 각기 다른 벤더 페이지에서는 매우 다른 수치를 얻게 되는데, 이는 각 페이지가 서로 다른 것을 계산하기 때문입니다. 차트 앞에 있는 방법 섹션을 읽은 후, 직접 자신만의 풀 리퀘스트(pull request)로 후보 목록을 실행해 보세요.

여기에 인용된 모든 페이지는 2026년 10월 5일에 읽었으며, ReviewBench 페이지는 10월 6일에 읽었습니다.

AI 코드 리뷰 벤치마크에 던져야 할 일곱 가지 질문

1. 누가 실행했는지, 그리고 그들의 제품이 표 안에 있나요?
2. 몇 개의 사례가 있으며, 누가 그것들을 선택했나요?
3. 누구(혹은 무엇)가 정답 키를 작성했나요?
4. 누가 또는 무엇이 댓글이 알려진 문제와 일치한다고 결정했나요?
5. 경쟁 도구들은 누가, 어떤 플랜으로, 어떤 설정으로 준비했나요?
6. 이 페이지에서

CodeRabbit은 다른 다섯 개 벤더들이 포함하고 있어 따라가기 쉽습니다. Augment's table에 따르면, CodeRabbit은 Augment의 '골든 코멘트(golden comments)' 대비 36%의 정밀도(precision)를 보입니다. Greptile는 Greptile의 50개 버그를 대상으로 44%의 발견율(catch rate)을 제시합니다. Macroscope은 Macroscope의 118개 런타임 버그에 대해 46%의 탐지율(detection rate)을 보여줍니다. Cursor는 공개 저장소의 코멘트를 대상으로 48.96%의 해결률(resolution rate)을 제시합니다. Bito는

답변 키(answer key)를 기준으로 할 때, 코멘트가 정확하려면 누군가 미리 나열한 이슈와 일치해야 합니다. Qodo는 정밀도(precision)를 "도구 생성 코멘트 중 실제 진실(ground truth) 이슈에 올바르게 대응하는 비율"로 정의합니다. 키에는 없지만 실제로 존재하는 버그는 도구의 감점 요인이 됩니다.

개발자 행동을 기준으로 할 때, 코멘트는 작성자가 코드를 변경했다면 정확합니다. Cursor는 다음과 같이 설명합니다: "식별한 버그 중 52%가 관련 PR이 병합될 무렵 해결되었으며, 이는 나머지는 오탐지(false positives)였음을 나타냅니다." 이 규칙 하에서는 작성자가 무시한 올바른 경고는 노이즈로 간주되고, 우연히 수정된 사소한 개선점(nit)은 신호(signal)로 간주됩니다. 포획률(catch rate)의 경우, 노이즈는 비용이 없습니다: Greptile은 "오탐지, 스타일 제안 및 관련 없는 코멘트가 포획률에 영향을 미치지 않았음"을 언급하며, 독자들에게 노이즈를 판단할 수 있도록 사례표(case tables)를 참고하도록 안내합니다.

판매업체들조차 어떤 숫자가 중요한지에 대해 의견이 분분합니다. Baz: "정밀도는 우리가 최적화하는 지표입니다." Qodo: "정밀도는 사용자 선호도에 따라 후처리(post-processing)할 수 있는 차원입니다." 만약 팀이 봇의 코멘트를 무시한다면, 개발자가 수정하는 것에 대한 정밀도를 보고, 버그가 메인 브랜치까지 도달하는지 확인하고 싶다면 신뢰하는 키에 대한 재현율(recall)을 살펴보십시오.

작성자들이 스스로 밝히는 한계점들

이 페이지들에서 가장 유용한 문장들은 종종 주의사항이며, 저는 차트보다 그것들을 먼저 읽을 것입니다. CodeRabbit: "13개의 사례는 작은 집합이며, 저희가 계속 그렇게 말씀드립니다." 그 사례들에서 Sonnet 5.5는 6개를 포착했고 Sonnet 5는 4개를 포착하여 두 개의 차이를 보였습니다.

Macroscope는 "오직 자체 실행 환경 버그만 감지하도록 설계되었기 때문에, Macroscope 코드 리뷰를 사용해 해당 유형의 문제만을 포착했다"고 언급하며 그 결과를 활용하여 자체 파이프라인을 개선했습니다. 동시에 "우리는 데이터셋에 있는 어떤 버그도 우리의 파이프라인에 인코딩하지 않았으며, 이 데이터를 사용하여 모델을 훈련시키지도 않았다"고 밝히고 추가로 다음과 같이 덧붙였습니다: "우리가 평가한 다른 도구들은 이 정확한 데이터셋으로 마주쳤을 법한 문제를 수정할 기회가 없었다는 점을 인정합니다."

Baz는 이 분야의 많은 초기 벤치마크들을 "일반화하기에는 너무 작고, 깨끗하게 유지하기에는 너무 정적이며, 단일 공급업체의 채점 선택에 너무 의존한다"고 평가절하합니다. CodeAnt는 더욱 직설적입니다: "게시된 대부분의 비교 분석은 공급업체들 스스로가 만들어낸 것입니다. 예상대로, 모든 벤치마크는 자신들의 도구를 승자로 선언했습니다."

독립적인 벤치마크가 있을까요?

Martian이 Code Review Bench를 오픈 소스로 공개했으며, 사이트에서 이를 "코드 리뷰 에이전트를 위한 편향되지 않은 OSS 벤치마크"라고 설명합니다. README에는 이 문제를 한 줄로 명시하고 있습니다: "이러한 도구들에 대한 공유 평가가 없기 때문에, 모든 회사가 스스로 숙제를 채점합니다." Martian의 README에 따르면, Martian은 공개하는 모든 도구에 대해 자체적으로 파이프라인을 실행하며(2026년 8월 25일 추가된 규칙), 50개의 풀 리퀘스트(3월 데이터에서는 137개)에 포함된 173개의 골든 코멘트를 기준으로 오프라인에서 점수를 매기고, 개발자들이 수정하는 새로운 풀 리퀘스트를 대상으로 온라인에서 점수를 매깁니다. 이는 첫 번째 질문과 파이프라인에 대한 다섯 번째 질문에 답을 주지만, 각 도구의 어떤 설정이 입력되었는지는 여전히 확인해야 하며 나머지는 동일하게 적용됩니다. 오프라인 순위와 온라인 순위가 다를 수 있는데, 그 이유는 측정하는 것이 다르기 때문이며, 이것이 r/codereview에서 이 질문을 한 사람을 당황하게 만들었습니다. README에는 "서로 다른 LLM 심사관들이 다르게 점수를 매길 수 있다"고 추가하면서도, "상위 5개 도구는 세 심사관 모두에게 동일하며, 대부분의 도구들은 최대 2개의 순위만 변동된다"고 보고합니다. 10월 5일 대시보드 데이터에서는 같은 다섯 가지 도구가 기본 보기에서 모든 심사관 아래에 나타났지만, 순서는 같지 않았습니다. 즉, 심사관들은 서로 다른 두 도구를 첫 번째로 지목했습니다. 공급업체들도 자신들의 스냅샷을 바탕으로 인용합니다: 2026년 3월 Baz는 "현재 결과에서 Baz가 정밀도(precision) 부문 1위를 차지했다"고 보고했고, CodeAnt는 F1 점수 기준으로 "전 세계적으로 3위에 올랐다"고 했습니다. CodeAnt가 보고한 F1 점수는 2026년 3월 16일 Martian의 오프라인 데이터와 일치하며, 3월 19일에 Martian은 중복된 발견 사항을 병합하여(커밋 720e1d3) 결과를 재점수했으며, 이로 인해 세 심사관 모두에게 1위가 바뀌었습니다.

GitHub가 10월 5일에 발표한 ReviewBench는 풀 리퀘스트(pull requests), 골든 파인딩(golden findings), 심사 프롬프트(judge prompt)까지 모두 공개된 오픈 소스입니다. 하지만 GitHub가 이 도구를 운영하며, 자체 Copilot Code Review가 최고 순위를 차지하고 있습니다. 발표 내용에 따르면, Copilot 코드 리뷰를 사용한 것이 "제품 개선에 도움이 되었다"고 합니다. extraction notes에는 LLM 제작사들이 "골든 세트(golden set)를 생성하는 데 사용된 모델 쪽으로 편향시킬 위험이 있다"는 경고가 담겨 있습니다. 10월 6일의 golden files에서, 참 양성(true positive)으로 표시된 2,623개의 발견 사항 중 1,185개는 "ccr"로 시작하는 제작자 필드를 가지고 있는데, 이는 발표에서 사용한 Copilot Code Review의 약어입니다. 동일한 문제를 발견한 제작자는 복사본 중 하나만 보관했습니다.

사용자 자신의 풀 리퀘스트로 후보군 테스트 실행하기

몇몇 저자들이 이 방법을 제안합니다. Bito는 "모든 벤치마크를 스냅샷으로 취급하고, 큰 제품 업데이트가 있거나 장기 계약을 앞두고 있을 때 테스트를 다시 실행하라"고 조언했습니다. CodeRabbit은 도구보다는 모델을 테스트하는 방법을 제시하며 "알려진 결과가 있는 자체 저장소의 풀 리퀘스트로 실행해 보라"고 말합니다.

1. 이미 버그를 알고 있는 병합된(merged) 풀 리퀘스트, 롤백(reverts), 긴급 패치(hotfixes) 및 사고 후속 조치에서 가져옵니다.
2. 각 변경 사항을 커밋 이전 시점부터 다시 열어 모든 도구가 Greptile과 Macroscope가 했던 것처럼 동일한 diff를 보도록 합니다.
3. 각 도구를 기본 설정뿐만 아니라 실제로 실행할 방식대로 설정합니다.
4. 알려진 버그가 발견되었는지 여부와 그곳에 도달하기 위해 사람이 몇 개의 댓글을 읽어야 했는지를 별도로 점수화하고, 리뷰당 시간과 비용을 기록합니다.

이러한 단계들은 Sigma(Mnemoverse, 저자의 회사)처럼 이러한 벤치마크 중 어느 곳에도 속하지 않은 도구를 평가하는 방법이며, 이는 클로즈 베타 버전의 GitHub 풀 리퀘스트 검토기입니다. 이 도구는 Claude Code와 OpenAI 모델에서 실행되며, 해당 팀은 매일 자체 저장소를 이용해 테스트를 진행합니다.

그렇다면, 신뢰할 수 있을까?

리더보드보다는 방법론(method sections)을 더 신뢰하세요. 특정 벤더의 벤치마크는 그 벤더가 측정하기로 선택한 것, 선택한 케이스들, 그리고 작성한 규칙에 따라 점수를 매긴 공정한 기록일 뿐이며, 더 나은 도구들은 스스로 그렇게 말합니다. 발표된 수치를 활용하여 시험해 볼 만한 두세 가지 도구를 고른 다음, 직접 여러분의 풀 리퀘스트(pull requests)가 결정하게 하세요.