2.9 풀 리퀘스트와 코드 리뷰 메트릭

개요 및 동기

코드 리뷰는 보통 주제 2.6의 사이클 타임 분해 안에서 가장 큰 단일 대기 시간 기여자이며, 공유 플랫폼 병목이나 외부 의존성과 달리 팀 자체의 통제 아래서 개선하기 가장 직접적인 단계이기도 하다. 이 주제는 리뷰 단계 안에 살아 있는 구체적인 메트릭, 즉 첫 리뷰까지의 시간, 풀 리퀘스트 크기, 리뷰 반복 횟수, 리뷰어 부하 분포를 다루며, 리뷰가 제공해야 할 실제 품질 이점을 희생하지 않으면서 리뷰 속도를 개선하기 위해 그것들을 사용하는 방법을 다룬다.

이 주제가 가장 경계하는 위험은 이 책이 아직 직접 다루지 않은 것이다: 리뷰 속도를 최적화하는 것은 부주의하게 추구될 경우 조용히 리뷰 품질을 침식할 수 있다. 모든 것을 형식적으로 승인함으로써 첫 리뷰까지의 시간을 절반으로 줄인 팀은 그 관행의 실제 가치를 파괴하면서 메트릭을 개선한 것이다. 이 주제의 모든 권장 사항은 그 트레이드오프를 염두에 두고 작성되었는데, 풀 리퀘스트 메트릭은 근본적인 코드베이스를 측정 가능하게 악화시키면서 대시보드에서는 좋아 보이는 방식으로 게임하기 가장 쉬운 것 중 하나이기 때문이다.

대규모 팀에게 리뷰 메트릭은 그렇지 않으면 보이지 않을 부하 분산 문제를 드러낸다: 소수의 고참 엔지니어가 불균형한 몫의 리뷰 부하를 흡수하는 것, 리뷰가 지속적으로 정체되는 특정 팀이나 코드베이스 영역, 혹은 리뷰어의 성실함과 무관하게 철저한 리뷰를 실질적으로 불가능하게 만드는 지나치게 큰 풀 리퀘스트의 패턴. 모두가 그것을 드러낼 메트릭 없이도 불균형을 직접 볼 수 있는 소규모 팀에서보다 이러한 패턴은 규모에서 훨씬 더 복합적으로 커진다.

핵심 원칙

첫 리뷰까지의 시간이 보통 가장 큰 지렛대이지, 리뷰의 철저함 자체가 아니다. 대부분의 지연은 리뷰 대화가 일단 시작된 후 오래 걸리는 것이 아니라 풀 리퀘스트가 살펴봐지기를 기다리는 것에서 온다.
더 작은 풀 리퀘스트는 단지 더 빠르게가 아니라 더 빠르고 더 철저하게 리뷰된다. 크기는 속도와 품질 둘 다에 동시에 작용하는 지렛대 지점이다.
리뷰 속도와 리뷰 품질이 자동으로 긴장 관계에 있는 것은 아니지만, 부주의하게 맞바꿀 수 있다. 그 거래를 명시적으로 경계하라.
리뷰어 부하 불균형은 흔하며 메트릭 없이는 보통 보이지 않는다. 소수의 사람들이 흔히 불균형한 몫을 흡수한다.
이 메트릭들은 형식적 승인 게임 위험에 노출된다. 진정한 정밀 조사 없는 빠른 승인은 리뷰의 전체 취지를 무너뜨린다.

권장 사항

첫 리뷰까지의 시간을 주요 속도 메트릭으로 추적하라

당신의 버전 관리 플랫폼으로부터 자동으로 계측되어, 풀 리퀘스트가 열리는 것부터 리뷰어의 첫 실질적인 코멘트나 승인까지의 간격을 측정하라. 이것은 보통 리뷰 단계 안에서 지배적인 대기 시간 기여자이며(주제 2.5, 주제 2.6), 더 명확한 리뷰 배정 규범, 알림 관행, 혹은 전용 리뷰 시간 블록을 통해 그것을 개선하는 것은 일반적으로 팀에게 이용 가능한 전체 사이클 타임에 대한 단일한 가장 큰 개선을 만들어 낸다.

