책 이야기 - 실천 반복형 소프트웨어 개발

왜 반복형 개발인가?

 Disciplined Agile Delivery (DAD)를 비롯해 애자일 개발에 가장 큰 영향을 끼치고 있는 인물인 Scot Ambler는 2007년부터 자신의 웹 사이트에서 비 정기적으로(거의 1-2년에 한차례)프로젝트 성공에 대한 설문을 진행해 오고 있다. (2013년 투표는 2013년 12월1일 현재 진행중이며 결과가 나오면 살펴볼 기회를 가져보려 한다.)

아래 표는 가장 최근 이뤄진 2011년의 조사 결과이다.

 여기서 눈여겨 보아야 할 것은 성공률 1위가 애자일 개발이 아닌 반복형 개발이라는 점이다.
 반복형 개발은 순차 점증적 개발(Iterative and incremental development)과 동일한 의미 이며 폭포수 개발 방식과 마찬가지로 여러가지 수정모델이 존재하는데, Rational Unified Process로 흔히 불리우는 Unified Process가 대표적이며,  2위와 3위에 오른 애자일 소프트웨어 개발 프로세스들 또한 반복형 개발에 근간을 두고 있다.

반복형 개발 VS 애자일 개발 VS 폭포수 모델

 애자일 개발과 반복형 개발은 실상 프로젝트 내부에서 이뤄지는 작업의 내용면에서는 사실상 큰 차이가 없다고 보는데, 두가지 개발 방식에 대한 차이는 무엇을 하는가 보다는 무었을 지향하는가에 있기 때문이다.

 애자일 개발은 가치 지향적이다. 애자일 개발은 프로세스나 계약, 절차보다 완성된 소프트웨어가 지니는 가치를 가장 중심에 놓고 프로세스를 바라보는 관점을 지닌다. 
반복형 개발은 폭포수 개발과 마찬가지로 기본적으로는 절차 지향적이다. 인적 자원에 크게 의존 할 수 밖에 없는 소프트웨어 개발 프로젝트가 필연적으로 지니게 되는 불가시성을 최대한 배제하기 위해 반복적이며 점진적으로 계획하고 실행하는 방법을 택하고 있다. 
XP나 스크럼과 같은 애자일 개발 프로세스들은 기본적으로 반복형 개발을 기초로 하여 개발 프로세스들을 확립하였다. 짧은 개발주기, 지속적인 통합/배포, 그리고 회고를 통한 피드백이 그것이다. 

 엔터프라이즈 어플리케이션 개발에 있어서 애자일 개발이 지니는 최대의 약점은 고객으로 부터 듣는 질문중 가장 단순하면서도 가장 흔히 듣는 질문인 "그래서 얼마면 되는거요?"라는 질문에 답변하기가 까다롭다는 점이다. 특히나 대규모의 프로젝트에서 "일단 한번 해 보시면 얼마나 좋은지 아실껍니다." 라는 답변으로 고객을 안심시키기는 쉽지가 않다는 이야기 이다.

 그렇다고 견적내기 편하다는 이유로 폭포수 모델을 택하기엔 너무나도 많은 대가를 감수해야만 한다. 폭포수 모델이 오늘날 천덕꾸러기 신세를 면치 못하는 이유는 만들어 내야 하는 소프트웨어에 대한 복잡성이 검토를 통해 예측 가능한 법위를 넘어섰기 때문이다. 

 현대의 사회 시스템은 끊임없이 복잡한 방향으로 변화하고 있으며 이를 추상화 하여 다루는 소프트웨어도 함께 복잡성을 더해가고 있다.  이에 대해 반복형 개발은 끊임없이 완성된 소프트웨어를 만들어 내고 그에 대한 피드백을 통해 프로젝트를 통제해 나가는 방식을 취함으로서 이러한 복잡성에 대응해 나가고 있다.

 즉, 고객이 진정 원하는 소프트웨어의 사양은 완성된 소프트웨어를 직접 만져보기 전에는 확정하기 어렵다. 따라서 검토만으로 해결 할 수있다고 주장하는것은 너무나 천진 난만한 생각이며, 이에 대한 대가로 지불되는 것은 대부분의 개발 현장에서 개발자들의 땀과 눈물이 될 것이다.  

