인간이 활동하면서 잠이란 존재는 불가결한 요소인듯 하다.
아무래도 뇌가 잠을 자는 동안 재정렬 및 리셋하는것이 아닐까라는 생각이 든다. (그냥 개인적인 가설...)
기사 발췌 부분을 보도록 하자.

"웬만한 운동보다 효과적"…美기업들 '수면실' 잇단 도입

아이작 뉴턴은 낮잠을 자다 만유인력의 법칙을 발견했고,나폴레옹은 매일 낮잠을 자면서 전투 계획을 세웠다. 토머스 에디슨,윈스턴 처칠도 매일 낮잠을 즐겼던 것으로 유명하다.

비즈니스위크는 30일 "갈수록 많은 기업이 직원들에게 낮잠을 권하고 있다"며 "생산성 감소로 인해 매년 수십억달러의 손실을 입기보다는 차라리 업무시간이 줄어드는 것을 택한 것"이라고 보도했다.

세계적인 스포츠 용품업체 나이키는 피트니스클럽,모유 수유실,탁아실에 이어 사내에 '콰이어트 룸'을 만들어 직원들이 낮잠을 자도록 한다. 구글은 근무시간의 20%를 낮잠 시간으로 지정해 따로 마련된 수면실에서 휴식을 취할 수 있도록 했다. 아이스크림 업체 벤앤드제리스도 최근 직원들에게 낮잠을 자도록 권장하기 시작했다. 미국의 모바일 기술업체 자와의 멜리사 기어자이너 대변인은 "최근 2개의 수면실을 만든 후 프로그래머들의 업무 효율이 몰라보게 향상됐다"며 "만약 하루에 16시간 이상 일하는 직원을 데리고 있는 회사라면 반드시 그들에게 낮잠을 자도록 해야 한다"고 말했다.

= 중략 =

펜실베이니아 의과대 연구 결과에 따르면 짧은 수면은 경각심,기억력,운동기능,의사결정 능력을 향상시키는 것으로 나타났다.

이유정 기자 yjlee@hankyung.com

놀랍다.
산업화 이후 인간의 활동을 기계에 맞춰왔었는데 그것을 다시 본래대로 회귀시키는 노력이 있는 듯하다.
진정 졸릴때 짧게라도 잠을 자고 일어나고 일어났을때 머리가 맑아 지는 기분은 과학적 증거가 바탕이 되는듯 하다는 생각이 든다.

지난번 까지 애자일의 추진=회고라고 이야기했었다.
* 마루날님의 사이냅소프트 방문기도 있으니 참고 하여 주기 바랍니다.
http://ithelink.net/501

그런데 회고는 왜 하는 것일까?
아니 바꾸어 이야기 해서 회고는 무엇을 위해 존재하는가?

이하는 개인적인 생각이다.
첫번째, 커뮤니케이션 만족도를 높여 궁극적으로 구성원의 만족도를 높이기 위함이다.
업무량이 같다는 전제로 연봉 많이 주는 회사와 커뮤니케이션 만족도가 높은 회사가 있다면 어떤 회사를 택할 것인가?
당연히 커뮤니케이션 만족도가 높은 회사를 선택할 것이다.
대기업이란 곳이 연봉이 많고 많이 쉬는 회사라고 착각하기 쉬운데... 절대 아니다. 커뮤니케이션 만족도는 10점 중에 약 6점 정도 된다.
위로 건의를 하여도 10번 건의하면 1~2번 혹은 아주 먹히지 않는 곳이 대기업이며
아래로는 강력한 압박과 성과를 강조하는 곳이 대기업이다.
그러나 이것이 비단 대기업만의 문제일까?
단지 본인이 어떻게 보면 대기업에 다니고 있는 이유는 아직까지 커뮤니케이션 만족도가 지금 다니고 있는 회사보다 좋은 곳을 못보았기 때문이다.
(최소한 옳은 일에 바락바락 대들어도 뒷끝이 없으니까...)

둘째로는 철저한 자기반성과 개선을 시도하고 도전해 보기 위함이다.
신도 실수로 만든것이 인간인데 한낱 인간이 스스로 완벽하다고 할 수 있을까?
수행한 업무의 복기와 실패의 원인을 찾고 또한 잘되는 원인을 찾아 잘되는 것은 더 잘되도록 하고 실패는 교정할 수 있도록 하기 위해 모든 것을 거는 것이다.

