주변에서 Waterfall이 좋다 Agile이 좋다 등의 논쟁을 가끔 보게 됩니다.
하지만 Waterfall을 비교 대상으로 삼기에는 적당하지 못한 것 같습니다.
즉, 너무 극과 극의 비교입니다.
이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다. 하지만 Waterfall 방식은 소프트웨어 개발의 기본 원리를 이해하는데 가장 중요한 모델이고 다른 모든 개발 모델들은 Waterfall에서 파생해 나온 것들이기 때문에 Waterfall 방식을 이해하는 것은 소프트웨어 개발 기본 원리를 이해하는 것처럼 중요합니다.
순수한 Waterfall 모델은 다음 단계로 진행하기 위해 전 단계가 완벽하게 끝나야 하고 모든 결과가 문서로 작성되어야 합니다. 폭포를 거슬러 올라가는 것이 원칙적으로 불가능하므로 Waterfall 모델에서는 이전 단계로 거슬러 가는 것이 불가능하거나 비용이 아주 많이 들게 됩니다. 현실에서는 이를 제대로 적용하기가 어려운 이유는 대부분의 소프트웨어 프로젝트는 요구사항을 초기에 완벽하게 파악하여 고정하는 것이 불가능하기 때문입니다. 더 많은 시간을 들여서 요구사항을 완벽하게 해도 시간이 흐르면서 주위 환경이 바뀌고 경쟁자들이 새로운 제품을 내놓는 등의 이슈로 인해서 이미 만들어 놓은 요구사항은 쓸모 없어 집니다. 그리고 너무 많은 문서를 요구하기 때문에 문서 작성과 관리에 너무 많은 시간을 쏟아 부어야 합니다. 그리고 프로젝트가 끝날 때까지 진행과정을 거의 볼 수가 없어서 사용자의 요구사항이 만족스러운지를 프로젝트가 끝날 때까지는 알 수가 없습니다. 이 또한 큰 리스크입니다. 만약에 Waterfall 모델을 따라서 개발하고 있다고 말할 수 있는 회사가 있다면 제대로 적용하고 있지 않거나 화성탐사선을 만드는 회사일 것입니다. 모든 종류의 프로젝트에 딱 적합한 방법이 있는 것은 아니니까 어느 한 라이프사이클 모델을 엄격하게 따를 필요는 없습니다. 원리만 알고 있고 경험이 있다면 응용이 가능하니까요.
