애자일을 추진하면서 겪었던 실재 사례를 지난번에 연재로 포스팅 하였다.
약간의 힌트로 애자일을 어떻게 추진해야 하는지에 대해 한마디로 회고 또는 성과평가회의를 하라고 주문하였다.
이것은 사실상 계획을 수립하고 추진하며 중간에 한번쯤 멈추어 서서 계획이 잘 추진되고 있는지 점검하고 필요하다면 마누라와 아기 빼고 다 바꾸라는 명사의 이야기와 상통하는 이야기였다.

결국 애자일이 됐던 뭐가 됐던 계획을 수립하고 추진하고 점검하고 변경하는 일처리 4단계를 하라는 것이다.
과연 이것은 무엇을 의미하는 것일까?
정보공학방법론과 무엇이 다를까?

정보공학방법론은 계획은 마스터 플래 즉, WBS(간트 챠트)하나로 모든 것을 해결하려 든다.
주변의 수많은 PM들은 계획 변경 그 자체를 리스크로 바라본다.
계획 변경에 따르는 책임과 합의 도출 과정 그 자체가 무서운 것이다.
따라서, 정보공학 방법론에서는 계획수립, 추진, 점검의 3단계의 구조를 가지고 있을수 밖에 없다.

과연 옳은 일처리 방법일까?
정보공학 방법론의 추종자들이 근원에 가정하고 있는 것은 "한 번 도출된 요구사항은 결코 변하지 않는다"이다.
또한 "필요한 것과 원하는 것"을 햇갈려 하고 "고객과 사용자"를 햇갈려 한다.

먼저 과연 변하지 않는 요구사항이 있는지를 묻고 싶다.
물론 요구사항이 변하지 않다는 것은 사실이다.
과업범위라는 것이 정해지면 그 과업범위 내에서 프로젝트가 진행되는 것이 맞다.
계약은 그러라고 있는 것이고 과업범위가 정해져야 무슨 계획을 하고 견적을 내고 인적 자산과 시간을 투입할 수 있는 것이다.
그러나 그 요구사항을 글로 적어서 기록하는 사람의 컨디션에 따라 그 요구사항을 제대로 전달 받지 못하는 커뮤니케이션의 한계가 있다는 것을 변수로 하면 또 다른 이야기가 된다.

고객은 처음부터 "A"라는 것을 원했는데 그 요구사항을 분석하는 사람이 기호로 받아 적으면서 자의적인 해석이 들어가고 결국 "a"라고 받아 적게된다. 이후 그것을 설계하는 설계자는 "a`"라고 적게되고 그것을 구현하는 개발자는 "a!"로 개발하게 된다.

이것이 사실이 맞냐 아니냐는 간단한 게임을 통해서도 체험할 수 있다.

5명에서 6명의 팀원이 각자 PM, 설계자, PL, 개발자, 테스터의 역할을 받고 PM에게 어떤 그림을 보여주고 구두로 순서대로 전달하라고 하면 마지막 테스터는 PM이 전달한 내용을 왜곡해서 이야기 하게 되어 있다.
아니라면 PM이 표현하는 이야기를 나머지 인원들이 받아 적게 하도록 하면 무조건 모든 기록물들은 형태나 뉘앙스가 달라지게 되어 있다.

결국 "a!"를 개발해놓고 고객이 "A"로 바뀌달라고 하면 요구사항 변경이 일어났다고 불만을 표출하게 되는 것이다.

기호는 그림보다 더 요약된 정보를 가지고 있고 그림은 영상에 비해 더욱 요약된 정보를 가지고 있기때문에 기호로 모든 것을 해석하거나 그것을 기반해서 무엇인가를 만들어 냈을때는 요구사항을 도출한 사람의 생각과 기호와의 GAP으로 인해 문제가 발생할 수 밖에 없는 것이다.

이번에는 "필요한 것과 원하는 것"을 논해보자.
원하는 것은 고객이 그야 말로 원하는 것이다. 다시말해 고객이 진정으로 원하는 것을 줄수 있다면 프로젝트에서 발생하는 대부분의 문제를 해결 할 수 있다.
그런데 필요한 것은 무엇일까?
이 녀석의 정체는 개발팀이 여러가지 정황을 자의적으로 판단하여 이런것이 필요하거나 필요없다라고 결정한뒤에 고객을 Lead해버리는 것이다.
이런 경우 고객이 원한 것이 아닐 수 있다.
가령 예를 들어 아프리카 어느지역 사막 국가에 사람들이 산다고 가정하고 이들을 방문한 자원봉사단이 있다고 생각해보자.
한낮의 기온이 40도에 육박하고 밤에는 0도에 가까워지는 기후특성상 밤에 방문한 자원봉사 요원은 이들이 코트가 필요할 것이라고 생각하고 봉사 본부에 겨울 코트를 대량 지원해줄것을 요청하였다고 가정하자.
과연 그 나라 사람들이 원한 것이 겨울 코트였을까?
그들이 원한 것은 겨울 코트가 아니라 단지 물이었을 수 있을 것이다.
결과론적으로 풍부한 물을 제공했더라면 자원봉사의 의미가 더 많이 부여 될 수 있었을 텐데 비교적 따뜻한 천막에서 추위를 피할 수 있으며 밤에는 그곳을 나갈 생각이 없는 그들에게 겨울 코트가 무슨 삶의 의미가 있을 수 있을까?

그리고 마지막으로 고객과 사용자를 이야기해보자.
고객은 그야말로 우리 개발팀에게 돈을 지불하는 사람들이다.
사용자는 우리가 만든 프로그램을 사용하는 사람들이다.
이들은 서로 생각이 다를 수 있다.
여기서 문제가 발생한다. 고객에 전적으로 의지하여 고객을 만족시키기 위해 노력하였을 경우 정치적, 경제적 성공은 답보할 수 있을 지 모른다.
그러나 실재 사용하고 있는 사용자는 돈을 지불하는 플러스 행동을 하지 못하더라도 만든것을 사용하지 않거나 더 나아가 불매 운동에 참여할 수 있는 마이너스 행동을 주도할 수 있다.

종합 정리하자면 이러하다.
먼저 고객과 사용자 모두를 만족시켜야 한다.
둘다 개발팀에 포함시켜서 사용자의 경험을 고객에게 납득시키는 활동을 해야 하는 것이다.
그리고 나서 고객과 사용자가 원하는 것을 정확히 파악하여 충족시켜야 한다.
그렇다면 프로젝트는 결과론적으로 성공할 수 있다.

따라서, 마스터 플랜이 수립되고 나면 단계별 계획 변경을 위해 우리가 잘하고 있는지 제 3자의 입장에서 객관적으로 검토해서 계획을 변경할 필요가 있는것이다.

즉, 검증된 이터레이션 개발로 사용자의 접점에 있는 UI 즉, 바운더리 Class를 먼저 개발해야 할 필요성이 제기되는 것이다.
이러한 활동에 적합한 것이 바로 Mockup Tool들이다.
Balsamiq 또는 Pencil 로 대표되는 Mockup 툴들은 적은 비용으로 요구사항을 더 치밀하게 검증할 수 있도록 도와준다.
* 파이어폭스 플러그인으로 사용가능한 Pencil 은 여기로~

그리고 프로젝트 팀원들이 정확하게 자신의 목표를 인지 하는지 확인하기 위해 본 프로젝트 이전에 프로젝트 수행 Prototyping 단계를 한번쯤 수행하는 것도 좋은 방법이다.

각자의 역할과 이터레이션을 통해 어떻게 해야 할지에 대한 목표와 규칙을 공유할 수 있는 좋은 기회이기도 하다.

이렇게 계획 변경의 필요성에 대해 논했음에도 잘 실감이 나지 않는다면 역사적으로 계획을 변경하지 않거나 변경해서 망해버린 사례를 한번쯤 떠올려 보자.

사례1. 임진왜란 일본군
토요토미 히데요시의 일본군은 작전계획에 따라 부산을 점령한후 곧장 수도 한양을 점령하고 당시의 제2도시인 평양으로 달려가서 눌러 앉아 버린다.
그 사이에 명나라 지원군이 달려오고 이후로는 경상도 지역에 쳐박혀 있다가 정유재란을 통해 다시 공세로 돌아섰지만 결국 패전하고 일본으로 철수하였다.
여기서 문제는 바로 일본의 계획에서 "한방 쎄게 치면 그쪽에서 알아서 기겠지"라는 가정에서 출발한 계획을 변경하지 않았다는 것이다.
총 7년의 전쟁기간동안 5년동안이나 초기 계획을 전혀 변경하지 못했다.
최초에 한양을 점령하고 선조가 도망간 그 시점에서 계획을 변경하여 추격전을 펼쳤어야 했음에도 추격전은 커녕 "어랏? 항복을 안해? 그럼 평양을 먹으면 항복할거야"로 현 정세에 안주하는 동안 그 가느다란 육상 보급로는 게릴라 활동으로 잦은 폐쇄와 재개통을 격게되고 믿었던 서해 해상 보급로는 이순신장군에게 막히게 되었다.
만약 일본군이 조선이 정신을 못차리는 사이에 계획을 변경하고 추격전을 펼쳤다면 역사는 아마도 바뀌게 되었을 것이다.

사례2. 김일성의 북한군
김일성이 1950년 6월 25일 구소련 군사자문단의 남침계획에 따라 병력을 분산하여 중부전선, 동부전선으로 내려온 것까지는 좋았다.
파죽지세로 서울을 꿀꺽하는것 까지는 성공했지만 문제는 동부전선에서 대한민국 칠성부대의 105mm 포 몇문에 진격이 막히자 작전 계획을 변경하고 우회했어야 했지만 이도 저도 못하는 사이에 시간이 흘러 맥아더가 한강 방어선 이남에서 전선을 시찰하고 참전을 결심하도록 만들어버렸다. 이를 우리는 북한의 서울에서의 3일간 미스터리라고 한다.
그때 만약 계획을 변경하였거나 Plan B를 실행하였다면 즉시 서울에서 주저앉을 것이 아니라 한강이남으로 도하하여 추격전을 펼쳤어야 했다. 그러나, 그들은 그렇게 하지 않았다.

