인공지능이 코드 양을 폭증시킨 뒤, 코드 리뷰는 어떻게 버틸까

• 인공지능이 코드 생산량을 늘리면서, 풀 리퀘스트 리뷰가 팀의 새 병목으로 떠오르고 있음

  • 글쓴이의 기준은 꽤 단순함. 사람이든 인공지능이든 “읽을 만하게, 책임 있게 만든 코드”면 성실하고 빠르게 리뷰함
  • 반대로 작성자가 자기 코드도 안 읽은 티가 나는 인공지능 덩어리면, 리뷰어도 인공지능 리뷰 결과를 던지고 깊게 읽지 않음. 약간 매운 대응이지만 현실적임

• 이 방식의 핵심은 “상호성”임

  • 리뷰를 받을 만큼의 노력을 작성자가 넣었다면 리뷰어도 같은 밀도로 봐줌
  • 작성자가 인공지능 출력물을 거의 그대로 던졌다면, 리뷰어가 인간 디버거처럼 고생할 이유가 없다는 얘기임

• 애매한 품질의 풀 리퀘스트에는 바로 전체 리뷰를 하지 않고, 작은 개선 포인트를 먼저 던짐

  • 예를 들면 “시스템 호출 4번 대신 2번으로 줄이면 어떰?” 같은 식으로 구체적인 대안을 제시함
  • 또는 중복 코드를 메서드로 뽑아 호출하게 만들자는 식의 리팩터링 제안을 던짐
  • 작성자가 그 제안에 자기 생각으로 답하면 이후 리뷰를 이어가고, 인공지능의 변명문을 그대로 붙여오면 정중하게 빠짐

• 코드 변경의 목적을 묻는 질문도 중요하게 다뤄짐

  • “프로덕션 장애 패치라면 최소 변경이어야 하지 않나?”처럼 변경량이 과한 상황을 짚음
  • “이 접근이 런타임 효율, 유지보수성, 복원력 중 뭘 최적화한 건지 모르겠다”처럼 설계 목표를 명확히 요구함
  • 이 질문은 단순 트집이 아니라, 인공지능이 만든 그럴듯한 코드가 실제 문제 해결과 어긋나는 걸 막는 장치임

• 개발팀 입장에서는 리뷰 정책을 다시 써야 할 타이밍임

  • 인공지능 사용 금지 같은 단순한 규칙보다, 작성자가 변경 의도와 테스트 근거를 설명하게 만드는 쪽이 더 실용적임
  • 리뷰어도 모든 코드를 같은 깊이로 봐야 한다는 압박에서 벗어나야 함. 입력 품질이 다르면 리뷰 방식도 달라져야 함

---

기술 맥락

• 여기서 중요한 선택은 인공지능 코드 자체를 막는 게 아니라, 풀 리퀘스트의 책임 기준을 다시 세우는 거예요. 코드가 빨리 많이 생기는 상황에서는 리뷰어 시간이 더 희소해지기 때문에, 작성자가 변경을 이해했다는 신호가 필요하거든요.

• “중간 품질 코드에 작은 제안을 먼저 던진다”는 방식은 일종의 저비용 검증이에요. 작성자가 맥락을 이해하고 있으면 제안의 장단점을 이야기할 수 있고, 이해하지 못했으면 인공지능 답변을 대신 붙여오는 식으로 티가 나요.

• 프로덕션 패치에서 변경량을 줄이라고 묻는 것도 같은 맥락이에요. 장애 대응 코드는 멋진 리팩터링보다 위험 면적을 줄이는 게 더 중요할 때가 많거든요. 그래서 리뷰어는 코드 스타일보다 “이 변경이 지금 문제에 맞는 크기인가”를 먼저 보는 거예요.