이카루스의 날개를 제외하면, 소프트웨어는 인간이 만든 가장 조악하게 만들어지고, 신뢰할 수 없으며, 유지하기 어려운 기술적 산물이다.
- Paul A. Strassmann
목차
0. 들어가며
1. 프로젝트 예측
들어가며
숲 속에서 숲을 바라보기가 어려운 것처럼, 우리가 항시 수행하고 있는 소프트웨어 개발 프로젝트이지만 프로젝트의 실체에 대한 바라보기란 쉽지 않다. 그러나 우리는 프로젝트에 대한 아무런 정보 없이도, 그 프로젝트가 제 날짜에 끝나지 못한다고 자신 있게 예상할 수 있다. 프로젝트가 제 날짜에 끝나지 않고, 프로젝트팀이 지속되는 야근에, 피곤에 젖어 사는 것은 너무나도 흔해서 굳이 천지신명의 도움을 받지 않아도 쉽사리 맞출 수 있는 것이다.
소프트웨어 개발 프로젝트가 이렇듯 힘든 작업이 된 데에는, 기존 제조업의 생산개념으로 소프트웨어 개발을 바라보는 시각 – 소프트웨어는 개발이지 생산이 아니다 -, 건축공사와 같이 프로젝트의 진척사항을 즉각적으로 바라볼 수 없는 비가시성 그리고 소프트웨어 산업의 짧은 역사로 인해 소프트웨어 개발 프로젝트의 실체를 제대로 바라보지 못하는 고객과 프로젝트팀의 인식 부족 – 메디컬 드라마나 소설을 통해 의사의 애환과 어려움에 대해서 우리는 더 많이 알지도 모른다 -등 많은 요인이 복합적으로 작용한다.
소프트웨어 개발 프로젝트의 실체에 대한 보다 정확한, 아니 보다 현실에 가까운 이해는 소프트웨어 개발 프로젝트의 성공을 위한 초석이 될 수 있다.
이 글은 몇몇 통계 자료를 통해 소프트웨어 개발 프로젝트에 대해 미처 생각지 못했던 또 다른 관점을 제공하고자 한다.
프로젝트 예측
개발 프로젝트의 진행과정 중 가장 난이하고 어려운 일은 프로젝트 규모 즉 비용에 대한 예측이다. 아무리 분석, 설계를 잘하고 개발을 잘한다 하더라도, 프로젝트 초기에 프로젝트의 대한 예측이 잘못되어 있다면 프로젝트가 정상적으로 수행될 수 없다.
프로젝트 비용 예측
그림 1은 우리가 주먹구구식으로 수행하고 있는 프로젝트 규모 산정이 얼마나 위험한 것인지를 보여주고 있다. 프로젝트의 제품설계가 끝난 시점에서도 오차가 무려 -20% ~ +25% 이다.
흔히 프로젝트 규모 예측은 전문가집단의 감에 따라 이루어지는 데, 프로젝트 고객의 성향, 요구사항의 끊임없는 변경, 프로젝트 개발팀의 능력, 개발 환경 등 너무나 많은 것이 프로젝트에 영향을 주기 때문에, 프로젝트의 규모를 정확히 산정하는 것은 천지신명의 도움을 받아야만 가능한 예술의 경지가 되어 있다.
그림 1 예측 값 수렴곡선 (Boehm, et al. Cost Models for Future Software Life Cycle Processes: COCOMO 2.0., 1995, p. 7)
이러한 오차를 조금이라도 줄이고자 한다면, 소프트웨어를 보다 구체화하고, 개발팀의 수행능력에 대한 통계적 데이터를 마련하는 등 오차를 줄이기 위한 지속적인 노력이 필요하다.
칠흑 같은 밤, 완전군장을 하고서 야간 행군을 나서게 되었다. 무반동 총이며, 포판이며, 중대원들이 그 무거운 것을 하나씩 들고서 계곡을 지나 산 정상에 도달했을 무렵이 새벽 4시.
늦가을이라 싸늘한 새벽공기에도, 땀을 뻘뻘 흘리며 겨우 산 정상에 도달했을 무렵, 저 앞에서 들리는 중대장의 목소리에 우리 모두는 앞으로 쓰러져야 했다.
"이 산이 아니갑다~"
프로젝트 개발에서 이런 일은 너무도 흔해서 놀랍거나 신기하지도 않다.
정말 아주 특이하게도, 다 지어진 건물의 창문 위치를 변경하는 것에 추가적인 비용이 드는 것은 누구나 이해하지만, 다 만들어진 프로그램을 변경하는 것에 비용이 든다는 것을 이해하는 사람은 극히 소수다.
프로젝트 일정 예측
프로젝트의 규모를 제대로 예측하기 어려운 만큼 프로젝트의 수행 일정 또한 제대로 맞추기가 어렵다. 따라서 일정 또한 확률론에 입각한 추정밖에 있을 수 없는 데 결국
"몇일쯤이면 프로젝트가 끝날 확률이 50%정도입니다."
라는 식만이 현실적으로 가능한 것이다.
그림 2 손익분기 일정수립 (DeMarco, Controlling Software Projects, 1982)1
그림 2는 Tom DeMarco가 제안했던 일정수립에 관한 그래프이다. 그래프의 면적이 프로젝트를 끝낼 확률을 나타내는 데, 불확실성 구간의 크기는 N지점(극소확률일자: 프로젝트를 완료할 확률이 0이 아닌 첫 번째 날짜)에 비해 통산 150~200%이다. 따라서 N이 25개월인 프로젝트의 경우 불확실성 구간의 끝은 75개월에 이른다.
Tom DeMarco의 경우 그림 2에서와 같이 일찍 마칠 확률과 늦게 마칠 확률을 50/50으로 잡을 것을 제안했다.
관리자라면 당연히 그림 3과 같이 이 불화실성 구간을 줄이고자 할 것이다. 그러나 이것은 개발 과정에 얼마나 많은 Noise2가 포함되는가에 따라 결정된다.
그림 3 불확실성 구간이 작은 예 (DeMarco & Lister, Waltzing With Bears: Managing Risk on Software Projects, 2003, p. 92)
일정을 어떻게 잡을까에 대한 연구가 진행되었는데 간략하게는 아래의 공식을 사용할 수 있다.
일정(개월) = 3.0 * (ManMonth)^(1/3)
프로젝트에 65 Man-Month가 든다고 예측하였다면 12개월(3.0 * (65)^(1/3))이라는 최적 일정을 얻을 수 있다. (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 189)
프로젝트 규모에 대한 이상적인 자원 투입
프로젝트 규모의 산정이 어렵고 프로젝트의 진행에 따라 변경될 수 있다는 것을 인정한다면 당연히 프로젝트에 투입되는 자원 또한 프로젝트의 규모가 변경되는 것에 맞춰서 변경되어야 한다. 그것이 합리적이지 않나? 그러나 Turnkey방식이라는 미명하에 개발사가 모든 것을 책임지는 분위기에서는 초기 할당되는 인력과 자원은 고정시켜 두고서 요구사항만 한 없이 늘어나는 게 현실이다.
그림 4 소프트웨어 진행에 따른 자원변화 (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 177)
프로젝트 비용과 일정
그림 5 비용과 일정과의 관계 (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 198)
프로젝트 수행에 있어서 더 이상 단축하지 못하는 최단일정이란 것이 존재한다.
예컨대, 한 명이 일주일 동안 개발해야 하는 프로그램 1,000줄을 5명이 하루에 개발할 수 있을까? 40명이 1시간 내로 개발할 수 있을까? 산모 10명을 데려다 놓는다고 해서 1달 안에 아기가 태어날 수는 없다
또한, 일정을 통상적인 일정보다 짧게 잡으면 비용은 급속하게 증가한다. 일정을 줄이고자 하면 단순히 개발자 수나 초과 근무량을 늘여서 일정을 줄일 수 있다. 그러나 그림 5에서 보듯이 개발기간의 단축에는 엄청난 부하가 든다. 의사소통 부하와 관리 부하가 커져서 상대적으로 비효율적인 인력충원 패턴을 써야 하기 때문이다. (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 197)
일정압축에 따른 비용에 대해서는 일반적으로 찰스 사이몬의 연구결과 (Symons, 1991)을 사용할 수 있다.
일정 압축률 = 원하는 일정 / 초기 일정
압축한 일정 노력 = 초기 노력 / 일정 압축률
프로젝트 초기 일정을 12개월로 예측했고 10개월 안에 완료하고 싶다면 압축률은 0.83(10/12)가 된다. 초기 노력 예측값이 70 Man-Month였다면 70/0.83을 하여 94Man-Month가 나오게 된다. 17%의 일정을 줄이고자 한다면 34%의 인력을 충원해야 한다. 물론, 이것은 개발환경이 동일하다는 가정하에서의 일이다.
대부분의 연구 결과에 따르면 아무리 인력을 투입한다고 해도 25%이상의 압축률은 불가능한 것으로 결론짓고 있다.
목차
0. 들어가며
1. 프로젝트 예측
