우리는 실제 운영 환경과 유사한 코드베이스에 23개의 알려진 버그를 심고, 8개의 AI 코드 리뷰 도구를 대상으로 테스트를 진행했습니다.

가장 성능이 좋은 도구는 14개를 잡아냈습니다. 가장 성능이 낮은 도구는 7개를 잡아냈습니다. 8개 도구 전체의 평균 탐지율은 60.3%였습니다. 이는 평균적인 AI 코드 리뷰 도구가 인간 리뷰어가 잡아낼 것으로 기대되는 실제적이고, 악용 가능하며, 운영에 영향을 미치는 버그의 약 40%를 놓치고 있음을 의미합니다.

비난이 쏟아지기 전에 말씀드리자면, 이것이 AI 코드 리뷰에 대한 비난은 아닙니다. 이러한 도구들은 실제 문제를 잡아내고, 코드 품질을 개선하며, 리뷰어의 시간을 절약해 줍니다. 하지만 "배포 전에 버그를 잡아낸다"는 마케팅 문구는 그들이 실제로 무엇을 잡아내고 무엇을 놓치는지에 따라 조정될 필요가 있습니다.

우리가 이것을 공개한 이유는 다른 누구도 이러한 도구들을 실제적인 버그로 테스트하지 않기 때문입니다. 기존의 비교 방식들은 장난감 예제(toy examples)의 탐지 여부를 테스트하거나, 도구 자체의 선별된 테스트 케이스를 대상으로 실행합니다. 우리는 알고 싶었습니다. 만약 당신이 리뷰 과정에서 레이스 컨디션 (race condition)을 잡아내는 시니어 엔지니어라면, AI 도구도 그것을 잡아낼 수 있을까요?

그 질문에 대한 답은, 실제적인 버그의 40%에 대해 '아니오'였습니다.

테스트 설정

우리는 34개 모듈에 걸쳐 약 15,000줄의 코드로 구성된, 의도적으로 버그를 심은 중간 규모의 Python/FastAPI 애플리케이션을 제작했습니다. 이 애플리케이션은 사용자 인증, 결제 처리, 주문 관리 및 알림 시스템을 처리합니다. 이는 대부분의 도구가 마케팅 대상으로 삼는 B2B SaaS 백엔드의 전형적인 모습입니다.

우리는 8개 카테고리에 걸쳐 23개의 버그를 심었습니다. 모든 버그는 우리가 코드 리뷰 및 기술 실사 (technical due diligence) 작업을 수행하는 동안 운영 시스템에서 실제로 마주쳤던 실제 버그 패턴이었습니다. 합성된 퍼즐 형태는 하나도 없었습니다. 모두 배포될 경우 실제적인 결과를 초래할 수 있는 것들이었습니다.

카테고리 및 심어진 버그:

SQL 인젝션 (SQL injection) 취약점: 3개의 버그. 문자열 연결 (string concatenation)을 사용하는 검색 엔드포인트에서 1개. 동적 컬럼 선택이 포함된 보고 쿼리에서 1개. 매개변수화된 쿼리 (parameterised query) 구문이 잘못 조립된 관리자 도구에서 1개.

인증 및 인가 우회 (Authentication and authorisation bypasses): 3개의 버그. 리소스 ID를 수정하여 사용자 A가 사용자 B의 데이터에 접근할 수 있었던 IDOR (Insecure Direct Object Reference) 1개. 내부 API 엔드포인트에서 인증 확인이 누락된 사례 1개. 만료 시간은 확인하지만 서명(signature)은 확인하지 않은 JWT 검증 사례 1개.

경쟁 상태 (Race conditions): 3개의 버그. 잔액 확인과 차감이 원자적(atomic)으로 이루어지지 않은 결제 처리 과정에서의 TOCTOU 1개. 동시 요청이 한도를 초과하여 사용할 수 있었던 쿠폰 사용 과정에서의 사례 1개. 동시 작업자(worker)가 동일한 작업을 가져갈 수 있었던 작업 큐(task queue)에서의 사례 1개.

메모리 및 리소스 누수 (Memory and resource leaks): 3개의 버그. 예외 경로(exception path)에서 데이터베이스 연결이 풀(pool)로 반환되지 않은 사례 1개. 에러 분기에서 파일 핸들(file handle)이 열린 채로 남겨진 사례 1개. 풀링(pooling) 없이 요청마다 Redis 연결이 생성된 사례 1개.

