유튜브 우아한Tech 백명석님의 코드리뷰 세미나를 듣고 기억에 남았던 이야기를 정리해보려고 한다.
영상 링크: https://youtu.be/ssDMIcPBqUE
세미나 자료: https://www.slideshare.net/codetemplate/2022-01okky

세미나 내용은 다음과 같은 목차로 되어 있다.

• 왜 코드 리뷰를 해야 하나?
• 코드 리뷰의 절차
• 왜 코드 리뷰가 어려운가
• 기법들

왜 코드 리뷰를 해야 하나?

한마디로 정리하자면 코드리뷰가 당장은 시간도 많이 필요해보이지만 결국에는 "생산성을 높이는데 도움"이 되기 때문이다. 사실 우리 조직에서 코드 리뷰의 필요성에 대해서는 잘 인지하고 있는 편이라고 생각한다. 그렇기 때문에 이 부분은 고개를 끄덕이며 술술 들었다. 이 부분에서 가장 인상 깊었던 것은 아래 문구였다.

"The only way to go fast, is to go well"- Robert C. Martin

코드 리뷰의 절차

코드 리뷰의 절차는 위의 발표 자료가 잘 표현하고 있다. 그리고 우리 조직에서 코드 리뷰의 절차도 잘 진행되고 위와 같은 형태 잘 진행되고 있다고 생각한다.

왜 코드 리뷰가 어려운가

이 부분이 이 글을 쓰게 된 이유이다. 평소 코드리뷰를 하면서 어려움을 겪었던 부분에 대해 어느정도 해결책을 얻을 수 있었다. 우선 여기서 말하는 코드 리뷰가 어려운 이유는 "코드에 대한 비판을 자신에 대한 비판으로 이해"하기 때문이라고 한다.

기법들

1. 효율적인 PR 방법

정적 분석, 포멧팅 등 컴퓨터가 할 수 있는 일은 컴퓨터로 처리

사실 코드리뷰를 하면서 가장 아쉬웠던 점이 이 부분이었다. 실제로 코드리뷰를 하다보면 로직적인 측면에서 리뷰를 받고 싶었는데 항상 포멧팅, 타입 힌팅 등 사소하거나 개인적인 스타일에 관한 리뷰가 많았다. 그러다보니 정작 비지니스 로직 같은 고수준의 리뷰는 이뤄지지 않았다. 그래서 리뷰한 코드에서도 이슈가 나오기도 하고 이슈가 없다고 하더라고 더 좋은 방법은 없었나 하는 아쉬움이 남는 경우가 많았다.

그렇다고 포맷팅이나 힌팅, 정적분석 등이 중요하지 않다는 것은 아니다. 코드를 장기적으로 유지 및 보수를 하기 위해서 코드의 품질을 잘 유지하는 것이 중요하기때문에 매우 중요한 부분이라고 생각한다. 또한 이것이 바로 생산성에 직결된다고 생각한다. 다만, 이러 일들은 컴퓨터가 잘할 수 있는 일이니 컴퓨터에게 맡기고 저자가 책임감 있는 자세로 본인이 작성한 코드에 대해서는 PR을 올리기 전에 잘 챙겨야한다고 생각한다. 각자의 책임감있는 자세와 팀원 간의 신뢰가 쌓인다면 더 효율적이고 의미있는 코드리뷰가 될 수 있을 거라고 생각한다.

스타일 가이드를 통한 스타일 논쟁 해소

이 세미나에서는 스타일에 대한 논쟁은 리뷰에서 시간 낭비라고 한다. 사실 맞는 말인 것 같다. 왜냐하면 스타일에는 정답이 없기 때문이다. 하지만 가독성과 코드의 일관성을 위해 팀내에서 합의를 통해 스타일 가이드를 만들어 나가면 좋을 것 같다. 이 세미나에서는 3가지 방법을 소개하고 있는데 이미 존재하고 있는 스타일 가이드를 가져와 사용하거나 팀내에서 합의를 통해 점진적으로 가이드를 구축해 나가는 방법 마지막으로 앞의 둘 방법의 하이브리드 형태이다.

PR을 올릴 때 커멘트 달기

