IBM®
메인 컨텐츠로 가기
    Korea [국가변경]    이용약관
 
 
   
        제품    서비스 & 솔루션    고객지원 & 다운로드    회원 서비스    
한국 developerWorks   >  dW Column  > developerworks

프로젝트 확률론



김창준김창준 juneaftn@hanmail.net

현재 애자일컨설팅 대표로 있으며 주로 소프트웨어 개발 조직의 생산성과 인간성 모두를 증진하기 위해 컨설팅, 코칭, 교육 등을 하고 있다. 애자일이야기라는 블로그를 운영중이다.

2008년 6월 24일


어디에 돈을 걸 것인가

글을 읽기 전에 우선 다음 두 문제에 답을 해보자. 하지만 종이를 꺼내들고 계산할 생각은 말자. 직관을 테스트하는 문제다. 다음 두 게임 중 어느 것이든 성공하면 100만 원을 상금으로 준다. 어느 게임을 선택하겠는가?

  1. 속이 안 보이는 주머니 속에 빨간 돌 5개, 흰 돌 5개가 들어있다. 임의로 하나를 꺼냈는데 빨간 돌이면 성공이다.
  2. 역시 속이 안 보이는 주머니인데, 이번에는 빨간 돌 9개, 흰 돌 1개가 들어있다. 꺼낸 돌을 다시 주머니에 넣으면서 총 7번 돌을 꺼내 색을 확인한다. 모두 빨간 돌이면 성공이다.

직관적으로 선택하자. 마음을 정했다면 다음 문제도 풀어보자. 역시 다음 두 개의 게임 중에서 어느 것이건 성공하면 100만 원을 상금으로 준다. 어느 게임을 선택하겠는가?

  1. 속이 안 보이는 주머니 속에 빨간 돌 5개, 흰 돌 5개가 들어있다. 임의로 하나를 꺼냈는데 빨간 돌이면 성공이다.
  2. 역시 속이 안 보이는 주머니인데, 이번에는 빨간 돌 1개, 흰 돌 9개가 들어있다. 꺼낸 돌을 다시 주머니에 넣으면서 총 7번 돌을 꺼내 색을 확인한다. 그 중 빨간 돌이 한 번이라도 나오면 성공이다.

이번 문제도 마음을 정했는가?


우리의 놀라운 직관

실제 이런 실험을 했고(Bar-Hillel, M., On the subjective probability of compound events, 1973), 대다수의 피실험자들은 첫 번째 질문에서 2번을 선택하고, 두 번째 질문에서 1번을 선택했다. 하지만 사실상 확률적으로 따져보면 첫 번째 질문에서는 1번이 더 유리하고(1번, 2번의 확률은 각기 0.5 대 0.48), 두 번째 질문에서는 2번이 더 유리하다(1번, 2번의 확률은 각기 0.5 대 0.52).

왜 그럴까? 첫 번째 질문에서 2번은 0.9라는 확률의 독립적 사건이 총 7번 발생해야 하기 때문에 0.9를 7번 곱한다. 0.9^7은 약 0.48이다. 두 번째 질문에서 2번은, 한 번도 빨간 돌이 안 나오는 경우의 확률이 0.9^7이므로 한 번 이상 나오는 확률은 1-0.9^7이 되어 약 0.52가 된다.

사람들은 통상 "그리고(and)" 조건의 사건들의 확률은 과대 평가하는 경향이 있고, "또는(or)" 조건의 사건들의 확률은 반대로 과소 평가하는 경향이 있다(Cohen, J. et al, A confirmation of the inertial-psi effect in sequential choice and decision, 1972).




위로


이 프로젝트 뭔가 느낌이 좋았는데...

이제 상황을 프로젝트로 바꿔보자.

한 명의 관리자와 7명의 개발자가 있다. 관리자는 예술적인 칼놀림으로 프로젝트를 7개의 독립적인 일덩어리로 잘라 개발자들에게 나누어줬다. 개발자들은 다른 개발자의 일에 관심을 둘 필요가 없다. 서로 분리된 일을 하면 된다. 프로젝트 중반쯤 되어 관리자는 최악의 마지노선을 긋고 개발자들에게 물어본다. 가능한가요? 모두 가능하다고 한다. 7명이 각기 90% 확률의 확신을 갖고 있다고 답했다고 치자. 사실 어떤 일을 X일 전에 끝낼 확률이 0.9라는 것은 상당히 높은 수치다. 개발자가 도중에 결혼할 수도 있고, 차에 치어 죽을 수도 있다. 잘못될 수 있는 경우는 무한하기 때문에 90% 정도면 굉장히 안전한 수준이라고 봐야 한다. 같은 일을 10번 반복했을 때 한 번 빼고는 모두 제시간 안에 끝낼 수 있는 정도라는 뜻이다.