풀 리퀘스트 크기를 추적하고 더 작은 변경을 적극적으로 장려하라

풀 리퀘스트당 변경된 줄이나 건드려진 파일을 측정하고, 지속적으로 큰 중앙값 크기를 직접 다룰 가치가 있는 신호로 취급하라. 더 작은 풀 리퀘스트는 더 빠르게 리뷰되고, 더 철저하게 리뷰되며(리뷰어가 실제로 전체 변경을 머릿속에 담을 수 있다), 무언가 잘못되었을 때 되돌리기 더 쉬우며, 이는 주제 2.10의 배포 빈도 배후에 있는 배치 크기 원칙에 직접 다시 연결된다. 작업이 허락하는 곳이라면 어디든 큰 변경을 일련의 더 작고 독립적으로 리뷰 가능한 풀 리퀘스트로 나누도록 장려하라.

리뷰어 부하 분포를 명시적으로 모니터링하라

순환하는 기간에 걸쳐 사람당 완료된 리뷰의 수를 추적하고, 특히 소수의 사람이 불균형한 몫을 흡수하는 것을 경계하라. 이 패턴은 흔하고, 흔히 가장 고참이거나 가장 신뢰받는 엔지니어에게 떨어지며, 병목(그들의 가용성이 전체 팀의 리뷰 처리량에 상한을 둔다)과 번아웃 위험(주제 3.2가 웰빙 메트릭을 더 깊이 다룬다) 둘 다를 만들어 낸다. 가장 빠르게 응답하는 사람 주위에 기본값으로 집중되게 두는 대신 의도적으로 리뷰 책임을 순환시켜라.

형식적 승인 게임 위험을 명시적으로 경계하라

첫 리뷰까지의 시간을 품질 신호와 짝지어라: 코멘트 없이 승인된 변경으로 거슬러 올라가는 결함이나 인시던트의 비율, 혹은 최근 리뷰된 코드에 필요한 병합 후 수정의 비율. 진정한 정밀 조사 없이 승인함으로써 리뷰 속도를 개선하는 팀은 이 가드레일이 악화되는 것을 보게 될 것이며, 이는 정확히 주제 1.2의 짝짓기 원칙을 이 특정 메트릭 패밀리에 적용한 것이다. 이 대응 메트릭을 염두에 두지 않고 결코 리뷰 속도를 좇지 마라.

리뷰 반복 횟수를 개인을 판단하는 것이 아니라 마찰을 발견하는 데 사용하라

풀 리퀘스트가 병합되기 전에 거치는 리뷰 라운드의 수는 진정한 마찰, 불명확한 요구 사항, 접근법에 대한 불일치, 일관성 없는 스타일 기대치를 나타낼 수 있으며, 이는 프로세스 수준에서 조사할 가치가 있다. 이 수치를 개별 작성자나 리뷰어를 직접 판단하는 데 사용하는 것을 피하라. 높은 반복 횟수는 개인적인 신호보다는 흔히 시스템이나 소통 신호이며, 그것을 개인 성적표로 취급하는 것은 정확히 주제 1.1이 경고하는 평가적 드리프트의 위험을 무릅쓴다.

트레이드오프: 장단점

접근법	장점	단점
순전히 첫 리뷰까지의 시간만 최적화하기	빠르고, 명확한 신호이며, 계측하기 쉬움	경계하지 않으면 피상적인 형식적 리뷰를 조장할 수 있음
순전히 풀 리퀘스트 크기 감소만 최적화하기	속도와 철저함 둘 다 동시에 개선함	모든 작업이 작은 증분으로 깔끔하게 나뉘지는 않음
리뷰 부하를 고르게 순환시키기	병목과 번아웃 위험을 줄임	특정 전문성이 필요한 전문화되고 리뷰하기 어려운 코드에 대해 리뷰를 늦출 수 있음
고참 엔지니어 사이에 리뷰를 집중시키기	일관되게 적용되는 깊은 도메인 전문성	시간이 지남에 따라 병목과 번아웃 위험을 만듦

