[Project design] 프로그램 공정(워터폴 vs 애자일)

안녕하세요. 명월입니다.

이 글은 프로그램 공정(워터폴 vs 애자일)에 대한 글입니다.

보통 우리가 어떤 프로그램을 작성한다 싶을 때, 많은 분들이 컴퓨터 키고 IDE 툴(Visual studio나 eclipse)를 실행하고 코드부터 작성하면서 프로그램을 작성합니다.

저도 대학교 다닐 때, 신입 때 항상 그랬던 것 같습니다.

그런데 이런 식으로 프로그램을 작성하면 프로그램이 산으로 간다던가 상상했던 퀄리티보다 한참 떨어져서 나오는 경우가 많습니다. 뛰어난 프로그램 작성 능력이나 머리가 매우 좋으신 분들은 이렇게 해도 좋은 품질의 프로그램의 나올 수 있겠지만 적어도 저는 생각한 대로 프로그램이 안나오는 경우가 많았습니다.

이유야 많이 있겠지만 우선 내가 생각했던 계획했던 내용을 잊어버린다던가 또는 작성하면서 욕심이 생겨서 원래 생각했던 내용에서 이런 기능이 있으면 좋겠다 해서 마구잡이로 기능을 끼워 넣거나 테스트가 부실해서 생각치도 못했던 버그가 많이 발생하거나 등등의 이유가 있습니다.

공부할 때까지야 이런 식으로 프로젝트 실패로 이어진다해도 별 손해는 없지만 실무에서 이런식으로 하다가 프로젝트 실패로 이어지면 곧 손해로 이어집니다.

또 공부할 때와는 다르게 실무에서는 혼자가 아닌 팀 단위로 움직이기 때문에 팀원이 우왕자왕하거나 프로젝트의 방향 제시등을 제대로 하지 못해 팀내 분위기가 안 좋아지는 경우도 많이 있습니다.

이러한 것을 피하기 위해서는 프로젝트를 설계하는 사람들은 먼저 공정을 생각해야 합니다.

이 프로젝트 공정이란 우리가 어떤 프로그램을 만들지 설정하고 그 프로그램에 어떠한 과정을 통해서 어떠한 방법으로 테스트를 하며 어떤한 방법으로 정보를 공유하는 방법을 설정하는 것입니다.

이론적으로 대표적인 프로젝트 공정에는 워터폴 공정과 애자일 공정이 있습니다.

워터폴에 대한 이론적 설명은 제가 하는 것보다 위키백과를 통해서 확인하는게 좋을 듯 싶네요.

링크 - https://ko.wikipedia.org/wiki/폭포수_모델

워터폴은 간단하게 이야기하면 다음과 같은 공정입니다.

간단하게 설명하면 요건 정의는 고객이 만들고 싶어하는 정의, 어떤 데이터를 어떻게 출력을 할지, 어떤 환경에서 사용할 지를 결정하는 부분입니다. 보통 PM(Project Manager)들이 고객과의 회의등을 통해서 결정하게 되는 부분입니다.

기본 설계는 UML로 이것저것 다이어그램을 만들어도 좋은데 보통은 화면 설계와 디비 설계가 여기에 포함됩니다. 좀 더 자세히 작성이 가능하면 스토리 보드도 여기에서 작성을 하게 되네요.

상세 설계는 프로그램 상에서 추상 클래스는 어떻게 할 것이며 클래스의 계층 구조, 공통 함수등을 설정하고 최종적으로 프로그램을 어떻게 작성할 것인지 정하는 부분입니다.

개발은 말 그대로 프로그램 코딩을 실시하고 개발 내용에 따라 함수 단위로 테스트하는 것을 단위 테스트입니다.

그리고 상세 설계의 내용대로 각 클래스 간의 연결 관리 테이터를 Input를 하면 정확한 Output이 나오는지 확인하는 테스트입니다.

스텐다드 혹은 시나리오 테스트는 기본 설계대로 프로그램이 전체적으로 제대로 작동하는 지, 고객이 원하는 시나리오대로 작동하는 지 확인하는 테스트입니다.

마지막은 프로그램이 작성되었으니 납품을 하는 것이네요.

워터폴의 장점은 역시 프로그램을 튼튼하게 만들 수 있는 장점(버그가 거의 없는)이 있고, 정확한 공수 계산과 팀 할당, 배분을 할 수 있고, 각 역할이 정확하게 분리가 되기 때문에 팀 인원 간의 의사소통이 비교적 쉽고, 혹시 프로젝트 중간에 인원 수급에 문제가 생길 경우 바로바로 대처가 가능한 형태입니다.

단점으로는 공정 자체가 길어보이는 만큼 개발 기간이 길어진다는 점이 있습니다. 그리고 공정의 유연성이 거의 없기 때문에 상세 설계 중에 고객의 요청 사항이나 변경 사항이 발생했을 시 새 브런치로 분리하기가 어렵습니다.

애자일에 대한 이론적 설명도 위키백과 링크를 해 놓겠습니다.

링크 - https://ko.wikipedia.org/wiki/애자일_소프트웨어_개발

애자일은 간단하게 이야기하면 다음과 같은 공정입니다.

애자일은 워터폴과 비교할 때 그림으로 보면 단순히 위에서 아래로 흐르는 것이 옆으로 흐르는 것 같지만 업무는 다릅니다.

애자일은 보통 설계와 개발을 최대한 단순 공정으로 만드는 것으로 소스 자체를 아예 설계도처럼 작성하게 됩니다.

즉, 워터폴에서는 추상이나 인터페이스를 많이 사용하지 않아도 결과물을 낼 수 있지만 애자일에서는 모든 것을 최대한 추상으로 만들어 소스 안에 설계도를 만들어 버리는 방식으로 개발을 합니다.

