AI 코드 리뷰는 "여기가 버그입니다"라고 말해주는 똑똑한 bot……이라고 생각했습니다만, 저희 팀에서 사용하기 시작하며 깨달은 것은 "LGTM(Looks Good To Me)만 답하는" 상황이 의외로 많다는 것이었습니다. 명백히 버그가 심겨 있는 코드를 던져도, 표면적인 lint 지적만으로 끝납니다. "결국, 정말로 버그를 찾아내고 있는가?"라는 의구심이 계속 남았습니다.

외부 벤치마크(Benchmark)는 확인합니다. CodeRabbit 51.5% F1, Greptile 82% catch, Bugbot 58%. 다양한 수치가 공표되어 있지만, 테스트 세트와 평가 기준이 제각각이라 자사 코드에 대한 수치로서는 신뢰하기 어렵습니다. 그렇다면 직접 측정해보자는 생각으로, OWASP Top 10 / CWE Top 25에서 편향 없이 선정한 30건의 실제 버그를 3개 툴(CodeRabbit / Claude Code Review / GitHub Copilot Review)에 던져보았습니다.

결론부터 말씀드리면, **진정한 버그 지적률은 3개 툴 평균 42%**였습니다. 제 체감보다 낮지도, 높지도 않은 현실적인 숫자였습니다.

솔직히 말하면, 처음에는 "LLM(Large Language Model)이 코드를 쓰는 시대라면, LLM이 리뷰도 완벽하게 해낼 것"이라고 낙관했습니다. 실측치를 보고 그것이 안이한 기대였다는 것을 깨달았다는 것이 지금의 감상입니다. AI에 과도한 기대를 품었던 저 자신을, 제가 만든 스프레드시트가 때린 격입니다.

공정한 비교를 위해 다음 사항을 고정했습니다.

코드베이스: TypeScript + Next.js 기반의 자사 프로덕트(약 4만 행)
버그 삽입 방식: 각 버그를 개별 PR(Pull Request)로 나누어 투입(30 PR × 3개 툴 = 90회 리뷰)
버그 선정: OWASP Top 10 / CWE Top 25에서 10개 카테고리 × 각 3건씩
판정: "진정한 버그 지적", "LGTM(놓침)", "오탐(False Positive)"의 3구분으로 수동 판정

버그 내역은 다음과 같은 10개 카테고리입니다.

카테고리별로 3건씩, 총 30건입니다. 버그 샘플링의 편향(Bias)을 줄이도록 설계했습니다.

사내 평가 후보 리스트에는 10개 정도의 툴이 올라와 있었지만, 무료 범위 내에서 30 PR 분량의 검증이 가능하다는 점, API 또는 GitHub App으로 자동화할 수 있다는 점, 일본어 리뷰 코멘트를 허용한다는 점의 3가지 조건으로 압축하면 현실적으로 남는 것은 CodeRabbit / Claude Code Review / GitHub Copilot Review 3개였습니다. Greptile은 개인적으로 테스트해보고 싶었으나, 무료 범위가 이번 검증 규모에 맞지 않아 이번에는 제외했습니다. 다음 검증에서는 추가하고 싶습니다.

판정자는 저를 포함한 시니어 엔지니어 2명이며, 판정에 흔들림이 있는 지적은 다른 한 명을 추가하여 다수결로 결정했습니다. "LGTM", "진정한 버그", "오탐"의 경계는 생각보다 모호하므로, 판정 예시집을 미리 만들어 두는 것을 추천합니다. 저는 처음에 그것을 게을리했다가 3주 만에 재판정을 다시 했습니다.

공개 벤치마크와 비교하면 낮은 수치로 보일 수 있지만, 이는 코드베이스 전체에 버그를 섞어 넣었다는 점이 크다고 생각합니다. 버그 단일 패치(Patch)만 보내는 스타일이라면 80%가 넘는 수치가 나오지만, 실제 프로젝트의 PR에 섞어 넣으면 놓치는 비율이 단번에 올라갑니다.

3개 툴의 "특기 분야"가 명확히 갈렸습니다.

"시그니처(Signature)적으로 이해하기 쉬운 버그에는 강하다"는 것이 3개 툴의 공통된 경향이었습니다. SQL Injection이나 XSS처럼 '금지 패턴(Forbidden pattern)'이 명확한 것은 전건 발견할 수 있습니다. 반면, 로직이나 실행 순서를 읽지 않으면 알 수 없는 버그(경합 상태(Race condition), off-by-one, N+1)는 거의 전멸 수준입니다.

