[Software Development] 워터폴 방법론과 애자일 방법론

워터폴 (Water Fall) 방법론이란?

• 폭포수 방법론이라고도 불리며 이름에서도 알 수 있듯이 각 작업이 폭포처럼 위에서 아래로 떨어지는 단계별 개발 방법론
• 요구사항 정의(설계) → 디자인 → 개발 → 테스트 → 배포의 과정이 순차적으로 진행되며 이전 단계가 그다음 단계로 떨어짐
• 애자일 방법론이 등장하기 전까지는 소프트웨어 개발 뿐 아니라 자동차, 선박 등 산업 현장에서 보편적으로 사용되던 개발 방법론

워터폴 방법론 프로세스

요구사항 정의

• 프로세스의 가장 첫 단계로 고객의 문제를 정의하고 요구사항을 문서화하여 정리하는 단계
• 어떤 작업이 필요한지, 필요한 리소스는 무엇인지, 우선순위는 무엇인지 등을 계획하는 단계로 요구사항이 명확해야 프로젝트를 시작하고 무사히 완성될 수 있기 때문에 요구사항을 분석하고 문서를 정리하는 데 많은 시간과 노력이 소요

디자인

• 앞에서 정리한 요구사항을 충족할 수 있는 제품을 설계하는 단계

개발

• 앞의 디자인 단계에서 설계한 내용에 따라 본격적으로 제품을 구현하고 만드는 단계

테스트

• 만들어진 제품 기능이 제대로 작동하는지 테스트하는 단계
• 배포가 되기 전에 문제가 될 만한 버그, 오류를 찾아 수정

배포

• 최종적으로 결과물이 출시가 되고 사용자에게 소프트웨어가 배포되는 단계

워터폴 방법론 장단점

장점

• 단계별로 업무를 분담하기 때문에 맡은 바가 명확
• 계획 단계의 문서화로 단계마다 소요되는 시간이나 현재 상황을 추적하고 병목을 파악하기 쉬움

단점

• 속도가 느리고 유연하지 못함
• 아래에선 위에서 물이 떨어질 때까지 마냥 기다린다거나, 요구사항대로 기능을 만들었으나 수 개월이 지난 시점에서는 시장 상황이 변해 더 이상 고객이 그 기능을 필요로 하지 않은 경우도 발생

워터폴 방법론의 한계

• 워터폴 방식의 소프트웨어 개발은 고객 요구 변화에 민첩하게 대처하지 못함
• 앞에서 언급한 것처럼 워터폴 방법론은 속도, 변화에 취약했고 문제가 발생했을 때 전 단계로 되돌리기 어렵기 때문에 변경 사항이 생길 경우 처음 계획 단계부터 다시 시작하는 한계가 드러남
• 워터폴 방법론의 한계를 보완하기 위해 애자일 방법론이 등장했고, 빠르게 확산됨

---

애자일(Agile) 방법론이란?

• 애자일(Agile)은 ‘기민한, 민첩한’이라는 뜻으로 일정한 주기를 가지고 빠르게 제품을 출시하여 고객의 요구사항, 변화된 환경에 맞게 요구를 더 하고 수정해나가는 탄력적인 방법론을 의미
• 변화하는 고객 요구 사항에 대응하는 민첩한(agile) 개발 방식

애자일 소프트웨어 개발 선언

우리는 소프트웨어를 개발하고,또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다.

이 말은, 왼쪽에 있는 것들도 가치가 있지만,우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.


(출처 : 애자일 소프트웨어 개발 선언)

애자일 방법론 프로세스

• 일반적으로는 오늘날 많은 기업에서는 스크럼(Scrum)과 같은 애자일 프로세스를 주로 활용
• 짧은 사이클로 제품을 개발하고 테스트하고 피드백을 받아 보완하는 방식
• 변화에 수동적으로 대처하기보다 변화를 하나의 고정값으로 전제하여 1~4주 작은 스프린트 단위로
  디자인 → 개발 → 테스트를 진행

애자일 방법론 장단점

장점

• 변화 대응이 빠름
  • 프로젝트 도중 요구사항 변경이 용이
  • 고객이나 시장의 피드백을 반영해 유연하게 개발 방향을 수정 가능
• 빠른 프로토타이핑 및 제품 출시
  • MVP(Minimum Viable Product) 방식으로 빠르게 기본 기능을 개발하고 출시 가능
  • 초기 버전을 빠르게 배포하여 실사용자의 피드백을 얻고 개선 가능