저자가 PR을 올린 후 먼저 읽어 본 후 설명을 커멘트로 남겨서 리뷰어들의 시간을 절약할 수 있게 하라는 것이다. 사실 가끔 꼭 리뷰를 받고 싶은 부분이 있을 때 종종 썼던 방법이었다. 그래서 이 얘기를 들었을 때 이 부분은 잘하고 있었구나 생각이 들었다.

리뷰어에 모두를 포함하라

이 부분은 가끔 헷갈렸던 부분이었다. PR을 올릴때 어디까지 리뷰어 범위에 넣어야할지 고민이 될 때가 있었다. 여기서는 많은 사람이 볼 수록 버그를 더 잘 찾아낼 수 있고 많이 저자도 많은 사람이 본다는 사실에 좀 더 잘 하려는 경향이 있어 리뷰어는 많을수록 좋다고 얘기한다. 팀이나 프로젝트마다 조금씩 달라질 수는 있지만 많은 사람들이 코드를 들여다 보는 것은 좋은 문화라는 생각이 든다.

2. 효율적인 리뷰 방법

위에는 어떻게 PR을 올려야 효율적인지에 대한 내용이라면 이제는 리뷰를 효율적으로 하는 방법에 대한 내용이다.

리뷰는 즉시 시작

여기서는 코드 리뷰는 높은 우선순위로 진행되어야하고 늦어도 1일 이내에 리뷰가 모두 이뤄져야한다고 한다. 그 이유는 코드 리뷰가 완료되기 전까지 저자는 blocked된 상태가 되어 업무에 차질이 생길 수 있기 때문이다. 저자가 리뷰하는 동안 다른 일을 한다고 하더라도 리뷰가 끝나기 전까지 두가지 일을 머리속에 넣고 있어야하기 때문에 힘이 든다고 한다. 그리고 리뷰가 끝나면 다시 원래 일로 돌아와서 작업을 해야하기 때문에 컨텍스트 스위칭으로 인한 부담이 증가한다고 한다.
하지만 리뷰어 입장에서는 코드리뷰를 하다보면 가장 큰 문제는 시간을 내는 것이다. 다들 너무 바쁘다 보니 PR이 올라와도 리뷰를 시간내어 한다는 것이 늘 부담이 된다. 그렇기 때문에 자꾸 후순위로 미루게 되고 그러다 보니 좋은 리뷰를 하지 못할 때가 많았다. 이 세미나에서는 이 문제를 해결하기 위해 몇가지 해결책을 제시한다.
우선 리뷰어는 매일 아침 30분, 점심 식사 후 30분을 리뷰를 위해 미리 확보하라는 것이다. 일을하다 PR이 올라오면 리뷰를 하기 위해 별도로 시간을 내는 것은 부담스러울 수 있지만 오전, 오후 본격적으로 일을 시작하기 전에 30분 정도 시간을 낸다고 하면 좀 덜 부담스러울 수 있을 것 같다. 그리고 저자의 입장에서도 워킹 타임 기준으로 4시간 이내에 리뷰를 받을 수 있다는 점에서 좋다는 생각이 들었다.
두번째 해결책은 저자는 PR에 포함된 변경이 적도록 노력하라는 것이다. 그래서 리뷰어가 최대 4시간 이내에는 리뷰를 완료 할 수 있도록 해야한다는 것이다. 위에 언급한 효율적인 PR 방법을 활용하여 리뷰어가 리뷰에 집중할 수 있도록 하는 것도 중요하다고 생각한다.
마지막은 조직적인 측면에서의 노력이다. 저자의 입장에서는 PR을 올려 코드를 머지하고 나면 그 기여를 본인의 성과로 인정받는 것은 비교적 쉽다. 하지만 코드리뷰를 하는 리뷰어의 기여는 성과로 인정 받기가 어려운 것 같다. 리뷰를 한다는 것은 분명 직접 개발하는 만큼 때로는 그 보다 더 어렵고 에너지를 많이 쏟아야하는 일임에도 불구하고 이 노력을 인정받기는 어려운 것 같다. 그렇기 때문에 리뷰어 입장에서는 코드리뷰의 우선순위가 점점 떨어지고 시간 낭비처럼 느낄 수 있는 것이다. 사실 지금까지 코드리뷰를 하면서 리뷰어의 입장은 많이 생각해 본적이 없이 왜 리뷰가 잘 안될까 생각만 했는데 이 부분은 완전히 간과하고 있었다. 그리고 리뷰어의 기여를 인정해주는 문화가 정착되어야 건강한 코드리뷰 문화가 정착될 수 있겠다라는 생각이 들었다.