사례3. 2차대전때의 독일군
6군은 스탈린 그라드로 진격하여 점령하는것 처럼 보였다. 그러나 강력한 저항에 부딪히고 오히려 역공을 받아 포위의 위기에 몰렸다. 즉시 코카스로 진격중이던 병력의 후위를 맡은 6군을 지연전을 펼치면서 빼내야 했지만 계획을 변경하지 않은 고집으로 인해 6군은 전멸당하고 만다.

우리는 이외에도 수많은 사례를 통해 계획 변경을 하지 않아 좌절한 수많은 조직을 보았다.
그리고 알고 있다. 단지 그것이 계획변경을 하지 않아 일어난 사건인지 모를 뿐이다.

결론적으로 애자일을 왜 이터레이션으로 해야 하는가? 또는 애자일은 왜 회고라는 프로세스를 가지고 있는가?에 대한 역사적 해답을 위의 몇가지 사례를 통해 알 수 있는 부분이다.

일을 추진함에 있어 잠깐이라도 객관적으로 일이 잘 진행되고 있는지 검토하고 일이 잘 진행되고 있다면 응당 계획을 계속 유지하고 계획 추진이 제대로 되고 있지 않다고 판단될때는 즉시 계획을 변경하여야 한다.
이렇게 함으로써 계획 자체로 인한 파국을 막을 수 있을 뿐 아니라 손실을 최소화 시킬 수 있는 것이다.

이시점에서 "회고"과정이 매우 잘 정착되어 있는 바둑의 "복기"라는 과정을 살펴 볼 필요가 있다.
다음은 경향신문의 김태관 논설위원께서 2009.05.25 작성하신 "인생 복기"라는 논설의 일부를 발췌하였다.

=전략=
복기(復棋)는 너의 눈으로 나를 돌아보는 일이다.
대국이 끝난 뒤 그때 그 장면에서 내가 둔 수가 상대의 눈에 어떻게 비쳤는지 돌아보면 비로소 실수가 눈에 보인다.
완착과 패착, 헛수와 자충수도 그제서야 선명해진다.
인생도 마찬가지다. 지나고 나서 돌아봐야 허물이 눈에 들어온다.
남의 눈에 내가 어떻게 비쳤는지 비로소 깨닫게 된다.
=후략=

*  2007 엠게임 마스터스 中 이민진 6단과 백홍석 6단의 복기장면

우리 개발팀도 이러한 복기, 회고, 성과평가회의라는 것을 프로세스 중간 중간에 고객과 함께 해보는 것.
그것이 바로 애자일의 추진이며 복기만으로 끝나서는 안되는 것이다.
복기가 완료되면 개선점을 찾아 개선 담당자를 지정하여 권한을 위임하고 위임된 권한하에 팀원 스스로 개선활동을 할 수 있도록 프로젝트 매니저와 고객은 지원해야 한다.

이것이 애자일이다.


* 담부터는 뭐를 쓰면 좋을까요? (쓸게 없어진듯...OTL)

프로토 타잎을 만드는 것이 그리 간단한 작업은 아닐것이다.
그러나 우리는 고객이 원하고 만들려고 하는 시스템이 무엇인지 알고 있었고  고객도 스스로 우리가 무엇을 할 수 있는지 알고 있었다.
따라서 우리는 아이템의 변경보다는 기존 시스템을 확장한 모델을 프로토타잎으로 만들었다.
지금은 다른회사에서 다른 일을 하고 있는 예전의 후배회사를 찾아가 다짜고짜 이번 사업이 이러하며 현재 하드웨어 구축중으로 내가 필요한것은 모션 인식을 바탕으로 운동량을 측정하는 게임이라고 설명하고 간단하게 만들어 달라고 부탁했다.
그러면 어떻게든 사업을 따와서 같이하자고 꼬신것이다.
이후에 토요일, 일요일에는 전모 사원과 함께 제안서 작업을 하고 위에는 제안서 작업이 마무리된때에 보고하였다.
그걸 왜하느냐? 부터 온갖 반응이 나왔지만 해야 한다고 우기고는 설득하기에 이르러 결국 설득이 완료되었을때 파트장이신 부장님을 내편으로 만들 수 있었다.
이때 연구소에서 헬스케어만 전문 연구하신 모 연구원의 도움이 매우 컸다.
이후 프로젝트 제안을 듣기위해 오신 미국 현지 법인 담당자 3분과의 미팅을 통해 짧게 나마 우리가 생각하는 비즈니스 모델을 설명하고 이렇게 만든다면 수익발생을 기대할 수 있다고 설득하였다.

문제는 우리회사의 인지도 였다. 한국 본사의 자회사와 같이 일하길 원했던 그들은 첫날 우리의 이야기를 들어 줬고.. (물론 숙소에 가서 아침에 납치해오다시피 하기도 했지만...)
2일째 오전에는 그 회사로 가서 설명을 들으신뒤에 다시 우리회사로 오셨다.
3분의 담당자중 1분은 이전의 프로토타잎 개발 PM으로써 우리의 역량을 알고 계신분이었고
나머지 2분중에 1분은 당시의 팀장님과 친구사이였던 덕에 다수결에 따라 우리가 사업을 획득하게 된다.

문제는 다음이다.
프로젝트의 규모가 지나치게 당시의 직급에 비해 커서 상급자가 PM으로 오게 되면서 방법론으로 수많은 언쟁과 설득이 오고가게 되었지만 결정적으로 BP사의 담당직원이 PMO의 승인없이 당사의 또 다른 BP사의 직원을 무단으로 휴가를 보내고 그것에 문제제기한 본인만 배제된체 프로젝트는 시작되었다.

이때가 시련의 시작이었던 것같다.
지나친 애자일 사랑(숭배)은 주변인에게 압박으로 다가가고 결국 그것이 나에게 독이 되었던 것이다.
그리고 결정적인 사건은 그에게 명분을 주는 역할 밖에는 되지 못했다.

이후에 현재 프로젝트의 프로토타잎 프로젝트에서 필요한 하드웨어를 납품하러 들어갔다가 그곳에서 어떤 일을 하는지 알고는 2007년 특허 등록을 위해 작성하였던 증강현실 프로토타잎을 꺼내들고는 급히 담당매니저를 다시 만나 설득하였다.

"단순히 하드웨어만 납품하는 것은 저를 낭비하는 것이니 옆에서 참관만이라도 할 수 있도록 해당 업체 룸에서 작업할 수 있도록 도와달라"는 내용이었다.
또한 "하드웨어만 하지 않고 궃은일도 맡겠다."는 개인적인 일욕심이 앞섰다.

담당 매니저님께서는 장시 고민하시고는 프로젝트의 참관과 일정 부분 맡아 달라는 말씀을 하셨고 프로젝트를 선듯 주셨다. (지금도 매우 고맙게 생각합니다.)

맡은 일은 간단했다.
증강현실에 사용될 테스트 장비의 선정과 카메라를 설치할 수 있는 크래들 만들기였다.

여기서도 애자일의 사상으로 접근하였다.

먼저 장비를 선정하는데 있어 주어진 요구사항은 "Nvidia 9800급 고사양 하드웨어이면서 작은것"으로 몇가지 타잎이 검토되었는데 문제는 크기를 웹에서 본다고 해서 그것을 가늠하고 결정하기 어렵다는 것이다.
실재 물건을 사올 수 있으면 좋으련만 한정된 예산으로는 무리였다.

그래서 생각한 것이 3면의 사진을 출력하여 제원표에 있는 그대로 "종이접기"한 것이다.
종이 접기한 본체의 크기를 보시자 금새 결정되었고 요구사항의 모호함은 사라졌다.
이어서 크래들이 문제였고 크래들은 기계공학과 출신 회사 선배들을 찾아가서 이리 저리 노하우를 습득하고 청계천과 종로 일대를 뒤지고 모형 사이트에서 얻은 Mockup 기술을 익혀나가 결국 3종류의 크래들을 완성하였다.

크래들을 먼저 보여드리고 각각 세세한 부분은 바로 그자리에서 드라이버와 벤치로 고쳐버리면서 그렇게 몇개월의 프로젝트를 고객의 만족을 받으면서 마쳤다.

이후 정식 프로젝트가 현재 추진하고 있는 프로젝트로 여러가지 시행착오는 있었지만 애자일하게 프로젝트를 수행하고 있기는 하다.

이제 정리 한번 해보자.

첫째, 애자일은 무엇인가에 대한 답이다.

애자일 선언에서는 다음과 같이 이야기한다.
프로세스나 도구에 앞서 개인과 상호 협력을
종합적인 문서화에 앞서 작동하는 소프트웨어를
계약 협상에 앞서 고객과의 협력을
계획 준수에 앞서 변화에 대한 대응을
우리는 왼쪽 항목의 가치를 인정하면서도 오른쪽 항목을 더 중요하게 여긴다.