• 지속적인 피드백과 개선
  • 스크럼(Scrum), 칸반(Kanban) 등의 프레임워크를 활용해 주기적으로 점검(sprint review, retrospective)하고 개선 가능
  • 개발자와 고객 간의 소통이 원활하여 만족도를 높일 수 있음
• 리스크 감소
  • 기능을 점진적으로 개발하므로 완성 직전에 큰 문제를 발견하는 리스크가 줄어듦
  • 초기에 주요 기능을 개발하고 지속적으로 개선할 수 있어 개발 실패 확률이 낮음
• 동기 부여와 팀워크 향상
  • 팀원 간 자율성이 보장되고 협업이 강조
  • 개발 과정에서 지속적인 피드백을 주고받아 성과를 확인할 수 있어 동기 부여에 긍정적인 영향

단점

• 명확한 계획 수립이 어려움
  • 프로젝트 초반에 전체적인 계획을 명확하게 정의하기 어려움
  • 장기적인 일정 예측이 어렵고, 비용 계산이 변동될 가능성이 큼
• 문서화 부족
  • 빠른 개발과 지속적인 변경을 반영하느라 초기 문서화가 부족한 경우가 많음
  • 이후 유지보수 시문서가 없어서개발자가 코드만 보고 이해해야 하는 문제가 발생 할 수 있음
• 프로젝트 범위(scope) 증가 가능성
  • 고객의 지속적인 요구사항 변경으로 인해 프로젝트 범위가 커질 위험이 있음
  • 처음 계획보다 더 많은 기능을 개발하게 되어 일정이 늘어날 가능성이 큼(Scope Creep)
• 팀 역량에 따라 성과가 달라짐
  • 애자일은 팀원 간 협업과 자율성이 중요한데 팀워크와 경험이 부족하면 오히려 비효율적일 수 있음
  • 경험이 적은 팀에서는 방향이 자주 바뀌고 혼란이 발생할 수 있음
• 대규모 프로젝트에서는 어려울 수 있음
  • 애자일은 작은 팀 단위의 프로젝트에 최적화된 방식
  • 대기업이나 대규모 프로젝트에서는 여러 팀 간 조율이 필요하므로 적용이 어려울 수 있음

애자일 방법론이 적합한 경우와 부적합한 경우

적합한 경우	부적합한 경우
요구 사항이 자주 변경	요구사항이 명확하고 변경이 거의 없음
빠른 프로토타입 및 피드백이 중요함	한 번에 완전한 시스템을 만들어야 함
스타트업, 웹 서비스, 모바일 앱 개발	항공, 의료, 금융 등 규제가 많은 산업
항공, 의료, 금융 등 규제가 많은 산업	여러 부서 간 조율이 필요한 대규모 프로젝트

---

워터폴 방법론과 애자일 방법론 정리

구분	워터폴(Waterfall) 방법론	애자일(Agile) 방법론
개발 방식	순차적 (단계별 진행)	반복적 (Iterative, 점진적 개발)
변경 대응	변경이 어렵고 초기 계획이 중요	유연하게 변경 가능
문서화	철저한 문서화 (계획 중심)	최소한의 문서화 (코드 중심)
개발 속도	비교적 느림	빠른 프로토타이핑 가능
고객 참여	초기 요구사항 정의 후 참여 적음	지속적인 피드백 반영
리스크 관리	후반부에 리스크 발생 가능	지속적인 개선으로 리스크 감소
팀 워크	역할이 명확히 구분됨	협업과 유연한 역할 분배 필요
적용 분야	대규모 프로젝트, 명확한 요구사항이 있는 경우 Ex) 정부, 금융, 항공 등	빠르게 변화하는 시장, 스타트업, 웹/모바일 앱 개발
예측 가능성	일정 및 비용 예측이 용이함	일정과 비용이 변동될 가능성이 있음
대표 프레임 워크	V 모델, 폭포수 모델	스크럼(Scrum), 칸반(Kanban)

 

---

참고 자료

https://www.codestates.com/blog/content/%EC%95%A0%EC%9E%90%EC%9D%BC%EB%B0%A9%EB%B2%95%EB%A1%A0-%EC%9B%8C%ED%84%B0%ED%8F%B4%EB%B0%A9%EB%B2%95%EB%A1%A0

애자일과 워터폴 방법론 비교 | 정의, 차이, 장단점, 적합한 조직 - 코드스테이츠 공식 블로그