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