HeyDeer, ReviewBench에서 가장 높은 정밀도 기록

ReviewBench는 GitHub이 만든 AI 코드 검토 공개 벤치마크입니다. 187개 저장소의 실제 풀 리퀘스트 219개에서 각 검토자를 실행하고, 검토자가 보고한 내용을 사람이 직접 검토하고 분류한 발견 사항과 비교합니다.

이제 HeyDeer도 리더보드에 올랐습니다. 리더보드의 기본 보기인 심각도가 높은 발견 사항 기준으로, HeyDeer는 리더보드의 모든 검토자 중 가장 높은 정밀도인 99.0%를 기록했습니다. HeyDeer가 보고한 심각한 문제는 거의 모두 실제 문제였습니다.

우연히 얻은 결과가 아닙니다. 정밀도는 처음부터 HeyDeer의 첫 번째 설계 목표였습니다. 이 글에서는 그 이유와 이를 달성하는 방법을 설명합니다.

1. 숫자가 의미하는 것

ReviewBench는 두 가지 주요 점수를 보고합니다(자세한 내용은 방법론 참고).

• 정밀도: 검토자가 보고한 문제 중 벤치마크가 판단할 수 있는 것 가운데 실제 문제의 비율.
• 재현율: PR에 있는 알려진 문제 중 검토자가 찾아낸 비율.

두 점수는 서로 반대 방향으로 움직입니다. 모든 것을 보고하는 검토자는 더 많은 문제를 찾지만 노이즈도 늘어나고, 거의 아무것도 보고하지 않는 검토자는 틀리는 일도 드물지만 쓸모 있는 일도 드뭅니다. ReviewBench가 공개한 실행 결과에서 심각도가 높은 발견 사항에 대한 HeyDeer의 재현율은 51.4%로 리더보드의 대부분 검토자와 비슷한 수준이었고, 정밀도는 가장 높았습니다.

2. 정밀도가 중요한 이유

사람에게: 노이즈가 진짜 버그를 가린다

오탐 하나하나가 사람의 시간을 빼앗습니다. 의견을 읽고, 코드를 확인하고, 그 의견이 틀렸다고 판단하기까지 시간이 듭니다. 더 큰 비용은 나중에 옵니다. 노이즈를 몇 번 겪고 나면 사람들은 검토자의 의견이 대개 틀린다는 것을 알게 되고 대충 훑어보기 시작합니다. 그러다 진짜 버그 하나가 나머지와 함께 그냥 지나가 버립니다.

의견 여덟 개 중 여섯 개가 틀린 검토는 진짜 의견 세 개만 있는 검토보다 못합니다. 검토자는 사람들이 그 말을 계속 읽어 줄 때만 쓸모가 있습니다.

코딩 에이전트에게: 오탐이 코드가 된다

검토 의견을 코딩 에이전트에게 바로 넘기는 팀이 점점 늘고 있습니다. 에이전트가 반박할 때도 있지만, 연구에 따르면 수정 요청이 틀렸다는 것을 알아차린 뒤에도 그대로 따르는 경우가 많고, 그 과정에서 모르는 사이에 새로운 오류를 만들어 냅니다(Jaiswal et al., 2026). 오탐은 null이 될 수 없는 값에 대한 null 검사, 예외를 던질 수 없는 코드를 감싼 try/catch, 이미 검증된 입력에 대한 검증 코드가 됩니다.

하나하나는 무해해 보입니다. 하지만 쌓이면 코드베이스가 비대해지고, 코드가 실제로 보장하는 것이 무엇인지 흐려지며, 다음 사람이나 다음 에이전트가 읽고 유지보수할 것이 늘어납니다. 검토를 자동화할수록 정밀도는 더 중요해집니다. 노이즈를 걸러 줄 사람이 남아 있지 않기 때문입니다.

3. HeyDeer가 높은 정밀도를 유지하는 방법

여러 모델이 검토하고 서로 교차 검증

