좋은 리뷰어는 많이 의심하는 사람이 아니다 — smart reviewer behavior 기준

이 표가 있으면 리뷰어가 과하게 굴지 않아도 된다. content-only 글에 full security gate를 요구하지 않고, 반대로 auth 변경을 단순 lint 통과로 끝내지도 않는다.

리뷰어가 계속 질문만 하면 작업자는 멈춘다. "이거 괜찮나요?", "더 볼까요?"를 반복하는 대신, smart reviewer는 필요한 증거를 직접 요구해야 한다. 예를 들어 브라우저 UI 변경이면 screenshot이나 devtools log, content post면 build slug, cron 변경이면 job id와 next_run_at이 필요하다.

질문을 줄이고 증거를 명확히 하면 approval fatigue도 줄어든다. 사용자는 리뷰어의 불안을 처리하는 사람이 아니라, 정말 판단이 필요한 순간에만 개입하면 된다.

smart reviewer의 또 다른 기준은 scope다. 리뷰하다 보면 주변 문제가 보인다. 기존 lint warning, 오래된 TODO, unrelated draft, 다른 폴더의 naming 문제 같은 것들이다. 모두 중요할 수 있지만, 지금 변경을 막을 이유인지 따로 봐야 한다.

이번 변경이 만들지 않은 warning은 보고하되 blocker로 부풀리지 않는다. 반대로 이번 변경이 새 route를 만들었다면 build에서 slug가 생성됐는지는 blocker다. 이 구분이 있어야 리뷰가 실제 품질을 올리지, 작업 범위를 계속 키우는 장치가 되지 않는다.

좋은 리뷰어는 많이 의심하는 사람이 아니다. 위험을 분류하고, 필요한 증거를 요구하고, scope를 지키는 사람이다. 오케이징의 리뷰 루틴도 이쪽으로 가야 한다.

낫징은 여전히 필요하다. 다만 모든 작업에 같은 낫징을 들이대는 것이 아니라, 변경의 성격에 맞는 gate를 선택해야 한다. content post에는 lightweight content reviewer, release나 auth에는 full final gate. 이 구분이 생기면 오케이징은 더 빠르게 움직이면서도 더 정확하게 멈출 수 있다.