즉, 이터레이션만 두고 변화에 맞춰 계획을 변경하는 것이나 애자일 프래틱스를 잘 준수하는 것이나 CI툴을 통해 리팩토링하는 것이나 자동화된 문서 체계를 갖는 것이나 자동화된 테스트 체계를 갖는다고 해서 애자일이 아니다.
애자일은 상호간의 협력과 작동하는 제품, 변화에 따른 능동적인 계획변경과 실행인것이다.
다시말해 애자일은 "가치"와 "철학"이지 "정형화된 방법론"이 아니다.
지금까지 내가 걸어온 길이 애자일하다라고 할 수 있는 이유도 바로 상기 선언에 비추어 한점 부끄럼 없기 때문이다.
다시말해 지금 다른 사람들이 특히, 이글을 보는 분들중에서 자신의 팀이 애자일하지 않다고 할 수 있는 팀은 몇개나 될까?

둘째, 애자일을 어떻게 추진해야 하는가?에 대한 답이다.
애자일을 추진하기위해서 수많은 프래틱스를 수행하고 계획만 변경하면 될까?
흔히 대기업의 QA수준의 하향식 또는 상향식 애자일 수행은 내가 2009년 프로젝트에서 겪은 바와 같이 필연적으로 실패의 길로 갈 확률이 굉장히 높아진다.
애자일을 수행하기 앞서 나는 가장 먼저 해야 할 일이 바로
"사람에 대한 이해와 사람의 다름을 인정하고 사람을 존중해야 한다"고 생각한다.
그리고 매단계별 "회고"를 도입하기 바란다.

사람에 대한 이해와 사람의 다름을 인정하고 사람을 존중한다면 "개인과 고객과의 상호협력"을 이끌어 낼 수 있다.
스스로 변화되는 것이다.
또한 "진심으로 다가간다면 언젠가는 그 진심은 반드시 보답한다."는 사실을 믿어 주기 바란다.
이건 내 경험이자 내 주변인들의 경험이기도 하다.
현재 모 식품사의 영업팀 과장으로 10년이상을 수많은 고객을 만나는 동기의 이야기도 그러했다.
"처음에는 내가 진심으로 다가가도 고객은 달콤한 말을 하는 사람을 더 좋아했다. 그러나, 시간이 흐르자 결국 찾은 것은 나였다."
그 동기의 이야기는 거짓이 아니다.
실재로 수많은 사람들은 수많은 유형을 가지고 있고 대표적인 유형을 몇개 꼽자면 "정치형", "계산기형", "보스형" 등의 사람들이 있지만 결국 진정성은 모든 유형의 사람을 관통하는 힘이 있다.
단지 시간이 문제일 뿐이다.

따라서, 우리 애자일을 추진하는 사람들은 "사람을 대하는 Mind"를 먼저 가지고 주변인을 설득하는데 설득하려 들지 말라.

그저 하나의 일이 끝나고 나서 일을 주제로 한번 돌아보는 시간을 가져보라.
이건 일을 잘하고 협력하기 위한 첫단추 일뿐이다.
실재로 우리 개발업무를 맡고 있는 사람들의 전유물도 아니다.
병원에서 질병에 대해 다른 과의 의사분들과 토론하고 토의하는 장면을 드라마나 영화에서 종종 볼 수 있다.
영화에서 조종사들끼리 브리핑을 하고 임무 종료후에 디브리핑을 하는 것도 종종 볼 수 있다.
운동경기에서도 마찬가지이다.
우리는 실재로 볼 수 없지만 경기시작전 감독은 선수들과 이번 경기에 사용될 전술을 브리핑하고 작전 타임을 불러 계획을 변경하고 경기후에는 비디오 분석을 통해 디브리핑을 한다.
이러한 목표 공유활동은 "문제를 인식"하고 "계획을 변경"할 수 있도록 하며 새로운 방법을 받아 들일 수 있도록 이해관계자를 "설득할 수 있는 기회"를 만들어 준다.

결국 애자일을 리딩하는 사람은 애자일하게 문제를 해결할 수 있고 스스로 원하는 변화를 만들 기회를 가질 수 있다.

가령 배포를 하고난후 난상토론을 통해 그간 업무 수행에서 어떤 점이 잘됐고 잘못된지만 제대로 공유되고 비난이 아닌 문제해결을 위한 회의를 통해 문제 해결 방법을 도출하거나 제안 할 수 있다.

실재로 내가 사용하고 있는 CI 툴인 HUDSON은 이러한 과정을 통해 도출된 아이디어였고 Doxygen도 마찬가지로 현장 실무자들의 아이디어였다.

단지 나는 그것을 채용하고 개발팀원 모두에게 공유했을 뿐이다.

마지막으로 기록하고 싶은 것은
"애자일 프래틱스 또는 도구는 아무것도 아니다. 애자일의 선언대로 그리고 회고를 통해 애자일을 추진하는 과정이 전부다."

애자일은 계획을 바뀌기에 중심을 두면 그것은 애자일이 아니라 그냥 잦은 계획 변경에 불과하고
애자일이 리팩토링에 중심을 두면 그것은 애자일이 아니라 그냥 잦은 배포에 불과하며
애자일이 기존 개발방법과 전혀 다르다고 생각하면 추진할 수 없는 문화이며
규모가 아주 작은 프로젝트라면 오히려 애자일보다 폭포수(Waterfall) 모델이 오히려 효과적일 수 있다.
마지막으로 인간은 감정의 동물이며 감정이 발단이 되어 논리를 만드는 동물임을 잊지말자.

따라서 개발 리더는 모두 알아야 한다. 그리고 상황에 맞게 적용해야 한다.
그것이 애자일 추친의 어려움이다.

=== 끝 ===

처음에는 불가능한 미션처럼 보였다.
무려 130대의 서버를 1달. 그중에서 추석연휴가 껴있고 휴일을 빼면 보름 남짖한 근무시간동안 다 설치하라니 미친것 아닌가? 하는 생각밖에 안들었다.
서버만 설치하면 그나마 어떻게든 해보겠지만.. 더 가관인것은 인프라부터 웹서버까지 토털 납품이 목표였기에 더 미친 짖처럼 보였다.

먼저 네트워크 선을 깔고 전원 선을 깔고 할당된 파티션위에 42U 짜리 서버 랙을 올려놓고 적정수량의 서버들을 장착한다. 그리고 Fiber를 연동하고 어마어마 한 량의 VLS 백업서버와 Storage를 설치한후에 파티션을 조정하고 모든 서버위에 OS와 웹서버 보안 등등등을 하는 일이 단 추석낀 1달동안 다 끝나야 한다면 가능한 일일까?

어쨌든 당시에는 무슨 정신이 있었는지 모르겠지만 손들고 "제가 하겠습니다." 했다.

그리고 현장으로 짐싸고 뛰어가서 제일 먼저 한일이 이해관계자의 소집이었다.

"우리의 목표는 어쩌구 저쩌구 그래서 커뮤니케이션이 중요하므로 매일 사진으로 현장의 상황을 보고 드리겠습니다. 도와주십시오."

모두가 모인 그자리에서 내가 한 이야기는 이게 전부다.

그러자 시설담당자가 언제까지 시설 작업을 끝내야 하냐고 물어봤고 이어 전원 담당, 네트워크 담당이 스스로 일정과 해야 할 일을 물어 봤다.
서버 장비 담당자만이 묵묵부담이었을 뿐이다.

글뻥 : "서버는 어떻게 재고가 준비 되어 있나요?"
서버담당 : "그 정도 수량이 재고로 쌓여 있을리가 있을까요? 싱가폴에 주문 아무리 빨리 넣어도 통관하는데 하세월입니다."
라는 답변에 모 제조사 영업 담당자를 통해 무슨 수를 내서라도 납기 완료일 7일전까지 모든 물량을 납품해 달라고 요청하였다. 그 당시는 내가 생각해도 미친거였다.

짧은 미팅을 마치고 그날 밤부터 카메라로 사진을 찍기 시작한다.
그리고 모든 이해관계자에게 매일밤 찍은 사진을 보냈다.

같은 장소에서 일하고 있지 않았지만 사진이라는 무기의 위력은 엄청나다.
거기다가 각 담당별로 경쟁이 붙기 시작한다.
시설 담당자가 레일을 깔고 파티션 작업을 끝내면 전원 담당자와 네트워크 담당자가 그 위에 선을 설치하고 모든 준비가 밤샘 작업으로 단 2일만에 완료되었다.

매일 아침 어제 보내드린 보고서를 바탕으로 다음 작업을 준비시켜 놓고 서버제조사 담당자와 오더 진행현황 통관 진행현황을 거의 실시간으로 공유하였다.

이어 현장팀은 서버가 도착하는대로 IDC로 올려보내기 위해 모든 절차를 확인하고 각종 서류 문서를 미리 작성해서 서버가 보안팀의 제제없이 최소한의 시간으로 IDC로 올라갈 수 있도록 준비하고 이동 경로 역시 세심히 따져 두었다.
3일차부터 국내 재고가 있는 서버부터 들어온다.
이때 중요한것이 자리 잡는 것인데 팀원(그래봐야 2명...)들 스스로 수십번의 반복 암기를 통해 알고 있는 위치로 랙을 설치하고 마무리 작업까지 숙지 하고 있었던 터라 일사천리로 업무가 진행되었고 파티션 용량까지 다 암기하고 있었던 팀원들 덕에 큰 사고 없이 1달안에 130대의 서버 납품, 설치가 완료되었다.

애자일의 가치를 S/W가 아닌 H/W 에 적용한 결과였다.
지금에는 애자일의 가치라고 당당히 이야기하지만 그 당시는 그러한 지식도 없이 목표는 "모든 이해관계자의 목표 공유와 리얼타임 커뮤니케이션"이었다.

그 1달외에 추가 변경 업무로 인해 수개월을 보라매 사옥에서 먹고 자고 주말만 퇴근잠깐 하는 일상이었지만 잘되는 팀은 한가지 공통점을 가진다.

바로 "성공에 대한 확신"이 서면 그리고 "목표를 공유하고 스스로 책임자가 되면" 그 팀은 굉장히 무서운 팀이 되어 버린다.

