Bus Factor, 혹은 Truck Number

The TruckNumber is the size of the smallest set of people in a project such that, if one of them got hit by a truck, the project would be in trouble. Many people think this definition is broken; they're right

출처 : https://wiki.c2.com/?TruckNumber

 

(오늘도 개인썰로 시작해보는 포스팅)

우리 회사엔 Agile Core Team이라는 팀이 있다.

지금은 많은 회사에서 채택중인 Agile 방법론에 기초해서 프로젝트를 진행하는 팀이고

회사내에서 Agile 관련 프로세스의 Core적인 역할도 겸하고 있기에 저런 이름을 가지고 있다.

 

그리고 신입사원들의 입문교육기간 중 현장 체험 1순위로 꼽히는 곳이기도하다.

쉽게 이해 될 법한 표현으론...'SDS에도 이런 곳이?!'라고 정의할 수 있을 것 같다.

(실제로 신입사원들이 가장 희망하는 부서라고 들었다)

 

그리고 저 팀엔 Tuesday Talk 이라는 게 있었다.

'화요일 이야기'정도로 풀어낼 수 있을 것 같은 의미인데, 그냥 가볍게 이야기하는 자리라고 보면된다.

매주 화요일 점심시간에 어떤 주제에 대해 ACT의 누군가가 발표를 하고

듣고 싶은 사람은 도시락을 테이크 아웃 해와서 먹으면서 듣는거다.

 

여기서 적절한 표현을 찾지 못 해서 발표라는 표현을 쓰긴했지만,

각잡고 오랫동안 철저히 준비하고 딱딱한...그런 자리가 아니라

 

그저 내가 이런 거 해보니 좀 좋더라, 우리는 이런 거 하고 있다, 최근에 이거 해보고 싶은데 어떠냐, 와 같이 평소에 동료들과 담소하듯 나누던 주제들을 공유하는 자리다. 주제에 제한은 없으며 기술적인 부분이 아니라도 좋다. 뭐, 내 취미가 롱보드라면 스케이트 보드랑 롱보드는 뭐가 다른지, 왜 롱보드를 타게됐는지, 월터의 상상은 현실이 된다에서 나오던 롱보드씬은 나도 솔직히 무섭더라, 라던지.

 

월터는 아니지만...롱보드 다운힐 영상은 볼 때마다 대단해보인다. 저걸 어떻게 저러고 내려가......

너나할 것 없이 화자와 청자가 뒤섞여서 이런저런 소소한 이야기를 하는 자리고, 곁다리로 듣는 사람도 편하게 밥 먹으면서 한 귀로 듣고 한 귀로 흘려도 되는, 그런 이야깃자리다. 나는 ACT 소속은 아니지만, Tuesday Talk은 가벼운 자리니만큼 참가인원에 제한이 없었기에(별도 신청방법이 있는 것도 아니고) 흥미로운 주제가 공지되면 종종 가서 듣곤했는데...

 

그 중에 기억에 남는 주제가 바로 오늘 포스팅 거리인

Bus Factor 혹은 Truck Number라고 불리는 개념이다.

 

유럽여행을 하다보면, 장거리 버스를 타는 일이 허다하다.

때론 이동시간을 줄이고자 8시간 정도 걸리는 슬리핑 버스를 타고 도시에서 도시로, 혹은 나라에서 나라로 이동하곤한다. 보통 그런 장거리 이동용 버스에는 총 3명이 하나의 크루를 이룬다. 이 셋 중 한 명은 당연하게도 버스를 운전하고 나머지 한 명은 운전사의 바로 뒷자리에 앉아서 승객들의 불편사항을 듣고 처리해주거나 안내를 해주곤한다. 그러니까 각각 운전사 1과 승무원 1인 것이다. 그리고 여기에 나머지 한 명이 추가되는건데...이 사람은 매우 중요한 역할을 맡고 있다.

 

그 역할은 바로 쉬는 것이다.

 

그냥, 쉰다.

아무것도 하지않고, 쉰다.

때로는 잠도 자더라.

 

3명이 하나의 크루인데, 2명은 열일하고 나머지 1명은 쉰다.

저렇게 아무것도 하지않는데 왜 3인이 하나의 크루를 구성하는걸까.

 