핵심 긴장은 속도 대 정밀 조사의 깊이다. 이 주제에서 리뷰를 더 빠르게 하기 위한 모든 기법, 즉 더 빠른 첫 응답, 더 작은 풀 리퀘스트, 더 분산된 리뷰어 부하는 이 주제가 권장하는 품질 가드레일 없이 추구될 경우 실제 정밀 조사를 맞바꿀 어느 정도의 위험을 지닌다. 팀이 조용히 침식되는 리뷰 기준으로부터 진정한 프로세스 개선을 구별할 수 있도록 모든 속도 메트릭을 같은 기간에 걸쳐 추적되는 품질 신호와 짝지음으로써 이 긴장을 해결하라.

팀과 논의할 질문

우리의 실제 첫 리뷰까지의 시간은 무엇이며, 리뷰 단계는 우리의 전체 사이클 타임 중 얼마나 많은 부분을 소비하는가? 인상에 의존하는 대신 실제 수치를 가져오라. 리뷰 대기 시간은 흔히 팀이 가정하는 것보다 더 큰데, 정확히 활발하게 일하는 시간보다 기다리는 데 쓴 시간을 과소평가하기 쉽기 때문이다.
우리의 중앙값 풀 리퀘스트 크기는 무엇이며, 그 크기가 줄어든다면 우리의 리뷰 지연은 얼마나 줄어들까? 큰 풀 리퀘스트는 리뷰하기 더 느리고 단순히 리뷰어가 한 번에 전체를 머릿속에 담을 수 없기 때문에 피상적인 리뷰를 받을 가능성이 더 높다. 중앙값만이 아니라 실제 크기 분포를 살펴보라.
리뷰 부하가 소수의 사람에게 집중되어 있으며, 그중 한 명이 2주 동안 이용 불가능하다면 우리의 리뷰 처리량에 무슨 일이 일어날까? 이 질문은 병목 위험과 번아웃 위험을 동시에 드러낸다. 인상에 의존하는 대신 실제 리뷰어 부하 데이터를 가져오라.
우리는 돌이켜보면 실제 정밀 조사를 줄인 방식으로 리뷰 속도 메트릭을 개선한 적이 있는가? 여기서 정직해져라. 이것이 정확히 이 주제가 이름 붙이는 형식적 승인 위험이며, 그렇게 하겠다는 어떤 의도적인 결정도 없이 미끄러지기 쉽다.
높은 리뷰 반복 횟수는 우리 팀에서 보통 무엇을 신호하는가: 진정한 불일치, 불명확한 요구 사항, 혹은 일관성 없는 스타일 기대치? 유난히 높은 반복 횟수를 가진 풀 리퀘스트의 표본을 살펴보고, 그것이 작성자나 리뷰어 어느 쪽에게든 나쁘게 반영된다고 가정하는 대신 실제 패턴을 진단하라.
우리는 리뷰 속도 메트릭과 짝을 이루는 품질 가드레일을 가지고 있는가, 아니면 속도만 고립된 채 추적하고 있는가? 정직한 답이 그런 가드레일이 존재하지 않는다는 것이라면, 그것은 주제 1.2의 짝짓기 원칙에 따라 리뷰 속도를 더 밀어붙이기 전에 메울 가치가 있는 간극이다.

분야별 관점

스타트업. 소규모 팀에서는 리뷰가 흔히 기본적으로 빠르며, 때로는 거의 너무 빠르다: 모두가 모두를 신뢰하기 때문에 최소한의 정밀 조사만 하는 단일 승인자 리뷰다. 팀이 성장함에 따라 지켜봐야 할 위험은 리뷰 품질이 팀 규모와 함께 확장되지 않는 것인데, 다섯 명의 엔지니어에게 통했던 비공식적인 신뢰는 쉰 명에게는 자동으로 통하지 않기 때문이다.

중소기업. 대부분의 버전 관리 플랫폼은 바로 병합까지의 시간과 리뷰 개수 통계를 보고한다. 맞춤형 계측을 구축하는 대신 이것들을 사용하라. 채택할 가치가 있는 주된 규율은 단순히 팀이 성장함에 따라 리뷰 부하가 한두 명에게 조용히 집중되었는지 알아채는 것이다.