고수준으로 시작, 저수준으로 내려가라

리뷰 라운드에서 많은 의견을 남길 수록 저자는 당황할 위험이 커진다고 한다. 저자도 사람이기 때문에 자신이 올린 PR에 많은 의견이 달리면 당황하는 건 당연할 것 같다. 그렇기 때문엔 리뷰 초기 라운드에서는 버그나 장애 등 고수준으로 피드백으로 제한하고 고수준의 피드백이 처리 된 후에 저수준 이슈를 처리하라고 한다. 개인적으로 코드리뷰를 할때 매우 중요한 부분이라고 생각한다.

리뷰의 범위를 존중하라

사실 이것과 관련하여 코드리뷰를 하면서 당황스러웠던 경험이 있어서 매우 공감이 갔다. PR을 올렸는데 이번에 내가 작업한 범위가 아닌 기존 코드에 대한 리뷰가 달린 것이다. 우선 이번 PR에 포함된 변경점도 아니었고 장애를 일으키거나 버그가 될 코드도 아니였기 때문에 좀 당황을 했다. 그렇기 때문에 리뷰의 범위를 존중하는 것이 중요하겠다라는 생각이 들었다. 이 세미나에서는 대신 예외상황에 대해 이야기를 하는데 PR이 둘러싼 코드에 영향을 미칠 때에는 범위에 벗어나도 리뷰를 해야한다고 한다. 그리고 사실 리뷰 범위를 벗어나더라고 장기적으로 코드 품질을 위해서 필요한 코멘트도 있을 수 있다. 이런 것들은 우선순위에 따라 백로그에 두고 별도의 PR을 통해 해결하는게 바람직해 보인다.

한두 등급만 코드 레벨을 올리는 것을 목표로

사실 이 부분을 듣고 느끼는 점이 많았다. 늘 코드리뷰 관련된 세미나를 보면 어떻게 해야하면 좋은 코드가 될 수 있게 할지에 대한 관점으로 이야기를 많이 들어왔다. 그래서 여기서 코드리뷰의 목표는 완전한 코드를 만드는 것이 아닌 한두 등급만 올리는 것을 목표로 하라고 해서 좀 놀랐다. 사실 생각해보면 코드리뷰가 어려웠던 이유도 완벽을 추구하려다 보니 그런 것 같다는 생각이 들었다. 아무리 리뷰를 잘하더라고 완벽한 코드는 불가능에 가까운데 말이다. 다만 한두 등급만 올리는 정도로는 장애나 버그를 일으키는 수준의 엉망인 코드가 PR에 올라온 경우에는 승인을 보류할 수 있다고 한다.

3. 피드백 방법

'너'라고 하지 마라

리뷰의 대상은 사람이 아니라 코드이다. 그렇기 때문에 코드에 대한 비판을 하는 것이 바람직하다고 한다. 이를 위해 '너'라는 말만 빼도 좋은 피드백을 할 수 있게 된다고 한다. 그리고 I Message와 "~하는 것을 제안합니다.", "~하는게 어떨까요?"등 완곡한 표현을 통해 저자의 기분을 상하지 않게 하는 것이 중요하다고 한다. 그리고 명령조가 아닌 요청으로 표현해야한다고 한다. 이 얘기를 듣고 나는 평소에 커멘트를 어떻게 남겼는가 혹시 나는 말로 저자의 기분을 상하게 한적은 없었나 좀 돌아보게 되었고 앞으로 조심해야겠다는 생각이 들었다.

건설적인 피드백을 하라

코드리뷰가 경쟁이 되어서는 안되고 팀의 생산성을 높이는 방향으로 가야한다고 한다. 코드 리뷰가 비판이 아닌 서로 발전할 수 있는 기회로 삼아야한다는 것이다. 그리고 건설적인 피드백을 못하겠으면 그냥 피드백을 하지 말라고 한다. 그 이유는 괜히 서로 감정을 상하게 하는 피드백을 하다 팀을 떠나겠다는 사람이 있으면 팀의 입장에서 매우 손해이기 때문이다. 그리고 결국 이는 서로 성장할 수 있는 기회를 잃어버리는 것이기 때문에 모두에게 최악의 결과이다.

