Waterfall 개발 방법론은 이제 한물갔을까? (Waterfall vs Agile 비교)

1. 서론

fastcampus에서 프로덕트 매니지먼트(Product Management)에 대한 온라인 강의를 듣던 중에 Waterfall과 Agile 방법론에 대한 이야기가 나와서 정리를 하고자 합니다. 
 
https://fastcampus.co.kr/dev_red_kyw

The RED : 모든 비즈니스를 성공으로 이끄는 Product Management Essential by 김영욱 | 패스트캠퍼스

 

2. Waterfall 개발 방법론

Waterfall 개발 방법론은 계획, 분석, 설계, 구현, 테스트, 유지보수 등의 단계를 순차적으로 진행하는 개발 방법론입니다. 각 단계는 이전 단계가 완료된 후에 시작하며, 다음 단계를 진행하기 전에 반드시 이전 단계의 결과물을 검토하고 승인하는 절차가 있습니다. 이러한 특징 때문에 Waterfall 방법론은 계획과 일정을 명확하게 정하고 프로젝트를 진행합니다.

Waterfall 방법론은 초기에 요구사항을 명확하게 파악하고 설계 단계에서 모든 것을 상세하게 정리하여 개발에 들어가므로, 변경이 발생할 때 어려움이 있습니다. 또한 프로젝트 초기에 발생할 수 있는 위험과 문제를 미리 파악하고 대비하기 어렵기 때문에, 예측 불가능성이 높습니다. 이에 따라, Waterfall 방법론은 초기에 충분한 검토와 계획이 필요합니다.
 
하지만, 현실적으로 미래를 예측하는 것은 어렵거나, 거의 불가능합니다. 
그리고, 근본적으로 프로젝트의 목적은 고객에게 가치를 제공하고, 회사는 이익을 얻어야 하는데,
환경이 변화한다면, 처음 계획대로 진행했을 때, 이런 가치가 제대로 창출되지 않습니다. 

이런 Waterfall 방법론의 단점으로 인해 최근에는 Agile 방법론이 더 많이 사용되고 있습니다. 

3. Agile 개발 방법론

Agile 개발 방법론은 초기 계획과 일정이 유동적이며, 짧은 주기로 결과물을 산출하고 검증하는 것에 중점을 둔 개발 방법론입니다.
프로젝트가 진행됨에 따라 요구사항이나 우선순위가 변경될 수 있기 때문에, 프로젝트 초기에 모든 것을 다 계획하지 않고, 유연하게 대응하는 것에 중점을 둡니다.

프로젝트 팀은 초기 계획을 수립하고, 짧은 주기로 반복적인 개발을 수행하며, 최종 제품에 대한 고객의 피드백을 반영합니다. 이를 통해 최종 제품의 품질과 고객 만족도를 높이는 것이 목적입니다.

Agile 개발 방법론에서는 팀 내 소통과 협업이 매우 중요합니다. 팀원들은 상호 간의 의견을 존중하며, 지속적인 피드백과 개선을 통해 프로젝트를 성공적으로 수행할 수 있어야 합니다. 또한 Agile 개발 방법론에서는 팀원들이 다양한 역할을 수행합니다. 개발자뿐만 아니라, 테스터, 디자이너, 프로젝트 매니저 등 다양한 역할의 전문가들이 함께 일합니다.
팀원들이 프로젝트에 대한 진행 상황과 고객의 피드백에 대해 서로 공유하며, 문제가 발생하면 빠르게 대응합니다. 

Agile 개발 방법론은 초기에 문제를 드러내어 조치함으로써 프로젝트의 실패를 방지하게 됩니다. 
 

4. Waterfall은 이제 한물간 걸까?

Waterfall 개발 방법론이 이제는 잘 사용되지 않는 것처럼, Waterfall과 Agile 방법론에 대한 비교도 한물간 주제인 것 같습니다.
이제는 Waterfall 개발 방법론을 고수하려는 조직/프로젝트는 거의 없을 것이라고 생각합니다. 
 
Standish Group Chaos Report 2020(25년 동안 5만 건 이상의 프로젝트를 분석하여 성공과 실패에 대한 리포트를 제공)에 따르면, Agile 방법론을 사용하는 프로젝트가 Waterfall 방법론을 사용하는 프로젝트보다 3배 이상 성공확률이 높으며, 규모가 작을수록 실패 확률이 낮으므로 이제는 큰 규모로 진행하는 "프로젝트"개념 자체를 버리라고 합니다.
 
※ 아래 글 참고
https://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects/

Why Agile is Better than Waterfall (Based on Standish Group Chaos Report 2020) | Vitality Chicago Inc.

 
확실히, 최근 들어 Waterfall은 배제되고 있습니다. 그럼에도 불구하고, 이 주제를 정리하는 이유가 있습니다. 
 
바로 프로젝트의 특성 자체가 Agile이 적합하지 않은 경우가 있다는 것입니다. Agile 방법론에서는 처음부터 모든 기능에 대해 개발하지 않으며, 전체가 100이라면, 20~50% 정도의 기능만 개발하고, 조금씩 개선해 나갑니다. 
 
하지만, 전체를 개발하지 않으면 의미가 없는 경우가 있습니다. 예를 들어 제가 진행하고 있는 빌링 프로젝트는 처음부터 끝까지 모든 프로세스를 거쳐야 정확한 "요금"이 나옵니다. 일부만 개발하는 것은 의미가 없습니다. 단위테스트로 각 모듈별 테스트를 할 때는 각 모듈별 정확하게 요금이 계산되어도 합쳐놓으면 틀리는 경우가 비일비재합니다.  이런 경우에는 Waterfall로 개발할 수밖에 없습니다.
 
쉽게 생각하면, 비행기를 만든다고 할 때, 비행기의 동체만 만들고 날개를 만들지 않으면, 날 수 없는 것과 마찬가지입니다.
비행기의 동체와, 주날개, 보조날개, 꼬리날개, 랜딩기어 등 대부분의 기능이 만들어진 후에야 비행기로써 기능할 수 있습니다.
 
제가 들은 앞서 언급한 김영욱 님 강의에서는 아파트를 예로 들고 있는데요. 아파트를 Agile 하게 짓는다고, 5층을 짓고, 사람들 입주를 받아서 피드백을 받은 후에, 6~10층을 지을 수는 없습니다. 
 
이런 예를 볼 때, Waterfall 개발 방법론이 완전히 한물갔다고 단정 지을 수는 없습니다.
 

5. 진짜 중요한 것

 
중요한 것은, 방법론 자체가 아니라, 가치를 창출하는 것입니다. 
그것이 어떤 방법론이든, 신기술이든, 고객에게 가치를 제공하고, 회사가 수익을 얻기 위한 것이 가장 중요합니다.
이 생각을 늘 염두하지 않으면, 유행을 따라서 방법론이나 신기술을 택하는 함정에 빠질 수 있습니다.