소프트웨어 개발 방법론 중 가장 자주 비교되는 두 가지는 폭포수와 애자일이다.
폭포수 모델, 우리가 아는 그 의미 그대로 생각해보면 폭포의 위쪽에서 아래쪽으로 떨어지면 다시 위쪽으로 갈 수 없듯이, 개발이 다음 단계로 넘어가면 이전 단계로는 넘어갈 수 없다.
폭포수 모델은 이러한 특징을 가지고 있기때문에, 각 단계에서 결함이 없도록 하기위해 많은 공을 들이게 된다. 이는 즉 소프트웨어가 실제 사용자에게 제공되기까지 많은 시간이 소요된다는 뜻이다.
이러한 모델의 문제점은 다음과 같다.
1. 시장의 트랜드가 변할 수 있다.
2. 구체적으로는, 사용자의 니즈가 변할 수 있다.
3. 즉각적인 사용자의 피드백을 반영할 수 없다.
4. 결과물을 보기까지 오래걸려 개발자들의 사기가 저하될 수 있다.
5. 완벽한 기획과 설계란 있을 수 없다.
이러한 문제점을 해결하고자 나온 것이 애자일 방법론이다. 그래서 애자일 방법론은, 이름 그대로 민첩한, 기민한이라는 뜻을 가진만큼 사용자의 피드백을 빠르게 받아 소프트웨어에 적용하는 것을 자주하는 것에 초점을 두었다.
이 때, 사용자의 피드백을 받기 위해서 전체적인 소프트웨어를 전부 다 만들어서 제공하는 것이 아니라 배포할 수 있는 기능을 만들고 이러한 기능을 제공하여 피드백을 받아 개선한다.
그러나, “우리는 이거 피드백 받아서 개선하는 방법론을 사용하니까~ 우리는 애자일이야~” 라는 생각은 프로젝트 개발 속도를 지체할 수 있다는 단점이 있다.
이러한 점을 개선하고자, 스프린트 를 도입하게 된다. 스프린트는 1~4주 정도의 기간을 잡고, 기획부터 테스트까지 사용자 피드백을 받기위한 기능을 개발하는 하나의 사이클이다. 이러한 사이클을 여러 번 수행함으로써 기간을 정해 프로젝트 기간이 지체되지 않도록 할 수 있다.
지금까지 나는 어떠한 방법론을 가지고 개발을 해왔을까? 그리고 나는 어떤 방법론을 선호할까?
어린이와 치매노인을 위한 포켓 블랙박스라는 주제로 피보호자를 위한 라즈베이파이와 아두이노 기반의 기기 제작 및 보호자를 위한 파이썬과 장고 기반의 웹 서비스 개발을 진행한 적이 있다.
이 때에는, 개인정보침해는 어떻게 할 것인지 기기와 기기의 배터리 문제로 인해 웹 통신에서 stateless와 statefull 중 어느 방식으로 채택할 것인지와 같은 문제들에 대해 의견을 주고받으며 기획과 설계에 시간과 노력을 많이 들였다.
그러다보니, 실제 개발할 시간이 부족하여 기획과 설계에 힘을 쓴 만큼 표현하지 못해 아쉬움이 남았었다. 돌이켜보면 폭포수방식으로 개발을 했던 것 같은데, 한정된 시간에서 이러한 방식은 원하는 결과를 가져오기 힘든 것 같다.
감사하게도 산학협력 학부연구생을 하게되었고, 기업과 협력하여 실제 시스템을 개선해볼 수 있는 경험을 가진 적이 있다.
이 때에는, 1주일 혹은 2주일에 한 번 요구사항을 받고 필요시에는 데이터 모델 설계 및 작성을 하였다. 그리고는 교수님께 피드백을 받고 구현하고, 그 다음 회의 때 현업분들께 피드백을 다시 받고 수정하는 과정을 거쳤었다.
폭포수와 애자일 구분없이 가장 중요한 것은 도메인에 대해 이해하고, 전체 프로세스에 대해 명확히 알아야한다는 점이다. 그러나 그 당시의 나처럼 해당 도메인에 대해 처음 접했던 개발자의 입장에서는 애자일한 방식이 더 좋은 것 같다.
왜냐하면, 하나의 기능을 구현하고 빠른 시일내에 피드백을 받음으로써 사용자가 무엇을 원하는지 더 명확히 알 수 있고 프로젝트에 더 몰입할 수 있기 때문이다.
사람마다 다를 수 있겠지만, 나는 그렇게 느꼈다.
그렇기 때문에, 나는 서비스 제공 목적에서 설계를 중요하게 여기지만, 폭포수 모델보다는 애자일한 방식을 더 선호하는 것 같다.
폭포수와 애자일, 나는 어떤 방식을 더 선호할까