
AI가 리뷰를 마친 PR을 인간이 다시 버그 찾기를 하는 것은 잘못된 일이다
요약
AI와 CI가 1차 리뷰를 마친 PR에 대해 인간이 단순 버그를 다시 찾는 것은 비효율적입니다. 인간은 기계가 판단하기 어려운 설계, 이식 충실성, 권한 경계와 같은 고차원적인 영역에 집중해야 합니다.
핵심 포인트
- AI/CI는 스타일, null 참조 등 정형화된 검사를 담당
- 인간은 이식 충실성, 설계 판단, 권한 경계에 집중
- AI의 리뷰 결과(지적 또는 통과)를 맹신하지 말고 검증 필요
- 코드 리뷰의 목적은 완벽함이 아닌 지속적인 코드 건강 개선
결론부터 말씀드리면
AI나 CI가 리뷰를 마친 PR을 인간이 다시 처음부터 버그 찾기를 하는 것은 효율적이지 않습니다. 스타일의 흐트러짐, null 참조, 비효율적인 루프, 포맷팅. 이런 종류의 정형화된 검사는 기계가 인간보다 더 빠르고 정확하게 처리합니다. 인간이 그 부분을 훑는다고 해서 가치가 늘어나지는 않습니다.
그렇다면 인간은 무엇을 해야 할까요? 기계가 원리적으로 판단할 수 없는 고차원적인 사항들입니다. 저는 다음 세 가지에 집중하고 있습니다: 이식 충실성 (Porting Fidelity), 설계 판단, 권한 경계. 그리고 AI의 "지적"도 "문제 없음"도 그대로 믿지 않는 것입니다.
우선, 기계와 인간의 역할을 나누어야 합니다
코드 리뷰의 정석 가이드들도 같은 방향을 가리키고 있습니다.
Google의 eng-practices는 리뷰의 제1 목적을 "코드베이스 전체의 code health가 시간이 지남에 따라 개선되는 것"이라고 정의합니다. OWASP의 Secure Code Review Cheat Sheet는 수동 리뷰를 자동 테스트 (SAST/DAST)의 보완으로 위치시키며, 비즈니스 로직의 검증이나 컨텍스트 의존적 취약성이라는 "인간의 분석 가치가 가장 높은 영역"에 집중하라고 말합니다.
즉, AI와 CI는 지원 도구이며, 판단은 인간의 몫입니다. 기계가 1차적으로 표층을 정리한 뒤, 인간이 고차원적인 부분을 보는 것. 이 순서가 역전되지 않도록 하는 것이 중요합니다.
인간이 보는 3가지 축
1. 이식 충실성 (Porting Fidelity)
기존 구현을 베이스로 하여 다른 화면이나 다른 레이어로 전개하는 파생 PR. 이 부분이 인간이 가장 눈여겨봐야 할 곳입니다.
"로직은 원본과 동일합니다"라는 주장이 정말로 동일한지. 누락, 열화, 혹은 반대로 너무 많이 삭제하지는 않았는지. 이는 차이점(diff)을 바라보는 것만으로는 알 수 없습니다. 참조 원본의 구현과 1:1 diff를 실제로 대조하여 과부족을 확인해야 합니다. 수고스러운 작업이지만, AI가 가장 실수하기 쉬운 영역이기도 합니다.
2. 설계 판단
스코프를 나누는 방식, 영속화 대상이나 데이터 모델의 선택, 상태의 의미 부여. 예를 들어 "계산할 수 없음"과 "아직 계산하지 않음"을 동일하게 표시해도 되는가와 같은 문제입니다. 코드의 정답 여부가 아니라 도메인과 맞물려 있는가의 문제이므로, 기계에게는 판단할 재료가 없습니다.
3. 권한 경계
인가(Authorization)의 전제가 바뀌는 이식 작업에서 특히 중요합니다. 이 fetch나 mutation을 해당 역할(role)이 호출할 수 있는지, 호출해도 "좋은지". 타사 또는 타 테넌트의 데이터를 취득하거나 업데이트할 수 있게 되지는 않는지. 원본 구현의 권한 전제를 그대로 옮기다 보면 경계가 조용히 무너지는 경우가 있습니다. OWASP가 "인간의 가치가 가장 높다"고 말하는 컨텍스트 의존적 취약성이 바로 이 지점입니다.
AI의 지적은 검증한 뒤에 받아들여야 합니다
LLM의 리뷰는 그럴싸해 보이지만 세부 사항을 놓치곤 합니다.
보안 코드 리뷰 실증 연구 (arXiv:2401.16310)에 따르면, LLM이 결함 탐지에서 정적 분석 도구를 능가하는 한편, GPT-4는 모호한 표현을 내뱉거나 지시를 정확히 따르지 못하는 경우가 많고, 다른 모델들은 코드의 세부 사항을 부정확하게 기술하는 경향이 있다고 보고되었습니다. 성능이 높은 것과 세부 사항이 정확한 것은 별개의 문제입니다.
따라서 AI의 "이 부분이 위험하다"는 말도, AI의 "문제 없습니다"라는 말도, 둘 다 도메인의 문맥 안에서 인간이 확인해야 합니다. 행 번호나 함수명이 어긋나지 않았는지, 그 지적이 정말로 성립하는지. 지적의 유무를 그대로 결론으로 삼아서는 안 됩니다.
합격 라인은 "완벽"이 아닙니다
마지막으로 한 가지. Google의 eng-practices는 "완벽한 코드란 존재하지 않으며, 오직 더 나은 코드만 있을 뿐이다"라고 단언합니다. 리뷰의 기준은 시스템 전체의 code health가 순수하게 개선되는가입니다.
AI가 찾아낸 사소한 지적을 인간이 증폭시켜, 완벽주의 때문에 머지(merge)를 막는 것은 이 기준에 어긋납니다. 기계가 세세한 부분을 잡아주는 시대이기에, 인간은 오히려 "이것이 중단할 정도의 일인가"를 판단하는 쪽으로 돌아가야 합니다.
리뷰의 업무는 상류로 이동합니다
AI 리뷰가 도입된 만큼 인간의 일이 없어지는 것은 아닙니다. 상류로 이동할 뿐입니다. 행을 쫓는 작업은 기계에 맡기고, 인간은 "이 설계가 맞는가", "이 사람이 이것을 건드려도 되는가"에 시간을 씁니다. 저는 그렇게 마음을 먹고 나서 리뷰가 훨씬 편해졌습니다.
출처
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기