AI 코드 리뷰에는 합의가 아니라 이견이 필요해요

adamsreview는 병렬 리뷰 관점, 검증 관문, 사람의 점검, Codex 동료 리뷰, 그리고 커밋 전에 변경 사항을 다시 검토하는 수정 반복을 갖춘 6개 명령 코드 리뷰 파이프라인을 설명해요.¹

이 설계는 AI 코드 리뷰의 진짜 최전선을 보여 줘요. 더 나은 리뷰는 또 다른 봇 댓글 흐름에서 나오지 않아요. 더 나은 리뷰는 서로 다른 판단을 내리고, 그 불일치를 보존하며, 주장을 검증하고, 프로젝트가 해당 발견을 차단 조건으로 다루기 전에 사람 리뷰어에게 판단을 되돌려 주는 독립 리뷰어에서 나와요.

요약

AI 코드 리뷰는 합의가 아니라 훈련된 이견에 맞춰 최적화되어야 해요. 쓸모 있는 리뷰 시스템은 독립적인 관점을 배정하고, 발견 사항을 중복 제거하며, 각 주장을 검증하고, 확인된 버그와 사람의 판단이 필요한 항목을 분리하고, 최종 리뷰 책임자를 사람으로 유지해요. 합의는 드물지만 중요한 발견을 가릴 수 있어요. 리뷰 패킷은 증거가 반박하기 전까지 소수 주장을 보존한 다음, 수정과 재검토 결과까지 추적해야 해요.

핵심 내용

엔지니어링 리더에게: - AI 리뷰를 투표 시스템이 아니라 증거 파이프라인으로 다루세요. - 에이전트가 실제 버그를 찾아내더라도 병합 권한은 사람에게 두세요.

에이전트 빌더에게: - 정확성, 보안, 테스트, 사용자 영향, 유지보수성, 실행 동작, 출시 위험처럼 서로 다른 임무를 가진 독립 리뷰 관점을 배정하세요. - 검증이 반박하기 전까지 소수 발견을 구조화된 주장으로 보존하세요.

코드 리뷰어에게: - 증거, 재현 단계, 영향을 받는 파일, 검증 결과, 사람의 결정 상태, 수정 검증을 요구하세요. - 근본 주장을 증명하지 않은 채 동의를 확신으로 바꾸는 리뷰 시스템은 거부하세요.

AI 코드 리뷰에 이견이 필요한 이유는 무엇인가요?

모든 리뷰어가 같은 종류의 결함만 찾으면 코드 리뷰는 조용히 실패해요.

단일 에이전트 리뷰는 하나의 실패 형태를 만들어요. 모델은 diff를 훑고, 그럴듯한 댓글을 만들고, 자기 주의 범위 밖의 문제는 놓쳐요. 다중 에이전트 리뷰가 이 형태를 개선하려면 에이전트가 독립성을 유지해야 해요. 5개의 에이전트가 같은 프롬프트를 읽고, 같은 우선순위를 물려받고, 같은 요약으로 수렴한다면 시스템은 반복만 산 셈이에요.

이견은 리뷰 표면을 바꿔요. 보안 리뷰어는 정확성 리뷰어가 받아들인 요청 흐름에 반대할 수 있어요. 테스트 리뷰어는 제품 리뷰어가 동작을 승인한 뒤에도 회귀 테스트 누락을 지적할 수 있어요. 실행 환경 리뷰어는 코드상으로는 깔끔해 보이지만 배포 제약에서는 실패하는 구현을 거부할 수 있어요.

소수 발견이 중요한 이유는 심각한 버그가 종종 외로운 반대로 시작되기 때문이에요. 합의 점수는 그 반대를 묻어 버릴 수 있어요. 좋은 리뷰 파이프라인은 주장을 증명하거나 반박할 수 있을 만큼 충분히 오래 그 반대를 살려 둬요.

독립 리뷰어는 무엇을 봐야 하나요?

독립 리뷰어에게 필요한 것은 서로 다른 이름이 아니라 서로 다른 임무예요.

관점 목록은 저장소마다 달라져야 해요. 결제 시스템에는 사기와 정산 관점이 필요해요. 컴파일러에는 정합성, 진단, 성능 관점이 필요해요. 게시 시스템에는 인용, SEO, 번역, 캐시 관점이 필요해요.

작동 방식은 안정적으로 유지돼요. 각 관점은 판정이 아니라 주장을 만들어요.

