폭포수 모델: 단계별 산출물로 관리하는 소프트웨어 개발

단계가 끝난 뒤에 다음 단계로 넘기는 개발 방식

폭포수 모델은 소프트웨어 개발 생명주기(SDLC)를 선형 순서로 운영하는 오래된 접근법이다. 1970년대 Winston W. Royce에 의해 공식화되었으며, 앞 단계가 완료된 뒤 다음 단계로 넘어간다는 점에서 폭포가 아래로 흐르는 모습에 비유된다.

각 단계에서 남긴 산출물은 다음 단계의 입력이 된다. 따라서 이 모델의 중심에는 엄격한 진행 순서와 문서화된 결과물이 있다.

요구사항부터 운영까지 이어지는 산출물

개발은 고객과 협의해 시스템의 목적, 기능, 제약조건을 식별하는 요구사항 분석 및 정의에서 시작한다. 이 단계의 결과물은 요구사항 명세서(SRS: Software Requirements Specification)이며, 초기 완성도는 이후 프로젝트 전반에 영향을 준다.

그다음 시스템 및 소프트웨어 설계 단계에서는 요구사항을 시스템 아키텍처로 구체화한다. 하드웨어와 소프트웨어 요구사항을 확립하고, 시스템 구조를 논리적 설계와 물리적 설계로 나누어 다룬다. 이때 시스템 설계 문서(System Design Document)를 남긴다.

구현 및 단위 테스트 단계에서는 설계 명세를 코드로 옮기고, 프로그래밍 언어·데이터베이스·기타 기술 요소를 사용한다. 개발한 모듈별 단위 테스트를 수행하며 소스 코드와 단위 테스트 결과 보고서가 산출된다.

통합 및 시스템 테스트에서는 개별 모듈을 전체 시스템으로 결합해 인터페이스와 상호작용을 검증한다. 시스템 기능과 성능을 시험한 뒤 통합 테스트 보고서와 시스템 테스트 보고서를 작성한다.

운영 및 유지보수 단계에서는 완성된 시스템을 실제 환경에 배포·설치하고 사용자 교육과 기술 지원을 제공한다. 오류 수정, 성능 개선, 기능 확장을 계속 수행하며 유지보수 계획, 변경 요청 문서, 패치 릴리스가 관리 대상이 된다.

⤢✕

문서와 통제가 필요한 프로젝트에서의 강점

단계 경계, 마일스톤, 산출물이 분명해 프로젝트 관리가 비교적 단순하다. 초보 개발자나 관리자도 구조를 이해하고 적용하기 쉽다.

단계별 상세 문서는 지식 전달과 인수인계, 유지보수를 돕는다. 의료, 금융, 국방처럼 규제가 엄격한 산업에서 문서화와 검증 절차가 필요한 이유이기도 하다.

각 단계에는 품질 검토와 승인 절차를 둘 수 있고, 요구사항 변경이 미치는 영향도 명확하게 평가할 수 있다. 테스트 단계가 분리되어 있어 검증을 관리하기에도 적합하다.

필요한 자원과 일정을 단계별로 계획할 수 있다는 점도 장점이다. 비용과 시간 추정의 정확도를 높이기 쉬우며, 산출물 범위가 명확한 계약 기반 프로젝트와 잘 맞는다.

변경과 학습이 늦어지는 구조

폭포수 모델은 초기 요구사항이 완전해야 한다는 전제에 의존하지만, 실제 프로젝트에서 이를 충족하기는 어렵다. 후반 단계에서 드러난 문제나 변경사항을 받아들이기 어렵고, 변경 비용은 프로젝트 후반부로 갈수록 기하급수적으로 증가한다.

작동하는 소프트웨어가 개발 후반부에 제공되므로 사용자 피드백도 늦어진다. 그 사이 실제 사용자 요구와 개발 방향이 어긋나거나, 고객 기대와 최종 제품 사이에 괴리가 생길 수 있다.

