AI 코드 리뷰는 실제로 쓸 만한가 — 측정된 증거가 말하는 정확도와 거짓 양성

• 들어가며 — "AI가 버그의 N%를 찾았다"는 문장이 왜 그 자체로는 무의미한가
• AI 리뷰 코멘트는 실제로 얼마나 반영되나 — 0.9%인가 73.8%인가
• 왜 같은 지표가 80배씩 벌어지나
• 거짓 양성은 얼마나 비싼가 — 텐센트의 76%
  • LLM을 거짓 양성 필터로 쓰면 어떻게 되나
• 구글은 이 문제를 20년 가까이 어떻게 관리해 왔나
• 리뷰 봇이 PR을 죽이는가 — 노이즈와 PR 포기
• 벤더의 숫자는 무엇을 재고 있나
  • Qodo 벤치마크 — 방법론이 있다는 것과 믿을 만하다는 것은 다르다
• 측정 자체가 무너지는 지점 — "해결함"은 정답이 아니다
• 그래서 팀은 실제로 어떻게 설정하나
• 언제 쓰지 말아야 하나
• 결정 규칙
• 마치며
• 참고 자료

들어가며 — "AI가 버그의 N%를 찾았다"는 문장이 왜 그 자체로는 무의미한가

먼저 결론부터 말하겠습니다. 2026년 7월 현재, 범용 AI 코드 리뷰어를 실제 프로덕션에서 벤더와 무관하게 측정한 정밀도·거짓 양성률 수치는 공개된 것이 사실상 없습니다. 공개된 것은 세 종류뿐입니다 — 벤더가 직접 만든 벤치마크, 개발자가 코멘트에 반응했는지를 대신 재는 대리 지표, 그리고 한 회사짜리 사례 연구. 이 글은 그 셋을 각각 뜯어봅니다.

그리고 이 사실 자체가 실무적으로 중요합니다. "AI 리뷰어가 버그의 N%를 잡았다"는 주장은 두 가지를 같이 주지 않으면 판단할 수 없습니다.

1. 어떤 데이터셋에서 재고, 정답(ground truth)을 누가 어떻게 만들었나
2. 거짓 양성률은 얼마인가 — 즉 그 N%를 얻기 위해 개발자가 몇 건의 헛소리를 읽어야 했나

두 번째가 빠진 재현율(recall)은 공짜로 100%를 만들 수 있습니다. 모든 줄에 "여기 버그 있을지도 모릅니다"라고 코멘트를 달면 됩니다. 리뷰 도구의 값은 잡아낸 것이 아니라 잡아내면서 만들지 않은 소음에서 나옵니다. 그래서 아래에서는 숫자를 볼 때마다 분모와 정답의 출처를 먼저 확인합니다.

이 글은 AI 코딩 모델 평가에서 신호와 잡음 가려내기 편의 문제의식을 코드 리뷰로 옮긴 것입니다. 저기서는 벤치마크가, 여기서는 리뷰 코멘트가 대상일 뿐, "숫자가 무엇을 재고 있는지 먼저 물어라"는 원칙은 같습니다.

AI 리뷰 코멘트는 실제로 얼마나 반영되나 — 0.9%인가 73.8%인가

가장 널리 쓰이는 대리 지표는 "개발자가 그 코멘트대로 코드를 고쳤나"입니다. 이 지표로 잰 공개 측정치가 두 개 있는데, 서로 정면으로 충돌합니다.

측정 A — 오픈소스 (Gan 등, arXiv 2508.18771). 깃허브 워크플로용 AI 코드 리뷰 액션 16종을 골라, PR이 50건 이상인 성숙한 저장소 178곳에서 AI가 생성한 리뷰 코멘트 22,326건을 수집했습니다. 그중 5,652건을 GPT-4.1로 유효성 판정해 3,955건을 "유효(구체적이고 실행 가능)"로 분류한 뒤, o3-mini로 실제 반영 여부를 판정했습니다. 결과는 이렇습니다.

• 유효한 AI 코멘트 중 실제 코드 변경으로 이어진 비율: 도구에 따라 0.9~19.2%
• 같은 기준으로 잰 사람 리뷰 코멘트: 60%
• 헝크(hunk) 단위로 코멘트하는 액션: 6.5~19.2% / 파일 단위 액션: 0.9~4.2%
• 최고는 coderabbitai/ai-pr-reviewer 19.2%, 최저는 mattzcarey/code-review-gpt 0.9%

측정 B — 한 기업 내부 (Cihan 등, arXiv 2412.18531). 다국적 가전기업 Beko가 오픈소스 Qodo PR-Agent 기반 리뷰 봇(GPT-4 Turbo)을 도입한 사례입니다. 10개 프로젝트 238명이 접근 권한을 가졌고, 그중 3개 프로젝트의 PR 4,335건(자동 리뷰가 붙은 것은 1,568건)을 분석했습니다. 봇 코멘트 4,408건 중 필터링을 거쳐 병합된 PR에 달린 1,408건을 집계한 결과입니다.

