AI가 작성한 풀 리퀘스트를 대충 검토하는 리뷰어들을 어떻게 막을까?

네가 나열한 세 가지 버그는 공통점이 있음. 구문이 아니라 동작 방식의 문제라 diff를 훑는 리뷰어는 절대 못 봄. 인간의 주의력에 의존하기보다 크게 실패하도록 만드는 체크로 옮기겠음.

반전된 플래그의 경우, 플래그를 명시적으로 켜고 끈 상태에서 두 분기를 모두 단언하는 테스트를 요구함. 재시도 래퍼의 경우, 재시도되는 모든 것은 멱등성 키를 가지거나 두 번 호출해서 단일 부작용을 단언하는 테스트가 있어야 한다는 규칙을 세움. 마이그레이션은 CI에서 프로덕션 크기의 데이터 복사본을 대상으로 실행하고 락 시간이나 문장 실행 시간이 예산을 초과하면 실패하게 함(마이그레이션 자체에 Postgres lock_timeout을 낮게 설정하는 것도 도움됨).

그러면 인간 리뷰는 더 좁은 역할을 맡게 됨. 지정된 리뷰어 한 명이 모든 줄이 아니라 위험 영역(결제, 인증, 마이그레이션, 플래그)과 테스트만 읽는 거임. 유용한 팁은 저자에게 무엇이 잘못될 수 있고 테스트가 어떻게 그걸 잡아낼지 PR 설명에 나열하라고 하는 거임. 목록이 비어있거나 일반적이라면 그게 바로 반려 신호임.

작은 PR도 도움이 되지만, 에이전트는 diff를 싸게 생성하니까 줄 수가 아니라 변경된 동작의 수로 제한하겠음.

네가 겪은 세 가지 버그의 공통점은 diff 자체에는 보이지 않는다는 거임. 멱등성, 락 시간, 플래그 기본값은 동작의 문제라 리뷰어의 머릿속에서 꺼내서 체크 항목으로 옮기겠음.

결제 재시도의 경우, 같은 요청을 두 번 쏘고 한 번만 결제되는지 단언하는 테스트를 넣음. 마이그레이션은 CI에서 프로덕션 크기 복사본을 대상으로 실행하고 몇 초 이상 락을 잡으면 실패하게 함. 플래그는 플래그가 꺼졌을 때 기본 상태를 확인하는 테스트를 넣음.

그러면 인간 리뷰어는 이 변경이 애초에 필요한지 같은, 체크가 할 수 없는 결정만 내리면 됨. 그리고 돈, 인증, 스키마를 건드리는 건 두 명의 반쪽짜리 리뷰보다 한 명의 지정된 진짜 리뷰어를 두는 것에 동의함.

나한테 효과적이었던 건 저자가 PR 설명에 재시도, 마이그레이션, 플래그 기본값처럼 에이전트가 스스로 결정한 부분을 나열하게 만드는 거였음. 리뷰어들은 diff 전체를 훑는 대신 그 부분들을 제대로 읽게 됨. 에이전트가 자주 틀리는 것들(멱등성, 락 시간, 반전된 조건)을 짧은 체크리스트로 만들어서 사람이 체크하게 하는 게 일반적인 체크리스트보다 나음. 너희 팀 개발자 8명은 주로 같은 서비스를 다룸, 아니면 영역별로 나뉘어 있음?

우리한테 효과적이었던 건 누가 승인하느냐가 아니라 저자가 무엇을 제출해야 하는지를 바꾸는 거였음. 각 PR 설명에 재시도, 마이그레이션, 플래그 뒤에 숨은 로직 등 위험한 부분을 평문으로 나열하고, 확인을 위해 실제로 무엇을 실행했는지 적게 했음. 네가 겪은 세 가지 버그는 누군가 지적해주지 않으면 읽는 사람이 절대 못 잡는 것들이라, '이 호출은 멱등한가?', '마이그레이션이 어떤 락을 거는가?', '플래그 기본값은 어느 쪽인가?' 같은 짧은 체크리스트가 대충 훑어보는 것보다 훨씬 나음. 또한 PR마다 한 명을 지정된 진짜 리뷰어로 정하고 두 번째 사람은 선택 사항으로 뒀더니, 승인 과정이 즉각적인 것에서 사려 깊은 것으로 바뀌었음.

나쁜 코드에 대한 대충 검토는 AI 이전에도 있었음. 기본적으로 피할 수 없는 일이고, 사람들이 배우는 유일한 방법은 직접 당해봐야 하는 거임. 가장 좋은 방법은 리뷰어에게도 저자와 똑같이 프로덕션 버그에 대한 책임을 묻는 거임. 여기서 유일한 차이점은 나쁜 코드가 훨씬 많이 돌아다니고, 그중 일부는 결함이 숨겨진 방식이 거의 악마적이라는 거지. 그래서 리뷰어들이 실패하고 책임을 지는 모습을 훨씬 더 많이 보게 되겠지만, 그건 절대 나쁜 게 아님. 그들은 대충 검토하는 걸 멈추고 노력을 들이기 시작할 거임.