팀이 탈진하기 전에 버닝아웃 코드베이스를 발견하는 방법

Source: Dev.to

(번역을 진행하려면 번역하고자 하는 전체 텍스트를 제공해 주세요.)

코드베이스가 먼저 알다

보통은 막연한 느낌에서 시작됩니다. 스탠드업이 무거워지고, 추정치가 계속 미끄러집니다. 어려운 문제에 자원하던 엔지니어들이 갑자기 간단한 문제를 배정받는 데 매우 관심을 보이게 됩니다.

사람 문제—예를 들어 누군가 사직서를 제출하거나 팀이 마일스톤을 놓치는 상황—으로 드러날 때쯤, 경고 신호는 이미 커밋 기록에 조용히 몇 달 동안 쌓여 있었습니다.

코드베이스는 번아웃되지 않지만, 그 안에서 일하는 사람들을 번아웃시키는 조건들을 축적합니다. 그 신호들을 읽는 법을 배우는 것은 엔지니어링 매니저가 할 수 있는 가장 높은 효율의 일 중 하나입니다.

코드베이스는 팀 건강 거울이다

리포지토리의 활동 패턴은 팀이 어떻게 작동하고 있는지를 직접적으로 반영합니다. 커밋 주기, PR 리뷰 소요 시간, 기여자 분포 — 이것들은 단순한 엔지니어링 위생 지표가 아니라, 팀이 에너지를 어떻게 소비하고 있는지, 누가 부담을 짊어지고 있는지, 그리고 마찰이 어디에서 발생하고 있는지를 기록한 것입니다.

여기서 살펴보는 장점은 객관적이며 조기에 파악할 수 있다는 점입니다. 사람들은 종종 번아웃이나 불만을 심각해질 때까지 드러내기를 꺼려합니다. 하지만 리포는 그런 필터가 없습니다.

5 Warning Signs to Watch

1. 지속적인 커밋 속도 감소

한 주만 느리게 진행되는 것은 잡음에 불과합니다. 4주 동안 커밋 빈도가 감소하는 추세—특히 명확한 변화가 없을 때(휴일도 없고, 계획된 집중 스프린트도 없을 때)—는 조사할 가치가 있는 신호입니다.

이는 작업이 덜 된 것이 아니라 더 어려워졌다는 의미가 많습니다. 엔지니어들이 기존 복잡성을 해결하거나, 불분명한 소유권을 디버깅하는 데 더 많은 시간을 쓰거나, 단순히 동기 부여가 떨어져 일을 추진하지 못하고 있기 때문입니다.

2. 버스 팩터 증가

핵심 레포지토리의 기여자 분포를 확인해 보세요. 최근 커밋의 60 % 이상을 한 사람이 담당하고 있다면 버스 팩터 문제가 있는 것이며, 번아웃 위험이 있는 후보자일 수도 있습니다.

높은 버스 팩터는 단순히 지식 위험을 의미하는 것이 아니라, 한 엔지니어가 불균형하게 많은 인지 부하를 짊어지고, 대부분의 질문에 답하며, 점점 고립감을 느끼고 있다는 뜻입니다. 그 사람이 떠나거나 번아웃되면 지식도 함께 사라집니다.

3. 오래된 PR 누적

일주일 이상 손대지 않은 열린 PR은 리뷰 문화가 무너졌다는 신호입니다. 이는 보통 두 가지 이유 중 하나 때문입니다: 리뷰어가 과부하에 시달리며 리뷰 작업을 우선순위에서 제외하거나, 코드베이스가 너무 복잡해져서 리뷰 자체가 부담스러워지는 경우입니다.

어느 쪽이든 PR 대기열이 묘비가 되는 상황은 PR을 만든 엔지니어들에게 사기를 꺾습니다. 이는 그들의 작업이 제대로 보이지 않고 있다는 신호이기도 합니다.

4. 특정 기여자 주변의 비활동 급증

개별 기여자의 커밋 빈도가 갑자기 급감하는 경우를 찾아보세요—완전히 멈춘 것이 아니라 평소 수준보다 눈에 띄게 낮아진 경우입니다. 이는 휴가를 떠난 경우와는 다릅니다. 일을 그만둔 것이 아니라 정신적으로 체크아웃한 패턴입니다.

이러한 엔지니어들은 여전히 할당된 작업을 수행하지만, 주도적으로 행동하지 않으며, PR을 적극적으로 리뷰하지 않고, 필수적인 범위를 넘어서는 기여를 하지 않게 됩니다.

5. 시간에 따른 기여자 다양성 감소

건강한 코드베이스는 팀 전체에 걸쳐 기여가 골고루 이루어집니다. 최근 커밋에 같은 두세 명의 이름만 계속 등장하고 다른 사람들은 점점 사라지는 현상을 발견하면, 그 이유를 물어볼 필요가 있습니다.

때로는 전문화의 자연스러운 결과일 수도 있습니다. 그러나 종종 이는 코드베이스에 비공식적인 게이트키퍼가 생겼거나, 새로운 팀원이 기여하기 위한 온보딩 비용이 너무 높아져서 참여를 포기하게 된 신호입니다.

이러한 신호를 보았을 때 해야 할 일

• 신호를 결론이 아니라 시작점으로 활용하세요.
  “지난 3주 동안 PR 리뷰 시간이 늘어나고 있는 것을 보았습니다 — 지금 리뷰가 어려워지는 이유는 무엇인가요?” 라는 질문은 마감일을 놓친 이유에 대한 회고보다 훨씬 생산적인 대화 시작점이 됩니다.

• 소유권을 의도적으로 순환시키세요.
  버스 팩터가 상승하고 있다면, 지식 이전을 위한 명시적인 기회를 만들세요. 페어 리뷰, 순환 온콜, 아키텍처 워크스루 등은 프로세스적인 연습이 아니라 팀이 실제로 필요한 커버리지를 제공하기 위해 진행합니다.

• 속도가 떨어질 때 범위를 축소하세요.
  지속적인 속도 저하가 반드시 사람들이 충분히 열심히 일하지 않음을 의미하는 것은 아닙니다. 보통 작업 자체가 계획보다 더 어려워졌다는 뜻입니다. 답은 더 힘내는 것이 아니라 마찰을 없애고, 비핵심 작업을 연기하거나, 일정이 변경되어야 함을 인정하는 것입니다.

팀의 엔지니어들은 결국 어려움을 겪고 있음을 말해줄 것입니다. 코드베이스는 그보다 더 빨리 알려줄 것입니다.

저는 RepoShark을 구축하여 여러분의 저장소에서 이러한 종류의 신호를 자동으로 추출하고 있습니다. 코드베이스 건강에 대한 조기 가시성을 원하시는 엔지니어링 리더라면 언제든지 연락 주세요.