• "Resolved"로 라벨된 코멘트: 73.8% ("Won't Fix"는 21.3%)
• 프로젝트별로는 55%에서 90%까지 벌어짐

같은 이름의 지표가 0.9%와 73.8% 사이에 있습니다. 최대 80배 차이입니다. 어느 쪽도 틀리지 않았습니다 — 서로 다른 것을 재고 있을 뿐입니다.

왜 같은 지표가 80배씩 벌어지나

차이는 도구 성능이 아니라 측정 조건에서 나옵니다. 네 가지가 다릅니다.

첫째, 분모가 다릅니다. 측정 B의 73.8%는 병합된 PR에 달린 코멘트만 셉니다. 버려진 PR에 달린 코멘트는 애초에 집계에서 빠집니다. 리뷰가 나빠서 PR이 죽은 경우가 분모에 안 들어가니, 이 숫자는 구조적으로 위쪽으로 편향됩니다. 측정 A는 반대로 성숙한 오픈소스 저장소 전체의 유효 코멘트를 봅니다.

둘째, 라벨을 만드는 힘이 다릅니다. Beko에서는 PR을 병합하려면 모든 리뷰 코멘트의 상태를 개발자가 명시적으로 확정해야 합니다. 즉 "Resolved"는 자발적 동의가 아니라 병합 조건을 통과하기 위한 절차 행위이기도 합니다. 오픈소스 기여자에게는 그런 강제가 없습니다.

셋째, 정답을 만드는 주체가 다릅니다. 측정 A의 "반영됨" 라벨은 사람이 아니라 LLM(GPT-4.1 + o3-mini)이 커밋을 보고 추론한 것입니다(수작업 주석 부분집합으로 검증했다고 밝히고 있습니다). 측정 B는 개발자 본인이 단 라벨입니다.

넷째, 도구와 모델이 다릅니다. 측정 A는 깃허브 액션 16종, 측정 B는 Qodo PR-Agent 하나입니다.

여기서 얻을 실무 규칙은 단순합니다. "코멘트 반영률 N%"라는 숫자를 보면, 병합된 PR만 셌는지, 라벨을 강제했는지, 정답을 누가 만들었는지를 먼저 물어보십시오. 이 셋을 모르면 그 숫자는 다른 조직의 숫자와 비교할 수 없습니다. 자기 팀 숫자와도 비교할 수 없습니다.

거짓 양성은 얼마나 비싼가 — 텐센트의 76%

거짓 양성이 "비용의 대부분"이라는 말은 자주 나오지만, 실제로 잰 숫자는 드뭅니다. 하나가 텐센트에서 나왔습니다(arXiv 2601.18844, 2026년 1월).

텐센트는 자체 개발한 정적 분석기 BkCheck를 광고·마케팅 서비스(AMS) 사업부 코드베이스에 돌립니다. 2024년 9월부터 2025년 6월까지의 실제 알람 중 코드 맥락이 확보된 것을 추려 433건의 데이터셋을 만들었습니다. 구성이 핵심입니다.

• 거짓 양성 328건, 진짜 버그 105건 → 거짓 양성 비율 76%
• 논문은 여기에 단서를 답니다. 코드 맥락이 불완전해 제외된 케이스까지 감안하면 실제 거짓 양성률은 90%를 넘는다고 저자들이 추정합니다(이건 측정이 아니라 저자 추정입니다)
• 알람 1건당 수동 검토 시간: 라운드당 약 10분, 최대 2라운드 → 10~20분 (개발자·리뷰어 5명 인터뷰 기반)

왜 이렇게 높은가. 논문의 설명은 설계상의 선택입니다 — 기업용 정적 분석기는 버그를 놓치지 않으려고 정밀도보다 재현율을 우선합니다. 그래서 실행 불가능한 경로까지 보수적으로 경고하고, 결과적으로 오픈소스 분석기보다도 거짓 양성률이 높아집니다.

산수를 해 보면 비용 구조가 보입니다. 알람 100건이면 그중 76건이 헛것이고, 건당 10~20분이면 헛것에만 12.7~25.3시간이 듭니다. 잡아낸 24건의 값이 이 시간을 넘어야 도구가 이득입니다. "버그를 N개 찾았다"가 아니라 이 뺄셈이 실제 손익계산서입니다.

LLM을 거짓 양성 필터로 쓰면 어떻게 되나

같은 논문이 이어서 흥미로운 것을 측정합니다. LLM에게 "이 알람이 진짜냐"고 물어보면 어떻게 될까요. 기본 프롬프트만 준 경우입니다.

