워터폴 개발 방식이 더 유용한 제품군이 있을까?
결론부터 말하자면 대규모 데이터를 연동하는 B2B 서비스, 금융 플랫폼이나 운영체제와 같이 한 번에 완제품을 출시하는 경우 워터폴 방식이 유용하다.
워터폴(Waterfall)
폭포수가 내려오는 것처럼 비즈니스 요구사항을 기반으로 기획, 디자인, 개발이 순차적으로 진행되는 개발 방식이다. 고객의 요구사항을 정리하고 실현 가능한 디자인의 형태와 개발 가능여부를 파악한 뒤 개발 우선순위를 정해 작업을 수행한다. 이후 요구사항에 맞게 잘 개발이 됐는지 검수를 진행한다. 정리하자면 다음과 같은 단계로 개발이 이뤄진다.
요구사항 정의 - 설계 - 디자인 - 개발 - 검수 - 배포
순차적 개발 방식인 워터폴 방식은 다음과 같은 장/단점을 가진다.
장점
개발 기한이 정해진 프로젝트에서 유용하다.
요구사항 및 개발 진행 사항을 기획자가 수시로 체크하기 때문이다.
작업속도가 빠를 수 있다.
기획단계에서 요구사항을 명확히 정의했기 때문에 요구사항을 토대로 개발 작업을 진행하면 되기 때문이다. 단계별 목표가 세분화되어 본인 할당 업무만 충실히 하면 된다.
단점
고객과의 즉각적인 커뮤니케이션이 힘들다.
워터폴 방식에서 고객이 관여할 수 있는 순간은 개발 과정의 처음과 끝에만 있다. 그렇다 보니 개발을 진행하는 동안 고객의 요구사항이 바뀐 경우 이를 즉각적으로 반영하기 어렵다. 수정 사항이 발생한다면 프로젝트에 투입되는 인원을 다시 산정하고 일정을 조율해야 하며 이에 따른 비용이 늘어난다.
수정 요청은 개발이 완료되어야만 가능하다.
개발 완료 전에 실제로 작동하는 모습을 보기 어렵다.
오히려 느릴 수 있다.
앞 단계 업무가 종료되기 전까지 다음 단계 작업을 할 수 없다.
처음부터 프로젝트의 결과가 명확한 경우 워터폴 방식이 가장 적합할 수 있다. 워터폴 방식은 다음 단계로 넘어가기 위해 각 단계에 대한 결과물이 필요하므로 프로젝트가 엄격한 규정을 충족해야 하는 경우에도 유용하게 사용될 수 있다.
