애자일 개발 vs. 폭포수 개발: 주요 차이점

출처: https://www.shutterstock.com/

 

오늘은 애자일 개발 방법론과 폭포수 개발 방법론에 대한 비교를 해 보고자 합니다.

어찌보면 너무 당연한 내용일 수도 있겠지만, 각 방법론들의 차이점을 관점별로 정리하여 간략히 정리 해 보는 것도 나름 의미가 있겠다 싶어 정리 해 봅니다.

 

1. 개발 프로세스 (Development Process) 관점

개발 프로세스 관점에서 폭포수 개발 방법론은 순차적이고 선형적인 접근 방식을 따릅니다. 즉 개발 프로세스는 활동(Activity)들에 대한 단계(Phase)를 구분하고, 각 단계별 활동들이 정의되며, 각 단계는 다음 단계로 넘어가기 전에 현재 단계의 모든 활동이 수행 완료되어야 한다는 점이 특징입니다. 이런 과정을 통해 단계별 완결성을 확인할 수 있으며, 각 단계별 활동을 통해 얻어지는 산출물들의 품질을 완성할 수 있다는 장점이 있습니다. 일반적으로 폭포수 개발에서는 요구사항 수집-설계-구현-테스트-배포-유지보수의 순서를 따릅니다.

반면 애자일 개발 방법론은 반복적이고 점진적인 접근 방식을 따릅니다. 큰 틀에서 활동들이 단계별로 구분되고, 각 단계별 활동이 완료되어야 다음 단계로 넘어간다는 점에서 비슷한 면이 있으나, 반복적이고 점진적 접근 방식을 따르기 때문에, 개발 대상을 가능한 작은 작업 단위로 쪼개고, 이를 여러개의 반복(스프린트)을 통해 작업 단위들을 완성 해 나간다는 점이 특징입니다. 이때 각 스프린트마다 개발되는 작업 단위들은 그 자체로 동작이 가능한 수준으로 개발되어야 하기 때문에 스프린트를 구성하기 위한 여러 부가적인 작업 즉, 스프린트 설계와 검증을 위한 테스트 오라클 개발 등을 수반하게 됩니다. 또한 스프린트 단위의 동작 가능한 소프트웨어 단위들은 초기 요구사항에 부합하는지를 지속적으로 고객 또는 이해관계자들의 피드백을 바탕으로 확인할 수 있어야 하며, 이러한 피드백을 통해 발견된 문제점들을 개선해 나가게 됩니다.

 

2. 유연성 (Flexibility) 관점

폭포수 개발 방법론은 단계별 활동이 모두 완료되어야 한다는 점에서 이전 단계로의 회귀가 어려울 수 있습니다. 예를 들어 요구사항 분석이 완료되고, 설계가 시작된 시점에 요구사항 변경이 발생하는 경우, 설계 과정에서 이를 반영하기가 매우 어려울 수 있습니다. 특히 프로젝트 후반부로 진행 될 수록 이러한 변경사항의 반영에는 많은 비용과 시간이 소요될 수 있습니다.

반면 애자일 개발 방법론은 기본적으로 개발과 개선이 반복적으로 일어나기 때문에 이러한 변화 요구에 대응이 용이합니다. 즉, 요구사항은 각 스프린트마다 재평가되고, 조정될 수 있으며, 피드백을 통해 지속적으로 개선될 수 있는 여지가 있습니다.

개발 대상이 되는 소프트웨어의 목적과 기능, 그리고 관련 속성들이 명확하게 정의되어 있는 경우에는 폭포수 개발 방법론이 매우 용이할 수 있겠지만, 신규 개발이 필요하고 목적과 기능은 명확하더라도, 각 기능별 비기능 요구사항이 불명확하거나, 급변하는 시장 상황에 능동적으로 대응해야 할 필요가 있는 소프트웨어 개발의 경우에는 상대적으로 폭포수 개발 방법론에 비해 애자일 개발 방법론이 유리할 수 있습니다.

 

3. 고객 참여 (Customer Involvement) 관점

폭포수 개발 방법론에서 고객 참여는 초기 요구사항 분석 단계와 최종 제품 인수 단계에서 참여하는 것이 원칙입니다. 물론 각 단계별 완결성을 확인하는 과정에서 고객 참여가 불가한 것은 아니지만, 단계별 완결성은 이전 단계 활동의 완결성을 확인하는 것이 목적이지, 고객 참여 및 변경사항을 반영하는 것이 목적이 아니기 때문에 고객 참여 관점에서 폭포수 개발 방법론은 어느정도 한계를 드러내게 됩니다. 대신 충분한 요구사항 분석을 통해 집중적인 개발활동을 수행하기에는 매우 유용할 수 있으며 폭포수 개발 방법론 중 V&V (Verification and Validation)을 통해 어느정도 고객 참여의 제한을 해소 할 수도 있게 됩니다.

