애자일(Agile)과 SI 프로젝트, 해결해야 하는 질문들, 잊어서는 안되는 원칙들

요즘 애자일(Agile)이 확실히 트랜드는 트랜드입니다.

여기 저기서 애자일을 어떻게 도입할지 고민하고 있는 모습이 보입니다.

원래 Agile 은 그 근원이 생산(Production)에서 기원하는 관계로 보다 빨리 출시하고, 보다 쉽게 변화에 적응하는 것을 그 바탕으로 합니다. 따라서 효율을 높이기 위해 우선순위에서 밀리는 요소는 뒤로 제치고, 중요한 것에 집중하는 형태를 취하게 됩니다.

어째서 Agile이 대두 되었을까요?

여러가지 이유야 많습니다만, 우선 Agile의 태생을 이해하는 것이 Agile을 적용을 하는데에 있어 이해득실을 따져보시기 좋을 것 같습니다.

90년대 중 후반, 소위 말하는 닷 컴 버블 시절, 너도 나도 인터넷을 이용한 서비스를 만들어 내기 시작한 시절이 있었습니다. 그 시절에는 누가 먼저 서비스를 내 놓느냐, 그리고 내 놓은 서비스를 고객 변화에 맞게 얼마나 잘 맞춰가며 변화하느냐가 생명이었습니다.

그런데, 대부분의 회사들이 기획한 대로 일정내에 출시 하는 것이 만만치 않다는 걸, 그리고 출시 하더라도 재빠른 버그수정이나 요구사항 적용같은 작업이 굉장히 어렵다는 걸 알게 됩니다. '최초 출시 업체보다 3개월 늦게 출시하면, 그 쪽 분야는 이미 그 업체에게 뺏긴거다' 라는 게 일반적인 인식이었습니다. 그래서 많이들 실패하게 됩니다. 출시는 늦춰지고, 나온 제품은 시원찮고, 경쟁은 심하고... 등등등.. ('세상을 바꾼 32개의 통찰'이란 책을 읽어보시면 다양한 이야기가 있습니다)

그런 상황이다 보니 무언가 대안을 찾게 되고, 그 와중에 Agile 이 떠오르게 됩니다.

'빠른 시간내에 고객에게 최대의 가치를 전달' 이란 모토와 맞는거죠. 그리고, 우수한 인재가 있는 팀들도 실패하는 와중에 성공 케이스들이 나오고 있었으니까요.

Lean 방식, Toyota 방식, Scrum 등등 생산성과 품질, 속도를 이야기 하는 방법들이 조명 받게 되었습니다.

2000년대 초반 XP도 한 열기 했는데, XP는 가치와 실천방법(Practice) 중심이다 보니, 전통적인 기존 기업들이 받아들이기에는 XP 가치 그대로의 '용기'가 필요했고, 쉽게 적용하기 어려운 점이 있었습니다. 결국 근래에는 XP 보다 Scrum 이 더 많이 적용되는 추세입니다.

<VersionOne's Research from infoQ.com>

우리나라는 번지는 분위기가 다소 늦었습니다만, 어쨌든 근래에 들어 관심들이 비상합니다.

음... 제가 여기서 주저리주저리 애자일 이야기를 계속하는 건 주제 넘는 짓이고, 요즘들어 그 열기가 번져서 SI 까지 오고 있는데, SI 프로젝트에 Agile 을 적용하기 위해서는 어떠한 문제점을 고려해야 하는지 몇 가지만 적어보겠습니다.

1. 방법론과 관계없이 모든 요구사항을 관철시키려고 하는 고객을 어떻게 설득할 것인가?
   - 이터레이션 마다 결과물을 보여주니, 고객의 feedback 이 강력할 수 있습니다
2. 팀 맴버 구성 비율을 어떻게 가져갈 것인지?
   - 기존의 role base의 인원구성으로 whole team 이 가능할 것인지 고민하셔야 합니다.
3. 기존 방법론에 충분히 익숙한 프로젝트 리더 들의 사고 전환을 어떻게 할 것인가?
   - 대시보드와 ToDo 정도로는 불안해 할 수 있습니다.
4. 앉아서 '아~ '하고 입만 벌리던 고객을 어떻게 참여시킬 것인가?
   - SI 기업에는 업무 전문가들이 고객보다 업무를 잘 알아서 고객은 자신이 하는 업무를 몰라도 알아서 구축해 주는 수준입니다.
   - 고객은 자신을 괴롭히는걸 좋아하지 않습니다.
5. 타협하고 싶어진다. (자동화된 Test는 어려우니까 빼고…etc)
6. Agile 에 대한 개발자들의 오해와 마음가짐
   - Agile 하면 산출물 안 만드는 거 아냐? 라고 생각하는 사람들이 적지 않습니다.
   - 만들어야 한다고 하면 급 실망해하며 결국 비슷하잖아... 라고 돌아서기 쉽습니다.
