이번 프로젝트는 제때에 끝낼 수 있을 것 같았는데
- 한 명의 관리자와 7명의 개발자가 있다.
- 관리자는 예술적인 칼놀림으로 프로젝트를 7개의 독립적인 일 덩어리로 잘라 개발자들에게 나누어줬다.
- 개발자들은 다른 개발자의 일에 관심을 둘 필요가 없다. 서로 분리된 일을 하면 된다.
- 프로젝트 중반쯤 되어 관리자는 최악의 마지노선을 긋고 개발자들에게 물어본다. “일정 안에 가능한가요?”
- 개발자들은 모두 가능하다고 답변한다. 7명이 각기 90% 확률의 확신을 갖고 있다고 답했다고 치자.
- 사실 어떤 일을 X일ㄹ 전에 끝낼 확률이 0.9라는 것은 상당히 높은 수치이다.
- 같은 일을 10번 반복했을 때 한 번 빼고는 모두 제시간에 끝낼 수 있는 정도라는 뜻이다.
- 이런 확률적 정의를 말로는 이해해도 본인이 확률적 답을 할 때에는 전혀 관계없이 답하는 경우가 흔하다.
- 예를 들어, “자신의 집에서 가장 가까운 지하철역으로 가는데 시간이 얼마나 걸릴까?”를 묻는다고 해보자.
- 누군가는 20분이라고 했다고 하자. 이 20분은 뭘 말하는 걸까?
- 이번에는 이사람이 집에서 지하철역까지 가는 실험을 수천 번 하고, 각기 걸린 소요 시간을 기록해서 확률 분포도를 그렸다고 해보자. 그래프는 어떻게 나왔을까? 아래 이미지는 그 예시이다.
- 먼저 주의해서 볼 것은 이 그래프가 대칭형이 아니라 비대칭이라는 점이다. ㅇ왜 그럴까? 지하철역까지 가는데 걸리는 시간은 1시간, 1일, 1년일 확률이 모두 0이라고 말할 수 는 없다. 가다가 교통사고를 당할 수도 있는 것이다.
- 하지만 0초 미만으로 걸릴 확률은 0이라고 말할 수 있다.
- 바로 여기서 문제가 발생한다. 통상 시간을 추정할 때 우리는 대푯값으로 최빈값(가장 빈번하게 나온 값)을 선택하는 경향이 있다.
- 그런데 이와 같은 비대칭 그래프에서 최빈값을 고르면 해당 시간 이하로 골인할 확률, 즉 이 그래프에서 A지점 좌측의 면적이 전체의 50%가 되지 않는다.
- 내가 20분 안에 골인할 확률은 동전 던지기보다도 못한 것이다 (동전 던지기는 확률이 50프로는 되기에..)
- 소프트웨어 공학 쪽의 연구에 따르면 사람들이 통상적으로 추정하는 소요 식나에 적어도 2~3배를 해야 80% 정도의 확률로 마칠 수 있는 시간이 나온다고 한다.
- 일반인들(심지어 의사 같은 전무가들도 포함)의 확률에 대한 직관이 형편 없다는 것을 고려할 때, 개발자들이 90%의 확률이라고 말했따느 것을 그대로 믿기는 힘들다만, 정말 이상적인 사황을 생각해보자.
- 실제로 각자의 확률이 90%였다고 치는 것이다.
- 다만 현실에서 사람들의 확률적 추정을 그리 믿을 수 없다는 것만 염두에 두고 넘어가자.
- 이제 관리자는 마음이 한결 놓일 것이다. 이번 프로젝트 진행이 잘되고 있구나 하고
- 하지만 이 관리자는 앞서 언급한 ‘빨간 돌 흰돌’ 게임의 오류를 그대로 저지르고 있는 것이다. (책 p179 참고)
- 각 개발자가 마감일을 지킬 확률이 0.9인데 모든 개발자가 마감일을 지킬 확률이 0.9라고 말하는 것은 아마 자신의 머릿속에서 0.9를 7번 더해서 7로 나눈 결과일 것이다. 이것은 평균의 악용이다.
- 이런 식으로 확률을 평균내면 안된다. 앞에서 말했찌만 우리는 대푯값을 취하는 경향이 있는데 여기에서 오류가 많이 생긴다.
- 이 경우 확률을 계산하려면 0.9를 7번 곱해야 한다. 그러면 0.48이 나온다. 즉, 모든 개발자가 90%의 확률로 안심을 하고 잇찌만 전체 프로젝트 입장에선 마감일에 맞출 확률이 동전 던지기에서 앞면이 나올 확률보다 안나오는 것이다.
- 게다가 일반적으로 일의 소요 식나을 추정할 때 사람들은 낙관적으로 추정한다는 편향에 대한 연구 결과가 많다는 점까지 고려하면 상황은 더 심각해진다.
- 학생들에게 논문 프로젝트의 완료 시기를 추정하게 했다. 99%의 확률로 언제 까지 끝낼 수 있는가에 대한 대답을 얻었다.
- 정말 그 기간 안에 끝낸 학생 수가 얼마나 되었을까? 그 학생들의 예측이 정확했땀녀 99%의 학생이 기간 내에 끄낼 수 있어야 한다.
- 하지만 실제로 45%의 학생만이 기간 내에 프로젝트를 완료할 수 있었다. 엄청난 차이이다.
- 또 다른 연구에 따르면, 사람들에게 가장 그럴싸한 추정을 부탁했을 떄와 자신이 기대하는 최선의 상황을 상상해서 추정해보라고 부탁했을 때 그 추정치는 큰 차이가 없었다.
- 설상가상으로, 프로젝트 절반 지점까지 햇던 일과 앞으로 해야 할 일의 종류가 너무 다르다. 이제 까지 분석, 설계, 밑부분 코딩을 진행해왔는데, 그것을 기준으로 미래에 있을 본격적 코딩, 테스팅, 디버깅, 배치 등을 추정하는 것은 매우 부정확하다. 추정은 과거의 일과 미래의 일이 판이하면 할수록 정확도가 떨어지는 경향이 있따.
- 분석, 설계, 테스팅, 디버깅은 질적으로 너무도 다른 작업이다. 이렇게 작업 단계로 나눠 일을 하면 단절 지점이 필연적으로 생기게 된다.
애자일 확률론
- 애자일 프로젝트라면 어떨까? 우선 워드 커닝햄의 영감 번뜩이는 다음 글을 보자.
- 어떤 관리자에게 12가지 할 일이 있고 그 일을 할 사람도 12명이 있다. 관리자는 어떻게 해야 할까?
대다수의 관리자들은 각자에게 한가지씩 일을 할당할 것인데, 이 경우에 병렬 진행이 최대화될 수 있다고 보기 때문입니다. 하지만 이것이 최고의 코드로 가는 가장 빠른 지름길일까요? 저는 그렇지 않다고 봅니다. 제 생각에는 관리자가 사람들에게 함께 작업하지 말라고 지시했을 겁니다. 그들이 따로 떨어져서는 할 수 없는 것을, 다 같이 모여서 도대체 무슨 일을 할 수 있을런지 그 관리자는 아마 상상조차 못할 것입니다. 그럴 수 밖에 없는 것이, 사람들이 하나의 문제를 해결하기 위해 각자의 경험을 동원할 수 있도록 허락했을 때 그들이 무슨 일을 할지 한 사람으로서는 상상하기가 무척이나 어렵기 때문입니다. 제가 선호하는 접근법은 관리자가 12명 모두에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것입니다. 그 일들이 완료되면 관리자는 할 일을 3개 더 만들어 냅니다. 사람들은 작업을 완료하기 위해 자기조직화(self-organize)할 수 있는 권한이 있고, 또 매번 다르게 조직화할 수도 있을 겁니다. 이 방식이 잘 돌아가는 이유는 사람들이 “관심사의 섞임”(mingling of concerns)을 통해 서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있기 때문입니다. 이런 식으로 학습한 지식은 관리자나 혹은 누구든 딱 한 사람이 모델링한 것의 위험을 피할 수 있는데, 그런 한 사람에 의한 모델링 때문에 모델 주도 접근법(model driven approaches)은 불리해 집니다. (워드 커닝햄, 우리는 팀인가요? 의 인용문 재인용)
Note: 여기에서 관심의 섞임이라는 표현은 전산학자 데이크스트라의 관심사의 분리(separation of concerns)를 빗대에 말한 것 같다. 관심사의 분리는 소프트웨어 설계의 중요한 원칙 중 중요한 하나로 각 모듈별로 다루는 사안들을 서로 분리하라는 의미이다. 다만 이 원칙을 사람 사이에도 적용하는 것은 협력을 저해할 수 있음을 경고하는 것이다.
- 애자일은 앞서의 고정적 방법과 달리 일을 공유한다.
- 각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않다.
- 애자일에서는 되도록 사람들이 섞이도록 한다.
- 이 경우에 확률적으로 어떤 현상들이 일어날까? 역시 7명이 있고, 모두 90% 확률로 확신을 한다고 해보자. 90% 확률이었따면 개중에는 일찍 끝내는 사람도 분명 있을 것이다(7명 중에 6.3명(7 * 0.9)은 데드라인 이내에 일을 끝낼 것이다.)
- 고전적 장법에선 내가 일을 빨리 끝내는 것이 이프로젝트에 큰 도움이 되지 않는다.
- 내 일은 내 일이고 다른 사람 일은 다른 사람 일이기 때문이다.
- 그래서 마감 시간에 맞춰 끝ㅌ나도록 일부러 일을 늘리는 경향도 생긴다.
- 하지만 애자일에서는 내가 일이 빨리 끝나면 다른 사람의 일을 도와준다. 가장 일이 밀려 있는 사람이 누구인지가 확연히 보이기 때문에 프로젝트에서 병목이 되는 사람을 도와주기 쉽다.
- 이렇게 먼저 일을 끝낸 사람이 나머지 사람들을 도와주게 되기 때문에 해당 시점에 나머지 사람들이 일을 제시간에 끝낼 확률이 높아질 것이다.
- 따라서 각기 제시간에 일을 마칠 확류이 90% 확률일때, 모든일을 제시간에 맞출 확률을 구한다고 0.9를 7번 곱할 수 없고 그보다 높은 확률이 되는 것이다.
- 게다가 애자일에선 지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게 된다. 그리고 그 좋은 정보는 각자의 일에 모두 도움이 된다.
- 서로 판이한 일을 하는 것이 아니고 관련성이 있는 것들을 진행하기 때문이다.
- 이런 새로운 지식, 깨달음은 프로젝트 속도를 높이는데 큰 도움이 되는 경우가 많은데, 애자일에서 이 확륭른 ‘또는’ 확률에 해당한다.
- 좀 더 자세히 설명하면 예컨대 7명 중에서 한 명이라도 중요한 발견을 하면 나머지 모든 사람이 그걸 공유해 함꼐 이득을 얻는 다는 뜻이다.
- 이와 반대로 고전적 방법에선 이런 좋은일이 생길 확률이 ‘그리고’ 확률이다.
- 모든 사람이 제 각기 꺠달음을 얻어야만 전체 프로젝트의 체감 성공률이 높아진다.
- ‘그리고’ 확률에서는 확률끼리 계속 곱해나가기 떄문에 팀 레벨에서 통찰을 통해 개선이 일어날 전체 확률은 기하급수적으로 떨어질 것이다.
- 하지만 ‘또는’ 확률은 그 일이 안 일어날 확률을 모두 곱해서 그 값을 1에서 뺴면 된다.
- 따라서 아까의 기하급수적으로 떨어지는 상황을 반대로 뒤집어서 확률이 올라가게 된다. 앞에서 이야기했듯이 사람들은 ‘또는’ 확률을 과소평가하는 경향이 있어서, 이 확률은 생각보다 훨씬 높은 것이다.
이와 관련된 저자의 경험담이 소개된다. 회사 전체가 자바로 개발을 하는데 각 팀별로, 각 개발자별로 담당 서버들이 있는데 회사에서 회사에서 자바 JDK 를 버전업하라고 기한을 몇 달을 줬다. 앞서 말한 파킨슨의 법칙처럼 사람들은 마지막 달에 버전업 작업을 시작했다. 당시 저자는 모팀의 개발자 자리에서 같이 페어 프로그래밍을 하고 있었는데 옆자리의 동료가 점심시간이라 자리를 뜨면서 화면을 흘긋 보더니 “어? 벚전업 작업하시네요? 고생 꽤나 하실 거에요” 하면서 나가는 것이었다. 그분은 알고 봤떠니 그 전주에 버전업 작업을 모두 마친것이었다. 하지만 옆에 앉아서 동료를 도와줄 생각을 아예 하지를 않았던 것이;다. 본인이 한 번 해봤으면 다른 사람을 도와줄 때 시간이 젋반도 안 걸맅넨데 말이다… 그러면 그 팀은 결과적으로 개발자 개개인이 동일한 시행착오를 겪어야 하는 ‘그리고’ 팀이라는 뜻이다.
- 그리고 여기에 더해, 애자일은 되도록 일 진해에 단계(앞서의 분석, 설계, 구현, 테스트, 전개 같은)를 두지 않으려고 한다. 단계가 있으면 시기에 따라 하는 일에 큰차이가 생긴다.
- 하지만 애자일은 마치 프랙털 구조처럼 부분 속에 전체가 들어가게 한다. 그렇게 하면 과거에서 미래를 점쳐보기가 훨씬 쉽다.
- 일이 진행되루솕 점점 추정 정확도가 높아진다. 대략 서너 번의 반복주기(iteration, 통상 1주에서 1달 사이)만 지나면 종료 가능 날짜가 고전적 방법에 비해 훨씬 더 정확히 예측된다.
- 이 방법을 통하면 사람들의 낙관적 추정 편향도 피해 갈 수 있다.
- 애자일은 좋은 일에 대해서는 ‘그리고’ 확률을 ‘또는’ 확률로 바꾸고, 나쁜 일에 대헛는 ‘또는’ 확률을 ‘그리고’ 확률로 바꾸는 경향이 있다.
- 좋은 일은 공유를 해서 한 사람만이라도 중요한 통찰이 있었따면 이걸 공유해서 ‘또는’ 확률로 만들고, 버그 같이 나쁜 일에 대헛는 여러 사람이 중복 검토를 해서(페어 프로그래밍, 코드 공유, 퀵 디자인 세션, 코드 리뷰 등) 모두가 실수해야지만 구멍이 나게 ‘그리고’ 확률로 바꾸는 것이다.