[회고] 코드리뷰 도입, 그 후 3개월

코드리뷰를 도입하자고 제안했다.

상황은 다음과 같다.

<상황>

필자는 2명으로 구성된 웹 프론트엔드 팀에서 웹 캘린더를 만드는 일을 하고 있다.
동료의 코드를 알아보기가 힘들었다.
동료가 짠 모듈에 새로운 기능을 더하려면 파악해야 하는 코드의 양이 방대했다.
또, 변수명을 통해 무엇이 할당되어있는지 파악하기 힘들었다.
따라서
1. 코드 파악
2. 변수명 리네임
3. 비즈니스 로직 파악
4. 비즈니스 로직 리팩터링
5. 기능 첨가
순서로 업무를 진행했었다.
 
다시 말하면 동료는 빠르게 기능을 개발하고, 필자는 맡은 피처 개발을 위해서 이미 개발된 동료의 코드를 뜯어서 파악하고 리팩토링한 후에야 모듈을 추가할 수 있는 상황이었다.
스파게티스러운 비즈니스 로직이 계속해서 붙어갔다.
그런 코드가 붙으면 필사적으로 의존성을 분리하는 리팩토링을 진행했다.
동료는 지라 이슈를 빨리빨리 완료하는데, 필자는 한 피처 개발에 일주일을 온전히 소진한 적도 있었다.
위 상황이 반복되자 엄청난 비효율의 존재를 느꼈다.
생산성이 명확히 저해되는 상황이었다.
 
힘들지 않았다고 하면 거짓말이다.
다만 이러한 상황에서 동료를 탓하기보다 본인이 할 수 있는 게 무엇이 있을지 고민했다.
그 결과 생각해낸 것은 "코드리뷰"였다.
남이 짜놓은 불명확한 변수명과 의존성 높은 로직을 매번 필자가 파악하고 고치기보다
코드리뷰를 통해 더 좋은 로직, 더 좋은 변수명으로 팀의 코드 스타일이 동기화되면 좋겠다는 생각을 했다.
본인이 짠 코드를 본인이 리팩토링하며 생산성의 향상을 꾀하는 것이다.
 

<코드리뷰 제도를 제안한 배경>

"당신의 코드가 이해하기 힘듭니다. 이 부분은 이렇게 해주시고, 이 부분을 이렇게 해주세요."
를 직접 말하기보다 코드리뷰라는 제도를 통해서 말하면 좀 더 감정이 덜 상할 것 같았다.
코드리뷰라는 제도를 강제함으로써 팀 차원에서 더 좋은 코드를 향한 태도를 함양할 수 있을 것 같았다. 
 
따라서 아래처럼 제안했다.
(실제 슬랙 대화 재구성)
 
---
 
필자: 저희 협업의 효용성을 늘리기 위해서 저희끼리 코드리뷰 제도를 도입하면 어떨까 하는데요, pr이 올라가면 동료의 verify 혹은 코드리뷰가 있어야만 merge가 가능하도록 하는 규칙은 어떠신가요? 작업이 완료되었다고 생각하면 merge는 본인이 하는 것으로요.
 
동료: 해당 제도의 취지는 좋은 것 같습니다 궁금한 점은 갑자기 리뷰 제도가 필요하다고 생각나신 계기가 있으신가요?
 
필자: 네 목적은 다음과 같습니다. 
1. 각자 코딩 스타일이 달라서 논의를 통해 일관된 코드 스타일을 유지하기 위함
  ㅁ 코드 스타일을 일관화하기 위해 리팩토링에 들어가는 비용 절감
     - 현재 1 + 1 - 0.5(리팩토링 비용) = 1.5라면 최대한 2에 가깝게 만들기 위함.
