당신의 소프트웨어 프로젝트가 망했음을 보여주는 10개의 신호(Top 10 Signs Your Software Project is Doomed)

출처 : DBguide

1. 처음 버전에서 너무 많은 것을 이루려고 하기(Trying to do too much in the first version)
2. 증명되지 않은 기술에 전적으로 매달리기(Taking a major dependency on unproven technology)
3. 든든한 재정적 지원을 받고 있는 회사 내부의 프로젝트와 경쟁하기 (Competing with an existing internal project that is either a cash cow or has powerful backers)
4. 모자란 개발자 수 (The team is understaffed)
5. “복잡한 문제는 복잡한 해결책을 요구한다” (“Complex problems require complex solutions”)
6. 스케줄 겁쟁이(Schedule Chicken)
7. 범위의 증가(Scope Creep)
8. 두 번째 시스템 신드롬(Second System Syndrome)
9. 진입전략의 부재
10. 해결책을 알지 못하는 문제와 씨름하기

데어 오바산조의 목록
5번 항목에 있는 “복잡한 문제는 복잡한 해결책을 요구한다”는 말이 의미하는 것은 이렇다. 프로젝트를 진행하는 사람들 중에는 간혹 ‘복잡한 해결책’을 구현하는 기쁨에 취한 나머지 해결해야 하는 문제보다는 문제의 ‘복잡성’ 자체를 목표로 삼는 사람이 있다. 문제를 일부러 복잡하게 만들어 놓고 기뻐하는 것이다. 이것은 매우 위험한 경향이다.

성공을 지향하는 프로젝트는 언제나 간결하고 안전한 방향을 취해야 한다. 프로젝트가 복잡한 해결책을 필요로 하는 상황에 빠졌다면, 그 프로젝트는 이미 실패의 길로 접어든 것과 다름없다. 문제를 단순하고 명쾌하게 정의하며, 최대한 해결 가능한 문제를 목표로 설정하는 것은 성공적인 프로젝트를 수행하기 위한 발걸음의 첫 번째이다.

6번 항목에 있는 ‘스케줄 겁쟁이’라는 표현은 오바산조가 아니라 피터 클락(Peter Clark)이라는 프로그래머가 처음 사용한 것이다. 이것은 프로젝트 일정의 지연을 초래하는 나쁜 소식을 입 밖에 꺼내기 두려워하는 사람들의 심리를 지칭한다. 프로그래머들은 종종 자신의 개발 일정이 설계에서의 실수나 치명적인 버그 때문에 지연되는 것을 말하지 않는다. 그들이 사용할 수 있는 핑계거리가 얼마든지 널려 있기 때문이다.

예컨대 사용자 인터페이스를 개발하는 사람이 GUI의 겉모습을 다듬을 시간이 필요하다고 말하는 것은 사실 설계상의 심각한 문제나 치명적인 버그를 감추기 위한 변명일 가능성이 높다. 서버의 모듈을 구현하는 개발자가 네트워크 관리팀의 지원이 없어서 모듈을 테스트하지 못했다고 말하는 것은 사실 자신의 일이 일정에 맞춰서 진행되고 있지 않다는 사실을 감추는 핑계에 불과할 수도 있다.

이러한 변명과 핑계는 대개 사소한 수준이지만 그들이 여러 사람들을 통해서 누적되면 프로젝트 전체 일정을 위기에 빠뜨릴 수도 있다. 문제가 생긴 당시에 솔직히 보고되었으면 유연하게 해결되었을 지도 모르는 문제들이 ‘스케줄 겁쟁이’들의 소심한 태도 때문에 큰 문제로 확대되는 것이다.

그 다음 항목은 ‘범위의 증가(scope creep)’다. 사실 이것은 어느 정도 불가피하다. 요구사항 분석, 개발, 테스트, 출시를 아우르는 소프트웨어 개발 사이클이 3개월이라고 하자. 가장 이상적인 상황에서는 요구사항이 결정되고 나면 고정되고, 개발자는 고정된 요구사항을 토대로 소프트웨어를 구현하고, 테스터는 소프트웨어를 테스트한다. 개발과 테스트가 끝나가는 무렵을 기준으로 보았을 때 고정된 요구사항은 3개월 전의 시장상황을 반영한다.
경험이 있는 개발자라면 잘 알겠지만, 이러한 상황은 현실에 존재하지 않는다. 시장은 하루가 다르게 변화하고, 시장을 반영하는 요구사항도 그에 따라 변화하기 때문이다. 프로젝트가 진행되는 도중에 요구사항이 바뀌고 범위가 늘어나는 것은 그래서 어쩔 수 없다. 하지만 모든 일에는 정도가 있는 법이다.

