Bus Factor와 프로젝트 안정성

소프트웨어 엔지니어링에서 사용하는 용어로 Bus Factor 또는 Truck Number라고도 부르는데, 프로젝트에 속한 인원이 버스나 트럭에 치여 사고가 나는 경우, 프로젝트가 진행될 수 있는지를 나타내는 수치이다. 버스나 트럭이 나올 정도로 잔혹할 필요가 있을까 생각이 들지만, 일을 못하거나 제외되어야 하는 당위성이 너무 분명하긴 하다. 비슷하게, 육아 휴직이나 병가, 이직, 퇴직 같은 갑자기 일을 할 수 없는 상태가 되는 것도 같은 맥락이라 볼 수 있다.

그렇다면 어떻게 수치로 나타낼 것인가. 예를 들어, 게임 개발을 할 때 기획, 개발, 아트로 구성되는데, 메인 기획자 1명이 대부분을 기획하고, 개발, 아트가 각각 3명씩 있다고 하자. 여기서 메인 기획자가 없으면 게임 개발을 진행 할 수 없기 때문에 Bus Factor는 1이다. 즉, 낮은 수치일 수록 프로젝트의 위험도는 커진다. 사실 이미 상식적으로 각 인원의 중요도를 알고 있고, 굳이 수치로 표현할 필요가 있을까 싶지만, 개발 프로세스에 필요한 요소를 수치화 하는 것은 중요한 일이다. 조직을 운영할 때에도 진행되고 있는 프로젝트들의 Bus Factor를 산출하여 어느 프로젝트가 인력의 위험도가 높은지 알 수 있는 척도가 될 수도 있다.

개인적인 의견이지만 대기업의 경우 Bus Factor가 낮더라도 그렇게 치명적이진 않아 보인다. 인력풀이 풍부하고, 시간적/물질적 비용은 들겠지만 필요한 인력을 대체하는 것은 그리 어려운 일은 아니다. 하지만 중소기업은 Bus Factor가 기본적으로 낮고, 좋은 인력을 수급하는 것은 아주 어렵기 때문에 주요 인력을 잃는 것은 치명적이다. 그래서 이를 보완하는 장치로 문서화, 코드 리뷰, 작업 담당을 순환하는 등 여러가지 장치가 있지만, 리더의 강한 의지가 있지 않는 한 현실적으로 적용하기 어렵다.

Bus Factor를 뒤집어서 생각하면 상당히 코믹해진다. Inverse Bus Factor라고 부르는데, 일종의 Joke처럼 들리기도 한다. ”how many developers have to be hit by a bus before a project starts to proceed smoothly?”. 즉, 얼마나 많은 개발자가 버스에 치어야 프로젝트가 잘 돌아가는가란 의미이다. 처음 들었을 때 빵 터질 정도로 반대되지만 틀리지 않는 말이라 놀랍기도 하고 재미있었다. 예전 프로젝트에서 어떤 개발자가 동료들에게 핀잔과 비난을 일삼아 주변 사람들을 힘들게 한 적이 있었는데 이런 사람들 때문에 생긴 개념인가 보다. ‘또라이 질량 보존의 법칙’이 괜히 나온 말은 아니었을 테니.

좋은 팀을 구성하는 것이 제일 중요하지만, 그 팀을 안정적으로 오래 유지하고 싶다면 Bus Factor를 통해 분석해 보는 것도 의미가 있을 것 같다.

References.
https://en.wikipedia.org/wiki/Bus_factor
https://www.lesstif.com/software-engineering/bus-factor-106857476.html
https://jhall.io/archive/2021/07/22/what-is-your-inverse-bus-factor/