애자일 개발의 불편한 진실

요즘들어 신문1면을 자주 차지하는 각종 보안관련 문제들의 원인중 상당부분이 하청중심의 소프트웨어 제작 관행에 있다는 것이 밝혀짐에 따라 많은 기업들이 사내개발을 검토/강화 하는 추세이다. 외주개발을 사내개발로 전환하는데 있어서 큰 어려움 중 한가지는 개발 프로세스를 확립하는 것 인데, 개발 프로세스는 구성원들의 성향에 기반한 기업문화와 밀접한 관련이 있기 때문에 아무리 좋은 옷이라도 몸에 맞지 않으면 소용이 없는것처럼 사내 구성원들간의 이해관계나 문화적인 배경 등을 제대로 고려하지 않는다면 제대로 뿌리내리기 힘들다.

 개발 프로세스 도입에 대한 컨설팅 하다보면 많은 고객들이 애자일 개발에 대해 관심을 가지고 문의를 해 오는데, 잘못된 관점으로 애자일 개발을 인식하고 있는 경우가 많다. 이는 각자의 위치에서 편한쪽으로 애자일 개발을 해석하려는 경향이 있기 때문이다.

동일한 대상이라도 바라보는 관점에 따라 여러가지 오해를 낳는다

오늘은 애자일 개발에 대한 올바른 접근방식을 이해하기 위해 애자일 도입시에 흔히 볼 수 있는 오해들에 대해 살펴보고자 한다.

애자일 개발은 쉽다

애자일 개발을 실패로 이끄는 가장 흔하면서 심각한 오해이다.

애자일 개발은 고도의 소프트웨어 공학에 대한 지식을 기반으로 하는 개발 방법론이다. 필자의 경험상 애자일 개발을 제대로 소화해 내기 위해서는 반복형 개발의 요소들을 완전히 마스터 해야만 한다. 프로세스 자체는 간단해 보이지만, 요건정의,모델링,설계,구현,테스트의 모든 과정에서 상당히 높은 수준의 소프트웨어 공학 지식이 종합적으로 요구된다.
컨설팅을 진행하면서 흔히 보는 풍경은 의욕 가득한 젊은 개발자와 매니저가 책 몇권을 읽고 애자일 팀을 꾸려나가다 좌절하는 것이다. 애자일 개발은 절대 쉽지 않다. 애자일 개발팀에는 고도의 모델링에 대한 지식을 기반으로 자동화 테스트, 이슈트랙킹, 지속적 통합, 형상관리와 같은 최신 개발 환경의 효율적인 운용이 필수로 요구된다.
처음 도입하는 팀에서 이러한 부분들을 모두 자체적으로 해결하기는 쉽지 않으므로, 전문가의 컨설팅을 받거나 최소한 경험자를 정기적으로 초빙함으로서 시행 착오를 최소화 해야 한다.

누워서 떡 먹기 조차 말처럼 쉽지 않다 (출처:서울속편한내과?)

애자일 개발은 상향식이다

애자일 개발 도입에 대한 컨설팅을 진행하다보면 2~3년차의 개발자가 중심이되어 애자일 개발팀을 꾸려 나가는 경우를 흔히 본다. 2~3년차라면 사실상 이제 막 초보 개발자를 졸업하는 시기로 아직 개발 역량 뿐만 아니라 정치적 역량도 부족하다. 애자일 개발을 원활히 진행하기 위해서는 프로젝트를 둘러싼 여러 이해관계자와의 긴밀한 의견조정이 필수인데, 이 부분은 윗선의 지원이 없이는 사실상 불가능하다.
애자일 개발도입의 성공을 위해서는 일선 개발자들의 주도적이고 자발적 참여 만큼이나 경영진으로부터 시작되는 하향식 서포트도 중요하며, 도입 또한 대규모 프로젝트의 경우 하향식 도입이 더 효과적인 경우도 많다.
 무엇보다 윗선의 이해를 제대로 구하지 못한 상태에서 개발자들 주도로만 진행하게 될 경우 개발 과정에서 발생하는 크고 작은 문제에 대해서 '거 봐라. 그러길래 하던데로 하지...'라는 비아냥과 함께 최악의 경우 프로젝트 자체가 기존 개발방식으로 돌아가 버리는 경우도 발생하기 쉽다.

애자일 개발을 도입하면 일의 양이 적어진다

