더골(THE GOAL)

감상

2010-03-20

병목의 원인을 파악하지 못한다면, 다른 효율성 높은 공정도 재고 비용만을 증가시킨다. 제조업 공장에서 생산성 향상에 대한 통찰과 교훈을 얻고자 한다면 진짜 공장을 경험하고, 고민하는 사람들의 이야기를 들어 보아야 한다. 다시 생각해도 이 책은 명저..

2009-12-23

‘성냥개비 나르기’게임을 다시 보려고 몇 년 만에 책을 펼쳤다. 눈에 확 들어오는 핵심단어는 ‘확률적 분포’와 ‘종속적 사건’… 우리가 겪는 많은 문제는 결국 의존 관계에 따른 불확실성이구나 싶었다. 모듈 간이든, 시스템 간이든, 사람 간이든, 프로세스 간이든.

2005년

제프 콕스 저, 김일운 역, 동양문고

회사 소모임의 워크샵에서 이 책을 주제로 한 발표가 있었습니다. 그 때 생각난 내용을 나중에 회사 커뮤니티 게시판에 적었는데, 그 내용의 일부를 옮겨써봅니다.

사촌형이 이 책을 낸 출판사에 일하고 있었습니다. 몇 년 전 그 형네 집에 놀러 갔을때 제가 꼭 읽어야 할 것이라면서 책을 공짜로 주었습니다. 대충 책장을 넘겨 보니 공장에 대한 이야기라서 서비스업에 종사하는 저로써는 별 상관없는 내용으로만 보였습니다. 그래서 한동안 책장에 꽂아만 두었습니다. 한참 뒤에 잡지나 블로그 등을 통해 이 책으로 개발자가 읽어야할 권장된다는 것을 알게되어서 다시 찾게 보게 되었습니다.

이 소설은 공장의 문제를 해결하는 공장자의 이야기입니다. 문제의 공장이 잘 돌아가지 않았던 이유는 공정마다의 “부분적인” 생산성에만 작업자의 목표가 맞춰져 있었기 때문이라고 정리하고 싶습니다. “부분 최적화는 전체 최적화를 보장하지 않는다"는 격언을 학교 다닐때 들었는데, 그 예가 이 소설 속에 나옵니다.

공장에서 도입한 자동 로봇은 자랑거리였고 많은 중간 부품을 생산했지만 그 부품의 재고만 더 쌓이게 만들어서 오히려 공장에 손해를 끼쳤다는 내용이 있습니다. 그 로봇이 있는 공정에서는 부품의 생산양만 보고 높은 성과를 이루고 있다고 생각했을 법도 합니다.

모두들 열심히 일하고 로봇도 쉬지 않고 있는 공장이 고객이 주문하는 생산량을 못 맞추자 공장장은 대학 때 교수로 부터 자문을 받아서 이를 해결해 나가기 시작합니다. 그 방법의 예는 아래와 같았습니다.

1. 병목이 일어나는 공정에 대해서 외주를 주거나 동원가능한 다른 기계를 이용해서 지원작업을 한다.
2. 우선 순위가 급한 부품을 다른 표시를 해서 그 부품이 해당 공정에 들어왔을때는 가장 먼저 작업을 한다.

위에 로봇의 경우와는 반대로 최적화된 한 번의 작업량 (예를 들면 붕어빵틀에 모든 구멍에 밀가루를 채우는 것 같이 해당공정의 효율이 극대화 되는 한번의 양)을 포기했을 때 오히려 공장의 전체 생산성이 더 좋아졌습니다.“재고는 자산이 아닌 비용이다"라는 개념도 기존 통념을 뒤엎는 것이였습니다.

전에는 이 책을 다 읽고 나서도 “그래도 나와는 큰 관련 없는 공장이야기군"하고 생각을 했었는데, 최근에 들어서야 IT업과 연관성을 생각해보게 되었습니다.

개발 프로젝트를 하면서 제가 경험한 일정관리는 프로그램의 목록을 엑셀 시트나 이슈 트래거에 나열해 놓고 그중에 몇개를 완성했느냐, 그것이 전체의 몇%냐로 평가를 받는 것이였습니다. 그 갯수가 적으면 다른 사람보다 생산성이 적은 것이 되고, 계획했던 갯수보다 적으면 일정을 못 맞춘것이 되는것이였습니다. 여기서 개발자가 충족해야할 목표는 그 갯수를 늘이는 것인데, 그러다보니 쉬운 프로그램, 고객이 별로 신경쓰지 않는 프로그램을 먼저 구현을 하게 되는 경향이 생기기 쉬워집니다. 그러다보면 오히려 많이 쓰이고 고객이 민감해 하는 프로그램은 나중에 급하게 졸속으로 구현되는 경우도 봤습니다. 이는 개발자가 평가받는 부분 목표(프로그램 갯수)와 프로젝트 성공의 목표(고객의 필요한 프로그램이 잘 돌아가서 검수를 받는 것)이 상충되는 상황입니다. ‘익스트림 프로그래밍’ 책에서도 비슷한 이야기를 봤습니다. 고객이 가장 우선시 하는 기능부터 구현하고 고객에게 피드백을 받고 다음 스토리로 넘어가야한다는 내용으로 기억합니다.

그리고 프로젝트에서 “고객검토"가 병목인 경우가 많다는 생각도 듭니다. 한참동안 피드백이 없다가 프로잭트 종료시점에서야 요구사항을 쏟아내는 고객의 경험을 다른 분들도 겪었을듯 합니다. 병목을 보강하듯히 업무별 고객담당자를 적절히 분할해서 지정하거나 개발팀 쪽에서도 고객검토을 촉진시킬수 있는 담당자를 두는 해결 방안이 떠오릅니다.

혼자서 이 책이 공장의 이야기인데도 개발자들사이에 많이 권해지는 이유를 연결시켜서 생각해봤는데, 그 외에도 연관시킬만한 것이 있는지 궁금합니다.