AI를 활용한 리뷰 정확도를 유지하는 방법

서론

최근 Claude Code로 대표되는 AI 에이전트를 개발 워크플로우에 통합하는 것은 엔지니어에게 매우 일상적인 풍경이 되었습니다. 우리는 풀 리퀘스트(PR)를 생성하자마자 AI 에이전트를 구동하여 변경 내용에 대한 '첫 번째 리뷰'를 요청하고 있습니다.

하지만 이 과정에는 치명적인 문제가 있었습니다. 바로 **'같은 차이점(diff)을 전달함에도 불구하고, 실행할 때마다 지적 내용의 질이나 종류가 흔들린다'**는 문제입니다. 어떤 때는 보안 취약점을 날카롭게 지적하는 반면, 다른 때는 네이밍 규칙의 사소한 실수만을 지적하고 정작 중요한 로직의 결함을 놓쳐버립니다. 이러한 '불확실성'은 AI 리뷰를 자동화된 CI 프로세스에 통합할 때 큰 장애물이 됩니다.

본 글에서는 왜 AI로 인한 리뷰 정확도가 불안정해지는지 그 원인 분석부터, 이러한 흔들림을 최소화하기 위해 개발한 자체 CLI 도구 'Revi'의 설계 사상 및 구현 상세에 대해 설명합니다.

왜 AI의 리뷰는 '흔들리는가'

분석 결과, 지적 내용의 흔들림은 단순히 모델의 확률적 특성(Temperature)뿐만 아니라, 다음 4가지 요인이 복합적으로 작용하고 있음이 밝혀졌습니다.

1. 직전 대화 기록에 의한 편향

왜 AI의 리뷰는 '흔들리는가'

분석 결과, 지적 내용의 흔들림은 단순히 모델의 확률적 특성(Temperature)뿐만 아니라, 다음 4가지 요인이 복합적으로 작용하고 있음이 밝혀졌습니다.

1. 직전 대화 기록에 의한 편향

(보안 (セキュリティ)), Performance

(성능), Maintainability

(유지보수성)의 4가지 관점을 강제적으로 결합합니다.

입력 범위 제한 (Scoped Input): 모든 파일을 읽게 하는 것이 아니라, diff를 중심으로 하며 의존 관계 해소에 필요한 파일만을 명시적으로 Read하게 합니다.

출력 스키마 구조화 (Structured Output): 자연문이 아닌, 반드시 JSON 형식으로 출력하게 합니다 (file, line, severity, category, confidence 등을 포함).

단계 분할 (Pipeline Decomposition): '차이 분석 → 배경 이해 → 리뷰 실행 → 결과 취합'이라는 프로세스를 단일 프롬프트가 아니라 단계적인 스텝으로 분리합니다.

해결책: CLI 툴 "Revi" 개발

이러한 원칙들을 운영 규칙으로서 엔지니어에게 강요하는 것은 불가능합니다. 그래서 저희는 위 설계 원칙들을 기술적으로 강제하는 OSS 기반의 CLI 툴인 "Revi"를 개발했습니다.

리포지토리는 GitHub에서 공개하고 있습니다: https://github.com/ben-saito/revi

Revi는 bun을 런타임으로 사용하며, 기존 AI 에이전트(Claude Code 등)를 서브프로세스로 제

• 대칭 차분 (Symmetric Difference) 테스트: 동일한 PR에 대해 Revi를 3회 연속으로 실행하고, 출력된 지적 사항들의 집합의 '대칭 차분'을 계산했습니다. 그 결과, 치명적인 지적(Severity: High)의 집합은 3회의 실행에서 완전히 일치하거나 매우 작은 차이로 수렴하는 것을 확인했습니다. - 골든셋을 이용한 정점 관측: 과거에 발생했던 알려진 취약 커밋(예: SQL 인젝션, 부적절한 권한 설정)을 '골든셋'으로 준비하고, CI 내에서 Revi가 이를 탐지할 수 있는지 정점 관측하고 있습니다.

요약

AI를 통한 코드 리뷰의 성공 여부는 모델의 파라미터(Temperature)나 모델 자체의 지능보다는, **'어떻게 실행 환경을 결정론적으로 제어할 수 있는가'**라는 엔지니어링 역량에 달려 있습니다.

운영 규칙으로 '의식적으로 검토해 주세요'라고 요청하는 것만으로는 인간의 부주의함이나 문맥의 흔들림을 배제할 수 없습니다. 문제를 특정하고, 그것을 해결하기 위한 메커니즘을 도구로서 코드에 새겨 넣는 것. 이 접근 방식이야말로 AI 에이전트를 진정으로 신뢰할 수 있는 팀 멤버로 승화시키는 열쇠가 됩니다.