들어가며
개발 관련 커뮤니티, 그리고 회사를 다니다 보면 "애자일하게 진행해", "폭포수 모델에서 애자일로 전환해야해" 라는 류의 이야기들을 종종 듣게 된다.
근데 대체 폭포수 모델, 애자일이 무엇인 걸까?
이번에는 이 알수 없는 단어들에 대해 알아보려고 한다.
소프트웨어 개발 방법론
소프트웨어 개발 방법론. 벌써 단어만 봐도 지루해지는 것 같다.
소프트웨어 관련 학과를 나온 사람이라면 한번 쯤 들어봤을 단어이다.
우리는 이를 간단하게 '소프트웨어를 만들 때(개발할 때) 사용하는 방법들의 종류' 라고 생각해보자.
폭포수 모델, 애자일 은 그 수많은 방법 들 중 하나이다.
폭포수 모델
보통 대학의 소프트웨어 공학 과목에서 이와 같은 단어를 쉽게 찾아 볼 수 있다.
어려워 보이지만, 간단하게 이름만으로 어떤 방식의 모델인지 쉽게 생각할 수 있다.
폭포수 모델, 영어로는 Waterfall Model으로 모든 과정을 순차적으로 하나하나 진행하는 방법론이다.
(실제 폭포의 모습, 위에서 부터 아래로 떨어지는 물을 볼 수 있다)
폭포는 다음 두 가지 특징을 보인다.
- 가장 위에서부터 가장 아래로 물이 내려간다.
- 물이 내려가는 도중에 다시 위로 올라가는 일은 절대 없다.
폭포수 모델은 위 같은 특징을 모두 가지고 있다. 폭포의 모습을 상상하며 아래 사진을 보자.
(정말 많이 본 '그 사진' 이다.)
이것이 폭포수 모델의 진짜 모습이다. 이것을 외울 필요는 없다. 어차피 검색하면 다 나온다.
(시험 보려면 외워야 한다.)
사진에도 볼 수 있듯이 계획 부터 운영·유지보수 까지 단계가 있으며, 모든 단계는 앞의 단계를 완벽히 완료한 후 진행되고 다시 돌아가지는 않는다.
(하지만 실무에서는 점검을 통해 결과에 결함이 있다면 전 단계로 돌아가기도 한다.)
폭포수 모델의 단점
자 이제 폭포수 모델이 뭔지 대략적으로 느낌이 온다.
정리하자면 폭포처럼 첫 단계부터 끝 단계까지 작업 순서가 정해져 있으며, 해당 순서는 변경 될 수 없다 라고 할 수 있겠다.
이것만 보자면 괜찮아 보이는 방법이지만, 사실 단점이 존재한다. 이 같은 단점으로 현재 트렌디한 개발 조직들은 폭포수 모델이 아닌 애자일 방법론을 사용하고 있다.
완벽한 문서가너무 많이필요해!!
문서를 작성하는 것은 나쁜 것이 아니다. 문서를 통해 새로운 사람이 정보를 알 수 있고, 유지보수에도 용이하기 때문이다. 그리고 문서가 잘못 작성되었거나, 기능이 변경되었으면 수정하면 그만 인 일이다.
그러나 처음부터 모든 상황들을 계획 하고 정의 하여 문서에 작성 하는 폭포수 모델은 다르다.
폭포수 모델은 앞서 작성한 문서들을 바탕으로 다음 단계가 진행되는 방식이므로 문서의 완성도가 매우 중요하며, 다음 단계로 넘어가면 수정을 하지 못하는 점도 한 몫 한다.
따라서 완벽한 문서 작성은 문서보다 개발에 더 익숙한 개발자들에게 부담이 되고, 프로젝트 진행 속도를 늦추게 된다.
이것 좀 추가해주세요. 안된다구요? 안되는데...
프로젝트를 진행하다보면 반드시 미처 생각하지 못한 부분이 생기기 마련이다. (다 사람이 하는 일이기에)
그러나 폭포수 모델은 변경되는 것을 수용하는 것이 어렵다.
그도 그럴 것이, 이미 저기 한참 앞에서 다 완벽히 정의해 놓은 것에 무언가를 추가한다면 다시 처음부터 설계해야 할 수도 있기 때문이다.
건물 1cm만 왼쪽으로 옮겨주세요! 별로 어렵지 않잖아요??
그 외에도 ‘실제 시스템 동작을 막바지 단계에서 확인 가능’, ‘위험 분석이 수행되지 않음’ 등의 단점들이 존재한다.
이쯤 되면 이런 이야기를 들어봤던 것이 이해가 될 것이다.
” 폭포수 모델은 개발 속도도 느리고, 버그 잡기도 어려운데 왜 써? 애자일하게 가!”
그럼 지금까지도 폭포수 모델을 사용 중인 조직들은 이것을 모르는 것일까?
모든 방법론들이 그렇듯, 폭포수 모델이 유용하게 쓰이는 상황도 존재한다.
즉, 케바케(Case-By-Case)라는 것이다.
폭포수 모델의 장점
혹시 이렇게 간단하게 작성한 폭포수 모델의 설명만 보고도 이해가 되지 않았는가?
이해가 잘 안된다면 설명을 잘 못한 것이겠지만… 일단 한 눈에 봐도 직관적인 방법으로 보여지는 건 확실하다.
이렇듯 폭포수 모델은 일상생활에서도 자연스럽게 활용하는 선형 모델로, 단순하고 이해가 빠르므로 새로운 인력이 충원되었을 때 빠르게 현장에 투입에 가능하다.
또한 문서가 매우 체계적으로 작성되어 있으며, 어떤 시점에 어느 정도의 진행 상황까지 도달했는지 쉽게 파악이 가능하다.
결론
폭포수 모델을 사용한다고 무조건 나쁜 것도, 애자일을 사용한다고 무조건 좋은 것도 아니다.
오히려 조직에 처한 사항을 고려하지 않고 무조건적으로 하나의 방법론을 고집하는 것이 프로젝트 진행에 있어서 매우 좋지 않은 선택이 된다.
이번 게시글에서는 소프트웨어 개발 방법론 중 폭포수 모델에 대해 알아보았다.
다음 게시글에서는 애자일 방법론에 대해서 알아보려고 한다.
+ 읽어주셔서 감사합니다.
+ 오타, 내용 지적, 피드백을 환영합니다. 많이 해주실 수록 제 성장의 밑거름이 됩니다.