코드 리뷰란?
코드 리뷰란 간단히 말해 서로가 작성한 코드를 함께 읽어보고 의견을 나누는 것을 코드 리뷰라고 한다. 말 그대로 서로의 코드를 리뷰하는 것이다. 책이나 영화, 가전제품 등의 리뷰를 쓰듯이 코드를 리뷰하는 거라고 생각하면 된다. 온라인으로 할 수도 있고 오프라인으로 할 수도 있다. 반드시 무엇을 지적하고 더 좋은 코드로 개선해야만 코드 리뷰인 건 아니다. 잘 작성된 부분을 칭찬할 수도 있고, 이해가 안 되는 부분을 질문할 수도 있다. 다른 리뷰어가 이해하기 쉽도록 코드 이해를 돕는 코멘트를 달아줄 수도 있다. 코드를 읽고 우리가 느낀 바를 잘 전달하면 된다.
함께 일하는 팀원들이 상호 간 코드 리뷰를 활발하게 진행하여 긍정적인 효과를 내며, 편하게 의견을 주고 받을 수 있는 분위기가 형성 되어 있다면 코드 리뷰 문화가 잘 정착되어 있다고 볼 수 있다. 코드 리뷰가 자연스러운 조직의 구성원들은 작성한 코드에 대해 피드백을 주고 받는 것이 성장의 밑거름이 된다는 것을 안다. 프로젝트를 성공적으로 이끌어 갈 수 있는 요소 중 하나라는 것을 알고 있으며, 자신의 생각이 틀릴 수 있음을 인정한다. 그렇기 때문에 피드백에 대한 거부감이 적으며 팀원들과 함께 성장할 수 있다.
일반적으로 Git으로 소스 코드의 버전을 관리하며 원격 저장소인 Github에서 코드를 리뷰하고 관리한다. 그러면 시간과 장소에 상관 없이 언제든 팀원의 코드를 리뷰할 수 있다는 장점이 있다.
코드 리뷰 장단점
코드 리뷰 장점
많은 개발자들은 코드 리뷰 문화가 정착되어 있는 일자리를 선호한다. 왜 그런 걸까? 많은 이유 중 하나는 코드 리뷰 문화가 활성화 되면 코드를 작성하는 과정에서 더 신경을 쓰게 되기 때문이다. 변경 사항을 코드 베이스에 merge하기 전에 팀원들에게 승인을 받아야 한다. 혼자만의 코드가 아니라 모두의 코드를 작성하는 것과 같다. 이러한 환경은 실력 향상에 좋은 영향을 끼친다. 또한 리뷰 과정에서 문제가 될만한 부분은 없는지 여러 명의 시각으로 검증하게 되어 문제 발생을 사전에 막을 수도 있다. 서로의 코드를 보고 배우면서 의견을 나누고 좋은 코드를 고민하는 과정에서 팀원들의 개발 역량을 상향 평준화로 이끌 수 있다. 실력 좋은 개발자들이 모여 좋은 개발 문화를 형성하고 있는 곳에 몸을 던져야 하는 이유이다. 즉, 코드 리뷰 문화가 자리 잡으면 프로젝트의 코드 품질도 높이고 개발 역량도 높일 수 있는 환경이 갖추어진다고 볼 수 있다.
코드 리뷰 단점
물론 장점만 있는 것은 아니다. 모든 일에는 일장일단이 있는 법. 필자가 생각하는 최대의 단점은 타인의 코드를 리뷰할 때 개인의 시간과 노력이 들어간다는 점이다. 다른 사람이 작성한 코드를 읽고 이해하는 일은 생각보다 어렵다. 리뷰어는 시간을 들여 이해한 내용을 바탕으로 코멘트를 작성한다. 그리고 PR(Pull Request)을 등록한 사람은 리뷰어의 코멘트에 답글을 달아주며 소통하거나 필요하다면 코드를 수정해야 한다. 이 또한 시간이 소요되는 일이다.
Github에는 리뷰어들에게 일정 수 이상의 승인을 받지 않으면 코드를 merge할 수 없도록 하는 Rule을 설정할 수 있다. 2명 이상에게 승인을 받아야 하는데 코드 리뷰가 활발하지 않은 분위기라면, PR이 승인되어 merge 되기 까지 생각보다 긴 시간이 걸릴 수도 있다. 그래서 코드 리뷰에 들어가는 비용을 고려하지 않고 일정을 산정하게 되면 시간이 부족해서 코드 리뷰가 형식적으로 흘러가게 될 확률이 높다. 너무 바빠서 리뷰를 제대로 할 시간이 없어 승인만 해주는 상황을 예로 들 수 있다. 그렇게 하더라도 어떤 변경사항을 PR 단위로 관리할 수 있기에 의미가 아주 없지는 않다.
또한 팀원 끼리 의견 충돌이 발생하거나 기분을 상하게 하는 코멘트로 인해 싸움으로 번질 가능성도 배제할 수 없다.
어떻게 보면 좋은 결과를 만들기 위해 노력과 시간이 더 들어가는 것은 당연하다. 앞에서 서술한 내용들을 충분히 고려해서 건강한 코드 리뷰 문화를 만들기 위해 노력해보기를 추천한다.
지양할 자세
좋은 문화를 만들어가기 위해 우리가 지양해야할 것들에 대한 생각을 정리해 보았다.
- 프로젝트 일정을 고려하지 않는다.
- 코드 리뷰를 거쳐서 코드가 merge 되려면 시간이 더 걸린다. 일정이 너무 바쁜 상황에서는 코드 품질에 너무 연연하지 않는 게 좋다. 사실 그런 상황을 만들지 않는 것이 가장 좋지만 현실은 그렇지 못한 경우가 허다하다. 반드시 고쳐야 할 부분이 있다면 그 부분만 지적하도록 하자. 그 외의 것들은 나중에 시간이 있을 때 수정하는 게 좋겠다고 얘기하자. 그리고 본인을 포함한 팀원들이 식사 시간이 되면 밥을 먹듯이 시간에 여유가 생기면 코드 품질 향상을 위해 노력해야겠다는 마음가짐을 갖는 것이 필요하다.
- 상대방의 기분을 배려하지 않는다.
- 코멘트를 등록하기 전에 상대방이 어떻게 받아 들일지, 꼭 해야 하는 말인지 생각해볼 필요가 있다. 말투가 너무 딱딱하다면 이모티콘을 활용해볼 수도 있다.😁 별 거 아닌 것 같지만 같은 내용이라도 훨씬 부드러운 느낌의 코멘트로 바뀌는 걸 느낄 수 있다.
- 근거를 말하지 않는다.
- 어떤 의견을 말할 때는 충분한 근거를 들어서 논리적으로 하자. 상대가 충분히 납득할 수 없는 코멘트라면 차라리 달지 않는 편이 낫다.
- 코드에 대해 지적하는 것이 아니라 사람을 지적한다.
- 말이 필요 없다. 코드에 대해서만 이야기하면 된다. 상대방을 깎아내리고 자존심 상하게 하는 말은 하지 말자.
- 리뷰어를 배려하지 않는 PR(Pull Request)을 등록한다.
- 변경한 사항에 대해 가장 잘 아는 사람은 PR을 등록한 사람이다. 작성된 코드의 중요한 부분에 본인이 직접 설명하는 코멘트를 달아주면 리뷰어들이 코드를 이해하는 시간을 줄여줄 수 있다. 어떤 부분을 중점적으로 보라고 알려주기만 해도 도움이 된다. 작성자는 변경 사항에 대한 설명을 달아주는 데 시간이 많이 들지 않는다. 조금의 시간을 들여 리뷰어들을 배려하자.
- 한 번의 PR은 하나의 작은 주제를 가져야 하고 변경된 코드의 양이 리뷰할 만 해야 한다. 봐야 할 코드의 양이 너무 많으면 리뷰어는 엄두가 나지 않을 것이다. 다른 사람이 짠 코드를 이해하는 건 쉬운 일이 아니다.
- 리뷰어들은 내용을 모른 채 처음 코드를 접한다. 본인 이외의 팀원들은 아무 것도 모른다고 가정하고 어떤 부분을 어떻게, 왜 수정했는지 자세히 작성하는 게 좋다.
좋은 문화를 경험하고 싶은 이들에게
다음과 같은 상황에 놓였다고 생각해보자. 우리는 코드 리뷰 문화가 활성화 된 곳에서 일하고 싶다. 그런데 내가 속한 팀은 코드 리뷰를 하지 않는다. 혹은 전혀 그럴 수 있는 환경이 아니다. 이 일을 어떻게 하면 좋을까? 개인적인 생각으로는 솔선수범하는 모습을 보이며 강요가 아닌 설득을 하되 지속적인 노력에도 나아질 기미가 없다면 이미 좋은 문화가 정착된 곳, 더 나은 곳으로 떠나는 걸 고려해 보는 게 좋다고 생각한다. 이미 오래도록 굳어진 분위기와 문화를 바꾸려면 세살 버릇을 고치는 것보다 힘들 지도 모른다. 하지만 문화를 바꾸려 노력하는 그 자체가 힘든 과정인 만큼, 스스로 성장할 수 있는 기회라고 볼 수도 있다. 작은 것 하나라도 시도해보자.
아직 취업을 준비중인 상황이라면 본인의 성향에 따라 어떤 환경에 놓인 회사에서 일하는 게 만족도가 높을지 충분히 생각해봐야 한다. 계속해서 공부하고 피드백 받으며 성장하는 것을 즐기는지, 아니면 그와 정 반대인지 스스로 진단을 내려 볼 필요가 있다. 그리고 처음부터 그러한 성격에 맞는 회사에 들어가기 위해 노력하는 것을 추천한다. 입사해서 경험해보기 전에는 모르는 일이고 팀바팀 부바부 라는 말도 있지만, 겉으로 보기에도 충분히 좋은 선택일 것으로 판단되는 회사가 분명히 있다. 하루 하루의 업무가 고통스럽지 않도록 스스로가 어떤 사람인지부터 깊게 고민해보는 시간을 가져봤으면 좋겠다.