후에 참여 했던 수많은 엔지니어, 영업담당자, 관리자들이 한결 같이 한 이야기는 "보고서를 써라라고 할 줄 알았는데 꺼꾸로 보고서를 주신것이 신선했고 사진으로 진행사항을 가시적으로 보여주어서 스스로 도움이 많이 되었다"는 것이다. 그리고 안티 C&C 고객사 담당자가 몇년이 지난 후에도 "내가 SKC&C에게 딱 한번 박수 쳐줬는데 그게 바로 서버 납품/설치 프로젝트다."라고 자랑스럽게 이야기 하였다고 한다.

이후에 투입된 2건의 서버납품건도 이러한 현장의 모습을 가지적으로 보여주는 것만으로도 충분히 효과를 발휘하였었다.

2008년 5월이 되어 본사로 복귀한지 하루 이틀 지났을 무렵 "세X 텔레콤"에 프로젝트가 박살났으니 들어가서 마무리 지으라는 지시를 받고 다시 짐챙겨 갔었다.

요구사항 분석의 오류로 인해 고객은 화가 난 상태이고 팀원들은 전부 입만 열면 욕하기 바쁜 상태에 놓여져 있었다. CRM 솔루션을 해당 고객사 입맛에 맞추다 보니 모든 것이 꼬여 있는 상황이었고 5월에 들어가서 1개월 만에 프로젝트 팀원 전원을 철수시키고 혼자 남아서 마무리 작업을 계속 진행하였다.

고객의 비협조(개인적으로 굉장히 친했지만... 업무적으로는 담당자의 교체, 퇴사 등으로 난리인 상황)에 녹초가 되어 납품 확인 싸인 다 받고 나왔음에도 초기부터 틀어진 요구사항은 끝내 힘싸움으로 까지 발전하여 본인에게 상처만 더 남긴 프로젝트가 되었었다.

이때까지 애자일이라는 용어는 서점에서나 보던 것이고 좀 제대로 내가 잘할 수 있는 일을 하길 원했었다.
이후 고객사의 미국법인에서 진행하는 연구과제가 있다는 이야기를 듣고 제안을 하게되는데 어차피 미국이니 제안서 따위는 최대한 간결하게 작성하고 이왕이면 실재 작동하는 프로토타잎이나 비슷한 어플을 만들어서 가져가자고 주장하여 관철시킨다.

당시 그 연구과제는 인간의 활동 패턴을 분석하는 프로젝트였고 우리는 마침 이미지 패턴을 분석하여 Recognition 하는 테스트 과제(노느니 개발한다.)를 진행하고 있더차라 마침 우리가 만든 얼굴인식, 모션인식,배경화면 치환등의 CAM기반의 Prototype과 10여장의 제안서를 들고 찾아가서 프로젝트를 수주하는데 성공하였다.

다행인것은 그 조직이 신생조직이었고 기존의 방법론에 이골이 난 리더가 그 현장에 있었다.
우리에게 조건을 내건것은 "기존 방법으로 개발하려면 관둬라. 새로운 프로세스를 만들어와라"였다.

그뒤 우리는 거의 모든 종류의 애자일 방법론을 분석하였고 고객이 힌트로 주는 방법들과 내가 알고 있는 방법들을 하나하나 녹여 넣는 작업을 하여 "GSL 방법론" 이라 이름 붙인 알고보니 스크럼을 만들어 낸다.

원칙은 간단했다.
1. 페어 프로그래밍 그딴거 안한다.
2. 요구사항 분석서, 명세서 따위의 불필요 문서는 만들지 않는다.
3. 모든 문서는 Wiki로 작성한다.
4. SVN을 통해 형상관리한다.
5. 이터레이션별로 쪼개서 개발한다.
6. 유닛테스트 만큼은 자동화 한다.
7. Doxygen 과 같은 산출물 문서자동화 툴을 적용한다.
8. 설계는 UML로 통일하고 설계시 테스트 케이스도 같이 도출한다.
9. 최종 사용자 UI테스트는 사용자가 한다.
10. 필요하면 방법론도 바꾼다.

Iteration 0를 우리는 Prototype단계라고 불렀었다.
각팀원의 Role과 커뮤니케이션을 점검하기위해 약 1주일간 장비로 부터 받은 Bluetooth Signal을 서버로 올리는 간단한 Application을 개발하는 것이다.
정확한 요일은 기억이 나지 않지만...
월요일 고객과 목표를 설정하였고 같이 일정계획을 세웠다. 이번에는 기간이 우선이니 가능한 인터페이스를 뚫어 보자가 목표였고 화요일 Star UML을 통해 UML 4종 세트를 만들고 고객과 리뷰하였다.
화요일 오후부터 금요일까지 개발을 완료하였고 그날 저녁 동영상으로 만든 작동하는 어플의 모습을 보고하였다.
이때 이전의 서버 설치를 통해 검증하였던 커뮤니케이션의 효율을 높이기 위해 매일 아침 모여서 오늘 할 일과 어제 했던 일을 점검하는 시간을 아침 9:30~10:00정도까지 짧게 가져갔었다.

다음 단계는 실재 구현이 하달된다.
월요일 고객과의 미팅을 통해 지난 Iteration 0에서 잘된 점과 잘못된 점을 도출하고 잘못된 점을 어떻게 잘되게 할지 고민하였다. 누구도 잘못된 점을 비난하지 않았고 오히려 잘못된 점의 원인을 파악하고 개발팀 차원에서 어떻게 하면 잘못된 점을 잘된 점으로 끌고 가느냐의 방안들을 수립하는 것이 인상적이었다.
이어 목표가 제시되고 그 자리에서 러프한 일정계획이 수립된다.
언제부터 설계하고 개발하고 테스트 할지가 결정되면 그것을 우리는 "성과평가회의"라고 불렀고 양식도 최대한 심플하게 통합하여 Wiki로 저장하였다.
단계별 개발기간은 일정하게 2주 또는 1달이 아니었다. 제시된 목표에 따라 그 기간은 합의에 의해 달라진다.
아마도 기억에 Iteration 1의 기간은 약 3주 정도로 기억된다.
주어진 목표를 우리는 초과 달성하여 목표 기한 -2일 정도로 끝내었다.
다시 동영상을 뜨고 인코딩하여 보고하고 그주말 부터 팀원들을 휴가를 가기 시작했다.
그 다음주는 고객의 Feedback을 위해 고객이 직접 작동하는 어플리케이션을 설치하고 만져보는 시간을 약 3일정도 가졌던 것으로 기억된다.
이후 성과 평가 보고회를 통해 목표의 달성, 잘된 점, 잘못된 점, 고객 Feedback, 다음단계 계획을 보고서로 남기고 Iteration 2를 진행하였고 Iteration 2에서 기억나는 잘된 점이 바로 신입사원이었던 모 사원의 노력으로 UML을 작성하고 나면 간단히 Documents 를 생성하도록 Templet을 적용한 것이다.
또한 TEST CASE 문서역시 자동 Generation 되었다.
또한 이때부터 MS사의 Unit test가 HUDSON이라는 CI툴에 들어가기 시작했고 우리가 원했던 Doxygen이 작동되기 시작했다.
그것도 목표 기간보다 단축되어서...

이때부터 논리적 설계와 실재 구현된 코드를 UML문서와 Doxygen을 비교함으로써 명확하게 설계된 부분과 실코드가 어떤부분이 다른지 파악되기 시작했다.

다른 부분은 설계에 반영하여 Method와 Entity 값들을 일치화 하였고 그동안 생각해왔던 UI Mockup Tool인 Balsamiq을 시범 적용하여 개발전 UI테스트를 선진행 하는 성과도 이때부터 얻었던 것으로 기억난다.
또다른 변화는 모든 팀원들이 스스로 기간단축하고 휴가가기 위해 혹은 일찍 퇴근하기위해 단계별 초기에 야근을 마다 하지 않았다.
이런 성과는 Issue Tracker를 활용하여 자신의 업무를 정량화 시키는데 성공하였기 때문일 것이다.

그렇게 몇개월이 흐르고 우리는 고객이 원하는 일정에 모든 개발을 완료할 수 있었고 차기 사업을 기획하던 도중 조직의 변화로 손가락 빠는 신세로 전략하게 되고 만다.

이후에 언론사 컨설팅 프로젝트에 있다가 그나마 하드웨어를 잘안다는 이유만으로 다시 서버 납품으로 1달 정도 보내다가 미국법인에서 직계약 할테니 기대는 말고 준비나 해둬라라는 연락을 받는다.

여기서 또 써먹었던 Prototype 전술을 사용하였다.

=== 다음에 또 계속 ===

여기까지 다시 말해 2004년까지 나의 프로젝트 수행방법은 언제나 "요구사항 분석, 설계(?), 구현, 테스트"였다.
요구사항을 받거나 혹은 고객에게 요구사항을 그리라고 하고나서 그것을 검토하고 담당자를 배치하고 담당자에게 물어본다.
"언제면 끝나겠니?"
담당자는 나이 어린 PL을 바라보면 "3주~4주 걸린거 같은데요~"라고 하면 "안돼. 오픈일이 언제고 테스트 기간이 얼마 잡혀 있으니까 요때까지 끝내야돼"라고 이야기 했다.

즉, 모든 계획의 개발 일정=오픈일-테스트일정-Plus Alpha였다.
오픈일은 어차피 정해져 있는것이고 오픈일을 어기면 다 뒤졌으~ 이런 마인드였던 것이다.
20대 후반 30대 초반의 개발 3~4년 하다가 갑작이 리딩을 맡게된 PL이 할줄 아는게 이게 다였다.
그리고 개발자가 원하는 개발 기간을 빼고나면 설계 소요 기간이 되고 설계소요 기간을 빼고나면 오늘로 부터 설계착수일까지가 바로 요구사항분석 기간이 되는 것이다.

