Code Review를 Review해 보자! – <A Story about…/>

1 프롤로그(Prologue)

Code Review가 좋다는 것은 많은 사람들이 동의 하는 명제입니다. 막연하게 Code Review는 해야 할 것 같다는 생각이 들기도 합니다. 그렇지만 때로는 바쁜 개발 일정때문에 Code Review가 걸림돌처럼 느껴지기도 합니다. 이번 포스팅에서는 바쁜 일정속에도 Code Review를 잘하기 위해서 필요한 것들과 어떤 상황/행동이 Code Review를 방해하는지 알아 보겠습니다. 그리고 마지막으로 Code Review에 영향을 미치는 요인의 영향도를 분석해 보겠습니다.

이번 포스팅은 객관적 자료를 기반으로 써보려고 합니다. 전체 내용을 Code Review에 대한 2개의 논문을 바탕으로 작성하였습니다. Code Review에 대한 많은 이야기와 소재가 있지만 논문을 통해서 Code Review의 가치를 확인한다면 더욱 깊이 있는 이해와 높은 동기 부여가 되지 않을까 생각합니다. 참고한 논문은 아래와 같습니다.

[1] C. Sadowski, E. Söderberg, L. Church, M. Sipko, and A. Bacchelli, “Modern code review: A case study at google,” in Proceedings - International Conference on Software Engineering, May 2018, pp. 181–190, doi: 10.1145/3183519.3183525.
[2] E. W. dos Santos and I. Nunes, “Investigating the effectiveness of peer code review in distributed software development based on objective and subjective data,” J. Softw. Eng. Res. Dev., vol. 6, no. 1, p. 14, Dec. 2018, doi: 10.1186/s40411-018-0058-0.
[3] Peter C Ridby and Christian Bird. 2013 Convergent software peer review practices. In FSE.

2 Code Review는 어떻게 진행 되는가?

2.1 현대(Modern) Code Review는 어떤 특징을 가지고 있는가?

처음으로 이야기할 주제는 구글에서 발표한 논문[1]에서 발췌하였습니다. 이 논문에서는 Rigby와 Bird의 연구[3]를 인용하여 현대 Code Reivew의 특징을 5가지로 규정하였습니다.

ID	convergent practice
CP₁	가볍고 유연한 프로세스를 따른다.
CP₂	신속하고 자주 이루어 진다.
CP₃	리뷰를 진행해야 할 변경 단위가 작다.
CP₄	두 명의 리뷰어가 최적의 결함을 찾을 수 있다.
CP₅	결함 찾기에서 그룹 문제 해결로 변화 되었다.

CP₁~CP₄는 우리가 이미 많이 들어 왔고, 실행하고 있는 부분입니다. 하지만 CP₅는 조금 낯설은 내용입니다. 이 내용은 바로 이전 포스팅에서 언급했던 내용이기도 합니다. 참고: Code Review란 무엇인가?

Code Review는 개발자가 작성한 Code에 대해서 작성자의 잘못을 여러 Reviewer가 발견하는 것이 목적이 아니라, Review에 참여한 사람들이 Code에 대해서 함께 논의 하고 Review한 Code를 공동 책임을 지는 과정이다.

Code Review 활동은 결함 발견, 코드 학습을 위한 도구인 동시에 구성원들이 함께 문제를 해결해 나가는 과정인 것입니다. 이것이 바로 현대 Code Review가 가지고 있는 힘이자 의미인 것이죠. 이전 포스팅에서 이야기 한 것처럼 Code Review에서 가장 중요하게 기억해야 하는 개념이자 철학입니다. Code Review가 조직의 문화로 뿌리 내리기 위해서는 누군가의 Source Code를 검증하기 위한 절차가 아닌 여러 이해 당사자가 참여해서 문제를 해결해나가는 공통의 작업이라는 인식의 변화가 반드시 필요합니다.

CP₁~CP₄에 대해서는 Code Review를 빠르게 수행하기 위해 필요한 조건들에 대해서 알아 보는 글 뒷쪽에서 자세히 설명하도록 하겠습니다.

2.2 Code Review는 어떤 동기로 수행이 되는가?

