[Essay] 코드 리뷰 할 때 중요한 것

나는 지난 2022년 팀에서 코드리뷰 문화를 개선하고자 집중 코드리뷰 시간을 도입하고 PR 작성 방법을 논의하여 실무에 적용해 현재까지 실행 및 유지하고 있다. 현재까지 느낀 내가 코드 리뷰 할 때 중요하게 생각하는 것들을 정리하고자 한다.
 

💻 코드 리뷰란

코드 리뷰란 개발자가 어떤 기능/이슈를 위한 코드를 작성하면, 다른 개발자들이 피드백을 주고받는 과정이다.
 

✨ 코드 리뷰의 장점

• 본인이 놓쳤을 수도 있는 이슈를 다른 사람이 먼저 발견하여 Side Effect를 미리 대응할 수 있고, 서비스의 안정성이 높아진다.
• 팀 내 컨벤션 규칙에 따랐는지 확인하여 일관성을 유지할 수 있고, 코드 품질이 향상된다.
• 코드 검토 과정에서 지식 공유가 이루어지고, 서로 다른 시각과 스타일을 공유하며 협업을 바탕으로 개발문화를 발전시킬 수 있다.
• 추후 해당 코드에서 이슈가 발생했을 때, 여러 명이 같이 확인했기에 개발자 개인이 혼자 책임져야 한다는 부담감이 감소된다.

 

📄 코드 리뷰를 위한 PR(Pull Request) 템플릿 예시

코드리뷰를 요청할 때, PR을 작성하게 되는데 최대한 이해하기 쉽게 필요한 정보를 제공해야 한다. 예를 들어, 회사에서 PR을 올릴 때 신규 프로젝트라면 다음과 같은 양식으로 내용을 작성한다.

[기획]
1. 개요 (기획)
2. 설명 (코드)
3. PR 중요도 (보통/중요/긴급) 
4. PR 기한
5. 배포 예정일
6. 참고 링크 (기획 문서, 디자인 링크)

[작업 내용]
- 추가 신규 기능 또는 변경 사항

 
이슈 수정 건이라면 비슷한 양식이지만 상황과 원인에 대한 설명이 들어가게 된다. 크로스 체크가 필요한 부분을 수정했다면 작업 내용을 작성할 때 특별히 요청사항으로 적어두어 모두가 인지하도록 한다. 다른 사람들이 궁금한 부분이 있을 것 같다면 그 부분에 대한 내용을 조금 더 자세히 적어두면 좋다. 이렇게 올라온 PR에 리뷰어들이 하나둘씩 코드를 검토하고 리뷰를 남기면 된다.
 

⭐️ 코드 리뷰할 때 중요한 것

1. 개선/수정 요청에 대한 이유를 설명하기

코드가 개선 또는 수정되어야 한다고 생각해서 리뷰를 남긴다면, 명확한 이유를 설명해야 한다. 이유가 작성되어 있지 않다면, 리뷰받는 사람은 그 리뷰의 의도를 잘 모를 수 있다. 그래서 구체적인 이유를 남겨주어 코드 리뷰에 오해가 없는 것이 중요하다. 수정되어야 할 코드는 특정 줄에서 어떤 문제가 예상되는지, 혹은 어떤 에러가 발생한다면 그 에러의 재현절차를 같이 명시해 준다.

// 안 좋은 리뷰
"delete로 변경해야 할 것 같아요."

// 좋은 리뷰
"이 버튼의 기능은 삭제인데, 
이 변수명은 delete가 아닌 update여서 삭제의 의미를 담고 있지 않아 혼란이 생길 수 있을 것 같아요.
delete로 변경한다면 의도를 쉽게 파악할 수 있을 것 같습니다."

// 위 리뷰를 본 개발자의 답변
(아하! 그렇게 생각할 수 있겠구나)"이 기능의 Api method가 delete가 아닌 update이고, 이 프로젝트 컨벤션은...(후략)"

 
 

2. 컨벤션 규칙은 리뷰하되 개발자의 스타일 자체를 리뷰하는 것은 지양하기

클린 코드를 위해서는 진행하는 프로젝트의 컨벤션 규칙을 따르는 것이 좋다. 만약 예외적인 케이스가 아니라면, 약속된 규칙을 지켜야 코드 가독성이 높아지고 업무도 효율적으로 할 수 있다. 그렇기 때문에 컨벤션 규칙과 다른 부분을 발견한다면 리뷰를 남기는 것이 좋다.
다만 여기서 주의할 점은 개발자의 코드 스타일 자체를 리뷰하는 것은 지양해야 한다는 것이다. 예를 들어 PR을 확인하다가 '어? 이 부분은 이렇게 하면 더 깔끔해질 것 같은데..'라고 생각이 들 수 있지만, 코드 가독성에 대한 부분은 주관적일 수 있다.
개발자마다 코드 스타일은 모두 다르기 때문에, 조금 더 자유롭게 의견을 낼 수 있는 분위기가 줄어들면서 개발자가 소극적으로 변할 가능성이 있다. 또한 개발자 개인의 성장에도 영향이 갈 수 있기 때문에, 개인의 코드 스타일을 참견하거나 부정적인 뉘앙스로 평가하는 듯한 피드백은 지양할 필요성이 있다.
 

