애자일이라는 주제는 다소 이해하기 어려운 것일 수 있으나, 보기에 따라 쉽게 이해 할 수도 있다.

애자일, 애자일 하는데 애자일은 도대체 무엇을 하는 걸까? 새로운 기술인건가? 아니면 무슨 프로그래밍 언어인건가? 왜 요즘에 소프트웨어를 개발하는 곳에서 끊이지 않고 화자가 되는 이 녀석의 정체는 무엇일까?

애자일은 흔히들 '방법론'이라고 얘기 한다. '방법론'이라는 말은 처음 접할 때 쉽게 가슴에 와 닿는 용어는 아닌 듯 싶다. 그렇다면 '프로세스'는 어떤 가? 그저 그렇다. 그냥 쉽게 '일하는 방식' 정도로 생각 해 보자. 애자일은 기존에 소프트웨어 개발을 할 때 사용하던 '구닥다리 일하는 방식'을 오랜 기간에 걸쳐 소프트웨어 제품을 만들어 오던 거장들이  소프트웨어의 소프트 한 면을 살려서 정의 한 일종의 '유연하게 일하는 방식' 이라고 볼 수 있겠다.

순서대로 일이 진행되고 다시 되돌아 갈 수 없는 구조로 일하는 방식을 소프트웨어 세계에서는 폭포수 개발 방식 (Waterfall model)이라고 부른다.

폭포수 개발 방식에서는 일반적으로 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포 형태로 단계적으로 프로젝트가 수행이 된다.

그럼 폭포수 개발 방식을 따르면 모든 소프트웨어 개발 프로젝트가 잘못 흘러가는가? 꼭, 그렇지만은 않다. 현재 해결하고자 하는 문제점이 무엇인지 명확하고, 솔루션 역시 구체적이라면 해볼만하다.

예를 들어서 100권짜리 백과사전에 있는 모든 내용을 전산화하는 프로젝트가 있다고 가정해보자. 1권씩 차례대로 1장 1장 옮기면 된다. 화면이 그리 복잡하지도 않을 것이다. 개발하는 속도 측정도 무척 간단하다. 1페이지 전환하는 시간을 계산하여 전체 페이지수만 곱하면 된다. End image가 너무나도 뚜렷하다. 이런 경우에는 폭포수 개발 방식도 사용이 가능하다.

하지만, 대부분의 소프트웨어 개발은 그렇지가 않다. 위에서 언급하였던 집필하는 과정과 너무나도 비슷하며, 위에서 나열한 문제점들로 인해 실패하는 프로젝트가 너무나도 많다. (반 이상 될 것이다.) 이렇게 실패한 프로젝트에서 흔히들 볼 수 있는 원인은 바로.. '고객의 요구사항 변경' 이다.

대부분의 소프트웨어 개발 프로젝트는 고객의 Needs에 의해 시작된다. 그런데 재미있는 사실은 고객이 본인들이 원하는 것을 잘 표현하지 못한다는 것이다. 심지어는 잘 모르는 경우도 많다. 필자는 처음 이것을 깨달았을 때 솔직히 말하자면 어이가 없었다. 왜 본인들이 하고자 한 일인데, 어떻게 잘 모를 수가 있지? 하지만, 곧 이유를 알 수 있었다.

모르는 것이 아니라 소프트웨어가 만들어지는 과정이나 어려움을 잘 모르기 때문에 생기는 문제가 대부분이였다.

가령, 어느 정도 개발이 된 화면을 본 고객이 쓱~ 쳐다보면서 한 마디 거들었다.

"이거.. 레이아웃을 이렇게 좀 바꿔보면 어떨까요?"

개발자는 속으로 이렇게 생각 할 것이다.

'참나.. 처음 부터 그렇게 만들라고 할 것이지..'

개발자가 일주일간 열심히 작업해서 원하는 대로 소스를 수정하여 고객에게 보여주었다. 고객 왈,

"아.. 예전게 더 좋은 거 같아요, 예전 걸로 가시죠?"

개발자의 속마음은 더 이상 쓰지 않더라도 예상하리라 본다.