해당 논문[1] 에서는 Code Review를 진행하는 각 구성원들이 어떤 동기로 Code Review를 수행 하는지를 조사하였습니다. 일부 회사의 조시일지도 모르지만 그 내용이나 방향성은 한 회사의 결과라고 단정짓기에는 꽤나 의미가 있는 것 같습니다. 아래 그림은 Code Review를 수행하는 각 구성원들의 Code Review 동기를 개발자를 중심에 두고 그린 그림입니다. 개인적으로 눈여겨서 보아야 할 부분은 프로젝트 개발에 직접참여하는 개발자뿐 아니라 프로젝트 리더와 다른팀이 Code Review에 참여하고 각각이 다른 동기와 시선으로 참여 한다는 점입니다. Code Reivew가 일정이 바쁘다고 형식적으로 진행되어서는 안된다는 것을 간접적으로 알려 주는 내용이기도 합니다.

그림에서 나오는 각 구성원들의 동기를 표에 정리 해 보았습니다.

동기	의미
*Education*	Code Review를 통해 과제의 지식이 전수되거나 전달 받을 수 있음
*Maintaining norms*	유지보수 편의을 위한 Code 작성 규칙, API 규약, Design Pattern 등의 준수
*Gatekeeping*	Code 혹은 설계의 범위가 지정된 범위를 넘어서는지 여부 체크
*Accident prevention*	Bug, Defect 또는 품질 문제에 대한 예방

Education은 Code Review를 통해서 얻을 수 있다고 널리 알려진 내용이고, Maintaining norms는 이전 포스팅에서도 언급된 내용입니다. Other teams의 Gatekeeping은 조금 새로운 개념입니다. 또한 다른 팀 멤버의 동기 중 Accident prevention도 의아합니다. 팀내에서 버그를 찾아야 하는것이 아닌가요? 그리고 팀내 버그 찾기 등은 Unit Test, Test 자동화 등으로 기계적으로도 많이 해결을 할 수 있습니다. 어떤 의미 일까요? 두가지 동기에 대해서 풀어서 설명해 보도록 하겠습니다.

Gatekeeping은 팀의 업무 범위를 하나의 모듈, 서비스로 두고 SOLID 원칙 중 SRP(단일 책임 원칙, Single Responsibility Priciple) 준수 여부를 확인 하는 것입니다. 즉, 의도한 기능을 벗어난 기능을 하고 있지는 않은지를 살펴 보는 것이죠. 일의 범위를 침범하는 것을 감시 한다기 보다는 중복된 기능 개발을 방지하고 필요시 모듈을 재사용할 수 있게도 만들 수 있습니다.

Accident prevention은 팀내 모듈에서 발생하는 오류가 아닌 다른 모듈이나 서비스와의 충돌, 팀내에서 파악하지 못한 파급효과/부작용을 검토 하는 것입니다. 팀내 Reviewer들은 알지 못하는 모듈 서비스와의 충돌을 검토 하는 것입니다.

구글의 Code Review는 직원 ‘E’에 의해서 시작되었다고 합니다. 처음에는 Education이 가장 중요한 목적이었다고 합니다. Education을 통해서 팀에 합류한 신규 멤버의 빠른 Catchup과 팀의 높은 효율을 기대한 것이라고 합니다. 하지만 지금은 위에서 살펴 본것 처럼 다양한 구성원이 각자의 동기를 가지고 그것을 실현하는 방법으로 정착된 것입니다. 단순히 Code를 검사하고 문제점을 없애는 것에 목적이 있지 않다는 것이 Code Review를 새롭게 되돌아 볼 수 있는 새로운 시선인 것 같습니다.

3 어떤 것들이 Code Review에 영향을 미치는가?

code Review는 종종 좋은 의도와는 다르게 감정싸움이 되거나 불필요한 논쟁으로 확산되기도 합니다. Code Review 과정에서 어떤 것들이 문제가 될까요? 다음 다섯 가지가 Code Review 진행시 발생되는 문제의 원인이라고 합니다.

Distance, Social interactions, Review subject, Context, Customization

3.1 Distance

거리는 물리적 거리와 조직적 거리가 있습니다. 물리적 거리의 기준이 얼마인지는 딱히 나와 있지는 않지만 다른 층 혹은 다른 건물, 대륙이 멀리 떨어진 경우 등을 말하는 것입니다. 조직적 거리는 협업의 정도를 말하는 것입니다. 거리의 문제는 Review 처리 시간 지연 및 문제의 잘못된 이해의 원인이 됩니다. 최근에는 다양한 커뮤니케이션 채널의 발달로 물리적 거리에 따른 문제는 많이 해결이 된 것 같습니다. Distance라는 원인은 바꾸어 말하면 커뮤니케이션이의 양과 질이 Code Review에서 질과 직결되어 있다고 할 수 있습니다.

