Pull Request (PR)에 LLM을 단순히 붙이는 것은 주말 동안 할 수 있는 프로젝트 수준입니다. 진짜 문제는 엔지니어들이 2주 안에 비활성화하지 않을 AI 코드 리뷰를 구축하는 것입니다. 실패 모드는 버그를 놓치는 것이 아니라, '양치기 소년'처럼 행동하는 것입니다. 누군가의 PR에 20개의 사소한 지적(nitpicks)과 3개의 환각(hallucinations)을 남기면, 그들은 영원히 봇을 뮤트(mute)할 것입니다. 이것이 우리가 Mattrx에서 신뢰를 얻고 — 그리고 유지하기 위해 — 구축한 파이프라인입니다.

Mattrx는 우리의 멀티 테넌트(multi-tenant) 마케팅 분석 SaaS입니다. 약 95,000줄의 C#, 11명의 엔지니어, 그리고 시니어 리뷰어의 시간이 병목 현상이 될 만큼 충분한 양의 Pull Request가 존재합니다. 우리는 처음에 단순한 방식 — 변경된 파일을 모델에 전달하고 출력을 게시하는 방식 — 을 시도했다가, 팀이 9일 만에 그것을 읽지 않기 시작하는 것을 목격했습니다.

요약 (TL;DR)

차원	인간 전용 / 단순한 AI (이전)	AI 리뷰 파이프라인 (이후)
커버리지	선택적 / 파일 전체 덤프	모든 PR, 차이점(diff) 중심
...

• 11명의 엔지니어가 주당 약 90개의 PR 생성; 파이프라인이 100%를 리뷰합니다.
• 1차 리뷰 지연 시간(latency) 6시간 → 3분.
• 오탐률(False-positive rate) ~35% → ~6% — 봇의 생존 여부를 결정하는 단 하나의 수치입니다.
• 운영 환경으로 유출된 결함(Escaped defects) 약 40% 감소; 시니어 리뷰어 시간 약 30% 감소.
• PR당 약 $0.05 (스타일용 저렴한 모델, 정확성용은 최첨단(frontier) 모델 사용).

단 하나의 사고방식 전환: AI 코드 리뷰는 문제를 찾는 것에 관한 것이 아닙니다 — 모델은 얼마든지 찾아낼 수 있습니다. 그것은 양치기 소년이 되지 않는 것에 관한 것입니다. 제품은 신뢰이며, 신뢰는 오탐률(false-positive-rate)의 문제입니다. 코멘트를 남기기 전에 검증하십시오. AI가 제안(propose)하게 하고, 인간이 결정(dispose)하게 하십시오.

단순한 접근 방식 — 그리고 그것이 무너지는 이유