기본 프롬프트 행의 정밀도를 보십시오. 0.26에서 0.29 사이입니다. 그런데 이 데이터셋에서 진짜 버그의 기저율은 105/433 = 24.2% 입니다. 즉 모든 알람에 "진짜입니다"라고 답하는 바보 분류기의 정밀도가 24.2%입니다. 최신 모델 네 개가 기저율보다 2~5%포인트 나은 셈입니다. 이건 신호가 아니라 잡음에 가깝습니다.

반대로 정적 분석에서 뽑은 경로 제약(path constraint)을 LLM 추론에 결합한 LLM4PFA는 정확도 0.93~0.94로 뜁니다. 논문의 표현으로 거짓 양성의 94~98%를 제거합니다. 모델을 바꿔서 얻은 결과가 아니라 구조를 바꿔서 얻은 결과라는 점이 중요합니다.

다만 초록의 "높은 재현율을 유지하면서"라는 표현은 표를 보면 조심해서 읽어야 합니다. LLM4PFA의 재현율은 0.75~0.88입니다. 진짜 버그의 12~25%가 필터에 걸려 조용히 사라진다는 뜻입니다. 논문 저자들도 이걸 알고 있어서, 기업은 재현율을 우선하므로 Claude(0.88)나 DeepSeek-R1(0.86) 조합이 실무에 더 적합하다고 씁니다. 거짓 양성 필터는 공짜가 아니라 거짓 음성과의 교환입니다.

비용은 알람당 2.1~109.5초, 금액으로는 0.0011~0.12달러입니다. 사람이 10~20분 쓰는 것에 비하면 자릿수가 다릅니다. 한계도 분명합니다 — 데이터가 텐센트 C/C++ 코드에 한정되고, 기밀 때문에 데이터셋은 공개되지 않습니다.

구글은 이 문제를 20년 가까이 어떻게 관리해 왔나

거짓 양성 거버넌스에 대해 지금도 가장 구체적인 공개 자료는 LLM 이전 시대의 것입니다. 구글의 Tricorder 논문(Sadowski 등, Communications of the ACM 2018년 4월호, 61권 4호)입니다. LLM 얘기는 한 줄도 없지만, 이 글의 주제에는 오히려 이쪽이 더 정확합니다.

핵심은 "실효 거짓 양성(effective false positive)" 이라는 정의입니다. 논문의 정의를 옮기면 이렇습니다 — 개발자가 그 이슈를 보고도 아무 조치를 취하지 않았다면 실효 거짓 양성이다. 분석기가 틀린 지적을 했는데 개발자가 가독성 때문에 어차피 고쳤다면 그건 실효 거짓 양성이 아니고, 반대로 분석기가 진짜 결함을 정확히 짚었는데 개발자가 이해하지 못해 넘어갔다면 그건 실효 거짓 양성입니다. 논문은 이 구분의 이유를 명시합니다 — 도구 저자가 아니라 개발자가 그 도구의 거짓 양성률을 결정한다.

그 위에 구글이 세운 규칙이 있습니다.

• 코드 리뷰 단계에 노출되는 체크는 실효 거짓 양성 10%까지 허용 (컴파일 타임 체크는 더 엄격)
• 리뷰 체크의 조건 네 가지: 이해 가능할 것, 실행 가능하고 고치기 쉬울 것, 실효 거짓 양성 10% 미만일 것(개발자가 최소 90%는 진짜 문제를 짚었다고 느껴야 함), 코드 품질에 실질적 영향이 있을 것
• Tricorder는 리뷰어의 "Please fix" 대 "Not useful" 클릭 비율을 추적합니다. 이 비율이 10%를 넘으면 해당 분석기를 끕니다 — 작성자가 개선할 때까지
• "Not useful" 클릭은 자동으로 이슈를 생성해 분석기 소유 팀에 라우팅됩니다

2018년 1월 기준 규모도 같이 공개돼 있습니다. 하루 약 50,000건의 코드 리뷰 변경을 분석했고, 피크에는 초당 3회 분석이 돌았습니다. 리뷰어는 하루 5,000회 넘게 "Please Fix"를 눌렀고, 자동 수정은 하루 약 3,000회 적용됐으며, "Not useful" 클릭은 하루 250회였습니다. 250 나누기 5,000은 5%입니다 — 자기들이 정한 10% 임계 아래입니다. 숫자가 정책과 맞아떨어집니다.

여기서 두 가지를 가져갈 수 있습니다. 하나는 10%라는 구체적 기준선이 이미 존재한다는 것이고, 다른 하나는 끄는 메커니즘이 있어야 기준선이 의미를 갖는다는 것입니다. 오늘날 어떤 AI 리뷰 벤더도 "우리 도구의 실효 거짓 양성률은 X%이고, 넘으면 자동으로 체크를 끕니다"라고 말하지 않습니다.