Review 진행시 어투(Tone)와 강한 의도(Power)도 문제가 됩니다. 어투에 의한 문제나 오해는 커뮤니케이션에서 흔히 발견됩니다. 문제점에 대한 토의가 아닌 잘못의 지적처럼 인식이 되면 Reviewee가 방어적이 되고 Review 진행이 어려워지는 경우가 많습니다.

강한 의도(Power)는 잘 통용되지 않는 개념이라서 논문 문구를 직접 인용하도록 하겠습니다.

Power refers to using the code review process to induce another person to change their behavior; for example, dragging out reviews or withholding approvals. [1]

강한 의도(Power)는 어떤 의도를 가지고 특정 개발 방향/성향/습성으로 개발자를 이끄는 것이라고 되어 있습니다. 잦은 Review reject 혹은 의도적인 지연등이 강한 의도(Power)에 의한 조치라고 할 수 있습니다. 어투 문제는 쉽게 인지 할 수 있지만 강한 의도는 제3자의 입장에서는 좋은 리뷰로 생각될 수 있기 때문에 반드시 주의해야 합니다. 좋은 Code Review는 Code Owner를 좋은 방향으로 유도하는 것이지 Reviewer의 취향이나 버릇을 강요하는 것이 아닙니다. 하지만 어떤 Review가 선한 의도를 가지고 있고 어떤 Review가 강한 의도를 가지고 있는 것일까요? 구별이 매우 어려울 것 같습니다. 그래서 강한 의도를 방지하기 위해서는 Code Review 원칙을 정하고 그 원칙에 대한 구성원 전체의 공감대가 형성이 되어야 합니다. 함께 일하는 구성원들과의 Code Review 원칙에 Design Pattern 사용이 높은 우선순위에 있다면 아무리 바쁘더라도 Design Pattern 적용을 Guide 하는 것이 좋은 Code Review입니다. 하지만 그렇지 않은 상황에서 Design Pattern 사용을 Code Review에서 특정인에게 혹은 특정인이 유독 강요나 강조하는 것은 좋은 Code Review가 아닙니다. 만약 새로운 원칙이 필요하다면 Code Review를 진행 하기 전에 충분한 대화나 정리된 문서를 통해 필요성을 설득한 후 진행이 되어야 할 것입니다.

3.3 Review subject

각 Code Commit은 구현 하려고하는 내용이 다릅니다. 그렇기 때문에 구현 목적에 적합한 리뷰가 되어야 합니다. 예를 들면 Test Code를 작성하는 PR에서 해당 모듈의 Design 방향성에 대해서 논의 하게 되면 PR의 의도와 맞지 않을 뿐더러 리뷰 지연이 발행할 수 있습니다. 손이 달을 가리키고 있는데 손 모양을 지적해서는 안되겠죠.

PR Description에 개발 Scope을 명시 하는 방법등을 사용하여 개발 의도가 잘 전달 될 수 있도록 해야 하고 Reviewer는 개발 의도에 적합한 Review를 진행해야 합니다.

이 문제는 구현 의도 파악이 안되어 발생하기도 하지만 작성자와 리뷰자의 개발 철학이 달라 발생하기도 합니다. 개발 철학이 너무나 상이한 두 사람간의 리뷰는 지연, 어투 문제, 강한 의도가 발생될 수 있습니다. Code Review는 자기의 주장을 관철시키는 것이 아닌 공동의 문제 해결이라는 명제를 상기하여 서로에 대한 이해와 배려가 반드시 필요합니다.

3.4 Context

Context는 Review subject와도 연관되어 있습니다. ‘시스템에 심각한 영향을 주는 버그를 수정한 Patch’와 ‘있으면 좋을 기능의 추가’는 긴급도와 중요도가 다릅니다. 하지만 Context를 이해하지 못한채 Review가 진행이 되면 문제가 발생할 수 있습니다. 긴급하다고 내용을 살피지 않은채 LGTM으로 마무리 하라는 것이 아닙니다. 리뷰의 우선순위를 높여 빠르게 진행해야 하고, 중요도에 따라 Review의 강도를 조절해야 할 것입니다. Context와 관련하여 뱅크샐러드의 기술 블로그의 아래 포스팅이 좋은 예시가 될 것입니다.

https://blog.banksalad.com/tech/banksalad-code-review-culture/

3.5 Customization

마지막 ‘사용자 정의’는 앞서 소개한 4가지와는 조금 결이 다릅니다. 앞쪽 네가지가 구성원 간 발생할 수 있는 문제의 원인 이었다면 Customization은 시스템의 문제입니다. Code Review 자동화는 GitHub등 Plug-in을 지원하는 형상 관리 시스템에 적용이 가능합니다. 본인이 속한 조직에 100%적합한 Review 자동화 시스템은 없을 것입니다. 그렇기 때문에 적절한 Customization이 필요합니다. 만약, 적절한 Customization 없이 맹목적으로 적용을 한다면 자동화 중 일부가 문제를 발생시켜 여러분의 Code Review에 심각한 문제가 될 수 있습니다.