// 이전: 변경된 파일 전체를 하나의 프롬프트에 덤프하고, 결과가 무엇이든 게시함.
foreach (var file in pr.ChangedFiles)
{
...

그것은 변경 사항이 아닌 파일 전체를 리뷰합니다. 프로젝트 컨텍스트 (Project context)가 없기 때문에, 당신의 컨벤션 (Conventions)을 버그로 표시합니다. 심각도 (Severity)도 없습니다. 누락된 null-check와 스타일 선호도가 동일한 비중으로 전달됩니다. 또한 검증 (Verification) 과정이 없으므로, 모든 환각 (Hallucination)이 개발자에게 그대로 전달됩니다. 그 결과 약 35%의 오탐률 (False-positive rate)이 발생하며, 팀은 봇을 무시하는 법을 (정확하게) 배우게 됩니다.

1. 컨텍스트 조립 (Context assembly) — 파일이 아닌 변경 사항을 리뷰하라

리뷰 컨텍스트 (Review context)를 구축하세요: diff (변경 사항만), 변경 사항이 영향을 미치는 심볼 (Symbols)의 호출 지점 (Call sites), 그리고 해당 파일들에 대한 프로젝트 컨벤션 (Project conventions)입니다.

public async Task<ReviewContext> BuildAsync(PullRequest pr, CancellationToken ct)
{
    var diff = await git.GetDiffAsync(pr.BaseSha, pr.HeadSha, ct); // 변경 사항, 그 외에는 없음
...

대부분의 오탐 (False positives)은 모델이 코드베이스 (Codebase)의 규칙을 알지 못하기 때문에 발생합니다. 컨벤션과 호출 지점 (Call sites)을 제공하면, 모델은 당신의 패턴을 지적하는 것을 멈추고 두 단계 떨어진 호출자 (Callers)의 버그를 잡아내기 시작합니다.

2. 하나의 거대한 프롬프트가 아닌, 다차원 리뷰어 (Multi-dimensional reviewers)

정확성 (Correctness), 보안 (Security), 성능 (Performance), 테스트 (Tests)와 같이 각각 좁은 범위의 임무를 가진 전문화된 리뷰어들이 병렬로 실행되어 **타입화된 구조적 결과 (Typed, structured findings)**를 반환합니다:

public sealed record ReviewFinding(
    string Dimension,      // "correctness" | "security" | "performance" | "tests"
    string File, int Line,
...

인젝션 (Injection)과 비밀 누출 (Secret leakage)을 추적하도록 지시받은 "보안 리뷰어 (Security reviewer)"는 "문제를 찾아라"라고 지시받은 일반론자보다 뛰어난 성능을 발휘하며, 그 출력값은 직접 파싱해야 하는 문단이 아니라 게이트 (Gate)를 설정할 수 있는 타입화된 레코드 (Typed record)입니다.

3. 적대적 검증 (Adversarial verification) — 신뢰를 얻는 기능

어떠한 결과가 게시되기 전에, 별도의 모델이 해당 결과를 **반박 (Refute)**하도록 프롬프트를 구성합니다. 불확실할 때는 기본적으로 "실제가 아님"으로 처리합니다.

public async Task<bool> IsRealAsync(ReviewFinding f, ReviewContext ctx, CancellationToken ct)
{
    var verdict = await gateway.EvaluateAsync(new EvalRequest
...

이러한 비대칭성이 핵심입니다. AI 리뷰어에게는 재현율 (Recall)보다 정밀도 (Precision)가 훨씬 더 중요합니다. 왜냐하면 오탐 (False Positive)의 비용은 도구 자체를 무력화시키는 것이기 때문입니다. 회의적인 두 번째 검토 (second pass)는 당신이 얻을 수 있는 가장 저렴한 정밀도입니다. 이것이 우리가 오탐 (FP)을 약 6% 수준으로 낮추고 봇을 계속 유지할 수 있었던 비결입니다.

4. 심각도 게이팅 (Severity gating) — 결정권은 인간에게

AI는 제안하고, 인간은 결정합니다. 차단 (Blocker) 또는 높음 (High) 등급의 발견 사항만 변경을 요청합니다. 그 외의 모든 사항은 비차단 (non-blocking) 댓글이며, 인간은 언제든지 이를 무시 (override)할 수 있습니다.

public MergeAdvice Gate(IReadOnlyList<ReviewFinding> findings)
{
    var blocking = findings.Where(f => f.Severity is Severity.Blocker or Severity.High).ToList();
...

단독으로 머지 (Merge)를 차단할 수 있는 AI는, 처음으로 확신을 가지고 틀렸을 때 즉시 꺼지게 될 것이며, 그와 함께 AI의 진정한 가치도 사라질 것입니다. 인간의 무시 (override)가 가능한 '기본 권고 (Advisory-by-default)' 방식이야말로 AI를 계속 켜두어도 안전하게 만드는 핵심입니다.

5. 거버넌스 (Governance) — 게이트웨이를 통한 실행

모든 리뷰 호출은 동일한 거버넌스 AI 게이트웨이를 통과합니다. 저장소(repo)별 토큰 예산, 모델 라우팅 (스타일 체크를 위한 저렴한 모델, 정확성을 위한 최첨단 (Frontier) 모델), 코드가 경계를 벗어나기 전의 비밀 정보 삭제 (Secret redaction), 그리고 추가 전용 (append-only) 감사 로그가 적용됩니다. 코드는 가장 민감한 자산 중 하나입니다. 만약 당신의 AI 리뷰어가 비밀 정보를 삭제하지 않고, 비용 지출을 제한하지 않으며, 무엇을 보았는지 기록하지 않는다면, 당신은 리뷰 병목 현상을 해결하는 대신 데이터 거버넌스 사고를 맞이하게 될 것입니다.

6. 피드백 루프 (The feedback loop)

개발자는 모든 댓글에 대해 '좋아요/싫어요'를 표시합니다. 정밀도가 낮은 차원(dimension)은 검증 임계값 (verification thresholds)을 더 엄격하게 설정하고, 계속해서 잘못 플래그가 지정되는 컨벤션 (conventions)은 컨텍스트 (context)에 추가됩니다. 이러한 루프 덕분에 출시 후에도 정밀도가 드리프트 (drift)되지 않고 높게 유지됩니다.

솔직한 이야기: 이 시스템을 구축하지 말아야 할 때

• 소규모 팀 / 낮은 PR (Pull Request) 빈도. 만약 사람이 한 시간 이내에 모든 것을 리뷰할 수 있다면, 오버헤드(overhead)를 감수할 가치가 없습니다.
• 오탐 (False Positives)을 측정하지 않았을 때. 소음이 심한 봇을 배포하면, 팀원들이 이를 영구적으로 무시하도록 훈련시키는 꼴이 됩니다. 파일럿 테스트를 진행하고, 오탐 (FP)을 측정하며, 약 10% 미만의 환경에서 점진적으로 배포하세요.
• AI가 단독으로 머지 (Merge)를 차단하게 둘 때. 그러지 마세요. AI는 제안하고, 인간이 결정합니다.
• 경계를 벗어날 수 없는 독점적/규제 대상 코드. 셀프 호스팅 (Self-host) 하거나 공격적으로 비식별화 (Redact) 하세요.
• 리뷰어를 대체할 수 있다고 생각할 때. AI는 어시스턴트 (Assistant)입니다. 아키텍처와 설계는 인간의 영역으로 남습니다.
• 스타일 교정용으로 사용할 때. 린터 (Linter)는 스타일을 결정론적이고 즉각적이며 무료로 처리합니다. AI는 로직 (Logic)과 보안 (Security)에 집중시키세요.

지속해 나가야 할 모델

AI 리뷰어의 역할은 인간이 중요한 것에 집중할 수 있도록 노이즈를 제거하는 것입니다. 모델은 하루 종일 문제를 찾아낼 수 있지만, 엔지니어링의 핵심은 '양치기 소년'이 되지 않는 데 있습니다. 재현율 (Recall)보다 정밀도 (Precision)를 최적화하고, 코멘트를 달기 전에 검증하며, 머지 (Merge) 버튼을 누르는 주체는 인간으로 유지하세요. 오탐 (False-positive) 비율을 충분히 낮추면 도구는 팀이 신뢰하는 존재가 되지만, 틀리기 시작하면 팀원들은 9일 안에 알림을 꺼버릴 것입니다 — 저희가 직접 시간을 재보았습니다.

원문은 PrepStack에 게시되었습니다. AI 코드 리뷰를 도입하고 오탐 (False-positive) 문제와 싸우고 계신가요? randhir.jassal[at]gmail.com으로 연락해 주세요.