실천 반복형 소프트웨어 개발에서 다루는 내용

이제 본론인 책 이야기를 할 시간이다.

 저자인 쓰다씨는 현재 일본 마이크로소프트에서 테스트 전문가로 활동하고 있으며 필자가 소속된 豆蔵Mamezou의 OB이기도 하다.

저자는 이 책의 대상 독자에 대해 책 머리에 다음과 같이 밝히고 있다.

• 3~5년정도의 소프트웨어 개발 경험이 있는 분
• 프로젝트 팀을 리드하는 위치이며, 팀운영방침을 정해야 하는 분
• 지금부터 프로젝트팀을 리드하는 위치에 서게되는 분
• 프로젝트팀의 운영에 대해서 문제의식을 가지고 있는 분
• 개발중인 소프트웨어의 품질을 제어할 수 없어서 곤란을 겪고 있는 분
• 개발을 지원하는 툴을 도입하고 싶지만, 조직의 문화적 저항에 부딧혀 뜻을 이루지 못하는 분
• 툴을 도입하기는 하였으나 제대로 활용하는 방법을 알지 못하는 분
• 폭포수개발 프로세스에서 벗어나고 싶은 분
• 반복형 개발을 시험해 보고 싶지만, 몇번을 반복해도 끝이 나질 않아 실패한적이 있는 분

 이 책에서는 언어나 생산되는 소프트웨어에 관계없이 다양한 소프트웨어 개발 프로젝트에서 사용 가능한 범용적인 반복헝 개발의 원칙과 규율을 제시하고 있다.

 책에서 소개하는 원칙과 규울은 단순히 이론에 그치는것이 아니라 현재 나와있는 최적의 개발지원 환경들(빌드, 형상관리, 이슈트래킹, CI)이 개발 규모와 진행상황에 따라 어떻게 연동되어 운용 되어야 하는지를 구체적인 예제와 함께 설명하고 있다.

 개인적으로 이 책의 가장 맘에 드는 부분은 일방적으로 이러한 방식이 가장 좋습니다 라고 강요하는 식이 아니라 스스로 각자의 개발 현실에 맞는 프로세스를 찾아 나갈 수 있도록 다양한 힌트를 제시하고 있다는 점이다.

품질과 납기를 동시에 잡는 비장의 무기 - 타임박싱 관리 기법

 저자인 쓰다씨가 반복형 개발에서 특히 중요하게 생각하는 개념은 타임박싱기법 이다.
타임박싱이란 기간 안에 끝낼 수 있는 작업과 그렇지 못한 작업을 선별하여 다음 반복에 넘기는 프로젝트 관리 기법을 지칭하는 것으로 정해진 시간 속에서 개발 사이클을 반복해야 하는 반복형 개발에서 품질과 납기를 지켜내기 위해 매우 유용한 개념이라 할 수 있다.

타임박싱 기법에 대해서는 아래 포스팅에서 자세히 다루고 있다.

프로젝트 관리 기법 - 타임박싱(Timeboxing) 관리 기법

그래서 얼마면 되는거요?

 마지막으로 아까전에 했던 "그래서 얼마면 되는거요?"라는 고객의 질문에 대해서 필자는 다음과 같이 답변을 하고자 한다.

"반복형 개발이 더 싸지지는 않을지 모릅니다. 하지만 같은 비용의 폭포수 개발과 비교하자면 위험 요소들의 제어가 훨씬 쉬워지며, 무엇보다 좋은 품질의 소프트웨어를 생산하는것이 가능해 집니다."

 반복형 개발(또는 애자일 개발)은 개발자가 편해지자고 하는것이 아니다. 오히려 개발자는 폭포수형 개발에 비해 훨씬 많은 작업들을 수행 해야만 한다. 그렇기 때문에 빌드하고 에러를 체크하고 코드 품질을 유지하는 등의 작업들을 철저하게 자동화 해 나감으로서 사람만이 할 수 있는 창조적인 작업에 보다 많은 시간을 투자 하는것이 가능해지는 것이다.

 개발 현장에서 애자일 프로세스의 도입을 검토하고 있거나 이미 도입하였더라도 프로세스의 개선에 목말라 하는 모든 이들에게 이 책을 꼭 추천한다.