서문
안녕하세요. 인재 채용 플랫폼 잡다 서비스의 웹 프론트엔드를 맡고 있는 배준형입니다.
저는 개발자의 성장에 있어 코드 리뷰가 매우 중요하다고 믿습니다. 코드 리뷰를 통해 다른 개발자의 관점을 접하고, 본인이 놓친 부분들을 발견할 수 있습니다. 또한 리뷰어 역할을 함으로써 코드 작성 시 더 철저한 고민을 하게 되는 효과도 있죠.
하지만 제가 잡다 팀에 합류했을 때, 코드 리뷰 문화는 거의 없었습니다. 이에 저는 팀 내 코드 리뷰 문화 정착을 위해 노력하였고, 그 과정을 공유하고자 합니다.
기존 코드 리뷰 과정의 문제점
잡다 팀은 코드 저장소로 빗 버켓(BitBucket)을 이용합니다. 작업 내용을 Jira 티켓(이슈) 기준으로 Pull Request(PR)을 생성하는데, 제가 합류하기 전 코드 리뷰 현황은 다음과 같았습니다.
- 대다수 PR이 동료의 리뷰 없이 Merge되고 있었습니다.
- PR에 대한 코멘트도 거의 남겨지지 않았습니다.
- PR의 제목이나 본문에 작업 내용 설명이 부족하거나 없는 경우가 많았습니다.
Approve, Comment 없이 머지된 PR 들
아무 내용도 적혀있지 않은 PR 내용
PR 내용을 하나하나 확인해 보면 내용이 하나도 작성되어 있지 않는 것도 꽤 많이 있음을 확인할 수 있었습니다.
이는 리뷰어가 PR의 변경 사항을 확인하거나 리뷰 포인트를 파악하기 어렵다는 문제점이 있습니다. 또한 Approve도 실제 검토 후 승인한 건지, 단순 확인만 한 건지 알기 어려웠습니다. 결국 코드 리뷰 프로세스와 규칙이 없다보니, 리뷰의 질이 낮고 유의미한 피드백이 부족하다는 것을 알 수 있었습니다.
이를 개선하기 위해서는 무엇보다 코드 리뷰에 대한 팀원의 인식을 변화시키는 것이 필요하다고 판단했습니다.
내가 먼저 적극적으로 참여하기
문제를 인식했으나, 바로 팀 차원의 코드 리뷰 문화를 만드는 것은 어려워 보였습니다. 그래서 제가 먼저 변화를 위해 적극적으로 리뷰에 참여하기로 했습니다. 그 과정에서 무언가 좋았던 점이 있다면 그걸 바탕으로 설득할 수 있을 것이고, 자연스럽게 리뷰하는 문화가 만들어질 수도 있을 것이기 때문이죠.
구체적으로 PR 작성하기
적극적으로 리뷰 남기기
저는 PR을 생성할 때 변경 사항 등을 상세히 작성하려고 했고, 동료의 PR에 대해 세부적인 리뷰 코멘트를 남기려고 노력했습니다. 제 기준에선 더 이상 수정할 사항이 없다면 LGTM 코멘트를 남기기도 했습니다.
이후 시간이 흘렀을 때 어떤 변화가 있었을까요??
팀에 실제로 유의미한 영향을 주었는지는 모르겠지만, 적어도 1~2개의 리뷰가 달리기 시작합니다. 많은 건 10개까지도 달렸네요.
PR 템플릿 사용하기
일정 시간 코드 리뷰에 참여하며 경험이 쌓이기 시작하였습니다. 이에 따라 빗 버켓에 PR을 생성할 때 템플릿을 적용하였습니다.
기존에는 PR 내부에 설명이 부족하여 어떤 부분을 확인해야 될지, 직접 테스트할 때 어떻게 확인하면 좋을지 등을 알 수 없었습니다. 그래서 일관된 방식으로 PR을 작성하고자 PR 템플릿을 적용했습니다.
적용된 모습
템플릿을 적용하게 되면서 PR을 생성하는 사람은 어떤 부분을 작성해야 할지, 리뷰어는 본문 내용을 참고하면서 어떤 부분을 중점적으로 코드 리뷰를 할지에 대한 고민하는 시간이 줄어들었습니다.
Teams 알림을 활용하기
회사에선 전사적으로 Teams를 메신저로 활용하고 있습니다. Teams에서는 Workflows 등을 활용하여 다양한 방식의 알림을 커스텀 하여 활용할 수 있는데요. 저희는 PR을 생성했을 때 알림이 전송하도록 Workflows를 구성했습니다.
그러면 위와 같이 PR이 새로 생성되었을 때 실시간으로 Teams로 알림을 받을 수 있습니다. Teams만 활용해서 그런지 PR 내용을 직접 확인할 수가 없고, 코멘트 작성에 대해선 알림을 받을 수 없지만 그래도 실시간으로 PR이 생성되었을 때 알림을 받아볼 수 있게 되었습니다.
코드 리뷰 가이드 문서 추가하기
저희 팀은 Jira와 Confluence를 사용합니다. 개인 또는 팀에게 공유할 만한 사항들을 사내 Confluence에 작업하여 공유하시는 분들도 계시는데요. 제가 속한 잡다 팀에서 코드 리뷰에 대한 규칙 문서를 만들어서 팀에게 공유하였습니다.
코드 리뷰 가이드 컨플루언스 자료.
예를 들어, Approve 상태는 모든 리뷰가 반영되었을 때 리뷰어가 눌러서 리뷰가 끝났음을 표시하고, Request change 상태는 리뷰어가 리뷰를 남겨서 머지 하기 전에 리뷰 내용을 확인해 달라 함을 의미합니다.
위 내용이 적용된 후에 PR 상태는 어떻게 바뀌었을까요??
9개의 코멘트가 달렸는데, 초록색 아바타인 저는 리뷰를 남기고 리뷰를 확인해달라는 표시인 Request change 상태이고, 고양이 아바타인 팀원 분은 리뷰를 마치고 모두 반영된 상태 임을 나타내기 위해 Approve 상태로 변경한 것을 확인할 수 있습니다.
이 경우 PR의 상세 정보를 확인하지 않더라도 목록만 봐서도 리뷰가 추가되었는지, 확인할 사항이 있는지를 알 수 있게 되었습니다.
정리
앞선 노력들로 PR 생성 및 리뷰가 적절히 잘 이루어지고 있습니다. 정리하자면,
- PR 템플릿 적용
- PR 생성에 대한 Teams Workflows 알림 추가
- PR 생성 / 리뷰 가이드 문서 작성
등이 이루어 졌습니다.
아쉬운 부분들도 존재합니다. PR을 올렸을 때 언제까지 리뷰를 받아서 머지 해야 한다 하는 Badge를 사용한다던가, Teams Workflows 내부에서 PR 내용을 확인한다거나 Comment가 작성되었을 때 그 내용 확인이나 알림을 활용할 수 없는 점이 아쉽습니다.
이전 회사에서 Gitlab을 활용하여 적절히 Badge를 사용하고, 모든 MR(Merge Request) 생성 및 액션, Comment 작성 등에 대한 알림을 Slack으로 보내서 더 활발히 코드 리뷰가 이루어졌었는데, Gitlab ↔ Bitbucket / Slack ↔ Teams 도구의 차이겠지만 이런 부분들이 아쉽게 느껴지긴 합니다.
저는 코드 리뷰를 좋아합니다. 무언가 게임처럼 느껴지기도 하고, 도움을 주고 싶은 마음, 도움을 받고 싶은 마음이 동시에 느껴지기도 합니다. 그 과정에서 꾸준한 성장이 이루어지기도 하고요. 그런 의미에서 팀에서 점점 활발해지는 코드 리뷰 현황을 보고 있으면 기분이 좋아지기도 합니다. 아직 개선될 수 있는 부분들이 있을 것이라 생각하고 있어서 더 좋은 문화가 정착될 수 있도록 노력하려고 합니다.