그리고 정직하게 덧붙이면, 구글의 이 정의에는 뒤에서 볼 약점이 있습니다 — 실효 거짓 양성은 개발자의 행동으로 정의되는데, 개발자의 행동이 항상 품질 판단인 것은 아닙니다.

리뷰 봇이 PR을 죽이는가 — 노이즈와 PR 포기

가장 최근 측정은 MSR '26에 실린 연구입니다(arXiv 2604.03196, DOI 10.1145/3793302.3793614). AIDev 데이터셋의 PR 리뷰 코멘트 19,450건에서 실제 코드 리뷰 에이전트(CRA)가 리뷰한 PR 3,109건을 추출하고, 그중 "Commented" 상태인 2,456건을 봤습니다.

차이는 23.17%포인트이고, 카이제곱 검정 결과는 84에 근접한 통계량(83.0319, 자유도 8)에 p 값 0.001 미만입니다.

이어서 저자들은 포기된 CRA 단독 PR 98건의 코멘트를 "신호 대 잡음비"로 분류했습니다. 런타임 오류·크래시·컴파일 실패·API 파괴·보안 취약점을 1차 신호로, 아키텍처·성능·유지보수성 문제를 2차 신호로 놓고, 전체 코멘트 대비 신호 코멘트의 비율을 계산하는 방식입니다(두 연구자 독립 분류, 코헨의 카파 0.75).

• 98건 중 59건(60.2%)이 신호 비율 0~30% 구간 — 코멘트 3분의 2 이상이 실행 불가능
• 31~59%: 14건(14.3%) / 60~79%: 7건(7.1%) / 80~100%: 18건(18.4%)
• CRA 13종 중 12종(92.31%)의 평균 신호 비율이 60% 미만
• 개별 도구: Copilot 19.79%, github-advanced-security[bot] 27.62%, codefactor-io[bot] 0.00%, entelligence-ai-pr-reviews[bot] 52.29%(7건), cursor[bot] 43.40%(5건)

숫자는 인상적이지만, 이 연구의 한계를 그대로 옮기는 것이 중요합니다. 논문 스스로 "위협" 절에 적어 둔 것부터.

• 상관관계는 인과관계가 아니다 — 저자들이 명시적으로 씁니다. CRA가 붙어서 PR이 죽은 것인지, 원래 죽을 만한 PR에 사람이 안 붙고 봇만 붙은 것인지 이 설계로는 구분되지 않습니다
• 신호 분류가 키워드 기반이라 키워드 없는 유효 피드백을 놓칠 수 있음
• 데이터가 AI 생성 코드가 있는 깃허브 저장소에 한정됨

그리고 논문이 적지 않은 한 가지를 제가 덧붙이겠습니다. 신호 비율을 잰 대상이 "포기된" PR 98건뿐입니다. 병합된 CRA 단독 PR 127건의 신호 비율은 측정되지 않았습니다. 비교군이 없으면 "낮은 신호 비율이 포기의 원인"이라는 결론은 데이터가 지지하지 못합니다 — 병합된 PR의 신호 비율도 똑같이 낮았을 수 있으니까요. 이 연구가 확실히 보여 주는 것은 "CRA 단독 리뷰 PR이 더 많이 버려진다"와 "버려진 PR의 코멘트는 대체로 저신호였다" 두 가지이고, 둘을 잇는 화살표는 아직 가설입니다.

이 논문이 겨냥한 업계 주장도 확인해 둘 필요가 있습니다. 논문은 "업계 보고서는 CRA를 켜면 PR의 80%에 사람 코멘트가 필요 없다고 주장한다"고 씁니다. 원출처는 Qodo의 2025 State of AI Code Quality 보고서입니다.

벤더의 숫자는 무엇을 재고 있나

Qodo 보고서를 직접 열어 보면 구조가 이렇습니다.

• 보고서의 뼈대는 개발자 609명 대상 설문입니다. "AI 리뷰를 쓰는 사람의 81%가 품질 개선을 봤다", "10배 속도 향상을 주장하는 팀 중 69%가 품질이 좋아졌다고 답했다" — 전부 자기 보고 인식이지 측정이 아닙니다
• 문제의 80%는 설문이 아닙니다. "Qodo product insight"라는 별도 딱지가 붙은 벤더 자체 제품 데이터이고, 문장은 "AI 리뷰 도구를 켜면 PR의 80%에 사람 코멘트나 리뷰가 달리지 않는다"입니다. 분모도, 기간도, 저장소 모집단도, "사람 코멘트"의 정의도 공개돼 있지 않습니다
• 같은 형식의 다른 주장도 있습니다 — "고심각도(9~10점) 이슈가 PR의 17%에서 발견됐다". 심각도를 매긴 것은 Qodo 자신의 모델입니다

