SW 개발 방법론이란?
Waterfall, Agile, DevOps를 설명하기 전 이들을 모두 포함하는 SW 개발 방법론에 대해 먼저 알아보자.
SW 개발 방법론은 사실 용어 그대로의 의미를 가진다.
"SW"를 "개발"하는 "방법"에 대한 "이론"
즉, 우리가 개발할 SW를 어떻게 만들어나갈지를 이론적으로 풀어낸 것이 SW 개발 방법론이라고 할 수 있겠다.
SW 개발 방법론은 SW를 어떻게 만드는지에 대해 관심을 가진다.
SW 개발 방법론은 어찌 되었든 실전이 아닌 이론이기 때문에 실제 상황과는 약간의 괴리가 있을 수도 있다.
SW 개발 방법론은 SW를 개발하는 과정을 단계별로 나누고, 단계별 산출물을 정의한다. 또한 이 산출물을 "누가" "어떻게" "어떤 순서로" 만들고 다뤄야 하는지, 그리고 그 과정에서 어떤 도구를 활용해야 하는지까지 구체적으로 정의한다
Waterfall Model이란?
과거에 매우 많이 활용되었고, 과거뿐만이 아닌 현재 대기업에서도 많이 활용하고 있는 Waterfall Model에 대해서 알아보자.
Waterfall을 직역하자면 "폭포수"이다. 폭포수의 특징을 생각해보자.
폭포수는 위에서 아래로 떨어진다. 또한 물이 떨어졌으면 다시 위로 거슬러 올라갈 수 없다. 마지막으로 중간에 끊겼다가 다시 물이 생성되지도 않는다.
이를 개발 방법에 접목하면 아래와 같이 설명할 수 있을 것이다.
"SW 개발을 단계별로 나누었을 때, 이전 단계가 완료된 경우 다음 단계로 넘어가며 다시 전 단계로 돌아올 수 없는 개발 방법"
이처럼 Waterfall Model은 이전 단계가 완벽히 수행되었을 때만 다음 단계로 넘어갈 수 있으며, 현재 수행하고 있는 개발 단계에서 이전 단계를 다시 수행할 수는 없다는 것이다.
예를 들어, 내가 개발 과정에서 갑자기 포인트 기능을 넣고 싶더라도 폭포수 모델은 기능 추가를 허락하지 않는 것이다.
(물론, Waterfall Model도 여러 변형 모델이 존재하며 과거로 돌아갈 수 있게 허용하는 폭포수 모델도 존재하는 것으로 알고 있다. 하지만 지금은 가장 원초적인 폭포수 모델을 공부하고 있기 때문에 변형 모델들은 고려하지 않겠다)
Waterfall Model은 이전 단계를 완벽히 수행해야 하며 계획대로 개발이 수행되어야 한다.
따라서 문서화, 계획을 매우 중요시 하는데 프로젝트 초기에 모든 요구사항을 정의하고 이를 충족하기 위한 계획을 수립하고 정해진 계획에 따라 개발 단계를 수행한다는 특징을 가지는 것이다.
Waterfall Model 수행 단계
단계 설명에 앞서 위 사진을 머리에 잘 새겨두자.
물론 박스 안에 설명된 단계에 대한 명칭도 중요하겠으나, 개인적으로는 1 ~ 3번째 박스에 이는 화살표가 더 중요하다고 생각한다.
화살표 이후로 나온 단어가 각 단계에서 나온 산출물인데 SW 개발 방법론이라는 것이 단계별 산출물을 중요시 생각하기 때문에 개발 단계와 같이 단계별 산출물도 연결시켜 공부하면 좋을 것 같다.
Requirements(요구사항 분석)
Client, 혹은 비즈니스 고객들(이하 고객)의 요구사항을 파악하고 기능, 비기능적 요구사항을 도출하는 과정이다.
기능, 비기능적 요구사항에 대해서도 나중에 공부할 기회가 있겠지만, 일단 지금은 "고객의 요구한 기능이나 요청 사항을 충족하기 위해 필요한 부가적 기능들"이라고만 이해하자.
요구사항 분석에서는 고객들의 의견을 종합하여 요구 사항들을 한눈에 알아볼 수 있게 정리하고 문서화한다.
추가적으로 요구사항을 종류 별로 나눠 특정 기준으로 분류를 할 수도 있을 것이다.
이 과정에선는 고객들의 의견을 분석하여 요청 사항들을 모두 분석한 이후 이러한 요구사항들을 "요구사항 명세서", 위 사진에서는 "Proudct Requirements Document"로 나와 있는 것으로 문서화시킨다.
이렇게 요구사항을 분석하고 문서화까지 종료했다면 다음 단계로 넘어간다.
Design(설계)
요구사항 명세서를 준수하여 일정을 설계하는 과정이다.
당연히 이 과정에서는 요구사항 명세서가 필요하기 때문에 폭포수 모델의 특징처럼 이전 단계(Requirements 단계)를 완벽히 수행해야 한다.
설계 단계에서는 요구사항 명세서에 정리된 여러 요구사항들을 파악하고 고객과 협의한 일정이나 자원 등을 고려하여 어떤 방식으로 개발을 진행할 것인지 계획을 짠다.
X ~ Y일까지 Z 기능을 개발한다던가 A, B 기능은 다른 팀에서 개발을 따로 진행하고 C 기능은 A와 B에 대한 개념이 모두 필요하기 때문에 두 팀을 모두 개발에 투입하는 등 개발 일정이나 개발 방법에 대한 전반적인 계획을 짜는 과정이라고 할 수 있다.
설계 과정은 SW의 전체적인 흐름이나 구조를 설계하는 "기본 설계"와 SW의 세부 로직을 설계하는 "상세 설계"로 나뉜다.
기본 설계 과정에서는 시스템 구조나 흐름을 짜고 DB를 설계하며 사용자 인터페이스를 설계하는 등 고객이 원하는 기능보다는 전체적인 흐름을 설계한다. 이렇게 전체적인 프로그램의 흐름을 짰다면 고객의 요구사항을 충족하기 위한 기능에 대하여 상세 설계 과정을 거치는 것이다.
예를 들어 "블로그에 글을 쓰고 싶다"라는 요구 사항이 있다고 생각하자.
우리는 기본 설계에서 "로그인을 하고 버튼을 클릭하여 내 블로그에 들어갈 수 있으며 블로그에서 글 쓰기 버튼을 클릭하면 글을 쓸 수 있다"라는 설계를 하며 어떤 버튼을 클릭하면 어떤 화면으로 이동하고, 인증은 어떤 방식을 활용할지 등에 대해 고민할 것이다. 이렇게 전체적인 흐름이 다 짜였다면 "로그인 기능", "블로그 기능", "버튼 클릭에 대한 화면 이동" 기능에 대한 방법을 정하고 일정을 짜는 상세 설계 과정을 거칠 것이다.
Implementation(구현)
설계단계가 완벽하게 종료되었다면 SW의 구조도가 도출될 것이며, 이 구조도를 구현하기 위한 일정이 나올 것이다.
그리고 이것들을 활용하여 구현 단계를 실행할 수 있다.
이 구현 단계는 설계 과정에서 나온 계획과 일정에 따라 SW 프로그래밍을 수행하는 과정이다.
이 과정은 코드를 짜는 것 뿐만이 아닌 "Unit Testt"와 "Code Inspection"과정도 포함되어 있다.
Unit Test(단위 테스트)는 로직 하나를 구현했을 때 내가 원하는 대로 코드가 작동되는지 실제로 구동시켜 테스트해보는 것을 의미한다.
Code Inspection(코드 검증)은 SW가 자잘한 디버그나 에러가 발생하는지 확인해보는 단계로 디버깅 단계라고 이해하면 편할 것이다.
즉, Unit Test는 "원하는 대로 수행되는가"에 목적을 두며 Code Inspection은 "내가 원하지 않는 방법으로 수행되지는 않는가"를 확인하는 것에 목적을 둔다고 볼 수 있다.
우리는 이 과정을 통해 최종적으로 Software(Application)을 얻을 수 있을 것이다(물론, 완벽한 소프트웨어가 아닌 알파나 베타 소프트웨어 정도일 것이다)
Vertification(확인)
구현이 완료되었다면 마지막으로 고객이 제대로 Software가 만들어졌는지 확인해야 할 것이다.
이 과정에서 고객은 처음 Software 구현 상태를 확인할 수 있게 되고, 이 과정에서 "잘 작동되는가", "내가 원하는 대로 작동되는가", "성능은 괜찮은가"를 검증할 것이다.
확인 과정에서는 이런 점들을 확인하기 위하여 총 3개의 테스트 과정을 거친다.
먼저 "통합 테스트"이다.
통합 테스트는 구현 과정에서 수행했던 Unit Test를 한번에 모두 실행시킴으로써 모든 Unit Test들이 정상적으로 작동되는지 확인하는 것이다. 물론 JUnit 등으로 짠 테스트 코드를 통해 확인할 수도 있겠지만, 고객이 애플리케이션을 실행시켜 보며 기능을 직접 확인하는 경우도 많다.
두 번째로 "시스템 테스트"이다.
시스템 테스트는 개발한 애플리케이션의 성능에 대해 실험하는 것이다. 기능이 수행되는 데 걸리는 시간, 처리할 수 있는 트래픽의 양, 저장할 수 있는 데이터의 양 등 소프트웨어를 사용했을 때 느끼는 불편함이나 제한 사항은 없는지 확인하는 과정이다.
마지막으로 "인수 테스트"이다.
인수 테스트는 고객이 원하던 요구사항들을 모두 충족시켰는지 관심을 두며 테스트하는 것이다. 이 과정에서 Requirements 과정의 산출물인 요구사항 명세서를 활용하기도 한다. 요구사항 명세서에 적혀있는 기능들을 한 개씩 직접 실행시켜 보며 소프트웨어가 "고객이 원하는 방식으로", "고객이 목적에 맞게" 구현되었는가를 검증하는 과정이다.
추가로 Code Inspection과 Unit Test도 Vertifiaction 과정에 포함되어야 하는 것이 아닐까 라는 의문이 생길수도 있다.
필자는 Code Inspection과 Unit Test는 "구현한 로직 1개에 대한 테스트"로써 기능 개발을 수행한 뒤 개발의 허점을 찾아 보강하는 과정이라고 생각하였다. 폭포수 모델은 이전 단계로 돌아갈 수 없다고 했지만 Code Inspection과 Unit Test를 통해 허점이나 에러를 찾아낸다면 그 즉시 수행하여 다시 수행시키며 에러를 줄여나가는 과정이다.
반대로 Vertification 과정은 완성된 SW의 전체적인 기능에 대하여 Test를 진행하는 것으로써 (이론적으로는) 에러가 발생하여 이전 단계로 돌아가면 안 되기 때문에 테스트보다는 구현 과정에 포함되는 것이 맞다고 생각이 든다.
Maintenance(유지보수)
확인 단계를 모두 거쳐 고객이 소프트웨어를 직접 활용한다면 마지막 유지보수 단계로 넘어간다.
Vertification 과정을 통해 고객은 "일단은" 이 프로그램을 활용해도 문제가 없을 것이라고 판단하여 돈을 지불하고 개발한 SW를 배포할 것이다.
하지만 개발이라는 것이 Vertifaction 과정이 끝났다고 완벽해지는 것은 아니다.
실제로 우리가 기능을 구현할 때 어떨때는 되고 어떨 때는 에러가 떠서 골머리를 앓기도 하고, 게임을 하다가도 수많은 버그들을 마주친다.
개발자는 최대한 에러가 발생할 수 있는 상황을 가정하여 테스트를 진행해보지만 미처 고려하지 못했던 상황은 개발자가 생각한 것보다 훨씬 많을 것이다.
실제로 프로그램을 사용하는 사람은 수천, 수만 명에 다다를 것이고 당연히 사람마다 각각의 상황이 존재할 것이다. 그리고 이런 과정에서 개발자가 고려하지 못했던 문제가 발생할 가능성이 높다.
따라서 개발자가 SW를 고객에게 배포한 뒤에도 (마치 물건의 품질 보증 기간처럼) 일정 기간 보증 기간을 가지며 발생되는 오류와 서비스적인 문제에 대해 대처하는데 이를 "유지보수" 단계라고 정의한다.
Waterfall Model 장점
많은 레퍼런스
Waterfall Model은 역사가 오래된 만큼 많은 레퍼런스(경험)가 존재한다.
이 수많은 레퍼런스라는 점이 생각보다 무시할 수 없는 장점이다.
레퍼런스가 많다는 것은 내가 실패하거나 모르는 부분이 생겼을 경우 나와 같은 경험을 했던 사람들이 존재할 가능성이 크다는 것이며, 이는 해결 방식을 쉽게 찾을 수 있거나 해결을 위한 아이디어의 계기를 줄 수 있는 배경지식들이 많이 존재한다는 것이다.
또한 실패하지 않았더라도 많은 실패 사례들을 참조하며 위험 요소를 감소시켜 미래에 생길 문제점을 사전에 처리하여 더욱 안전하게 프로젝트를 수행할 수 있다는 장점을 가진다.
과정에 대한 이해가 쉬움
Waterfall 방식은 이해하지 못하는게 더 어려울 정도로 매우 쉬운 개발 방식이다.
결국 Waterfall Model은 1마디로 표현 가능하다
"고객이 뭘 원하는지 알아내서 문서에 정리한 뒤 계획을 짜서 계획대로 개발한 후 고객에게 확인받는다"
개념이 쉽기 때문에 Waterfall Model의 과정 또한 매우 직관적이고 단순하다. 따라서 처음 접하는 사람들도 쉽게 과정을 이해하고 프로젝트에 참여할 수 있게 되는 것이다.
Waterfall Model은 요구사항 명세서와 계획서가 존재하기 때문에 개발할 기능들이 미리 분류되어 있다. 따라서 관리자 입장에서는 일정에 따라 팀별로 개발할 기능을 할당하는 것이 쉬워지며 대규모 개발 과정에서 흐름을 깨지 않는 선에서 팀에게 업무를 할당할 수 있게 되는 것이다.
결과물 관리가 편함
이전 과정으로 돌아오기 힘들다는 Waterfall 방식은 각 단계를 완벽히 수행하는 것이 중요해지며, 자연스럽게 검토 프로세스가 중요해진다. 그리고 검토 프로세스가 중요해질 경우 가장 필요한 과정은 "문서화"이다.
이렇게 모든 단계를 수행할 때 문서화해야 하는 것은 단점으로도 이어지기도 하지만 프로젝트를 관리하는 측면에서는 현재 상황 파악이 쉬워진다는 장점이 존재한다. 또한 일정을 미리 짜기 때문에 일정 관리가 편하고 현재 진행상황에 대한 관리도 편해진다는 장점이 존재한다.
문서화로 인해 생기는 부가적인 장점들도 존재한다.
먼저, 비용 추정이 정확해진다. 초기에 계획을 짜서 계획대로 자원을 투자하면 되기 때문에 비용을 추정하기 수월해진다.
두 번째로 작업 범위가 명확해진다. 요구사항 명세서에 따라 분할된 작업을 팀별로 할당만 하면 되기 때문에 팀이 수행할 작업들이 예측 가능해지며 팀 입장에서도 작업 범위가 구체화되면 작업 내용이 명확해지기 때문에 작업을 더욱 확실히 수행할 수 있다.
Waterfall Model 단점
불확실성을 허용하지 않는 딱딱한 개발 과정
Waterfall Model은 말했듯이 이전 단계로 돌아갈 수 없는 수직적인 관계를 가지고 있다. 당연히, 동시에 다수의 단계를 병행할 수 없다.
이는 다른 말로 불확실성을 허용하지 않는다고 표현할 수 있다.
불확실성을 허용하지 않기 떄문에 각 단계가 완벽히 수행되어야 하며, 다른 의미로 단계를 수행하는 과정에서 불확실성을 가져다줄 수 있는 계획은 수용되기 힘들다.
따라서 개발자는 아이디어나 혁신, 창의성을 발휘하기 어려워지고 좋은 방법을 고안했다고 하더라도 그 방법이 검증되지 않는 이상 불확실성을 가지기 때문에 채택되기 어렵다.
위기 상황 대처가 어려움
모든 것이 그렇지만 프로젝트 또한 예상하지 못한 상황이 발생한다.
Waterfall 방식은 계획대로 수행되는 것이 매우 중요하기 때문에 이런 예기치 못한 상황에 대응하기 어렵다.
예를 들어 A 기능을 10일 안에 구현된다고 예상했는데, 알고보니 생각보다 많은 부분이 겹쳐 있는 기능이라 20일이 걸렸다고 가정하자. 그렇다면 어떤 방식으로 10일의 오차를 해결할 수 있을까?
또한 고객의 추가 요구사항도 엄청난 위기 상황이 될 것이다.
고객도 사람이기 때문에 마음이 변한다. 만약 원래 있던 로직을 삭제시켜달라는 요청이라면 속으로는 열불이 나겠지만 그래도 주석처리만 하면 바로 처리 가능하다. 그런데 만약 기존에 존재하지 않았던 로직을 추가시켜달라는 요청이 온다면?
Waterfall 방식은 "계획대로" 수행되어야 하고 이전 단계로 넘어갈 수 없는데, 첫 번째 단계인 Requiremetns(요구사항 분석) 단계로 다시 돌아가야 하는 상황이 되는 것이다. 당연히 계획은 무너질 것이며 이런 불확실성을 가져다줄 수 있는 고객의 추가 요구사항에 대해 보수적이 되는 것이다.
즉, 고객의 요구사항에 즉각적으로 대응해야 고객의 마음에 드는 Software를 개발할 수 있을텐데 고객의 만족도를 위해 추가 요구사항을 들어줄 수 없는 이상한 상황이 발생하는 것이다.
고객의 요구사항을 모두 담아내기 힘듦
위의 단점과 이어지는 단점이다.
고객의 추가적인 요구사항이 생길 경우 이는 개발의 불확실성을 가져다 줄 수 있기 때문에 추가 요구사항을 거절해야 하는 상황이 올 수도 있다. 여기에서 고객의 요구사항을 모두 담아내기 힘들다는 단점이 발생한다.
하지만, 고객의 추가 요구사항이 없을 경우에도 고객의 요구사항을 모두 담아내기 힘들다는 단점이 존재한다.
Waterfall Model의 가장 중요한 과정은 내가 생각하기에 요구사항 분석 과정이다. 요구사항 분석이 제대로 수행되어야 고객이 원하는 로직을 모두 구현할 수 있기 때문이다. 그런데 요구사항을 완벽히 분석한다는 것이 가능할까? 바로 앞에 대화하고 있는 사람의 속마음도 잘 모르는데 심지어 잘 만나지도 않고 접점도 크게 없는 고객의 요구사항을 완벽히 분석하라? 개인적으로는 매우 불가능한 작업이라고 생각한다.
이런 어려운 작업을 수행해야 하는데, 만약 요구사항에서 누락된 부분이 있다면 사실상 고객의 추가 요구사항(심지어 거부할 수 없는!)이 되는 것이 된다. 하지만 아이러니하게도 이 경우는 그나마 나은 상황이라고 볼 수 있다.
만약 고객이 Verification 과정에서 요구사항의 누락을 발견했다면?
이는 Waterfall 모델이 고객의 불만을 발생시킨다는 단점으로 이어진다. 고객은 개발 프로세스에 거의 참여하지 못하기 때문에 개발 과정을 거의 인지하지 못하고, 당연히 결과물을 파악하지 못한다. 결국 고객은 개발팀을 믿을 수밖에 없는데, 당연히 불안감이 생길 것이다. 개발팀 입장에서도 고객의 즉각적인 피드백을 받으며 수정할 수 없기 때문에 고객의 기대치와 개발팀 작업 간의 간극이 커지게 된다.
결국 고객은 최종 확인 과정에서 처음으로 Software가 구동되는 것을 확인할 수 있고, 실제 소프트웨어를 시각적으로 확인한 뒤에서야 수정요청이 발생하는 경우도 다수 존재한다.
그리고 이 경우 고객사의 요청을 거절하기는 상당히 껄끄럽다. 고객사 측에서 "나는 당연히 이것까지 생각했는데 왜 안되어 있냐"라고 주장할 경우 "요구사항 명세서 제대로 안 보셨어요?"라고 말하기엔 돈 주는 사람에게 그런 말을 하기가 상당히 꺼려지는 것이 사실이며, 요구사항 명세서가 모호하여 실제로 이해가 어려운 경우도 있을 것이다. 그렇다고 이미 많은 단계를 지나온 상태에서 다시 되돌아가 기획단계부터 수정되기 시작하면 일정과 비용 등 여러 항목에서 문제점이 발생하고, Waterfall Model 자체가 깨지는 결과가 나올 수도 있다.
테스트에 소홀해짐
모든 것이 짜여진 일정대로 되면 얼마나 좋겠냐만은, 현실은 그렇지 않다.
최근을 보더라도, 코로나 때문에 재택근무 환경으로 바뀌는 상황이 발생했는데 이런 특수 상황을 예측했던 사람은 몇 명이나 있었을까?
만약 특수 상황 때문에 개발 일정이 밀린다면 어떤 과정이 소홀해질까? 바로 Code Inspection, Unit Test, 그리고 Verification 과정이다.
개발자는 아무래도 시간에 쫓긴다면 "일단 기능이 구현되면 된다"라는 생각을 가지게 된다. 이후에 발생하는 에러들은 유지보수 단계에서 수정하면 된다는 생각을 하며 테스트에 소홀해지게 될 것이고, 시간이 없을수록 더더욱 이런 마음은 강해질 것이다.
즉, Verifiaction 및 테스트 과정이 소홀해지며 제품의 품질이 떨어질 수 있는 것이다.
문서화에 발생하는 자원 낭비
Waterfall 방식을 나쁘게 말하라면 나는 이렇게 말할 것이다
"불확실성을 허락하지 않기 위해 모든 과정을 문서화하여 계획대로 수행되어야 하는 컨베이너 벨트와 같은 개발"
Waterfall Model의 가장 중요한 점은 계획에 따라 수행되어야 한다는 점이다. 또한 이전 단계로 돌아가서는 안된다는 점이다.
이런 특징들을 모두 충족시키기 위하여 Waterfall Model은 문서화에 많은 시간을 들인다.
꼼꼼한 문서화는 관리자 입장에서는 장점이 될 수 있겠으나 이 문서를 직접 작성해야 하는 개발자에게는 부담 그 이상도 이하도 아니다.
개발자는 실제 개발보다 문서화와 문서를 검증하는데 더 많은 시간을 쏟게 되며, 이는 완벽한 자원 낭비이다.
요구사항 파악, 계획, 문서화에 자원이 투입되어야 하는데 Waterfall Model에서는 매우 중요한 과정이기 때문에 가장 핵심이 되어야 할 제품 개발에 투입할 자원이 부족해진다는 단점을 가지고 오는 것이다.
사실상 불가능한 "완벽한 완료"
사실 Waterfall Model은 이론상 매우 완벽한 모델이다.
"이전 단계를 완벽히 완료하면서 모든 일이 계획대로 수행된다"라는 가정만 있다면!
... 얼마나 허황된 꿈인지 알 수 있다.
당장 5분 뒤에 무슨 일이 일어날지도 모르는 것이 사람 일이다. 그런데 고객과의 최소한의 소통으로 고객이 표현은 안 했지만 마음속으로 원했던 요구사항까지 파악하여 모든 요구사항을 분석하고 특수상황들까지 고려한 계획을 짜서 계획에 오차 없이 개발을 하고 확인 과정에서도 에러 없는 완벽한 소프트웨어를 개발한다?
나는 이게 절대로 가능하다고 생각하지 않는다. 과정을 완벽히 완료한다는 것이 사실상 불가능한 이상 Waterfall Model은 현실과 가장 괴리감 있는 개발 방식이 되는 것이다
