애자일 vs 폭포수 모델

오늘 개발자들과 소프트웨어 개발론에 대해 이야기했다.

 

애자일 방법론이 더 좋은가? 폭포수 모델이 더 좋은가? 어떤 방법론을 더 선호하는가?

 

내 의견은 애자일 방법론이 더 좋다! 였다.

사실 원래는 폭포수 모델을 더 선호했다.

폭포수 모델을 채택했던 회사에서 인턴 근무를 해서 그런지 폭포수 모델이 더 익숙하기도 하고 개발 진행 상황을 파악하고 정리하기 편하다고 생각했다.

특히, 나는 계획과 문서화를 매우 좋아하는 사람으로써... 폭포수 모델과 같은 명확한 단계가 있는 방법론이 더 좋았다.

 

그런데 직접 프로젝트에 참여하여 개발을 하면서 생각이 많이 바뀌었다.

스터디 관리 앱 Modi 프로젝트에서 처음에는 폭포수 모델로 시작했다.

PM이 기획을 하고, 그 다음으로 디자이너가 디자인, 개발자가 그 다음으로 개발을 진행하는 식으로 세미(?) 폭포수 모델로 시작했다.

그런데 기획이 끝나고 디자인으로 넘어갔을 때, 기획에 많은 구멍이 발견됐다. 그래서 다시 기획 단계로 돌아갈 수 밖에 없었다.

그 이후로도 개발을 하면서 기획과 디자인에서 매우 많은 구멍이 발견되었다.

 

즉, 프로젝트를 하면서

"아.. 완벽한 기획이라는 것은 불가능하구나..."

라는 것을 깨달았고, 그 이후로는 애자일 방법론을 선호하게 되었다.

 

대부분의 기획자가 그럴 것이라 예상하는데, 개발 경험이 없는 기획자가 만든 기획서에는 반드시 구멍이 있을 수 밖에 없다는 것을 깨닫고 원활한 협업을 위해서라도 애자일하게 개발하는 것이 마음 편하게 개발을 할 수 있다고 생각하게 됐다.

 

---

혹시라도 소프트웨어 개발 방법론을 잘 모르는 사람들을 위해 간략하게 설명하자면,

폭포수 모델은 50년이 넘은 아주 오래된 방법론이다.

오래된 만큼 폭포수 모델이 적용된 사례가 많다.

이는 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 배포 -> 유지보수 단계로 진행되며, 첫 단계부터 마지막 단계까지 순차적으로 진행된다.

여기서 주목할 점은 폭포수가 역행하지 않듯 폭포수 모델의 단계는 매 단계가 완벽하게 완료된 후 다음 단계로 넘어가기 때문에 다시 이전 단계로 돌아올 수 없다는 큰 특징이 있다.

 

애자일 방법론은 폭포수 모델의 이 특징 때문에 등장했다고 봐도 과언이 아니다.

내가 경험했듯이 사람은 완벽할 수 없고, 따라서 인간이 폭포수 모델의 매 단계를 완벽하게 해낸다는 것은 거의 불가능에 가깝다.

그래서 모든 단계를 완벽하게 해내기 위해 많은 인력이 필요하고 유지보수가 쉽지 않다는 단점이 있다.

 

애자일 방법론은 핵심적인 기능을 빠르게 개발하고, 고객의 피드백에 빠르게 대처할 수 있다.

보통 2-4주 정도의 짧은 주기로 개발을 진행한다.

뭔가 좋아만 보이는 애자일 방법론에도 치명적인 단점이 있는데 바로 개발 기간이 무한대로 길어질 수 있다는 것이다.

폭포수 모델에서와 달리 애자일 방법론에서는 개발자들이 피드백에 대해 오픈 마인드를 가지고 있다.

즉, 고객의 피드백을 모두 반영할 생각을 가지고 있기 때문에 고객의 요구사항이 변하면 또 변하는대로 개발 기간이 무한히 길어질 수 있는 것이다.

이러한 단점을 해결하기 위해 "스프린트"라는 개념이 등장했다.

 

---

이렇게 말하면 뭔가 애자일 방법론이 무조건 좋고, 폭포수 모델은 이제 구식인 방법론인 것 같지만 아직도 폭포수 모델을 쓰는 곳은 많다.

특히 큰 기업일수록 결재 라인을 타기 위해서는 폭포수 모델이 편할 수도 있을 것이다.

어떤 방법론이든 각각의 장단점이 있으니 필요에 따라 선택하여 개발하면 될 것 같다.

그런데 일단 나는 애자일이 더 좋은걸로...!