따라서, 고객에게 이렇게 이야기한다.
"님~! 이거 언제까지 그려주세요" 혹은 "님이 원하는게 뭐죠?"

당시 알고있는 설계지식이라봤자 고작 "Flow chart"와 "ERD", "UI 설계"가 전부인줄 알던 풋내기 PL은 그렇게 일을 했었다.

그런데 여기서 부터 문제가 발생한다.

지금까지 겪었던 수많은 고객들은 스스로 무엇을 원하는 지, 무엇을 하고싶어 하는지 몰랐다.
이것은 지난 10여년동안 변한적이 없던 진실이다.

예를 들면 이런식이다.
글뻥 : "음.. 과장님께서 하시는 일이 뭐죠?"
과장 : "제가하는 일이 뭐 있나요... 그냥 이것저것 하지요"
글뻥 : "그래도 프로젝트 개발하러 왔는데 뭐가 필요하신지 말씀을 해주셔야..."
과장 : "그건 그쪽 사정이지요. 그냥 저는 이대로가 좋은데... 전산팀에서 뭐라하나요?"
글뻥 : "전산쪽에서 발주내서 어쩌구 저쩌구 그래서 저희가 왔는데... 그럼 지금까지 불편하셨던거는 없으셨나요?"
과장 : "뭐 불편한게 한두갠가요? 이런것도 불편하고 저런것도 불편하고..."
글뻥 : (마구마구 적는다..) "아~ 그럼 이런것을 고치면 되겠네요."

이렇게 받은게 나의 요구사항들 이었다.
이정도는 양반이다.
어떤 고객은 "그냥 엑셀처럼 만들어 주세요!"라던가 "아 XX 바빠 죽겠는데... 담에 와요~"라던가...
그렇다고 해서 업무 매뉴얼이 있는가?
업무 매뉴얼이라도 보면서 관계도를 그려보면 금방이라도 알 수 있을 업무 관계를 전적으로 탐정이 된 것처럼 탐문 수사(?)를 해야 하니 어찌 제대로 된 요구사항이 나오겠는가?

이런상황에서 2004년 11월 프로젝트 종료후에 서산으로 옮겨 가게된다.
대학교라는 곳이 병원, 종교기관, 학원과 함께 SI회사의 무덤이라불리는 그곳으로 끌려가서는 처음 들은 이야기는 이것이었다.
"SKC&C는 가만히 H/W나 납품하시오. 나머지는 저기 당신들 협력사랑 같이 하겠소."
그래서 진짜 H/W나(?) 납품하고 설치하고 운영하는 일을 맡았다.
HP RX 8640 장비라는 대형 클러스터링 서버를 MSCS 설치하여 Database Active-Standby 로 운영하는게 내 업무였다. 분명 프로젝트 관리를 위해 내려간 현장 책임자였지만 당시 내일은 이런 것이었다.

종합대학교의 학사행정 시스템이 그리 간단한 것이 절대 아니다. 1만명이나 되는 학생들이 수강신청을 할때는 상상을 초월하는 트래픽이 발생하는 시스템이며 사소한 전산 오류 하나가 학생의 미래를 바꾸기도 한다.
거기다 시시탐탐 성적표를 노리는 해커들이 있는 곳이 바로 학교 전산 시스템이다.
그야 말로 사회의 모든 시스템을 모아놓은 곳이 바로 학교이다.
이런 시스템을 몇개월간 수천장에 달하는 인터뷰 목록이 만들어 졌고 협력사 직원들이 매달려 수개월간 CRUD라고 하는 챠트를 그려 나갔다.
CRUD를 그리는 수개월이 지나자 한학기가 끝났고 그 CRUD를 다시 Entity와 Relation으로 표현하는데 다시 수개월이 흘렀다. 분석이 끝난 시스템부터 개발되기 시작했으며 그 과정을 일정 계획표하나 가지고 TASK하나가 끝날때 마다 하나씩 지워가며 "진척도가 몇 %입니다"라고 보고서에 올렸다.

그러다가 이슈가 업무관계가 안맞는 이슈가 터지기 시작하고 이슈가 무려 200여개나 되는 미친 시스템이 되어 가고 있었다.

즉, 학사과에서 어떤 일을 하면 그것이 각 학과로 연결되고 학과에서 업무는 다시 학생과, 행정처, 학생 예비군, 학적과, 수납과, 회계팀 등으로 퍼져나간다. 그런데 각과의 업무중 하나라도 문제가 발생하면 모든 업무는 스톱이 되는 것이다.
그런데 이런 밀접한 관계를 가진 시스템을 고작 20명이 들어가서 6개월이 넘도록 인터뷰만으로 요구사항을 도출했다는 것이 가당키나 한 것일까? 그것도 고작 개발 경력이 길어봐야 5~6년 많이 길면 10년 넘으신 분들 1, 2명으로 비전문 분석가가 수천장에 달하는 문서를 만들고 그것을 정리해서 설계한다는 것이 가능한 일일까?

결국 프로젝트는 망했다.

요구사항을 제대로 구현하기는 커녕 잦은 요구 변경과 고객의 원성에 형상관리조차 하지 못하는 상황에서 그제서야 "C&C가 책임져!"라는 고객의 요구는 어찌보면 황당하기 그지 없는 일이기도 했지만 그제서야 문제를 잡아가기 시작했다.

제일 먼저 한일이 형상관리 부터 때려 잡는 일이었다. 그래서 생각해낸 것이 보험사 SM요원이었을 때 도입된 "하베스트"라는 형상관리 툴을 기억해냈고 오픈소스로 뒤져보니 CVS와 비슷하지만 사용하기 쉬운 "SVN"이 눈에 띈다. 부랴 부랴 개발 시스템에 "SVN"을 설치하고 형상관리를 하기 시작했다.
프로젝트가 1년하고 2개월정도 진척되고 있을 무렵 늦었지만 형상관리가 들어가자 버그가 눈에 띄게 줄어든다.
그렇지만 몇개월간의 강행군으로 개발자 하나 둘씩 나가 떨어지고 고객은 고객대로 불만만 쌓여 결국 그해 여름 전면 감사라는 표현으로 감리를 수검하게 된다.
본사에 올라와서 몇개월에 걸친 방대한 문서를 감리 수검을 위해 재정리하고 본사의 감리 전문가들도 손을 들고 말았다. 결국 그들이 선택한것은 현장 책임자인 나와의 인터뷰였고 결론은 "감리 부적합"이었다. 보완사항을 지적받고 다시 재정리한 끝에 감리수검용 문서만 바인더로 4~5m 정도 쌓아 놓고 감리를 수검하였다.
10일간의 수검기간동안 감리인들은 그 방대한 문서를 다 보지도 못했고 그들이 남긴 한마디는 "그래서 프로젝트 잘된다고 생각하시오?"였다.
아무튼 관리 측면에서만 "부적합"이었고 나머지는 "적정" 또는 "보통" 판정으로 고객의 중도금 미지급 문제와 공문과 내용증명에 대한 미응답을 사유로 고객 책임이 되고 말았다.
대신 감리 지적사항에 대해서는 시정 명령을 받아 이수하였고 그것으로 그 프로젝트는 종료되었다.

햇수로 3년 만으로 2년의 전쟁이 남긴것은 나에게 몇 가지 질문을 주었다.

첫째, "요구사항 도출 방법은 적정한가? 더 확실한 방법이 없을까?"
둘째, "현재 설계 방식이 적정한가? 더 빠르게 설계할 방법이 없을까?"
셋째, "SVN은 합리적 선택이었을까?"
넷째, "TASK의 완료가 실재적인 완료일까?"
다섯째, "테스트를 자동화 할 수 있을까?"

첫번째에 대한 질문은 이전 프로젝트에서 우리가 고민했던 그 문제 바로 Mockup툴의 필요성으로 귀결되었다.
고객이 스스로 만든 어플을 돌려 보면서 빠르게 고쳐 나가면 요구사항은 확실하게 Fix될 것이라는 생각이다.
두번째에 대한 질문은 ERD와 UI설계, Work Flow의 과감한 통합 내지 포기였다.
그래서 선택한것이 바로 UML이었다.
셋째는 SVN만한것이 없었다.
넷째는 TASK의 완료는 완료일뿐 실재적인 고객이 원하는 어플을 만들지 못한다는 결론에 이르렀고 TASK가 중요한것이 아니라 최종 산출물이 중요하다는 것을 깨달았다.
다섯째는 그 당시 JUNIT과 xUNIT을 보면서 자동 유닛 테스트 만이 해답이라는 생각을 했다.

2006년 12월 프로젝트가 종료되고 복귀한후 마침 팀으로 이동해온 모 과장님을 붙잡고 공공에서 경험하셨던 UML을 하나씩 하나씩 알려달라고 조르고 물어보면서 하나 하나씩 배워나갔다.
그리고 사내 UML강의도 들으면서 UML에 대해서 하나씩 하나씩 내것으로 흡수하기 시작했다.

그런데 이게 웃기다.
배움을 얻으려 했던 거의 모든 전문가가 USE CASE Diagram을 그리고 바로 Class Diagram을 그리고 이것을 다시 Sequence Diagram으로 전개하는 것이 아닌가?
그렇다면 Class Diagram은 전혀 근거없이 상상의 나래를 펴서 만드는 것 아닌가?
즉, CRUD없는 ERD였던 것이다.

몇권의 책을 사서 보기 시작했다. 과연 이게 맞는 것인지.
그리고 해답을 찾았다. Workflow Diagram인 Activity Diagram이 바로 그것이다.
이제 하나씩 연결고리가 보이기 시작했다.

