카테고리 없음

코드 리뷰 문화 도입하기

cocojen 2025. 3. 7. 19:25

코드리뷰가 좋다는 것은 누구나 알고 있지만, 유지하기가 참 어려운 것 같다.

많은 회사가 그렇듯이 우리 팀도  코드 리뷰가 원활하지 않았다.

처음엔 merge 를 눈치보지 않고 팍팍할 수 있어서 좋았지만 점차 시간이 지나며 몇몇 문제들이 누적되었다. 

 

내가 느낀 코드리뷰를 하지 않을 때의 문제점은 크게 세 가지이다.

 첫 번째로, 팀원들이 무슨 일을 하는지 파악하기 어렵다. 

팀원들이 하는 일이 남의 일 같이 느껴지고, 무관심해진다. 같은 맥락에서 팀원이 짠 코드에 문제가 발생하면 원작자의 부재시 빠른 대응이 어렵다. (코드도 코드지만 비즈니스 로직 이해가 참 어렵다..) 말 그대로 이거 왜 이렇게 한거지?? 가 나오게 된다.

 두 번째로, 문제 해결 비용이 크게 든다.

크로스체크를 통해 쉽게 예방할 수 있는 문제를 prod 레벨에서 잡아야하는 일이 생긴다. 문제 해결 비용이 어마어마하게 늘어나는 것이다.

세 번째로, 팀워크를 강화할 수 있는 소중한 기회를 놓치게된다.

 코드리뷰를 하면서 team-awareness 를 매순간 늘릴 수 있다. 이 좋은 기회를 매일 놓치는 것이다. 조금 오버하는 것일 수 있지만, 팀워크는 곧 모든 것과 연관되는 것 아닌가? 낮은 팀워크, 낮은 직무 만족도, 퇴사,,,, 모두 관련있다고 생각한다.

 

물론 이런 문제가 있다는것은 누구나 알지만 ㅎㅎ 편함과 잠수함 패치ㅠ에 익숙해져서 불편함 없이 살아가고 있었다.

그러던 와중 prod에서 너무 큰 버그가 발생했는데, 주석을 제거 하지 않은 정말 어처구니없는 실수였다. 

정말 한 명만 그 pr을 봤어도 예방할 수 있는 문제였다. 

그 날 이후로 정말 확실한 코드리뷰 도입의 필요성을 느꼈고, 우리팀에 제안해야겠다고 결심했다.

 

아래의 글은 내가 백엔드 회의 때 공유한 내용이다.

거창한 내용은 없지만 이 내용을 공유하며 우리 팀에 맞는 방식을 논의했고, 지금은 어느정도 우리 팀만의 코드리뷰 문화가 자리잡게되었다.

 

이전보다 확실히 버그가 줄었고, 특히 서비스에 새로 들어가는 feature가 무엇인지 저절로 파악된다는 게 매우 좋았다.

비즈니스 이해도가 높아지고, 전반적으로 팀워크도 좋아진다고 느낀다.

 

 

목차

  1. 들어가며
  2. 코드 리뷰의 이점
  3. 우리 팀의 코드 리뷰 현황
  4. 코드 리뷰하기 어려운 이유
  5. 코드 리뷰 활성화 방안
  6. 도입해볼 만한 추가 방법들
  7. 마무리하며
  8. 참고 문헌

들어가며

이 문서를 통해 코드 리뷰의 중요성과 이를 통해 얻을 수 있는 다양한 이점에 대해 설명하려고 한다. 또한, 우리 팀의 코드 리뷰 현황을 분석하고, 코드 리뷰가 활발히 이루어지지 않는 이유를 파악한다. 이를 바탕으로 코드 리뷰를 활성화하기 위한 구체적인 방안들을 제안하며, 도입해볼 만한 추가 방법들도 소개한다. 마지막으로, 문서를 작성하며 느낀 점과 앞으로의 다짐을 공유한다.

