워터폴 모델 및 그 실패

Source: Dev.to

개요

워터폴은 작업이 고정된 단계들을 따라 아래로 흐르는 선형, 단계‑게이트 소프트웨어 전달 모델이며, 각 단계가 완료되어야 다음 단계로 넘어갈 수 있습니다. 예측 가능성을 위해 설계되었으며, 속도를 위한 모델은 아닙니다. 피드백이 늦게 도착하고, 변경 비용이 높습니다.

단계

Requirements
    ↓
Design
    ↓
Development
    ↓
Testing
    ↓
Deployment
    ↓
Maintenance

단계 특성

• 한 번만 완료됨
• 다음 단계로 이동하기 전에 서명하고 잠금
• 공식적인 변경 요청 없이 되돌아가지 않음

워터폴이 효과적인 경우

• 소프트웨어 요구사항이 안정적일 때
• 릴리즈가 드물 때
• 시스템이 단순할 때
• 하드웨어 비용이 비쌀 때
• 변경이 위험할 때

워터폴을 많이 사용한 산업

• 정부
• 금융
• 방위
• 통신

이 분야들은 속도보다 제어와 문서화를 더 중시했습니다.

일반적인 프로세스 상세

• 비즈니스는 초기부터 완전한 명확성을 가정하고 방대한 요구사항 문서를 작성합니다.
• 변경은 억제됩니다.
• 설계자는 상세 설계를 작성하고, 초기 단계에서 결정을 고정시키며, 향후 가정을 내재시킵니다.
• 개발자는 최소한의 사용자 피드백으로 사양에 따라 구현합니다.
• 문제는 늦게 드러나며, 테스트는 거의 마지막에 이루어집니다.
• 버그 수정 비용이 높고, 시간 압박이 극심합니다.
• 수개월 혹은 수년 후에 수동적이고 위험한 롤백이 발생하며, 종종 큰 파급 효과를 가집니다.

문제점

• 버그와 설계 결함이 너무 늦게 나타납니다.
• 큰 파급 효과로 인해 롤백이 어렵습니다.
• 개발자는 생산 환경 문제를 거의 보지 못합니다.
• 프로세스를 따르는 것이 사용자 만족을 보장하지 않습니다.

비교 표

일반적인 오해

• 워터폴은 “악이다.” 라는 생각. 올바른 상황에 적용하면 유용한 접근법이며, 문제는 오용에 있습니다.

워터폴이 실패하는 이유

• 불확실한 세상에서 확실성을 가정합니다.
• 기능별 사일로, 수동 운영, 빈번한 비즈니스 변화와 결합될 때 모델이 붕괴됩니다.

DevOps의 대응

DevOps는 워터폴의 단점을 해결하기 위해 등장했습니다:

• 지속적인 피드백 루프
• 빌드, 테스트, 배포 파이프라인 자동화
• 개발과 운영 간의 공유 소유권

이러한 실천을 수용함으로써 팀은 엄격히 선형적이고 단계‑게이트 방식에 내재된 위험을 완화할 수 있습니다.