반면 애자일 개발 방법론에서는 고객이 개발 과정 전반에 걸쳐 지속적으로 참여하게 되므로, 각 스프린트마다 일정한 피드백을 통해 개발 방향을 조정할 수 있으며, 이를 통해 팀과 긴밀히 협력하여 제품이 요구사항을 충족하는지를 끊임없이 확인할 수 있게 됩니다.

 

4. 문서화 (Documentation) 관점

폭포수 개발 방법론에서 각 단계별 완결성 확인은 주로 문서화된 산출물을 바탕으로 이루어집니다. 따라서 프로젝트 진행에 따른 광범위한 문서화를 요구하게 됩니다. 각 단계에 대한 상세한 문서가 작성되어야 하며, 이는 다음 단계로 넘어가는데 있어 기준으로 활용됩니다. 다시 말해 폭포수 개발 방법론에서는 소프트웨어 개발에 더해 별도의 문서화가 반드시 수반되어야 하기 때문에 추가적인 공수를 필요로 할 수 있습니다. 하지만 결과적으로 이러한 산출물들은 조직에 있어 하나의 자산으로 활용될 수 있으므로, 차기 프로젝트를 수행하거나 신규 인원이 참여할 때 효율적인 적용이 가능하다는 점이 장점으로 작용할 수 있습니다.

반면 애자일 개발 방법론에서는 필요한 문서만 작성하여 개발을 지원하기 때문에 작동하는 소프트웨어가 문서화보다 더 중요한 가치를 지니게 됩니다. 따라서, 문서화는 자산 축적보다는 개발을 지원하는데 중점을 두기 때문에 폭포수 개발 방법론과는 상충되는 의미를 가진다고 볼 수 있습니다.

 

5. 프로젝트 타임 라인 (Project Timeline) 관점

폭포수 개발 방법론에서 프로젝트 타임 라인은 계획단계에서 설정된 타임 라인으로 고정되어 있으며, 기간이 명확히 정의됩니다. 따라서 프로젝트 관리가 상대적으로 편리하다는 장점이 있습니다. 

반면 애자일 개발 방법론에서는 유연한 타임 라인을 가집니다. 일반적으로 각 스프린트는 2~4주 정도의 타임 라인을 가지고 스프트린트가 진행되며, 스프린트가 끝날 때마다 제품의 기능이 증가하게 됩니다. 

 

6. 위험 관리 (Risk Management) 관점

폭포수 개발 방법론에서는 개발 초기 단계에서 요구사항을 확정하기 때문에, 프로젝트 후반부에 변경이 발생하면 큰 위험을 초래할 수 있습니다. 하지만 충분한 역량을 가지는 조직의 경우, 과거 프로젝트 경험을 바탕으로 각 단계별 위험을 사전에 예측할 수 있으며, 이를 현 개발 단계에서 검토 할 수 있는 기준으로 활용할 수도 있습니다.

반면, 애자일 개발 방법론에서는 각 스프린트마다 제품을 점진적으로 개발하고 테스트하므로, 위험을 조기에 발견하고 관리할 수 있습니다. 그러나 각 스프린트에서 발견된 위험을 개선하는 과정에서 예상치 못한 일정과 비용이 발생할 수 있으며, 이런 경우 스프트린트 유지/관리가 추가적인 위험이 될 수도 있습니다.

---

마치며...

앞에서 언급한 바와 같이 애자일과 폭포수는 각각의 장단점이 있습니다. 폭포수 개발 방법론은 명확한 구조와 문서화를 통해 큰 프로젝트에서 효과적일 수 있지만, 변경 사항에 대한 유연성이 부족합니다. 반면, 애자일 개발 방법론은 변화에 빠르게 대응하고, 고객의 지속적인 피드백을 반영할 수 있어 더 유연하고 반응성이 뛰어나지만, 지속적인 고객 참여는 또다른 개발 버든으로 작용할 수 있으며, 지속적인 스프린트 관리를 수반해야 한다는 점에서 신중한 선택이 필요할 수 있습니다.

 

 

2024.07.23 - [System & Software Engineering] - 애자일 소프트웨어 개발 (Agile Software Development)

애자일 소프트웨어 개발 (Agile Software Development)

 

2024.07.03 - [System & Software Engineering] - 소프트웨어 형상관리와 소프트웨어 개발

소프트웨어 형상관리와 소프트웨어 개발

 

2024.06.18 - [System & Software Engineering] - 소프트웨어 진화와 아키텍처 트레이드 오프 (Software Evolution and Architecture Trade-Off)

소프트웨어 진화와 아키텍처 트레이드 오프 (Software Evolution and Architecture Trade-Off)