소프트웨어 프로젝트 성공을 한마디로 말하면 다음과 같습니다.
"주어진 시간에 주어진 비용으로 요구된 품질의 제품을 만들어 내는 것"
여기서 가장 중요한 것은 시간과 비용입니다. 어차피 품질도 시간과 비용에 귀결됩니다.
소프트웨어 공학은 이 둘을 충족시키기 위해서 즉, 최소비용으로 최소시간에 소프트웨어를 개발하기 위해서 40년간 연구되어온 실전 학문입니다. 즉 연구소에서 연구만 한 것이 아니라 실제 프로젝트에 적용이 되면서 계속 발전해 온 것입니다.
이 문장에는 많은 함축적인 의미가 있습니다.
고객과 합의한 스펙은 만족했으나 최종 제품이 고객의 요구를 만족시키지 못하면 분석부터 잘못된 것이므로 진정한 성공으로 보기 어렵고, 개발과정에서 개발자를 너무 밤낮, 주말 가리지 않고 혹사해서 개발자가 몇몇 퇴사를 했다면 비록 종료 날짜는 지켰어도 시간과 비용 면에서 성공적이지 못하다고 할 수 있습니다.
하지만 몇몇 프로젝트에서는 프로젝트 성공을 절차를 지키는 것으로 굳고 믿고 있는 경우가 많습니다. 방법론의 프로세스를 따르고 그에 따르는 산출물들을 만들어내는 것을 중요하게 생각합니다. 특히 공공 프로젝트에서는 별 쓸모도 없는 문서를 많이 만들어 내야 하는 경우가 많은데, 담당자가 무슨 문서가 필요한지를 모르니 나중에 있을 문제를 회피하고자 대부분 그냥 모든 문서를 다 요구합니다. 문서를 봐도 뭔지 잘 모르고 그냥 책꽂이에만 장식을 해 놓고, 나중에 문제 생기면 어차피 개발자를 부를 것이면서 장식용 문서 또는 감사용 문서를 요구하는 것이지요. 또 중간에 감수도 있어서 중간에 요구하는 문서도 만들어내야 합니다.
이렇게 절차와 문서를 요구하는데도 잘 안되니 절차를 잘 안 지키는 것으로 생각하고 중간 마일스톤 단위로 또다시 점검을 하겠다고 하는 것인데, 무지가 가장 무섭다고 하는 말이 딱 떠오릅니다.
이런 환경에서 꾸준히 일을 하다 보니 개발자도 소프트웨어 개발에 꼭 필요한 문서가 뭔지 잘 모르고 문서를 제대로 만드는 훈련이 못하게 됩니다. 그리고 나서 자기 회사의 솔루션을 개발할 때는 헷갈리는 상황이 됩니다. 기존에는 갑이 요구하는 절차와 문서에 불평을 많이 했지만, 진짜 제대로 할 기회가 오면 제대로 하기 어려운 것입니다. 훈련이 안되어 있으니까요. 그렇게 부적합한 절차와 많은 문서를 만드느니 그냥 주먹구구식으로 똘똘 뭉쳐서 열심히 개발하는 것이 더 잘 됩니다. 이 방식으로 성공한 많은 선배들이 있으니까요.
소프트웨어를 왜 개발하고 있고 어떻게 하는 것이 성공적인 개발인지 다시 한번 생각해 봤으면 합니다.
