애자일에 대한 관심도가 높아지던 2000년 중반 이후부터 전통적인 프로세스를 사용하는 경우가 많은 SI 프로젝트에 애자일 프로세스를 적용하는 사례가 늘어나기 시작했다. 프로젝트 초기에 정해진 계약과 고객의 요구사항에 맞춰 개발하기 위해서는 전통적인 프로세스를 따를 수 밖에 없어 애자일을 일부 적용한 정도로는 실패할 수 밖에 없었다. 최근에는 SI 프로젝트에도 애자일을 좀더 많이 적용하려는 노력이 많아지는데 SI의 한계로 인해 많이 지친 것이 사실이다. 이번 회에서는 애자일을 SI 프로젝트에 적용하기 어려운 이유를 살펴보면서 돌파구를 찾아보고자 한다.
SI 프로젝트에 애자일 적용 방안
SI 프로젝트 vs. 애자일
SI 프로젝트는 프로젝트를 시작하는 시점에 모든 환경이 계약에 의해 정해져 있다. 프로젝트 범위, 기간, 심지어는 만들어야 하는 기능까지 정의된 경우도 있다. 반면에 애자일은 프로젝트를 하면서 정의해 나간다. 이러한 이유로 SI 프로젝트는 전통적인 소프트웨어공학에 기반한 프로세스에 가까워 계획적이고 정적인 환경이고, 애자일은 조정이 가능하고 동적인 환경으로 구성된다(그림1).
<그림1> SI 프로젝트와 애자일의 적용 환경 비교
출처: Agile projects and the project context
SI 프로젝트에 애자일을 적용하기 어려웠던 가장 큰 이유는 계약 관계에 있는 고객의 요구사항이 초기에 정해졌다는 것 때문이었다. SI 프로젝트는 모든 프로세스가 고객이 요청한 요구사항을 중심으로 움직이기 때문에 그림1에서 나타난 것처럼 애자일의 장점인 계획을 조정하거나(Adaptive) 동적인 환경(Changing environment) 구성을 활용할 수가 없었다. 해외 사례를 보면 계획 조정에 의해 프로세스나 기간 등이 함께 수정되는 경우가 있어 애자일 적용에 문제가 발생할 확률이 낮지만 우리나라는 최초 계약이 변경되는 경우가 매우 드물다.
여러모로 전통적인 개발 프로세스의 개선 효과를 가지고 있는 애자일을 포기할 수는 없기 때문에 요구사항 정의, 분석, 설계, 개발, 구현으로 구성된 전통적인 프로세스에서 개발과 관련 있는 분석, 설계, 개발 단계에만 적용하게 되었다(그림2). 고객과 관련이 없는 부분만 적용하기 때문에 큰 무리가 없을 것으로 당시에는 판단되었다.