그리고 확인할 수 있는 사실 하나. 이 보고서 전문에 "false positive", "precision", "recall"이라는 단어는 0번 등장합니다. 품질을 논하는 벤더 대표 보고서에 정밀도도 거짓 양성률도 없습니다.

여기서 공정하게 덧붙일 것이 둘 있습니다. 하나는 MSR 논문 쪽의 과장입니다. "사람 코멘트가 안 달렸다"와 "사람 없이 처리 가능하다"는 같은 말이 아닙니다 — 코멘트 없이 승인된 PR도 사람이 본 것이니까요. 벤더 주장을 비판하는 논문이 그 주장을 살짝 부풀려 인용한 셈입니다. 양쪽 다 조심해서 읽어야 합니다.

다른 하나는 Qodo에 대한 크레딧입니다. Qodo는 저 보고서와 별도로 방법론을 공개한 벤치마크를 운영합니다(2026년 2월 4일 공개, 3월 12일 수정).

Qodo 벤치마크 — 방법론이 있다는 것과 믿을 만하다는 것은 다르다

방법은 이렇습니다. 실제로 병합된 프로덕션급 오픈소스 PR을 가져와, LLM으로 결함을 주입합니다. 저장소별 베스트 프랙티스 규칙을 먼저 추출해 컴플라이언스 위반을 심고, 추가로 논리 오류·엣지 케이스·경쟁 조건·자원 누수 등 기능 버그를 1~3개 더 심습니다. 그렇게 만든 PR 100건, 이슈 580건에 8개 도구(Qodo + 경쟁 7종)를 기본 설정으로 돌리고, LLM-as-a-judge로 채점합니다. 벤치마크 저장소는 깃허브에 실제로 공개돼 있습니다(cal.com, tauri, redis, Ghost, aspnetcore 등의 포크).

결과로 Qodo가 F1 60.1% 로 1위입니다. 벤더 자체 측정입니다.

이 숫자를 어떻게 읽어야 하나. 먼저 방법론과 데이터를 공개했다는 것만으로 대부분의 경쟁사보다 낫습니다. 그런데 설계에 구조적 문제가 있습니다.

• 거짓 양성의 정의가 이 설계에서 깨집니다. Qodo의 정의는 "정답 목록에 없는 이슈를 지적하면 거짓 양성"입니다. 그런데 정답 목록은 주입한 결함 목록입니다. 도구가 원래 그 PR에 있던 진짜 버그를 찾아내면 거짓 양성으로 집계됩니다. Qodo도 이걸 알고 검증 단계에서 자연 발생 이슈를 정답에 수동 추가한다고 밝히지만, Qodo의 검증자가 놓친 진짜 버그는 여전히 도구의 감점입니다. 즉 여기서의 "정밀도"는 개발자가 체감하는 거짓 양성률과 같은 물건이 아닙니다
• 주입된 버그는 자연 발생 버그가 아닙니다. 결함의 분포를 주입기가 정합니다. 주입기와 같은 "결함관"을 가진 도구가 유리합니다. 그 주입기를 만든 것도, 경쟁에 참가한 것도 Qodo입니다
• 채점이 LLM 심사입니다. 바로 다음 절에서 보겠지만, 코드 리뷰 코멘트에 대한 LLM 심사는 신뢰도가 측정된 바 있고 결과가 좋지 않습니다
• 자기만 설정이 두 개입니다. 경쟁 도구는 기본 설정 하나로 돌리고, Qodo는 Precise와 Exhaustive 두 구성을 보고합니다
• 정밀도가 낮은 것에 대한 Qodo의 해명은 "정밀도는 후처리로 튜닝 가능한 차원이고 재현율이야말로 근본적 제약"이라는 것입니다. 일리 있지만, 정밀도가 아쉬운 쪽이 하기 딱 좋은 주장이기도 합니다

그럼에도 이 벤치마크에서 가장 인용할 만한 사실은 따로 있습니다. 자기가 설계하고 자기가 채점한 벤치마크에서 1등의 F1이 60.1% 라는 것입니다. 마케팅 문구("PR의 80%에 사람이 필요 없다")와 같은 회사가 낸 숫자입니다. 그리고 Qodo 자신의 관찰에 따르면 나머지 도구 대부분은 정밀도는 높고 재현율은 극히 낮은 쪽에 몰려 있습니다 — 제일 뻔한 것만 지적하고 조용히 있는 전략입니다.

측정 자체가 무너지는 지점 — "해결함"은 정답이 아니다

지금까지의 측정은 거의 전부 "개발자가 코멘트에 반응했나"에 기대고 있습니다. 구글의 실효 거짓 양성도, Gan 등의 반영률도, Cihan 등의 73.8%도 마찬가지입니다. 그럼 그 라벨은 믿을 만한가.