셋째로는 교육이다.
둘째 목적과 상통하는 부분으로 교육은 인위적으로 이루어 질 수 없다.
가장 강력한 Face to Face 교육법이라고 해도 단순한 지식의 전수만으로는 교육의 목적을 100% 만족하기 어렵다. 해봐야 한다. 해보고 반성하고 다시 해보는 것이 가장 훌륭한 교육방법이다.
예를 들면 군사교육이 그러하다.
실재 군경력자들이 경험하는 것으로 수십번 수백번의 같은 동작을 통해 뼈속 깊이 교육의 내용을 숙달한다.

즉, 프로젝트에서의 회고는 그간의 성과를 검토하고 미진한 부분을 복기함으로써 다음을 준비하는 과정이라 할 수 있다.

그렇다면 회고는 어떻게 해야 하는가?
회고 역시 일종의 브레인스토밍이다.
단, 익명성이 보장되는 것이 최고의 방법이다. 실명이 거론되면 실패한 부분, 지적당할 부분을 숨기는 것이 인간의 본성이기 때문이다.

따라서, 회고하기위해 Wiki 또는 Ticket System을 통해 익명계정을 만들어 iteration 종료와 시작전 (Iteration 사이에..) 모든 팀원들이 익명계정으로 다음의 3가지 의견을 취합하는 것이 중요하다.

첫째, "잘된점"이다.
업무를 추진하면서 혹은 대인관계 더해서 모든 생활에서 스스로 만족도가 높았던 부분을 하나씩 정리해 본다.

둘째, "잘못된점"이다.
위와  마찬가지로 불만족 스럽거나 개선해야 한다고 생각하는 것들을 써내려간다.

셋째, "새로 깨달은 것"이다.
일을 하다보면 "아하!"하며 무릎이나 이마를 탁 치는 경우가 있을 것이다. 이런 것들을 써놓는다.

우리 프로젝트에서 조금 각색하여 정리한 것이 바로 이런 것이다.
1. 잘된점
   - OO기능 조기 완성
   - 일일 미팅
   - 고객 관리
2. 잘못된점
   - UNIT TEST CODE 적용
   - 버그 수정후 새로운 버그 파생현상
   - PM 권한 집중
3. 새로운점
   - 고객 Feedback 접수 방식

이것으로 끝이 나면 재미도 없고 그냥 Paper작업 한것 뿐이다.
이런 취합을 몇 시간정도 받고 나서 즉시 시행하는 것이 성과평가회의 또는 회고를 회의형식을 통해 진행한다.
팀원의 수가 얼마안되면 그냥 차한잔하면서 복기 할 수도 있다.
팀원의 수가 많다면 조를 나누고 각각의 ITEM별로 Mindmap을 그려갈 수 있다.

여기서 중요한것은 각각의 원인을 파악하는 것이다.
누구때문이다라는 이야기가 가장 많을 수 있으며 스스로 그 원인을 제공했다는데에 죄책감을 느낄수도 있다.
따라서, 그 누구는 철저히 나오지 않도록 팀원들에게 요청하고 사건 즉, FACT를 논하도록 한다.

Ticket System을 이용한다면 정확하게 그 FACT를 파악할 수도 있다.

이렇게 파악된 원인에 대해 개선 담당자와 확산 담당자를 지정하고 다음과 같은 권한을 준다.
첫째, 팀원소집권한 : 필요하다면 모든 팀원을 호출하여 회의를 개회할 수 있는 권한
둘째, 비용사용권한 : 필요하다면 담당자가 식사와 술을 계정 한도 내에서 사용할 수 있는 권한
셋째, 보고받을권한 : 담당자에게 각각의 실무자가 어떻게 일이 진행되고있는지 보고 받을 수 있는 권한

그리고 각각의 담당자를 지속적으로 모니터링하고 담당자와 자주 보고하는 실무자 역시 모니터링 한다.
이렇게 사람에 대한 관심을 계속 쏟는 것이 회고이자 근본적으로 복기의 과정이다.