4 어떻게 해야 Code Review를 빠르게 할 수 있는가?

이번에는 E. W. dos Santos와 I. Nunes의 논문인 “Investigating the effectiveness of peer code review in distributed software development based on objective and subjective data,”를 살펴 보겠습니다. 인용된 도표는 모두 CC BY 4.0 라이선스로 수정없이 논문의 내용을 그대로 인용하였습니다. Open Access 링크는 다음과 같습니다.

https://jserd.springeropen.com/articles/10.1186/s40411-018-0058-0

두번째 논문에서는 code Review에서 측정 가능한 몇가지 Metric과 Code Review의 효율성에 대해서 분석하였습니다. Code Review에 영향을 미치는 요인 네가지와 각각의 요인에 영향을 받는 네가지 수치의 상관 관계를 분석하였습니다. 영향을 주는 요인과 영향을 받는 수치는 아래 테이블과 같습니다.

영향을 주는 요인	의미
Patch Size (LOC)	PR, Commit에 포함된 수정 Code Line
Teams	Code Review 참여 팀 숫자
Locations	참여자간 거리, 동일층 근무를 1로 표기함
Active Reviewers	Review 요청 받은 Reviewer중 실제 Review 활동을 진행한 숫자

영향을 받는 수치	의미
Duration (DUR)	Code Review를 시작해서 완료할 때까지 소요된 일수(Day)
Participation (PART)	요청 받은 Reviewer들의 Review 참여 비율
Comment Density (CDG)	100 LOC당 Review Comment 숫자
Comment Density by Reviewer (CDR)	CDG를 실제 참여한 Reviewer 숫자로 나눈 수치

CDR은 Reviewer 숫자가 많아질 경우 CDG 수치가 왜곡되는 것을 방지하기 위해 만들어진 수치 입니다.

4.1 Patch Size (LOC)

Commit에 들어가 있는 Code의 크기가 커질 수록 안 좋은 수치에 부정적인 영향을 줍니다. 완료 시간(DUR)은 늘어 났으며, 참여율(PART)도 저조합니다. CDG, CDR 모두 줄어 든것을 확인할 수 있습니다. 하나의 Commit/PR 등 리뷰를 진행하는 단위의 크기가 커질 수록 Review 진행에 많은 문제를 내포하게 됩니다. 분석의 결론을 한마디로 요약한다면 아래와 같습니다.

‘Code Review 진행 시 Review 단위가 되는 Commit 혹은 PR등은 적은 LOC로 진행하는 것이 좋다.‘

4.2 Teams

참여 팀의 숫자가 많아 질 수록 DUR이 늘어 납니다. CDG, CDR은 2~3개 팀에서 가장 높은 것을 알 수 있습니다. 결과를 요약하면 아래 문장으로 표현할 수 있습니다.

‘많은 의견 교환이 이루어지기 위해서는 2~3개 팀이 참여하여 Code Review를 진행하는 것이 좋다.‘

4.3 Locations

거리에 따른 Code Review의 영향은 결과가 해석하기 어렵네요. 예상한 것처럼 거리가 멀면 DUR이 늘어납니다. PART가 조금 줄어 들었지만 중앙값에는 큰 차이가 없습니다. 반면 CDG, CDR은 상승하는 것을 볼 수 있습니다.

4.4 Active Reviewers

Active Reviewer의 숫자가 많아 질 수록 DUR이 증가 합니다. CDR의 결과를 보시면 흥미로운 점이 보입니다. 2명의 경우 가장 높은 CDR을 보여주고 있습니다. 많은 Code Review Guide가 2명이상이 Code Reviewer수를 요구 하는 것도 비슷한 이유가 아닐까 생각해 봅니다. Teams와 동일한 결과를 확인할 수 있습니다.

5 마치며

Code Review가 좋은 것인지는 알고 있지만, 어떻게 해야 하고 왜 그렇게 해야 하는지 막연한 경우가 많을 것이라고 생각합니다. 이번 포스팅에서 살펴본 논문 세가지를 통해서 이 질문에 대한 해답을 찾을 수 있길 바랍니다.

※ 본문에 사용된 이미지는 모두 https://pixabay.com/을 통해서 다운로드 받은 무료로 사용할 수 있는 이미지입니다.