2026년 4월 논문이 정확히 이걸 검증했습니다(arXiv 2604.24525). 대상은 앞서 나온 Beko의 바로 그 데이터입니다. 개발자가 fixed/wontFix로 라벨한 봇 코멘트 2,604건(fixed 1,733건 약 66%, wontFix 871건 약 34%)에 G-Eval과 LLM-as-a-Judge를 각각 이진/리커트 방식으로 돌려, 개발자 라벨과 얼마나 일치하는지 쟀습니다.

일치율 0.44~0.62. 최고 성적은 G-Eval 리커트 + GPT-4.1-mini의 0.62입니다. 흥미롭게도 가장 최신·최강 모델인 GPT-5.2가 최고가 아닙니다.

그 최고 구성의 세부 지표가 이 글에서 가장 중요한 대목입니다.

F1 0.76은 그럴싸해 보입니다. 일치율 62%도 나쁘지 않아 보입니다. 그런데 MCC(매튜스 상관계수)가 전부 0 근처이고 일부는 음수입니다. MCC는 클래스 불균형을 보정한 상관계수이고, 0이면 정답과 아무 상관이 없다는 뜻입니다. 논문의 표현 그대로, 일치율과 F1만 보면 심사자의 신뢰도가 과대평가된다는 것입니다.

논문이 보고한 숫자로 직접 산수를 해 보면 더 분명해집니다. 정답의 66.5%가 "fixed"이므로, 모든 코멘트에 무조건 "유용함"이라고 답하는 바보 심사자의 성적은 이렇게 됩니다.

바보 기준선 (항상 "유용함"):
  정밀도 = 1733/2604      = 0.665
  재현율 = 1.0
  F1     = 2(0.665)(1.0)/(0.665+1.0) = 0.799
  일치율 = 0.665
  MCC    = 0

최고 성적 LLM 심사자 (G-Eval 리커트 + GPT-4.1-mini):
  정밀도 = 0.66   재현율 = 0.90
  F1     = 0.76   일치율 = 0.62   MCC = -0.059

바보 기준선이 F1(0.799 대 0.76)에서도, 일치율(0.665 대 0.62)에서도 최고 LLM 심사자를 이깁니다. 이건 제가 논문의 공개 수치로 계산한 것이지 논문이 명시한 문장은 아닙니다. 다만 논문이 MCC를 굳이 보고한 이유("데이터셋이 불균형하므로")와 정확히 같은 방향입니다.

더 근본적인 문제는 왜 그런가입니다. 논문은 개발자 라벨 자체가 정답이 아니라고 봅니다.

• Beko에서는 PR 병합 전에 모든 코멘트의 상태를 확정해야 합니다. 즉 라벨링은 의무입니다
• 소프트웨어 엔지니어링 디렉터 인터뷰에서 나온 이야기 — 특히 wontFix 쪽은 개발자가 아주 빠르게 선택하는 경향이 있는데, 우선순위가 대개 변경을 프로덕션에 넣는 것이기 때문이라는 것입니다
• 평가 파이프라인은 PR diff와 제한된 메타데이터만 보지만, 개발자는 런타임 동작·아키텍처 제약·PR 밖의 안전장치까지 총체적으로 고려합니다. 그래서 고립해서 보면 기술적으로 타당한 코멘트가 실제로는 이미 다른 곳에서 처리됐거나 팀이 의도적으로 감수하기로 한 것일 수 있습니다

논문의 결론은 이렇습니다 — 개발자의 행동(해결/무시)은 코멘트 품질만이 아니라 맥락적 제약, 우선순위 결정, 워크플로 역학을 함께 반영하므로 객관적 정답으로 취급할 수 없다.

이게 구글의 정의로 되돌아옵니다. 구글의 실효 거짓 양성은 "개발자가 조치를 안 했다"로 정의됩니다. Beko 연구는 그 정의가 조직의 압력을 함께 측정한다는 것을 보여 줍니다. 구글의 정의가 틀렸다는 게 아닙니다 — 구글은 개발자 인식을 재려고 의도적으로 그렇게 정의했고, 그건 도구를 끌지 말지 정하는 데는 정확히 맞는 지표입니다. 다만 그 숫자를 조직 간에 비교하거나 "정확도"로 읽으면 안 된다는 뜻입니다.

여기서 이 글 전체의 뼈대가 드러납니다. 리뷰 코멘트의 유용성을 값싸게 자동으로 재는 방법은 아직 없습니다. 대리 지표는 조직 압력에 오염돼 있고, LLM 심사는 기저율을 못 이깁니다. 그러니 "AI 리뷰가 우리 팀에 도움이 되는가"라는 질문에는 지금으로선 표본을 떠서 사람이 직접 읽는 것 말고 신뢰할 방법이 없습니다.

그래서 팀은 실제로 어떻게 설정하나