1개의 USE CASE는 1개의 Activity Diagram을 가진다.
1개의 Activity Diagram은 n개의 Action과 Entity를 포함한다.
즉, Activity Diagram으로 도출된 Action이 바로 Method 였던 것이고 그 Action 을 작동하기위해 들어가는 인자값인 Entity가 Entity 였던 것이다.
다시말해 Method를 따로 모아두면 Controller Class가 되고 Entity만 모아 두면 Entity Class가 된다.
이게 바로 Class Diagram의 정체였던 것이다.
또한 그 Class Diagram의 연관관계가 Sequence Diagram이다.

즉, 적정한 UML은 요구사항 분석과 함께 설계 및 설계를 통해 예측되는 작동까지 알수 있는 툴이 되는 것이었다.
그러나 여전히 UI 설계와 사용자 체험에 대한 갈증은 풀수 없었다.

그리고 한참뒤 쉬고 있는 동안 T의 Store 컨설팅 프로젝트에서 아키텍쳐의 역할을 맡으면서 지금까지 고민해왔던 그동안 딱아 왔던 나만의 무기를 꺼내 들고 유수의 컨설던트들과 협업하기 시작했다.
수많은 업무범위를 적정하게 쪼게야 하는데 어떤 데이터 기준으로 쪼게는지가 문제였고 내가 사용한 방법은 바로 포스트 잇이었다.
파워포인트로 한장씩 그려서 혹은 화이트 보드에 그려서 커뮤니케이션하는데는 많은 시간과 가시성이 떨어지는 문제가 생겼고 파견된 1주동안 나는 사업팀의 대표로 그 문제를 풀어야만 했던 것이다.
결국 마지막날 하루전에 아키텍쳐들과 컨설던트, 그리고 다른 참여자들이 모두 모인 그 자리에서 포스트 잇을 꺼내서 발생할 수 있는 데이터의 종류를 모두 가리지 말고 불러 보라고 하였다.
"고객기본 정보", "배송정보", "환불정보" 등등등등 수많은 포스잇 위에 나오는 이름마다 하나씩 모두 포스잇에 적어 나갔다. 그리고는 비슷한 것끼리 모아서 붙여 나가자 하나의 거대한 나무가 만들어 진다.
이것으로 모든 업무 수행조직이 결정되었고 어떤 데이터를 어떻게 흘려야 하며 누가 컨트롤할지가 결정되었다.

이작업을 통해 느낀 바는 "가시성이다."
말과 글은 은유의 종합예술 일뿐이었다.
따라서, 사람들이 무엇인가를 보기전에는 결정하기 매우 어렵다는 사실을 다시 확인했고 그것을 꺼꾸로 이용한다면 쉽게 결정을 도출할 수 있다는 것도 배웠다.

이로써 나는 차기 SI프로젝트에서 사용할 무기들을 어느 정도 완성할 수 있었다.

심플한 요구사항을 결정하기 위한 포스트 잇의 새로운 사용처를 발견했고 요구분석도구인 UML USE CASE와 Activity Diagram을 자유자재로 사용할 수 있게 되었으며 이를 통해 설계할 수 있는 Class Diagram과 연관관계를 통해 실재 어플이 작동되는 것을 예측할 수 있는 Sequence Diagram을 보유하게 된것이다.

긴 문장보다 그림으로 표현되는 심플한 방식은 그 뒤의 T-Store (현재의 11번가) 하드웨어 설치 프로젝트 PM을 맡으면서 더 크게 적용되었다.

130여대의 서버와 네트워크 장비, 그리고 그 인프라를 1달안에 설치하는 프로젝트에서 S/W개발 툴들과 기법을 적용할 기회를 얻은 것이다.

=== 다음회 계속~ === 

애자일에 대한 이야기를 한동안 하지 못했다.
프로젝트는 막바지로 달리고 있고 안정화 작업에 여념이 없는 팀원들을 바라보며 아쉬움과 조금더 강하게 리딩했어야 했어 하는 생각도 들지만... 쩝...

일전에 포스팅한 애자일 초보자 강연은 Focus 자체가 글러 먹었었다.
한동안 생각했다. 그러다 내린 결론은 애자일을 어떻게 추진해왔는지 하는 과정을 처음부터 구구절절 기억을 더듬어 써놓으면 처음 접하는 사람들에게 도움이 되지 않을까 하는 생각이다.
물론 애자일 경험담은 경험으로 쓰기는 했지만...
기존의 문제에 대한 인식을 써놓은 탓에 눈에 잘 안들어 올 수도 있는 것이다.
그래서 애자일 경험담 19편 부터는 중간 정리차원에서 애자일의 구구절절 뒷이야기를 한번 풀어보고자 한다.

때는 2004년이었다. 2003년 SK C&C 의 투자회사였던 엔텔을 그만두고 나와서 쇼핑몰에 잠깐 개발 팀장으로 있다가 다시 SKC&C로 돌아온 2004년 2월이었다.
당시 프로젝트는 T의 BCP라는 X-Internet을 실재 업무에 적용하는 ASP 구축 사업으로 개발자만 70명이 넘는 대규모 프로젝트였다.

그러나, 문제가 발생하였고 PM 교체라는 극단적인 상황에서 그해 2월에 사수였던 모 과장님의 추천으로 정식 입사를 하였다. 어차피 친척 회사였던 탓에 연봉 협상 이런거 없이 그냥 채용 시험 보자마자 예전에 받던 연봉 받으삼~ 통보받고 입사한 것이다.
아무튼 당시로써는 획기적인 X-Internet을 접했지만 왠걸...
4월에 프로젝트 종료인데 업체간의 알력다툼으로 Interface도 정해지지 않은 상태이다. OTL..
2개월간 내 업무는 통합 PL 역할이었고 그때부터 2개월간 일요일도 토요일도 없는 생활이 반복된다.
그야 말로 새벽 5시에 자고 9시에서 10시에 일어나 하루죙일 일하다가 새벽에 책상에 퍼지는 생활의 연속이었다.

막판에 항상 들어오는 요구사항 검증 및 변경에 매달리다 보니 어느새 4월이 되었고 다른 프로젝트때문에 후임자에게 인수인계하고 XX 보일러 회사 CRM에 BCP 플랫폼을 들고 간다.

5월부터 시작이었나? 프로젝트 종료는 7월로 매우 빡빡했다.
먼저 BCP를 가지고 모바일 AS 기사 관리 시스템을 구축하고 고객상담센터를 100여석으로 늘리면서 기능을 추가하는 모든 업무를 3개월에 마치라는 미션이 떨어졌다. (덴장 걸리는 프로젝트마다...)
몇날 몇일의 강행군속에 어느날 고객센터에 날아온 카나리아 한마리를 손으로 덮석 잡아다가 집에서 새장에 키웠는데 먹이 못주는 날이 거급되자 굶어 죽고 말았다는 슬픈 기억이 있었다. 이때 혼자 사는게 불쌍해 보여 한마디 더 넣어 줬지만 이녀석도 결국 굶어 죽고 만다...
같이 일하던 동료는 지방에 모바일 교육을 돌아 다녔고 우리는 우리대로 남아서 고객센터 업무에 매달렸지만 결국 요구사항의 변경과 BCP 개발팀의 개발 진척 미진으로 인해 그해 11월까지 남아 있어야 했었다.

이때 처절하게 필요했던 것이 바로 Mockup 개념과 지금의 SOAP과 같은 Simple한 Controller였다.

- Mockup 은 요구사항을 확정하는데 Power point보다 빠르게 작성하고 UI를 실재 눌러보면서 고객과 Communication하는 Tool로 적합할 것이라는 판단이었다.
- Controller가 분리 되어 있다면 변경 작업이 매우 작아 질것이라고 생각했다.

당시 개발팀원들은 이런 고민들을 했었다. 어떻게 하면 빠르게 개발진척하고 조기에 요구사항을 확정시킬까?
나름 십년 이상 개발하던 분들이었고 술한잔하면서 그러한 고민을 해결하기 위해 각종 아이디어가 쏟아져 나왔는데 바로 그중 몇개가 위의 Mockup 툴과 Controller가 분리된 Framework였다.

프로젝트가 지연되자 해당 전산팀장님이 폭발하셨고 수많은 이슈가 발생되고 해결이 불가능한 상황으로 가기는 했지만 우리의 전략전술은 "열심히 몸빵하면 고객이 좋아하겠지" 전술로 밀어 붙이다가 전산팀의 도움으로 겨우 현업을 설득하여 종료하기에 이른다.

이때의 처절한 경험을 글로 남겨서 본부장님께서 주시는 상도 받았다는 웃기지도 않는 현실이었다.

= 2부는 다음으로 =

*[Xper] 2010 Agile Seminar for beginners(6/26)*
   - 일시 : 2010년 6월 26일(토) 9:30~16:00 (상황에 따라 30분 연장)
   - 장소 : 명동 LG CNS 본사 9층 대강당
   - 참가 자격 : 애자일에 관심 있다면 모든 분들을 환영합니다.
   - 참가비 : 5,000원(점식식사 비용입니다. 선입금 외환은행 620-193437-140 장정화 )
   - 문의 : 장정화(Mobile: 010-8946-8418, E-mail: jang.hell...@gmail.com)
   - 참가신청: *http://www.onoffmix.com/e/xper/1592*

