코드리뷰에 관하여

코드 리뷰가 뭐예요?

..라고 물어보면 질문받는 사람마다 다른 대답이 돌아왔었다. 용어 자체의 뜻이 모호해서 그런 걸까, 코드의 기술적 분석을 포함한다는 공통분모는 있었지만 그것 말고는 전부 생각하는 정의가 제각각이라는 게 참 신기하게 느껴졌다. 마치 '리팩토링Refactoring'과 비슷한 느낌인데, 이 역시 생각하는 뜻이 다 달라서 한 번은 이런 곤혹을 치룬 적이 있었지.

---

니델바 : 저 코드 리팩토링 경험이 있습니다!

시니어 : 오 그래요? 어떤 식으로 하셨죠?

니델바 : 상속구조를 개선하고, 변수명과 스크립팅 방식을 통일하고.. 뭔가 쓰레기더미로 가득 찬 집을 정리하는 느낌이었네요.

시니어 : 그래서요?

니델바 : 네?

시니어 : 그건 코드 리팩토링이 아니죠.

니델바 : 

---

물론 내가 겪은 상황을 단면으로 일축하다 보니 저 대화 양상에서의 상대방이 예의 없는 사람(...)처럼 보일 수는 있겠으나 요지는 그거였다. 업무 혹은 Progress의 용어도 사람마다 다 다를 수 있겠구나 하는 것. 물론 나는 저 시니어에게 '코드 리팩토링이란 무엇인가-' 에 대하여 자그마치 20분간 일장 연설을 들어야 했다. 이런 상황이 '코드 리뷰'라는 단어에서도 그대로 이어졌는데, 멘붕하게 된 이유는 다음 대화에서였다.

---

친구 : 이번에 회사에서 코드 리뷰 있어서 바빠..

니델바 : 헐 그래? 그럼 너가 PT하니?

친구 : 아니. 소집자는 내가 아냐.

니델바 : (소집자..?) 에엫 그럼 누가 리뷰하는데?

친구 : 코드 리뷰를 한 사람만 하는건 아니니까.. 아이고 귀찮아 죽겠다.

니델바 : 아..!

---

친구가 생각하는 코드 리뷰의 정의는 내가 생각하는 것과 달랐다. 저 때 나는 대충 눈치빠른 척을 하며 '다 같이 모여 공통개발코드에 대한 피드백을 하는 자리겠거니-' 하고 넘어갔던 기억이다.

---

 

코드 리뷰는 숙제 검사 맡는 자리?

그렇다면 나는 이제껏 코드 리뷰를 뭐라고 생각하고 있었는가? 돌이켜본다면.. 코드 리뷰라고 부르는 n번의 자리에서 공통으로 내가 했던 것들을 떠올리게 되는 것이다. 나는 이 프로젝트와 코드가 대체 어떻게 굴러가는지 기술적 인과관계를 설명해야 했고, 듣는 사람은 단순히 고개만 끄덕거리거나 '그거 그렇게 하는 거 아닌데.' 로 응수하는, 그야말로 숙제를 검사 맡는 듯한 자리였다. 코드 리뷰를 하는 사람이 '해당 주제에 대해 얼마나 잘 알고 있나'를 테스트받는 느낌? 그렇기에 내가 경험한 '코드 리뷰'는 항상 주니어들의 몫이었다.

 

피드백을 준다는 것

지금은 생각이 좀 바뀌었지만 역시 누군가가 '코드 리뷰가 뭐예요?' 라고 묻는다면 아직 대답하기 어렵다. 이상적인 코드 리뷰가 무엇인지는 어렴풋이 알고 있으나 이게 막상 오프라인 회의실에 자리 깔고 앉으면 서로 의미 없는 논쟁하기 바쁘다는 이미지가 아주 크다. 코드 컨벤션을 지키지 않았다는 둥 괄호 위치가 잘못되었다는 둥 하등 쓸모없는 얘기가 나온다는 것은 코드 리뷰의 질이 그만큼 나쁘단 의미이기도 하다. 피드백을 주고받는 것은 곧 토론과 논쟁의 소지가 있는 것이다. 각자 가지고 있는 개발 스타일에 반하는 것이기도 하고, 때에 따라서는 과도한 논쟁으로 이어지기 쉬우니 그냥 '저 사람은 스타일이 그래' 하며 넘어가려는 분위기가 되고 만다.

 

가령 이슈(버그)가 하나 터졌다고 치자. '이 버그는 누가 만들었는가' 라고 질문 하는 것과 '왜 지금까지 이 버그가 발견되지 않았는가' 라고 질문하는 것의 차이는 매우 매우 크다. 다른 사람이 짠 코드를 들여다보고 피드백을 주고 받는 것이 코드 리뷰의 기본 골자가 된다면 그 기대 효과가 더 크지 않을까? 문제는 이러한 코드 리뷰 문화를 어떻게 정착시킬 것인가에 대해서다.

 

어쩌면 꼭 사람들을 회의실에 소집해서 프로젝터를 켜지 않아도 우리들은 일상에서 이미 코드 리뷰를 꾸준히 하고 있을지도 모른다. 피드백을 줄 때는 남의 자리에 가서 마우스를 뺏어 스크롤 몇 번 휘적거리면 '음 이런 식이군!' 이해할 수 있는 짬이 있다. 그 과정에서 '이렇게 짠 이유가 있어요?' 물어볼 수도 있고, '그거 그렇게 하는 거 아닌데' 하고 이야기할 수도 있고, 따봉을 날려줄 수도 있다. 반대로 피드백을 받는 상황에서도 마찬가지일 것이다. 나의 경우 조금 푸념을 늘어놓자면 지금껏 내 코드를 리뷰해주는 사람이 거의 없다시피 했다. 내가 만났던 팀원들 성격은 너무나 완강했고, 남의 코드 들여다보기를 싫어하는 사람들 투성이였다. 예를 들어 유니티에서 모종의 이유로 Inspector 기능을 사용하지 않는 사람, 모종의 이유로 자료형 Serializable을 걸지 않는 사람이 있었는데, 이유를 물어보니 '개발자는 코드로만 개발해야 한다' 라는 해괴망측한 대답을 한 경우도 있었다. 나는 이런 부류의 사람에게는 피드백을 줄 수도, 받을 수도 없다 느끼고 무조건 이해하려는 방향으로 맘을 틀게 된다.

 

그건 내 책임이 아냐

어쨌든 나는 지금도 코드 리뷰를 준비하고 있다. 하지만 이번 자리는 단순히 숙제를 검사 맡는 자리는 아닐 것이다. 내가 왜 이렇게 코드를 짰는지에 대해 충분히 설명할 근거가 있음은 물론이고 반드시 유의미한 피드백을 받아낼 것이다. 이는 나중에 문제가 발생했을 때 코드를 짠 나만 책임을 지는 것이 아니라 그때 리뷰를 했던 사람들까지 책임을 같이 지게 하리라 생각하면서.

 

앞서 적었지만 피드백이란 건 무섭다. 논쟁으로 번지기 아주 쉽다.(특히 개발자들끼리 모이면 더더욱) 최대한 모나지 않게 진행해야 하고, 상처받을 각오도 해야 한다. 코드 리뷰를 받으며 내가 잘못되었단 생각은 뒤로 접어두자. 더 좋은 코드를 만들기 위한 집단지성을 활용하는 것뿐이다. 코드는 내가 아니다. 내가 작성한 것일 뿐이니까.