사실 이 사람의 진짜 역할은 그냥 푹~잘 쉬다가 현재 운전 중인 버스 기사가 운전을 할 수 없는 상황이 됐을 때, 교대하기 위함이다. 즉, 장거리 운전이다보니 현재 운전 중인 사람이 졸릴 수도 있고 화장실이 급할수도있고, 혹은 뭐 다양한 돌발의 변수는 언제든 발생할 수 있기 마련이니까. 그럴때는 대비해서 미리 준비해놓는 예비인력인것이다.

 

그리고 이게 Bus Factor(Truck Number)의 핵심개념을 관통한다고 볼 수 있다.

 

만약 당신이 현재 진행중인 프로젝트에서 정말 중요한, 핵심 모듈을 만들고있다고 가정해보자.

근데 그걸 오롯이 당신 혼자 설계하고 개발하고 테스트를 하는 것이다.

정말 당신말고는 그 모듈에 대해서 아는 팀원이 1명도 없는 상황이다.

 

이런 상태를 우리는 Bus Factor가 1이라고 한다.

여기서의 1은, 이 버스에 몇명이 치이면 해당 프로젝트가 망하는가...에 대한 지수다.

 

사, 살려주세요....

즉, 혼자 모듈을 개발하는 당신이 버스에 치임으로써 해당 프로젝트는 아주 큰 리스크를 맞이하게 된다는 것이다. 그렇기때문에 너무 당연하게도 우리는 이를 미연에 방지하기위해 여러 대책을 세워둬야 하는 것이다.

 

가령 예를들면,

스크럼과 같은 활동을 통해 지속적으로 팀원간의 정보를 교류하거나

페어 프로그래밍을 통해서 하나의 피쳐를 둘 이상의 사람이 개발하거나

1인에게 역량이 뛰어나다는 이유로 업무를 과중시키지않거나.

 

...하지만 이런 대책들을 적으면서도 떠오르는 건, 이렇게 당연해야 할 활동들 혹은 그라운드 룰과 같은 서로간의 약속들이 프로젝트를 진행하다보면 대부분 지켜지지 못 한다는 현실이다. 특히나 여기에는 각자의 입장차도 섞여들어가게 되는데, 프로젝트를 관리하고 인력을 운영해야하는 PM의 입장에서는 하나의 모듈을 개발하는데 2명 이상의 개발자를 투입하고 싶지않을 것이다.

 

"2명이서 2가지의 일을 해야지, 왜 2명이서 1개를 같이 개발하냐?"

이는 내가 실제로 프로젝트 현장에서 들은 말이다.

물론, 다행히도 그 프로젝트에서는 누구도 버스에 치이지 않았다.

 

하지만, 나는 겪어보았다.

전배를 통해 이동한 선배의 일감을 온전히 받게 되었을 때.

그리고 그 선배가 혼자 그 모듈을 개발했을 때.

그리고 그 모듈에 대한 어떤 문서도 가이드도 설명도 없을 때.

그리고 나는 고작 입사 1년을 막 채운 햇병아리였을때.

 

그래, 확실히 많이 강해지긴했어...

지금 생각해도 아찔하기 그지없는 경험이었다.

물론 그때 그 고난이 나를 더 단단하게 해 준 건 사실이지만...

(요즘도 종종 그 선배와 그 당시 이야기를 할때면 고생한 몫만큼 치킨을 사달라고 하곤한다)

 

그렇기 때문에 Bus Factor 지수는 크면 클수록 좋다.

이 큰 값은 프로젝트의 리스크가 감소하는 지표로도 충분히 활용될 수 있다.

혹여나 내 옆 사람이 버스에 치이더라도, 그 사람이 하던 일은 나와 다른 동료들이 충분히 인지하고 과정을 알아왔던 일이기에 프로젝트의 일정 및 진척도엔 차질이 없을테니까 말이다(비유긴 하지만 내 동료가 버스에 치였는데 난 일을 해야하다니...말은 했지만 좀..음...그르네...)

 

물론 앞서 말했던 것과 같이 보통의 프로젝트들은,

그리고 내가 지원해왔던 프로젝트들이나 지금 하는 업무들까지도