진정한 칭찬을 해라

가끔 다른 사람의 코드를 보다 보면 이렇게 좋은 방법이 있었어 놀란 경우가 있다. (이럴때는 조용히 내꺼에도 적용해 보는데....ㅎㅎㅎ) 이럴때 칭찬을 해주면 좋겠다는 생각이 들었다. 칭찬은 고래도 춤추게 한다고 저자에게도 큰 힘이 되고 나도 많이 배울 수 있게 되어 선순환이라고 생각한다. 앞으로 칭찬에 인색해지지 말아야겠다고 생각이 들었다.

의견이 아니라 원칙에 기반하여 피드백하라

저자에게 의견을 줄 때는 "제안하는 변경"과 "이유"를 모두 설명하라고 한다. 예전에 받았던 리뷰 중에 이런 리뷰가 있어 당황스러웠던 적이 있었다. 클래스 이름을 어떻게 바꿨으면 좋겠다라는 코멘트였는데 이유가 없었다. 그래서 이유를 물었고 그러자 그 이유가 본인의 생각에 직관적이지 않다라는 것이었다. 하지만 나는 이유가 납득이 잘 안됐고 이름을 지을 때 파이썬 기본 라이브러리의 이름을 참고하여 지은 것이기 때문에 문제가 없을 것 같다는 의견이었다. 결국에 이름을 바꾸기 싫어 안바꿨고 그대로 머지가 되었다. 하지만 기분이 서로 상했었던 것 같다. 그때 이러한 원칙을 공유하고 이해했더라면 좋았겠다라는 생각이 들었다.

반복적인 패턴에 대해서 피드백을 제한하라

저자의 실수가 동일한 패턴일 경우 2~3군데만 코멘트를 남기라는 것이다. 저자가 식별할 정도만 된다는 것이다. 하지만 간혹 정말 코멘트를 남긴 곳만 수정하는 경우도 있는데 이건 다시 정중하게 얘기해서 수정하도록 해야하는 것 같다. 그리고 저자도 기계적으로 피드백을 수정하지 말고 스스로 이런 피드백을 받았을 때는 리뷰어가 두번 세번 동일한 피드백을 하지 않도록 노력해야할 것 같다.

4. 교착상태 시

교착 상태를 적극적으로 처리해야한다고 강조한다. 이런 교착상태에 빠지게 되면 인정하거나 만약 도저히 해결이 안된다면 escalate해서라도 해결하라고 한다. 위에서 말했듯 코드리뷰를 하다 서로 관계가 나빠져 퇴사하거나 조직을 이탈하게 된다면 모두에게 손해이다.
그럼 교착상태는 어떻게 처리해야하나를 보면 설계리뷰 때 이런 논의가 있었는지 돌아보고 그때 했어야할 논의가 지금 이뤄지는 것은 아닌가 점검 해보라고 한다. 그리고 심각한 문제가 아니라면 그냥 인정하고 좋은 동료로 남아 협업하는 것이 좋다라고 한다.

마무리하며...

늘 코드리뷰에 관한 세미나 강의를 들으면 어떻게 해야 좋은 코드가 되는지에 대한 부분을 늘 강조 했었는데 여기서는 정 반대의 시각으로 생각해 볼 수 있어서 좋았다. 완벽을 추구하기 보단 코드 리뷰 문화가 정착될 수 있도록 각자 노력하는 것이 우선이라는 생각이 들었다. 그리고 그동안 왜 내가 코드리뷰를 어렵게 느꼈는지 좀 명확해져서 좋았고 또 한편으로는 나의 이전 코드리뷰에 대해서도 반성을 했다. 또 느낌점은 우리는 모두 공학을 하는 사람이지만 공학도 결국 사람이 하는 일이기 때문에 인문학적인 부분도 매우 중요하다는 생각이 들었다. 이 세미나는 내가 일 하는데 있어 새로운 관점을 제시해 주어 매우 좋았고 인상 깊었다.