그림 1에서 우측 음영처리가 있는 부분의 글은 WBS 변경에 대한 메모다. 프로젝트 중반 이후부터는 변경이 발생했다는 이야기다. 만일 이 부분에 대해 도입단계에서 고정해두었다면, 고객의 이해를 구하기 위한 설득 작업이 필요했을 것이다. 경우에 따라서는 고객이 계층적으로 존재하여 많은 보고 절차가 빈번하게 필요하기도 하다. 다행히 우리는 이러한 번거로운 절차를 피할 수 있었다. 이로써 얻은 교훈은 필연적으로 바뀔 가능성이 있는 부분을 인정하고 여지를 두라는 것이다. 

2.2 소프트웨어에 집중하라

Working software over comprehensive documentation
현장에서 종종 지나치게 상세한 명세 작업 혹은 표준화나 기법에만 초점을 맞춘 요구사항 모델링으로 비생산적인 분석 작업을 하는 것을 경험한다. 종국의 결과물은 작동하는 소프트웨어란 사실을 잊지 말아야 한다. 도입 단계에서 모호한 요구사항을 밝혀내는 일은 쉽지 않았다. 고객들마저 정확하게 무엇이 필요한지 모르는 상황이기 때문이다. 조기에 확정하기 어려운 것을 정하는데 지나치게 시간을 투여할 우려가 있어, 명세 자체보다는 요구사항 충족 기준이 되는 검증 기준 수립에 초점을 두었고 이는 표1에 보는 바와 같다. 이로써 약10주 후에 소프트웨어를 구현했을 때 사용할 지표를 2주 만에 만들 수 있었다.  앞서 말했던 것처럼 무리한 듯 보이는 개발범위에도 불구하고, 10주 후 70개의 모든 기준을 충족시킬 수 있었던 요인 중에 하나는 ‘5대1’ 비율 즉, ‘요구사항 정의 2주 대 소프트웨어 개발10주’에 있다.

[표1] 요구사항 정의 사례

3, 구축단계에서의 애자일 프랙티스
도입단계는 전체 26주의 기간 중에서 중반 15주에 해당한다. 실제 제품 개발의 대부분을 수행하는 단계이다. 애자일 프랙티스를 도입했을 때 구축 단계의 가장 두드러진 특징 중 하나는 조기에 통합이 이뤄진다는 점이다. 이는 이행단계의 부담을 한결 줄여준다. 결론부터 말하자면 조기 통합 및 상시 통합 수행은 구축단계에서 빠른 피드백과 팀 협력을 가속화 하는 효과를 가져왔고, 이행 단계로 연착륙할 수 있게 하는데 큰 공헌을 했다. 


3.1 CI 적용 과정에서 배운 협업의 가치

Individuals and interactions over processes and tools
프로젝트 초기에 나는 툴과 프로세스에 초점을 맞춰 환경을 잘 구비하고, 단위 테스트만 잘 실시하면 CI(Continuous Integration) 즉, 지속적인 통합이 가능할 것이라고 보았다. 그러나, 툴의 이점은 분명 한계가 있었고, 프로세스 실현은 그리 간단하지 않았다. 우리는 이번 프로젝트 처음으로 손발을 맞춘 팀이었고, 당연히 프로세스가 몸에 밴 팀은 아니었다. 또한, 프로젝트 일정 역시 프로세스 익히는데 사용할 여유라고는 없었다. 여기서 나는 해결책이 필요했다. 결국 개개인의 특성 파악으로 들어갔다. 프로젝트를 하면서 종종 그 사실을 잊어버리지만, 우린 모두 개성을 지닌 존재이다. 우선 각자 자신이 만들어야 할 산출물을 그리고, 해당 산출물을 통한 다른 사람과의 관계를 표현하게 했다. 작업자와 산출물 사이에 선을 그으면 행위가 나타난다. 나는 이를 문맥도(context diagram)라 칭하고, 모두에게 편한 방식으로 그려오게 했다. 흥미롭게도 관리자인 나와는 달리, 대부분 주변 개발자와의 관계를 완벽하게 알지는 못했다. 나는 그 부분을 찾아서 그려주었다. 이후에 팀원 개인과 서로가 맺고 있는 관계(Individuals and interactions)가 정형화된 부분에 대해서만, 이를 프로세스로 정의해서 공유했다.

[그림 2] 문맥도(context diagram) 작성 사례

3.2 고객과 마치 하나의 팀처럼 협력하라

Customer collaboration over contract negotiation
프로젝트에 잔뼈가 굵은 사람이라면 ‘계약서’, ‘날인한 회의록’, ‘명세서’ 등을 중요하게 취급한다. 하지만, 분쟁이 발생했을 때 이들이 개발팀을 유리한 입장에 놓을 수 있을지 몰라도, 그 이상의 가치는 없다. 구축 기간 초반에 앞서 언급한 것처럼, 70개의 기준을 충족했을 때 고객과 개발팀 사이에 신뢰 관계가 쌓였다. 신뢰 관계는 고객과 사전 협의한 사항에 대한 변경이 용이해졌음을 의미한다. 개발팀은 애초부터 지나치게 기술적인 어려움을 의식해서 요구사항 수용을 거부할 필요가 없어졌다. 고객은 언제든지 개발팀의 입장을 이해할 준비가 되어 있었다. 개발팀은 신뢰를 깨뜨리는 우를 범하지 않는 이상 계약관계에 입각해 서로를 인식하는데 에너지를 쏟는 대신에 본연의 활동 즉, 개발에 대해 집중할 수 있었다. 자신감을 얻은 우리는 고객의 요구사항 수집에 있어서도 장벽을 제거했다.

[그림 3] 개발도구에서 보는 작업목록 사례

우리는 그림3과 같이 개발도구에서 작업목록을 볼 수 있는 환경을 구축하고 있는데, 고객이 직접 올린 요청사항을 작업목록에 포함시켰다. 고객 요청의 즉각적인 수렴과 기민한 커뮤니케이션은 고객의 개발팀에 대한 신뢰감을 더욱 높여주었다. 종국에 고객과 개발팀의 협력은 마치 오랫동안 함께 해온 조직 구성원의 일상적인 협력을 보는 듯했다. 물론, 이러한 협력을 모든 프로젝트에서 실현할 수 있다고 할 순 없을 것이다. 착수보고 때 프로젝트 스폰서인 임원이 ‘고객’이라는 말에 대해 거부감을 표시하며, ‘어차피 같이 일하는 사람인데 고객은 무슨’이라며 호칭을 나무랐다. 고객들은 향후 인수인계와 기술이전을 받는데 매우 적극적이었기 때문에 고객과 마치 한 조직 내에 속한 다른 팀처럼 일할 수 있었다.

4. 결론
애자일 프랙티스는 SI 개발 환경에서 오랜 논의 끝에 나온 경험의 산물이다. 연구소나 학계에서 나온 것이 아니란 점에서 ‘새로운 방법론의 하나’로 취급하는 것은 실용적이지 않다. 오히려 현재 사용하는 혹은 익숙한 방법론이나 개발 프로세스를 사용하면서도 단계적으로 애자일 프렉티스를 충분히 적용할 수 있다. 본 글에서는 이에 대한 하나의 사례를 제공함으로 해서 현장에 응용하기 위한 논의의 단초를 제공하는데 의의를 지닌다.