XPER에서 팀내 교육에 관련한 포스트가 있어 조금 구태의연한 방식을 올렸었는데..
http://groups.google.com/group/xper/bro ··· 14f0533d

김창준님께서 답변 달아 주신것을 조금 정리하여 보았다.

먼저 기존방식.
2가지 방식이 있다. 하나는 PL급을 모아서 전파 교육을 하는 방식으로 ptototype을 만들면서 같이 애자일 프래틱스를 하나씩 적용해가며 튜닝하는 방식과 또 하나는 별도의 교육없이 전체에게 어떤 프래틱스를 쓰라고 공지하는 대신 프로젝트 Iteration 별로 단계별로 교육하는 방식이다.

여기에 김창준님께서 권해주신 방법은 이러하다.

쉽지 않은 일을 하시네요. 저는 다음 방안을 권해드리고 싶습니다.

일종의 애자일 프로젝트 식으로 교육을 진행하는 방법입니다.
최초 소규모 그룹을 선정합니다(두가지 전략이 가능한데, 하고 싶어하는 사람들로 하는 방안, 최대한 다양한 샘플링을 하는 방안이 있습니다). 그 그룹과 실험적으로 (기간도 압축해서 -- 예컨대 하루나 반나절) 교육을 진행합니다. 단, 교육을 하기 전에 다음 세 가지는 미리 고민을 해둬야 합니다.

1. 교육이 효과(여러 레벨에서 말할 수 있는데 다음 순서를 참고로 하세요: 만족하는가, 잘 이해하는가, 그렇게 행동하는가, 그래서 성과가 있는가)가 있는지 없는지, 그리고 왜 그런지를 모니터링 할 수 있는 방법
2. 잘 될 때 이걸 어떤 식으로 증폭시킬지에 대한 전략
3. 잘 안될 때 부정적 효과를 어떻게 감소시킬지에 대한 전략

그리고 교육이 끝나면 피교육자들과 함께 고민을 하면서 어떻게 이걸 나머지 인원에게 효과적으로 전파, 발전시킬지 "함께" 의논하고 액션 플랜을 만듭니다. 그리고 주기적으로 이런 과정에 참여하고 싶은 사람을 뽑습니다.

그 다음 릴리즈 2를 계획합니다. 조금 더 사이즈를 늘린 실험을 하는 것이죠.

대략 세 번 정도 릴리즈 하면 이 조직 문화에서, 이런 사람들을 대상으로 어떤 방식의, 어떤 내용의 교육이 효과적일지 윤곽이 드러나지
않을까 생각이 들고요, 또 이 과정에서 동지들을 얻어서 전파도 더 쉬워지지 않을까 합니다.

마지막 팁으로, 이런 과정에 함께 하는 동지들(위원회라고 해도 될 듯)과 함께, 필수, 가능한한, 옵션 사항들을 정하면 좋을 것 같습니다.

필수는 이 부분은 무슨 일이 있어도 지켜야 한다는 겁니다. HOW보다는 WHAT을 정하는 것이 좋습니다. 그리고 HOW는 각자 선호도에
따라 알아서 하도록.  그리고 왜 이것이 필요한지, 중요한지, 잘 안지켜지면 어떤 impact가 있는지를 분명히 밝혀야 합니다.

가능한한은 가급적 이 부분을 노력해 달라는 것인데, 좋기는 하지만 정 사정이 안되면 잘 못해도 괜찮다는 것입니다.

마지막 옵션 사항은 다음과 같은 옵션들이 있는데 결정은 당신들의 선택이다라고 하는 겁니다.

이런식으로 개인별(혹은 소규모 그룹별) 어느 정도의 자유도와 동시에 책임/의무를 함께 보여주는 것이 효과적인 것 같습니다.

정리요약하면 이러하다.
먼저 계획을 수립한다. 계획 수립에는 3가지 측면에서 고민한다.
1. 교육의 효과를 측정하는 방법
2. 교육의 효과가 좋을 때의 증폭방법
3. 교육의 효과가 나쁠 때의 감소방법
그리고 또하나 유념해야 할 것은 교육 내용을 무엇(What)으로 채우자.(기존의 어떻게(how)에 비해 효과적일 것이라 생각됨)
그리고 교육 아이템을 필수, 가능한, 옵션 3단계로 설정하여 필수적인 것은 반드시 해야 하는 프래틱스, 가능한은 상황이 가능하다면 해야 하는 프래틱스, 옵션은 해도 안해도 무방한 것들로 채운다.