엔터프라이즈. 리뷰어 부하 불균형과 전문 지식 병목은 여기서 특히 흔한데, 중요한 시스템에 대한 깊은 도메인 전문성은 팀 규모와 무관하게 소규모 그룹에 리뷰 책임을 집중시킬 수 있기 때문이다. 전문성을 확산시키기 위해 의도적인 지식 공유와 리뷰 순환에 투자하여, 병목과 그 전문성이 너무 적은 사람에게 집중되어 있는 버스 팩터 위험 둘 다를 줄여라.

정부. 여기서 리뷰 프로세스는 흔히 품질 목표와 함께 준수의 무게를 지니며, 이는 풀 리퀘스트를 설계상 더 크고 리뷰를 더 느리게 만들 수 있다. 진정한 준수 요건이 철저한 리뷰를 요구하는 곳에서는, 리뷰의 실제 깊이를 타협하는 대신 개선 노력을 대기 시간을 줄이는 것(더 빠른 리뷰 배정, 더 명확한 트리아지)에 집중하고, 규제상의 이유로 정밀 조사가 무겁게 유지되어야 한다면 그 트레이드오프를 명시적으로 문서화하라.

사례

엔터프라이즈. 한 사이버보안 회사의 엔지니어링 조직은 200명 규모 조직 전체에 걸친 모든 코드 리뷰의 40% 이상을 소수의 주임 엔지니어가 완료하고 있다는 것을 발견했으며, 이는 리뷰어 부하 데이터를 가져오기 전까지 아무도 직접 측정하지 않은 불균형이었다. 이 집중은 그 엔지니어들의 가용성이 전체 조직의 리뷰 처리량에 상한을 두었기 때문에 병목이었고, 참여도 설문(주제 3.2)에 의해 별도로 표시된 번아웃 위험이기도 했다. 그 조직은 목표에 맞춘 지식 공유 세션과 짝을 이루는 구조화된 리뷰 순환 프로그램을 도입했고, 두 분기 안에 리뷰 부하는 훨씬 더 넓은 그룹에 걸쳐 퍼졌으며, 첫 리뷰까지의 시간은 줄어든 병목의 직접적인 부수 효과로 개선되었다.

정부. 전달 속도를 개선하라는 압박을 받은 한 세무 당국의 엔지니어링 팀은 첫 리뷰까지의 시간을 절반으로 줄이는 목표를 설정했다. 한 분기 안에 그 목표는 달성되었지만, 후속 품질 감사는 단일하고 짧은 코멘트로 승인된 변경에 집중된, 병합 후 결함 수정 풀 리퀘스트의 급격한 증가를 발견했다. 팀의 해결책은 속도 목표를 명시적인 품질 가드레일, 즉 리뷰 후 2주 안에 필요한 병합 후 수정의 비율과 짝지었고, 실질적인 리뷰가 실제로 요구하는 것에 대해 팀을 재훈련했으며, 더 나은 리뷰 배정과 더 작은 풀 리퀘스트 크기에서 온 속도 개선의 대부분을 유지하면서 진정한 정밀 조사를 회복했다.

비즈니스 사례: 동기, ROI, TCO

잘 관리된 리뷰 메트릭의 수익은 품질을 희생하지 않는 더 빠른 전달이며, 이는 드문 조합이다: 대부분의 전달 개선은 어딘가에서 속도를 위험과 맞바꾸지만, 이 주제가 권장하는 품질 가드레일과 함께 추구될 때 리뷰 단계 개선, 즉 더 작은 풀 리퀘스트, 더 나은 부하 분산, 더 빠른 첫 응답은 진정으로 둘 다를 동시에 개선한다. 위의 사이버보안 사례가 전형적이다: 병목을 고치는 것은 속도를 개선했고, 근본적인 리뷰 품질은 전문성이 더 넓게 퍼지면서 오히려 개선되었다.

총 소유 비용은 낮다: 이 메트릭 대부분은 최소한의 추가 계측으로 기존 버전 관리 플랫폼 데이터로부터 직접 온다, 그리고 그것들이 가리키는 프로세스 변화, 즉 리뷰 순환, 더 작은 풀 리퀘스트 장려는 대체로 도구 투자보다 규율의 비용이 든다.

