코드 리뷰는 작성자 이외의 사람이 코드를 검토하는 프로세스입니다. 주로 코드를 코드베이스에 반영하기 전에 수행합니다. 정의는 단순하지만 소프트웨어 업계에서 실행되는 모습은 매우 다채롭습니다. 

 

어떤 조직은 코드베이스 전체의 변경 검토를 전담하는 게이트키퍼 그룹을 두기도 합니다. 또 다른 조직은 몇 개의 작은 팀을 두어 팀별로 검토하는 수준을 달리 진행합니다. 구글에서는 모든 코드 변경을 커밋 전에 검토하도록 강제하는 동시에 리뷰 프로세스를 시작하고 변경을 검토할 책임을 모든 엔지니어에게 부과합니다. 

 

코드 리뷰는 ‘버그가 코드베이스로 침투하기 전에 잡아낸다’처럼 확실하고 쉽게 납득되는 이점을 제공합니다. 하지만 미묘한 이점들도 따라옵니다. 

 

LGTM 태그

코드 리뷰는 소프트웨어 개발 단계 곳곳에서 이루어질 수 있습니다. 구글에서는 변경을 코드베이스에 커밋하기 전에 수행합니다. 이 단계를 프리커밋 리뷰(커밋 직전 리뷰)라고 합니다. 

 

코드 리뷰의 최종 목표는 다른 엔지니어로부터 해당 변경을 적용해도 된다는 합의를 이끌어내는 것입니다. 합의한 엔지니어는 ‘좋아 보임(looks good to me)’이라는 뜻의 LGTM이라는 태그를 달아 의사를 표현합니다. 구글에서는 이 LGTM이 변경을 커밋하는 데 요구되는 필수 항목입니다.

 

구글은 코드 리뷰를 보통 다음 절차대로 진행합니다.

 

 

1. 작성자가 자신의 작업 공간에서 코드베이스에 적용할 변경사항을 작성합니다. 그런 다음 변경의 스냅샷을 만듭니다. 여기서 스냅샷이란 코드 리뷰 도구에 업로드할 코드 패치와 관련된 설명입니다. 이 변경으로 현재 코드베이스와의 diff를 떠서 코드가 어떻게 달라졌는지를 평가합니다.

 

2. 작성자는 초기 패치를 사용하여 자동 리뷰 의견을 받거나 스스로 리뷰를 해봅니다. 변경 내용이 만족스럽다면 한 명 이상의 리뷰어에게 메일을 보내 리뷰를 요청합니다. 메일을 받은 리뷰어들에게 스냅샷을 보고 리뷰 의견을 달라는 뜻입니다.

 

3. 리뷰어들은 코드 리뷰 도구에서 변경을 열고 해당 diff에 댓글로 의견을 남깁니다. 작성자에게 해결해야 할 문제를 던져주거나, 단순히 유용한 정보를 제공해주기도 합니다.

 

4. 작성자는 피드백을 기초로 변경을 수정하고 새로운 스냅샷을 업로드한 후 리뷰어들에게 회신합니다. 3~4단계는 여러 차례 반복될 수 있습니다.

 

5. 리뷰어들이 변경 내용에 모두 만족하면 LGTM 태그를 달아줍니다. 보통은 모든 리뷰어가 LGTM을 달아주는 게 관례지만 원칙적으로는 한 개만 얻어도 됩니다.

 

6. 변경에 LGTM이 달리고 모든 댓글을 해결하고 변경이 승인되면 작성자는 코드베이스에 커밋할 수 있습니다.

 

 

그리고 어떤 변경이든 ‘승인’을 얻으려면 세 가지 측면에서의 리뷰를 통과해야 합니다.

 

 

● 첫째, 다른 엔지니어로부터 정확성(correctness)과 이해 용이성(comprehension)을 평가받습니다. 즉, 작성자가 의도한 작업을 코드가 적절하게 수행하는지를 봅니다. 

 

● 둘째, 변경되는 코드 영역을 관리하는 코드 소유자로부터 변경 코드가 적절하다는 (그리고 특정 디렉터리에 체크인해도 좋다는) 승인을 받습니다. 구글의 코드베이스는 트리 구조로 되어 있고, 디렉터리별 소유자들이 계층적으로 할당되어 있습니다. 그리고 소유자는 자신이 맡은 디렉터리의 문지기 역할을 합니다. 변경은 아무 엔지니어나 제안할 수 있고 LGTM도 제안자 외의 모든 엔지니어가 달 수 있습니다. 하지만 코드베이스에 변경을 반영하려면 해당 디렉터리 소유자의 승인이 반드시 필요합니다. 

 

