버스 지수

최근 읽은 책, 나는 아마존에서 미래를 다녔다 에서 재미있는 지표를 접했다. 이름하여 버스지수 (Bus factor)인데. 이를 소개해보려고 한다.

개요

처음 이름을 들었을때
“출퇴근중 버스를 몇번 타야 할 까” 혹은 “출근까지 얼마나 걸릴까” 등을 모델링해서 회사 혹은 “특정 위치의 접근성을 표현하는 지표인가?” 라는 생각을 했지만 놀랍게도 아니었다.

버스 지수란, 아래 이미지처럼 사람이 버스 사고와 같이 불가피, 예측 불가능한 상황으로 인해 업무가 불가능할 경우를 가정한 팀의 업무 복잡도를 표현하는 방법으로, 사람에 따라서 (사고는 너무 극단적이니) 로또에 맞아 회사를 사직하는 형태의 로또 지수 혹은 트럭 지수라고 부르기도 한다.

Agile, 혹은 개발 프로세스, Risk management, Business management와 관련한 컨셉이지만. 꼭 해당 도메인이 아니더라도 적용할 수 있을 것 같아서 가볍게 소개해보려고 한다.

참고: 이 글에서는 버스 지수, Bus factor로 통일하여 부르겠다.

이런 짤도 있었다

조금 더 자세히 버스 지수에 대해 알아보자.

N명이 팀을 구성한다 라고 하면 1과 N사이의 값을 갖게 되는데,

만약 특정 업무를 진행하는데에 있어서 팀원들중 1명만이 맥락을 이해하고 있다면, 해당 1명이 사라지면 업무가 진행 될 수 없기 때문에, 이 경우 이 팀은 (이 업무는) 1이라는 버스 지수 값을 갖는다.

반대로 다른 업무에 대해서 M명이 컨텍스트를 가지고 있다면, 이 경우는 M 의 값을 갖는다. (M명이 전부 없어져야 업무가 중단)

번외로, 따로 정의되어 있지는 않았지만 보통 한 팀이 하나의 업무만 하는 경우는 없으므로 각 업무들의 버스 지수를 합쳐, minimum 이나 mean을 팀 단위로 사용 할 수 있을 것 같다.

이 상황에서 맨 오른쪽 사람이 퇴사해버리면, 핑크색 업무는 더 이상 진행될 수 없다. (Bus Factor = 1)

이론적으로는 모든 팀의 버스 지수가 팀 구성원수와 동일한게 최고지만. 여러가지 이유로 인해서 이는 불가능하고, 아마 아아아아주 잘 짜여진 팀이 아닌 이상 버스 지수가 1 혹은 2–3 정도이지 않을까? 라고 생각한다 (잘 짜여진의 방향은 잘 짜여진 팀 혹은 잘 짜여진 업무 프로세스가 될 수 있다.)

관련 리서치

실제로 이에 대해서 연구한 논문도 있었는데(…?), github에서 돌아가는 유명한 133개의 project들의 버스 지수를 계산했더니 65%의 프로젝트가 2의 값을 가졌다고 한다.

지수 계산을 위해 Github project의 코드 / 파일 목록에 대해서, 누가 변경 혹은 기여했는지를 추적했다. 그 결과 극소수의 프로젝트를 제외하고는 … (말잇못)

A Novel Approach for Estimating Truck Factors

What is the Truck Factor of popular GitHub applications? A first assessment

물론 방법론 자체도 상당히 많은 노력을 필요로 하지만 이 Paper의 진가는 다른 면에서 나타난다.

연구진은 추정한 버스 지수가 “실제”와 얼마나 유사한지 알아보기 위해서. 기어이 133개의 프로젝트에 속해있는 사람들에게 조사를 하면서 (empyrical 하게) 이러한 질문도 했다고 한다.

Bus factor를 어떻게 하면 올릴 수 있을까요?

그리고 그 설문 조사의 결과는 아래와 같다. (의역했다)

• 깔쌈한 문서화
• 시끌벅적한 커뮤니티
• 자동화된 테스트
• 코드 주석
• 읽기 쉬운 코드
• 이 일을 위해서만 고용된 개발자 (Found / Paid developer)
• 잘 짜여진 아키텍쳐와 디자인
• (프로젝트 자체의) 유명함
• 프로젝트 접근 권한 공유
• 라이센스
• 잘 설계된 튜토리얼
• 기타 등등

너무 당연한 이야기지만 버스 지수가 낮은 업무는 어려울 수 밖에 없고 오히려 쓰레기를 줍는 것처럼 모두가 할 수 있으면 버스 지수는 엄청 높을 것이다.

그러나 이는 “건강한” 팀 혹은 프로세스는 아니라고 생각하는데, 이를 위해 결국 어려운 일을 잘게 쪼개 두거나, 따라 할 수 있는 가이드를 잘 만들어두고 더 나아가 트레이닝 시키는 일이 필요하다고 생각한다.

동시에 이런 질문이 들 수 도 있다.

내가 전문적으로 하는 일을, “문서화”를 통해 다른 사람도 할 수 있게 해버리면 나의 Uniqueness가 떨어지는게 아닐까?

팀원들과 문서화의 필요성을 같이 이야기하면서도 했던 이야기지만, 대부분의 경우 이러한 걱정은 하지 않아도 된다.

1. 내가 하던 “전문적인” 업무를 다른 사람이 원래 내가 하던 만큼 하려면 많은 시간이 필요하다. 즉 이른 시간내에 완벽하게 대체는 거의 불가능하다.
2. 아는 것과, 하는 것, 그리고 설명 하는 것은 정말 정말 너무 다르다. 즉 “전문적인” 업무를 다른 사람이 참조해서 따라할 수 있을 정도로 가이드라인을 만드는 과정에서 내 스스로에게도 도움이 된다.
3. 다른 사람을 “전문가”의 영역으로 트레이닝 시키는 경험은 사실 장인(수제자) 혹은 교수(대학원생)가 많이 하는 방식이다. 이 경우 원래 해당 업무를 하던 사람들이 자리를 빼앗기는 경우.. 보다는 오히려 그 업무를 “뿌려버리고” 자신이 하고 싶은 업무, 혹은 또 다른 자신만이 할 수 있는 업무를 하는 경우가 더 많다.

이 외에 다른 이야기들도 했었지만. 기억이 나지 않으므로 생략하고, 이를 통해 우리팀에서 정했던 OKR을 짧게 공유하는 것으로 글을 마무리 지으려고 한다.

여전히 나는 OKR이 어렵다