이제 교육대상을 추린다. 방법은 2가지이다. 지원자 또는 무작위 샘플링이다. 아무래도 대한민국의 특성이 반영된 듯 싶지만... 개인적인 생각으로는 한국과 같은 상황을 반영하려면 다른 사람에게 영향력을 미치는 키맨을 찾아야 될 듯 싶다.

샘플링이 끝나면 Quick하게 반나절 교육을 실시한다.
교육이후에 피교육자들과 토론을 거쳐 전파 시킬 방법을 찾고 액션플랜을 세운후에 담당자를 지정한다.

이렇게 iteration 1이 완료되면 교육 범위를 확대하여 (여기서 조금 정리가 안되는 것이 교육 과제 확대일까? 대상의 확대일까?) iteration2를 진행하고 iteration1을 반복한다. iteration2 종료후에는 iteration3을 진행한다.

여기서 하나더 나아간다면 Keyman을 찾는 방법이다.
Keyman이란 직급과 나이를 떠나 팀내에서 영향력을 많이 주는 요원인데 이를 찾는 방법은 이전에 포스팅한 것을 참조하자.
http://www.wolfpack.pe.kr/487

영향력과 관심도 2개의 축으로 개개인별로 분석하면 어느정도 영향력이 있는 요원들을 따로 선별할 수 있으리라 생각된다. (나름 응용이랄까... ^^;;)

하나더 이야기 하고 싶은 것은 나이를 먹다보니 인문학의 중요성이 더 커지는 것 같다.
어릴때는 기술지상주의였는데 리더의 위치로 다가갈 수록 철학과 심리에 대해 공부하지 않으면 안되는 느낌이다.

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

결국 애자일이 됐던 뭐가 됐던 계획을 수립하고 추진하고 점검하고 변경하는 일처리 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부는 다음으로 =

이사하느라 네트워크 연결이 안됐습니다.
회사에서 짬날때 쓰느라 아껴 두기도 했구요.
교재를 오늘 가져와서 기억을 더듬으며 2일차에 대한 회고를 기록해둡니다.

먼저 SI 프로젝트에서의 주요 협상시점입니다.
(1일차 교육에서 다르게 기록됐던 부분이기도 합니다.)

우선협상단계 : 갑의 관심은 "가격협상", "요구사항 변경 불가 가능성에 대한 불안"
착수단계 : 갑의 관심은 "낯선 인력과의 첫 대면", "성공에 대한 불안"
요구사항단계 : 갑의 관심은 "요구사항 누락가능성", "프로젝트 팀의 성실성"
설계단계 : 갑의 관심은 "진척현황", "요구사항 반영여부", "요구사항 추가 수용 여부"
개발단계 : 갑의 관심은 "UI불만", "기능누락 및 변경", "추가 요구사항 수용 여부"
완료단계 : 갑의 관심은 "안정성 불안", "산출물 및 인수인계 불안", "운영 및 유지보수"

입니다. 개발단계에서 요구사항에 대한 이슈는 꾸준히 제기된다는 객관적 자료여서 기록으로 남겨 두고 싶었습니다.

그리고 협상의 자질에 대한 이야기가 나왔는데...
1. 설득능력
2. 듣는기술
3. 현안에 대한 지식
4. 계획과 준비능력
5. 감정 통제 능력
이상 5가지가 협상가에게 가장 필요한 능력 Top 5로 선별되었습니다.

이해관계자에 대한 분석도 재미 있었습니다. 협상테이블에 앉기전에 이해관계자를 분석하고 이를 대응하는 전술을 수립하는 게임을 하였습니다.

이해관계자 A, B, C가 있다고 하면 먼저 프로젝트에 대한 관심도와 영향력을 분석합니다.
그리고 이를 PI Chart라는 것으로 옮깁니다.