안티패턴과 함정

짝을 이루는 품질 가드레일 없이 첫 리뷰까지의 시간을 최적화하기: 리뷰의 목적을 무너뜨리는 형식적 승인을 초래한다.
리뷰어 부하 집중을 무시하기: 측정될 때까지 보이지 않는 병목과 번아웃 위험 둘 다를 만든다.
리뷰 반복 횟수를 개인 성적표로 취급하기: 개인적인 신호보다는 흔히 시스템이나 소통 신호다.
지속적으로 큰 풀 리퀘스트를 불가피한 것으로 받아들이기: 대부분의 큰 변경은 팀이 처음에 가정하는 것보다 더 나눌 수 있다.
변경 위험과 무관하게 균일한 리뷰 깊이를 적용하기: 잠재적으로 높은 위험의 변경을 충분히 정밀 조사하지 않으면서 낮은 위험의 변경에 정밀 조사를 낭비한다.
리뷰 속도는 측정하지만 그와 함께 실제 정밀 조사가 떨어졌는지는 결코 확인하지 않기: 이 메트릭 패밀리가 의도치 않게 게임당하는 가장 흔한 단일 방법.

성숙도 모델

1단계, 시작: 리뷰 메트릭이 추적되지 않는다. 리뷰 부하 분포와 풀 리퀘스트 크기가 보이지 않는다.
2단계, 개발: 플랫폼 기본값으로부터 일부 리뷰 속도 데이터가 존재하지만, 품질 가드레일도 리뷰어 부하의 능동적인 관리도 없다.
3단계, 표준화: 첫 리뷰까지의 시간, 풀 리퀘스트 크기, 리뷰어 부하가 일관되게 추적되며, 속도 개선에 대해 명시적인 품질 가드레일이 짝을 이룬다.
4단계, 관리: 리뷰어 부하가 순환과 지식 공유를 통해 능동적으로 재균형되며, 반복 횟수 패턴은 개인 수준이 아니라 프로세스 수준에서 조사된다.
5단계, 조율: 리뷰 단계 메트릭이 프로세스 투자를 직접 알려주며, 조직은 지속된 기간에 걸쳐 리뷰 속도와 리뷰 연계 품질 결과 둘 다의 동시적인 개선을 입증할 수 있다.

논의를 위한 아이디어

우리의 현재 중앙값 첫 리뷰까지의 시간은 무엇이며, 그 시간은 실제로 어디로 가는가?
우리의 리뷰 부하는 소수의 사람에게 집중되어 있으며, 한 명이 이용 불가능하다면 위험은 무엇인가?
우리는 의도치 않게라도 실제 정밀 조사를 희생하며 리뷰 속도를 개선한 적이 있는가?
우리의 중앙값 풀 리퀘스트 크기는 무엇이며, 현실적으로 대부분의 변경이 얼마나 더 작아질 수 있을까?
우리는 높은 리뷰 반복 횟수를 시스템 신호로 취급하는가, 개인적 판단으로 취급하는가?

핵심 요약

첫 리뷰까지의 시간은 리뷰 대화 길이 자체보다 보통 리뷰 단계 안에서 가장 큰 단일 지렛대다.
더 작은 풀 리퀘스트는 리뷰 속도와 리뷰 철저함 둘 다를 동시에 개선한다.
리뷰어 부하 불균형은 흔하며 직접 측정 없이는 보통 보이지 않는다. 그것은 병목과 번아웃 위험 둘 다를 만든다.
이 메트릭 패밀리가 특히 취약한 형식적 승인 게임 위험을 잡아내기 위해 모든 리뷰 속도 메트릭을 명시적인 품질 가드레일과 짝지어라.
리뷰 반복 횟수를 개별 작성자나 리뷰어를 판단하는 것이 아니라 시스템 수준의 마찰을 진단하는 데 사용하라.

참고 문헌 및 추가 자료

Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
Bacchelli, Alberto, and Christian Bird. “Expectations, Outcomes, and Challenges of Modern Code Review.” ICSE, 2013.
Wiegers, Karl E. Peer Reviews in Software: A Practical Guide. Addison-Wesley, 2002.
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.