프로젝트가 마감일에 가까워질수록 요구사항의 변경과 범위의 증가가 초래하는 비용(cost)은 기하급수적으로 늘어난다. 그리고 그 비용이 어느 지점을 넘어서면 프로젝트 자체의 파국을 초래한다. 프로젝트가 망하는 것이다.


두 번째 시스템 효과
8번 항목인 두 번째 시스템 신드롬은 ‘두 번째 시스템 효과(second-system effect)’라고 불리기도 하는 내용이다. 영국 프리미어 축구와 같은 프로 운동경기에 보면 흔히 ‘2년차 신드롬’이라고 말하는 징크스가 있다. 많은 기대를 안고 데뷔한 선수가 처음 한 해 동안은 긴장도 하고 해서 잘 적응을 하는 것처럼 보였는데, 2년차가 되면 긴장이 풀리며 슬럼프에 빠지는 현상을 지칭하는 표현이다. 소프트웨어에도 이와 비슷한 경향이 있다. 상업적이나 대중적으로 성공을 거둔 소프트웨어가 있다고 하자. 그 소프트웨어를 계승하는 새로운 소프트웨어, 즉 후속작이 만들어질 때를 관찰해보면 소프트웨어의 설계가 필요이상으로 거창(grandiose)해 지는 경향이 있다.

전편을 뛰어넘겠다는 강박증이 작용하는 탓이다. 그렇지만 ‘복잡한 해결책’의 경우와 마찬가지로 지나친 거창함이란 프로젝트를 실패로 이끄는 확실한 지름길에 불과하다. 언제나 그렇지만, 아름다운 것은 단순한 법이다.

‘두 번째 시스템 효과’라는 표현은 프레드 브룩스(Fred Brooks)가 1975년에 쓴 <신비로운 맨먼스: 소프트웨어 공학에 대한 에세이(The Mythical Man-Month: Essays on Software Engineering)>라는 책에서 처음 사용했다. “일정이 늦어지는 프로젝트에 더 많은 개발자를 투입하면, 일정이 앞당겨 지는 것이 아니라 더욱 늦어질 뿐”이라는 브룩스의 법칙으로 유명한 그는 이 책에서 IBM 70xx 시리즈가 사용했던 간결하고 유연한 운영체제가 360 시리즈의 OS/360으로 넘어갈 때, 새로운 운영체제를 개발하기 위한 프로젝트가 실패를 겪을 수밖에 없었던 이유를 분석하여 많은 유용한 법칙을 정리해냈다.

브룩스는 훗날 <신비로운 맨먼스>를 가리켜서 “모든 사람이 이 책을 읽지만, 책을 읽은 다음 행동을 취하는 사람은 아무도 없다”고 지적하고, 그런 점에 있어서 이 책은 “소프트웨어 공학의 성경이다”라고 말하며 익살을 부리기도 했다. 맞는 말이다. 일정이 늦춰지는 프로젝트에 더 많은 개발자가 투입되는 음울한 풍경을 본 적이 없는 프로그래머가 도대체 어디에 있겠는가?


진입전략의 부재
9번 항목인 ‘진입전략의 부재’가 의미하는 것은 간단하다. 오바산조 자신의 설명에 의하면 그는 데모나 프로토타입 버전을 최종 제품으로 바꾸어내기 위한 구체적인 전략이 부재한 상태를 지칭하기 위해서 이 표현을 사용했다.

특히 그는 웹 2.0 시대에 수많은 신생회사들이 매체의 관심을 끌기 위한 목적으로 반짝거리는 데모 프로그램을 만들어내는 것에만 익숙하고, 데모 버전을 유용하고 진지한 제품으로 만드는 전략엔 서투른 점을 지적하고자 했다.

아무리 지금이 최종버전이 없이 베타버전만 존재하는 웹 2.0 시대라고 하지만, 최종 제품에 대한 고민이나 전략을 무시한 채 겉모습만 번듯한 데모 버전으로 관심을 끄는 회사나 개발자는 냉정한 의미에서 보면 일종의 사기를 치는 것이다. 그것은 스스로의 무덤을 파는 것과 다를 바가 없다. 진정한 제품을 위한 아이디어 없이 데모 버전의 화려한 치장에만 몰두하는 것은 자멸적 행위인 것이다.