오프 바이 원 및 경계 오류 (Off-by-one and boundary errors): 3개의 버그. 마지막 페이지를 건너뛴 페이지네이션(pagination) 1개. 종료 날짜를 제외한 날짜 범위 1개. 빈 입력값에서 충돌을 일으키는 배열 인덱스 1개.

입력 유효성 검사 실패 (Input validation failures): 3개의 버그. 파일 업로드 엔드포인트에서의 경로 탐색 (path traversal) 1개. XML 파싱에서의 XXE 취약점 1개. ReDoS (정규 표현식 서비스 거부)에 취약한 정규 표현식 패턴 1개.

로직 오류 (Logic errors): 3개의 버그. 세금 적용 전이 아닌 세금 적용 후에 할인을 적용한 가격 계산 1개. 성공 상태가 아닌 실패 상태에서 전송된 알림 1개. 의도한 순서를 뒤바꾼 정렬 1개.

데이터 처리 위반 (Data handling violations): 2개의 버그. PII (개인 식별 정보)를 평문으로 로그에 남긴 엔드포인트 1개. API 응답에서 삭제된 사용자 데이터를 반환한 엔드포인트 1개.

테스트한 8개의 도구

우리는 현재 시장의 스펙트럼을 대표하는 8개의 도구를 실행했습니다: GitHub Copilot code review, Cursor의 내장 리뷰, CodeRabbit, Qodo (구 CodiumAI), Amazon CodeGuru, Sourcery, DeepSource, 그리고 고객 작업을 위해 우리가 직접 구축한 Claude 기반의 커스텀 리뷰 파이프라인입니다.

각 도구에는 동일한 상태의 동일한 코드베이스가 제공되었습니다. 우리는 버그가 포함된 코드를 깨끗한 베이스라인(baseline)에 대한 PR로 제출하였고, 각 도구가 플래그(flag)를 표시한 모든 이슈를 캡처했습니다.

탐지 매트릭스 (The detection matrix)

데이터가 드러내는 사실 (What the data reveals)

카테고리별 분류는 전체 집계 수치보다 더 흥미롭습니다.

SQL 인젝션 (SQL injection)과 입력값 검증 (input validation)은 모든 도구에서 가장 잘 탐지된 카테고리였습니다. 대부분의 도구가 명백한 문자열 연결 인젝션 (string concatenation injection)과 경로 탐색 (path traversal)을 잡아냈습니다. 이러한 유형은 학습 데이터에 잘 나타나 있으며, 취약점 패턴으로서도 잘 문서화되어 있습니다. 만약 여러분의 관심사가 일반적인 OWASP 스타일의 취약점이라면, 대부분의 AI 리뷰 도구는 준수한 커버리지를 제공합니다.

경쟁 상태 (Race conditions)는 처참할 정도로 탐지율이 낮았습니다. 단 두 개의 도구만이 경쟁 상태를 잡아냈습니다. 전체 테스트 세트에서 가장 영향력이 큰 버그라고 할 수 있는 결제 처리 과정의 TOCTOU (Time-of-check to time-of-use)는 8개의 도구 중 단 2개만이 포착했습니다. 경쟁 상태를 파악하려면 동시 실행 흐름 (concurrent execution flows)에 대한 이해가 필요한데, 대부분의 AI 리뷰 도구는 이를 효과적으로 추론하지 못합니다. 이들은 코드 경로를 순차적으로 분석하며, 두 개의 스레드 (threads)가 동일한 함수를 동시에 실행할 때 발생하는 상황을 모델링하지 못합니다.

이것이 중요한 이유는 결제 처리, 재고 관리, 리소스 할당에서의 경쟁 상태가 가장 비용이 많이 드는 운영 환경(production) 버그 중 하나이기 때문입니다. 또한 이는 인간 리뷰어가 잡아내기 가장 어려운 버그 중 하나이기도 합니다. 즉, 경쟁 상태는 AI의 지원이 가장 가치 있을 카테고리인 동시에, 현재 AI의 지원이 가장 취약한 카테고리라는 것을 의미합니다.

논리 오류(Logic errors)는 대부분의 도구에서 거의 보이지 않았습니다. 세금 적용 전이 아닌 세금 적용 후에 할인이 적용되는 가격 계산 버그는 단 세 개의 도구만이 잡아냈습니다. 이는 논리 오류를 탐지하기 위해서는 단순히 코드 구조(code structure)가 아니라 비즈니스 의도(business intent)를 이해해야 하기 때문입니다. 해당 코드는 구문론적으로 올바르고(syntactically correct), 좋은 패턴을 따르고 있었으며, 어떤 정적 분석(static analysis)도 통과했을 것입니다. 단지 비즈니스 요구사항대로 작동하지 않았을 뿐입니다. 코드가 무엇을 해야 하는지 이해하지 못하면 어떤 도구도 이를 잡아낼 수 없으며, 이를 위해서는 대부분의 리뷰 도구가 갖추지 못한 컨텍스트(context)가 필요합니다.

