The Goal (더 골) - [12/50-2007]

이제 몇 시간만 있으면 한국으로 돌아가는 비행기 안에 있겠군요.

긴 출장동안, 생각보다 책도 많이 못읽고, 운동도 많이 못하고, 영어도 많이 안늘었지만, 그래도 몇가지 화두를 얻을 수 있었던 것 같습니다.

그중에 가장 큰 것은 Fearless change가 아닌가 합니다. 대부분의 사람들은 변화를 좋아하지 않고, 그게 더욱이 외부로 부터의 요구라면 심리적으로 강한 거부를 하는 것 같습니다. 변화의 목적이나 방향보다는 변화자체에 대한 거부가 생기는 것이죠. 따라서 변화라는 말보다는 끊임없는 개선, 다양한 시도라는 말과 느낌으로 변화의 에너지를 유지 하는 요령을 더 익혀야 한다는 생각이 들었습니다.

물론 변화가 새로운 문제를 야기할 수도 있고 해결안이 안될 가능성도 있겠지만, 기존에 있던 것을 부정하는 것이 변화의 목적이 아니고 앞으로 더 나아가는게 목적이므로, 더더욱 해결안 중심 접근법으로 시도가 되어야 하는게 아닌가 합니다.

---

The Goal (더 골) 엘리 골드렛 외 지음, 김일운 외 옮김/동양문고

이 책은 400 페이지가 넘는 두꺼운 책임에도, 추리소설처럼 막힘없이 읽히게 됩니다. 제약이론(TOC, Theory of Constraint)을 어느 한 공장의 사례를 빌어서 아주 재미있게 풀어 놓았습니다. 팀 혹은 조직의 생산성이 가장 병목이 되는 자원의 생산성과 같다는 내용입니다.

무인도에 남자가 10명이 있고 여자가 1명이 있으면 남자 10명이 아무리 노력해도 1년에 아이는 많아야 한명 밖에 안태어 나는 경우와 비슷하다고 할 수 있습니다.

소프트웨어도 비슷하게 한쪽에서는 library 를 만들고, 한쪽에서는 application 을 만든다고 하여도 결국 병목이 되는 자원의 생산량이 최종 생산량이 되겠죠. library 가 빠르면 application 이 손가락을 물고 있을테고, 그 반대면 library 가 놀거나 쓸지말지도 모를 library 가 늘어날지도 모릅니다.

그래서 가장 병목이 되는 자원 해소에 노력을 기울이면 생산성이 높아지게 될 것입니다.

사실 말처럼 단순한 것도 아니고, 단순히 병목만 해결하려 들면 병목이 해결되는게 아니라 옮겨다니는 결과를 가져오게 되고, 그러한 경우들이 책에 실감나게 서술되어 있습니다. 책의 사례는 사람, 재고, 기계등의 전통(?)적인 요소들 사이에서 제약을 해결하는 과정이 있지만, 소프트웨어는 어떻게 보면 좀더 사람들 간의 병목이 더 큰 것 같습니다.

그렇다고 단순히 library 만들던 사람을 application 을 시킨다고 상황이 좋아지거나 할 것 같지는 않습니다.

---

그래서 두번째는 화두는 Whole Team 입니다. Whole Team 이 소프트웨어에 개발에 존재하는 많은 병목들을 해소하지 않을까 라고 개인적으로 생각을 합니다. 병목이 최종 생산품의 속도를 좌우하고, 결국 중요한 것이 최종 생산품의 속도와 품질이라면, 업무가 어느정도 분화가 되어 있더라도 프로젝트의 구성원 모두가, 자신의 모듈의 완료 뿐만 아니라, End-to-End 의 개발에 처음부터 끝까지 긴밀하게 관여하여야 하지 않는가 하는 거죠.

하지만 각자가 맡은 개별 모듈에만 집중하고, 최종 생산물에 대한 관여도가 낮다면, 병목이 유령처럼 떠돌아 다니게 되는 것 같습니다. 디자이너가 갑자기 코드를 짜듯, 누구나 무엇이든 하라는게 아니라, 누구나 최종생산물을 같이 계속 보고 있어야 하는게 아닌가 합니다.

하지만 A 작업이 끝나면 그걸 받아서 B가 하고, 그게 끝나면 C가 그 결과를 받아서 하고, A는 B 하고만 이야기 하고, B는 C하고만 이야기 하고.. 이런게 각각의 전문성을 살리고, 견고한 시스템이 나온다고 생각한다면 속도는 포기할 수 밖에 없는게 아닌가 합니다.

하지만 신뢰와 거침없는 변경을 가할 수 있는 시스템이 먼저 있어야 가능한, 더군다나 일하는 시간조차 전혀 겹치지 않는 먼나라와의 협업은 역시나 쉽지 않은 문제 인것 같습니다.