*일정***
   - 09:30 ~ 10:00 - 접수자 확인 및 입장
   - 10:00 ~ 10:10 - Xper 소개
   - 10:10 ~ 11:00 - Agile 이란? (애자일컨설팅 대표 김창준님 발표 30분, Q&A 20분)
   - 11:00 ~ 12:00 - Agile 사례 발표 (SK C&C 민신현님 발표, 정확한 주제는 추후 공지)
   - 12:00 ~ 13:00 - 점심시간(도시락)
   - 13:00 ~ 15:00 - 칸반게임(삼성 SDS 황상철 책임, LG 전자 심우곤 책임 공동 진행 - 칸반게임은 애자일을 실습
   할 수 있는 게임입니다.)
   - 15:00 ~ 15:30 - 회고

* 관련 링크 : http://groups.google.com/group/xper/bro ··· 7e30b79b


어제 장정화님께서 전화주셔서 김창준님 발표 끝나고 애자일 초보 세미나에 발표 하면 점심 도시락 주시겠다는 꼬임에 넘어가서 넹~ 그럴께요~ 했는데...
지금 일정을 보니 솔찍한 심정으로 ㅎㄷㄷㄷ 하다.

무슨 내용으로 김창준님의 포스를 잘받아서 칸반게임까지 잘 토스 할 수 있을까? 이런생각 때문이다.
일단 iPAD의 Keynote로 좌중의 시선을 끌고나서 잡스처럼 청바지에 시커먼 목티입고 올라가야 하나?
라는 재미있는 상상도 해보지만.. 역시나... T_T 심란해...

 

이번주부터 팀 재건 차원에서 몇가지 일들을 수행하고 있는데 이를 소개 할까 한다.
먼저 오전에 일일 이슈회의를 진행하고 있다.

그날 또는 전날 또는 그 이전에 고객 또는 Risk 를 나열하고 토론하며 팀원들과 업무우선순위를 재조정하는 일들을 진행하는 것이 그 첫단계이다.

나의 일은 서두에 몇가지 생각하고 있는 구두상 요청사항이나 프로젝트 범위나 변경에 영향을 미칠 만한 것들을 찾아 키워드로 화두를 던지면 나머지 팀원들의 이야기를 들어주는 것이 전부이다.

몇주간 방치되었던 팀에서 이런 저런 이야기가 나오고 고객에 대한 불만 등이 쏟아져 나오면 가만히 듣고만 있는 상황이다.
속으로는 "참 내가 못났다"라는 생각과 함께 "내가 지금 잘 듣고 있는가?"와 "팀원들의 감정이 어떠할까?"라는 생각을 한다.

거의 모든 서비스업이 마찬가지겠지만 사람과 사람사이에서 받는 스트레스와 에너지 소모가 생각보다 매우 크다는 생각을 다시하게 되는 계기가 되고 있다.

마지막으로 하는 일은 모든것을 조합해서 오늘저녁 퇴근전까지는 이런일 이런일을 해야 한다라는 합의를 거치고는 다 함께 밖으로 나가서 못다한 이야기 등을 하고 있는데 한 4일정도 지속적인 의견을 교환하면서 팀원들의 생각과 나의 생각을 서로 맞추는 일을 하다보니 근무 의욕이 소폭 상승한 느낌이다.

그리고 또하나 하고 있는것은 USE CASE로만 정의되어 있었던 요구사항의 정의를 User Story라는 이름의 Chart로 재작성하고 있는 일이다.

처음에는 UX관점에서 조금더 Customer Value를 어떻게 올릴까 고민하다가 챠트를 만들었는데 생각지도 못했던 추가 업무들이 나타나고 있다.
차기 프로젝트에서는 초기부터 도입해야 할 듯 싶다.
간단히 예를 들면 이렇게 진행중이다.

Step	User Experience	System Message	Exception/Caution	Exception Message
제품수령	철수는 X폰을 수령하였습니다. 거금 80만원이나 준 최신 스마트 폰입니다. 제품을 수령하고 기쁜 마음으로 포장을 해체합니다.	n/a	포장 해체가 잘안된다. 매뉴얼, 충전기, 소켓 중 하나가 빠져 있다.	n/a 매뉴얼에 고객상담실 연락처를 적어놓는다.
중간생략
앱스다운로드	철수는 앱을 다운로드 받기위해 XXX 버튼을 누릅니다.	환영합니다. 철수님	네트워크가 연결되어 있지 않다. 서버가 죽어있다.	네트워크가 연결되어 있지 않습니다. CDMA통신망으로 연결할까요? 서버가 연결되지 않습니다. 계속 연결되지 않으면 고객상담센터 555-5555번으로 전화주십시오.

* 위의 챠트는 현재 제가 하는 업무와 관계가 없습니다.


먼저 최종소비자의 행동을 묘사하는 순서가 Step 항목이다.
최종 소비자가 제품을 인수받고 설치하고 사용하고 전원을 끄는 등의 시나리오를 주루루룩 기재한다.
그리고 고객의 상황을 소설을 쓴다. 즉, 고객이 경험할 일을 기재하는 것이다.
그리고 정상적인 고객경험에서의 반응을 기록하고
예외사항 또는 에러사항 등의 부정적인 상황을 기록한다.
이후에 어떻게 부정적인 상황에 반응할지를 기록한다.

이렇게 단순한 Chart인데 여러 팀원들과 같이 작성해 나가면서 생각지도 못했던 업무들이 발견되었다.

그리고 이번주의 하일라이트는 시계를 켜놓고 알람을 설정한 일이다.
짧고 퀵하게 하기위해 중간 중간에 몇분 남았다고 주지시키고 완벽하지 않더라고 일단 끝까지 가보자라고 독려하였다.

그결과 합의 과정이 굉장히 빨라졌다.
총 49개의 Step을 점검하는데 4:20분경부터 시작해서 5:10까지 약 50분만에 한바퀴 도는데 성공한 것이다.
내일 또 오늘의 기록을 바탕으로 2차 브레인 스토밍을 진행할 생각인데 내일도 알람 시계를 맞춰놓고 Quick하게 한바퀴 돌아 보고자 한다.

애자일 프로젝트를 진행하다가 지난 5월 초에 모든 업무를 중지하였다.
중요한 보고용 데모를 만들기위함인데 Show에 성공하여야 차기 사업 진행여부가 결정되는 일인지라 모든 개발 업무를 중지하고 데모 프로그램에 매달리고 있는 상황이다.

현재의 팀에서 추가적으로 데모 Contents 제작팀이 들어와 있는 상황이며 원격에서 근무하면서 즉시 지원해주고있다.

그런데 약 2주간 달리다 보니 몇가지 문제점이 들어난다.

원래 작게 데모하려고 했었는데 어느순간부터 점차 커져서 커뮤니케이션 문제가 발생하고 잦은 변경과 독촉으로 인해 Contents 제작팀이 제대로 업무수행하지 못하는 상황이다.

개발팀 역시 마찬가지이다.

중간 버전을... 개발 진행 점검이라는 목적으로 2~3일 혹은 1~2일 혹은 1~2번/1일 짧게 나마 중간 버전을 계속 빌드해서 시연하고 있는데 시연때마다 요구사항이 추가되거나 변경되는 일이 잦다.

기본적으로 실무자 스스로 스케쥴링할 수 있도록 매니징할 수 있도록 해야 함에도 불구하고 1~2일 작업으로 요건을 맞추려니 Quality게 계속 제자리다.

실무자들은 지쳐가고 Decision maker(Client)들은 만족하지 못하는 상황이 발생되어 고객 만족에 집중하다가 현재 상황은 고객 포기 상황에 다다른다.

최근 내업무는 개발팀의 관리보다는 개발팀 시다바리(?)에 치중하고 있는 상황이다.
CAM에 기능을 미지원하면 사비 털어서 CAM을 몇개 구입해서 뒤애서 테스트 하고 Client Confirm을 받는다던가...
음원파일을 찾아서 변환한다던가...
테스트 PC를 후배에게 지시하여 미리 설치해둔다던가...
하다 못해 인식용 카드를 코팅해서 만들어 둔다던가와 같은 일이다.

그러다가 퍼져 있는 PL들이 보이면 밖으로 데려가서 토닥토닥 하는 일이 전부인 상황...

Business의 중요 결정 회의니 마치 Client의 답답함과 개발팀과 Contents팀간의 업무 미루기를 겨우 겨우 해소하고 있는 상황...

그런데 이런 일련의 일들이 Agile 때문이라는 이야기를 들을까봐 겁이 난다.
현재의 데모 시연 어플은 전혀 Agile하지 않고 별도의 관리 보다는 요건이 나오면 즉시 반영해서 다시 시연하는 식으로 업무를 밀어 붙이고 있는데...

문제는 사람이 지친다는 것이 문제이다.

Contents 팀에서는 Design에 자신 있고 이것 저것 욕심을 내고 싶어 하지만 짧은 일정으로 인해 포기하게 만드는 것이 내일이며 개발팀 역시 짧은 일정으로 최소한의 가치만 만들려다 보니 결국 미완의 완성품이 만들어져 가고 있다.

중간 버전의 랜더링 엔진으로 프로젝트 종료후의 모습을 투영하려니 그역시 많이 힘든부분이기도 하다.

다행스러운것은 이러한 상황에서 SVN의 도움을 많이 받고 있다는 사실이다.
결정사항이 후퇴하는 건의 경우는 바로 리비전하여 빌드하고 있으니 그나마 쪼끔 나은 상황인것은 사실이다.

그럼에도 불구하고 시간적 여유가 너무 없다.

내가 어떻게 해야 하는지 그리고 지금 나의 역할을 제대로 해내고 있는지 궁금할 뿐...
즉, 우리 개발팀은 위기에 빠진 상황이라 판단되며 이를 어떻게 극복해 나갈지 고민이다.

현상황을 정리하자면...
고객의 참여는 멋찌지만 고객과의 신뢰 문제는 풀리지 않는 숙제인가?