영역 1은 프로젝트의 관심이 많고 영향력이 높은 사람 ==> 밀착해서 같이 참여시켜서 일을 한다.
영역 2는 프로젝트에 관심 없고 영향력이 높은 사람 ==> 안심시키기위해 납득과 만족 활동을 수행한다.
영역 3은 프로젝트에 관심이 많지만 영향력이 낮은 사람 ==> 정보를 계속 제공하는 등의 활동을 수행한다.
영역 4는 프로젝트에 관심 없고 영향력도 낮은 사람 ==> 모니터링한다.
와 같이 4개 군을 분류하고 대응전략을 수립합니다.

특히 영역 2에 있는 사람들의 경우는 Care Program등을 가동하고 종국에는 "1"과 "2", "3"의 영역에 있는 고객을 자신의 편으로 만드는 것이 본 과정의 목적이었습니다.

그리고 특이한 기억중 하나는 이상적인 PM의 특징입니다.
지금까지의 PM론은 "기술전문가"와 "방법론전문가"를 강조하였는데 교육과정에서 PM은
- 기술전문가
- 심리전문가
- 영업전문가
- 엔터테인먼트전문가
등 4개의 요소를 모두 융합한것이 이상적인 PM이라고 정의합니다.
(OTL.. 나는 PM이 아니었다...)

또 재미 있는 것은 제갈량의 협상전략 사례였습니다.
유비군이 조조에게 대패하여 패주할때 제갈량의 삼분지계의 기회는 상실되는듯 했습니다만. 제갈량은 손권을 설득하기로 하고 손권을 만나러 갑니다.
그러나 손권을 바로 만나지 않고 오의 문무대신들을 만나 손권과 세력구도에 대한 정보를 획득합니다.
손권이 자존심이 매우 센사람이고 주유의 말에는 꿈뻑 죽는다는 것을 알아내고는 손권을 만나서
"싸우던가 아니라면 꼴리시면 뒤지시던가"라며 손권의 자존심을 긁어버립니다.
손권은 화가나서 "그럼 왜 유비는 항복안해? (속으로 ㅅㅂㄻ)" 이에 제갈량은 "항복해서 조조넘 돠주는 꼬라지는 못보겠고 대의를 따르련다"하니 손권은 유비와 비교당하는것이 못내 아쉬워했고 형님인 손책의 유어에 따라 내사엔 장소, 외사엔 주유라며 주유를 만나라 한다.
이때 제갈량은 주유를 만나 조조의 침공목적이 대교와 소교라고 이야기하여 주유를 열받게 한다. 주유의 마눌님이 소교니 어찌 안싸울수 있겠는가?
이리하여 손권과 조조를 싸움 붙여 놓는다는 협상사례였다.
여기서 하나 재미 있는 것이 SOWT 분석표이다. (이런곳에 사용될 줄이야)

먼저 Strengths, Weaknesses, Opportunities, Thrests 4가지 요소를 써넣는다.
(위에서는 내부, 외부 및 이로운, 해로운 등 각 상황별 구분이 있지만 일단 다 무시하고 SWOT에 집중하자.)
당시의 제갈량이 속한 유비군의 상황을 예로 든것이 흥미로웠다.
(기억이 안나니 그냥 한번 써보자)
1. 만나기전
강점 : 대의 명분은 유비에게 있다.
약점 : 군사력이 미약하고 거점이 없다.
기회 : 조조가 오로 진격중이다.
위협 : 시간이 매우 부족하고 손권이 기권하면 이제 끝이다.
4가지 상황중 기회요소에 집중 둘을 싸움 붙일 전략을 수립한다.

2. 손권을 만나서는
강점 : 대의 명분은 유비에게 있다.
약점 : 군사력이 미약하고 거점이 없다.
기회 : 조조가 오로 진격중이다. 손권은 주유말이라면 죽는다. 손권의 자존심이 쎄다.
위협 : 문신들의 반대가 매우 심하다.
여기서도 4가지 상황중 기회요소에 집중한다.

3. 주유를 만나서는
강점 : 일단 손권을 설득했다.
약점 : 군사력이 미약하고 거점이 없다.
기회 : 조조가 오로 진격중이다. 조조가 대교와 소교가 탐이 나서 달려온다.
위협 : 주유는 자신을 제거하려 한다.
여기서도 제갈량은 4가지 요소중 기회에 집중하였다.

