버스 지수(Bus Factor)
여는 글
1인 개발과 버스팩터 및 위험요소를 고려하지 않고 개발했던 지난 시간을 회고하며 제대로 기억하고 무엇을 개선할 필요가 있는지 분명히 인식하기 위해서 정리하는 글을 쓴다.
읽기 전에
-
Software engineering at google 책에는
문제의 발견을 타임라인의 왼쪽으로 이동하라는 내용이 나온다. -
문제를 해결하려면 뒤가 아니라 앞으로 가서 상황에 개입해야 한다.
‘업스트림’이라는 새로운 행동모델을 설계한 댄 히스. https://biz.chosun.com/notice/interstellar/2021/10/02/EBEMJTVYYNB25NLYVL3JWLNXUI/) -
문제 해결 비용은 타임 라인에서
왼쪽으로 갈수록 저렴해지고, 오른쪽으로 갈수록 비싸진다.
버스 지수(Bus factor)
버스 지수라니 도대체 무엇을 뜻하는 걸까. 답은 간단하다. “팀 구성원간에 공유되지 않는 정보 및 기능으로 인한 위험을 버스에 부딪힐 경우를 대비하여 측정” 한 것이다. 다시 말하자면 구성원 중의 일부가 불미스러운 사고로 갑자기 사라졌을때 프로젝트가 위험에 빠질 정도를 측정한것이다. 단위는 ‘인원 수’이며, 갑자기 프로젝트에서 핵심 인력이 사라졌을 때, 프로젝트가 중단될수 있는 팀 구성원의 최소 수이다.
굳이 버스가 아니어도 상관이 없는게, Bus factor 뿐만 아니라 트럭 지수(truck factor), 로또 지수(lottery factor)라고도 불리기 때문이다. 결론적으로 불미스러운 사건과 팀원의 결여, 이에 따른 위험을 강조하는 것은 같은 맥락이다.
이 용어는 소프트웨어 서비스에 처음으로 적용되었다. 초기에는 잘 돌아가는 서비스였으나, 암호화 되거나, 체계적으로 문서화가 되어있지 않거나, 이해도가 낮은 코드, 정보나 기능이 공유되지 않을 경우 버스 지수는 점점 낮아진다. 즉, 주요 인적 자원이 가지고 있는 비 공유 정보가 거대해 질수록 리스크는 점점 증가하게 되는 것이다. 이와 반대로 비 주요 인적 자원이나 대체 가능 요소에 대한 버스 요인 효과가 일어나지 않는다.
따라서 이러한 위험 요소를 줄이기 위한 방법은 다음과 같다.
위험 요소를 줄이기 위한 방법
-
복잡도 줄이기
-
문서화와 문서의 최신화
-
업무 교차 장려
추가적으로, 한사람에게 쏠리는 업무의 부담을 줄여야한다. 이를 위해 인력의 충원이 필요하지만 상황이 여의치 않다면, 위의 3가지 방법을 적극적으로 사용해야한다.
규모가 작은 스타트업의 경우, 한사람이 한가지 주요 업무를 담당하기 때문에 인력이 교체될때 많은 리스크를 동반한다. 따라서 모든 구성원이 자신이 담당하는 업무에 대한 인수 인계서나 문서를 ‘자세하게’ 작성하는게 가장 좋은 방법이며, 이는 후임이나 동료가 업무를 인계 받았을 때 막힘이 없어야한다.
결론, 나에게 하는 한마디
개발을 하면서 문제를 최대한 빨리 발견할 수 있도록 최대한 누군가의 조언을 구하거나 미리 내용 공유를 해서 머리를 맞댄다. 혼자 고민하고 앓다가 내보내더라도 문제가 있을 가능성이 높다!
읽어 볼만한 글