공개된 증거를 종합하면, 잘 되는 설정에는 공통점이 있습니다. 아래는 전부 위에서 인용한 측정에 근거한 것입니다.

1. 좁게 설정한다. 범용 "이 PR을 리뷰해 줘"가 가장 나쁩니다. 텐센트에서 기본 프롬프트 LLM의 정밀도가 기저율 수준(0.26~0.29 대 0.242)이었던 것이 이 얘기입니다. 반대로 정적 분석의 경로 제약을 결합해 판단 범위를 좁힌 LLM4PFA는 정확도 0.93~0.94로 올라갔습니다. 모델이 아니라 구조를 바꾼 결과입니다.

2. 코멘트를 코드 위치에 붙인다. Gan 등의 측정에서 헝크 단위 액션의 반영률(6.5~19.2%)이 파일 단위 액션(0.9~4.2%)보다 일관되게 높았습니다. 같은 연구에서 간결하고 코드 스니펫을 포함한 코멘트가 더 잘 반영됐습니다.

3. 자동 트리거보다 수동 트리거가 낫다. 역시 Gan 등의 결과입니다. 사람이 요청했을 때 코멘트 반영률이 더 높습니다. 원치 않을 때 밀어 넣는 피드백은 잘 안 읽힙니다.

4. 거짓 양성 예산을 정하고, 넘으면 끈다. 구글의 10%가 유일하게 검증된 기준선입니다. 중요한 건 숫자가 아니라 끄는 메커니즘입니다 — "Not useful" 버튼, 소유 팀으로의 자동 라우팅, 임계 초과 시 비활성화. 이 셋이 없으면 10%는 그냥 슬라이드의 숫자입니다.

5. 표본을 떠서 사람이 읽는다. Beko 후속 연구의 권고 그대로입니다 — 자동 점수는 정답이 아니라 약한 신호로 취급하고, 무엇을 검사할지 우선순위를 정하는 트리아지에만 쓰고, 승인/기각 결정에는 쓰지 마십시오. 그리고 모델이나 프롬프트를 바꿀 때마다 재평가하십시오(같은 논문: 모델과 루브릭에 따라 일치율이 0.44에서 0.62까지 흔들립니다).

6. 사람을 빼지 않는다. MSR 연구의 실무 권고는 CRA가 사람 리뷰어를 대체가 아니라 보강해야 한다는 것입니다. 같은 데이터에서 사람이 섞인 리뷰(61.09~67.99%)는 CRA 단독(45.20%)보다 사람 단독(68.37%)에 훨씬 가까웠습니다.

언제 쓰지 말아야 하나

정직하게 쓰지 말아야 할 경우를 적습니다.

• 사람 리뷰를 없애려는 목적이라면. 이걸 지지하는 공개 증거가 없습니다. 있는 증거는 반대 방향입니다.
• 속도를 얻으려는 목적이라면. Beko 사례에서 PR 종료 시간은 5시간 52분에서 8시간 20분으로 늘었습니다(p 값 0.001 미만). 프로젝트별로 갈렸다는 점은 중요합니다 — 프로젝트 #1은 2시간 48분에서 4시간 38분으로, #3은 20시간 22분에서 30시간 51분으로 늘었지만, #2는 6시간 6분에서 3시간 7분으로 줄었습니다. 게다가 PR당 사람 리뷰 코멘트 수는 유의미하게 줄지 않았습니다. 논문의 결론은 시간·노력 절감에 대한 일관된 증거를 찾지 못했다는 것입니다.
• 리뷰 문화가 이미 촘촘하다면. 이건 러스트 표준 라이브러리 검증 캠페인 편과 같은 구조의 얘기입니다. 기존 테스트와 리뷰가 이미 잘 작동하는 코드베이스에서는 새 도구가 주울 것이 별로 남아 있지 않습니다. 값이 나오는 자리는 기존 방어선이 얇은 쪽입니다.
• 거짓 음성이 치명적인 도메인에서 필터로 쓴다면. LLM4PFA의 재현율 0.75~0.88을 기억하십시오. 거짓 양성을 줄이는 필터는 진짜 버그의 12~25%를 같이 버립니다.
• 끌 방법이 없다면. 소음이 나도 아무도 못 끄는 체크는 몇 주 안에 전원이 무시하게 되고, 그때부터는 진짜 발견까지 같이 묻힙니다. 구글 논문의 표현으로 "경고 실명(warning blindness)"입니다.

결정 규칙

"상황에 따라 다르다"로 끝내지 않겠습니다. 이렇게 하십시오.

