소프트웨어 프로젝트가 실패하는 가장 큰 요인..

인류는 소프트웨어 개발을 시작한지 이미 수십년이 지났다. 그 기간동안 다양한 개발 기법이 탄생했고 실제 실무에서도 상당한 결과물들을 만들어 온 것도 사실이다. 하지만 과거나 지금이나 개발자들은 항상 고통에 쌓여있고 개발 과정에서의 스트레스로 골머리를 앓고있다.

수십년동안 진보하지 않은 것인가?

결코 그렇지 않다. 인류가 진화해 왔고 그 진화속에 기술들이 한 축을 형성하며 인류 진화에 이바지해 왔기에 소프트웨어 개발 역시 꽤 많은 진화를 거듭해 왔다고 보는 것이 맞을 것이다.

그럼에도 영원히 풀리지 않을 숙제처럼 개발과정에서 많은 문제점들이 노출되는 것도 사실이다. 이전글인 "사상 최고 또는 최악의 소프트웨어를 가르는 기준은?"을 보면 전체 소프트웨어 개발 프로젝트에서 약 25 % 정도의 소프트웨어가 완전히 실패했고, 50%의 프로젝트가 개발 기한을 넘겼으며, 대부분의의 프로젝트가 예산을 초과했다는 통계가 있다.

이런 일련의 소프트웨어 개발 실패는 인력 문제, 개발 범위 산출 문제, 스케줄관리 미흡.. 등 다양한 문제들 가운데서 나타나는 것도 사실이다 .

 

과거로부터의 경험을 활용하다.
우리는 과거로부터 이런 실패 사례들을 통해 좋은 경험을 얻어왔지만 이를 잘못이해하는 바람에 오히려 잘못 된 방법으로 프로젝트를 진행하는 경우도 발생한다 .

소프트웨어 개발과 관련한 통계에 따르면 중규모 프로젝트의 75%와 대규모 프로젝트의 90% 이상이 스케줄에 쫒기면서 일하게 된다고 한다. 이런 상황이 한국에서도 심화되다 보니 정상적인 업무 시간 이외에 초과근무는 당연시하는 현상이 일어났다.

기업은 오히려 이것에 문제의식을 가지고 개선해 좀 더 가치있는 프로젝트운영을 위해 기법과 프로세스를 정비하기 보다 직원들의 초과 근무를 은근히 바라는 상황까지 발생하고 있는 것이다.

이 과정에서 우리가 착각하는 것은 과거에 비해 더 큰 규모의 프로젝트를 진행하고 있기 때문에 새로운 기법이나 프로세스 개선이 쉽지 않다고 잘 못 판단하는 경우가 비일비재하다. 

과거의 예를 하나 찾아보자면 1966년에 완성 된 OS/360 개발의 경우 5,000명 가까운 인원이 투입이되었다. 그로부터 10여년 이상이 흐른뒤 Microsoft에 의해 시작 된 윈도우 NT 프로젝트는 3~4년에 걸쳐 1,500명의 인력을 투입해 개발했다.

과연 시간이 지나고 개발 코드의 양이 늘었다고해서 과거에 비해 개발의 양이나 범위가 더 커졌다고 느낄수 있을까?

우리가 이 과정에서 간과하고 있는 것은 5,000여명 이상이 투입되던 프로젝트가 1,500여명 수준으로 줄었다는 것이다. 우리는 과거의 경험을 통해 좀 더 프로젝트 관리를 원활하게 할 수 있는 방법을 찾았고 그것이 오늘날 초대형 프로젝트 속에서 지속적으로 성공율을 높일 수 있게 된 이유인 것이다.


그런데 왜? 급격하게 프로젝트 개발 성공율이 높아지지 않나?
소프트웨어 개발과 관련한 조사 자료들에 따르면 일반적으로 프로젝트가 크게 실패하는 요인은 요구사항에 있다고 한다. (요구사항 문제는 시스템 정의, 요구사항의 지속적인 변화 과정.. 등으로 시스템 디자인이 엉망으로 되는 문제를 일컫는다)

클라이언트는 늘 생각이 변하기 때문에 계약 당시와 프로젝트 진행과정 끝에가서는 프로젝트 완료 과정에까지 끊임 없이 새로운 것, 예상 불가능한 아이디어를 요구한다.

이것이 결국 프로젝트 성공을 어렵게 만드는 요인으로 작용한다는 것이다.

다만 이런 상황은 과거에도 끊임 없이 문제가 되어 왔다는 사실을 알아야 한다. 유명한 매니저들이 이 과정에서 문제점을 이야기 하는 공통적인 요소는 빠르게 만드는 것과 정확하게 만드는 것의 차이를 인지해야 한다는 것이다.

사용자의 요구가 많아지는 요소들을 생각해 보면 실제 시스템 설계시에는 예상하지 못했던 것들이 대부분 일 것이다. 설사 예상을 했어도 예상 범위를 넘어서는 요구들도 많을 것인데, 문제는 이 과정에서 대부분은 정확하게 개발하는 것보다 빠르게 개발할 요소를 찾다보니 이런 불특정한 요구에 쉽게 대응하기 어려운 취약 요소속에서 프로젝트 개발이 시작 된다는 것이다.


빠르게 개발하는 것과 정확하게 개발한다는 것의 차이..
정석적인 답이겠지만 3개월의 프로젝트 기간이 있다고 한다면 끝까지 좋은 프로젝트 성공율을 유지하는 팀은 설계에 시간과 공을 많이 들인다.

빠르게 만든다는 것은 빨리 만들어 사용자의 피드백을 받아 빨리 뜯어 고칠 수 있다는 장점이 생기지만 궁극에는 정확한 설계가 밑받침되지 않는 경우가 많아서 프로그램이 꼬이거나 오류가 발생해 시간이 지날 수록 최악의 문제를 발생시키는 경우가 많다.

최대한 다양한 예상 범위를 생각해 심도있게 설계와 시스템 디자인에 시간을 쏟고 프로그램 개발에 나머지 시간을 쏟을 수 있는 프로젝트 운영이 필요하다는 것이다.

앞으로 이 이외의 다양한 실무적 이야기들로 예를들어 주겠지만 필자가 오늘 하고자 하는 것은 빠르게 만드는 것보다 어떻게 빠른 피드백들을 반영 할 수 있는 완벽한 시스템을 만드느냐에 더 포커싱이 되어야 한다는 것이다.

개발 기법, 매니징, 방법론, 시스템 툴 사용의 문제등은 아주 작은 요소의 단위이다. 충분히 공부하고 노력한다면 어느정도 이런 요소들은 다른 기법을 제시하거나 매니징 툴을 바꾸는등으로 해결 할 수도 있다.

그러나 기본적으로 설계가 잚못된 시스템은 새롭게 프로젝트를 구성하는 것보다 개발이나 업그레이드가 지연되는 현상이 발생한다. 설계와 디자인에 70%의 시간을 쏟고 나머지 30%로 개발 할 수 있는 소프트웨어 개발에 대해 좀 더 심도있게 생각해 볼 필요성이 여기서 생기는 것이다.


이 글은 아이엠데이 IT 칼럼에 기도 된 글입니다.
http://www.iamday.net/apps/article/talk/762/view.iamday