합의가 리뷰 신호로 실패하는 이유는 무엇인가요?

합의는 잘못된 질문에 답해요.

다수결은 많은 리뷰어가 동의하는지를 물어요. 코드 리뷰가 알아야 하는 것은 어떤 주장이 코드, 테스트, 실행 환경, 프로젝트 정책을 통과해도 살아남는지예요.

동의는 발견이 명백하다는 뜻일 수 있어요. 하지만 모든 리뷰어가 같은 사각지대를 공유했다는 뜻일 수도 있어요. 불일치는 잡음일 수 있어요. 하지만 한 리뷰어가 진짜 버그를 찾았다는 뜻일 수도 있어요.

더 나은 지표는 주장 상태예요.

이 상태 기계는 합의보다 나아요. 불일치를 증거 목록으로 다루기 때문이에요. 파이프라인은 시끄러운 발견을 지우지 않고 닫을 수 있고, 검증이 결함을 증명하면 외로운 발견도 승격할 수 있어요.

강한 AI 리뷰 파이프라인은 무엇을 하나요?

강한 AI 코드 리뷰 파이프라인은 단계별로 실행돼요.

1. 독립적으로 탐지해요. 리뷰 관점은 서로의 결론을 보지 않고 diff를 검사해요.
2. 주장을 중복 제거해요. 시스템은 서로 다른 증거를 뭉개지 않으면서 동등한 발견을 묶어요.
3. 가볍게 검증해요. 빠른 검사는 깨진 주장을 잡아내요. 파일 존재 여부, 변경된 줄의 도달 가능성, 테스트 존재 여부, 타입 오류, 명백히 오래된 맥락이 여기에 들어가요.
4. 깊게 검증해요. 영향이 큰 주장은 더 느린 리뷰를 받아요. 재현, 추적 기록 읽기, 집중 테스트, 보안 추론, 또는 두 번째 모델 비평이 여기에 해당해요.
5. 상태를 분류해요. 파이프라인은 각 발견을 확인됨, 반박됨, 수동 판단, 보고 전용, 또는 기준 미달로 표시해요.
6. 불확실성을 사람에게 설명해요. 리뷰어는 판단이 필요한 항목을 결정하고, 중요한 주장을 승격하며, 가치 낮은 작업을 거부해요.
7. 그룹 단위로 수정해요. 관련 발견은 함께 이동하므로 시스템이 충돌하는 패치를 적용하지 않아요.
8. 수정 사항을 다시 검토해요. 파이프라인은 변경된 코드를 다시 리뷰하고, 커밋 전에 회귀를 되돌려요.
9. 패킷을 작성해요. 최종 산출물은 발견, 증거, 결정, 테스트, 커밋, 미해결 공백을 기록해요.

adamsreview는 이 형태의 구체적인 예를 제공해요. README는 최대 7개의 병렬 하위 에이전트 관점, 중복 제거, 가벼운 검증에서 깊은 검증으로 이어지는 절차, 선택적 전체 검토, Codex 리뷰 동료, 외부 발견 주입, 불확실한 발견을 위한 점검, 그리고 살아남은 수정 사항을 커밋하기 전에 회귀를 다시 검토하고 되돌리는 수정 반복을 설명해요.¹ README가 성능 주장을 일화적이라고 표시한다는 점도 중요해요. 이 프로젝트는 벤치마크가 아니라 유용한 설계 증거로 다루세요.

AI 코드 리뷰 발견은 어떤 모습이어야 하나요?

쓸모 있는 발견에는 다른 리뷰어, 에이전트, CI 작업이 나중에 검사할 수 있을 만큼 충분한 구조가 필요해요.

id: SEC-003
lens: security
claim: "The new webhook endpoint accepts unsigned retry requests."
severity: high
affected_files:
  - app/routes/webhooks.py
evidence:
  - "Handler reads JSON before signature validation."
  - "Test suite covers valid signatures but not missing signatures."
validator:
  cheap_check: pass
  deep_check: manual
  reason: "Reachable path confirmed; exploit impact needs owner judgment."
human_decision:
  status: promoted
  reviewer: "reviewer of record"
fix_group: webhook-auth
post_fix_review:
  status: pending
remaining_gap: "Need replay test against malformed retry payload."