그 이후에 교육마지막 시간에는 불려나가서 고객과 협상하는 PM의 역할을 했었는데... 헐...
다들 아카데미 남우 주연상을 줘야 할듯 할 정도로 "갑"의 역할에 열성이다.
맨날 당하기만 했던지 그 내공이 장난이 아닌듯...

아무튼 유익한 교육이었다. 다른 분들도 기회가 되시면 받아 보시길...

오늘부터 내일까지 그동안 받고 싶었던 교육중 하나인 고객관계관리 과정에 입교했습니다.
한편으로는 명확한 권리 위임이 없었다면 힘든 일이었을테고 고객측에서도 크게 크레임 걸만한 일이지만 팀원들도 고객측에서도 그동안 고생했으니 다녀오라는 분위기여서 다행히 교육 잘 받고 있습니다.

몇가지 저의 생각과 강사님의 생각이 다른 부분이 있었습니다.
아마도 강사님의 생각이 더 맞을 것 같다는 느낌을 받았는데...

첫째, 문제를 정의하는 방법이 달랐습니다.
저는 문제를 인식하는 수준과 원하는 수준과의 차이라고 생각합니다만 (물론 제 개인 생각이 아니라 제럴드 와인버그님의 생각입니다.)
교육과정에서는 협상이 필요한 것이라고 정의합니다.
그러나 생각해보면 둘이 그리 크게 벗어나는 부분이 아니었습니다.

둘째, 고객의 걱정에 대한 것이었습니다.
제안단계부터 우선협상단계에서는 고객은 가격과 일정이 최우선 관심사였고 그리고 첫대면으로 서먹서먹한 부분이 고객입장에서는 제일 걸리는 부분이었습니다.
그리고 요구사항분석 단계에서는 이것들이 일을 열심히 잘하는지에 대한 성실성이 최우선 관심사이며 요구사항이 빠지지 않을까 하는 고민이 있었습니다.
설계단계에서는 고객은 향후 설계 변경이 되지 않을까 노심초사합니다.
개발단계에서 고객은 제대로 개발되고 있는지가 궁금해 합니다.
테스트 단계에서는 어쭈~로 갑니다. 어쭈~ 이것들 봐라?와 어쭈~ 제법인데로 나뉩니다.
종료단계에서는 인수인계와 향후 유지보수가 최대 관심사항이었습니다.

Role Plating game을 하면서 처음으로 현업의 입장도 되어 보았고 갑의 입장도 되어 봤습니다.
카메라가 옆에서 돌아가면서 각각의 협상의 단계를 체험했습니다.

재미 있었던 것은 농담 따먹다가도 Role Playing Game에 들어가자 각자의 역할에 충실한 팀원들의 모습이었습니다.

주어진 과제에 너무 충실해서 나는 갑만 할거야 하시는 분도 있었는데 (갑이 평생 소원이시라능...)
부장님과 차장님과의 언쟁, 분노, 좌절, 희망을 모두 겪었습니다.

그리고 상대방을 점수를 냅니다. 내점수와 상대방 점수를 내서는 통보합니다. 너의 협상 점수는 몇점이다라고...
서로 무안해지기는 하지만 스스로의 모습을 돌아볼 수 있어서 좋았습니다.

내일까지 실습인데... 솔찍히 저의 협상 스킬이 부족한지라... 특히 감정 콘트롤이... 많이 힘들기도 했습니다.

그럼에도 협상의 ABC는 배운듯 하군요.

협상 시작전에 "명확한 주제에 대해 협상 전략을 준비하고 주고 받을 것을 정하는것"
협상 시작과 동시에 "분위기를 긍정적으로 일단 끌고 가는것"
협상이 중반쯤 다다르면 "상대방의 의지를 시험하고 성향을 파악하는것"
최종 "협상이 종료되면 누구나 알아 듣고 해석의 오류가 없도록 정리하는것"

또한 세세한 협상의 제스췌를 읽는 법, 상대방의 표정과 억양을 읽는것 그리고 그 속에 숨겨진 의도를 읽는 법도 배운 하루였습니다.
ㅋㅋㅋㅋ 행복해 T_T