Meta가 코드 리뷰 품질을 유지하면서도 리뷰 대기 시간을 줄이기 위해 측정 지표를 정립하고, 실험을 통해 도구와 기능을 개선해 온 방법을 소개한다.
URL: https://engineering.fb.com/2022/11/16/culture/meta-code-review-time-improving
Title: 더 빠르게 움직이고, 덜 기다리기: Meta의 코드 리뷰 시간 개선
코드 리뷰가 잘 수행되면 버그를 잡아내고, 모범 사례를 가르치며, 높은 코드 품질을 보장할 수 있습니다. Meta에서는 코드베이스에 적용되는 개별 변경 묶음을 “diff(디프)”라고 부릅니다. Meta는 빠르게 움직이는 것을 선호하지만, 모든 diff는 예외 없이 반드시 리뷰를 거쳐야 합니다. 하지만 코드 리뷰 팀으로서, 리뷰가 오래 걸릴수록 사람들이 해낼 수 있는 일이 줄어든다는 점도 잘 알고 있습니다.
우리는 개발자들을 불만족하게 만드는 코드 리뷰 병목을 더 잘 이해하기 위해 여러 지표를 연구했고, 그 지식을 바탕으로 리뷰 품질을 희생하지 않으면서 코드 리뷰 프로세스를 가속하는 기능들을 구축했습니다. 느린 diff 리뷰 시간(P75)과 엔지니어 불만족 사이에 상관관계가 있음을 확인했습니다. 코드 리뷰 라이프사이클의 핵심 순간에 적절한 리뷰어에게 diff를 노출하는 도구들은 diff 리뷰 경험을 크게 개선했습니다.
이 질문에 답하기 위해, 우리는 먼저 데이터부터 살펴보았습니다. 우리는 “Time In Review(리뷰 대기 시간)”이라는 지표를 추적하는데, 이는 diff가 여러 개별 리뷰 사이클 전반에 걸쳐 리뷰를 기다리고 있는 총 시간을 측정합니다. 여기서는 diff가 리뷰어의 액션을 기다리고 있는 시간만을 집계합니다.
Time In Review는 파란색 구간에서 소비된 시간의 합으로 계산됩니다.
우리가 발견한 사실은 놀라웠습니다. 2021년 초 데이터를 살펴봤을 때, diff의 리뷰 대기 시간 중앙값(P50)은 몇 시간 정도로, 꽤 괜찮다고 느꼈습니다. 하지만 P75(즉, 가장 느린 25%의 리뷰)를 보면 diff 리뷰 시간이 최대 하루까지 늘어나는 것을 확인했습니다.
우리는 Time In Review와 사용자 만족도(전사 설문조사로 측정) 간의 상관관계를 분석했습니다. 결과는 분명했습니다. 자신이 경험한 가장 느린 25%의 diff들이 리뷰되기까지 걸리는 시간이 길수록, 코드 리뷰 프로세스에 대한 만족도는 낮아졌습니다. 이렇게 해서 우리의 ‘북극성(north star) 지표’가 정해졌습니다: P75 Time In Review.
Time In Review를 낮추는 것은 코드 리뷰 프로세스에 대한 만족도를 높일 뿐 아니라, Meta의 모든 엔지니어 생산성도 높일 것입니다. diff의 리뷰 대기 시간을 줄인다는 것은 엔지니어들이 리뷰를 기다리는 데 쓰는 시간이 크게 줄어든다는 뜻이며, 그만큼 더 생산적이고 전체 리뷰 프로세스에도 더 만족하게 됩니다.
하지만 단순히 리뷰 속도만 최적화하면, ‘대충 도장 찍기(rubber-stamp)’처럼 부정적인 부작용을 유발할 수 있습니다. 의도치 않은 부정적 결과를 막기 위한 가드레일(guardrail) 지표가 필요했습니다. 우리는 “Eyeball Time(아이볼 타임)”을 선택했습니다. 이는 리뷰어가 diff를 실제로 들여다본 총 시간입니다. 고무도장식 리뷰가 늘어나면 Eyeball Time은 감소하게 됩니다.
이제 목표 지표(Time In Review)와 가드레일 지표(Eyeball Time)를 정립했습니다. 다음은 무엇일까요?
Meta의 거의 모든 제품 팀은 실험과 데이터 기반 프로세스를 통해 기능을 출시하고 반복 개선합니다. 하지만 이런 프로세스는 우리 같은 내부 도구 팀에는 아직 매우 새로운 방식입니다. 제품 팀들이 겪지 않는 여러 도전 과제(표본 크기, 무작위 배정, 네트워크 효과)가 있고, 우리는 이를 극복해야 했습니다. 우리는 네트워크 실험을 수행하기 위한 새로운 데이터 기반을 만들고, 분산을 줄이고 표본 크기를 늘리는 기법을 활용함으로써 이런 문제를 해결합니다. 이러한 추가 노력은 충분히 가치가 있습니다. 실험의 기반을 마련하면, 이후 우리가 만드는 기능의 영향과 효과를 입증할 수 있기 때문입니다.
실험 프로세스: 목표 및 가드레일 지표의 선택은 해당 기능에 대해 우리가 가진 가설에 의해 결정됩니다. 우리는 사용자 클러스터 기반 무작위화 등, 처치(treatment)를 무작위 배정할 실험 단위를 손쉽게 선택할 수 있는 기반을 구축했습니다.
이 기능의 영감은 의외의 곳, 바로 동영상 스트리밍 서비스에서 왔습니다. 특정 스트리밍 서비스에서 한 에피소드에서 다음 에피소드로 넘어가는 전환이 매끄럽기 때문에 ‘정주행(binge watch)’이 쉬운 것처럼, 코드 리뷰에서도 그렇게 할 수 있다면 어떨까요? diff를 미리 큐(queue)에 올려두면 리뷰어가 리뷰의 ‘플로우 상태’에 들어가 시간을 효율적으로, 정신적 에너지를 최대한 활용해 리뷰할 수 있을 것입니다.
이렇게 해서 Next Reviewable Diff가 탄생했습니다. 우리는 머신러닝을 사용해, 현재 리뷰어가 리뷰하고 싶어 할 가능성이 매우 높은 diff를 식별합니다. 그리고 리뷰어가 현재 코드 리뷰를 마치면 그 diff를 노출합니다. 또한 가능한 ‘다음 diff’ 후보들을 쉽게 순환해서 살펴볼 수 있게 하고, 해당 diff가 자신과 관련이 없다면 빠르게 리뷰어에서 빠질 수 있도록 합니다.
출시 후, 이 기능은 하루당 전체 리뷰 액션(예: diff 승인, 코멘트 등)을 17% 증가시키는 결과를 냈고, 이 흐름을 사용하는 엔지니어들은 평균 리뷰어보다 44% 더 많은 리뷰 액션을 수행하는 것으로 나타났습니다!
작성자가 diff에 대해 어떤 리뷰어를 선택하느냐는 매우 중요합니다. diff 작성자는 코드를 잘 리뷰해 주고, 빠르게 리뷰해 주며, 해당 diff가 건드리는 코드의 전문가인 리뷰어를 원합니다. 과거 Meta의 리뷰어 추천기는 제한된 데이터만을 바탕으로 추천을 수행했는데, 그 결과 새 파일에 취약하고 엔지니어가 팀을 옮기면서 추천이 금방 낡는(stale) 문제가 있었습니다.
우리는 근무 시간 인지(work hours awareness)와 파일 오너십(file ownership) 정보를 포함하는 새로운 리뷰어 추천 시스템을 구축했습니다. 이를 통해 diff를 리뷰할 수 있는 여유가 있고 훌륭한 리뷰어가 될 가능성이 높은 사람들이 우선순위로 올라가게 됩니다. 또한 이러한 추천을 구동하는 모델을 재작성하여 백테스팅(backtesting)과 자동 재학습(automatic retraining)도 지원하도록 했습니다.
결과는 어떨까요? 24시간 내에 리뷰된 diff의 비율이 1.5% 증가했고, 상위 3개 추천 정확도(실제 리뷰어가 제안된 상위 3명 중 한 명인 경우의 비율)는 60% 미만에서 거의 75%까지 증가했습니다. 추가 보너스로, 새 모델은 또한 14배 더 빨랐습니다(P90 지연 시간 기준)!
우리는 소수의 오래된(stale) diff만으로도, 다른 diff들이 빠르게 리뷰되더라도 엔지니어들이 불만족할 수 있다는 것을 알고 있습니다. 느린 리뷰는 또 다른 영향도 있습니다. 코드 자체가 낡고, 작성자는 컨텍스트 전환을 해야 하며, 전체 생산성도 떨어집니다. 이를 직접적으로 해결하기 위해, 우리는 Microsoft에서 수행된 연구에서 영감을 받아 Nudgebot을 만들었습니다.
리뷰에 유난히 오랜 시간이 걸리는 diff에 대해, Nudgebot은 해당 diff를 리뷰할 가능성이 가장 높은 리뷰어 하위 집합을 결정합니다. 그리고 적절한 컨텍스트와 함께, 수신자가 곧바로 리뷰에 들어갈 수 있도록 하는 빠른 액션 세트를 포함한 채팅 핑을 보냅니다.
Nudgebot 실험은 훌륭한 성과를 냈습니다. 모든 diff에 대한 평균 Time In Review가 7% 감소했고(주말 제외로 보정), 리뷰를 3일 넘게 기다린 diff의 비율은 12% 감소했습니다! 이 기능의 성공은 별도로도 출판되었습니다.
이는 오래된 diff 묶음에 대한 채팅 알림이 리뷰어에게 어떻게 보이는지, 그리고 “나중에 다시 알림(Remind Me Later)”과 같은 잠재적 상호작용 중 하나를 보여줍니다.
현재 및 향후 작업은 다음과 같은 질문에 초점을 맞추고 있습니다:
우리는 이러한 질문들에 대한 답을 계속해서 추구하고 있으며, 앞으로 개발자 프로세스를 더 간소화할 수 있는 방법들을 더 많이 찾아내길 기대합니다!
개발자 생산성의 미래를 만드는 일에 관심이 있나요? 함께하세요!
이 글을 준비하는 데 도움과 기여를 해준 다음 분들께 감사드립니다: Louise Huang, Seth Rogers, James Saindon.
