소프트웨어 공학- 소프트웨어 프로세스 모델의 이해

IT업계에서 일을 하기 시작하면서 내 인생을 통틀어 꽤 많은 공부를 했다.
컴공 출신이 아니였기에 가끔씩 주위 동료들과 대화나 회의 시에 튀어나오는 전문 용어들이 들릴 때마다 공부의 필요성을 느끼게 됐다.
컴퓨터 공학 계열 학생들은 어떤 과목을 배우는지 이곳저곳 대학 강의 목록을 검색해보니 "소프트웨어 공학" 은 필수인듯하더라. 그래서 나도 책 하나 사서 쭉 읽어 봤다.

선형순차 또는 폭포수 모델

책을 보면, "소프트웨어의 이해", "특징", "분류", "개발 프로세스" 등이 목차가 보이는데 많은 부분을 할애하는 것은 개발 프로세스의 세부 단계별 진행방식이다.
내가 포스팅하고자 하는 부분이기도 하다.

IT분야의 역사는 100년이 안된 상태다. 계속 진행형이며, 타 공학 분야와 분명 비슷한 점도 있고 다른 부분도 있다.
우리가 흔히 알고 있는 국내 대기업 "네카라구배" 는 아마도 애자일, TDD 등으로 개발을 하겠지만, 공공기관이나 제조산업 분야의 많은 기업들은(SI 프로젝트) 주로 "폭포수 모델" 프로세스로 프로젝트를 진행한다.
나 역시 20년 가까이 SI 분야에서 일을 했지만, 거의 모든 프로젝트의 프로세스는 폭포수 모델이였다.

폭포수 모델의 단점은 변화에 대응하기가 쉽지 않고, 요구사항 수집이 어렵다.

"고객들은 자신이 무엇을 원하는지 모른다." 처음에는 이 말을 듣고, 읽기도 하며 이해를 못 했다. 자신들이 이해를 못 하는 것을 만들어 달라니?... 뭐지?

그들은 전문가가 아니기 때문에 꽤나 추상적으로 결과를 예상한다. 어쩌면 너무 추상적이라 어디서 본 남의 시스템 또는 네이버? 쿠팡? 이런 웹서비스들을 막연하게 상상하고 있을 확률이 높다. 그런 뜻이라고 이해하면 되겠다.

내 경험으로는 고객들은 "꼭 무언가를 봐야 아이디어가 떠오른다".
고객들만 그런 것은 아니다. 개발자들도 결과물을 만들다 보면 이런저런 아이디어들이 떠오른다.
처음 시작할 때는 필요 없는 기능이라고 판단했지만 공정률이 꽤 지난 후에 꼭 필요한 기능이라는 것을 깨달을 수도 있다. 더블어 새로운 부가 기능이 필요할 수도 있다.

프로젝트가 진행되는 과정에서 새로운 요구사항의 변경이 일어나는 일을 난 당연하다고 생각한다. 사람이 계획하고 진행하는 일인데 어떻게 변경이 일어나지 않겠는가? 일어나지 않는 게 더 이상하다.
요구사항 변경이나 기능의 추가가 발생하게 되면 개발자들이 고스란히 피해를 입니다.

자신들이 원하는 것을 만들어 달라고 해서 분석/설계 역할을 하는 인원들이 인터뷰나 회의를 하고 요구사항 수집을 하지만 여기서부터 시간에 쫓긴다. 어떤 일이든 시간은 제한적이다. 특히 Task 성인 프로젝트는 더욱 그렇다.
만나는 고객들도 자신들의 업무를 잠시 뒤로 미루고 회의나 인터뷰를 하는 것이기 때문에, 회의 시간이나 인터뷰가 길어지면 집중력이 흐트러지기 일수며 끝은 자신들의 업무 불만으로 끝나는 경우가 허다하다.

그렇게 무엇을 원하는지 잘 알아듣지 못한 상태에서 일정을 체크하고 분석하고 디자인/설계를 한다.
이게 제대로 될 리가 없잖은가?

범용적인 업무들은 대부분의 회사가 비슷하니 기본 기능만 구현해도 프로젝트가 실패하지는 않는다. 하지만 일반적이지 않은 업무나 프로세스라면 실패 확률은 성공확률보다 높다. 특히 공공기관은 더욱 그렇다.

지금까지 적은 이야기가 우리나라 SI 프로젝트들의 어제와 오늘 그리고 앞으로의 문제점들이다.
그런데도 소프트웨어 공학의 폭포수 모델을 거의 모든 프로젝트들이 기본 프로세스로 이행하고 있다.

다른 대안은 정녕 없는 것인가?

다음 편에 계속...