프로젝트를 진행한지 약 한달가량 되었다.
실질 근무 일수는 19일정도로 그리 길지 않은 시간이었고 JIRA를 통해 프로젝트 관리한지는 약 근무일수 기준 보름정도이다.

그동안 SKC&C 개발 가능 요원 2명과 (허접한 본인 포함 3명인가?) 연구원 1명 등 4명이 개발팀과 Direct로 붙어서 일하고 있고 간접적으로 본사 연구원 2명이 간접 근무하고 있다.
고객사 요원 3명이 직접 전담중이다.
우리의 가장 중요한 메인 개발자는 6명, 서브 개발자 6명으로 총 12명이 본 프로젝트에 매달리고 있는데... 한달 정도 지나가면서 나름대로의 회고(?)와 반성을 하고 있는 상황이다.

먼저 오늘까지의 우리의 실적을 보면

154개의 요구사항 (커뮤니케이션, 조사, 발표 등등 포함) 중 총 115개를 수행하였다.
중요한 점은 완료 한것이 아니라 수행하였다는 것이다.
Milestone (즉, iteration, Sprint 같은 뜻으로 사용) 종료시점에서 Resolve된 Ticket을 다시열어서 Close 시킬것인지 Reopen할것인지 고객과 합의과정을 거치므로 수행하였다는 것은 단지 수행하였다는 것일뿐 완료되었다고 보기 힘들다.
현재까지의 Milestone 완료는
 Milestone1은 Perfect하게 종료되었으나 금번 Milestone은 전일 돌발 요구사항으로 인해 약 2Week의 일정 순연과 함께 급하게 덮어버린 상태이다.
어제 오늘 정도만 더 달렸다면 온통 녹색으로 칠할 수 있었던 기능 구현을 다음 Milestone으로 넘겨야 하는 심정이 너무나 가슴이 아프다.
약 1달간의 활동 결과를 보면 미리 간접 생산활동으로 지정한 ToDo가 27%로 전체 업무중에 상당수를 차지하고 있다.
직접 생산활동은 New Feature와 Sub-Task의 일부, Task라 볼수 있는데 이를 종합해 판단하면 커뮤니케이션 비용등 의 간접 생산활동이 약 40~50%정도로 추산되어 이를 시정할 방법이 없는지 고민중이다.

그러나 성과도 있었다.
먼저 활동의 투명성이다.
개발자 개개인은 자신에게 할당된 업무가 무엇인지 스스로 알고 있고 아직은 미숙하지만 스스로 관리하고 있다.
주단위로 보았을때 6시 칼퇴근자가 2~3명정도 저녁먹고 7~8시 사이에 대부분이 퇴근하고 9시정도는 PM과 PL들이 업무 정리시간을 가지고 있어 개발자의 피로도가 낮아 생산성이 매우 높다고 판단되고 Challenge 한 일정에도 불구하고 2주에 한번씩 진행되는 성과평가회의의 고객 만족도도 매우 높은 편이다.

그리고 고객의 신뢰 부분이다.
일정부분 고객에게 본의아니게 잘못된 보고를 하였으나 비교적 마무리가 잘되고 있는 상황이다.
거기다가 개발해야 하니 고객이 먼저 회의시간 짧게 가지고 가자라고 하는 부분은 너무나 고마운 이야기.
또한 고객 담당자가 윗 관리자에게 프로젝트 관리 잘하고 있다는 평판을 듣고 있는것도 나름대로 보람된다.
이러한 관계가 신뢰라고 생각하기에 더욱 그러하다.

즉, 투명한 프로젝트 관리를 통해 고객의 적극적인 참여를 유도하고 고객이 새로운 기능을 무조건 강요하기보다는 기능을 추가하였을때 일정을 조정하는 융통성도 발휘하여 주니 실무자 입장에서는 2마리의 토끼를 다 잡을수 있었던 것 같다.

하지만 아직 TDD 부분을 손을 못대고 있는 부분은 개인적으로 불만이다.
현재 하고 있는 프로젝트가 이미지 프로세싱+3D 분야이므로 고난이도의 과제이기에 초기 학습시간이 매우 길고 핵심 개발자들의 코드를 보면서 설계를 보면서 진행할 수 있는 부분이 한정적이다라는 것을 감안하더라도 업무에 있어 금주에는 해결했어야 했던 일임에도 안되고 있어 조금 답답하기도 하고 그렇다고 어설픈 상황에서 강요하여 역효과가 날것으로 생각되어 이부분도 사실 걱정되는 부분이기도 하다.

앞으로 남은 기간은 총 6주이다.
그중 2주는 돌발 요구로 인해 우리가 Delivery하기로한 제품을 손을 못댈 것이다.
이부분도 아쉬운 부분인지라 1달을 마감하는 입장에서 아쉽기만 하다.

그리고 Project의 Leader로써 또하나 아쉬운 점은 인재관리 분야이다.
일전에도 밝힌바와 같이 조직의 관성때문에 피해를 많이 본 인재들이 몇몇 있다.
그중에 한분이 조금 걱정되었는데 요즘은 다시 의욕을 회복하는 중이라 나름대로의 보람을 찾기도 한다.

그래도 저래도 요즘 가장 기쁜일은 팀원들에게 "집에 안가?"를 입에 달고 다닐수 있는 행복함이다.
6시부터 시작되는 Leader의 잔소리(?)에 팀원들은 못내 싫은 표정이지만 그리 싫지만은 않은듯 하고~
일끝내고 일찍가는 팀원들을 바라볼때 무엇인가 잘 돌아간다는 느낌도 괜찮다.


마지막으로 한때는 군인이었고 지금은 국민이 된 시민으로써 금번 천안함 사건의 희생자 46명의 충혼들께 평안한 영면 하시라는 마음을 받침니다.

 

"훌륭한 감독은 기본 규칙에 대해 알고 있다.
또한 대부분의 감독은 그 기본을 열심히 찾는다.
그러나 규칙을 따른다고 해서 영화가 잘 된다는 보장은 없다.
그렇게만 되면 일이 너무 쉬워진다."
-Ethan Coen, 거장의 노트를 훔치다-

위의 문구는 작년 이었나? District9 이라는 영화 후기로 올라온 딴지일보의 기사중 일부였다.
http://www.ddanzi.com/news/6206.html

이런 화두부터 던지는 이유는 간단하다.
프로젝트를 성공으로 이끄는 것은 PM의 Role이며 PM은 영화감독과 같은 위치에 있는 직책이다.
영화감독이 각종 투자를 받아서 영화를 찍고 그것을 고객에게 팔아 돈을 벌어서 투자자에게 배당하듯이 프로젝트 PM도 고객사의 돈과 지원으로 업무 효율화 또는 신규사업에 사용될 어플리케이션을 만들고 이를 통해 Value를 투자자인 고객에게 돌려준다.

PM은 먼저 고객을 만들어야 하고 자신과 Vision을 같이할 조직도 구성해야 한다.
그리고 그 조직의 칼날이 무뎌지지 않도록 갈고 딱도록 해야 한다.
따라서, PM은 첫째, 의사소통에 문제가 없어야 하고 둘째, 도메인 전반에 대한 지식이 있어야 하며 셋째, 리더쉽이 있어야 하고 넷째, 팀원들을 몰아 붙일때는 몰아 붙이고 쉬게 할때는 푹 쉬게 할줄알아야 하며 다섯째, 다른 팀원들보다 통찰력이 뛰어나야하며 여섯째, 계획과 실행에 능해야 한다.

다른 도메인으로 넘어가면 군의 장교들이 이런 자질이 필요하다.
그런데 문제는 이렇게 막중한 역할을 담당하는 PM은 어떻게 양성되고 있는가?를 짚어 봐야 하지 않을까?
우리 도메인의 현실은 시궁창에 가까운데 개발자가 어느정도 나이가 들면 아무런 지식없이 PM이 되어버리는 현실때문이다.

한국사회의 병폐인 짬밥으로 밀어 붙이니 이런 문제가 발생한다.
- 나는 너희때 그러했는데 너넨 왜 그러냐?
  ex)자신이 팀원으로 일할때는 밤새는것을 밥먹듯이 했다.
- 시키면 시키고 까라면 까라
- 개발은 니가 하지만 정치는 내가한다.
- 술사주면 만사 OK아닌가?
- 배째라. 등등등

우리 개발자들이 흔히 겪고 있고 나 스스로도 아니라고는 말을 못하는 행동들이다.

우리의 교주이신 김창준님(http://agile.egloos.com/)께서 최근에 발표한 자료를 보다가 문득 이런 생각이 들었다.
김창준님께서 애자일이든 정보공학이든 수없이 현장에서 반복되는 업무들을 분류하시고 성공적인 프로젝트에 필요한 몇가지 수행 방법을 도출하셨는데 요약하면 다음과 같다.

- 고객참여  (성공지수 0.77)
- 리팩토링 (성공지수 0.42)
- 자동화테스트 (성공지수 0.38)
- 코드공유 (성공지수 0.37)
* 1점이 최고점이므로 고객참여의 중요성을 알 수 있다.

그리고 조직의 애자일 성숙도가 4이하(최고 5)인 조직 (SI업에서는 항상 4이하일수 밖에 없겠지요?)에서는 고객참여가 0.94로 최고점에 가까웠다.

그에 비해 애자일 성숙도 4이상인 조직은
- 짧은 개발주기 (성공지수 0.49)
- 고객참여 (성공지수 0.36)
- 코드공유 (성공지수 0.33)
등으로 성숙도가 낮은 조직일 수록 고객 참여를 가장 중요하게 생각해야 하며 고객의 참여는 다양한 형태로 받아 들여야 한다는 지표이다.

마지막으로 김창준님의 연구결과를 공유 한다.