프로젝트 초기에 모든 위험 요소를 식별하기 어렵다는 점도 제약이다. 문제 발견 시점이 늦을수록 해결 비용이 커지므로, 불확실성이 높은 프로젝트에는 적합하지 않다. 비즈니스 환경과 기술의 변화에도 즉시 대응하기 어렵고, 단계 간 피드백 루프가 부족해 학습 기회가 제한될 수 있다. 복잡하고 불확실한 대규모 프로젝트에 적용하면 위험도도 증가한다.

국방 시스템과 FBI 사례가 보여주는 조건

미 국방부의 미사일 방어 시스템 개발 프로젝트처럼 요구사항이 명확하고 변경 가능성이 낮으며, 엄격한 문서화와 검증 절차가 필요한 환경에서는 안정적이고 신뢰성 높은 시스템을 구축하는 방식으로 활용될 수 있다.

반대로 FBI의 Virtual Case File 시스템은 2000년대 초 사례 관리 시스템 현대화를 위해 폭포수 방식을 적용했으나, 3년과 1억 7천만 달러를 투입한 뒤 폐기됐다. 요구사항 변경에 대응하지 못했고 기술 환경의 변화를 반영하지 못한 것이 실패 원인이었다. 이후 애자일 방식으로 전환해 Sentinel 시스템을 성공적으로 개발했다.

순차 모델을 보완하는 피드백과 검증

수정된 폭포수 모델(Modified Waterfall)은 인접 단계 사이에 피드백 루프를 넣어 유연성을 높인다. 단계 중복을 허용해 병렬 작업을 가능하게 하고, 프로토타이핑 요소를 도입해 사용자 피드백을 일찍 반영한다.

⤢✕

V 모델(Verification & Validation Model)은 폭포수 모델을 확장해 개발 단계와 테스트 단계를 대응시킨다. 각 개발 활동에 상응하는 테스트를 두어 결함을 조기에 발견하고 품질 향상을 기대하는 방식이다.

⤢✕

요구사항 안정성에 따라 폭포수와 애자일을 고른다

폭포수 모델은 요구사항이 명확하고 변경 가능성이 낮으며, 기술적 불확실성이 낮은 프로젝트에 맞는다. 항공, 의료기기, 국방처럼 엄격한 규제가 적용되는 분야와 명확한 산출물 정의가 필요한 계약 기반 프로젝트도 이에 해당한다.

애자일은 요구사항 변화가 빈번하거나 불확실한 경우, 빠른 시장 출시가 중요한 경쟁 환경, 사용자 피드백이 중요한 소비자 지향 애플리케이션에 더 적합하다. 혁신적인 제품처럼 탐색적 개발이 필요한 상황도 같은 범주다.

규제 산업에서는 문서화와 엄격한 검증이 필수이므로 폭포수 모델이 계속 활용된다. 한편 폭포수와 애자일을 결합하는 하이브리드 접근도 늘고 있다. 대규모 시스템에서는 전체 프레임워크를 폭포수 방식으로 관리하면서 세부 구현에 애자일을 적용할 수 있고, 출발점과 끝점이 명확한 프로젝트에서는 폭포수 모델이 여전히 효과적이다.

방법론 선택과 단계별 검증의 관점

폭포수 모델은 조직 문화와 프로젝트 특성에 맞춰 선택해야 한다. 전통적 강점인 문서화와 거버넌스를 유지하되, 필요한 유연성을 보완하는 접근이 필요하다.

리스크 관리에서는 초기 단계의 철저한 분석을 통해 위험 최소화 계획을 세우는 일이 중요하다. 정보시스템 감리와 감사에서는 폭포수 기반 프로젝트가 남긴 단계별 산출물을 검증할 수 있으며, 대형 공공 프로젝트나 엔터프라이즈 시스템에서는 폭포수 기반 관리가 여전히 유효하다.