● 셋째, 누군가로부터 ‘가독성’ 승인을 받습니다. 즉, 변경 코드가 해당 언어의 스타일과 모범 사례를 잘 따르고 조직에서 기대하는 방식으로 작성되었는지를 검사받습니다. 

 

 

변경 하나 반영하기 위해 이렇게까지 통제하는 게 너무 과해 보일 수 있고, 때로는 과하게 느껴지기도 합니다. 하지만 대부분의 리뷰는 세 역할을 모두 수행할 수 있는 사람 한 명이 처리하기 때문에 이 절차들이 빠르게 진행됩니다. 

 

이러한 방식으로 코드 리뷰 프로세스는 상당히 유연하게 운영됩니다. 예를 들어 프로젝트의 소유자이자 해당 언어의 가독성 인증자인 테크 리드라면 LGTM을 평가해줄 엔지니어 한 명만 더 있으면 코드를 서브밋할 수 있습니다. 이런 권한이 없는 인턴사원도 가독성 인증을 받은 코드 소유자의 허가만 얻으면 서브밋할 수 있습니다. 세 가지 승인 조건은 어떤 형태로 조합되든 상관없습니다. 

 

한편, 작성자는 원한다면 변경에 태그를 달아서 리뷰어 모두로부터 LGTM을 받고 싶다고 요청할 수도 있습니다. 실제로 승인을 두 개 이상 얻어야 하는 코드 리뷰 대부분은 두 단계로 진행됩니다. 먼저 동료 엔지니어로부터 LGTM을 받고, 그다음으로 해당 코드 소유자와 가독성 인증자에게 승인을 요청합니다. 이 방식은 참여하는 두 역할의 사람들이 각기 다른 측면에 집중해 리뷰하도록 해주어 시간을 절약해줍니다. 

 

첫 번째 리뷰어인 동료 엔지니어는 코드가 정확한지와 변경된 코드가 유효한지에 집중합니다. 이어서 코드 소유자는 한 줄 한 줄 상세히 살펴보는 대신(이 일은 앞 단계에서 끝났으므로) 자신이 맡은 코드베이스에 적합한 변경인지에 집중합니다. 승인자는 동료 리뷰어와는 다른 관점에서 코드를 살펴보는 것입니다. 

 

소유자 입장에서는 누군가가 자신이 맡은 프로젝트/디렉터리에 코드를 밀어 넣으려 하는 것이므로 자연스럽게 다음과 같은 고민을 한번 더 하게 해주는 것이죠. ‘이 코드는 유지보수하기 쉬운가?’, ‘내게 기술 부채를 안겨주나?’, ‘우리 팀원 중에 이 코드를 유지보수해줄 전문가가 있나?’ 

 

세 가지 역할 모두를 한 사람이 처리할 수 있음에도 모든 코드 리뷰를 이런 사람들이 도맡아 수행하지 않는 이유는 무엇일까요? 바로 확장성 때문입니다. 역할을 셋으로 나눔으로써 코드 리뷰 프로세스가 더 유연해지는 것입니다. 

 

 

 

 

코드 리뷰 유형

코드 리뷰에도 여러 가지가 있습니다. 그리고 코드 리뷰 유형에 따라 리뷰 프로세스의 어느 측면에 더 집중해야 하는지가 달라집니다. 구글에서의 코드 변경은 보통 다음의 네 가지 분류에 속합니다(때로는 겹치기도 합니다).

 

● 그린필드 리뷰와 새로운 기능 개발

● 동작 변경, 개선, 최적화

● 버그 수정과 롤백

● 리팩터링과 대규모 변경

 

그린필드 코드 리뷰

그린필드 리뷰는 완전히 새로운 코드를 대상으로 하는 가장 드문 유형의 코드 리뷰입니다. 그린필드 리뷰는 대상 코드가 오랜 기간 존속될 수 있는지를 평가하기에 가장 중요한 기회입니다. 

 

