AI 코드 리뷰, “문제없음”보다 재현 가능한 테스트가 낫다

요약보다 diff에서 시작한다

AI가 바꾼 파일 목록을 열고 요청하지 않은 설정, 삭제, 의존성 변경이 있는지 먼저 본다. 코드 한 줄을 고쳤다면서 수십 파일을 건드렸다면 의도와 범위를 다시 물어야 한다. 실제 개발자 경험에서도 계획·구현·리뷰 단계를 분리하고 검증 스크립트를 갖추는 쪽이 막연한 “코드 괜찮아?” 질문보다 효과적이었다.

리뷰 지적은 재현 입력으로 바꾼다

“빈 배열일 때 오류 가능”이라는 지적을 받으면 빈 배열을 실제 입력해 본다. 문제가 재현되면 먼저 실패하는 테스트를 남기고 수정한다. 재현되지 않으면 버전, 호출 경로, 기존 테스트를 확인한 뒤 오탐일 가능성을 기록한다. AI가 놓친 경우도 있으니 정상 경로뿐 아니라 경계값·실패 경로를 넣는다.

마지막 한 번은 소비자 화면에서

빌드 성공과 유닛 테스트 통과 뒤에도 모바일 화면이 깨지거나 버튼이 다른 위치를 가리킬 수 있다. 배포 전엔 실제 사용자 행동 한 가지를 끝까지 해본다. 자동 리뷰는 사람의 주의를 좁혀주는 도구이지 최종 승인자가 아니다.