그렇게 설계 단계를 아예 생략을 해버리고 요구 사항이 오는 대로 바로 바로 개발을 하는 방법입니다. 그리고 요건 정의마다 버전을 생성해서 그대로 브런치를 만들어 테스트로 넘겨버리는 방법을 사용합니다.

이 부분은 스크럼 주기라고 하는데 보통은 1달 단위 혹은 2달 단위로 주기를 만들어서 단계 별로 개발, 테스트가 실행됩니다.

글로 설명하니 워터폴과 정확한 표현이 되지 안되네요.

예로 설명을 하면, 최초 개발을 할 때 0.01버전으로 요건 정의가 옵니다. 그리고 0.01버전의 개발을 시작할 때, 요건 정의에서는 0.02버전의 요건 정의가 만들어 집니다.

다시 0.01버전의 개발이 끝나고 테스트 공정으로 넘어가면 개발은 0.02버전을 개발합니다. 그 때 다시 요건 정의는 0.03버전의 요건 정의가 만들어 집니다.

0.04 버전의 요건정의가 이루어지면 0.01버전의 납품이 이루어집니다.

워터폴의 경우는 요건 정의부터 납품까지 순차적으로 일어나고 중간에 브런치가 발생해도 그 이후에 작성이 가능하지만 애자일의 경우는 병렬적인 공정으로 계속적으로 생산이 일어납니다.

애자일의 장점은 프로그램을 빠른 시간에 만들 수 있다는 장점과 공정의 유연성이 매우 좋고, 역시나 정확한 공수 계산과 팀 할당, 배분을 할 수 있다는 장점이 있습니다.

단점으로는 애자일 개발 공정을 하기 위해서는 팀원 간의 높은 개발 스킬을 요구하게 되며, 병렬적인 처리이다 보니 중간에 버그가 발생할 시에 대처하기가 힘들어지는 단점이 있습니다.(0.02에서 버그가 발생했는데 개발은 0.03를 달리고 있습니다. 이 때, 이 버그를 0.03에서 고치고 버그가 있는 채로 0.02를 납품을 하느냐. 0.03버전을 멈추고 스크럼을 다시 0.02를 돌리느냐하는 문제입니다.)

그래서 애자일 공정으로 만드는 경우는 품질이 약간 떨어지는 문제가 발생합니다.

여기까지가 이론적인 설명입니다. 실무에서는 위처럼 이론대로 움직이지는 않습니다.

여러가지 이유가 있습니다만 가장 큰 이유는 역시나 돈의 문제입니다.

워터폴의 경우는 정말 품질 좋은 프로그램이 나올 수 있으나 개발기간이 길어지는 만큼 돈이 많이 듭니다. 애자일의 경우는 빠른 개발로 돈을 많이 아낄 수 있는 장점이 있으나 역시나 품질의 문제가 발생할 여지가 있습니다. 그리고 공정 자체가 높은 스킬을 요구하기 때문에 가격이 비싼 개발자를 많이 사용하기 때문에 꼭 많은 절감 효과가 있다고 보기에도 힘듭니다.

고객의 입장에서는 시니어 개발자 한두명과 일반 개발자를 여럿 붙여서 공정을 만들기를 원합니다.

그렇게 높은 품질과 낮은 가격으로 프로젝트가 나오기를 기대하는 것이지요.

그러다 보니 많은 개발자들이 이 워터폴과 애자일의 적절하게 섞은 개발 공정법이 나옵니다.

저의 경우도 애자일의 방식으로 설계를 쭉 생략해 버리고 프레임 워크와 코어를 최대한 제대로 구성하고 개발부터 테스트를 하나의 브런치로 묶어서 개발을 합니다.

즉, 요건정의부터 개발까지는 애자일 방식, 개발부터 최종 테스트까지는 폭포수 형식으로 개발 공정으로 많이 짭니다. 그러면 테스트 때문에 어쩔 수 없이 시간이 들어가기는 합니다만 정석 워터폴보다는 빠른 결과물을 만들 수 있고, 코어와 프레임워크는 시니어 개발자가 맡고, Process영역 즉, 상속을 받아서 업무 프로그램을 만드는 부분은 일반 개발자가 맡는 형식으로 공정을 만들기 때문에 버그 발생율도 최소한으로 줄일 수 있습니다.

또, 좋은 장점은 시니어급 개발자가 많이 있을 경우 여러 프로젝트를 한번에 엮어서 진행할 수 있습니다.

즉, 시니어 개발자 4명 A,B,C,D가 있을 경우 AA라는 프로젝트에는 A,B가 시니어 C,D가 일반 개발로 담당을 맡고 BB라는 프로젝트에는 C,D가 시니어를 맡고 A,B가 일반 개발 담당을 맡는 형식으로 섞어서 개발도 가능합니다.

여기서 일반 개발자 급이 팀원으로 들어오면 부하기 있는 프로젝트에 쉽게 접근도 가능하고 여러가지 공정 변형의 이점이 있습니다.

단점은 개발자가 스크럼의 공포에 죽어나가겠네요..ㅎㅎㅎ 그러나 인력을 넣고 빼기가 워낙 용이하기 때문에 팀내에 연차나 휴가가 발생하게 되면 대체 인력 투입하기도 용이해 집니다.

이런 형식으로 저는 꽤 오랜 시간 프로젝트를 운용해 왔고 물론 전혀 문제가 없었던 것 아니었습니다만, 저에게는 딱 맞지 않는 개발 공정이지 않나 생각이 되네요.

여기까지 프로그램 공정(워터폴 vs 애자일)에 대한 글이었습니다.

궁금한 점이나 잘못된 점이 있으면 댓글 부탁드립니다.