내가 박재성씨를 도와 KSUG/자바지기 공동 주체 세미나를 진행한 이유는 언젠가는 'SI 프로젝트에서도 애자일 프로세스를 적용할 수 있는 방안'을 논의하고 싶어서였다. 나는 소규모 팀 프로젝트이지만, SI 프로젝트를 수주해서 애자일 프로세스로 프로젝트를 진행 중이다. 6개월 프로젝트에서 13주차를 진행했고, 얼마전에 이미 1차 릴리즈를 해서 결과물을 고객과 공유했고, 7월 중순에 2차 릴리즈를 할 예정이다. 하지만, 우리가 만든 결과물을 고객들이 수시에 사용해보고 피드백을 주기 때문에 내부적인 릴리즈가 별도로 있다. 편의상 우리는 이를 리비전 배포라고 부른다. (아래 그림 참조)

이러한 진행을 하면서 나는 몇 가지 노하우를 익힐 수 있었다. 전형적인 애자일 프로세스는 당장은 그리 유용하지 않다는 점이다. 최초에 우리는 2주마다 스프린트를 계획하고, 회고를 하고 백로그를 사용하는 유형으로 진행했다. 최초 릴리즈를 하고 국면 전화이 있으면서 우리는 이러한 프로세스를 변경했다. 다음 릴리즈까지의 7, 8주 기간을 하나의 사이클로 계획했다. 여기서 우리는 애자일 프로세스를 현장에 맞게 적용할 수 있는 인력이 필요함을 알 수 있었다. 공교롭게 번역을 하게 된 글에, Iteration Manager 라는 이름으로 그런 영향을 잘 정리되어 있다. SI 프로젝트에서도 애자일 프로세스를 적용한다면 상황파악과 대인기술이 뛰어난 동시에 기술적인 이해도 충분한 전문가가 필요하다. 그를 Iteration Manager라고 하든, 애자일 코치라고 하든.. 뭐라고 부르든.. 여튼 프로젝트 규모에 따라 기존 관리자와는 성격이 다른 일선 개발자와 함께 하면서 관리층에 개발자의 언어를 관리자의 언어로 전달할 수 있는 사람이 반드시 필요하다.

두번째는 도구는 프로세스에 비하면 참 사소한 문제고, 프로세스 역시 사람을 움직이지 못하면 말장난이 된다는 단순 명제를 실천해내는 것이다. 박재성씨가 SI 프로젝트에서도 애자일 프로세스는 가능한가? 에서 계약 문제를 아주 크게 다뤘지만, 내 생각은 좀 다르다. 본질적으로 계약과 개발 프로세스는 완전하게 연결되어 있는 것은 아니다. 나도 2년 전에 비슷한 취지의 글을 쓴 일이 있다. 조직의 구매, 인력 조정, 조달 등의 프로세스는 유연하지 못하기 때문에 계약 때, 이를 고려하는 것은 매우 중요하다. 그러나, 계약이 잘못되었다고 애자일 하지 못할 이유는 없다. 방법론자의 입장에서 정의하는 '애자일 프로세스'가 있겠지만, 실무자 입장에서야 '애자일'이라고 부르는 행위의 내용이 중요하니까. 내가 최초에 Continuous Integration을 적용하려 할 때는, 좋은 툴과 이를 활용하는 프로세스 자체에만 관심을 가졌다. 그러나, 막상 적용해보면 그것 자체는 그리 어려운 일이 아니었다. 정말 핵심은 팀원들이 내가 하는 일과 유관한 작업을 하는 누군가에 대한 배려를 하면서 지속적으로 통합하는 과정이었다. 툴, 프로세스보다는 팀이 Continous Integration 하는 것이 훨씬 중요하다는 산 경험을 얻었다.

아직 정리되지 않은 생각을 피력하게 된 계기는 재성씨의 글에서 볼 수 있는 열정과 희망에 대한 응원이다. 지금 SI 현장에서 애자일 프로세스 자체가 아니라, 거기서 얻을 수 있는 가치를 실천하려고 노력하는 사람들이 있다는 사실을 말해주고 싶었다.