코드는 시간이 흐르고 프로젝트 규모가 커져 초기에 내린 가정들이 변해도 여전히 유지보수하기 쉬워야 합니다. 코드는 부채입니다. 따라서 완전히 새로운 코드가 단순히 또 하나의 대안 제시에 머물러서는 안 됩니다. 실제 문제를 해결해주는 코드여야 하죠. 

 

구글에서는 보통 새로운 코드나 프로젝트에는 코드 리뷰와 별개로 설계 리뷰를 강도 높게 진행합니다. 따라서 코드 리뷰는 이미 결정된 설계에 관해서 왈가왈부하는 시간이 아닙니다(같은 이유에서 대안 설계를 제시하는 자리도 아닙니다).

 

코드가 지속 가능함을 보장하려면 API가 합의된 설계에 부합하고 테스트도 완벽히 이루어졌는지를 그린필드 리뷰에서 확인해야 합니다. 따라서 설계 문서도 함께 검토하기도 하고, 공개된 모든 API에 단위 테스트가 존재해야 하며, 이 테스트들은 코드의 가정이 달라지면 실패해야 합니다. 

 

또한 코드를 책임질 알맞은 소유자가 배정되어야 하고(그래서 새로운 프로젝트의 첫 번째 리뷰에서는 디렉터리에 OWNERS 파일이 제대로 존재하는지 확인합니다), 주석도 충분해야 하고, 필요하면 보충 문서도 제공해야 합니다. 프로젝트를 회사의 지속적 통합 시스템에 포함시킬지를 논의하기도 합니다.

 

동작 변경, 개선, 최적화

구글에서 이루어지는 대부분의 변경은 코드베이스 안의 기존 코드를 수정한다고 볼 수 있습니다. API 수정, 기존 구현 개선, 성능 최적화 등이 이루어지죠. 대부분 소프트웨어 엔지니어들에게 가장 필요한 변경들입니다.

 

이 경우에도 그린필드 리뷰의 지침이 그대로 적용됩니다. 꼭 필요한 변경인지, 코드베이스를 개선하는지를 살펴야 합니다. 가장 바람직한 변경의 멋진 예로 ‘삭제’를 많이 거론합니다. 죽은 코드나 낡은 코드 제거는 코드베이스를 전반적으로 건실하게 만드는 아주 멋진 방법입니다.

 

API의 동작을 수정할 때는 변경된 동작에 맞게 관련 테스트도 함께 수정해야 합니다. 동작 변경 없이 구현 방식만 개선한 경우라면 지속적 통합 시스템을 거쳐서 기존 테스트들이 모두 통과하는지 봐야 합니다. 

 

최적화 역시 기존 테스트들에 영향을 주지 말아야 하며, 추가로 성능 벤치마크 결과를 리뷰어에게 제시해야 할 것입니다. 그래서 최적화를 하려면 벤치마크 테스트를 미리 준비해두는 게 좋습니다.

 

버그 수정과 롤백

소프트웨어에는 버그가 있을 것이고 버그를 잡으려면 코드베이스를 변경해야 합니다. 이때 버그를 수정하면서 (기능 변경 등) 다른 문제까지 묶어 처리하고픈 마음을 꾹 눌러야 합니다. 

 

여러 주제가 섞이면 리뷰할 게 많아지는 건 둘째 치고, 회귀 테스트나 롤백을 훨씬 어렵게 만듭니다. 버그 수정은 온전히 그 버그를 잡는 데만 집중합시다. 물론 관련 테스트도 함께 수정하여 버그가 재발할 시 알려주도록 해야 합니다.

 

버그 수정 시 테스트도 보강해야 할 가능성이 큽니다. 버그가 새로 발견된 이유는 기존 테스트들이 충분하지 못했거나 특정 가정이 어긋났기 때문입니다. 관련 단위 테스트에 업데이트가 필요한지 확인해서 업데이트를 요청하는 것 역시 버그 수정 변경의 리뷰어가 챙겨야 할 중요한일입니다.

 

구글처럼 코드베이스가 거대하면 변경한 코드가 테스트들이 지금까지 잡아내지 못했거나 테스트되지 않은 코드를 사용해서 오류가 나는 일이 종종 생깁니다. 이럴 때 구글은 영향받은 다운스트림 고객들이 해당 변경을 롤백시킬 수 있게 합니다. 

 

