12월 25일, 크리스마스의 아침이 밝자마자 시작한 데브코스 1차 팀 프로젝트가 약 4주 간의 여정 끝에 막을 내렸습니다. 그 과정에서 내가 작성한 코드 리뷰를 위주로 되돌아보며 느낀점을 정리해보았습니다.
코드 리뷰
코드 리뷰는 내가 열심히 작성한 코드에 대한 피드백을 받고 개선할 수 있는 환경을 마련하는 것, 혹은 미처 생각하지 못한 부분에 대해 고민하게 하여 시야를 확장할 수 있는 것입니다. 그래서 개인적으로 협업을 진행하면서 가장 기대하는 것 중 하나이기도 합니다.
우리 팀에서도 프로젝트를 진행하며 코드 퀄리티를 개선하기 위해 코드 리뷰 문화를 도입하기로 결정했습니다.
내가 작성한 코드 리뷰
위 이미지는 버튼 컴포넌트에 대해 제가 작성한 리뷰 일부를 발췌해온 것이고, 버튼의 기본 너비를 block과 inline 중 어느 것으로 할 지에 대한 내용입니다.
모바일 환경에서는 버튼의 크기가 작으면 잘못된 영역을 터치할 확률이 커지고, 이는 사용자 경험과 연관이 있다고 판단해 전체 너비를 기본 사이즈로 설계할 것을 제안했습니다. 반대로 팀원 분께서는 우리 팀의 와이어프레임 상 전체 너비를 사용하는 경우가 없기 때문에 이를 기준으로 컴포넌트를 설계했다고 하네요. 두 의견 모두 적절한 근거를 토대로 제시되었지만, 저는 제 의견이 조금 더 맞다고 판단했고, 결국 다시 한 번 제안을 한 모습입니다.
제안을 하고 난 뒤 문득 이런 생각을 했습니다.
충분한 근거를 바탕으로 건넨 제안이지만, 내 생각과 다르다는 이유로 불필요하게 시간을 낭비하는 것은 아닌가?
그도 그럴 것이 성능에 크게 영향을 미치는 것이 아니라서 수정이 시급한 것은 아니었거든요. 또 이제까지 작성해온 코드 리뷰가 오히려 팀원들을 괴롭히거나, 업무 효율을 저하한 것일 수 있겠다는 생각에 갑자기 혼란스러워졌습니다.
주관이 담긴 코드 리뷰
위에서 두 개발자가 작성한 리뷰에는 각자의 주관이 담겨 있습니다. 이 주관이 코드 성능과 관련한 것이었다면 조금 더 명확한 결론을 내릴 수 있었겠지만, 지금의 경우는 개인의 성향에 조금 더 관련이 있는 것 같습니다. 동시에 각자의 주장에는 나름의 근거도 있기 때문에 "지양해야 할 코드 리뷰인가?"라는 물음에는 확실하게 답을 내릴 수 없겠다고 판단했습니다. 이런 이유로 의견을 조율하는 것이 조금 더 어려웠던 것 같기도 하네요.
그렇다면 이런 경우에는 어떤 태도로 코드 리뷰에 임하는 것이 좋을까요? 확신이 서지 않았습니다. 서로의 주관이 계속해서 부딪힌다면 앞서 떠올린 고민처럼 업무 효율이 떨어질 수 있지만, 동시에 더 나은 서비스를 위한 고민이기도 했거든요.
결국 저는 멘토님의 도움을 빌리기로 결정합니다. 제가 작성한 리뷰에 대한 피드백을 요청드렸고, 앞으로 원활하게 협업하기 위해 개선점을 찾고자 했습니다. 아래는 멘토님께서 남겨 주신 답변을 정리한 것입니다.
- 코드를 작성할 때 주관이나 개인의 취향 들어가는 것은 그 자체로 문제가 되지는 않는다.
- 다만 주관을 강요하고 가르치려 한다면 그것은 분명한 문제가 될 것이다.
- 리뷰를 할 때는 '상대방과의 협업'에 대한 존중이 필연적으로 뒤따라야 한다.
- '취향인가?' 싶은 내용에 대해 리뷰를 할 때는 개인적인 취향임을 함께 명시하는 것이 오해의 여지를 차단할 수 있다.
개선점
멘토님의 피드백을 바탕으로 현재 상황에서의 개선점, 나아가 앞으로 코드 리뷰를 진행하며 가져야 할 태도에 대해 고민해보았습니다.
꼼꼼한 코딩 컨벤션
가장 중요한 것은 팀 내 코딩 컨벤션을 더 꼼꼼하게 정하는 것이라고 생각했어요. 코드는 인간이 작성하는 것이기 때문에 개인의 주관이나 취향이 반영되는 것은 어찌 보면 당연하다고 생각이 되는데, 만약 그 취향이 중구난방으로 코드에 반영된다면 일관된 코드를 작성하기 어렵겠죠. 그렇다면 후에 코드를 읽는 사람에게 혼란을 줄 수 있고, 유지/보수 하는 데에 어려움이 생길 수도 있습니다.
그래서 이를 사전에 꼼꼼하게 논의하는 과정이 필요할 것 같습니다. 그렇다면 불필요하게 주관을 근거로 코드리뷰 하는 과정이 현저히 줄어들 것이라 생각해요. 만약 ESLint와 같은 포맷터를 사용하여 자동화 한다면 코드를 작성하는 입장에서도 크게 신경쓰지 않고 작업을 할 수 있으니 훨씬 효율적일 것입니다.
의도를 명확하게 전달하기
다만, 컴포넌트 설계와 같은 복잡한 부분에서는 조금 더 깊은 논의가 필요할 것 같습니다. 컴포넌트의 종류나 추상화 수준 등 고려해야 할 부분이 더 많기 때문이죠. 그래서 이런 경우에는 취향이 담긴 리뷰임을 확실히 알려주는 것이 도움이 될 것이라 생각했습니다.
이렇게 했을 때 불필요한 곳에서 시간을 소요하지 않게 되어 작업 속도가 소폭 개선되었음을 체감했습니다.(제 마음의 빚을 덜기도 했구요.)
이를 좀 더 개선하자면, 뱅크샐러드에서 사용하는 Pn Rule을 도입해 볼 수도 있겠습니다. 리뷰의 중요도에 따라 다른 태그를 작성하여 리뷰이(Reviewee)가 리뷰어(Reviewer)의 의도를 명확하게 파악할 수 있고, 이를 통해 커뮤니케이션 비용 절감을 기대할 수 있어요.
맺음
취향의 영역이라 할 지라도, 아무런 근거 없이 무작정 제안한 것은 아니었습니다. 나름대로 더 완성도 있는 프로젝트를 개발하고 싶은 마음이 반영되었던 것 같네요. 다만, 내가 그런 것처럼 팀원들 역시 좋은 코드를 위해 고민한 뒤 작성한 코드라는 것을 항상 명심해야 할 것 같습니다. 고민의 결과물을 충분히 존중하는 것 역시 당연한 일이겠지요.
이번 경험을 통해 더 성숙한 리뷰를 남길 수 있을 것 같아 앞으로의 프로젝트가 더 기대됩니다✨