1. 먼저 좁은 체크 하나로 시작하십시오. 보안 규칙이든 스타일이든, 정답이 기계적으로 확인 가능한 것. 범용 리뷰어로 시작하면 첫 2주의 소음으로 팀의 신뢰를 잃고 끝납니다.
2. 켜기 전에 거짓 양성 예산을 문서로 정하십시오. 구글의 10%를 기본값으로 쓰십시오. 다른 숫자를 쓰려면 근거를 적으십시오.
3. 끄는 메커니즘을 같은 날 만드십시오. "Not useful" 상당의 버튼, 소유자, 임계 초과 시 비활성화 규칙. 이게 없으면 1~2번은 무의미합니다.
4. 자동 점수로 판단하지 마십시오. 4주간 코멘트를 무작위로 50~100건 떠서 사람이 직접 읽고 유용/무용을 매기십시오. 그 표본이 당신의 유일한 신뢰 가능한 데이터입니다. LLM 심사 파이프라인을 세우고 싶다면, 먼저 그 심사자가 다수 클래스 기준선을 이기는지 확인하십시오. Beko 데이터에서는 못 이겼습니다.
5. 속도가 아니라 결함으로 정당화하십시오. 시간 절감은 증거가 없습니다. 잡은 결함 개수 곱하기 그 결함이 프로덕션에 나갔을 때의 비용에서, 개발자가 소음 읽는 데 쓴 시간을 빼십시오. 이게 양수여야 계속 켜 둘 이유가 있습니다.
6. 범위를 넓히는 것은 5번이 양수로 나온 다음입니다.

한 문장으로 줄이면 이렇습니다. AI 코드 리뷰는 "리뷰어"로 쓰면 실패하고, "좁고 끌 수 있는 체크"로 쓰면 값을 합니다.

마치며

이 글을 시작할 때의 질문은 "AI 코드 리뷰는 쓸 만한가"였습니다. 공개된 측정치를 다 모아 놓고 보면, 답은 "그렇다/아니다"가 아니라 이렇게 됩니다.

증거는 얇습니다. 다만 특정한 방식으로 얇습니다. 연구는 꽤 있고, 방향도 대체로 일치합니다 — 오픈소스에서 AI 코멘트 반영률(0.9~19.2%)은 사람(60%)에 한참 못 미치고, 정적 분석 알람의 76%는 헛것이며, 리뷰 봇만 붙은 PR은 더 많이 버려집니다. 빠진 것은 범용 AI 리뷰어의 프로덕션 정밀도·거짓 양성률을 벤더와 무관하게 잰 숫자입니다. 그 자리에 있는 것은 벤더가 자기 벤치마크에서 자기가 1등한 F1 60.1%, 조직 압력에 오염된 대리 지표, 그리고 기저율도 못 이기는 LLM 심사자뿐입니다.

그러니 다음에 "AI 리뷰어가 버그의 N%를 잡았습니다"라는 슬라이드를 보면 두 가지만 물어보십시오. 어떤 데이터셋입니까. 그리고 거짓 양성률은 얼마입니까. 둘 중 하나라도 답이 없으면, 그 N%는 아무것도 말하고 있지 않습니다.

그리고 이 질문은 벤더에게만 하는 게 아닙니다. 4주 뒤 당신 팀의 대시보드에 뜰 숫자에도 똑같이 해야 합니다.

참고 자료

• Does AI Code Review Lead to Code Changes? A Case Study of GitHub Actions (Gan 등, arXiv 2508.18771) — 액션 16종·저장소 178곳·코멘트 22,326건, 반영률 0.9~19.2% 대 사람 60%
• Automated Code Review In Practice (Cihan 등, arXiv 2412.18531) — Beko 사례, 73.8% 해결, PR 종료 5시간 52분 → 8시간 20분
• Understanding the Limits of Automated Evaluation for Code Review Bots in Practice (arXiv 2604.24525) — 같은 Beko 데이터 2,604건, LLM 심사 일치율 0.44~0.62, MCC 약 0
• From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests (MSR '26, arXiv 2604.03196) — CRA 단독 병합률 45.20% 대 사람 단독 68.37%, 신호 대 잡음비 분석
• Reducing False Positives in Static Bug Detection with LLMs: An Empirical Study in Industry (arXiv 2601.18844) — 텐센트 433건 중 거짓 양성 76%, LLM4PFA가 94~98% 제거(재현율 0.75~0.88)
• Lessons from Building Static Analysis Tools at Google (Sadowski 등, CACM 2018년 4월, 61권 4호) — 실효 거짓 양성 정의, 10% 임계, Tricorder 운영 규모
• Qodo — 2025 State of AI Code Quality (벤더 보고서, 설문 n=609) — "PR의 80%에 사람 코멘트 없음"의 원출처
• Qodo — How we built a real-world benchmark for AI code review (벤더 자체 측정) — PR 100건·이슈 580건 주입, Qodo F1 60.1%
• AI 코딩 모델 평가에서 신호와 잡음 가려내기 (관련 글)
• 러스트 표준 라이브러리 검증 캠페인이 찾아낸 메모리 안전성 버그는 0개였다 (관련 글)