인증 우회(Authentication bypasses)는 중간 정도의 탐지율을 보였으나, 탐지된 패턴들은 모두 명백한 것들이었습니다. 엔드포인트(endpoint)에서 인증 확인이 누락된 것은 대부분의 도구가 잡아냈습니다. 만료 시간은 확인하지만 서명(signature)은 확인하지 않는 미묘한 JWT 서명 검증 문제는 단 두 개의 도구만이 잡아냈습니다. IDOR(Insecure Direct Object Reference)는 세 개가 잡아냈습니다. 패턴을 요약하자면, 명백한 보안 누락은 탐지되지만 미묘한 보안 논리 오류는 놓쳐진다는 것입니다.

오탐(False positive) 문제

탐지율(Detection rate)은 이야기의 절반에 불과합니다. 오탐율(False positive rate)은 개발자가 실제로 도구를 사용할지, 아니면 그 출력을 무시하기 시작할지를 결정합니다.

CodeRabbit은 상용 도구 중 가장 높은 탐지율을 보였지만, 오탐(false positive) 횟수 또한 가장 많았습니다. Sourcery는 가장 나쁜 비율을 보였는데, 실제 탐지(true positives)보다 오탐이 더 많았습니다. 커스텀 Claude 파이프라인은 높은 탐지율과 낮은 오탐율 사이에서 가장 좋은 균형을 보여주었는데, 이는 주로 우리가 이 코드베이스의 패턴에 맞춰 리뷰 프롬프트(review prompt)를 구체적으로 조정하고, 모델에게 구체적인 영향이 있는 문제만 표시하도록 명시적으로 지시했기 때문입니다.

40% 이상의 오탐(False positives)은 도입을 저해하는 결정적인 요소입니다. 개발자들이 세 개의 리뷰 코멘트 중 하나 이상이 틀렸거나 무관하다는 것을 인지하게 되면, 더 이상 코멘트를 읽지 않게 됩니다. 도구는 팀이 무시하는 법을 배우게 되는 소음(noise)이 되며, 이는 도구가 아예 없는 것보다 더 나쁩니다. 왜냐하면 잘못된 보안 의식(false sense of security)을 심어주기 때문입니다.

AI 코드 리뷰를 사용하는 팀에게 이것이 의미하는 바

AI 코드 리뷰는 가치가 있습니다. 실제 버그를 잡아내고, 일관성을 강제하며, 인간 리뷰어를 기계적인 검사로부터 해방시켜 줍니다. 하지만 레이스 컨디션(race conditions), 로직 오류(logic errors), 미묘한 보안 취약점(subtle security vulnerabilities), 비즈니스 규칙 위반(business rule violations)과 같이 가장 중요한 버그 카테고리에 대해서는 인간의 리뷰를 대체할 수 없습니다.

효과적인 배포 패턴: AI 리뷰가 첫 번째 패스(first pass)를 담당합니다. AI는 일반적인 취약점, 스타일 문제, 명백한 오류를 잡아냅니다. 그런 다음 인간 리뷰어는 AI가 지속적으로 놓치는 카테고리, 즉 동시성(concurrency), 비즈니스 로직(business logic), 아키텍처 결정(architectural decisions), 그리고 구조가 아닌 의도를 이해해야 하는 미묘한 보안 패턴(subtle security patterns)에 주의를 집중합니다.

도구 선택은 싸움의 절반에 불과합니다. 나머지 절반은 워크플로우 통합(workflow integration)입니다. PR 사이클의 어느 단계에 AI 리뷰를 배치할 것인지, 무엇을 인간 리뷰어에게 에스컬레이션(escalate)할 것인지, 그리고 팀이 AI 리뷰를 충분한 리뷰로 간주하는 것을 어떻게 방지할 것인지가 중요합니다. **AI 코드 리뷰 엔터프라이즈 가이드**에서는 AI 리뷰를 잘못된 안전망이 아닌 보완적인 도구로 만드는 조직적 변화를 포함하여 전체 워크플로우 설계를 다룹니다.

Dextra Labs, AI 컨설팅 및 엔터프라이즈 에이전트 개발(Enterprise Agent Development) 발행