'시그니처적으로 이해하기 쉬운' 그룹에서도 100%는 아니라는 점에 주목하십시오. XSS나 SQL Injection은 '금지 패턴'이 널리 알려져 있음에도 불구하고, Claude / Copilot은 1~2건을 놓쳤습니다. 공통된 약점은 이스케이프(Escape) 처리가 된 것처럼 보이는 경로(path), 문자열 결합이 여러 파일에 나누어져 있는 케이스입니다. AI에게 '보안 모범 사례 문제'를 내면 풀 수 있지만, 현장의 복잡한 코드에 섞여 있는 순간 검지율이 떨어지는 구도였습니다.

입력 검증, XSS, 린트(Lint) 스타일의 지적에 안정적으로 강합니다. 설정 파일(.coderabbit.yaml)을 통해 어휘를 늘릴 수 있어 커스터마이징 자유도도 높았습니다.

"인증 우회(Authentication bypass)"와 같이 문맥 추론이 필요한 버그에서 한 발 앞서 나갑니다. 코드베이스 전체의 컨텍스트(Context)를 에이전틱 서치(Agentic Search)로 읽으러 가기 때문에, '이 함수가 다른 곳에서 인증 미들웨어(Auth middleware)를 통과하는가'를 실제로 확인할 수 있습니다. 반면, 표면적인 오탐(False positive)도 많아 CodeRabbit보다 오탐율이 높은 결과였습니다.

3개 툴 중에서 가장 오탐이 적습니다(2/30). "자신 있는 것만 말한다"는 설계로 보였습니다. 반대로 놓치는 비율(False negative)이 가장 높아, 지나치게 보수적이라는 인상을 줍니다. OSS 프로젝트에서 노이즈를 싫어하는 팀에는 적합하지만, 사내 프로덕트를 방어하기에는 부족함이 있습니다.

이번 실측에서 가장 뼈아픈 수치는 "3개 툴 모두에게 던져도 LGTM이 반환되는 버그가 12건 있었다"는 점이었습니다.

30건의 버그 × 3개 툴 = 90회의 리뷰 기회
└─ 진정한 버그 지적: 38회
└─ LGTM (놓침): 42회
...

3개 툴이 놓친 12건의 내역을 보면, 경합 상태와 N+1 문제가 9건을 차지했습니다. **"여러 파일을 실행 시점에 가로지르는 문제"**는 2026년 5월 시점의 AI 리뷰 3개 툴로는 거의 잡을 수 없다고 생각하는 것이 안전합니다. 코드의 텍스트 측면만 읽어서는 런타임(Runtime)에서 어떤 순서로 무엇이 호출되는지는 보이지 않는다는 것이 현재의 한계점이었습니다.

참고로 이 12건 중 2건은 제가 "이건 분명 AI가 알아챌 것이다"라고 예상했던 버그였습니다. N+1의 전형적인 사례로, Prisma의 include가 누락된 아주 흔한 케이스입니다. 3개 툴 모두가 그냥 지나치는 순간, 인간 리뷰어의 존재 의의를 다소 과하게 재고하게 되었습니다.

AI 코드 리뷰가 'LGTM'을 반환했다고 해서 버그가 없다는 뜻은 아닙니다. 특히 **실행 순서, 병행성(Concurrency), 여러 모듈을 가로지르는 데이터 흐름(Data flow)**과 관련된 버그는 AI 리뷰를 통과하여 머지(Merge)됩니다. 인간 리뷰어의 눈은 바로 이 영역에 필요합니다.

오탐(False positive)도 무시할 수 없습니다. 3개 툴 합계로 10건의 오탐이 발생했습니다. "여기는 버그입니다"라고 단언한 지적의 11%는 사실 문제가 없는 정상 코드였습니다.

대표적인 오탐 패턴:

• 테스트 코드의 expect(thing).toThrow()를 예외 미처리로 판정
• 타입 추론으로 명백히 non-nullable한 변수를 nullable로 취급
• React의 useEffect 내의 stale closure를 실제로는 문제가 없는데 경고

처음에 오탐을 받았을 때, 저는 순순히 믿고 리팩터링(Refactor)을 해버렸다가 다른 테스트를 망가뜨린 경험이 있습니다. AI 리뷰를 '선생님'으로서 무비판적으로 받아들이면 이런 사고가 발생한다는 것이 교훈이었습니다. 지금은 "AI 리뷰는 한 명의 주니어 엔지니어의 의견" 정도의 무게로 다루고 있습니다. 무게를 낮추고 나서야 오히려 진짜 지적에 집중할 수 있게 되었습니다.

