코드 리뷰에는 읽기가 필요하다

• 코드 리뷰는 배포 전 형식 절차가 아니라 장애·보안 문제·데이터 삭제 책임을 한 개인에서 팀 책임으로 옮기는 과정임
• 더 나은 평가·테스트·기능 플래그·가드레일·관측 가능성은 읽지 않은 코드 배포의 불안을 줄이려는 답변일 수 있지만, 리뷰의 책임 분산 목적을 놓친 접근이라는 비판임
• 읽지 않고 승인하라는 요구는 사람에게 생각 없이 버튼을 누르게 하는 것과 같으며, CI가 모두 green인 무작위 PR을 병합하는 button roulette 풍자로 이어짐
• 코드 리뷰는 큰 코드베이스의 여러 부분을 팀원이 보게 만들어 bus factor를 낮추고, 새 팀원이 코드와 코드 문화를 익히는 학습 장치로 기능함
• 읽지 않은 코드 배포를 강요하려면 버그·보안 문제·다운타임 등에 대한 서면 책임 면제가 필요하며, 그런 면제를 받기는 어렵다는 결론임

리뷰의 목적은 승인보다 책임 분산

• Charity Majors의 글 “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy”에 나온 “읽지 않은 코드를 프로덕션에 배포해도 편안해지려면 무엇이 필요한가”라는 질문이 출발점임
• 더 나은 evals, 테스트, 기능 플래그, 가드레일, 관측 가능성, 의존성 분리, 폭발 반경 축소, 중요 경로 밖의 작은 변경부터 시작하기 같은 답변은 리뷰의 핵심을 비껴간 것으로 다뤄짐
• 리뷰의 목적은 장애, 보안 문제, 우발적 데이터 삭제에 대한 부담을 한 개인에게 두지 않고 작성자와 리뷰어 전체의 팀 책임으로 나누는 데 있음
• “읽지 않고 승인”을 요구한다면 사람에게 수동으로 버튼을 누르게 할 이유가 약해지며, 모든 CI가 green인 할당 PR 중 하나를 무작위로 병합하는 button roulette이라는 풍자가 등장함

읽지 않는 리뷰가 잃는 것

• 코드 리뷰는 팀원이 코드베이스의 다른 부분을 보도록 강제해, 너무 큰 시스템에서 모든 부분을 항상 알고 있을 수 없는 한계를 보완함
• 리뷰 과정은 bus factor를 낮추고, 팀의 여러 구성원이 코드베이스와 코드 문화에 더 익숙해지도록 돕는 역할을 함
• 모두가 읽지 않고 승인하게 되면 이런 학습 효과를 잃고, bus factor가 1로 올라갈 뿐 아니라 제3자에게 외부화되는 문제가 생김
• 읽지 않은 코드를 프로덕션에 배포하라는 요구를 받아들이려면, 그 지시를 내린 사람이 버그·보안 문제·다운타임 등에 대한 서면 책임 면제를 제공해야 한다는 답변으로 정리됨