✅ 폭포수 모델(Waterfall Model)이란?
애자일에 대해 알아보기 전에 우리에게 익숙한 폭포수 개발 방식(Waterfall model)에 대해서 짚고 넘어가보자
폭포수 모델
Waterfall Model
소프트웨어 개발 생명주기(Software Development Life Cycle)에 기반하고 있는 소프트웨어 개발 기법으로, 워터폴 모델, 폭포수 모형, 선형 순차 모형, 단계적 생명주기라고도 한다. 한 번 떨어지면 거슬러 올라갈 수 없는 폭포수와 같이 소프트웨어 개발도 각 단계를 확실히 매듭짓고 다음 단계로 넘어간다는 의미에서 붙여진 명칭이다. 전통적인 시스템 생명주기 모델로 소프트웨어를 개발할 때 가장 널리 사용된다.
폭포수 모델로 프로젝트를 진행하면 보통 요구 사항 분석, 설계, 개발, 테스트, 배포 순서의 프로세스를 따르게 된다. 고객의 요구 사항이 명확하고 그에 따른 솔루션 역시 구체적이라면 이 방식이 적합할 수 있다.
하지만 위와 같은 개발 방식은 고객의 요구 사항이 마지막 배포 단계에서 변경된다면 다시 처음으로 돌아가 요구 사항을 분석하고, 그에 따른 사이드 이펙트들 때문에 설계 및 개발 내용 모두 변경해야 하는 상황이 발생할 수 있다. 폭포수 모델은 개발 과정이 명확하게 단계화되어 있는 만큼 관리가 쉬우나 요구 사항 분석에 상당한 시간이 소요되며, 일단 분석이 끝나면 수정이 어렵다는 단점을 가지고 있다. 또한 개발 단계마다 피드백이 발생하므로 순차적인 흐름을 따라가기 어려울 수 있기 때문에 규모가 크고 복잡한 시스템에는 폭포수 모델이 적합하지 않다.
이러한 폭포수 모델의 단점을 보완할 수 있는 것이 바로 애자일 방법론이다.
✅ 애자일(Agile)이란?
애자일 개발방법론
Agile Software Development
신속하고 유연하며 적응적인(Adaptive) 소프트웨어 개발을 목표로 하는 다양한 경량 개발 방법론 전체를 일컫는 총칭으로, 반복(Interation)이라 불리는 단기 단위를 채용함으로 위험을 최소화하는 개발 방법이다.
애자일이라는 단어가 주는 의미(기민한, 날렵한)처럼, 앞을 예측하며 개발하지 않고 일정한 주기를 가지고 계속 검토해 나가며 필요할 때마다 요구사항을 더하고 수정하여 커다랗게 살을 붙이면서 개발하는 프로세스 모델 방식이다.
✅ 애자일 방법론의 진행 과정
애자일 방법론은 계획 -> 설계(디자인) -> 개발(발전) -> 테스트 -> 검토(피드백) 순으로 반복적으로 진행된다. 계획을 세운 후 다음 단계까지 기다려서 절차대로 진행하는 폭포수 모델과 달리 먼저 진행 후 분석, 피드백을 통하여 개선하여 나가는 진행 모델이다.
- 계획 및 분석: 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 SW 기능과 제약조건을 정의하는 명세서 작성, 대상이 되는 문제 영역과 사용자가 원하는 task를 이해하는 단계
- 설계(디자인): 기획 의도에 맞는 설계 및 디자인 추가 및 수정하는 단계
- 개발(발전): 설계단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합테스트 수행
- 테스트: 발생할 수 있는 실행 프로그램 오류를 발견, 수정하는 단계
- 검토(피드백): 기획 의도를 파악하고 시험 결과와 기획에 따라 수정할 부분을 제시하는 단계
✅ 애자일 방법론의 특징
- 고객과 개발자의 지속적인 소통을 통하여 변화하는 요구사항을 신속하게 수용한다.
- 개발자 개인의 가치보다는 팀의 목적을 우선시하며 고객의 의견을 가장 우선시한다.
- 팀원들과 주기적인 회의 및 제품 시현을 통한 방지를 점검한다.
- 진행하면서 프로그램을 시행해보고 고객으로부터 피드백을 받는다.
- 내부 구조 형성을 통한 비용 절감에 힘쓰는 동시에 프로그램 품질 향상을 위해 노력한다.
✅ 애자일 방법론의 장단점
🔎 장점
- 프로젝트 계획에 걸리는 시간을 최소화할 수 있다.
- 점진적으로 테스트할 수 있어서 버그를 쉽고 빠르게 발견할 수 있다.
- 계획 혹은 기능에 대한 수정과 변경에 유연하다.
- 고객 요구사항에 대한 즉각적인 피드백에 유연하며 프로토타입 모델을 빠르게 출시할 수 있다.
- 빠듯한 기한의 프로젝트를 빠르게 출시할 수 있다.
🔎 단점
- 확정되지 않은 계획 및 요구사항으로 인한 반복적인 유지보수 작업이 많다.
- 고객의 요구사항 및 계획이 크게 변경되면 모델이 무너질 수 있다.
- 개인이 아닌 팀이 중심이 되다 보니 공통으로 해야 할 작업이 많을 수 있다. (회의, 로그 등)
- 반복적인 업무로 속도는 빠를 수 있으나 미흡한 기능들에 대한 대처가 필요하다.
- 확정되지 않은 계획으로 개발 진행 시 이해하지 못하고 진행하는 부분이 많을 수 있다.
✅ 애자일 방법론 쉽게 이해하기
첫 날에 그린 그림을 보면, 부분을 완성시킨 것이 아니라 (1번) 전체에 대한 스케치를 그렸다. 이것이 소프트웨어로 따지면 애자일 선언문에서 말하는 '동작하는 소프트웨어'이다. 완벽하진 않지만 짧은 시간안에 고객의 요구사항을 증명 할 수 있는 그림을 그린 것이다. 고객은 이 그림을 보고 (2번) 여성의 손의 위치와 배경의 산 비중을 줄여 달라는 피드백을 주었다. 피드백을 받은 후 최대한 빠른 시일내에 고객과 개발자의 방향성을 잡을 수 있다. 그 뒤에도 점점 진하게 색을 칠해 가면서 작품을 완성한다. 옷이나 머리색 등도 언제든지 변경 될 수 있을 것이다.
📚 Reference
'Computer Science' 카테고리의 다른 글
IPC(Inter-Process Communication)란? (2) | 2023.02.06 |
---|---|
[DB] 데이터베이스 정규화란? (0) | 2023.02.02 |
TDD(Test Driven Development)란? (0) | 2023.01.31 |
[DB] 데이터베이스 인덱스(Index)란 무엇인가? (0) | 2023.01.30 |
[python] 클린코드와 코드 리팩토링 (2) | 2023.01.25 |