개발자 코드리뷰가 필요한 이유 (이상적인게 아니고 기본인 것)

개발자 코드리뷰가 좋거나 안 좋거나 아니면 애매하다는 이유로 잘 정착하지 못하는 개발조직이 많은 것 같다. 잘 정착하기위해서는 코드리뷰 참여자들 모두가 마음에서 우러나는 긍정적인 신호가 필요하다. 그 긍정적인 신호를 만들기 위해 코드리뷰가 필요한지에 대하여 누군가를 설득한다고 가정하고 글을 써보려고 한다.

---

1. 코드리뷰의 장점

개발 컨벤션 준수, 이슈 발견을 대표적으로 꼽는다.

 

1-1. 코딩 컨벤션 준수 = 생산성 향상

내가 개발한 기능을 꼭 내가 유지보수하는 것은 아니다. 그리고 내가 개발한 기능을 꼭 내가 기능 고도화하는 것도 아니다. 새롭게 팀을 옮겨 새로운 환경의 코드를 만나게 될 수도 있다. 그렇기에 개발을 하면서 수없이 다른 사람의 개발 코드를 만나야하며 이해해야한다. 이때, 생산성을 높이기 위해 코딩 컨벤션을 준수해야한다. 코딩 컨벤션을 정해두었다고 하루아침이 조직의 코딩 스타일이 맞춰지는 것은 아니다. 꾸준한 리뷰를 통해 체득해야한다. 

 

1-2. 이슈 발견 (사이드이펙트, 성능 등)

화면을 보지 않아도, API를 직접 실행해보지 않아도, 나의 경험에 빗대어 이러한 코드를 짰을때 사이드이펙트가 발생하겠다하는 지점이 분명 있다. 사이드 이펙트를 많이 경험한 사람일수록 더 리뷰해줄게 많다. 유지보수하면서 하루종일 이슈의 원인을 찾다가 한 줄 고치는 경우도 꽤 많다. 만약 코드 리뷰 단계에서 그 한 줄을 필터하여 누군가 잡아줬더라면 누군가의 유지보수 하루를 살려낼 수 있다.
 사이드이펙트 뿐만 아니라 성능 이슈 지점도 발견할 수 있다. 작은 성능 이슈가 큰 문제를 만들어낼 수 있고 하루아침에 자잘한 성능 이슈를 모두 걷어낼 수 없기에 코드를 짜는 첫 지점부터 최대한 성능을 고려해 개발하는 것이 좋다.

 

보통 이 두 가지를 코드리뷰의 대표적인 장점으로 꼽는데, 개인적으로 몇가지 더 있다고 생각한다.

 

2. 코드리뷰의 또 다른 장점

 

2-1. 지식 노하우 전파

10명의 개발 조직이 있다고 했을때, A팀원, B팀원 모두 어떠한 개발 소스에 관하여 이슈가 있음을 확인했다. 팀원들에게 공유할 목적으로 잘 정리해 사내채팅방에 공유했다. 다른 팀원 8명은 두 팀원이 잘 정리한 내용은 확인하고 싶었지만 각자의 사정으로 인하여 일단 스킵하게 되었다.
 그리고 지난 어느 날 같은 이슈가 또 발생했다. 프로세스를 어떻게 개선하면 좋을까 고민했다. 잘 전파하지 못한 탓이기에 A팀원, B팀원이 사내채팅방에 다 읽고 이해될때까지 주기적으로 사내채팅방에 공유해야했을까? 아니면 잘 확인 안 한 탓이기에 8명의 팀원이 바쁘더라도 정리된 글을 정독하고 이해해야했을까? 둘 다 무리라고 생각한다. 가장 좋은 방법은 코드리뷰다. C라는 팀원이 같은 이슈가 발생할만한 코드를 작성했을때 리뷰를 해주면 된다. 자신의 코드를 피드백해준 부분을 C는 잊지 못할 것이고, 나머지 팀원들은 자신도 같은 피드백을 받고 싶지 않기에 사내채팅방에 공유된 글보다는 훨씬 관심 갖고 확인할 것이다. 이렇게 지식 노하우가 전파되고 조직이 상향평준화될 수 있다.

 

2-2. 상하막론 피드백

건강한 조직으로 거듭나려면 상하 막론하고 피드백이 원활해야한다. 주니어 개발자가 시니어 개발자에게 코드 리뷰를 해줄 수 있는 환경이라면 그 조직은 보다 더 건강할 가능성이 높다고 본다. 피드백이라는 것은 아무리 좋게 말해도 마음 한구석 찜찜한 부분이 있는 녀석이다. 이 부분을 발판삼아 성장하고자 하는 사람이 있는가하면, 다시는 피드백받지 않기 위해 더 노력하는 사람도 있다. 어떻게든 조직은 성장한다. 주니어가 시니어에게 코드리뷰에서 피드백할 수 있다보면 코드 외적인 의견도 서슴없이 소통될 수 있음을 말한다. 개발 조직도 조직이기에 수많은 커뮤니케이션이 오간다. 불만이 생길 수 있고, 의견을 내고 싶을때도 있다. 침묵은 조직을 병들게 한다. 코드리뷰의 피드백 문화가 잘 잡히면 조직은 침묵하지 않을 것이라고 믿는다.

 

2-3. 커뮤니케이션 능력 향상

 위에서 말했다 싶이 피드백이라는 것은 아무리 좋게 말해도 마음 한구석 찜찜한 부분이 있는 녀석이다. 만약 좋게 말하지 않고 팩트에만 의거해 리뷰하다보면 마음 한구석 찜찜한게 아니라 '이 사람이 나에게 안 좋은 감정이 있나?'라고 비춰질 수 있다. 피드백을 주고 받는 과정에서 좀 더 상대방을 배려하며 소통하는 방법을 고민하게 된다. 그렇게 커뮤니케이션 능력이 향상된다.

---

 물론, 장점만큼 단점이 있을 수 있다. 조금 더 시간을 투자해야된다는 점, 리뷰로 인한 병목현상이 발생할 수 있다는 점, 지속해서 리뷰문화를 개선해나가지 않으면 단순히 컨벤션 혹은 탑다운의 지식 주입이 될 수 있다는 점 등등등.
그럼에도 불구하고 많은 개발 조직이 코드리뷰를 하는 것은 단점보다는 장점이 크기 때문이 아닐까 싶다.

---

 몇가지 다른 포스팅에 주옥같은 말들이 있어 몇 개 적어보며 마무리한다.

• 코드를 놓고 일이야기를 하는 것. 그 모든 행위가 코드리뷰다.
• 코드리뷰 문화는 회사가 어떻게 운영되는지 확인할 수 있는 나침반과도 같다.
• 코드는 내가 아니고, 그냥 내가 작성한 코드일뿐, 상처받지 말아야 함

---

참고한 문서

https://greypencil.tistory.com/141
https://tech.kakao.com/2016/02/04/code-review/
https://blog.logi-spot.com/%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0%EC%9D%98-%EC%A7%84%EC%A7%9C-%EB%AA%A9%EC%A0%81%EC%9D%80-%EB%94%B0%EB%A1%9C%EC%9E%88%EB%8B%A4/