단일 모델은 문제를 놓치기도 하고 없는 문제를 보고하기도 하며, 같은 모델을 여러 개 돌려도 같은 실수를 반복하기 쉽습니다. HeyDeer는 서로 다른 회사의 모델이 각 변경을 검토하게 하고, 의심되는 문제 하나하나를 PR에 올리기 전에 독립적으로 검증합니다. 모델마다 사각지대가 다르기 때문에, 교차 검증으로 한 모델이 틀린 부분을 상당 부분 잡아낼 수 있습니다.

의견이 일치한다고 해서 증거가 되지는 않습니다. 두 모델이 같은 방식으로 틀릴 수도 있습니다. 발견 사항을 게시할지는 근거가 결정합니다.

모든 발견 사항에는 근거가 필요하다

발견 사항은 문제가 어떻게 일어나는지 보여 줘야 합니다. 실제 호출자, 사용자 동작 또는 입력에서 시작해 변경된 코드를 거쳐 결과에 이르기까지입니다. “null일 수 있습니다”로는 충분하지 않습니다. 검토자는 그 null이 어디서 오는지 보여 줘야 합니다. 확보한 근거로 확인할 수 없는 사실이 하나 있으면, 추측을 확실한 것처럼 내세우지 않고 그렇다고 밝히며 그 사실을 명시합니다.

추측하지 않고 소스를 읽는다

오탐의 상당수는 diff 밖에 있는 무언가의 동작을 추측하는 데서 생깁니다. HeyDeer의 검토자는 추측하는 대신 직접 확인합니다.

• 종속성 소스: 주장이 라이브러리의 동작에 달려 있으면, 검토자는 기억에 의존하지 않고 라이브러리의 실제 구현을 읽습니다.
• 문서: 검토자는 코드가 사용하는 프레임워크와 서비스의 공식 문서를 검색합니다.
• 샌드박스 확인: 읽는 것만으로 부족할 때는, 함수가 엣지 케이스를 어떻게 처리하는지처럼 범위가 좁은 주장을 격리된 샌드박스에서 테스트할 수 있습니다. 저장소의 코드 자체는 절대 실행되지 않습니다.

4. 재현율: 노이즈 없이 더 많이 찾기

아무 말도 하지 않으면 높은 정밀도는 쉽습니다. 그래서 재현율도 똑같이 중요합니다. ReviewBench가 측정한 버전 이후로 HeyDeer의 재현율을 개선했으며, ReviewBench가 새 결과를 공개하면 수치를 공유하겠습니다.

핵심은 찾는 일과 걸러 내는 일을 분리하는 것입니다. 문제를 찾는 검토자는 근거로 뒷받침할 수 있는 후보를 작거나 가능성이 낮아 보여도 모두 보고하고, 무엇이 실제 문제인지는 검증 단계에서 판단합니다. 검증이 정밀도를 지켜 주기 때문에, 탐색 단계는 PR에 노이즈를 더 보내지 않고도 더 깊이, 더 다양한 관점에서 살펴볼 수 있습니다.

얼마나 볼지도 직접 정할 수 있습니다. HeyDeer의 피드백 범위를 사용하면 팀이 워크스페이스나 개별 저장소 단위로 중요한 발견 사항만 볼지, 확인된 발견 사항을 모두 볼지 정할 수 있습니다.

5. 벤치마크에 대하여

어떤 벤치마크도 모든 것을 말해 주지는 않습니다. ReviewBench는 연구 미리보기 단계이고, 위의 수치는 기본 보기인 심각도 높음 기준이라 심각도 필터에 따라 달라집니다. 또 점수 하나로는 검토자가 여러분의 코드베이스나 팀에 얼마나 잘 맞는지 알 수 없습니다. 그래도 저희는 ReviewBench가 실제 PR에서 검토자를 비교하는 공정하고 열린 방법이라고 생각하며, 공개적으로 평가받게 되어 기쁩니다.

여러분의 PR에서 직접 사용해 보세요

가장 좋은 벤치마크는 여러분의 코드입니다. HeyDeer에는 무료 요금제가 있으므로 지금 쓰고 있는 검토자와 같은 PR에서 실행해 보고 결과를 직접 비교할 수 있습니다.