관리자는 마음이 한결 놓인다. 개발자들이 고맙다. 진행이 잘 되고 있구나. 이번 프로젝트는 뭔가 잘 풀리려나 보다.

하지만 이 관리자는 앞서 언급한 ‘빨간 돌 흰 돌’ 게임의 오류를 그대로 저지르고 있다. 0.9가 각기 일곱 번 발생해 그걸 평균낸 값 0.9를 취하여, 이 프로젝트가 예컨대 3월 1일 이전에 끝날 확률은 90%라고 말하는 것은 평균의 악용이다. 확률을 평균내는 경우는 없다. 우리는 대표값을 취하는 경향이 있는데 여기에서 오류가 많이 생긴다.

이 경우 0.9를 일곱 번 곱해야 한다. 그러면 0.48이 나온다. 즉, 모든 개발자가 90%의 확률로 안심을 하고 있지만 전체 프로젝트 입장에서는 동전 던지기보다도 확률이 안 나오는 것이다.


그게 다가 아니라네

게다가 일반적으로 일의 소요 시간을 추정할 때 사람들이 낙관적으로 추정한다는 편향에 대한 연구 결과가 많다는 점까지 고려하면 상황은 더 심각해진다. 학생들에게 논문 프로젝트의 완료 시기를 추정하게 했다. 99%의 확률로 언제까지 끝낼 수 있는가? 정말 그 기간 안에 끝낸 학생 수가 얼마나 되었을까? 그 학생들의 확률이 정확했다면 99%의 학생이 그 기간 내에 끝낼 수 있어야 한다. 하지만 사실은 45%의 학생만이 기간 내에 완료할 수 있었다(Buehler, R., et al, It's about time: Optimistic predictions in work and love, 1995). 엄청난 차이다. 또 다른 연구에 따르면, 사람들에게 가장 그럴싸한 추정(best guess)을 부탁했을 때와 자신이 기대하는 최선의 상황(best case scenario)을 생각해 보라고 부탁했을 때 그 둘은 큰 차이가 없었다(Newby-Clark, I. R., et al, People focus on optimistic and disregard pessimistic scenarios while predicting their task completion times, 2000).

설상가상으로, 프로젝트 절반 지점까지 했던 일과 앞으로 남은 절반 동안 할 일의 종류가 너무도 다르다. 사람들은 사용자 기능 단위로 개발하지 않고 기술적으로 편리한 순서로 개발했다. 이제까지 분석, 설계, 밑부분 코딩을 진행해왔는데, 그것을 기준으로 미래에 있을 본격적 코딩, 테스팅, 디버깅, 배치 등을 추정하는 것은 매우 부정확하다. 추정은 비슷한 과거의 일을 기준으로 비교했을 때 상당히 정확해지는 경향이 있다. 하지만 과거의 일과 미래의 일이 판이하면 할수록 추정의 정확도는 떨어진다.




위로


애자일 확률론

애자일 프로젝트라면 어떨까? 우선 워드 커닝햄의 영감 번뜩이는 다음 글을 보자.

어떤 소프트웨어 관리자(manager)에게 12가지 할 일이 있고 그 일을 할 사람도 12명이 있습니다. 그는 어떻게 해야 할까요?

대다수의 관리자들은 각자에게 한 가지씩 일을 할당할 것인데, 이 경우에 병렬 진행이 최대화될 수 있다고 보기 때문입니다. 하지만 이것이 최고의 코드로 가는 가장 빠른 지름길일까요? 저는 그렇지 않다고 봅니다. 제 생각에는 관리자가 사람들에게 함께 작업하지 말라고 지시했을 겁니다. 그들이 따로 떨어져서는 할 수 없는 것을, 다 같이 모여서 도대체 무슨 일을 할 수 있을런지 그 관리자는 아마 상상조차 못할 것입니다. 그럴 수밖에 없는 것이, 사람들이 하나의 문제를 해결하기 위해 각자의 경험을 동원할 수 있도록 허락했을 때 그들이 무슨 일을 할지 한 사람으로서는 상상하기가 무척이나 어렵기 때문입니다.

제가 선호하는 접근법은 관리자가 12명 모두에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것입니다. 그 일들이 완료되면 관리자는 할 일을 3개 더 만들어 냅니다. 사람들은 작업을 완료하기 위해 자기조직화(self-organize)할 수 있는 권한이 있고, 또 매번 다르게 조직화할 수도 있을 겁니다. 이 방식이 잘 돌아가는 이유는 사람들이 "관심사의 섞임"(mingling of concerns)을 통해 서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있기 때문입니다. 이런 식으로 학습한 지식은 관리자나 혹은 누구든 딱 한 사람이 모델링한 것의 위험을 피할 수 있는데, 그런 한 사람에 의한 모델링 때문에 모델 주도 접근법(model driven approaches)은 불리해집니다.

-- 워드 커닝햄, 우리는 팀인가요?의 인용문 재인용

애자일은 앞서의 고전적 방법과 달리 일을 공유한다. 각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않다. 애자일에서는 되도록 사람들이 섞이도록 한다.

이 경우에 확률적으로 어떤 현상들이 일어날까? 역시 7명이 있고, 모두 90% 확률로 확신을 한다고 치자. 90% 확률이었다면 개중에는 일찍 끝내는 사람도 분명 있을 것이다. 고전적 방법에서는 내가 일을 빨리 끝내는 것이 이 프로젝트에 큰 도움이 되지 않는다. 내 일은 내 일이고 다른 사람 일은 다른 사람 일이기 때문이다. 그래서 일부러 일이 마감 시간에 맞춰 끝나도록 일을 늘리는 경향도 생긴다(파킨슨의 법칙이라고 한다). 하지만 애자일에서는 내가 일이 빨리 끝나면 다른 사람의 일을 도와준다. 가장 일이 밀려있는 사람이 누구인지가 확연히 보이기 때문에(정보 방열판 덕분이다) 프로젝트에서 병목이 되는 사람을 도와주기 쉽다. 그렇기 때문에 모두 90% 확률일 때 그냥 0.9를 일곱번 곱할 수 없다. 그래서 전체 확률이 그다지 떨어지지 않는다.

게다가 애자일에서는 지식 공유 덕분에 좋은 정보는 금세 모두가 알게 된다. 그리고 그 좋은 정보는 각자의 일에 모두 도움이 된다. 서로 판이한 일을 하는 것이 아니고 관련성이 있는 것들을 진행하기 때문이다. 이런 새로운 지식, 깨달음은 프로젝트 속도를 높히는 데에 큰 도움이 되는 경우가 많은데, 애자일에서 이 확률은 "또는" 확률에 해당한다. 무슨 이야기냐면, 예컨대 7명 중에서 한 명이라도 중요한 발견을 하면 나머지 모든 사람이 그걸 공유해 함께 이득을 얻는다는 뜻이다. 그래서 "또는" 확률이다. 앞에서 이야기했듯이 사람들은 "또는" 확률을 과소평가하는 경향이 있다. 이와 반대로 고전적 방법에서는 이런 좋은 일이 생길 확률이 "그리고" 확률이다. 모든 사람이 제각기 깨달음을 얻어야만 전체 프로젝트의 체감 성공률이 높아진다.

그리고 여기에 더해, 애자일은 되도록 일 진행에 단계를 두지 않으려고 한다. 단계가 있으면 시기에 따라 하는 일에 큰 차이가 생긴다. 하지만 애자일은 이와 반대로, 마치 프랙탈 구조처럼 부분 속에 전체가 들어가게 한다. 그렇게 하면 과거에서 미래를 점쳐 보기가 훨씬 쉽다. 일이 진행될수록 점점 정확도가 높아진다. 대략 서너 번의 반복주기(iteration, 통상 1주에서 1달 사이)만 지나면 종료 가능 날짜가 고전적 방법에 비해 훨씬 더 정확히 예측되는 경우가 흔하다. 이 방법을 통하면 사람들의 낙관적 추정 편향도 피해갈 수 있다.

애자일은 좋은 일에 대해서는 ‘그리고’ 확률을 ‘또는’ 확률로 바꾸고 나쁜 일에 대해서는 ‘또는’ 확률을 ‘그리고’ 확률로 바꾸는 경향이 있다.

참고 자료: 추단법과 편향에 대해서는 노벨상 수상자인 카네만과 트벌스키가 편저한 "불확실한 상황에서의 판단"(Judgement under Uncertainty: Heuristics and biases, 대우학술총서에서 역서가 나왔다)이라는 책을 참고할 것을 권한다. 이 분야의 고전 중의 고전이다.


이 문서 북마킹 하기

mar.gar.in mar.gar.in naver naver eolin eolin del.icio.us del.icio.us



위로


[지난 developerWorks Column 보기]

사이트 여행

dW 커뮤니티
포럼 | 블로그 | Spaces
dW Student Community

로컬 컨텐츠

행사 및 세미나

기획 기사

개발자 입문

튜토리얼 및 교육

TOP 10 인기자료

SW 다운로드

RSS 피드

뉴스레터
 
  
자바스크립트가 작동이 중지되었습니다. 이 기능을 수행하시려면 브라우저에서 자바스크립스트를 작동시켜 주시거나 이곳을 클릭해주세요.

Special offers
Screencast
IBM SOA Sandbox 시험판
dW Student Community
로보코드
코드 트레이닝


    IBM 소개 개인정보 보호정책 문의