개발자들은 자신이 작업할 일에 대해 추정해야 할 기회가 많습니다. 쉽게 말해 "이거 개발하는 데에 얼마나 걸리겠어?"에 대답하는 겁니다. 사업의 성패가 이 추정에 크게 의존하는 경우가 흔합니다.

소프트웨어공학에서는 수십년의 연구를 통해 이 개발자 추정의 정확도에 영향을 미치는 요소들을 찾아내었습니다. 이 주제 하나만으로 AC2의 하루 워크숍 꺼리이긴 한데, 그 중 추정이 엉망이 되게 하는 비결 몇가지를 소개해 볼까 합니다.연구를 통해 위 방법을 사용하면 개발자 추정이 지나치게 낙관적으로 나오며(개발자 추정은 대부분의 경우 낙관적이라고 분석됨) 따라서 정확도가 떨어진다는 발견이 나왔습니다.

보시다시피 아주 사소해 보이는 것들에도 영향을 받습니다.좀 어처구니가 없다 싶죠. 흥미로운 부분은 요구사항명세서(SRS)의 내용이 어떤가와 상관 없이 추정에 영향을 미치는 요소가 많다는 점이죠 -- 좋은 SRS에 대한 환상(즉, SRS를 논리적으로 잘 쓰면 소프트웨어 개발이 잘 될거야)이 있는데 이게 고전 경제학에서 보는 이성적 인간에 대한 환상과 겹치는 부분이 있습니다. 행동경제학에서도 말하듯이 사람이라는 것이 사실 그렇게 논리적, 이성적인 존재가 아니거든요.

예를 들어 위에서 폰트 크기 같은 경우, 완전히 동일한 요구사항 문서를 폰트 크기를 줄여서 전체 페이지 수가 줄어들게 하면 사람들은 요구사항이 비교적 간단하다고 착각을 해서 추정치가 줄어들게 됩니다.

그리고 아무리 시간이 없고 바쁘다고 하더라도 그걸 티내면 개발자들은 상대를 기쁘게 해주기 위해(혹은 상대를 기분 나쁘게 하지 않기 위해) 추정치를 무의식적으로 낮추게 됩니다. 그걸 간접적으로 하더라도(지나가는 말로 넌지시 언급하거나) 효과가 있습니다. 비슷한 것으로 기준치를 제공하는 것도 그렇습니다. 남들은 얼마라고 한다는 걸 미리 알면 사람들은 거기에서 시작해서 추정치를 조정하는 경향이 있습니다. 또 사소한 확장이라고 말하면 실제로 추정할 때 사소하게 생각해서 더 작게 추정합니다. 상대의 말에 영향을 받는 것이죠.

리스크 분석을 하게 되면 실제로 리스크가 주는 것은 아니지만 리스크가 줄었다고 착각하게 되어 마치 해결이 된 것처럼 생각하고 추정치를 많이 줄이게 됩니다. 리스크를 많이 나열한 것으로 리스크가 없어졌다고 생각하고 자신의 추정에 대한 확신도도 높아져 버립니다.

외부 평가자 없이 내부 평가로만 해도 추정치가 낮아집니다. 아무래도 내부자들만 아는 불완전한 지식/정보에 영향을 받고, 또 우리가 하니까 성공해야해, 혹은 성공할거라는 내부인들의 기대에 맞추려는 마음 등이 작용하게 되는 거지요.

이 비결들을 사실 마음 먹기에 따라 역이용할 수도 있습니다. 개발자들이 추정을 지나치게 낙관적으로 하게 해서 스스로 함정에 빠지게 하고 싶은 경우 -- 예컨대 예전에 추정한 것을 들이밀고 책임지라고 하거나, 야근하라고 하거나 -- 이 방법을 악의적으로 쓸 수 있습니다.

당연히 제가 기대하는 것은 이 방법들을 반대로 쓰는 겁니다. 본인이 개발자에게 일을 맡기는 사람이라면 이런 요소들을 고려해서 주의를 하고, 스스로 개발자라면 이런 요소에 영향을 받을 수 있다는 것을 인식하고 조심해야겠죠. 개발자 개인이 할 수 있는 방법이 여러가지가 있는데 이건 다음 기회에... ^^;

--김창준