어떤이는 불필요한 문서화 작업을 줄일 수 있어 작업량이 줄어든다고 애자일 개발에 대해 설명한다. 하지만 애자일 개발의 도입한다고 해서 일의 양이 적어지진 않는다. 오히려 반복형 개발의 경우 폭포수형 개발에 비해 이터레이션 내에서 설계,구현,테스트,배포가 매번 실행되야 하기 때문에 일의 양이 엄청나게 많아지는데, 그렇기 때문에 테스트,빌드,배포와 같은 기계적인 작업을 자동화 하여 최대한 사람의 일을 줄이지 않으면 안되는 것이다. 바꿔 말하자면, 이러한 자동화 툴의 도움 없이 진행하는 애자일 개발은 반드시 실패하게 될 것이다.

애자일 개발은 프로젝트 성공률을 올려준다

여러 조사에 의하면 애자일 개발이 성공률을 획기적으로 올려주지는 않다. 대신 만들어지는 소프트웨어의 가치를 높여준다. 애자일 개발과 같은 반복형 개발이 지니는 가장 큰 장점은 기간이나 예산면에서 실패를 하더라도 핵심 요구조건 조차 전혀 움직이지 않는 최악의 상황은 면할 수 있다는 점 이다. 따라서 애자일 개발의 장점을 부각시키고자 한다면 성공률을 올려준다기 보다는 실패할 확율을 줄여줄 수 있다고 설명하는것이 더 적절할 것이다.

애자일 개발에는 계획이 필요 없다

폭포수형 개발과 비교해 계획의 형식이 달라질 뿐 계획 자체는 애자일 개발이라 하더라도 반드시 필요하다. 프로젝트 실행의 기본 사이클인 PDCA(Plan,Do,Check,Action)는 애자일에서도 유효 하며 특히나 추정과 결과에 대한 피드백은 정확하고 빠르게 이루어져야 한다.

모든 일에는 계획이 필요하다 (출처:사망공책)

애자일 개발은 고객의 부담을 덜어준다

고객의 적극적 참여는 애자일 개발의 핵심 요소이다. 애자일 개발에서는 고객이 원하는 가치를 만들어 내기 위해 보다 많은 고객의 참여를 필요로 한다. 비단 애자일 개발 뿐만 아니라 모든 고객의 참여 없는 개발은 등대없이 밤바다를 항해하는것과 같아서 절대 목적지에 다다를 수 없을것이다.

애자일 개발은 개발기간을 단축시켜준다

애자일 개발은 이터레이션을 통해 빠른 피드백을 가능하게 해 주지만, 전체 개발 기간이라는 면 에서는 기존의 폭포수형 개발에 비해 절대 빠르다 할 수 없다. 오히려 현실적인 추정이 가능해 지기 때문에 예상 개발 기간은 폭포수형 개발에 비해 늘어나는 경우도 있다. 하지만 이것을 생각해보자. 계획한 기간 내에 끝나는 폭포수형 개발이 과연 얼마나 될까? 게다가 개발기간이 예상보다 늘어나는 경우 필연적으로 품질저하가 따라온다.

애자일 개발은 테스터가 필요 없다

매 이터레이션마다 테스트가 동반되는 반복형 개발에서 테스터의 필요성은 폭포수형 개발보다 높을 수 밖에 없다. 이상적인 테스터는 요건을 가장 정확히 이해하고 있는 고객이므로 여기서 또한 고객의 참여가 절실히 필요해 지는 부분이다.

애자일 개발에는 설계가 필요 없다

설계없이 개발을 하겠다는것은 지도 없이 세계일주를 하겠다는것과 같다. 애자일 선언서의 "포괄적인 문서보다 작동하는 소프트웨어를"이란 문구가 의미하는것은 문서작성 자체가 필요 없다는 뜻이 아니라 꼭 필요한 문서만 만들라는 의미이다.
애자일 개발에서 설계는 두꺼운 서류뭉치가 아닌 그때그때 이해당사자들 간의 커뮤니케이션을 보조해 줄 도구로서의 역할을 해 줄 수 있는것 이면 무엇이든 충분하다.
애자일 개발이 정착된 팀에서의 문서작성은 UML모델을 적극적으로 사용하며 특히 임시문서의 경우 화이트보드에 그린 내용을 사진찍는것으로 대체하는 경우가 많다. 애자일 개발의 설계/문서화에 대한 내용은 "애자일 시대의 모델링:애자일 팀의 확장에 따른 문서화에 대한 조언"을 살펴보기 바란다.