코드 리뷰의 이점

  1. 로직을 올바르게 작성했는지 더블 체크가 가능하다
    1. 개발 단계에서 버그를 캐치하면 가장 저렴한 비용으로 Prod issue 를 감소시킬 수 있음
    2. 놓쳤던 부분을 캐치할 수 있다.
  2. 비즈니스 로직에 대한 이해도가 높아진다.
    1. 다른 개발자의 코드를 리뷰하면서 새로운 피쳐에 대한 이해, 다른 파트에 대한 이해도를 높일 수 있다.
  3. 의견을 나누며 개발 지식을 늘릴 수 있다.
  4. 일관된 코드 스타일을 유지할 수 있다
    1. 리뷰를 통해 일관된 코드 스타일을 장려할 수 있으며코드 퀄리티와 가독성을 높인다.

코드리뷰가 다양한 이점을 가지고 있다는 것은 굳이 설명하지 않아도 많은 개발자들이 잘 알고 있는 사실이다. 그렇다면 우리 팀의 코드 리뷰는 얼마나 활성화되어 있을까?

우리 팀 레포의 코드 리뷰 현황

  • 8월 7일부터 이전 3주 동안
  • PR #7567번 부터 #7464번까지
  • 배포 pr, 핫픽스 pr 을 제외하고
  • 총 78개의 PR을 대상으로
  • 평균 approve 수와 평균 comment 수를 구해보았다.
PR 수 평균 Approval 수 평균 Comments 수 (codecov 와 sonacloud 가 포함된 갯수)
78 1.65 2.32

표를 보면 알 수 있듯이, PR 한 개당 평균 1.6명이 확인하고, codecov와 sonacloud를 제외하면 평균 0.5개 정도의 코멘트가 달리고 있다. 굉장히 낮은 숫자이다.

물론 평균 코멘트 수와 approval 수가 코드 리뷰의 퀄리티를 대변하지는 않기 때문에 이 숫자를 보고. 우리 팀의 코드 리뷰 문화가 좋지 않다고 단언할 수는 없지만, 활성도 측면에서 보았을때는 변명의 여지 없이 좋은 편은 아니라고 할 수 있다. 앞서 말햇듯, 코드리뷰는 다양한 이점을 가지고 있는데, 왜 이렇게 하기 어려운 것일까? 다음은 마이크로 소프트 개발자 911명을 대상으로 한 코드리뷰 관련 리서치이다.

코드리뷰하기 어려운 이유

  1. 리뷰할 양이 많으면 읽기 어렵다.
  2. 리뷰할 시간이 없다.
  3. 바꾼 이유와 바뀐 점을 이해하는 것이 어렵다.
  4. 관련 문서를 찾는 것이 어렵다.
  5. 리뷰를 하기에 충분한 역량, 경험이 없다.
  6. 리뷰잉 자체가 (들이는 시간과 노력에 비해) 가치 높게 평가 되지 않는다
  7. 내 업무평가에 어떻게 반영될지 확실하지 않아서

마이크로소프트 개발자들도 싫대요

마이크로소프트의 리서치에 따르면, 1주일에 얼마나 자주 코드리뷰를 하냐는 질문에, 최소 하루에 한 번 한다는 응답이 39%, 한 주에 한 번 한다는 응답이 12%, 안 한다는 응답이 13% 였다.

코드 리뷰 참여도 조사(마이크로 소프트 개발자 4300명에게 물었고 911명에게 응답받은 결과)

 

 
 

그렇다면 어떻게 코드리뷰를 유도할 수 있을까?

  • 개인적으로 강제성을 두는 것은 좋지 않다고 생각한다.
  • 우리 팀원들은 강제성이 없어도 코드리뷰를 잘 해줄 수 있는 훌륭한 사람들이라고 생각하기 때문에 조금의 룰 도입과 관성만 생긴다면 활발한 코드리뷰가 가능할 것이라고 생각한다.
  • 리뷰어의 부담을 줄일 수 있는 방안을 생각하는 것이 최선이다.
  • 코드리뷰를 하기 어려운 이유와 이를 개선할 수 있는 방법들을 생각해보자.
 

코드리뷰가 어려운 이유 도입해봐요 설명
시간이 소요된다. 내 것 하기도 바쁘다 업무시간에 코드 리뷰 시간을 할당하기
  • 오전 00분/ 오후 00분
  • 월, 목 씽크 전 30분씩 등등 ..
