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

결국 애자일이 됐던 뭐가 됐던 계획을 수립하고 추진하고 점검하고 변경하는 일처리 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)
2010/07/19 21:44 2010/07/19 21:44

트랙백 주소 :: 이 글에는 트랙백을 보낼 수 없습니다