Pull Requests가 오래되게 되는 이유 — 그리고 이것은 사람 문제라기보다 가시성 문제이다

Source: Dev.to

The Pattern

여러 개의 레포지토리를 다루는 모든 엔지니어링 팀은 결국 같은 벽에 부딪힙니다: 풀 리퀘스트가 며칠, 때로는 몇 주 동안 열려 있는 경우가 있습니다 — 그 이유는 누군가 거부했기 때문이 아니라, 아무도 그것을 보지 못했기 때문입니다.

그 풀 리퀘스트를 연 개발자는 할당된 리뷰어가 알림을 받았다고 가정했습니다. 리뷰어는 다른 프로젝트에 몰두해 있었고 GitHub 이메일 폭풍 속에서 이를 놓쳤습니다. 엔지니어링 매니저는 그 특정 레포지토리를 그 특정 날에 확인할 이유가 없었습니다.

PR이 차단된 것이 아니라, 보이지 않았을 뿐입니다.

현대 엔지니어링 팀은 수십 개에서 수백 개의 레포지토리에 작업을 분산합니다. 마이크로서비스 아키텍처, 모노레포‑투‑폴리레포 마이그레이션, 그리고 다팀 소유 구조는 모두 어느 한 사람이 활성 작업이 어디서 진행되고 있는지 전체적인 정신 모델을 갖기 어려운 세상을 만들고 있습니다.

GitHub와 GitLab 알림은 개인 기여자가 자신의 작업을 추적하도록 설계되었습니다. 개발자, 리뷰어, 매니저 등 누구에게도 — 다중 레포지토리에서 열려 있고 오래된 PR을 한눈에 보여주는 기능은 설계되지 않았습니다.

일부 팀은 Slack 통합이나 커스텀 봇을 구축합니다. 이는 잠시 동안은 효과가 있지만, 결국 또 다른 소음원이 됩니다. 채널에 하루에 30개의 PR 업데이트가 올라오면 사람들은 채널을 뮤트합니다. 신호‑대‑소음 비율이 무너집니다.

이것은 게으른 리뷰어 혹은 부주의한 개발자 문제라기보다 도구의 격차입니다. 여러 레포지토리에서 PR을 관리하기 위한 기본 경험은 집계된 뷰, 연령 추적, 우선순위 지정 기능을 제공하지 않습니다. 이러한 것이 없으면 시스템적인 사각지대를 보완하기 위해 개인의 경계를 의존하게 되며, 이는 규모에 맞지 않습니다.

해결책은 개념적으로는 간단합니다: 모든 열린 PR을 하나의 뷰에 집계하고, 연령과 위험도 순으로 정렬하며, 각 레포지토리를 클릭하지 않고도 행동할 수 있을 만큼 충분한 컨텍스트를 제공하는 것입니다.

이것이 Code Board와 같은 도구가 추구하는 핵심 아이디어이며, GitHub와 GitLab의 PR을 하나의 칸반 보드에 끌어와 자동 위험 점수와 오래된 PR 추적을 제공합니다. 하지만 어떤 도구를 사용하든 원칙은 같습니다: 가시성은 부가적인 퀘스트가 아니라 기본값이어야 합니다.

팀에서 PR이 오래 머무는 현상이 보인다면, 개인을 비난하려는 충동을 억제하세요. 시스템을 바라보세요. 여러분의 도구가 모든 레포지토리에서 리뷰를 기다리는 항목을 완전하게 보여주고 있는지 스스로에게 물어보세요.

그 답이 ‘아니오’라면, 문제가 바로 그곳에 있습니다.