11월 24일자 웹진 기사를 보면 타뷸라라사의 발매 연기 소식이 있었다. 당초 타뷸라라사는 상반기 초에 출시할 예정이었으나 하반기 이후로 연기한다는 내용이었으며 사실 이러한 발매 연기 소식은 개발자들이나 게이머들에게 있어서 (너무나 자주 듣는 소식이기에) 그다지 놀라운 소식에도 속하지 않는 통상적인 이야기 정도로 받아들이게 된다.

개발자 입장에서 본다면 ‘완성도를 높이기 위한 어쩔 수 없는 결정’이라고는 말하지만 모든 ‘개발일정의 지연’ 뒷면에는 ‘과도한 일정’이라는 공통적 기저 요인이 있기 마련이다. 일정이라는 요소는 프로젝트 결과물에 있어 아래 그림과 같이 절대적인 영향을 받게 된다.

대부분의 개발자들은 이러한 과도한 일정이 근래에 생긴 문제라고 생각할지도 모르겠으나 소프트웨어 개발 분야에서는 지나치게 낙관적인 소프트웨어 일정은 이미 오래된 전통인 것 같다. 1967년 진 블린스키는 “중대한 프로그램 문제는 모든 개발상의 문제를 재빠르게 처치해야 하는 응급 상태라고 단정 짓는 것에서 시작된다”라고 이야기 했고, 1970년대 프레드 브룩스는 “시간 부족으로 실패한 프로젝트의 수는 다른 모든 실패 원인을 합친 것보다 많다”라고 경고했으며, 1984년의 스콧 카스텔로는 “소프트웨어 공학에서 가장 큰 적은 기한의 압력이다”라고 말했다.

이러한 문제는 현재에 이르기까지도 매우 빈번히 발생되고 있다. 케이퍼스 존스는 중대한 소프트웨어 공학 문제 가운데 과도한 일정 압력이 가장 흔한 문제라고 강조하고 있다. 그는 “극단적인 마감 압력을 받으면서 일하는 것은 모든 개발자들에게 전통이 되어버린 지 오래다. 내가 알고 있는 프로젝트의 절반은 심지어 요구사항을 결정하기도 전에 일정부터 세워진다.” 라고 이야기했다.

그렇다면 비합리적이며 지나치게 낙관적인 일정 수립이 어떠한 영향을 미치는 지, 또 그 해결 방법은 어떤 것이 있는지에 대하여 알아보도록 하자. 난 이러한 탐구 노력들이 분명히 프로젝트의 정상적인 쾌속 개발에 긍정적인 영향을 줄 것이라 예상하고 있다.

과도한 일정 수립 사례

우리가 살펴볼 잘못된 전형적 일정 사례는 빌게이트의 MS가 추진한 윈워드 1.0 개발 프로젝트이다. 결론부터 이야기하자면 윈워드는 일정을 극단적으로 무리하게 세웠다. 윈워드는 결국 개발기간 5년과 개발자원 600月/인을 들여서 만든 코드 249,000 라인의 시스템이다. 통상적인 그 정도 크기의 최단 일정은 460일 정도로 예측하는 것이 옳다고 전문가들은 분석하였지만 빌게이트는 개발에 필요한 기간을 365일(1년)으로 강제 제한하였고 그 기간은 그 어느 최단 일정보다 65일이나 짧은 것이었다. (아래 표 참조)

보고일	출시예측일	예정잔여일수	실제잔여일수	상대오차
1984년 9월	1985년 9월	365	1887	81%
1985년 6월	1986년 7월	395	1614	76%
1986년 1월	1986년 11월	304	1400	78%
1986년 6월	1987년 5월	334	1245	73%
1987년 1월	1987년 12월	334	1035	68%
1987년 6월	1988년 2월	245	884	72%
1988년 1월	1988년 6월	152	670	77%
1988년 6월	1988년 10월	122	518	76%
1988년 8월	1989년 1월	153	457	67%
1988년 10월	1989년 2월	123	396	69%
1989년 1월	1989년 5월	120	304	61%
1989년 6월	1989년 9월	92	153	40%
1989년 7월	1989년 10월	92	123	25%
1989년 8월	1989년 11월	92	92	0%
1989년 11월	1989년 11월	0	0	0%

윈워드는 애당초 달성할 수 없는 목표를 세웠다. 빌게이츠는 팀에게 ‘우수한 문서 작성기 개발’과 ‘가능한 빨리, 가급적 12개월 안에’라는 지시를 내렸다. 개발팀이 받은 지시가 이 중 하나였다면 목표 달성이 가능하였을 것이다. 그러나 둘 다는 불가능한 일이었다.

무리한 일정 때문에 계획을 정확하게 세울 수 없었다. 표에서 보듯이 MS의 수석 개발팀들은 일정 예측을 10번이나 더하고 1년이 더 넘게 걸렸다. 프로젝트가 시작되고 첫 4년 동안 ‘잘되겠지’라는 막연한 기대로 인해 매번 일정을 잡을 때 마다 60%-80%가량이 연기되었다.

과도한 프로젝트 일정이 진행되는 동안 중도 이직률이 기록적으로 높았다. 5년동안 일반 개발자들은 물론이고 개발 수석이 4번이나 바뀌었다. 2번은 일정 압력에 따른 스트레스 때문에 그만두었고 나머지 한 명은 일정 강행에 따른 건강 악화로 그만두었다.

일정 압력 때문에 개발자들은 각각의 기능들을 대충 구현하였다. 품질이 낮고 안정적이지 않은 미완성이라는 사실을 알면서도 해당 항목을 완료로 보고하고 말았다. 결국 3개월 정도 걸린다고 예상했던 안정화에만 12개월을 소비하게 만든 것이다.

지나치게 낙관적인 일정을 수립하게 되는 근본 원인

게임 프로젝트 일정을 낙관적으로 세우게 되는 근본 원인은 깊고도 다양하다. 그 중 몇 가지를 여기서 제시한다.

• 경쟁작 출시, 연말, 방학 대목 기간에 따른 시장 외부적 기한
• 관리자가 예측된 일정의 범위를 인정치 않고, ‘최단의 경우’ 예측 일정만 믿으려 할때
• 일정이 촉박하면 개발자가 더 열심히 일한다고 믿고 그에 따라 일정을 잡을 때
• 경영진이 특정한 마감 날짜를 요구하고, 프로젝트 관리자가 그들을 설득하지 못할 때
• 현실적인 일정으로 시작했으나 개발 도중 새로운 기능들이 끊임없이 추가될 때
• 프로젝트 관리자, 개발자 모두 프로젝트 일정 예측 방법을 모를 때

지나치게 낙관적인 일정이 미치는 영향

일정 압력 해소하기 >>