배경과 맥락을 파악하기가 힘들고 귀찮다 PR에 변경 이유와 변경 내용을 상세하게 작성하기 현재 PR 템플릿에 Background 에 지라 링크를 넣고 백그라운드는 잘 적지 않는 경우가 많다. 지라 태스크에 내용이 잘 적혀있는 경우에는 이렇게 해도 상관 없지만, 지라 태스크의 내용도 비어있는 경우가 종종 있다. 템플릿에 지라 티켓 칸을 추가하고 백그라운드가 아닌 이곳에 지라 티켓을 첨부하자. 그리고 Background가 지라티켓에 충분히 잘 적혀있다면 티켓과 동일에 체크박스에 체크하고, 설명이 더 필요하다면 Background 에 설명을 적자.


 


 
코멘트 남기는 것이 지적처럼 느껴질까봐 말투에 신경쓰는 것이 부담스럽다 코멘트 앞에 종류별로 이모티콘 혹은 어떤 코멘트인지 간략하게 알려주는 Abbreviation 달기 NIT : nitpick (사소한 잘못을 지적하다)의 줄임말로 변경이 필수적이지 않지만 의견이나 사실을 전하고 싶을 때 사용
JS : Just Saying 의 줄임말로, 특별한 의도없이 그냥 말하는 것을 강조하고 싶을 때 사용
FYI : For Your Information 의 줄임말로, 상대에게 도움이 될 것 같은 정보를 전달할 때 사용
등등 을 사용하여 의도를 명확히 할 수 있음.
PR이 쌓여있을 때 무엇을 먼저해야할지 모르겠다 선택과 집중을 하자
  • 리뷰를 스킵해도 되는 PR들을 분류하자.
    • 코드의 로직을 바꾸지 않는 변경 사항
    • 리포맷팅
    • 오타 수정
    • 변수이름 변경 등..
  • review-not-neccesary 태그를 사용하여 리뷰가 필요 없음을 알리자.



 

이 외에도 도입해볼만한 방법들

  1. 랜덤 리뷰어를 배정하기
  2. 슬랙으로 열려있는 PR 알림오게 하기
     

마무리하며

문서를 작성하며 나는 왜 리뷰를 적게 남겼을까에 대해 생각해보았다. 단순히 생각해보면 일대일 상대매매 전환 일정에 맞추기 위해서 다른 사람의 PR에 코멘트하기는 절대적인 시간이 부족했을 수 있다. 하지만 나는 중간중간 여유가 있었을 때에도 다른 사람의 PR에 문제가 없어보이면 approve는 눌러도 코멘트는 잘 남기지 않았다.

생각해보면 나는 항상 버그를 찾거나, 기술적으로 더 나은 제안을 할 수 있을 때에만 리뷰를 남기려고 했던 것 같다. 또, 심리적으로는 나보다 경험이 많고 기술적으로 숙련된 팀원들의 PR에 리뷰를 남기는 것에 조금 위축되고 주저했던 것 같기도 하다.

하지만 이번에 코드리뷰 관련 리서치를 하다보니 꼭 그럴 필요는 없다는 것을 깨달았다. 왜냐면 코드 리뷰의 목적과 의의가 ‘결함 찾기’, ‘품질 개선하기’ 에만 국한되는 것은 아니기 때문이다.

코드 리뷰는 온라인에서 지속적으로 일어나는 커뮤니케이션이다. 이는 팀워크를 강화하고, team-awareness를 높이며, 코드 오너십을 공유할 수 있게 만든다. 그리고 이렇게 강화된 팀워크는 또 다시 코드 리뷰에 대한 장벽을 낮추고 활성화하는 촉진제가 된다.

문제 없는 PR에 approve 만 누르는 것 보다는, LGTM 과 함께 누르는 것, LGTM 만 쓰는 것 보다는 과 함께 쓰는 것이 더 좋은 리뷰이고, 커뮤니케이션인 이유다.

좋은 코드 리뷰는 팀원들의 심리적 안정감을 높일 수 있고, 팀의 문화도 좋은 방향으로 이끌 수 있다는 사실을 인지하고, 앞으로는 의식적으로 코드 리뷰에 참여해보면 좋을 것 같다.

 

 

[참고 문헌]

저작자표시 비영리 변경금지