코드리뷰 잘하는 법 (팀이 성장하는 리뷰 vs 감정 상하는 리뷰)

코드리뷰만 올라오면 마음이 무거워지는 사람 많습니다. 지적당하는 느낌, 끝없는 코멘트, 며칠째 머지 안 되는 PR. 하지만 코드리뷰는 비난이 아니라 팀의 집단지성입니다. 잘하면 코드 품질과 팀워크가 동시에 오르고, 못하면 둘 다 무너집니다.

1. 리뷰어: '코드'를 지적하되 '사람'을 공격하지 마라

같은 내용도 표현에 따라 완전히 다르게 읽힙니다.

[나쁜 코멘트]
- "이건 왜 이렇게 짰어요?"
- "이거 완전 안티패턴인데요."
- "다시 하세요."

[좋은 코멘트]
- "여기 map 안에서 setState를 호출하면 리렌더가
  여러 번 일어날 수 있어요. useMemo로 묶는 건 어떨까요?"
- "제안: 이 부분을 함수로 분리하면 테스트하기 편할 것 같아요."
- "(질문) 이 케이스에서 null이 들어오면 어떻게 되나요?"

핵심은 이유 + 대안 + 부드러운 어조입니다. 명령이 아니라 제안으로 말하세요.

2. 코멘트에 '심각도'를 표시하라

모든 코멘트가 같은 무게로 읽히면 작성자는 지칩니다. 라벨로 우선순위를 알려주세요.

라벨	의미	머지 차단?
[must]	버그·보안 등 반드시 수정	O
[should]	권장 개선, 논의 가능	협의
[nit]	사소한 취향(네이밍 등)	X
[question]	단순 궁금증	X

"[nit] 변수명 user_list보다 users가 어떨까요?"처럼 라벨만 붙여도, 작성자는 '이건 안 고쳐도 머지되는구나'를 바로 압니다.

3. 작성자: 리뷰받기 쉬운 PR을 만들어라

리뷰는 작성자 하기 나름입니다. 작고, 설명된 PR이 빨리 통과됩니다.

• PR은 300줄 이하로 잘게 쪼개기 (큰 PR은 리뷰 품질이 급락)
• PR 설명에 무엇을·왜·어떻게 테스트했는지 적기
• 스스로 한 번 셀프 리뷰 후 올리기
• 리뷰 코멘트엔 방어 대신 "좋은 지적이에요" 또는 "이 이유로 이렇게 했는데 어떠세요?"로 대화하기

4. 리뷰 속도도 매너다

리뷰가 며칠씩 방치되면 팀 전체가 느려집니다. 24시간 내 1차 응답을 팀 규칙으로 정하면 좋습니다. 바쁘면 "오늘 오후에 볼게요"라는 한마디라도 남기세요.

마무리 체크리스트

• 코멘트에 이유와 대안을 함께 적었는가
• must/nit 등 심각도를 구분했는가
• 사람이 아닌 코드를 이야기했는가
• PR을 작게 쪼개고 설명을 달았는가
• 리뷰 응답을 하루 안에 했는가

좋은 리뷰 문화의 목표는 '완벽한 코드'가 아니라 **'함께 더 나아지는 팀'**입니다. 오늘 코멘트 하나를 제안형으로 바꿔보세요.