정확한 필드는 바뀔 수 있어요. 하지만 규율은 바뀌면 안 돼요. 발견은 주장, 증거, 검증 결과, 사람의 결정, 수정 그룹, 수정 후 상태, 남은 공백을 이름 붙여요. “webhook auth 확인”이라고만 말하는 댓글은 책임 있는 병합 결정을 뒷받침할 수 없어요. 구조화된 발견은 가능해요.

왜 사람은 최종 리뷰 책임자로 남아야 하나요?

GitHub의 리뷰 모델은 병합 전에 리뷰어에게 댓글, 승인, 변경 요청이라는 3가지 상위 결과를 제공해요.² AI 리뷰는 이 결과에 정보를 제공할 수 있어요. 하지만 조용히 그 역할을 대체해서는 안 돼요.

Rust 초안 LLM 정책은 그 경계를 분명히 그어요. 2026년 5월 18일 기준으로 이 정책은 아직 열린 pull request이며, 채택된 Rust 정책이 아니에요.³ 이 초안은 비공개 LLM 리뷰를 허용하지만, LLM 리뷰만으로 변경을 병합하거나 거부하기에 충분하다고 다루는 일을 금지해요. 또한 리뷰 봇은 자문 역할에 머물러야 하고, 봇 댓글만으로는 차단할 수 없으며, 사람 리뷰어가 처리하기를 원하는 댓글을 명시적으로 승인해야 한다고 말해요.⁴

이 경계는 책임성을 보호해요. 봇은 실제 버그를 발견할 수 있어요. 봇은 오래된 댓글, 얕은 스타일 반대, 자신감 있는 오탐도 만들 수 있어요. 최종 리뷰 책임자는 차단, 병합, 변경 요청, 또는 주장 무시 결정을 소유해요.

사람의 역할은 산출물에 나타나야 해요.

AI 리뷰는 사람의 리뷰를 더 날카롭게 만들 때 신뢰를 얻어요. 봇 판정 안에 권한을 숨길 때 신뢰를 잃어요.

리뷰 패킷에는 무엇이 들어가야 하나요?

리뷰 패킷은 리뷰 실행을 오래 남는 결정 객체로 바꿔요.

최소 필드:

패킷은 전체 대화 기록처럼 읽히면 안 돼요. 전체 대화 기록은 일어난 모든 일을 보여 줘요. 리뷰 패킷은 책임 있는 리뷰어가 결정을 내리는 데 필요한 것을 보여 줘요.

패킷은 조직의 기억도 보존해요. 다음 주에 같은 오탐이 돌아오면 팀은 왜 실패했는지 볼 수 있어요. 소수 발견이 운영 버그로 바뀌면 팀은 그 주장이 시스템을 어떻게 지나갔는지 검사할 수 있어요.

연구는 에이전트형 PR 실패에 대해 무엇을 말하나요?

실패 패턴은 리뷰 봇을 넘어 확장돼요.

MSR 2026 논문은 GitHub 전반의 에이전트 작성 pull request 33,000개를 분석했고, 문서화, CI, 빌드 업데이트 작업이 가장 높은 병합 성공률을 보인 반면, 성능과 버그 수정 작업은 가장 낮은 성과를 냈다고 밝혔어요.⁵ 저자들은 병합되지 않은 PR이 더 많은 파일을 건드리고, 더 큰 변경을 만들며, CI에 실패하는 경향도 발견했어요. 정성 분석에서는 약한 리뷰어 참여, 중복 PR, 원치 않는 구현, 에이전트 불일치 같은 거부 패턴을 확인했어요.⁵

이 발견은 실용적인 규칙을 뒷받침해요. AI 코드 리뷰는 diff에 버그가 있는지만 물어서는 안 돼요. 에이전트 작업 흐름이 유지관리자가 리뷰할 수 있는 객체를 제공하는지도 물어야 해요. 크고, 어긋나 있고, 리뷰가 약한 PR에는 더 나은 리뷰 패킷, 더 좁은 커밋 경계, 더 강한 사람의 결정 지점이 필요해요.

팀은 어떻게 시작해야 하나요?

더 많은 댓글이 아니라 더 나은 결정을 만드는 작은 리뷰 시스템으로 시작하세요.

1. 가장 위험한 코드 경로에 대해 2개 또는 3개의 관점을 고르세요.
2. 모든 발견에 주장, 증거, 영향을 받는 파일, 검증 결과를 포함하도록 요구하세요.
3. 검증기가 반박하기 전까지 소수 발견을 보존하세요.
4. 수동 판단이 필요한 주장은 점수 밑에 숨기지 말고 사람 리뷰어에게 전달하세요.
5. 오탐을 추적해 팀이 무엇을 거부하는지 시스템이 배우게 하세요.
6. 커밋 전에 수정 사항을 다시 검토하세요.
7. 패킷을 PR에 첨부하세요.