2. 좋은 코드에 관한 고민을 통해 코드 품질을 높임
colorpicker 체크가 실시간으로 반영되지 않는 문제를 고치고 있었는데 제가 제때 OO님 코드리뷰를 하지 않아서 새로 붙은 코드 파악이 어려웠습니다. 문제는 아직도 해결중인데 바로 문제 해결이 쉽지 않아서 리팩토링을 진행중입니다. 그러던 중에 남이 만든 코드라도 내가 만든 코드처럼 이해할 수 있으면 좋겠다고 생각했습니다. 또 반대로 내가 만든 코드도 남이 만든 코드처럼 이해할 수 있도록 하는데 코드리뷰가 도움 될 것 같다고 생각했습니다.
 
동료: 일단 현재 안건이랑 다른 부분이지만, 말씀하신 문제 해결이 쉽지않아서 리팩토링을 다시 진행하는건 생각을 해보셔야할것같습니다.
코드 파악이 다 안되셨는데 리팩토링에 리팩토링을 진행하는건 조금 이해하기가 어렵습니다.. 그리고 일단 저희가 지금 초기개발 단계라 아주 빠르게 개발이 진행되고 있습니다. 때문에 어쩔수없이 개발 스타일을 맞추기 어려운 부분도 있구요 다만 말씀하신대로 저희가 서로 코드스타일을 맞춰가기위해 코드리뷰를 도입하는건 찬성합니다. 처음에 말씀드린 리팩토링 부분은 또 다른 버그를 야기할수있을 가능성이 크다고 보여집니다
 
필자: https://ringed-condor-e73.notion.site/2023-02-07-58e7757ec6a24abdad191be46aaf80a4 지금 하고 있는 리팩토링은 이 노션에 정리되어있는데요, 리네이밍 위주로 진행하고 있었습니다. 또 비즈니스 로직이 명확히 보이도록 코드의 가독성을 높이는 방식으로 리팩토링을 진행했습니다. 지금껏 그렇게 리팩토링 후에 로직이 더 잘 파악되고 문제 원인이 더 잘 보이는 경험을 해서 그렇게 리팩토링을 진행하고 잇었습니다.  그러한 과정 중에서 이런 리팩토링은 코드리뷰로 방지할 수 있지 않을까? 하는 생각이 들어서 제안했습니다
 
동료: 네 말씀하신대로 리팩토링은 가독성이 주가된 것인데, 비즈니스 로직을 건들이지않았다고 이해하면될까요?
 
필자: 네네 맞습니다. 로직 리팩토링은 피하고있습니다
 
동료: 지금 출시가 앞이라 남은 버그 해결하기가 바빠서 노파심에 얘기를 드려봤습니다. 저도 코드리뷰를 도입하는것이 좋을것 같습니다
 
필자: 네 감사합니다!! 사실 업무일지 저렇게 일주일 전부터 쓰고 있었는데, 제가 작업한 의도나 현재 업무 진행상황 파악에 도움 되실 거 같아서 매일 공유드려도 괜찮을까요? 공유한다면 개발직군에 공유해서 뭔가 동료 전체의 소통하는 분위기를 만들면 어떨까 합니다. 만든다기보단… 0.1정도 이바지..
 
동료: 넵 코드리뷰를 할때 쓰신 글을 읽고 보면 이해가 빠를 것 같기도합니다
 
필자: 오 네 알겠습니다!! 오늘도 화이팅입니다 ㅠㅠ!!
 
동료: 넵 화이팅입니다!!
 
---
 

코드리뷰 제도가 동료의 동의를 얻어 도입되었다.

이 때 정말 기뻤다.
그리고 한달 정도 서로 적극적으로 리뷰를 했다.
어느 정도 코드 스타일도 통일되고, 명확한 변수명과 이해하기 쉬운 비즈니스 로직을 추구하는 방향으로 바뀌었다.
확실히 좋은 성과였다.
 
하지만 도입 후 3개월이 지난 지금, 문제 몇몇이 수면위로 떠오르기 시작했다.
 
필자가 파악한 문제는 다음과 같다.

1. 코드 리뷰 목적에 관한 공감대 형성 실패
2. 코드 리뷰 강제성 부재
3. 좋은 코드 기준 불명확

 

1. 코드 리뷰 목적에 관한 공감대 형성 실패

