![애자일(Agile) 방법론에 대한 이해 ↔ 폭포수(Waterfall) 방법론](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2Fbm0gB9%2FbtsoyJUqKMw%2F5ITuDG4KwUroih9YnNYEUk%2Fimg.jpg)
서론
테스트 코드에 대한 공부 중에 Scrum, Kanban, XP(eXtreme Programing)과 같은 키워드가 등장했고 찾아보니 전부 애자일 방법론이라는 공통 뿌리를 발견하게 되었다.
소프트웨어 개발 방법론에는 여러가지가 있지만, 그 중 애자일 방법론이라는 키워드를 얻게 되어 공부를 위한 포스팅이다.
구글링 중 애자일 방법론이 등장한 배경과 같은 자료들도 많아서 읽어보았고 개인적으로 가장 잘 읽혔던 것을 하나 공유해둔다.
'애자일은 뭐고 폭포수는 뭐야?' 애자일 방법론 역사 이해하기
요즘은 모든 기술 조직이 어떤 형태로든 애자일 방법론을 실천하거나 그렇게 하고 있다고 믿는 것 같다. 소프트웨어 개발에 처음 발을 들여놓는 사람
www.itworld.co.kr
폭포수(Waterfall) 방법론
폭포처럼, 프로젝트의 각 단계가 위에서 아래로 떨어지는 방식으로 아래의 각 단계를 거친다.
위의 그림을 보자마자 단계별로 명확하게 구분되어 있구나. 라는 생각을 했다. 누가 봐도 그렇게 생각할 것이다.
장점
업무를 단계별로 분담하기 때문에, 업무가 명확하게 구분되어 있다는 장점이 있다.
단점
하지만 명확히 구분되어 있기 때문에 발생하는 단점도 있다.
요구사항을 정의하기 위해 필요한 작업, 리소스, 우선순위등을 파악해야 하며, 요구사항을 분석하고 문서화하는 데 많은 시간과 노력이 소요되는 것은 당연하다.
위의 그림대로라면 비즈니스 요구사항 문서를 통해 아키텍처와 데이터 구조, 기능 설계, UI 및 기타 비기능적 요구사항을 정의한 개발 문서를 작성해서 개발자에게 전달하여 개발 착수 과정을 거친다. 이처럼 위에서 아래로 떨어지는 구조이기 때문에, 아래에서는 위에서 물이 떨어질 때 까지 기다리고 있어야 했고, 혹여나 완성된 사양대로 기능을 만들었지만 이미 수 개월 혹은 년 단위가 지나 고객이 그 기능을 필요로 하지 않는 경우도 발생할 수 있다. 개발 속도가 느리고 유연하지 못하다는 소리다.
폭포수 방법론에서 사용된 문서를 사양 이라고 불렀다고 한다.
한계
애자일을 위해 이전 폭포수 방법론을 찾아보고 정리하면서 드는 생각은 개발속도가 느리다는 점에서 한계가 분명하다고 생각한다. 세상이 급변하는게 피부로 느껴지는 시대이기 때문이다.
기존의 폭포수 방법론으로의 소프트웨어 개발은 실제로 90년대 이후 인터넷 기술이 발달하고, 개인 PC가 늘어남에 따라 사용자의 요구가 빠르게 변했고 사용자의 니즈를 충족시키는데 한계가 분명했다고 한다. 개발 중간에 이전 단계로 되돌리기 어려운 문제는 결국 변화에 취약하며, 근본적으로 개발 속도가 느려 니즈를 충족시킬수 없기 때문일 것 같다.
애자일(Agile) 방법론
문서를 통한 개발이 아닌, 실질적인 코딩을 통한 방법론으로 계획을 통해 주도해 나갔던 과거의 방법론과 달리 앞을 예측하며 개발을 하지 않고 일정한 주기를 가지고 꾸준히 프로토타입을 만들어내며 그때마다 필요한 요구사항을 더하고 수정하며 소프트웨어를 개발해나가는 과정이다. - 위키백과
애자일(Agile=기민한, 민첩한, 좋은것을 빠르고 낭비없게 만드는 것)
변화하는 고객의 요구사항에 대응하는 탄력적이고 민첩한(Agile) 개발 방식이다.
2001년, 경험 많은 소프트웨어 개발자들은 본인들이 기존의 폭포수 방법론이 아닌 새로운 프로세스로 개발하고 있다는 사실을 인식했고 아래와 같은 애자일 선언문 (Manifesto for Agile Software Development)을 발표했다. 이것이 시발점이라고 할 수 있다.
아래의 그림처럼, 애자일 방법론에서는 짧은 사이클로 제품을 개발하고 테스트하며 보완하는 방식으로, 최종 제품을 배포하기 전까지 반복한다. 변화를 하나의 고정값으로 전제하고 작은 스프린트 단위로 디자인 > 개발 > 테스트 과정을 거친다.
프로젝트 진행 단계
- 요구사항 정의
- 스프린트 계획 : 스프린트에 포함할 작업 선정과 수행할 작업 범위 결정 및 우선순위 선정
- 백로그 작성 : 개발 작업의 전체 목록에 대한 상세한 작성 (칸반보드, 간트차트 등을 활용하여 진행 상황 관리)
- 스프린트 실행 : 기 계획된 작업 수행
- 작업 완료 및 검토
- 회고 : 개선점 도출 및 전반 작업에 대한 평가 정리.
종류
칸반(Kanban), 스크럼(Scrum), 익스트림 프로그래밍(eXtreme Programing, XP), ASD(Adaptive Software Development) 등이 있다.
(공부를 위해 칸반, 스크럼, XP정도는 따로 포스팅 할 예정이다.)
장점
위에서 언급한 것 처럼, 변화에 빠르게 대응할 수 있는 유연함과 민첩함이 장점이다.
또한 폭포수 방법론처럼, 굳이 모든 요구사항을 계획하고 분석하지 않기 때문에 배포까지의 과정을 신속하게 처리할 수 있다.
제품을 배포하고, 고객의 니즈 변화나 피드백에 따라 빠르게 보완하는 것이 필요한 상황에 많이 사용한다.(스타트업 등)
단점
반복 업무로 속도는 빠를 수 있지만, 미흡한 기능에 대한 대처가 필요하며, 계획을 확실하게 수립하지 않고 개발을 진행한다면 프로세스를 이해하지 못하고 단순 구현만 하는 부분이 많을 수 있다.
유연한 방법론이지만, 고객의 니즈나 계획 등이 크게 변경된다면 모델 자체가 무너질 수 있으며, 고객의 니즈가 너무 자주 바뀌게되면 반복적인 유지보수 작업을 많이 진행해야 할 수도 있다.
Reference
https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%AA%A8%EB%8D%B8
https://blog.naver.com/dongwoo0313/222358903027
2023.04 ~ 백엔드 개발자의 기록
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!