Bus Factor가 2를 넘는 경우보다 1에 가까웠던 적이 훨씬 많았다.

 

우리가 해야 할 일은 많고, 우리는 늘 인력이 없으니까.

 

그나마 그동안 내가 현장지원을 하거나 종종 업무를 할 때, 홀로 수행해야 하는 경우들이 있었음에도 불구하고 Bus Factor 지수를 1보다 크게 가져갈 수 있었던 이유는 내가 가진 하나의 습관덕이라고 볼 수 있다.

 

데일리 로그(Daily Log), 라고 지칭하고 있는 이 습관은 일종의 일지(日誌)다.

2015년부터 2021년 11월인 오늘까지도 쓴, 내가 거의 매일 쓰고 있는 일지.

 

입사했던 2014년의 기록은...SI 프로젝트에서 해제될 당시에 PC 강제 포맷으로 사라졌다ㅠㅠ

나는 출근해서 PC를 켜면, 일단 어제 작성한 데일리 로그파일을 연다.

그리고 새 메모장도 하나 연다.

 

내가 어제 뭘 했고 어디까지했고, 오늘은 뭘 하려고 했는지가 어제 데일리 로그에 남아있다.

그리고 오늘 연 새 메모장에는 일을 하며 오늘 뭘 했고 어디까지했고,

내일 출근해서 무엇부터 할지를 적고서야 퇴근을 한다.

 

그렇게 쌓인 7년간의 기록은 내게 정말 많은 도움을 주었는데,

그 도움 중에 하나가 바로 Bus Factor 지수를 1보다 높게 올려준 것이었다.

 

가령 예를들어, 작년에 혼자 3개월정도 투입됐던 프로젝트가 있었다.

그 프로젝트의 핸들링은 다른 사업부가 하고, 나는 공통을 잡는 역할로 투입됐었는데

굉장히 타이트한 일정과 다난한 고객의 요구를 힘겹게 클리어하고 무사히 릴리즈 할 수 있었다.

그리고 올해 3월쯤, 그 프로젝트의 PM님이 올해 버전업을 준비하며 인력이 필요하자,

우리 부서에 다시 한 번 나를 파견해 줄 수 없는지 요청하셨던 적이 있었는데...

 

그 타이밍에 나는 규모가 제법 큰 다른 프로젝트를 지원하기로 약속이 되어있었기 때문에 다른 팀원이 해당 프로젝트를 지원하게 되었고, 나는 작년 프로젝트 투입시기에 작성해 둔 데일리 로그를 바탕으로 그 팀원에게 프로젝트의 전반적인 히스토리나 내가 지원했던 내용, 고객의 요청에 따라 변경한 세부사항과 같은 세세한 정보까지 손쉽게 전달할 수 있었다.

 

만약 내가 이런 데일리 로그를 기록해두지 않았다면,

혼자 투입되서 반년이상 진행했던 프로젝트이기에 Bus Factor가 1이었을 것이다.

그랬다면 아마 올해 투입된 팀원은 해당 프로젝트에 대한 세부 정보가 없는채로 투입되었을 것이고, 이는 곧 빠르게 빌드업하며 지원해야 할 프로젝트의 일정에 차질을 빚을 수도 있게되는 것이다.

 

하지만 3개월의 시간동안 나는 착실하게 데일리 로그를 정리해두었고 그덕에 내가 굳이 가지않더라도...즉, 내가 버스에 치였더라도 다른 팀원이 내가 작성해 둔 데일리 로그를 보고 프로젝트를 무사히 진행할 수 있기 때문에 Bus Factor가 1이 아니었던 것이다.

 

이처럼 어쩔 수 없이 일은 많고 사람은 적을 수 있다.

그러다보면 인력적인 운용부분에서 Bus Factor가 1에 근접할 수도 있지만,

앞서 말한 것과 같이 굳이 페어 프로그래밍이 아니더라도

매일 스크럼을 통해 서로가 하는 업무나 이슈사항등을 공유한다거나

혹은 하는 일들에 대한 메모 정도의 기록으로라도

 

팀원들과 함께 공유함으로써 우리는 Bus Factor가 1에 가까워지지 않도록 늘 유의해야한다.