앞선 몇 번의 프로젝트에서 애자일 방식으로 일한 뒤,  필자는 스스로를 책에서 본 스크럼 마스터라는 명칭으로 부르기 시작했다. 스크럼 마스터는 팀에 스크럼 프로세스를 지키도록 도우면서, 팀 내/외부 병목을 해결하는 역할이다. 문제는 그러면서 스스로를 애자일 전문가라고 얘기했던 것인데, 열정이 지나쳤던 것일까...? 당시 필자는 모든 프로젝트를 애자일로 할 수 있다고 믿었다. 3개의 성공케이스를 만든 후 자신감이 컸다.

앞서 필자가 했던 다양한 시도들은 여러 형태로 본사에 보고되었다. 그리고 다양한 SI 프로젝트에 애자일이라는 것이 조금씩 알려지게 된다. 그러면서, 이곳저곳에서 애자일을 적용해보겠다는 프로젝트 관리자들에게 연락을 받게 되었는데, 가장 먼저 연락 온 곳은 어떤 유지보수 팀이었다.

혹시나 본인이 처한 상황이 모두가 워터폴 프로세스를 쓰고 있는데, 본인은 애자일의 무언가를 시도하고 싶은 분들이 있는가? 주변 환경을 바꿀 수 있는 여건은 안되지만 지금 있는 환경에서 프로세스적인 애자일을 시도하고 싶은 분들을 위해 필자의 경험을 공유드리고 싶다.

결론적으로 말하면 이 프로젝트는 크게 성공했다. 제 때에 프로젝트가 잘 수행되었고 고객은 만족했으며 프로젝트 종료 후, 성과를 인정받아 심지어 고객과 프로젝트 관리자가 동시에 승진하는 일까지 겹쳤다. 이후 프로젝트 성공 사례로 애자일이라는 이야기가 사내에 퍼져나가기 시작했다.

필자는 운이 좋았다. 훌륭한 애자일 코치와 더불어 당시 스크럼을 제대로 경험해 볼 기회가 있었다. 그리고 그때를 시작으로 이후 수행하는 프로젝트마다 일하는 방법을 조금씩 개선해 나갔다. 있었던 일을 가능하면 상세하게 기록으로 남기고 개선하면 좋겠다는 생각에, 일기 형태의 문서를 쓰기 시작했다. 업무가 끝나면 매일 글을 쓰면서, 혼자서 하는 회고를 진행했다.

이번 장은 필자가 작은 팀을 이루어 애자일 프로세스를 적용한 내용을 다루었다. 이를 통해 독자들은 여러분이 속한 팀에서 팀원들과 가장 쉽게 적용할 수 있는 애자일 프로세스인 스크럼에 대해 알아보고, 이를 기반으로 프로젝트의 특성에 따라 달리 접근한 여러 경험들을 확인할 수 있다.

엔지니어링 기법들을 하나씩 경험을 통해 체득하게 될 즈음, 필자는 애자일에 대해 본격적으로 공부하기 시작했다. 당시 애자일이라는 용어와 함께 새로운 프로세스들이 하나 둘 대한민국의 소프트웨어 업계에 들어오기 시작했는데, XP(Extreme programming)와 스크럼이라는 프로세스가 대표적이었다. 스크럼은 한 달의 짧은 개발 주기를 반복적으로 활용하며 팀이 수행해야 할 역할과 책임을 정의한 프로세스다.

로그인 소스에 문제가 발생했다고 말했다. 고객은 처음에는 불같이 화를 냈다. 하지만, 복구 시간이 지연되면서, 고객의 얼굴이 점점 새 하얗게 질리기 시작했다. 또 다른 30분이 지나고, 그 고객은 나에게 어떻게든 이 상황을 제발 해결해달라고 간청하기에 이르렀다. 곧 누군가 징계를 받을 수 있는 상황까지 가고 있었다.

“피엠님, 이 책 한번 읽어보실래요? 미국에는 XP란게 있데요. 근데 이 내용 중에 재미있는 것들이 있어요. 예를 들면, 페어 프로그래밍이라고, 둘이서 한 키보드를 두고 같이 개발을 한데요. 피엠님이 들으면 기가 막힐 이야기죠. (웃음)”

이 책의 첫 번째 챕터에서는 필자가 과거 애자일을 처음으로 시작했던 이유와 경험에 대해 적었다. SW를 만드는 바쁜 개발 현장에서 새롭게 무언가를 시도하려는 독자가 있다면 이 이야기를 듣고 용기를 얻기 바란다. 이 챕터는 여러분의 시도가 얼마나 가치 있는지를 이야기하기 위해 쓴 글이다.