DevOps를 공부하기 앞서서...
DevOps를 공부하기 전 Waterfall과 Agile 방식을 비교하는 시간을 가져보자.
DevOps도 SW 개발 방법론 중 하나지만, DevOps는 Agile 방식에서 운영과 개발 과정을 합친 개발 방법론으로써 진화된 Agile 방식이라고 봐도 무관하다.
즉, 현재 자주 활용하는 개발 방법론은 Waterfall과 Agile, 두 방법이라고 이해해도 무방하다.
현재에도 Waterfall Model을 활용하는 기업이 많은 만큼 둘 사이에 차이에 대해 알아보고 어떤 상황에서 무슨 개발 방법론을 활용하는 것이 좋은지 확인하고 가는 것이 좋을 것이다
Waterfall Model과 Agile Model 비교
요구사항
Waterfall Model은 Requirements 단계에서 모든 요구사항을 미리 파악하고 프로젝트 전체에 대한 분석을 수행하는 모델로 고객의 추가적인 요구사항에 대한 대처가 어렵다.
Agile 모델은 고객으로부터 실시간으로 피드백을 받는 개발 방법이므로 미리 모든 요구사항을 알 수는 없으나, 실시간으로 변화를 인지하며 지속적으로 고객의 피드백을 수용할 수 있는 개발 방법이다.
릴리즈
Waterfall Model은 개발에 대한 사이클이 크기 때문에 당연히 사이클이 끝난 이후 도출되는 릴리즈가 클 수 밖에 없다.
릴리즈가 크기 때문에 1개의 릴리즈에 추가된 기능들이 많으며 업데이트가 비교적 느릴 수 밖에 없다.
Agile Model은 Sprint라는 짧은 주기 내에 고객이 원하는 요구사항을 즉시 반영하는 개발 방법으로 릴리즈가 도출되는 주기가 잦을 수밖에 없다. 자연스럽게 릴리즈에 포함된 추가 기능들이 적고 릴리즈의 크기도 작아진다.
프로젝트 진행 방식
Waterfall Model은 프로젝트에 대해 완벽한 계획을 수립한 뒤 계획에 맞게 개발을 진행하는 계획 중심의 개발 방법론이다.
Agile Model은 Sprint라는 짧은 단계를 거듭하며 테스트를 수행하고 이 과정에서 학습하며 개발하는 학습 중심의 개발 방법론이다.
의사소통 빈도
Waterfall Model은 문서 중심의 개발 방법론으로써 고객과의 의사소통은 사실상 요구사항 파악 단계에서 밖에 수행되지 않고 개발 계획에 따라 개발이 진행되기만 하면 되기 때문에 팀 사이에서도 의사소통이 많을 필요가 없다.
Agile Model은 항상 고객의 피드백을 받아야하므로 고객과의 잦은 의사소통 과정이 요구되며 팀들이 모두 자율성을 가지고 있기에 팀 사이 의사소통이 요구되는 소통 중심의 개발 방식이다.
Waterfall 방법론이 유리한 경우
최근에는 Agile 방법이 각광받고 있다. 하지만 각광받고 있다고 해서 무조건 모든 기업이 Agile 방법론을 활용하는 것은 아니다.
그렇다면 어떤 경우에서 Agile 방법보다는 Waterfall 방법론이 유리할까?
단순한 요구사항 & 단순한 프로젝트
요구사항이 단순할 경우 Waterfall Model이 유리하다.
요구사항이 단순할 경우 추가 요구사항이 발생할 확률이 적고 Requirements 단계에서 파악한 요구사항이 완벽할 가능성이 높아 계획대로 개발이 진행될 확률이 높다.
따라서 Waterfall Model의 각 단계를 완벽히 수행할 수 없다는 단점과 실시간으로 고객의 요구사항을 처리하지 못한다는 단점이 많이 지워진다.
비슷한 이유로 프로젝트가 단순할 경우 Waterfall Model이 적절하다.
복잡한 프로젝트의 경우에는 요구사항을 한 번에 파악하기 어렵기 때문에 Agile Model 사용이 적합하다.
하지만 프로젝트가 간단할 경우 요구사항을 한 번에 파악하기 쉬워지며 추가 요청사항이 올 확률도 적기 때문에 Waterfall Model 사용이 유리하다.
적게 예측되는 사용자의 피드백
이전 Section에서 말했듯 Agile 방법론에서 사용자의 피드백이 적거나 없다면 그저 깡통 SW가 만들어질 수도 있다.
따라서 사용자의 피드백이 적을 것이라고 예측되는 개발을 수행할 때는 제품의 완성도를 높이기 위해서 Waterfall Model을 활용하는 것이 좋다.
기존 프로젝트를 재사용하는 프로젝트
기존 개발했던 프로젝트 중 참고할 만한 것이 있다면 Waterfall Model이 적절하다.
기본 기능이 이미 구현되어 있기 때문에 Requirements 단계에서 기존 프로젝트를 고객에게 보여줌으로써 요구사항을 더욱 확실히 정의할 수 있으며 기능적으로도 분리하기가 쉬워 계획을 짜기 수월해진다.
또한 Agile Model을 활용하면 빈번한 코드 수정이 발생할 텐데 기존 프로젝트는 당연히 기능들이 연동되어 있기 때문에 1개의 코드 수정이 여러 개의 기능에 영향을 줄 수 있어 SW의 안정성을 떨어뜨릴 수 있다
협업하는 조직
만약 내부 조직끼리 일한다면 Agile Model이 유리하다. 내부 조직끼리 일할 경우 의사소통의 난이도가 낮아지므로 Agile 방식을 채택하여 잦은 의사소통을 통해 빠르게 피드백받아 문제를 해결하는 것이 더 유리하다.
하지만 외부 조직이나 다른 기관과 협업을 해야 하는 경우 Waterfall Model이 적합하다.
외부 조직과 협업할 경우 의사소통이 간헐적으로 일어나게 되며, 의사소통의 난이도 또한 증가한다.
이는 Agile Model에서 필요한 "원활한 의사소통"을 불가능하게 한다.
따라서 Waterfall Model을 통해 계획을 미리 세워두고 가끔씩 중간 결과를 확인하는 방식의 협업이 더 유리하다.
장기 프로젝트
장기 프로젝트의 경우 처음 요구사항을 파악하며 계획을 짜는데에 많은 시간을 투자할 수 있다. 따라서 고객과의 소통이 그렇게까지 필요하지 않고 시간에 쫓기지 않아도 된다.
이 경우 계획을 짜기 쉽고 관리가 쉬운 Waterfall Model이 적합하다.
정해진 HW 스펙
Agile은 계속해서 고객의 요구사항을 처리하기 위하여 코드와 기능을 덧붙여야 하기 때문에 어느 정도 HW 스펙이 필요한지 예측할 수 없다.
Waterfall Model은 모든 요구사항을 한번에 파악하고 계획을 짜는데 이 과정에서 필요한 HW 스펙에 대해서도 어느 정도 산출된다.
따라서 만약 HW 스펙이 미리 정해져있거나 고객에게 필요한 HW 스펙을 통지해야 하는 프로젝트의 경우 초기 단계에 HW 스펙을 예측할 수 있고 처음 정했던 HW 스펙과 최종적으로 필요한 HW 스펙의 차이가 크지 않을 Waterfall Model이 적절하다.
