판교에 취직하고 경기도로 올라가기 전 메일로 4월 우아한테크세미나 관련 정보가 왔다. 지속가능한 SW개발을 위한 코드리뷰라는 주제로 백명석 개발자님이 진행해주시는 세미나였다.
이제 막 취업 후 본격적으로 실무를 경험하기 전에 협업은 불가피 하다고 생각했고, 그 과정에서 코드리뷰는 반드시 거쳐가야할 단계라고 생각한다.
그래서일까 마치 날 위해서 준비해주는 세미나처럼 느껴졌고, 메일을 받자마자 곧바로 세미나 신청을 했다.
세미나는 링크 클릭을 통해 풀영상으로 볼 수 있다.
세미나는 실시간 줌으로 진행됐다.
본격적인 세미나 전엔 간단하게 우아한형제들에 관한 개발 교육 프로그램, 기술이야기, Tech 페이지 등을 소개하는 시간을 가졌다. 가끔씩 유튜브에서 올라오는 우테코 발표 영상을 보곤 하는데, 정말 도움을 많이 받고 있다. 영상 퀄리티를 보면 얼마나 뛰어난 교육을 받는지, 잘하는 분들이 많은지 실감하게 할 수 있다.
세미나는 왜 코드리뷰를 해야하는지에 대한 필요성 부터 코드리뷰 절차, 방법 등에 대해 순차적으로 설명해주셨다.
왜 코드리뷰를 해야 하나
코드리뷰를 왜 해야하는지에 대해 핵심만 말하자면, 결국엔 코드 퀄리티와 이에따른 생산성이라고 말할 수 있다.
위의 그래프를 보면 초기에는 no design이 생산성이 좋으나, design payoff line을 지나는 시점 부터는 good design이 생산성이 높아지는걸 볼 수 있다.
이는 클린하고 확장성 있게 잘 짜여진 코드가 초기 작업에는 시간 투자가 많아 생산성이 낮을지 모르지만, 리소스가 쌓이고 서비스가 방대해지면서 결국에는 생산성이 더 좋다는 것을 말해준다.
코드리뷰는 개발과정에서 good design으로 나아가게 하는 수단이라고 볼 수 있다. 혼자 생각하고 짜는 코드는 생각하지 못한 버그를 내포하고 있을 수도 있고, 내 생각에만 갇혀 코드를 작성하기 때문에 유연하지 못하다.
코드리뷰를 통해 내 코드에 대한 타인의 생각을 접하는 과정에서 타인의 새로운 관점과 지식을 얻을 수 있다.
또한 서로 코드를 봐준다는 점에서 상호 책임감이 증대할 수 있고, 나아가 서로 주도적인 개발 문화로 개선될 수 있다.
코드리뷰 절차
일반적인 코드리뷰 절차는 다음과 같다.
코드리뷰는 저자, 리뷰어, 변경 내역으로 구성된다.
저자는 코드를 작성하고 리뷰를 요청하는 사람이고, 리뷰어는 저자의 코드를 읽고 머지 여부를 판단하는 사람이다.
리뷰어는 저자가 작성한 변경 내역을 바탕으로 머지 여부를 판단한다.
코드리뷰는 다른 사람이 작성한 코드를 읽는 만큼 때로는 리뷰어에게 부담이 될 수 있다.
따라서 저자는 리뷰어의 부담이 최소화되도록 변경 내역을 보다 상세하게 작성해주는 것이 좋다.
위의 PR 예시는 11번가의 예시로 저자가 고생해서 상세하게 PR을 남김으로써 리뷰어의 시간을 아껴준 사례이다.
코드리뷰 기법들
- 효율적인 PR 방법
효율적으로 PR을 활용하는 몇 가지 방법을 제시해주었다.
첫 번째로 공백이나 들여쓰기와 오류는 별도의 커밋과 PR로 분류해서 코드 로직의 오류와 별개로 관리하는 것이 좋다.
PR을 올릴 때 주석과 리뷰어를 위한 설명을 코멘트로 남기는 것도 좋은 방법이다. PR에서 수정한 코드 라인을 지정하고 부연 설명과 질문 등을 남겨보자.
스타일과 같은 논쟁은 리뷰에서 시간 낭비이다. 따라서 팀 내에서 스타일 가이드를 정하고 합의를 통해 빠르게 결정하는 것이 좋다.
리뷰의 경우엔 최대한 여러 명을 태그하여 받는 것이 좋다. 한정된 인원이 리뷰하는 것 보다 여러 명이 리뷰해야 효과적인 리뷰가 가능하다. - 효율적인 리뷰 방법
효율적으로 리뷰하는 방법에 대해서도 몇 가지 방법을 제시해주셨다.
리뷰는즉시 시작하는 것이 좋다. 보통 업무에서 코드리뷰는 후순위로 밀리기 쉽다. 리뷰에 대한 노고가 인정되지 않는다는 점이 가장 큰 이유인데, 그렇기 때문에 개인 문제 보다 조직 문제인 경우가 크다. 따라서 회사에서 코드리뷰 문화를 지향 한다면 조직 단에서도 코드 리뷰에 대한 노고를 인정해주고, 개인적으로는 우선 순위를 높게 가져가서 리뷰 하는 것이 좋다. 그래야 저자가 리뷰가 종료될 때까지 한 없이 대기하지 않기 때문이다.
리뷰를 할 때고수준으로 시작해서 저수준으로 내려가는 것이 좋다. 초기에는 버그, 장애, 성능, 보안과 같은 고수준 피드백으로 시작하고, 해당 피드백이 모두 마무리 되면 변수명, 주석과 같은 저수준 피드백으로 넘어간다.
예제 코드를 적극적으로 제공해주면 저자가 작업하기 수월하고, 의사 전달도 보다 명확하게 되기 때문에 적극 활용하자. 이 때 너무 긴 예제는 억압적으로 보일 수 있기 때뭉네 지양한다.
리뷰 중 팀원 간의의미있는 태그를 정하여 활용하는 것도 좋다. 중요하지 않은 부분의 리뷰는 "Nit"과 같은 태그를 두어 해당 리뷰에 대한 중요도 등을 보다 손쉽게 나타낼 수 있다.
저자의 수준에서 살짝 더 높은 등급의 코드 레벨 향상을 기준으로 리뷰하는 것이 좋다. 한 번에 너무 높은 수준의 코드로 전환하는걸 바란다면 저자 입장에서도 부담될 수 있고, 한 번에 크게 바뀌기는 쉽지 않기 때문이다. - 피드백 방법
피드백 방법은 의사소통과 가장 밀접한 부분이다.
피드백을 할 때는 항상 존대해야 한다. 리뷰의 핵심은상대를 비판하는 것이 아닌, 코드가 비판의 대상이 되어야 한다.코드리뷰에서는 대상을 제외하자.
칭찬을 아끼지 않는 것도 중요하다. 대부분 리뷰어는 잘못된 코드에만 집중하여 리뷰를 해준다. 그러나 잘한 코드에 대해서도 칭찬을 해준다면, 리뷰에 대한 긴장감을 낮추고 저자의 기분을 좋게 만들 수 있다.
피드백을 남길 때는 의견이 아닌 원칙에 기반하여 피드백을 하는 것이 좋다. 제안하는 변경사항과 변경의 이유를 모두 설명해줘야 한다. 주관적인 의견이 아닌 객관적인 지식에 기반하여 적어야 한다. - 교착상태 시
코드리뷰 또한 사람 간에 의사소통을 하는 과정이다 보니 리뷰 간에 저자와 리뷰어 사이의 갈등이 발생할 수 있다.
갈등이 발생하면 톤이 팽팽해지고, 공격적, 커멘트가 줄어들지 않고, 리뷰에 저항하는 등 부정적인 리뷰가 반복될 수 있다.
따라서적극적으로 갈등을 해소하는 것이 좋다. 직접 만나서 해당 문제에 대해 이야기하고, 다른 리뷰어들과 협조하여 갈등을 해소할 수도 있다. 무엇보다도 가장 중요한건 스스로 인정하는 자세이다.
코드리뷰의 어려움과 극복 방법
강사님은 코드리뷰라는 것인 근본적으로 쉽지 않다고 말한다. 근본적으로 코드리뷰란 저자는 PR을 자신이 가장 잘 짰다고 생각한 코드로 보내는데, 리뷰어는 무엇이 문제인지 PR에서 찾는 과정이기 때문에 문제가 발생하기 쉽다는 것이다.
또한 리뷰 과정에서 코드에 대한 비판을 자칫 저자 자신에 대한 비판으로 받아들일 수 있는 오해의 소지가 많기도 하다.
아무래도 생각을 글로 전달하는 과정이다보니 오해의 위험성이 높다.
강사님은 코드리뷰 문화 정착의 어려움 속에서 몇 가지 극복 방법을 제시해주셨다.
먼저 구성원들이 코드리뷰에 대한 적극적인 열정이 있어야하고, 리더는 이를 뒷받침 해줄 코드리뷰 문화를 조성해주어야 한다.
구성원 모두가 코드리뷰를 하고싶게 리뷰라는 과정이 멋있다고 느껴질만한 코드리뷰 문화를 조성해주는 것이 좋다.
가장 근본적으로는 저자들의 노력이 뒷받침 되야한다. 모두가 노력한다면 리뷰어들의 시간을 절약할 수 있고, 효과적인 리뷰가 가능하기 때문에 코드리뷰의 부담을 줄이고, 안정적으로 리뷰 문화를 만들어 갈 수 있다.
위에 보이는 그래프와 같이 새로운 것을 도입한다고 해서 곧바로 이득이 생기는 것 보다는 초기에는 일정 부분 손해가 발생하는 것이 일반적이다.
코드리뷰 또한 처음엔 적응 기간과 여러 시행착오를 겪기 때문에 더 비효율적으로 일이 진행될 가능성이 높다.
하지만 이를 극복했을 때 비로소 이득이 나타나기 시작한다.
개인적으로 코드리뷰를 반드시 해야할 필요는 없다고 본다. 작은 규모에서 단기적으로 사용할 프로젝트라면 오히려 코드리뷰 절차가 생산성을 떨어뜨리는 요소가 될 수 있다. 하지만 일정 수준 이상의 프로젝트 규모를 운영하는 팀이라면 코드리뷰는 좋은 선택지가 될 수 있다고 본다.