오탐이 많으면 리뷰어가 '양치기 소년 효과'로 인해 진짜 버그까지 읽어 넘기게 됩니다. 저희 팀에서는 오탐율 15%를 허용 상한으로 두고 있으며, 이를 초과하는 툴은 설정을 재검토하거나 다른 툴로 교체하는 규칙을 세웠습니다.

"여러 AI에게 보여주면 놓치는 것이 줄어들지 않을까?"라는 것은 자연스러운 발상입니다. 실제로 저희 팀도 한때 그렇게 했습니다.

3개 툴을 병용하여, 3개 중 하나라도 지적하면 '발견'으로 간주하면,

발견율: 21/30 (70%)

확실히 놓치는 부분은 47% → 30%까지 줄어듭니다. 하지만 리뷰어가 처리해야 하는 코멘트 수는 단순하게 3배가 됩니다. 오탐 (False Positive)의 절대수도 늘어나기 때문에 팀의 인지 부하 (Cognitive Load)가 상당히 증가했습니다.

저의 현재 팀은 "CodeRabbit + 인간 리뷰어" 구성입니다. Claude Code Review는 "Claude Code 내의 리뷰 subcommand"로서, 개발자가 로컬에서 작업하는 동안 수시로 실행하는 방식으로 사용하고 있습니다. 사내 도입 로드맵으로는, CodeRabbit을 중심으로 하되 Claude는 로컬 IDE 사용 시 활용하는 것이 현재의 베스트 프랙티스 (Best Practice)라고 느끼고 있습니다.

"3개 툴에 보여주고도 전부 놓친 버그는 리뷰 체계 외부에서 잡는다"라는 발상도 필요합니다. 저희 팀에서는 뮤테이션 테스팅 (Mutation Testing)을 시험 도입했는데, 코드 커버리지 (Code Coverage)가 95%임에도 구현 실수를 검출할 수 있는 지점이 10여 건이나 나왔습니다. 이는 향후 별도의 글로 정리할 예정입니다만, AI 리뷰 단독으로 품질을 보장하는 시대는 아니라는 것이 현재의 견해입니다.

이 벤치마크는 외부에 공개할 수 있는 형태로 테스트 세트를 만들었습니다. 동일한 절차로 자사 버전의 벤치마크를 수행하고 싶은 분들을 위해 절차를 남깁니다.

버그 카테고리 선정: OWASP Top 10 / CWE Top 25에서 10개 카테고리 × 3건 -
PR 형식으로 제출: 1개 버그당 1개 PR, 코드베이스 전체에 섞어 넣음 -
판정자는 3명: AI 1명, 시니어 엔지니어 2명으로 다수결 결정 -
3개 축으로 집계: 실제 버그 지적 / LGTM / 오탐 (False Positive) -
카테고리별 장단점 시각화: 표로 나열

공수는 1인일 × 3주 정도입니다. 비용은 AI 리뷰 이용료(월 수천~수만 엔)뿐입니다. 저는 이 수치를 산출한 이후, 사내 AI 리뷰 선정 논의가 단번에 짧아졌습니다. "공개 벤치마크가 아닌, 자사 코드에서의 수치"가 결정적인 요인이 됩니다.

실제 버그 30건 × 3개 툴의 실측을 통해 확인된 내용은 다음과 같습니다.

실제 버그 지적률은 3개 툴 평균 42% (공개 벤치마크보다 낮음) -
특기 분야가 나뉨: CodeRabbit = 린트 (Lint) 계열, Claude = 문맥 추론, Copilot = 보수적 -
경쟁 상태 (Race Condition) · N+1 문제는 3개 툴 모두 전멸 (복수 파일/실행 순서 관련) LGTM은 버그 0을 보장하지 않음

AI 코드 리뷰는 "인간 리뷰어의 대체"가 아니라, "lint + α"로서組み込む (통합하는) 것이 현실적인 해답이라는 것을 이번 검증을 통해 명확히 알 수 있었습니다. 로직 · 병행성 · 데이터 흐름 (Data Flow) 계열의 버그는 아직 인간이 확인해야 합니다. 그것을 전제로 AI에게 무엇을 시키고, 무엇을 인간에게 남길지를 설계하는 것이 2026년 리뷰 체계화의 출발점입니다.

당신 팀의 AI 코드 리뷰어, 오탐율은 어느 정도입니까? AI 리뷰가 놓친 결과로 운영 환경에서 버그가 된 사례가 있다면 꼭 댓글로 알려주세요. 저도 이 글의 수치를 연 2회 업데이트할 예정이므로, 현장의 체감을 공유해 주시면 큰 도움이 됩니다.