코드 리뷰 목적에 관한 공감대가 형성되지 않았다고 판단한 계기는 아래 사건을 통해서였다.
https://developeonmyown.tistory.com/379

[TIL] 2023-04-28 듣는 것의 힘은 위대하고 강력하다.

언젠가부터 동료는 코드리뷰에 스트레스를 받고 있었다.
코드리뷰의 내용이 변수명에 관한 내용으로 반복되다 보니 스트레스를 느꼈다고 한다.
 
필자의 업무는 한달쯤 전부터 웹캘린더 업무에서 랜딩페이지 및 블로그 개발 작업으로 이관되었다.
코드리뷰는 웹 캘린더 부문에서 '필자 => 동료' 방향으로만 진행되었다.
한달간 일방적인 방향으로 코드 리뷰가 진행되었기에 동료가 더욱 스트레스를 느꼈을 수 있다.
 
랜딩 페이지, 블로그 작업 코드리뷰에 관한 논의는 이루어지지 않았다.
반성해야 한다. 필자 본인이 제안한 제도이다.
제도를 도입했으면 랜딩페이지 및 블로그 작업에 대해서도 도입한 제도를 적용할 지 논의해야 했다.
하지만 그러지 않았다.
코드리뷰에 얼마나 많은 품이 들어가는지 알고 있기에 쉽게 요청드릴 수 없었다.
이미 웹 캘린더 작업을 혼자 해야 하는 상황인데 부담을 지어드리기 싫었던 것 같다.
또, 랜딩 페이지 작업은 혼자 개발할 수 있는 볼륨이었다.
작업 완료 후에는 변경, 협업이 많이 이루어지지 않을 것 같아 코드 리뷰 없이 독립적으로 진행해도 괜찮다고 생각했었다.
 
하지만 이 사고가 타당하든, 타당하지 않든, 코드리뷰 실행에 관한 논의는 같이 해야 했다.
나 혼자 판단할 게 아니었다.
 
위 상황이 발생한 근본적 이유는 코드 리뷰 목적에 관한 공감대가 형성되지 않았기 때문이라고 생각한다.
코드 리뷰는 본인 작업물을 채점 받고 지적 받는 게 목적이 아니다.
 
필자가 생각하는 코드 리뷰의 목적은
1. 회사 제품의 코드 품질이 더 나아지도록 머리를 맞대고 집단지성을 활용하는 것
2. 현재 개발자 뿐 아니라 미래의 다른 개발자와 협업하기 용이한 코드를 만드는 것
이다.
여기서 미래의 다른 개발자는 literally 다른 개발자일 수도 있고, 과거의 개발 컨텍스트를 까먹은 미래의 본인일 수도 있다.
 
작업이 PR로 올라간 그 순간부터, 그것은 본인의 작업물을 넘어 "예비 팀 작업물"로서 대해야 한다고 생각했다.
그래서 리뷰할 내용이 없어도 드릴 수 있는 리뷰 내용을 최대한 짜내서라도 리뷰했다.
그 PR은 단순히 타인의 작업물이 아니라 내가 반드시 이해하고 피드백해야 하는 "미래의 내 코드"와 같다고 생각했기 때문이다. 
시간이 없어도 최대한 It Looks Good To Me스러운 코드리뷰는 피했다.
변수명 Renaming이나 영문법 Correction같은 사소한 리뷰라도 조금이라도 도움될 수 있는 피드백을 드리려 노력했었다.
It Looks Good To Me스러운 코드 리뷰는 성의 없는 것이고 후자의 행동이 조금이나마 성의를 표현하는 것이라고 생각했다.
하지만 그것이 동료가 받아들이기에는 스트레스였다고 한다.
따라서 코드 리뷰의 목적에 관한 공감대를 형성하고, 코드 리뷰의 대상, 코드 리뷰의 방식 등을 논의하여 문서화할 필요성이 있다고 판단했다.
명확한 문서가 기준으로 잡히면 좋은 코드리뷰 문화가 형성 되는데 도움 될 것이라고 생각한다.
 

