[소프트웨어 공학] Waterfall 모델과 Incremental Development

 

 

 

워터폴 모델(Waterfall model)은 소프트웨어 개발 과정에서 가장 오래되고 널리 사용되는 개발 프로세스 중 하나입니다. 이름에서 유추할 수 있듯이 한 방향으로 흐르는 폭포처럼 이 모델은 각 단계를 순차적으로 진행하는 것을 특징으로 합니다. 워터폴 모델의 단계는 기본적으로 4단계로 명화하게 구분할 수 있으며 이는 요구사항 정의(requirements definition), 시스템 및 소프트웨어 설계(system and software design), 구현 및 단위 테스트(implementation and unit testing), 통합 및 시스템 테스트(integration and system testing), 그리고 운영 및 유지보수(operation and maintenance) 가 있습니다. 각 단계를 거의 완료해야지만 다음 단계로 넘어가는 것이 가장 큰 특징입니다.

워터폴 모델의 주요 문제는 프로젝트를 독립된 단계로 엄격하게 나누는 구조 때문에 발생합니다. 고객의 요구는 시시가각 변경될 수 있습니다. 특히 고객뿐만 아니라 현대사회처럼 빠르게 트렌드와 기술이 변화하는 환경 때문에 시스템에 대한 요구사항은 변경될 수 있습니다. 워터폴 모델에서는 만약 프로세스가 진행 중일 때 특히 설계나 구현 단계에서 요구사항에 대한 변경이 필요하면, 여러 단계를 거슬러 올라가야 하합니다. 마치 폭포를 거슬러 올라가는 이 모습은 종종 재앙적인 결과를 초래할 수 있습니다. 따라서, 변경사항이 자주 발생할 가능성이 있는 프로젝트에서는 워터폴 모델을 사용하는 것이 위험할 수 있습니다.

 

하지만 그럼에도 불구하고, 워터폴 모델은 대규모 시스템 개발에서 여전히 많이 사용됩니다. 이는 두 가지 주요 이유 때문인데, 첫 번째는 병렬 개발(parallel development)이 가능하기 때문이고, 두 번째는 관리가 비교적 쉽다는 점입니다. 병렬 개발이 가능한 이유는 요구사항이 명확하게 정해진 상황에서 분업이 쉽기 때문입니다. 또한 관리가 쉬운 이유는 명세사항을 문서화하여 다음단계로 넘어가기 때문에 명세사항 따른 변화를 트랙하기 쉽기 때문으로 여겨집니다. 

 

 

 

워터폴의 변경사항 요구에 취약한 단점을 극복하기 위해 또 다른 개발 프로세스가 나타났는데 이는 점진적 개발, 영어로 Incremental devleopment입니다. 

 

점진적 개발은 초기에 완전히 명확하지 않은 고객 요구사항을 기반으로 하여 개요에서 시작하여 점진적으로 완성되는 시스템을 구축하는 소프트웨어 개발 프로세스 모델입니다. 이 모델은 선형적 접근법인 워터폴 모델을 사용하기 어려운 경우에 특히 유용합니다. 점진적 개발에서는 제품의 각 버전을 완성될 때마다 시장이나 고객에게 선보일 수 있으며, 이를 통해 시스템이 최종 완성되기 전에도 운영을 시작할 수 있는 가능성을 제공합니다. 이 방식은 'time to market'이 중요한 요소로 작용할 때 효과적인 전략이 될 수 있습니다. 

 

Incremental model의 장점은 명확합니다. 첫째, 고객의 요구사항 변경을 상대적으로 적은 비용으로 수용할 수 있습니다. 프로젝트의 일부분만 짧은 사이클에서 개발되기 때문에 필요한 변경사항이 있으면 다음 버전에서 반영할 수 있습니다. 이는 적은 비용 뿐만 아니라 빠르게 변경사항을 개발하는 데에도 도움이 됩니다. 두번째 장점은 바로 빠른 피드백입니다. 고객의 변경사항뿐만 아니라, 실제 개발된 모듈을 확인하고 생기는 피드백도 존재합니다. 유저가 실제로 제품을 볼 수 있기 때문에, 특히 사용자 인터페이스(user interface)의 설계와 개발에 있어 유용한 피드백을 얻을 수 있습니다. 마지막 장점은, 고객에게 신속하게 소프트웨어를 배포할 수 있어 경쟁 우위를 점할 수 있습니다. 특히 현대사회처럼 시시가각 변경되는 트렌드에서 빠르게 배포하여 유저에게 전달하여 사업적으로 우위를 점하는 것이 가능합니다.

하지만 이 모델의 단점도 분명한 편입니다. 가장 큰 문제는 가시성 부족입니다. 모델의 반복적이고 짧은 개발 프로세스로 인해, 문서화가 어려운 부분이 있습니다. 요구사항 명세화 즉 문서로 기입하는 것은 정기적으로 갱신되어야 하는데, 점진적 개발처럼 빠르게 흘러가는 프로세스에서는 제대로 이루어지지 않을 수 있습니다. 명확하지 않은 문서화는 개발 과정의 관리가 복잡해질 수 있으며, 이후 시스템의 진화 그리고 버전 관리에서 문제를 일으킬 수 있습니다. 빠르게 대응한 결과 시스템 구조 자체가 약해질 수 있고, 유지보수(maintenance) 관점에서 다른 요소들에 미치는 영향을 예측하기 어려울 수 있습니다.

결국 점진적 개발은 고객의 변화하는 요구사항에 유연하게 대응할 수 있는 장점을 제공하지만, 프로젝트의 생명주기 동안 효과적으로 유지되기 위해서는 주의 깊은 관리와 문서의 정기적 갱신이 요구됩니다.