Review Latency는 가시성 문제이며 사람 문제가 아니다

Source: Dev.to

개발 사이클의 실제 병목 현상

대부분의 엔지니어링 팀은 리뷰 속도에 문제가 있다고 생각합니다. SLA 목표를 설정하고, 전용 리뷰 시간을 잡고, 슬랙에서 사람들을 독촉하죠. 하지만 이번 주에 여러 팀의 패턴을 살펴보니 한 가지가 매우 명확해졌습니다: 병목 현상은 누군가가 PR을 얼마나 빨리 리뷰하느냐가 아니라, PR이 존재한다는 사실을 누가 언제 알아차리는가에 달려 있습니다.

알림 묘지

GitHub와 GitLab은 모두 알림을 보냅니다—이메일 푸시, 인앱 배지, 슬랙 연동 등. 그럼에도 불구하고 PR은 몇 시간, 때로는 며칠 동안 첫 리뷰가 이루어지지 않고 방치됩니다.

왜일까요? 신호‑대‑잡음 비율이 끔찍하기 때문입니다. 여러 저장소를 오가며 작업하는 개발자는 하루에 수십 개의 알림을 받을 수 있습니다. 이메일 알림은 필터링되고, 슬랙 메시지는 스크롤을 지나갑니다. GitHub 알림 탭은 아무도 다시 보지 않을 읽지 않은 항목들의 묘지가 됩니다.

PR은 있었고, 알림은 전송됐지만, 실제로 볼 수 있는 충분한 맥락을 가진 사람이 없었습니다.

프로세스만으로는 해결되지 않음

자연스러운 반응은 더 많은 프로세스를 도입하는 것입니다: 필수 리뷰어 지정, 오픈 PR에 대한 일일 스탠드업 체크‑인, 자동 리마인더 등. 이러한 조치는 어느 정도 도움이 될 수 있지만, 증상을 치료할 뿐 근본 원인을 해결하지는 못합니다.

근본 원인은 파편화입니다. 팀의 작업이 15개의 저장소, 두 개의 Git 플랫폼, 세 개의 커뮤니케이션 도구에 흩어져 있다면, 누군가가 지금 바로 주의를 기울여야 할 항목을 한눈에 파악할 수 있는 단일 장소가 없습니다.

가시성이 곱셈 효과를 냄

가장 빠르게 배포하는 팀이 반드시 가장 엄격한 리뷰 습관을 가진 팀은 아닙니다. 그들은 오픈 PR을 놓칠 수 없는 팀입니다.

설정에 따라 모습은 다를 수 있습니다. 일부 팀은 대시보드를 사용하고, 일부는 PR용 칸반 보드를 사용합니다. 우리는 Code Board에서 위험 점수를 매긴 통합 뷰를 구축했는데, 이는 “올바른 PR을 올바른 사람에게 올바른 시점에 보여주는” 것이 가장 큰 효과를 만든다는 패턴을 계속 목격했기 때문입니다.

하지만 도구와 관계없이 원칙은 같습니다: 사이클 타임을 줄이고 싶다면 사람들에게 더 빨리 리뷰하라고 요구하지 마세요. 리뷰가 필요한 것을 보게 만드는 것부터 시작하세요.

이번 주에 할 일

• 팀의 첫 리뷰까지 걸린 시간을 측정하세요(단순히 머지까지 걸린 시간만이 아니라).
• 24시간 이상 리뷰어와의 상호작용 없이 머물렀던 PR이 몇 개인지 확인하세요.
• 팀에게 솔직히 물어보세요: “PR이 기다리고 있다는 걸 항상 알고 있나요?”

그 답변을 통해 여러분이 규율 문제인지 가시성 문제인지를 알 수 있습니다. 대부분의 경우, 뒤가 정답입니다.