코드 리뷰에 ‘켄트 벡’의 아이디어 접목하기

<코드 리뷰가 개발 문화에 미치는 영향>이 발행된 바로 그날, 존경하는 프로그래머인 켄트 벡Kent Beck도 코드 리뷰에 대해 쓴 글 <Thinking About Code Review>을 발행했습니다. 우연이긴 했지만, 마침 코드 리뷰에 대한 글을 막 쓰고 난 참이라 제 글에 다루지 않았던 측면을 살펴 글로 추가하면 좋겠다는 생각이 들었습니다.

코드 리뷰가 팀 작업에 끼치는 영향

켄트 벡은 팀 작업에 코드 리뷰가 끼치는 효과를 다섯 가지 항목으로 제시합니다.

• 동작 오류 제거(Reduce behavioral errors)
• 구조 결함 제거(Reduce structural errors)
• 팀 이해도 향상(Improve team understanding)
• 학습 촉진(Accelerate learning)
• 팀 위험 제거(Reduce team risk)

명료한 정리란 생각이 들었습니다. 하지만, 코드 리뷰 경험이 부족한 분들 입장에서는 조금 더 풍부한 내용을 기대할 수도 있겠다고 생각했습니다.

코드 리뷰 피라미드 대입해보기

마침 작년에 <학습 피라미드와 코드 리뷰 피라미드 비교해보기>란 글을 쓰면서 인용했던 코드 리뷰 피라미드가 떠올랐습니다. 이 코드 리뷰 피라미드와 켄트 벡이 제시한 항목을 함께 살펴본다면 더 풍부한 접근을 할 수 있을 것 같았습니다.

그래서 저는 ‘코드 리뷰 피라미드’를 구성하는 다섯 개의 계층에 더하여 켄트 벡이 제시한 항목을 둘로 구분하여 2차원 표를 만들어 보았습니다.

굳이 표를 다 채우지 않아도 영역별로 얻을 수 있는 효과를 짐작해 볼 수 있는 점검표 역할을 할 수 있겠다는 생각이 들었습니다. 예를 들어 다음과 같은 대화 기록은 ‘문서화’에 대해서 ‘팀 이해도와 학습 촉진’ 영역에 해당하는 코드 리뷰 활동의 결과로 볼 수 있습니다. 이런 식으로 코드 리뷰의 대상과 효과를 연결해 볼 수 있습니다.

코드 리뷰의 경제성

한편, 켄트 벡의 글에 굉장히 흥미로운 도식이 등장합니다. 악순환을 표현한 그림이죠.

흔히 깃Git과 같은 소스코드 관리 환경에서 PR(Pull Request) 등의 절차를 통해 코드를 통합합니다. 개발 조직마다 실제 수행 방법이야 다를 수 있겠지만, 보통 PR 발생 시점이 코드 리뷰의 수행 시점이기 되기도 합니다. PR 크기가 커진다는 말은 한 번에 검토해야 할 코드의 양이 많다는 말입니다. 그렇게 되면 자연스럽게 지연이 발생하고 팀 전체의 출시 속도를 늦출 수 있습니다.

여기서 출시 속도의 중요성을 강조하고 싶습니다. 소프트웨어의 빠른 출시는 현대 비즈니스 환경에서 개발팀의 가장 중요한 경쟁력입니다. 이를 받아들이고 나서 다시 위의 그림을 보면 한 가지 중요한 단서를 얻을 수 있습니다. PR 크기를 줄일 수 있다면 혹은 PR 크기가 큰 일이나 개발자의 문제를 팀이 이해하게 되면 지연을 줄이고 팀의 출시 속도를 늘릴 수 있는 기회가 생긴다는 것입니다.

PR 크기와 케이던스

여기서 흥미로운 우연을 하나 더 소개합니다. 켄트 벡의 글을 읽지도 않은 우리 회사 동료가 다음과 같은 업무를 등록했습니다.

동료가 사용한 케이던스(cadence)라는 말은 ‘개발을 해나가는 리듬감’을 표현하기 위해 쓰는 말인데, 우리 팀에서 제가 가끔 차용하는 SAFe라는 프레임워크에서 소개된 용어입니다. 이 업무를 배경으로 동료가 설명한 바에 따르면 너무 띄엄띄엄 PR을 올리면 개발자들의 성장에도 큰 도움이 되지 않는다고 합니다. 제 짐작으로는 띄엄띄엄 PR을 올리면 코드 리뷰하는 맛(?)도 안날 듯합니다.

지난번 제 글인 <코드 리뷰가 개발 문화에 미치는 영향>에서도 ‘일상의 반복에서 벌어지는 다자간 소통’의 중요성에 대해 썼습니다. 문화적인 측면을 강조한 글이기도 하지만, 소통의 반복이 되려면 서로가 하는 일에 대해 스스로 개방하고 관심을 두는 일이 가능해야 합니다. 그렇게 할 수 있다면 어려운 문제를 혼자 싸매고 고민하는 상황을 해소할 가능성이 높아집니다. 반면에 PR 크기가 크다는 말은 일을 나눌 수 없어 혼자 고심하는 상황으로 묘사할 수도 있다고 봅니다.

그렇게 가정하면 동료는 PR을 자주 올리지 못하는 개발자들이 더 작은 PR을 만들 수 있도록 돕겠다는 제안을 한 것입니다. 그래서, 함께 일하는 케이던스 즉, 팀의 ‘케미’가 느껴지는 스포츠 같은 업무 상황을 연출하는 시도를 하고 있다고 말할 수도 있습니다. ‘협업 방식’이라고 말할 수도 있겠으나 ‘리듬’이나 ‘케미’는 실제로 생산성에 미치는 긍정적인 영향은 물론 일하는 순간 자체에 몰입의 즐거움을 선사하고 우리가 연결되어 있다는 전혀 다른 종류의 만족감도 선사할 수 있습니다.

코드 리뷰를 보는 네 개의 차원

켄트 벡은 또한 코드 리뷰 수행 방식을 기준으로 네 개의 차원을 구분했습니다.

켄트 벡이 말하는 블로킹Blocking은 실제 구동 시스템(production)에 배포할 때, 코드 리뷰가 제약으로 작용하는지를 말하는 듯합니다. 블로킹과 관련해 이런 문장을 덧붙이고 있기 때문입니다. “Can the change go to production without a review?”

다시 표를 보면 실제 구동 시스템 배포 전에 코드 리뷰를 강제하는 환경이라면 필수 선택지는 두 개가 있습니다. 한 화면을 보며 코드 리뷰를 하는 짝 프로그래밍(Pairing)을 하거나 원격에서 PR을 하는 방법 중에 선택할 수 있습니다. 동기(Sync)와 비동기(Async)가 이를 구분하는 표현이죠. 

이와 다르게 블로킹Blocking이 없는 상황에서도 코드 리뷰가 있습니다. 이는 무엇을 뜻하는 것일까요? PR을 강제화하지 못하는 상황에서 하는 코드 리뷰를 생각해 볼 수 있습니다. 그리고, PR과 무관하게 코드 리뷰를 할 수도 있죠.

각자가 놓인 상황을 점검해보고, 그에 따라 효과적인 방법을 선택하길 바랍니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.