코드 리뷰에 대하여
개발자가 되고자 하는 마음을 가지고 마구 서칭을 하고 다녔을 때 충격받았던 점은 '코드 리뷰' 문화였다. 코드리뷰가 뭐지? '코드 리뷰' 라는 단어가 주는 어떤 위압감은 마치 내가 짠 코드를 (아직 제대로 짜보지도 않았는데) 만천하에 공개처형 당하는 느낌일까 생각했다. 어디에서는 영업 비밀이 누출되지 않기 위해 보안에 보안에 보안을 더해서 힘 쓰는데 코드 리뷰가 대체 뭐길래 내로라 하는 IT 기업들에서도 본인들의 전부를 오픈해주고 기꺼이 그 코드에 '참견' 해달라고 할까?
11번가 백명석 자문위원님의 코드리뷰 노하우 영상을 보고 많은 걸 깨닫고 배웠다. 그 까짓 거 그냥 모든 기업의 개발팀에서 다 하는 거 아니야? 나도 추후에 입사를 하게 되면 '당연히' 코드 리뷰를 하겠지? 했던 나의 생각을 완전히 무너뜨리셨다. 해당 세미나에서는 이미 개발자로서 현업을 하고 계신 분들까지 소속된 기업에서의 코드리뷰 문화가 마땅치 않거나, 혹은 코드리뷰 문화 자체가 없다시피해 힘들다고 하신다.
내가 상상했던 코드리뷰는 빔 프로젝터 같은 큰 화면에 다같이 볼 수 있도록 코드를 띄워두고 "자, 우리 다함께 이 코드에 대해 이야기 해봅시다." 하는 모습이었다. 모두가 회의실에 둘러 앉아서 이 부분은 어떻고, 저 부분은 어떻고에 대해 서로 묻고 답하며 토론하는 모습이랄까. 하지만 백명석 위원님이 말씀하신 코드리뷰는 나의 이러한 상상을 또 한 번 무너뜨리셨는데, 코드 리뷰는 Git이나 Bigbucket과 같은 버전 관리 시스템의 Pull Request를 통해 진행된다고 하셨기 때문이다. 무려 '댓글 놀이처럼' 이라는 말씀도 얹으시면서.
그렇다면 과연 '좋은 코드리뷰' 란 무엇일까?
효율적인 코드 리뷰 방법
백명석 위원님께서는 말씀하신 코드리뷰는 다음과 같다.
코드 리뷰란?
지식과 경험을 공유하고 상호학습을 통한 역량 증대의 수단이며,
참여자 모두에게 배움의 기회를 제공하고 상호 책임감이 증대되어 좋은 팀 워크가 발생한다.
물론 함께 말씀해주신 좋은 내용이 너무나도 많지만 간결하게 요약했다. 코드 리뷰 자체가 해당 코드를 작성한 저자에 대한 비판이 아니라는 것은 알았으나, 단순히 제품의 품질 검수를 위한 리뷰가 아니라 궁극적으로 팀의 개발 문화를 개선하고 더 나아가 결국에는 개발 문화 전체를 개선하는데 영향력이 있다는 것이 놀라웠다. 코드 리뷰 문화는 개발 직군에서 흔히 볼 수 있는 문화지만 없는 기업도 많으며, 코드 리뷰를 한다고 해서 전부 좋은 기업이 아닐 수도 있다는 것. '좋은 코드 리뷰', 코드 리뷰의 질이 중요하다는 걸 깨달았다.
리뷰이의 자세 (저자)
- 공백이나 오타 등의 불필요한 코멘트가 없도록 따로 관리하자.
- PR의 스타일을 가지고 논쟁하지 말자. 팀 혹은 기업 별로 코드리뷰 스타일 가이드가 있으면 좋다.
- 본인의 PR을 먼저 읽어보고 리뷰어들을 위한 코멘트를 작성하자.
- 가급적 많은 사람이 보게 하자. 많이 볼수록 오류를 찾을 가능성이 높아지고, 잘 하고 싶은 마음도 커진다.
- 언제봐도 잘 이해할 수 있도록 commit message를 잘 남기자.
리뷰어의 자세
- 코드 리뷰를 우선 순위 안에 두자. 리뷰이가 오래 기다리지 않도록 되도록 하루 안에 해결하자.
- 하루에 일정 시간 코드 리뷰를 위한 시간을 확보하자.
- Pull Request vs Pair Programming 절대 답은 없으므로 때마다 적절히 선택하자.
- 고수준에서 저수준으로 리뷰하자. 초기에는 버그/장애/성능 보완을 위주로, 나중에 가서 설계 개선
- 간단한 예제 코드를 제공해도 좋다. 하지만 길지 않게, 너무 많이 주는 것은 삼가하자.
- 리뷰의 범위를 존중하자. PR에 포함되지 않는 범위는 건드리지 말자.
- Nit 을 자유롭게 남길 수 있어야 한다. 고치면 좋고 아니면 말고! 리뷰이가 선택할 수 있도록 하자.
- 한 번에 여러 단계를 성장할 수 없다. 리뷰이의 현재 단계에서 1~2단계씩 성장할 수 있도록 도와주자.
피드백 방법
- 리뷰의 핵심은 성장, 더 나아지는 것이다. 비판의 대상은 리뷰이(저자)가 아닌 코드."
명령이 아닌 요청! I message 전달법으로 대화하자."~하는 것을 제안합니다.""~하는 게 어떨까요? - 동료간의 피드백은 비판과 경쟁이 아닌 팀의 생산성을 높이는 것이다.
건설적인 피드백이 아니라면 때로는 함구하는 것이 더 나은 결과를 가져올 수 있다. - 진심으로 칭찬하자. 칭찬에 인색하지 말자.
- 개선이 필요한 이유를 정확한 근거와 함께 객관적으로 설명하자.
충분한 이유가 뒷받침되지 않거나 주관적/추상적인 리뷰는 리뷰이(저자)에게 혼란을 줄 수 있다. - 같은 코드 내 동일한 패턴이 보인다면, 모두를 지적하지 말자.
10개 중 3개만 전달하고 나머지는 리뷰이(저자)에게 맡기자. - 죽자고 싸우지 말자. 크리티컬한게 아니라면 유연하게 넘어갈 수 있는 자세를 가지자.
- 설계 단계에서 필요한 리뷰를 가져와 코드 리뷰에 적용하지 말자.
- 말로 설명하기 어려울 땐 Pair Programming OK!
이후 Revert 하여 리뷰이(저자)가 다시 시도해볼 수 있도록 하자. - 모든 결정은 '리뷰이(저자)'가 하는 것. 팀 정신을 위해 약간은 불완전 하더라도 넘어갈 수 있도록 하자.
마치며
이 글은 백명석 위원님의 세미나를 위주로 배운 것과 느낀점을 늘어놓은 글이지만, 사실은 영상 시청 이후 각 IT 기업의 기술 블로그에서 코드 리뷰와 관련한 포스트도 많이 찾아봤다. 모든 기업의 코드 리뷰 문화를 전부 안다고 할 수는 없지만 적어도 내가 찾아본 기업들에서는 위원님이 말씀하신 내용에서 크게 벗어난 점은 없었다. 그리고 대부분의 기업이 '작은 단위 PR' 과 '칭찬' 의 중요성을 강조했다.
"If it hurts, do it more often!" (어려워? 더 자주 해!)
세미나 중 특히 마음에 와닿았던 문장이다. 코드 리뷰라는 건 결국 시작 자체가 어마무시하고 대단한 게 아니라 작은 단위로 일단 시작해보되, 지속하고 발전시킨다면 그 끝에는 큰 성장이 이루어지는 것. 그리고 그 성장은 개인의 성장이기도 하지만, 내가 소속된 팀과 기업의 성장이기도 하며, 더 나아가 개발 문화 전체에 영향을 끼치게 된다. 나에게 익숙하지 않고, 어려워서 피하게 된다면 아무것도 이뤄지는 건 없다. 어려우면 어려울수록, 더 자주 시도하고 부딪혀보자.
참고자료
[OKKY 1월 세미나] 한번 듣고 평생 써먹는 코드 리뷰 노하우
[4월 우아한테크세미나] 지속가능한 SW개발을 위한 코드리뷰
[KAKAO] 효과적인 로트리뷰를 위한 리뷰어의 자세
[LINE] 효과적인 코드 리뷰를 위해서
[뱅크샐러드] 코드 리뷰 in 뱅크샐러드 개발 문화