7. 기법 활용 미숙 (User story ? Story point?, 스크럼 미팅? CI?)
   - 책 읽고, 교육 한번 받고 진행하면 헤메기 딱 좋습니다. 기존 방법론의 갑갑하지만, 타이트한 틀이 없기 때문입니다.
8. 외부 감리는 어떻게 설득할 것인가?
   - 외부 감리가 당황해 할 수 있습니다.
9. SI에는 분석 설계가 끝난 다음에 개발자가 투입되는 경우가 많습니다. 하지만, 이는 대부분의 Agile 방법에 상치됩니다.
10. 초급 개발자들이 많은 프로젝트는 어떻게 해야 하나요? 문제를 일으키는 개발자가 있을 경우에는요? 그리고, 인원교체가 쉽지 않은 경우에는요?
    개발자 5명 정도의 소규모 팀이라면 1명의 포션이 20%입니다. %가 큽니다.
11. 혹시, 사내에서 필수로 사용해야 하는 프로젝트 프로세스나 시스템(진척도,공정관리 등등)들은 어떻게 할까요? 예외로 할까요?
12. '전체비용절감'을 생각하는 Agile에서 봤을 때, 배포전까지의 비용이 오히려 예전보다 높을 수 있습니다. 구축만 하고 빠지는 프로젝트의 경우 그걸 감당하려는 PM이나 팀을 만들 수 있을까요?

제가 질문만 하고 끝내는 것 같아 마음이 좋진 않습니다만, 혹, 다른 분들의 의견 피드백이라던가, 논의하고 싶어하시는 분이 계시다면 나름의 고민과 생각, 회사내에서의 고민과 해결노력에 대해서 일주일 즈음 후에 정리해 올려보겠습니다. (이번주에는 육체적으로 힘든 노동의 한 주가 기다리고 있습니다... 의사가 쉬랬는데 걱정입니다.)

Agile을 황금 화살, 은탄환처럼 보는 사람들도 적지 않습니다. 사실 저도 Agile을 이상으로 보고, 비록 닿지 못하더라도 이카루스처럼 날아오르고 싶어하는 사람중 한 명입니다.

<Ideal 함으로 가슴 뭉클하게 해주는 dtsagile.com 의 Agile 소개 동영상. 안보이시면 URL 클릭>

다만, 한가지 안타까운 사실은, Agile 열기에 취해 우리가 원하는 것이 프로젝트의 성공인건지? 아니면 Agile 적용인건지 조차 헷갈려 하는 경우가 생긴다는 겁니다.

실제로 XP의 창시자 중 한명이며 Agile Manifesto 선언자 중 한 명인 론 제프리(Ron Jeffries)조차도 그의 블로그의 Agile: Is, Is Not, May Be 이란 글에서 Agile 이 어디에나 다 맞고 늘 성공하는 건 아니다 라고 이야기 합니다.

노력이 많이 필요한 것 같습니다. 지식도 필요하고, 경험도 필요합니다만, 경험이 약하면 지식을 비롯하여 준비가 많이 필요한 것 같습니다.

Agile 신봉에 적용을 하고 싶어 안달이 된 사람들 조차도 Agile Manifesto 중 첫 장 네 줄만 읽고 그 뒤는 읽어보지도 않은 사람들이 수두룩합니다.

<문제의 네 줄. 전문(全文)은 Skip 하기 쉽상>

Scrum 은 가장 유행하는 방법론입니다. (저는 사실 방법론이라는 말 자체가 Agile 에 맞나 싶기도 합니다만 어쨌든.)

가장 많이 사용되고 있으며, 앞으로도 당분간 새로 시작하는 그룹은 Scrum 을 선택할 가능성이 높습니다. 하지만, Scrum은 근래에 프로젝트에서 가장 많이 실패하는 개발방법으로 꼽히고 있기도 합니다. 전체 시도 횟수가 많아지다 보니 성공사례가 많이 발표되고 있지만, 그 만큼이나 많이들 실패하고 있는 겁니다. 이에 대해서는 마틴 파울러(Martin Fowler)의 최근 글 FlaccidScrum 에서도 잘 이야기 되고 있습니다. '내실없는 적용은 실패를 부른다.'

우리는 사실 목표가 한 가지 입니다. 그걸 잘 해보려고 이것 저것 사용할 수 있는 방법, 용다하는 의원에, 좋다는 약들을 쓰려고 하는 거 아니겠습니까?

하지만, 언제가 되었든, 어떤 상황이 되었든

성숙한 팀을 만들어 프로젝트를 성공시키는 것, 그리고 참여한 사람이 모두 그 안에서 좀 더 행복해 지는 것, 바로 그 선(善) 지향의 목적을 잊어서는 안되겠습니다.