설계문서, 사양서 없이 개발한다는 것.

설계문서, 사양서 없이 개발한다는 것.

건축물이 구축되려면 치밀한 설계도와 그 설계도를 준수하기 위해 필요한 공법까지 사전에 준비가 되어야 합니다. 설계 기술이 좋아져서 요즘은 설계도가 나오면 3차원 영상으로 미리 건물 내/외부를 이리저리 돌아다니면서 실제 건축된 후의 모습을 미리 볼 수도 있습니다.
건축물 뿐 아니라, 싱크대를 하나 짜더라도 어떤 디자인, 어떤 치수, 어느 자재를 사용할지를 사전에 설계를 하지요. 자동차, 기계, 그 어떤 가공물도 - 적어도 "제품"이라면 - 설계 없이 만들어지는 경우는 거의 없습니다.

소프트웨어의 설계 문서란, 소프트웨어의 전체적인 구조에서부터 특정 루틴에 이르는 소프트웨어 구현에 필요한 상세한 청사진을 말합니다(물론, 설계 문서의 종류는 다양합니다만.). 사양서는 설계 문서와는 다르게 소프트웨어가 어떤 역할을 하며 어떤 방식으로 동작한다라는 소프트웨어의 사양을 기술하는 비교적 간단한 문서입니다.

어떤 관리자들은 "바쁘기 때문에", 혹은 "시간이 없기 때문에" 이 문서들을 준비하지 않고 개발자들에게 개발을 시작하라고 합니다. 1~2억이 투자되는 소프트웨어 개발을 말이죠.

이렇게 되면 개발자들은 그야말로 "알아서" 개발을 시작합니다. 열심히 한 개발자는 나중에 열심히 새로 개발해야 하는 상황이 발생하고 얍삽한 개발자들은 어느정도의 결과물이 나오면 일단 소스 코드를 릴리즈를 하고 반응이 오면 고칠 준비를 하고 기다립니다. 자신이 작성한 소프트웨어가 "과연 그렇게 동작해야 하는가"하는 의문이 서기 때문이죠. ( 어느 쪽이든 욕을 먹지만, 후자쪽의 개발자가 욕은 더 많이 먹습니다. ) 결국 결과물은 어떻게 어떻게 해서 나오게 되지만 "이게 우리가 2억을 들여 만든게 맞습니까?" 하는 이야기를 듣게 됩니다.

설계서, 사양서는 개발 하면서도 계속해서 수정되고 릴리즈되어야 합니다. 마치 건축물 설계도가 그러하듯이 말입니다. 그리고 개발자들은 필요하다면 수정된 문서에 의해 자신의 소프트웨어를 변경해야 합니다.

뜬금없이 왠 설계, 사양서 얘기냐구요? 이런 생각을 하게 하는 일들이 있었거든요.
상황이 이랬거나 저랬거나 프로젝트는 완수해야죠. 오늘도 파이팅하면서 시작입니다! 즐프~