글로벌기업은 코드 리뷰를 어떻게 할까요?

코로나 사태가 길어지면서 비대면 원격 업무 방식으로 일하는 것이 더 이상 특이한 업무 형태가 아닌 것으로 여겨지는 것 같습니다. 불편하고 어려웠던 화상회의도 점차 일반적인 업무 수단이 되어가고요. 코드 리뷰도 처음엔 어색하지만 여러분들에게 꼭 맞는 맞춤옷처럼 없어서는 안 될 업무 도구가 되었으면 좋겠습니다. 오늘은 국내외 기업들이 코드 리뷰를 어떻게 활용하고 있는지 여러 사례를 알아보겠습니다.

   

100% 코드 리뷰, 모든 코드를 리뷰하는 Google

Google은 코드 리뷰 개발자 가이드(https://google.github.io/eng-practices/review/)를 통해 코딩 스타일을 비롯한 주요 원칙을 공개하고 있습니다. Google이라면 왠지 자유롭게 코드 리뷰를 하도록 할 것 같지만, 표준과 프로세스, 정책을 엄격히 적용하고 있죠.

코드 리뷰 가이드에는 ‘코드가 잘 설계되고, 시스템에 적합한가? (설계)’, ‘코드는 설계자의 의도대로 동작하는가? (기능)’, ‘자동화된 테스트가 적용되어 있는가? (테스트)’ 등의 필수 검토사항들까지 상세히 적혀 있습니다. 특히, 코드 리뷰의 진행 속도는 개발 생산성에 중대한 영향을 미치며, 코드 리뷰도 이에 따라 신속히 이뤄져야 한다는 점도 강조하고 있죠. Google은 코드 리뷰가 요청되고 나서 1영업일 이내에 반드시 코드 리뷰가 완료되어야 하는 것을 원칙으로 합니다. (심지어 다음 날 아침 최우선 업무로 이것을 처리해야 한다고 규정합니다.) 왜냐하면 코드 리뷰가 늦어지면 팀 전체의 개발 일정이 문제가 될 정도로 코드 리뷰를 100% 강제하고 있기 때문입니다. Google의 코드 리뷰는 작은 변경은 1시간 이내, 규모가 큰 변경사항은 5시간 이내 검토가 완료됩니다. 평균적으로 4시간 이내에 완료된다고 하니 놀랍죠? (대기업의 경우 평균적으로 15시간 이상이 소요되는데 말이죠.)

더 놀라운 것은 Google의 코드 리뷰의 90%는 10개 미만의 파일로 구성되어 있고, 리뷰의 75%는 리뷰어가 한 명뿐입니다. 변경 요구사항(Change List; CL)의 규모가 크고, 코드 리뷰 대상이 크면 클수록 코드 리뷰 시간은 길어지기 마련입니다. 그래서, Google에서는 변경사항의 전체를 조망해 보고, 주요 부분을 작게 나누어 리뷰할 수 있도록 CL을 여러 개의 CL로 분할한 다음 적절한 순서로 살펴보도록 권장하고 있죠.

    Code Revies at Google. Every Code Change is Reviewed - 75% of the code reviews are approved by only one reviewer. Company-wide Approval Criteria - Approver needs ownership rights and readability certificate. 4 Hours to Review Completion - Small reviews are completed within one hour. Large reviews within five hours. Small and Frequent Reviews - 90% of all code changes comprise less than 10 files and 24 lines of code.     작게 나누어 신속히 처리되는 Google의 코드 리뷰 문화(출처: michaelagriler.com)

Google은 Tricorder라는 정적 분석(잠재결함 분석) 도구와 Rosie라는 코드 정리 시스템(Large-Scale Cleanups and Code Changes)을 활용해 사용하지 않는 코드는 없애고, 리팩토링(Refactoring)이 필요한 경우에는 수정된 코드를 개발자들에게 리뷰 요청하는 것으로 알려져 있어요. 이렇게 자동화된 코드 리뷰와 분석이 필요한 이유는 Google의 서비스 소스코드가 20억 라인(2015년 기준)이 넘는 단일 코드로 되어 있고, 매주 1,500만 라인 이상의 수정이 이뤄지고 있기 때문이라고 합니다. 내부 코드의 경우, 최근에는 Critique이라는 도구를 사용하는데, 자세한 기능은 알려지지 않았지만 널리 사용되고 있는 것 같습니다.

더 자세한 내용이 궁금하신 분들은 아래 글을 참고해서 읽어보시면 도움이 될 것입니다.
Code Reviews at Google are lightweight and fast (https://www.michaelagreiler.com/code-reviews-at-google/)

개발자 업무는 개발 50%, 리뷰 50%인 Microsoft

Microsoft의 개발자라면 매일 코드 리뷰를 해야 합니다. Microsoft의 전체 직원 수는 14만 명이고, 이중 44%인 6만 명에 이르는 개발자의 75%가 매일 코드 리뷰를 하고 있다고 알려져 있죠. Windows와 Office 등의 글로벌 소프트웨어가 단일 상품으로 운영되고 있기 때문에, 당연히 공동 개발을 위한 코드 품질 확보를 위해서는 코드 리뷰가 필수적이기 때문입니다. Microsoft의 시장점유율이 높은 만큼, 잘못된 업데이트 하나, 변경사항 하나가 전 세계 모든 기업의 업무에 마비를 가져올 수도 있다는 것을 감안해야 하겠죠. Microsoft 개발자의 13% 정도만이 코드 리뷰를 하지 않았고, 나머지 개발자들은 전부 코드 리뷰를 진행했다고 합니다.

        Microsoft는 얼마나 자주 코드 리뷰를 할까요? (출처: michaelagriler.com)

다른 회사들처럼, Microsoft도 자동화된 코드 리뷰 도구인 Codeflow를 통해서 코드 리뷰를 진행해 왔습니다. 다만, Microsoft에서는 팀별로 자유롭게 자동화된 검토 도구를 활용할 수 있고, 프로세스도 자율적으로 구성할 수 있다는 점이 다르죠. VSCode의 여러 코드 리뷰 플러그인과 GitHub, Visual Studio Teams Service를 활용하는 등 다양한 방법을 선택할 수 있습니다. 최근에는 Microsoft에서 GitHub를 인수했기 때문에, Git에 대한 활용이 광범위하게 확대되고 있다고 해요. 또한 Microsoft에서는 개발자들 간에 코드 리뷰의 코멘트를 명확히 이해하고 전달할 수 있도록 이모지(Emoji)를 활용하기도 합니다. 이모지를 통해서 텍스트만으로 전달하면서 발생할 수 있는 감정적인 싸움이나 소모를 예방하기도 하죠. 이를 통해서 코드 리뷰를 하는 상대방에 대한 배려를 잊지 않도록 역할을 하고 있습니다.

    Microsoft에서 코드 리뷰 코멘트 시 사용하는 이모지, :+1: : 대단하다! 누군가에게 보여줘야 하는 거 아니야?, :question: : 질문이 하나 있어/말해줄 수 있어?, :upside_down_face: : 이건 트집잡기야, 이런 걸로 진행을 막으면 안되지, :thought_balloon: : 꼭 바꿔야 하는 건 아니지만, 내 생각을 꼭 나누고 싶어.     Microsoft에서 코드 리뷰 코멘트 시 사용하는 이모지

“리뷰는 당연하다”, 네카라쿠배*와 스타트업

* 네카라쿠배: 네이버, 카카오, 라인 등을 뜻하는 신조어

        페어 프로그래밍 같이 다양한 코드 리뷰 방법을 도입하여 변화를 이끌어 온 네카라쿠배

국내 스타트업을 중심으로 자동화된 배포와 테스트는 이제 기본기 중의 기본기가 되었습니다. 테스트 기반의 코딩인 TDD(Test Driven Development)를 필수로 적용하고, 코드 Merge 전에 코드 리뷰는 필수적인 프로세스가 되었죠. 국내 IT 선도기업들은 회사에서 표준을 제공하기보다는 팀 상황에 맞추어 자율적으로 코드 리뷰 방법을 결정해서 자율적으로 적용하고 있지만, 대부분의 회사는 GitHub에서 제공하는 PR(Pull Request)을 활용해서 리뷰 요청과 검토를 완료(Approve)하는 방식으로 코드 리뷰를 진행합니다.

특히, 코드 리뷰 진행 이전에 Unit/UI 테스트와 정적 분석을 통해 문제점을 도출한 다음 코드 리뷰를 진행하는 카카오는 자체 개발한 TestBot을 통해 Code Smell과 Bug, Vulnerability 등의 문제를 분석하여 알림으로 제공해 줍니다. 또한 코드 리뷰 진행을 위한 자체 Chrome Extension을 개발해 코드 리뷰가 필요할 때마다 코드 리뷰어를 자동 할당하여 리뷰하도록 하고 있어요. Discourse를 이용한 코드 리뷰 토론과 정보 공유가 이뤄지는 포털을 통해 온라인 커뮤니케이션을 하지만, 중요한 모듈의 코드 리뷰는 오프라인에서 모여서 진행하는 방식을 선호한다고 합니다.

최근 국내 스타트업의 코드 리뷰 트렌드는 단편적인 코드의 성능과 문제점만 보거나 버그 발생 가능성만 검토하는 것이 아니라, 전체적으로 일관적인 아키텍처를 유지하고 있는지와 기술적인 지식과 노하우를 공유하며 함께 성장할 수 있는지, 그리고 맥락(Context)과 히스토리를 누가 보아도 인지할 수 있도록 개발되고 설명되어지는지를 코드 리뷰 과정에서 살펴본다고 합니다. 쉽게 얘기하자면, 코드 리뷰가 소프트웨어 검수 절차와 품질 프로세스라기보다는 개발자와 회사가 함께 성장할 수 있도록 하는 수단으로 여겨진다는 겁니다. 코드 리뷰의 결과물은 지식 자산으로서 회사에 남게 되는 것이구요. 그래서, 리뷰 마스터 제도를 도입하여 리뷰를 독려하고, Merge 권한도 전문가에게 부여하는 등의 활동이 중요시되고 있습니다.

‘테스트 없는 코드는 없고, 리뷰는 당연하다’는 인식이 일반화되어가는 지금, 우리 회사의 코드 리뷰 방식에서 장점은 취하고, 특성은 살리는 우리만의 방식을 찾아가는 과정이 되어야 할 것 같네요.



▶  해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶  해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.