3. 코드 뒤에 사람 있어요

코드 리뷰할 때 가장 중요한 것 중 하나는 소프트 스킬이다. 코드 리뷰에 속상해하거나 두려워하는 사람들이 꽤 많다. 이는 아무래도 내가 짠 코드를 나와 어느 정도 동일시하게 되어서 나에 대한 리뷰라고 느끼기 때문인 것 같다. 많은 개발자들이 나에 대한 비판이 아니라는 것을 알고 있지만, 그래도 기분은 썩 유쾌하지 않을 수 있다.
리뷰를 받는 사람도 방어적인 태도로 일관하지 않는 것도 필요하지만, 리뷰를 작성하는 사람도 리뷰가 전달하고자 하는 의미에만 집중할 수 있게 부드럽게 전달하는 스킬이 필요하다. 나는 지금 회사 입사했을 때 소프트 스킬이 뛰어나신 개발자님들이 많아서 보고 많이 배웠는데, 소프트 스킬이 좋을수록 오해나 불필요한 작업이 없어 협업이 효율적으로 진행되는 것을 알게 되었다. 그래서 우리는 코드 리뷰를 작성할 때에도 팩트만 전달하지 않고 이모지도 쓰고 감정 표현을 많이 넣어서 리뷰한다. 그리고 잘 작성한 코드에 대해서는 긍정적인 피드백을 아끼지 않고 구체적으로 하면, 코드 리뷰가 더욱 즐거워진다.
 

4. 최대한 빠르게 리뷰하기

개발자가 코드 리뷰 기한을 올렸다면 최대한 그 기한 내에는 무조건 리뷰를 해야 한다. 기한을 공유한 이유는 그 이후에 진행되어야 하는 QA 일정, 배포 일정이 있기 때문이다. 팀과 회사의 일정이 지켜지기 위해서 하나의 프로세스임을 잊지 말고, 급하게 리뷰를 진행해서 코드 품질을 확인하지 못하는 일이 생기지 않도록 리뷰를 하는 것을 권장한다. 가급적이면 올린 당일 리뷰하는 것이 좋으며, 하루를 넘기면 PR을 머지한다는 팀 내 약속을 정해도 좋다.
 

✅ 우리가 적용한 코드 리뷰 규칙들

집중 코드 리뷰 시간 도입

우리는 점심시간 직후에 '집중 코드 리뷰 시간'을 도입해서 유지하고 있다. 리뷰가 필요한 PR이 있을 경우에 이 시간대에 진행하고, 만약 긴급 건이 있다면 그 외 시간에도 리뷰를 하게 된다. 이 시간을 도입하기 전에는 하는 사람만 코드 리뷰를 했고, 실제로도 업무가 바쁜 사람은 코드 리뷰를 위해 시간을 내기가 어려웠다. 하지만 이 시간이 생긴 뒤로부터는 모두 더 적극적으로 리뷰를 하게 되었고, 코드 리뷰를 위해 따로 시간을 낼 필요 없이 부담 없이 리뷰할 수 있게 되어 좋다는 긍정적인 의견이 많았다.
 

하나의 PR은 작은 단위로!

큰 프로젝트를 진행할 경우, 하나의 PR 안에 몇백 개의 수정된 파일을 확인해야 한다면, 헉! 하게 된다. 물론 할 수는 있지만, 당장 각자의 업무가 있는데 코드 리뷰에 그 코드를 파악하기 위해서 큰 시간을 들여야 하기 때문에 부담이 될 수 있다. 그래서 그 PR을 한 번에 올리기보다는 작은 단위로 쪼개서 올리는 것이 좋은데, 이렇게 하면 요청자나 리뷰어가 둘 다 부담스럽지 않고 코드 리뷰에 드는 시간이 줄어든다는 장점이 있다.
 

✍🏻 마치며

코드 리뷰는 커뮤니케이션 비용이 많이 드는 일이다. 하지만 서비스 안정성 개선, 코드 품질 향상, 개발 문화 형성 등 코드 리뷰가 필요한 이유는 다양하다. 이렇게 내가 코드 리뷰할 때 중요하게 생각하는 것들과 직접 도입해 본 코드 리뷰 규칙들을 정리해 보았다. 이 포스팅을 통해 코드 리뷰를 할 때 어떻게 피드백하면 좋을지, 또 다른 사람은 어떻게 코드 리뷰를 진행하고 있는지 참고가 되었으면 좋겠다.