개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까?
Language 기초를 다시 가르칠까요?
UML을 가르칠까요?
문서 작성법을 훈련 시킬까요?
개발방법론을 가르칠까요?
팀워크를 키워줄까요?
OOP를 가르칠까요?
어떻게 하시겠습니까?
나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다.
즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement engineering을 제대로 알고 잘 작성한 스펙문서는 별로 접해보지 못했습니다. 또한 그로 인해서 프로젝트나 제품에서는 수많은 문제들이 야기되고 있었습니다.
물론 스펙을 제대로 쓰기만 한다고 소프트웨어를 잘 개발할 수 있는 모든 준비가 된 것은 아닙니다. 스펙을 쓰는 것은 이제 소프트웨어 제대로 된 소프트웨어 개발에 한 걸음 내디딘 것 뿐입니다. 거꾸로 스펙도 쓰지 않고 소프트웨어를 어떻게 개발하냐고 반문할 수 있습니다. 즉, 무엇을 개발할지도 모르고 여럿이서 소프트웨어를 어떻게 개발하냐는 것입니다. 또 영업이나 고객은 정확하게 무슨 제품이 나올지도 모르고 기다리냐는 것입니다.
하지만, 이에 대한 반론을 얘기하는 사람도 꽤 됩니다. 기존에 제대로 된 스펙 없이도 훌륭한 제품을 많이 탄생했고, 성공한 제품도 꽤 된다고 얘기합니다. 물론 예외는 항상 있습니다. 저도 몇몇 그런 사례를 알고 있습니다.
정확하게 따지면, 그렇게 성공한 제품은 별로 많지는 않습니다. 그리고 초창기에 제품의 크기가 작거나 고객 수가 작을 때는 멋진 제품이었으나 매출이 늘고, 소프트웨어 규모가 커지면서 망가진 제품도 꽤 많습니다. 즉, 스펙의 부실로 혼동에 빠져서 실패한 제품이 꽤 됩니다.
제대로 된 스펙도 없는 제품이 성공할 확률은 잘 작성된 스펙을 토대로 개발하고 유지보수 되는 제품의 성공확률의 1/10도 안될 겁니다.
소프트웨어 개발자라면 스펙이 왜 중요하고, 스펙을 잘 적기 위해서 배우고 많은 노력을 기울여야 한다는 것을 알아야겠습니다.
PS) 가끔 우리나라가 소프트웨어 업계에서는 섬처럼 느껴지곤 합니다.
이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
