코드 리뷰의 예술: 단순한 버그 사냥을 넘어

Source: Dev.to

코드 리뷰는 건강한 엔지니어링 팀의 심장 박동과 같습니다. 이는 품질을 보장하고, 지식을 공유하며, 일관성을 유지하기 위한 우리의 주요 메커니즘입니다. 그러나 이를 단순히 버그를 잡는 탐험이나 스타일을 강제하는 절차로만 접근한다면 핵심을 놓치게 되고, 동료들을 좌절시킬 위험이 있습니다.
코드 리뷰 프로세스를 단순한 잡무에서 팀 성장과 제품 안정성을 위한 강력한 도구로 끌어올릴 수 있는 방법을 살펴보겠습니다.

“무엇” 뒤에 있는 “왜”

코드 한 줄도 보기 전에 상황을 이해해야 합니다. 설명이 없는 PR은 범례 없는 지도와 같습니다.

작성자로서

• 이 변경이 무엇을 하는가? – 요약
• 왜 이 작업을 하는가? – [티켓/이슈 링크]
• 어떻게 테스트해야 하는가? – 스크린샷, 터미널 출력, 혹은 테스트 단계

리뷰어로서

황금 규칙: 사람을 아니라 코드를 리뷰하라

이것은 가장 오래된 규칙이지만 가장 마스터하기 어려운 규칙입니다. 코드를 한 줄 읽고 “이거 지저분해.”라고 생각하기 쉽습니다.
차이는 미묘하지만 결정적입니다:

• “이거 지저분해.” → 작성자의 정체성을 공격합니다.
• “이 코드를 따라가기 어렵다.” → 코드 자체에 대한 중립적인 관찰입니다.

피드백 표현 방법

자동화된 사소한 지적

이것은 코드 리뷰에서 가장 큰 생산성 해킹입니다. 세미콜론 누락, 들여쓰기 오류, 혹은 린터가 잡아낼 수 있는 부적절한 변수 이름을 지적한다면, 모두의 시간을 낭비하는 것입니다.

현대 개발 환경은 강력합니다. ESLint, Prettier, RuboCop, 혹은 GitHub Actions와 같은 도구를 사용해 코드 스타일을 자동으로 강제하세요.

왜?
CI 파이프라인이 통과하면 코드는 이미 올바르게 포맷된 것입니다. 리뷰에서 다시 언급하지 마세요.

균형 잡기: Nit vs. Blocking

• Blocking (Request Changes): 프로덕션을 중단시키거나 보안 취약점을 만들거나 비즈니스 요구사항을 놓치는 중대한 이슈. 이를 해결하지 않으면 PR을 병합할 수 없습니다.
• Ask (Question): “이 접근 방식이 궁금합니다. 여기서 map 대신 for 루프를 선택한 특별한 이유가 있나요?” – 토론과 학습을 촉진합니다.
• Nit (Nitpick): “아주 사소한 점이지만…” 혹은 “명확성을 위해 이름을 바꾸는 것을 고려해 보세요.” Nit은 절대 병합을 차단해서는 안 됩니다. 작성자가 다른 우선순위가 있다면 Nit을 무시하고 진행할 수 있습니다.

공개적으로 칭찬하기

코드 리뷰 댓글은 영구 기록입니다. 복잡한 문제에 대한 기발한 해결책, 잘 작성된 테스트, 디자인 패턴의 훌륭한 활용 등 뛰어난 것을 보면 꼭 언급하세요. 긍정적 강화는 단순히 “친절하게 대하는 것”이 아니라 기준을 세우는 일입니다.

• “와, 새로운 CSS :has() 선택자를 그렇게 사용할 수 있는지 몰랐어요. TIL!”
• “이 유틸리티 함수는 정말 깔끔하고 재사용성이 뛰어나네요. 훌륭한 작업입니다.”

시의성 > 완벽함

우리는 모두 “중요한” 작업을 마무리하는 동안 PR을 이틀 동안 방치한 적이 있습니다. 그 사이에 작성자는 작업이 막히고, 맥락이 사라지며, 병합 충돌이 쌓이기 시작합니다.

• 비동기 우선 협업을 목표로 합니다.
• 작은 PR이 더 좋습니다: 10줄 정도의 변경은 검토하기 쉽지만, 2,000줄 정도의 변경은 위압적이며 검토가 대충 넘어가거나 무시될 가능성이 높습니다.
• 24시간 이내에 응답하세요. 짧게라도 “제가 맡겠습니다, 오늘 마감까지 검토하겠습니다” 라는 메시지만으로도 작성자의 정신적 차단을 해제할 수 있습니다.

최종 평결

목표는 소프트웨어 역사상 가장 깔끔한 코드를 만드는 것이 아닙니다. 목표는 행복하고 협업적인 팀을 유지하면서 사용자에게 가치를 안정적으로 제공하는 것입니다. 우리는 비판만 하는 것이 아니라, 차단을 해제하고, 가르치며, 협업하는 리뷰어가 되자.