2. 코드 리뷰 강제성 부재.

이렇게 대화가 끝나고 일주일이 지났다.
코드 리뷰 방식을 논의하는 날은 기약이 없어졌다.
필자와 동료 모두 업무에 치여 코드 리뷰 방식을 생각할 겨를이 없어서였으리라.
 
그리고 동료는 팀에서 합의한 PR Merge 기준에 예외를 두기 시작했다.
<5/4일자 DM>
동료: 금일 배포는 배포후에 따로 pr하는걸로해야할것같습니다 대표님이 배포원하시는것같아서..
필자: 배포 후에 PR이라는게 어떤 말씀이신가요?
동료: 아니 배포후에 리뷰입니다
필자: 아 넵 알겠습니다!
 
<5/8일자 DM>
동료: 말일 반복 기능 테스트 금일까지라 이것도 먼저 머지하겠습니다
필자: 네 알겠습니다!
 
코드가 리뷰없이 바로 머지된다.
 
이것이 반복되면 코드리뷰 제도는 점점 역사의 뒤안길로 사라질 것이다.
사라진 이후에는 "저번에 해봤는데 안하는게 더 좋은 것 같아요" 라는 논리로 더 도입하기 힘들어질 수 있다.
 

3. 좋은 코드 기준의 불명확성

아무래도 "영문법이 올바른 코드"라는 기준은 동료가 생각하는 좋은 코드의 기준들 속에 존재하지 않는 것 같다.
필자는 그렇게 생각하지 않는다. "영문법이 올바른 코드"는 신뢰할 수 있는 코드의 시작점이라고 생각한다.
영문법이 올바르지 않아 해당 코드를 보는 개발자마다 코드의 해석이 달라진다면, "그 코드의 뜻이 정말 그 뜻이 맞는지"부터 의심해야 할 것이고, 협업하는 경험은 악몽과 같아질 것이다.
이것을 직접 말하기보다 날을 잡고 논의하여 하나의 결론을 이끌어내야 한다고 생각한다.
그렇게 얻어진 결론은 같은 팀의 모든 개발자들이 항상 염두하여 참고하며 개발해야 한다.
답은 "좋은 코드 기준의 문서화"라고 생각한다.
 
---
 
이제 곧 블로그 작업도 끝나고 웹캘린더 작업으로 돌아갈 때가 온다.
반드시 좋은 코드리뷰 문화를 회사에 정착시키고 싶다.
더 좋은 제품을 만들고, 더 좋은 개발 문화를 만드는데 이바지하고 싶다.
 
좋은 개발자란 무엇일까? 라는 물음에 대한 답을 찾기 위해 "우아한 형제들"이라는 회사부터 파기 시작했던 요즈음이다.
개발 문화의 최고봉이라는 우아한 형제들을 파보면 인사이트를 얻을 수 있을 것 같았다.
이미 필자는 본인이 "우아한 개발자"이다. 라고 생각하며 살고 있다.
"우아한 테크" 유튜브 채널을 구독하고 "배민다움"이라는 책을 읽으며 그 생각은 더욱 깊어지고 있다.
필자가 우아한 개발자라면 필자가 속해 있는 회사 또한 우아한 조직으로 변화시킬 수 있다.
그래서 하루 하루 열심히 배우고 노력하는 중이다.
 
마침 우아한 스터디에서 "근거있는 코드 리뷰를 위하여"라는 주제로 스터디를 진행한다고 한다.
정말 간절히 배우고 싶다.
스터디에서 얻은 인사이트를 필자의 조직에 적용해 "좋은 코드리뷰의 정착"이라는 좋은 사례를 만들고 싶다.
그 과정을 또 회고로 작성하여 우아한 스터디를 포함하여 다른 커뮤니티에까지 공유한다면 1명의 성장은 N명의 성장으로 확산 될 것이다.
 
N명의 성장을 이끌어내보고 싶다.
그것이 우아한 개발자의 덕목 중 하나가 아닐까