롤백은 변경이 반영되기 전 상태로 코드를 되돌리도록 구성한 또 하나의 ‘변경’입니다. 잘 이용하던 상태로 돌아가는 것뿐이라 롤백 변경은 보통 수 초면 만들 수 있지만, 그래도 코드 리뷰는 필요합니다.

 

또한 잠재적으로 롤백을 유발할 수 있는 모든 변경은 가능한 한 작고 원자적이어야 합니다. 그래야 혹시라도 있을 롤백으로 인해 해당 코드를 사용하던 다른 모듈이나 프로젝트들이 망가지는 문제를 막을 수 있습니다. 이런 종류의 문제는 해결하기가 상당히 까다롭죠. 

 

구글은 조직이 매우 거대하고 거의 모든 코드를 모노리포에서 투명하게 관리하기 때문에 코드를 새로 추가하면 얼마 지나지 않아 누군가 이용하기 시작합니다. 따라서 롤백은 그 사이에 코드를 이용하기 시작한 엔지니어들의 작업에 지장을 주게 됩니다. 작은 변경은 원자적이라서, 또 빠르게 리뷰할 수 있어서 이런 피해를 줄여줍니다.

 

리팩터링과 대규모 변경

구글에서는 많은 변경이 자동으로 생성됩니다. 변경의 작성자가 사람이 아니라 기계라는 뜻입니다. 기계(도구)가 생성한 변경도 리뷰가 필요합니다. 위험성이 낮다고 생각되는 변경은 해당 코드에 관한 전권을 가진 리뷰어가 맡아서 처리합니다. 하지만 위험도가 높거나 도메인 전문가가 필요한 변경들은 다른 엔지니어들도 리뷰에 참여합니다.

 

일차적으로, 자동 생성된 변경이라도 리뷰어가 정확성과 적용 가능성을 확인합니다. 여느 코드 리뷰와 다르지 않습니다. 하지만 댓글을 다는 건 지양하라고 안내합니다. 또한 기반 도구나 변경들을 생성한 LSC(대규모 변경) 자체에는 신경 쓰지 말고 리뷰어 자신의 코드와 관련된 문제만 신경 쓰라고 안내합니다. 

 

검토하는 특정 변경은 기계가 만들었지만, 그 변경을 생성한 전체 과정은 이미 검토가 끝난 후라서 개별 팀이 전체 프로세스를 거부할 수는 없기 때문입니다. 이런 방식이 아니면 조직 차원의 대규모 변경을 수행할 수 없을 것입니다. 기반 도구나 프로세스에 대해 제기할 문제가 있는 리뷰어는 LSC 감독 그룹에 연락하여 자세한 정보를 얻을 수 있습니다.

 

또한 자동 변경의 리뷰어들에게 수정 범위를 확대하지 않기를 권합니다. 팀원이 작성한 변경을 리뷰할 때는 작성자에게 변경과 관련하여 추가적인 요청을 해도 이상하지 않을 때가 많습니다. 

 

변경을 작게 유지하라는 앞서의 조언에만 부합하면 됩니다. 하지만 도구가 자동 생성한 변경이라면 그 도구를 운영하는 엔지니어는 수백 개의 변경을 동시에 처리해야 할 수 있습니다. 따라서 댓글이나 질문이 단 몇 %의 변경에만 달리더라도 도구를 지속해서 개선하려는 의욕을 위축시킬 수 있습니다.

 

 

코드 리뷰는 엔지니어들을 이어주는 매개체이자, 테스트, 정적 분석, 지속적 통합 등 거의 모든 다른 프로세스가 엮여 있는 최우선 개발 워크플로입니다. 

 

코드 리뷰 프로세스는 확장이 매끄럽게 이루어져야 합니다. 따라서 작은 변경, 빠른 피드백과 반복 같은 모범 사례가 엄격히 지켜져야 합니다. 그래야 개발자의 만족도와 생산 속도가 유지됩니다.

 

 

---

 

이 글은 <구글 엔지니어는 이렇게 일한다> 도서 내용 일부를 발췌 편집하여 작성되었습니다. 구글러가 전하는 문화, 프로세스, 도구의 모든 것을 재미있게 풀어내며 출간과 동시에 국내외 많은 이들로부터 공감을 얻어낸 내용들을 만나보실 수 있습니다.   

 

『구글 엔지니어는 이렇게 일한다』