안녕하세요. 린치핀소프트 한광희입니다.

“코드 리뷰(Code Review) 는 더 좋은 소프트웨어 품질과 조직에 기여 할까요?”

 

소프트웨어 개발을 주업으로 하는 개발사, 외주용역 개발 또는 수주 개발을 하는 회사에서 근무하는 개발자나 PM의 경우 아마 한번쯤은 이런 고민들을 해보셨을 거라고 생각합니다.

개발사에게는 한정된 개발일정속에서 “코드리뷰(Code Review)”에 대한 일정을 어느 정도의 빈도와 시간을 할애하여 투자해야 할지도 쉽게 판단 내리기 어려운 부분이기도 합니다.  빠듯한 프로젝트 개발일정속에서 소프트웨어 개발을 위한 시간과 “코드 리뷰”를 하는 시간이 대립될수 있기 때문입니다.

코드리뷰의 양과 절차, 수준에 따라 다르지만 제 경험상 짧은 코드리뷰는 몇 분 정도 팀원들이 집중해서 논의해도 되는 정도이지만,  많은 양의 코드리뷰가 필요한 경우에는  하루에 6-7시간씩 2-3일에 걸쳐 코드리뷰를 진행한 적도 있었습니다.

즉, “코드리뷰”는 생각보다 조직적으로 많은 자원이 필요로 하는 활동인 것이지요. 그렇기 때문에 개발사의 각 회사의 문화에 따라 “코드 리뷰”를 어떻게 바라보는가에 따라 프로젝트 진행 및 SW 개발에 있어서 코드리뷰시간을 천차만별로 배분하고 있지 않을까 싶습니다.

제 생각에 “코드 리뷰”는 어느 정도 이상의 규모 있는 소프트웨어 개발 또는 난이도 있는 기능적 구현이 있는 소프트웨어 개발 프로젝트라면 꼭 시간을 할당해야 한다고 믿습니다. 그렇지만 이런 코드리뷰 시간을 할당해서 잘 진행하는 것도 사실 쉽지는 않습니다. 자신의 코드를 전 구성원에게 납득시키고 각 구성원들이 열린 마음으로 해당 소스 코드에 대한 비판과 수용(지지)을 해주는 문화가 기반이 되어야 올바른 코드리뷰 시간이 진행된다고 생각합니다.(코드리뷰는 상대방에 대한 코드에 대한 비판의 시간도 되겠지만, 코드에 대한 이해와 수용 그리고 지지의 시간이기도 하다고 생각합니다)

그래서 이런 문화는 각 회사의 개발자 문화, PM이 코드리뷰를 얼마나 중요시 생각하는지에 따라서도 코드리뷰에 따른 성과를 달성해 낼 수 있다고 봅니다.

저희 린치핀소프트 팀 역시도 소프트웨어 개발과 병행하여 여러 차례 코드리뷰 시간을 가지려고 노력하며 소프트웨어 개발에 대해서 넓은 시야와 정보, 비판을 공유하고자 노력합니다. 앞으로도 이 “코드 리뷰(Code Review)” 시간을 사내 문화로 확고히 정착시켜 더 원활하고 많은 소통과 비판 그리고 서로에 대한 지지가 공존하는 개발문화로 나아가고자 하는 것이 저희 린치핀소프트의 미래상이자 현재진행형입니다.

여러 차례 코드리뷰를 진행해보며 제가 깨달은 몇 가지 노하우(?)가 있습니다.

1.코드리뷰는 어쩌다 마음 먹고 시행하는 이벤트(?)가 아닌 상시적인 활동이다. 이 상시적인 활동인 코드리뷰와 맞닿아 있는 개발 문화 중에 하나로 소스코드에 “주석”을 구체적으로 기입하는 것이다.

2.코드리뷰에서는 프로그래밍 응용이나 테크닉보다는 “논리적”으로 올바른 방향과 철학으로 구현하고 있는가? 를 기준의 큰 줄기로 논의가 나아가야 한다.

3.코드에 대한 비판과 지지가 존재해야 한다. “비판” 또는 “지지”가 없는 감상적인 또는 정보전달의 코드리뷰는 의미가 없다.

4.코드리뷰를 통해 개발자(프로그래머)는 자신이 구현한 소스코드를 공개적으로 팀원들에게 이해시키고 설득해야 하며, 청중(팀원)은 열린 마음과 이해하겠다는 열정이 있어야 한다.

5.코드리뷰를 주관하는 프로젝트 매니저나 발표 담당자는 즉흥적으로 발표(소개) 하지 말아야 하며 최소한 1-2 차례의 전체적인 리허설(약식으로라도)과 코드리뷰의 흐름과 개요안을 생각해두어야 한다.

 

몇 차례의 코드리뷰를 통해 성공적인 코드 리뷰를 위해서는 최소한 위와같은 절차가 팀 내에서 있어야 한다는 생각이 많이 들었습니다. 특히나 코드리뷰 당일이나 직전에 코드리뷰 시간을 위해 준비하는 작업은 평소 프로그래밍 할때 소스코드에 “주석”을 많이 기입해 두면 준비 시간을 줄일 수 있습니다. 더 나아가 코드리뷰를 같이 진행하는 청중(팀원)도 코드리뷰 전에 해당 소소코드를 주석과 같이 먼저 살펴볼 수 있어 더 효과적으로 진행할 수 있게 됩니다.

 

코드리뷰는 앞서 설명한 것처럼 개발자의 조직문화에 많이 좌우되는 편이지만, 소프트웨어 개발사 전체에 적지 않은 이익과 도움을 준다고 생각합니다.