워터폴
이라고도 불리는 폭포수 방식을 자세히 알아보자.
소프트웨어 개발 방식 중 하나로, 프로젝트를 선형적이로 순차적으로 진행하는 방법론이다. 이 방식은 보통 요구사항 분석, 개발, 테스트, 배포 등의 과정을 순서대로 진행하며 이전 단계가 완료되지않으면 다음 단계로 진행할 수 없다.
폭포수 방식은 주로 요구사항이 명확하고 고정적이며 변경 가능성이 적은 프로젝트에 적합하다.
하지만 개발 도중 요구사항이 변경되는 일은 너무 빈번하게 일어난다.
자바 테스트 프레임워크인 JUnit으로 유명한 켄트백의 저서 '익스트림 프로그래밍' 36페이지를 보면 아래와 같은 내용이 있다.
소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다.
이렇듯 우리는 항상 변화에 대응할 수 있는 시스템을 갖추고있어야한다.
그러한 방법이 애자일 방법론이다.
애자일 방법론이란 위에서 보았듯 폭포수 방식의 반대되는 개념이다.
프로젝트를 작은 단위의 작업으로 나누고, 일정한 주기마다 작업을 개발, 테스트하며 클라이언트의 피드백을 받아 보완하는 반복적인 방법론이다.
초기에 요구사항을 완전하게 정의하기보다는 변화에 대응하면서 진행된다. 작업은 짧은 주기인 스프린트 단위로 진행되며, 각 스프린트의 개발이 완료되면 결과물을 클라인트에게 제공하여 피드백을 받고 개선해나간다.
따라서 변화에 즉각적으로 대응이 가능하고 더 유연하게 개발이 가능하다.
스프린트: 프로젝트를 작은 주기로 분할하여 개발하는 방식의 애자일 방법론에서 작은 개발주기를 뜻한다.
하지만 이런 애자일 소프트웨어 개발 방식을 마치 퍼즐 맞추기처럼 조각 내서 개발하는것으로 오해할 수 있다.
5일동안 모나리자를 그리라는 요구가 있다고 가정하자.
위에 그림처럼 작업을 하게된다면, 그림이 완성되기전까지는 문제점을 찾기가 어렵다. 즉, 폭포수 방식과같이 결과물이 나온후에야 문제에 대응을 하게될것이다.
위와같이 첫 번째 날 그림을 그림의 일부분이 아닌 전체적인 스케치로 시작을 하였다. 완벽하진 않지만 짧은 시간안에 고객의 요구사항을 증명하는 개발을 한 것이다.
고객은 이 그림을 보고 배경과 손 위치의 수정을 요청했다.
2일차에는 고객의 요청사항을 반영하여 3, 4, 5일차까지 그림을 완성했다.
위에서 설명한 애자일 방법론과 같이 변화에 유연하게 대응하면서 작업을 완료할 수 있게 될 것이다.
애자일 방법론을 잘 실천하기 위해 사용되는 도구들이 스크럼, 칸반, Xp 같은 것들이다. 폭포수 방식, 애자일 방식의 차이점을 아래 표로 보자.
뚜렷한 정답이 없다 본인의 프로젝트에 맞는 방법을 선택해서 개발하자!
Reference
애자일이 무엇인가요?
워터폴이란?