자동 패치로 시작하지 마세요. 신뢰할 수 있는 리뷰 산출물부터 시작하세요. 발견 파이프라인이 신뢰를 얻은 뒤에는 좁은 자동 수정 경로를 추가할 수 있어요. 기계적인 테스트, 명백한 null 검사, 오타 수준의 수정, 또는 사람이 점검 중에 승격한 수정이 여기에 해당해요.

목표는 코드 리뷰가 자율적으로 느껴지도록 만드는 것이 아니에요. 목표는 사람의 리뷰를 속이기 더 어렵게 만드는 것이에요.

빠른 정리

AI 코드 리뷰에는 독립적인 이견이 필요해요. 동의만으로는 발견을 증명할 수 없기 때문이에요. 강한 시스템은 리뷰어를 임무별로 나누고, 소수 주장을 보존하며, 증거를 검증하고, 불확실성을 사람에게 전달하고, 커밋 전에 수정 사항을 다시 검토해요. GitHub의 리뷰 계약은 여전히 사람의 리뷰 상태로 끝나요.² Rust 초안 정책은 사람이 주장을 승인하기 전까지 LLM 리뷰를 자문으로 유지해요.⁴ adamsreview는 관점, 관문, 점검, 수정 재검토를 갖춘 현재 파이프라인 형태 하나를 보여 줘요.¹

이기는 산출물은 봇 댓글이 아니에요. 이기는 산출물은 사람이 책임 있게 결정할 수 있게 해 주는 리뷰 패킷이에요.

FAQ

AI 코드 리뷰란 무엇인가요?

AI 코드 리뷰는 language model 또는 에이전트를 사용해 코드 변경을 검사하고, 가능한 결함을 식별하고, 위험을 설명하고, 수정을 제안하거나, 사람을 위한 리뷰 산출물을 준비하는 방식이에요. 진지한 시스템은 댓글만 게시하는 대신 각 발견에 대한 증거와 상태를 제공해야 해요.

AI 코드 리뷰는 여러 에이전트를 사용해야 하나요?

각 에이전트가 독립적인 임무를 갖고 파이프라인이 불일치를 보존할 때 여러 에이전트는 도움이 돼요. 모든 에이전트가 같은 프롬프트를 보고, 같은 요약을 만들고, 합의 점수로 수렴한다면 여러 에이전트가 더하는 가치는 작아요.

AI 코드 리뷰에서 이견이 합의보다 나은 이유는 무엇인가요?

이견은 증거가 발견을 증명하거나 반박할 때까지 드문 발견을 보이게 유지해요. 대부분의 리뷰어가 같은 엣지 케이스를 놓치면 합의는 심각한 소수 발견을 숨길 수 있어요. 코드 리뷰에는 동의만이 아니라 검증된 주장이 필요해요.

AI 리뷰어가 pull request를 차단할 수 있나요?

팀은 차단 권한을 사람에게 유지해야 해요. Rust 초안 LLM 정책은 LLM 리뷰가 자문 역할에 머물러야 하며, PR을 차단하려면 리뷰어가 LLM 댓글을 명시적으로 승인해야 한다고 말해요.⁴ 이 규칙은 더 넓은 책임 원칙과 맞아요. 병합 결정은 사람 리뷰어가 소유해요.

AI 리뷰 패킷에는 무엇이 포함되어야 하나요?

AI 리뷰 패킷에는 범위, 관점, 발견, 증거, 검증 결과, 사람의 결정, 수정 그룹, 재검토 결과, 관련 있는 경우 출시 증거, 그리고 미해결 공백이 포함되어야 해요. 패킷은 독자가 전체 대화 기록을 읽지 않아도 리뷰 결정을 감사할 수 있게 만들어야 해요.

팀은 언제 자동 수정을 허용해야 하나요?

팀은 발견 파이프라인이 신뢰를 얻은 뒤에만 자동 수정을 허용해야 해요. 기계적이고 위험이 낮은 수정부터 시작하거나, 리뷰 중 사람이 승격한 발견부터 시작하세요. 모든 자동 수정에는 수정 후 리뷰와 롤백 경로가 필요해요.

참고 문헌