린 소프트웨어 개발의 적용

메리 포펜딕 (Mary Poppendieck)

톰 포펜딕 (Tom Poppendieck)

∙

엄위상

심우곤

한주영

속 도 경 쟁 에 서 승 리 하 기

우리 부모님들께 이 책을 바칩니다:

존 브러스트와 마지 브러스트

그리고

엘머 포펜딕과 루스 포펜딕

목 차

역자서문....................................................................................xiv

한국어판서문..............................................................................xviii

추천의글.....................................................................................xx

0 ■ 서 문 ㅣ Preface xxvii

감사의.글...................................................................................xxix

1 ■ 역 사 ㅣ History

교환.가능한.부품..............................................................................1

대체.가능한.인력..............................................................................2

도요다.가문.....................................................................................3

도요타.생산방식...............................................................................5

오노.다이이치.............................................................................6적시생산흐름......................................................................... 6자동화(지도카)...................................................................... 6

신고.시게오................................................................................7무재고.생산........................................................................... 7무검사.................................................................................. 8

적시.생산방식..................................................................................8

린... ...........................................................................................12

vi

린.생산방식./.린.운영..................................................................14

린.공급망...................................................................................14

린.제품.개발...............................................................................15

린.소프트웨어.개발.....................................................................19

시도해.볼.것....................................................................................19

2 ■ 원 칙 ㅣ Principles

원칙과.실천법..................................................................................21

소프트웨어.개발.........................................................................22소프트웨어............................................................................ 22개발...................................................................................... 23

린.소프트웨어.개발의.7가지.원칙......................................................25

원칙.1:.낭비를.제거하라..............................................................25잘못된.통념:.스펙.조기.확정이.낭비를.줄인다.......................... 27

원칙.2.:.품질을.내재화하라..........................................................28잘못된.통념:.테스팅의.역할은.결함을.발견하는.것이다............. 31

원칙.3:.지식을.창출하라..............................................................32잘못된.통념:.예측을.해야.예측이.가능해진다........................... 34

원칙.4:.확정을.늦춰라.................................................................35잘못된.통념:.계획을.세우는.것은.확정하는.것이다................... 36

원칙.5:.빨리.인도하라.................................................................37잘못된.통념:.서두르는.것은.낭비를.낳는다.............................. 38

원칙.6:.사람을.존중하라..............................................................40잘못된.통념:.유일한.최선의.방법이.존재한다........................... 41

원칙.7:.전체를.최적화하라...........................................................42잘못된.통념:.부분으로.나누어.최적화하라............................... 44

시도해.볼.것....................................................................................47

3 ■ 가 치 ㅣ Value

린.해법............................................................................................49

vii

구글...........................................................................................50

컨셉에서.현금까지......................................................................52컨셉...................................................................................... 52타당성.검토........................................................................... 53파일럿.................................................................................. 54현금...................................................................................... 56

감동하는.고객..................................................................................56

고객에.대한.깊은.이해.................................................................57

해야.할.업무에.집중하라.............................................................58

고객중심.조직..................................................................................60

리더십........................................................................................60수석.엔지니어........................................................................ 61리더십.팀.............................................................................. 62리더십.공유하기.................................................................... 63책임자는.누구인가?................................................................ 64

완전한.팀...................................................................................65운영.용이성.설계................................................................... 66

고객.주문형.개발..............................................................................68

프로젝트에서.제품으로................................................................68

IT.부서와.사업.부서의.협력.........................................................70책임...................................................................................... 72

시도해.볼.것....................................................................................73

4 ■ 낭 비 ㅣ Waste

코드를.더.적게.짜라.........................................................................75

.자라zara...................................................................................75

복잡도........................................................................................78모든.기능은.명분을.가져야.한다............................................. 79최소한의.유용한.기능집합...................................................... 80복잡한.것을.자동화하지.마라.................................................. 80

7대.낭비..........................................................................................82

미완성.작업................................................................................83

viii

가외.기능...................................................................................84

재학습........................................................................................85

이관...........................................................................................86

작업.전환...................................................................................88

지연...........................................................................................90

결함...........................................................................................91

가치흐름도.그리기...........................................................................93

준비...........................................................................................93가치흐름을.선택하라.............................................................. 93시각표의.시작과.끝을.결정하라.............................................. 94가치흐름.소유자를.확인하라................................................... 95간결하게.유지하라................................................................. 95

사례.[Examples].........................................................................96사례.1................................................................................... 96사례.2................................................................................... 97사례.3................................................................................... 99사례.4................................................................................... 100진단...................................................................................... 103

미래의.가치흐름도......................................................................103

시도해.볼.것....................................................................................104

5 ■ 속 도 ㅣ Speed

빨리.인도하라..................................................................................107

페이션트키퍼............................................................................ 107

시간:.보편적.가치기준.................................................................110

대기행렬.이론..................................................................................113

리틀의.법칙................................................................................113

변동과.가동률.............................................................................114

주기.시간.줄이기........................................................................116일의.양이.고르게.도착하도록.하라.......................................... 116진행중인.작업의.수를.최소화하라........................................... 118

ix

진행중인.작업의.크기를.최소화하라........................................ 121일정한.리듬을.가져라............................................................. 123일의.양을.할.수.있는.만큼으로.제한하라................................. 124당김.스케줄링을.사용하라...................................................... 127요약...................................................................................... 129

시도해.볼.것....................................................................................130

6 ■ 사 람 ㅣ People

경영.시스템.....................................................................................133

보잉.777....................................................................................133

W..에드워즈.데밍W..Edwards.Deming.......................................137

좋은.프로그램들이.실패하는.이유................................................141

팀. . ...........................................................................................143

팀은.어떻게.만들어지는가?..........................................................144

전문적.지식................................................................................146

리더십........................................................................................150

책임.기반의.계획과.통제..............................................................152

시각적.작업.공간..............................................................................155

자기지시적.업무.........................................................................156간판...................................................................................... 157안돈...................................................................................... 159대시보드............................................................................... 160

인센티브..........................................................................................161

성과.평가...................................................................................162평가.순위.............................................................................. 163

보상...........................................................................................164지침1:.승진.체계는.이론의.여지가.없도록.하라........................ 164지침2:.연간.급여.인상의.비중을.낮춰라................................... 165지침3:.통제.범위보다는.영향.범위를.근거로.보상하라.............. 165지침4:.돈보다.더.나은.동기.유발자를.찾아라........................... 166

시도해.볼.것....................................................................................168

x

7 ■ 지 식 ㅣ Knowledge

지식.창출.........................................................................................171

랠리Rally...................................................................................171

진짜.문제가.무엇인가?.................................................................175

과학적.사고................................................................................176

지식.기록하기.............................................................................178A3.보고서............................................................................. 180인터넷.시대........................................................................... 182

적시.확정.........................................................................................182

집합.기반.설계............................................................................183사례1:.의료.장비.인터페이스.설계........................................... 185사례2:.적목.감소.................................................................... 186사례3:.플러그인.방식의.인터페이스........................................ 187왜.낭비가.아닌가?.................................................................. 188

리팩터링....................................................................................188

레거시.시스템.............................................................................190

사례.[Examples]............................................................................192

문제.해결.........................................................................................193

체계적.접근.방법........................................................................1941..문제를.정의한다................................................................ 1942..상황을.분석한다................................................................ 1943..가설을.세운다.................................................................... 1964..실험을.실시한다................................................................ 1975..결과를.확인한다................................................................ 1976..후속조치를.취하고.표준화한다............................................ 198

개선.이벤트................................................................................198대그룹.개선.이벤트................................................................ 199

시도해.볼.것....................................................................................201

8 ■ 품 질 ㅣ Quality

피드백. ...........................................................................................203

xi

폴라리스Polaris.프로그램............................................................203

릴리스.계획................................................................................206

아키텍처....................................................................................208

이터레이션.................................................................................210준비...................................................................................... 212계획수립............................................................................... 213구현...................................................................................... 213평가...................................................................................... 215변동:.사용자.인터페이스........................................................ 216

규범.. ...........................................................................................217

5.S.............................................................................................218

표준...........................................................................................221코드.리뷰.............................................................................. 223짝짓기.................................................................................. 224

실수.방지...................................................................................225자동화.................................................................................. 226

테스트.주도.개발........................................................................228단위.테스트.(또는.프로그래머.테스트).................................... 229스토리.테스트.(또는.인수.테스트)........................................... 230사용성.테스팅과.탐색적.테스팅.............................................. 230특성.테스트........................................................................... 231

형상.관리...................................................................................231

지속적인.통합.............................................................................232

중첩된.동기화.............................................................................233

시도해.볼.것....................................................................................235

9 ■ 파 트 너 ㅣ Partners

시너지. ...........................................................................................237

위급상황!...................................................................................237

오픈소스....................................................................................239

글로벌.네트워크.........................................................................241

외주...........................................................................................246

xii

인프라.................................................................................. 246트랜잭션............................................................................... 247개발...................................................................................... 247

계약. ...........................................................................................249

T5.계약......................................................................................249

PS.2000.계약..............................................................................250

관계형.계약................................................................................251

시도해.볼.것....................................................................................253

10 ■ 여 정 ㅣ Journey

어디로.가고.싶나요?.........................................................................255

차량제어.컴퓨터.........................................................................256

장기적.관점................................................................................257

인간.중심...................................................................................260

우리가.배워온.것은?.........................................................................261

식스시그마.................................................................................262프로세스.리더-실무.작업.팀.리더............................................ 262도구-결과.............................................................................. 262

제약이론....................................................................................263애로사슬............................................................................... 265관행...................................................................................... 266

가설. ...........................................................................................267

훈련...........................................................................................267

사고...........................................................................................269

평가...........................................................................................271주기.시간.............................................................................. 272투자.수익.............................................................................. 274고객.만족.............................................................................. 275

로드맵. ...........................................................................................276

시도해.볼.것....................................................................................277

전체를.최적화하라......................................................................277

xiii

사람을.존중하라.........................................................................277

빨리.인도하라.............................................................................278

확정을.늦춰라.............................................................................278

지식을.창출하라.........................................................................279

품질을.내재화하라......................................................................280

낭비를.제거하라.........................................................................280

참고 문헌 281

찾아 보기 290

xiv

역 자 서 문

주인공은 어려서 무술의 비법이 담긴 책을 전수받는다. 매일 매일 사부의 가르침을 받고,

초식을 연습하고 단련한다. 또, 책에 있는 동작들을 하나씩 익혀나가서 금세 권법의 달인

이 된다. 성인이 될 때쯤이면 기다렸다는 듯이 하늘이 그에게 사명을 내려주고, 이를 받들

기 위해 뜻이 맞는 사람들을 규합하여 문파를 만들어 세상에 나아간다. 속세의 모진 풍파

를 이겨나가기 위해 부하들은 일일이 지시하지 않아도 이심 전심으로 각자 할 일을 거뜬히

해내고, 악당이 나타나면 힘을 합하여 물리친다. 불가항력의 거대한 악의 세력이 몰려와도

홀연히 도인이 나타나 이들을 돕는다. 때로는 다른 조직(타 문파 등)과 연맹을 만들어 서로

의 임무를 나누어 갖고, 그 임무를 성실히 수행한다. 하나 둘 임무를 완료할 때마다 무공비

급을 습득하기도 하여 내공은 착실히 쌓여간다. 하늘이 주신 사명을 다할 쯤에는 자신만의

권법을 집대성한 책을 후배들에게 물려주고 그는 홀연히 사라진다.

무협지에서만 볼 수 있는 이야기지만, 우리는 가끔 현실에서도 ‘특히 소프트웨어 개발에

서도 무협지처럼 될 수 있으면 얼마나 좋을까’ 하고 생각해본다. 다음과 같이 말이다.

신입사원이 입사하면 개발에 대해 잘 정리된 매뉴얼을 받는다. 선배의 따끔한 지도 속에

틈틈이 매뉴얼을 익혀서 필요한 지식을 모두 습득한다. 개발 프로젝트에 투입되면 프로젝

트 리더가 해야 할 일과 필요한 기술을 상세히 알려준다. 개발이 시작되면 팀원들은 이심전

심으로 자신이 할 일을 찾아 이를 수행한다. 가끔 외부에서 문제가 발생해도 힘을 합쳐 이

를 해결한다. 도저히 감당할 수 없는 문제가 생기면 홀연히 컨설턴트가 나타나 이를 해결해

주고 사라진다. 경우에 따라서는 할 일을 뚝 떼어 외주업체에 주고, 외주받은 업체는 이를

성실히 수행하여 약속한 납기에 제공한다. 개발 중간중간 쌓은 지식을 정리하여 매뉴얼을

업데이트 한다. 개발은 주어진 일정과 비용으로 성공적으로 완료되고 매뉴얼은 다음 팀에

게 전수된다.

물론 이것은 꿈 같은 이야기다. 현실은 참혹하기만 하다.

xv

신입사원은 참고할 만한 문서가 별로 없다. 더러 몇 권 있기는 하지만 대부분 형식적인

것들이고 실무에 도움될 만한 것을 찾기는 힘들다. 필요한 지식이 턱없이 부족한 상태에서

프로젝트에 투입된다. 프로젝트 리더는 업무를 할당하기보다는 선배 사원을 지정해주고 모

든 것을 그에게 위임한다. 개발이 시작되어도 자신이 할 일을 잘 알지 못하고, 외부 상황에

따라 팀원 전체가 우왕좌왕 혼란을 겪는다. 어제 잘 돌아가던 코드가 외주업체 코드를 머지

한 후부터 돌아가지 않는다. 외주업체는 당면한 이슈에 대해 언제까지 해결하겠다는 말만

되풀이하는데, 그 동안의 이력을 볼 때 그렇게 될 가능성은 거의 없어 보인다. 고객은 갑자

기 기능 추가를 요구하면서 일정은 절대 바꿀 수 없다고 윽박지른다. 이런 상황에서 필요한

신기술을 습득하기 위해 공부할 시간을 확보하는 것은 어불성설이다. 시스템 테스팅에서는

수많은 결함이 발견되어 매일 같이 쏟아지고 아무리 수정을 해도 끝이 없다. 그렇게 정신

없이 전쟁을 치르다 보면 우여곡절 끝에 어찌어찌 개발이 완료된다. 이미 계획된 비용을 초

과했고, 일정은 기한을 넘긴 지 오래다. 체력은 바닥났고 가족과 함께했던 시간은 일년에

며칠인지 손에 꼽을 정도다. 개발은 끝이 났지만 그 동안 습득한 지식은 정리하지 못했다.

다음 프로젝트에서도 혼란은 반복된다.

소프트웨어 개발에서 흔히 발생하는 일이다. 개발 프로젝트의 74%가 일정을 맞추지 못

하거나 중간에 아예 개발이 취소되며, 일정의 2배 이상을 소요하는 경우도 전체의 22%에

이른다는 것은 잘 알려진 사실이다. 그만큼 현실에서는 개발이 어렵게 진행되고 있는 것이

다. 고객의 기대 수준은 점점 올라가고 이에 따라 기능이 감당 못하게 복잡해지는데 일정

및 비용은 제한돼 있다. 품질을 올리려면 일정이 더 필요하고 일정을 맞추려면 품질 활동

을 할 시간이 부족한 딜레마 속에서 해법을 찾기가 어렵다. 이 책은 이러한 딜레마 속에서

고뇌하는 경영자와 개발자에게 이러한 상황이 발생하는 근본적인 이유가 무엇인지, 그리고

이를 타개하기 위해 무엇을 고민해야 하는지를 7가지 린 원칙과 함께 제시한다.

애자일 고수들은 말한다. 수면 위에서는 우아해 보이는 백조가 그 밑에서는 쉼 없이 발을

움직이는 것처럼, 애자일의 방법론들도 일견 자유 분방해 보이지만 실제로는 상당한 스킬

과 엄격한 규범을 필요로 한다고... 쏟아지는 신기술, 끊임없는 요구사항의 변경, 들쭉날

쭉한 업체의 대응, 고르지 못한 팀원의 스킬, 애매 모호한 조직의 프로세스와 표준, 생각지

도 못한 기술적/관리적 돌발상황 등 이런 것들에 대응하기 위해서는 반복적 개발 전략과 지

속적인 통합 및 빌드, 끊임없는 리팩터링, 자동화된 단위 테스트와 인수 테스트 등의 엄격

xvi

한 규범이 필요한 것이다. 또한 변하는 상황에 능동적으로 대응하기 위한 유연하고 민첩한

프로젝트 관리, 개발에서 발생하는 낭비를 제거하고 효율을 높일 수 있는 개발 프로세스,

전 조직원이 하나의 목표를 추구하게 하는 성과 측정 및 평가 시스템, 전체 최적화를 목표

로 하는 외주관리, 그리고 미래를 대비하기 위한 지식 창출/관리 시스템의 구현도 필요하다.

이 책은 저자의 풍부한 경험을 바탕으로 경쟁력 있는 조직이 되기 위한 전략과 세부적인

실천도구를 제시한다. 저자가 전 세계를 돌아다니면서 경험한 각 개발 조직의 일화와 사례

는 마치 현장에 있는 듯한 사실감을 준다.

속도 경쟁에서 승리하는 회사는 경쟁사에 비해 현저한 비용 우위를 가질 뿐만 아니라 결

함율이 극단적으로 낮다. 이 책에서 제시한 방법들을 실천하기가 쉽지는 않지만 하나씩 하

나씩 방법을 찾아 실행해나가면 언젠가는 무림 고수들로 가득 찬 천하무적의 문파를 발견할

수도 있을 것이다. 아무쪼록, 품질과 일정이라는 두 마리 토끼를 잡고 무한 경쟁에서 승리

하는 데 이 책이 일조하기를 기대한다.

*

본래 이 책의 부제는 “From Concept To Cash (컨셉에서 현금까지)” 다. 우리는 저자가 이 짧

은 문구에 많은 의미를 함축했다고 생각한다. 실제로 본문을 보고 나면 이 문장 하나로 다

양한 깨달음(悟)을 얻을 수 있을 것이다. 하지만 이 짧은 문장을 그대로 번역하면 의도를 정

확히 전달하기도 어려울 뿐만 아니라, 독자들에게 크게 어필할 수 없을 것 같았다. 결국 책

의 내용을 모두 포함하면서도 임팩트를 줄 수 있는 새로운 부제를 짓기로 결정했다. 그러던

중에 메리 포펜딕의 구글 강연에서 힌트를 얻었다. 강연 제목이 “Competing On The Basis of

Speed”였는데, 오늘날과 같은 경쟁사회에서 조직 경쟁력은 '속도'에 있음을 강조하고 그것

을 달성할 수 있는 방안으로 린 사상을 설파하고 있었다. 한국어판 부제 ‘속도 경쟁에서 승

리하기’는 이렇게 탄생했다.

xvii

감 사 의 글

엄위상

번역기간 내내 오랜 시간 동안 불평 한마디 없이 뒷바라지 해준 아내 수미에게 감사

한다. 마음으로부터 후원을 해준 부모님과 동생들에게도 감사한다. 나름대로 많은

배려를 해준 두 딸 태은이와 정은이에게도 고맙다는 말을 전한다. 끝으로 바쁜 와중

에도 관심을 가져주고 격려와 조언을 아끼지 않은 선후배와 동료들에게 감사드린다.

심우곤 ㅣ http://www.wgshim.com

먼저 번역기간 내내 곁에서 후원해주신 부모님과 동생에게 감사한다. 초벌번역 검

토를 해주었던 성훈이와 번역 막바지에 리뷰해주신 정우형, 그리고 어색한 문장들

을 꼼꼼하게 다듬어준 민이와 현진이에게 정말 고맙다는 말을 전한다. 끝으로 늘 함

께 고민하고 샘솟는 아이디어를 제공해주시는 파트원들께도 진심으로 감사드린다.

한주영 ㅣ http://feeds.feedburner.com/jooyunghan

도움 주신 많은 분들께 감사드린다. 때로는 고민의 씨앗을 던져주시고, 가끔은 실험

대상이 되어 주셨던 구미와 서울의 개발자분들께도 감사드린다. 아껴주신 부모님,

형제들께도 감사드린다. 마지막으로 사랑하는 아내 혜정이에게 미안한 마음이 앞선

다. 가끔 구박하긴 했지만 그래도 몸으로 마음으로 후원해줘서 너무 고맙다!

**

세 사람은 ‘즐거운 소프트웨어’를 위해 의기투합하였다. 사용자가 즐겁고, 경영자가 즐

겁고, 개발자가 즐거운 소프트웨어를 실현하기 위해 고민하고 있다. 현재 LG전자 사업

부들을 오가며 고군분투 중이다.

xviii

한국은 지난 30년 동안 경이로운 경제성장을 이뤄냈습니다. 2007년 비즈니스위크가 선정

한 ‘글로벌 100대 브랜드’에 한국의 세 회사 삼성, 현대, LG가 선정된 것은 전혀 놀라운

일이 아닙니다. 또한 삼성과 LG는 비즈니스위크가 선정한 ‘세계에서 가장 혁신적인 100대

기업’에도 올라 있습니다. 한국과 같은 작은 나라에서 세계 톱 브랜드 3개와 가장 혁신적인

기업 2개가 나왔다는 것을 우연이라고 치부할 수 있을까요? 아닙니다. 한국은 자국민의 지

성를 최대한 활용한 제품과 서비스를 수출하는 것이, 세계 속에서 위상을 높이는 방법이라

는 것을 인식하였던 것입니다. 지식을 획득하고 분배하는 최선의 방법 중 하나는 소프트웨

어에 지혜를 녹이는 것입니다. 소프트웨어라 하면 제품에 숨겨진 소프트웨어, 비즈니스 프

로세스를 실행하는 소프트웨어, 사람들의 삶을 즐겁게 하는 소프트웨어 등이 있겠죠. 저희

는 독자 여러분들께서 더욱 효과적으로 지식을 경제적 성과로 만드는데 이번 한국어판이 도

움을 드릴 수 있길 기원합니다.

경쟁자보다 빠르게 학습하는 능력이야말로 유일한 ‘지속적 경쟁우위’입니다. 이는 개별

회사와 국가 전체에 공통으로 적용됩니다. 근본적으로 린 사고는 신속하고 지속적인 학습

에 초점을 둔 경영 시스템입니다. 여기서의 학습은 생산중인 제품과 그 제품을 생산하기 위

해 사용된 프로세스에 관한 것입니다. 제품 생산 프로세스를 사용하는 사람과 린 사고의 핵

심 도구인 과학적 방법론을 사용함으로써 학습이 완성됩니다. 학습은 고객에게 가치를 제

공하는 흐름 속의 모든 낭비를 제거하는데 초점을 두고 있습입니다.

이제는 더 이상 농경시대와 같이 토지의 소유가 힘의 기반이 될 수는 없습니다. 산업시대

에서처럼 자본의 소유가 힘의 기반이 되는 것도 아닙니다. 오늘날 힘의 기반은 지식입니다.

이전 시대의 힘의 기반은 유한한 것이었지만 지식은 공유할수록 늘어납니다. 지식을 만들

어내기는 힘들지만 이미 알려진 지식에 접근하는 것은 점점 더 쉬워지고 있습니다. 신속하

게 학습하는 능력은 개인과 조직적 차원이 모두 존재합니다. 지속적 경쟁우위의 조직에 속

한 모든 사람들은 지속적으로 학습합니다. 이것은 조직이 이미 알고 있는 것이 대한 적극적

한 국 어 판 서 문

xix

인 훈련과 프로세스와 실천법을 개선하기 위한 새로운 것들을 실습을 통해 이루어집니다.

사실 이러한 조직에서 관리자의 주된 책임은 구성원들이 선택한 시장을 공략하는 방식을 끊

임없이 개선하도록 육성하는 것입니다. 만약 프로세스와 제품이 지속적으로 개선되지 않는

다면 조직의 생존 자체가 위태로워지기 때문입니다.

린 사고는 경쟁자보다 더 빠르게 학습하고 더 나은 성과를 낼 수 있는, 저희가 알고 있는

최선의 방법입니다. 이 책은 소프트웨어가 핵심인 제품이나 비즈니스 프로세스에 린 사고

를 적용하는데 중점을 두었습니다.

- 메리 포펜딕과 톰 포펜딕

2007년 8월

xx

제프 서더랜드 ㅣ Jeff Sutherland

저는 메사추세츠 주 벌링턴에 위치한 이젤Easel 社에서 1993년 처음으로 스크럼Scrum 팀을

만들었습니다.1 당시 스크럼에 함께 참여했던 CEO는 첫 번째 스크럼을 성공시킨 그 팀에

회사의 사활을 걸었습니다. 1995년부터 저는 켄 쉬와버Ken Schwaber와 함께 일하기 시작했

습니다. 그는 스크럼 프로세스를 전세계에 배포할 수 있도록 프로세스를 정형화하였습니다.2

이젤 이 후 네 개의 회사에서 저는 스크럼의 자기조직화 특성을 사용하여 A 타입 스크럼(승

리하는 팀)에서 B 타입 스크럼(승리하는 제품 포트폴리오)으로, 그리고 곧 C 타입 스크럼(승

리하는 회사)으로 발전시켜 나갔습니다.

2000년에 저는 페이션트키퍼PatientKeeper 社에 스크럼을 소개하였는데, 이는 린 개발의 대

표적 성공 사례가 되었습니다. 수년에 걸쳐 주기 시간cycle time을 단축하여 고객이 딱 필요

로 하는 수준에 이르렀습니다. 중요한 항목은 1주, 사소한 개선사항은 1개월, 완전히 새로

운 제품은 3개월에 전달할 수 있게 되었습니다. 3개월 간격의 릴리스는 1개월의 스프린트

Sprint가 누적된 것으로, 각각의 스프린트 결과물은 고객에게 인도할 수 있는 수준의 소규모

릴리스입니다.

페이션트키퍼는 스크럼을 확산하였으며 회사 전체를 마치 하나의 스크럼처럼 운영합니

다. 매주 월요일마다 메타스크럼MetaScrum 미팅을 열어 점검하고, 적응하고, 자기조직화하

고, 변화합니다3. 제품 소유자가 이 미팅을 주재하고 CEO를 포함한 모든 회사의 이해당사

1 Sutherland,J.,“AgileDevelopment:LessonsLearnedfromtheFirstScrum,”CutterAgileProjectManagementAdvisory

Service:ExecutiveUpdate,2004,5(20):pp.1–4.참조

2 Schwaber,K., “ScrumDevelopmentProcess,” inOOPSLABusinessObjectDesignand ImplementationWorkshop,J.

Sutherland,etal.,editors.1997,Springer:London.참조

3 Sutherland,J.,“FutureofScrum:ParallelPipeliningofSprintsinComplexProjects,”inAGILE2005Conference.2005.Denver,

Colorado:IEEE.참조

추 천 의 글 1

xxi

자들이 미팅에 참석합니다. 이 자리에서는 린 개념들을 주의깊게 검토하며, 오직 여기서만

스프린트를 시작, 중단, 변경하는 결정을 내립니다. 메타스크럼 미팅에서 결정된 사항들은

당일 오후까지 관련된 고객들을 포함한 회사 전체에 반영됩니다.

우리는 메타 스크럼 팀에 제품 백로그Product Backlog를 ‘준비’ 상태로 지정할 수 있는 수석

제품 소유자Product Owner를 한 명 두었습니다.4 그리고 스크럼들을 대상으로 15분간 일일 스

크럼을 진행하는 수석 스크럼마스터ScrumMaster를 한 명 선임하였습니다. 일일 스크럼에서는

어제 팀이 무엇을 했는지, 오늘은 무엇을 할 것인지, 고객에게 인도하는 것을 방해하는 요

인들이 무엇인지를 확인합니다. 이렇게 짧은 미팅과 자동화된 스프린트 백로그 추적 시스

템을 통해, 대규모의 미션 크리티컬한 조직5을 대상으로 하는 연간 45개의 소프트웨어 릴

리스를 관리합니다. 스프린트를 시작하기 전에 일정을 고객들에게 약속하고, 매 스프린트

가 끝날 때면 수 천명의 웹 사용자와 PDA를 사용하는 수 백명의 의료진들이 시스템을 사

용하게 됩니다. 페이션트키퍼에 있어서 ‘컨셉(제품 백로그)에서 현금(생산된 제품)까지’6는

1개월이 걸립니다. 우리는 구현 전, 구현 중, 구현 후의 모든 곳에서 낭비를 제거해야만 했

습니다.

1993년 당시에는 아직 린 제품 개발이 어떠한 산업 분야에서도 잘 알려지지 않았었습니다.

스크럼은 소프트웨어 개발에 린 사고를 적용한 첫 구체적 구현물이었습니다. 모든 유형, 모

든 규모의 조직에서 스크럼을 통해 며칠 내에 린 팀을 운영할 수 있었습니다. 스크럼은 쉽게

이해하고 따라할 수 있는 표준 패턴을 갖추고 있었기 때문입니다. 오히려 어려웠던 일은 왜

그리고 어떻게 지속적인 품질과 생산성 향상을 만들어내는지를 설명하는 것이었습니다.

오늘날 메리와 톰 포펜딕 부부는 글과 교육을 통해 검증된 원칙들을 제공합니다. 그 원칙

들을 바탕으로 도구와 기법, 방법들을 조직의 고유하고 특별한 상황과 역량에 맞게 고쳐서

적용할 수 있을 것입니다. 이제 우리는 스크럼이 어떤 방식으로 소프트웨어 개발을 린하게

만드는지 설명할 수 있습니다. 제가 몸담고 있는 페이션트키퍼뿐만 아니라 전세계 실무자

들에게 스크럼을 최적화하는 방법을 알려줄 때 저는 이 책에서 언급하는 절차와 프로세스를

사용합니다.

4 JeffSutherland,AntonVictorov,andJackBlount, “AdaptiveEngineeringofLargeSoftwareProjectswithDistributed/

OutsourcedTeams”,6thInternationalConferenceonComplexSystems(ICCS),June25-30,2006.참조.

5 페이션트키퍼의고객은병원과같은의료기관이다.

6 concepttocash.이책의원서부제인Fromconcepttocash(컨셉에서현금까지)를인용한것이다.

xxii

린 소프트웨어 개발은, 모든 애자일 방법론들이 린 사고를 소프트웨어에 응용하여 유효

성이 검증된 것이라고 봅니다. 또한 애자일 방법론이 성공할 수 있도록 하는 광범위한 시

각을 제공한다는 면에서 애자일을 넘어서고 있습니다. 첫째, 린 소프트웨어 개발은 컨셉

에서 현금까지의 전체 가치 사슬을 관찰하고, 코드 작성의 앞뒤에서 발생하는 모든 낭비와

지연까지 제거하려고 노력합니다. 둘째, 린 소프트웨어 개발은 애자일 소프트웨어 실천법

들을 확장하고, 발전시키고, 효과를 배가시킬 수 있는 관리 환경을 확립합니다. 셋째, 린

소프트웨어 개발은 도구와 기법, 방법들을 조직의 고유하고 특별한 상황과 역량에 맞게 고

쳐서 적용할 수 있게하는 검증된 원칙들을 제공합니다.

이 책의 모든 장에서는 한층 더 생산적인 팀을 만들기 위해 실천할 수 있는 여러 원칙들

을 제시하고 있습니다. 만약 여러분이 경쟁사에 비해 4배나 높은 생산성과 12배나 높은

품질을 꾸준히 유지하고 있는 도요타처럼 되고 싶다면 이러한 실천법들은 필수적입니다.

이 책에 있는 원칙들을 잘 실행한다면 경쟁자들의 저항은 부질없는 짓이며 시장에서의 승

리는 떼어 놓은 당상입니다. 여기에 간략히 기술되어 있는 실천법들은 투자수익률ROI이 매

우 높을 것입니다.

여러분 회사에 맞는 린 ‘비밀 소스’를 제조하기 위해서는 축적된 린 지혜를 체계적으로

구현해야만 한다는 사실을 배웠습니다. 간단히 말해 여러분은 무리, 무라, 무다7를 깊이있

게 이해해야만 합니다. 메리와 톰은 이것들이 무엇인지, 그리고 여러분들이 어떻게 해야하

는지를 손쉽게 이해할 수 있도록 7개의 린 원칙과 소프트웨어 개발의 7가지 낭비로 풀어서

설명하고 있습니다.

‘무리’는 시스템 부하를 적절하게 하는 것, ‘무라’는 사람이나 시스템, 프로세스에 절

대 스트레스를 주지 않는 것과 관련되어 있습니다. 하지만 많은 관리자들은 개발자에게

110%의 업무를 부과합니다. 그들은 개발자들이 ‘일을 더 열심히’ 하도록 ‘긴급’ 상황을 만

드느라 필사적입니다. 관리자는 팀을 사소한 것까지 꼼꼼하게 관리하기를 원하는데 이것

은 자기조직화를 고사시킵니다. 이러한 잘못된 발상은 종종 대기 시간을 야기하고 점차 개

발 팀의 혼란, 죽음의 행진, 체력 쇠진을 거쳐 결국 프로젝트 실패를 초래하게 됩니다.

7 <역주>본래도요타생산방식에서는‘무다(むだ,無馱),무리(むり,無理),무라(むら,無斑)’라고하여‘3무’를철저히배제할대상으

로본다.일본어로'무다'는낭비,'무리'는말그대로무리,‘무라’는고르지못함을의미한다.본문에서제프서더랜드는무리를부하

(loading),무라를스트레스(stress),무다를낭비(waste)로설명하고있는데,여기서무라는본래의의미(불균일,unevennessor

inconsistency)와다르다.제프는린이나TPS의전문가가아니므로실수를한것으로보인다.

xxiii

제가 기술 관리자들에게 PC의 CPU에 부하를 110% 주는지 묻자 그들은 웃으며 말했습

니다. “물론 아니죠. 컴퓨터가 뻗어버릴꺼에요!” 그럼에도 불구하고 개발 팀에는 여전히 과

부하가 걸리고, 그로 인해 프로젝트는 자주 지연되며, 소프트웨어는 깨지기 쉽고 유지보수

하기 어렵고, 일은 점점 악화되어 나아질 기미가 보이지 않게 됩니다. 도요타와 스크럼이

스트레스(무라)를 피하고 병목(무리)을 제거하는데 사용하는 당김 시스템을 이해할 필요가

있습니다. 개발자들은 제품 백로그에서 적시에 필요한 항목들을 취합니다. 스프린트에 가

져갈 항목을 제품 백로그에서만 취하되, 스프린트 내에서 완료할 수 없는 정도로 가져가지

는 않습니다. 장애를 드러내고 낭비(무다)를 제거하는 관리를 통해 그들은 점점 속도를 내

게 됩니다. 낭비를 제거함으로써 개발자들이 할 일도 줄어듭니다. 결국 생산성이 향상되며

고품질의 소프트웨어를 인도하고, 고객이 정확히 무엇을 원하는지 초점을 맞출 수 있는 시

간을 확보하게 됩니다.

따라서 부하(무리)를 이해하고 스트레스(무라)를 피하여 여러분의 주기 시간을 단축하십

시오. 그러면 환경이 린하게 되어 결국 낭비(무다)를 만드는 장애가 쉽게 드러나 보입니다.

이러한 장애를 제거할 때 비로소 여러분의 팀은 더 신속하게 움직이고 일을 덜 하며, 품질

은 높여서, 결국 고객이 원하는 제품을 적시에 내어놓을 수 있게 됩니다.

저는 여러분에게 포펜딕 부부의 책을 책상 위에 놓아두고 정기적으로 참고하여 린 원칙를

체계적이고 지속적으로 구현하는데 도움을 얻으시길 권합니다. 실천법은 어렵지만, 낭비를

회피하여 일을 덜 하도록 해주는 린 개발방식을 적용한다면 여러분은 재빨리 생산성 2배를

달성할 수 있습니다. 그 후 장애물을 제거하여 일을 더 똑똑하게 한다면 거기서 다시 2배의

생산성을 낼 수 있을 것입니다. 올바른 방법을 통해 생산성이 4배 빨라지게 되면, 여러분

은 도요타 처럼 12배나 높은 품질향상을 달성할 수 있을 것입니다.

- 제프 서더랜드 박사

페이션트키퍼 社 CTO

공인 스크럼마스터 트레이너

스크럼 개발 프로세스 창시자

2006년 7월

xxiv

켄트 벡 ㅣ Kent Beck

소프트웨어 개발은 많은 링크들로 이루어진 사슬이며, 전체 효과성을 향상시키기 위해서는

전체 사슬을 바라봐야 할 필요가 있습니다. 이 책은 프로그래머에 국한하지 않고 관리자,

스폰서, 고객, 테스터, 디자이너를 포함한 소프트웨어 개발에 참여하는 모든 사람들을 대

상으로 쓰여졌습니다. 이 책에서 제시한 원칙들은 결국 소프트웨어 개발에 관련된 모든 사

람들에게 영향을 미치게 됩니다. 이 책은 개발의 큰 그림을 보고자 하는 사람들을 대상으로

하고 있습니다.

영향력을 가진 아이디어는 이론과 경험 모두에 뿌리를 두고 있어야 합니다. 이 책은 린

생산방식에서 검증된 아이디어들을 재해석하여 이론과 실천법을 설명하고 이것들을 소프트

웨어 개발에 적용합니다. 제조 분야의 많은 기본적 문제들은 소프트웨어 개발의 문제이기

도 합니다. 불확실성과 변화를 다뤄야 하고, 지속적으로 프로세스를 개선해야 하며 고객에

게 가치를 제공해야 합니다.

이 책이 여러분에게 제공하는 것은 무엇일까요? 첫째, 다양한 이론을 제공합니다. 이 이

론들은 소프트웨어 개발을 어떻게 개선할 수 있는지 다양한 사고방식을 제공합니다. 둘째,

이론이 실제 프로젝트에 적용된 사례를 이야기해주고 있습니다. 셋째, 이야기 속에서 얻은

이론과 교훈을 여러분의 독특한 상황에 적용할 때 도움을 줄 자극적인 질문들을 제공합니다.

메리는 이러한 자료를 내놓을 수 있는 유일한 적임자입니다. 그녀는 린 생산방식을 직접

경험하였으며, 운영방식을 바꾸어 폐쇄 위기의 공장을 구해냈습니다. 또한 프로그래머와

관리자로서의 소프트웨어 개발도 경험하였습니다. 제가 메리의 세미나에 참석한 적이 있

습니다. 준비한 강의자료를 발표하는 그녀의 힘과 자신감은 저를 무척 즐겁게 하였습니다.

저는 이 책에서 그 때와 같이 올곧은 그녀의 목소리를 들을 수 있습니다.

추 천 의 글 2

xxv

만약 포펜딕 부부의 이전 책인 『Lean Software Development: An Agile Toolkit』을 읽으셨다면

이 책이 그것을 구현하기 위한 새로운 길잡이가 되어줄 것입니다. 이전 책에서 다룬 이론을

되풀이하고 있지만 아이디어를 실제 상황에 적용하기 위한 노력을 기울였습니다. 그 결과

읽기쉽고 실무적인 지침들을 제공하고 있는데, 이 지침들은 여러분의 개발 환경을 변화시

키는데 도움을 줄 잠재력 있는 아이디어들을 안내해 줄 것입니다.

이 책은 실천가를 위한 책입니다. 실천가는 최고의 행복을 추구하는 방향으로 자신의 행

동을 일치시키려 합니다. 만약 여러분이 그런 실천가라면 저는 긍정적 변화 에너지와 아이

디어의 근원으로 이 책을 강력히 추천합니다.

- 켄트 벡

쓰리 리버스 인스티튜트(Three Rivers Institute)

2006년 7월

xxvi

xxvii

속편

2003년 『Lean Software Development: An Agile Toolkit』8을 썼을 때, 린Lean이라는 아이디어는

1990년대의 것을 가져온 것입니다. 저희는 제조와 물류에서 탄생한 획기적인 아이디어가

개발에 적용될 수 있기까지 10~20년이 걸린다는 것을 보아 왔습니다. 따라서 저희는 애자

일 방법이 소프트웨어 개발에 효과적인 이유를 설명하기 위해, 80년대와 90년대부터 이미

충분히 입증된 린의 개념을 활용하는 것은 시대착오적인 발상이 아니라고 판단하였습니다.

그 전략은 먹혀들었습니다. 『Lean Software Development』는 리더들이 애자일 소프트웨어

개발을 이해하는데 유용하다고 계속해서 느껴온, 린 사고에 기반한 사고의 도구들을 제시

하고 있습니다. 책을 구입한 많은 개발자들이 그것을 자신의 관리자에게 주었고, 많은 관

리자들이 린/애자일 소프트웨어 개발을 도입하려는 동료들에게 그 책을 선물하였습니다.

한편 린에 관해 예상치 못한 일이 일어났습니다. 최근 2년간 린 이니셔티브는 재조명받

기 시작했습니다. 린이라는 단어는 원래 90년대에 일본 자동차 제조방식의 특징을 나타내

는 단어로 사용되면서 유명해졌습니다.9 최근에 혼다와 도요타는 북미 자동차 시장에서 승

승장구하고 있는 반면에, 디트로이트의 자동차 회사들은 구조조정을 겪고 있습니다. 예를

들어, 도요타의 수익은 2003년 3월 31일 회계년도 결산시 80억 달러를 넘었고 2004년

에는 100억 달러 돌파, 2005년에는 110억 달러, 2006년에는 120억 달러를 기록했습니

8 번역서로는『린소프트웨어개발:애자일22가지실천도구』(인사이트,2007)가있다.

9 JamesWomack,DanielJones,andDanielRoos,TheMachineThatChangedtheWorld,RawsonAssociates,1990.

0■서 문ㅣ Preface

xxviii

다. 많은 회사들이 그러한 꾸준하고 지속적인 성공 뒤에 무엇이 있는지 이해하기 위해 린을

새로운 시각으로 보게 된 것입니다.

린 이니셔티브가 회사의 소프트웨어 개발이나 제품개발 분야에서 시작되는 경우는 거의 없

었습니다. 그러나 시간이 지나면서 성공적인 린 이니셔티브는 제조와 물류에서부터 출발하여

개발 부서로 나아가게 되었습니다. 하지만 제조나 기타 운영 부문에서 나온 린 실천법들은 개

발에 쉽게 적용하기 어려웠습니다. 따라서 린 이니셔티브는 소프트웨어 개발에 다다르면 급

격히 힘이 떨어지곤 했습니다. 린의 근본적인 원칙은 여전히 유효했지만 운영 부문의 실천법

이나 지표들을 개발에 적용하는 것은 적절하지 않았습니다. 린 이니셔티브가 소프트웨어 개

발 분야에서 힘을 잃고 있을 때, 많은 회사들이 『Lean Software Development』가 그들의 접근 방

법을 수정하고 린 아이디어를 개발 조직에 적용하는 사고의 기반을 마련해 주었다고 합니다.

최근 몇 년간 린과 애자일 소프트웨어 개발 방법의 이점이 널리 알려지고 그 효과를 인정

받게 되면서, 많은 회사가 그들의 소프트웨어 개발 방법을 바꾸고 있습니다. 저희는 이렇

게 새로운 접근을 시도하는 세계 각국의 조직을 방문하였고, 거기서 소프트웨어 개발 방법

을 바꾸기 위해 열심히 노력하는 사람들과의 상호작용을 통해 많은 것을 배웠습니다. 저희

의 지식이 늘어나면서 동시에 린 소프트웨어 개발을 적용하기 위해서는 더 많은 정보가 필

요하다는 요구도 늘어났습니다. 저희는 사람들을 일일이 직접 만나는 것보다 새로운 책 한

권을 씀으로써 더 많은 사람들에게 저희가 배운 것을 공유할 수 있다고 생각했습니다. 그래

서 저희는 저희의 경험을 바로 이 책 『린 소프트웨어 개발의 적용: 속도 경쟁에서 승리하기』10

에 요약하였습니다.

이 책은 린 소프트웨어 개발을 구현하는 방법에 대한 ‘요리책’이 아닙니다. 전판과 마찬가

지로 린 원칙을 어떻게 당신의 분야에 맞게 고쳐서 적용할 것인지에 대한 사고의 도구들을

소개합니다. 이 책은 지난 책의 연장선 상에서 출발하였으며, 린과 애자일 소프트웨어 개

발을 구현하려고 시도할 때 사람들이 맞닥뜨리는 이슈와 문제들에 대해 더 깊이 파고듭니다.

이 책을 『Lean Software Development』의 속편으로 생각할 수도 있겠습니다. 그 책에 있는 내

용을 반복하는 대신에 저희는 다른 관점을 취했습니다. 독자들이 린 소프트웨어 개발이 좋

은 생각이라는 것을 확신한다고 가정하고, 성공적인 구현을 위한 필수 요소가 무엇인지에

중점을 두었습니다. 구현의 핵심 요소들을 살펴보고, 무엇이 중요하고 무엇이 중요하지 않

10 원서제목은『ImplementingLeanSoftwareDevelopment:FromConcepttoCash』임

xxix

은지, 왜 그런지에 대해 논의하였습니다. 저희의 목적은 조직이 더욱 효과적인 소프트웨어

개발의 길로 접어들도록 돕는 것입니다.

이 책의 첫 장은 린의 역사를 돌아보고, 두 번째 장은 『Lean Software Development』에서 소

개된 린 소프트웨어 개발의 7가지 원칙을 검토합니다. 그 후 가치, 낭비, 속도, 사람, 지식,

품질, 파트너 그리고 여정에 대한 장이 이어집니다. 이 8개 장의 각각은 어떤 조직이 눈앞

에 닥친 이슈를 어떻게 다루는지를 보여주는 사례로부터 시작합니다. 그 뒤에 중요하다고

생각되는 주요 주제에 대한 논의, 주제를 설명하는 짧은 이야기 그리고 저희가 자주 듣는

질문에 대한 답이 이어집니다. 각 장은 그 장의 주제들을 더 깊게 탐색하도록 도와주는 연

습문제들로 마무리됩니다.

감사의 글

저희의 토론과 수업에 참가하고 회사에 저희를 초대해 주신 모든 분들, 특히 자신의 경험을

공유해주고 예리한 질문을 던져주신 분들께 감사를 드리고 싶습니다. 이 책은 그 분들 모두

로부터 얻은 지식을 공유하고 있습니다.

추천의 글을 써 준 Jeff Sutherland와 Kent Beck에게 깊은 감사를 드리며, 편집을 맡아 준

Greg Doench와 프로젝트 편집자, Tyrrell Albaugh, 특히 교열 편집자인 Nancy Hendryx에게 감

사 드린다. 이 책에 사례와 아이디어들을 제공한 Jill Aden, Brad Appleton, Ralph Bohnet, Mike

Cohn, Bent Jensen, Brian Marick, Clare Crawford-Mason, Ryan Martens, Gerard Meszaros, Lynn

Miller, Kent Schnaith, Ian Shimmings, Joel Spolsky, Jeff Sutherland, Nancy Van Schooenderwoert, Bill

Wake, Werner Wild 그리고 익명으로 남고 싶어한 저의 친구이자 운영 관리자에게 특별히 감

사드립니다.

첫 번째 초고를 읽고 제안을 해준 사람들, 특히 Glen Alleman, Brad Appleton, Daniel

Brolund, Bob Corrick, Allan Kelly, Kent Schnaith, Dave Simpson, Alan Shalloway 그리고 Willem

van den Ende에게 감사드립니다. 이 책의 두 번의 초고를 모두 검토하고 바쁜 일정 속에서도

촉박한 일정을 우리와 함께 해준 Mike Cohn에게 마음 깊은 곳으로부터의 감사를 드립니다.

그의 의견과 제안은 이 책을 더 좋은 것으로 만드는데 매우 큰 도움이 되었습니다.

- 메리 포펜딕과 톰 포펜딕

2006년 6월

xxx

1

교환 가능한 부품

1785년 6월 프랑스 파리. 미국 독립전쟁이 끝난 지 18개월 후, 프랑스 혁명이 시작되기 4

년 전이었다. 오노레 블랑1은 군 고위 관계자와 외교관들을 파리에 있는 그의 총포상으로 초

대했다. 그 때는 모든 사람이 무기에 대한 필요성을 절감하고 있을 무렵이었다. 그는 50개

의 발사 장치를 분해하여 그 부품들을 상자에 넣었다. 방문자들은 직접 상자에서 임의의 부

품들을 꺼내 발사 장치를 만들어 장총에 장착해 보고는 깜짝 놀랐다. 부품들이 완벽하게 맞

물렸기 때문이다. 교환 가능한 부품으로 총을 만드는 가능성을 처음으로 확인한 순간이었다.2

당시 파리에 파견된 외교관이었던 토머스 제퍼슨Thomas Jefferson이 그 자리에 있었다. 후에

미국의 대통령이 되는 그는 이제 막 태동하고 있던 미국의 커다란 문제를 해결할 수 있는

길을 보았다. 당시 미국은 영토를 지키고 국경을 넓히는 데 필요한 무기가 턱없이 부족했다.

만약 교환 가능한 부품을 쉽게 생산할 수 있다면, 상대적으로 덜 숙련된 작업자도 많은 총

을 낮은 비용으로 제작할 수 있을 거로 생각했다. 이것은 총을 살 돈도, 총을 만들어 낼 장

인도 부족하던 미국에 커다란 선물이었다.

교환 가능한 총포 부품을 만들 수 있는 정밀한 제조공정의 설계는, 당시에 조면기(繰綿機:

cotton gin) 특허를 냈던 일라이 휘트니3가 맡았다. 1798년 휘트니는 2년간 1만대의 총을 납

1 Honoré Blanc,프랑스총포제작자로부품을교환가능하게만든선구자.

2 그전까지장총은산재한장인들에의해한번에한자루씩생산되었다.만일통기의부품하나가망가지면바로그통을마든장인이

생산한부품음로만바꿔끼울수있었다.

3 EliWhitney,미국의기계발명가.간단한구조의조면기를발명하였으며호환식생산법으로대량생산의기초를마련함.

1■역 사ㅣ History

2

History _1

품하는 정부 계약을 따냈다. 10년이 지나고, 비용을 한참 초과한 후에야 총이 납품되었는

데, 그 때도 부품들이 완전히 교환 가능하지는 않았다. 그럼에도 불구하고 휘트니는, 반쯤

숙련된 작업자가 기계 공구와 정밀 지그4를 이용하여 표준 부품을 만들고 조립하여 제품을

만드는 ‘미국식 제조 방식’을 개발한 중추적인 인물로 평가되고 있다.

1800년대 미국은 산업 강국으로 눈부시게 성장했는데 이는 새로운 제조 방식 덕분이었다.

그동안 유럽에서는 공방 생산방식craft production을 대체하는데 대한 저항이 강했다. 프랑스에

서는 정부의 규제를 받지 않는 작업자가 장총을 조립하게 되면 총포 제작에 대한 통제권을

잃어버릴 것을 두려워한 정부가 오노레 블랑의 일을 중단시켰다. 영국에서는 방적(紡績)과

직조(織造)를 자동화한 기계가 발명되자 직업을 잃을지도 모른다고 생각한 화난 군중이 그

기계 발명가를 공격하였다. 그러나 노동 인력이 부족하고 공방 제작의 전통이 거의 없었던

미국에서는 교환 가능한 부품이라는 새로운 산업 모델이 뿌리를 내리고 번창할 수 있었다.

대체 가능한 인력

1914년 1월 미국 디트로이트. T 모델 조립라인을 가동하기 시작하면서 헨리 포드Henry Ford

는 노동자들의 임금을 2.4 달러(하루 9시간 기준)에서 5 달러(하루 8시간 기준)로 인상했

다. 언론은 그가 미쳤다고 했지만 사실 그의 결정에는 빈틈이 없었다. 포드는 차 한 대당

필요 인력을 85% 이상 줄였기 때문에 2배로 인상된 임금을 충분히 감당할 수 있었다. 그

는 그 전에 이미 차량의 판매가를 현저히 낮췄는데, 이제 임금을 올리고 근무시간을 줄이면

차를 소유할 돈과 시간을 가진 중산층을 만들어낼 수 있었던 것이다.

차 한 대를 조립하는데 12시간 이상이 걸렸던 예전과는 달리 이제 90분이면 되었다. 그

렇다면 나머지 시간들은 어디로 간 것일까? 포드의 경영진은 효율성 전문가인 프레드릭

윈슬로우 테일러Frederick Winslow Taylor의 생각에 따라 생산라인의 작업을 설계하였다. 테일러

는 대부분의 고정급료 노동자들이 어떻게 하면 일을 천천히 할 수 있을지 궁리하는데 시간

을 쓴다고 믿었다. 왜냐하면, 노동자들의 효율성이 높아지면 시간 외 수당이 없어지고, 직

업 자체도 위협을 받을 수 있기 때문이었다. 그가 취한 해결책은 조립 라인을 아주 작은 단

4 jig.측정을위한기판/구조물을통칭함.

3

1_ 역사

계로 나누고 노동자들의 작업 시간을 측정하여 각 단계를 수행하는 ‘유일한 최선의 방법one

best way’을 찾아내는 것이었다.

조립라인에서의 작업은 지루하고 반복적이며 철저하게 통제되었다. 노동자들은 작업 방

법을 배우고 그 작업을 얼마 만에 완료해야 하는지 들었다. 그들을 교육하는데는 10분이면

충분했고, 그것은 다른 사람으로 교체하는 것도 10분이면 충분하다는 의미였다. 1세기 전

의 교환 가능한 부품과 마찬가지로, 이번에는 대체 가능한 노동자가 새로운 산업 모델의 중

심이 되었다. 대량 생산이 시작된 것이다.

다양성과 자율성을 통제하더라도 높은 임금으로 무마가 될 것이라고 믿었고, 얼마 동안

은 실제로 그러했다. 그 동안 포드는 승승장구했다. 매출이 치솟았고 시장을 장악했다. 그

러나 얼마 후 T 모델은 구식이 되었고, 점점 더 부유해지던 중산층은 오래된 차를 더 멋진

세단형 차로 바꾸고 싶어 했다. 포드는 이에 대한 대응이 느렸다. 그의 생산 시스템은 오직

한 종류의 차를 생산할 때만 가장 효율적이었기 때문이었다. 한편 제너럴 모터스의 알프레

드 슬론Alfred P. Sloan은 시장을 나누어 공략하기 위해 여러 모델을 생산할 수 있도록 조직을 구

성하였다. 다양성과 복잡성에 대한 요구가 증가하면서 포드의 생산 시스템은 점점 더 감당

하기 어렵게 되었다.

또한 시간이 지남에 따라 노동자들은 자신들이 견디기 어려운 작업 환경에 갇혀 있다고

느끼게 되었다. 그들은 높은 생활 수준에 익숙해졌지만 다른 직업에서는 그만한 급료를 받

을 수가 없었다. 1930년대 미국에 널리 퍼져 있던 고용 불안의 원인을, 노동자들을 존중

하지 않고 대체 가능한 존재로 간주했던 당시의 시스템에서 찾는 경우도 종종 있다.

도요다 가문

1927년 2월 일본 아이치 현의 가리야 시. 도요다 자동 직조기 社는 직조 기술자들에게 회

사의 새로운 직조기를 전시하는 박람회를 개최했다. 참석자들은 먼저 고정밀 공작기계로

도요다 직조기를 생산하는 과정을 보았고, 이어서 520개의 도요다 직조기가 가동중인 실

험 단계의 방직설비를 둘러보았다. 그 직조기들은 보는 것 자체가 경이로움이었다. 그것들

4

History _1

은 분당 240번의 놀라운 속도로 북침5을 하고 있었고, 전체 설비가 겨우 20명의 직공에 의

해 가동되고 있었다. 게다가 그 직조기들은 야간 근로를 폐지하는 법안을 예상하여 사람이

돌보지 않아도 자동으로 밤새도록 돌아갈 수 있도록 제작되었다. 직조기 좌우를 오가는 베

틀 북에 실이 떨어지면 새로운 북으로 매끄럽고 안정적으로 교체되었다. 만약 수백 개의 날

실 중 하나가 끊어지거나 씨실이 바닥나면 직조기는 동작을 멈추고 직공에게 문제를 해결하

라는 신호를 보냈다.

도요타6 생산방식Toyota Production System을 이해하려면, ‘완벽한 직조기’를 개발하고 제조하는

것이 얼마나 어려운지 이해하는 것이 중요하다. 도요다 사키치(豊田 佐吉)는 1896년 처음

으로 동력 직조기를 만들었고 1903년에 자동 북 교환 장치를 만들었다. 그러고는 50대의

도요다 북 교환 직조기를 비슷한 수의 유럽제 단순 동력 직조기와 비교하는 시험을 실시하

였는데 결과는 실망스러웠다. 그 당시 도요다 직조기는 복잡하고 정밀도가 떨어졌으며, 자

주 멈추는데다 유지보수도 어려웠다.

도요다 사키치는 뛰어난 기술자들을 모집하였는데, 특히 미국식 제조 방식을 도입하기

위해 미국인 엔지니어인 찰스 A. 프란시스Charles A. Francis를 영입하였다. 프란시스는 제조설

비를 다시 설계하고 그것을 만들어내기 위한 기계가공실을 만들었다. 그는 표준 스펙을 개

발하고 표준 게이지와 지그를 만들었으며 제조라인을 재구성하였다. 같은 시기에 도요다

사키치는 더 큰 철제 직조기를 설계하였고 1909년에는 월등히 자동화된 북 교환 방식으로

특허를 획득하였다. 그 후 10년간 전쟁이 유럽과 미국을 휩쓸었고 도요다 사키치의 직조기

는 불티나게 팔려나갔다.

도요다 사키치가 고정밀 부품들은 교환 가능하게 만들 수 있었지만, 사람을 교체 가능하

게 하는 것은 직조기 제조 사업의 특성상 불가능한 일이었다. 자동 직조기는 복잡한 고정

밀 장비로, 물성 변화에 매우 민감하며 원활하게 운용하는 것 자체가 큰 도전이다. 따라서

25~30대의 장비를 셋업하고 동시에 돌리기 위해서는 매우 숙련된 직공이 필요했다. 한편

직조기를 돌리는데 솜씨가 필요하다면, 자동 직조기를 설계하고 제조하는데는 훨씬 더 많

5 직물의가로방향으로걸쳐진실을위사라고하며이위사를걸치는것을북침이라고한다.

6 본래'도요다'의영문표기는'Toyoda'이지만도요타자동차를설립하며서'Toyota'로바꾸었다.작명학자의조언에의한것으로일본어

가타카나로표기했을때トヨタ(도요타)는トヨダ(도요다)와비슷하지만두획이적다.더구나영문TOYOTA가더기억하기쉽고일

본어표기로는전체가8획이되어행운을의미하였다.일본에서행운의숫자8은한자八의글자모양에서비롯하는것으로두획이아

래쪽에서넓게퍼져있어앞으로좋은시절이오거나,좋은일이있을것을암시한다고본다.

5

1_ 역사

은 자질이 필요했다. 도요다 사키치는 대학에서 교육받은, 최고로 역량있는 엔지니어를 채

용하는 것으로 유명하였다. 그는 새로운 회사를 시작할 때도 이 개발팀을 그대로 유지하였

으며, 직조기 설계와 제조에 관한 연구를 할 때도 그들에게 의존하였다.

1921년 도요다 사키치의 아들 키이치로(喜一郎)는 아버지 회사에 합류하여 직조기 자동

화에 몰두하였다. 1924년에 도요다 부자는 개선된 자동 북 교환 방식으로 특허를 공동 출

원하였다. 연구팀은 다시 직조기 가동중에 발생하는 문제를 인지하고 가동을 멈추게 하는

방법을 고안하여, 야간에 지켜보는 사람 없이도 직조기를 가동할 수 있게 하였다. 도요다

키이치로는 새로운 직조기를 생산하는 공장을 짓고 시험 운전하는 총 책임을 맡았으며, 그

중 520대를 도요다 시험 직조실에 배치하였다. ‘완벽한 직조기’를 자랑스럽게 시연해 보이

자 주문이 폭주했다. 키이치로는 여기서 발생한 수익으로 자동차 제조를 시작하였고, 본인

이 직접 디트로이트를 견학하여 수년간 엔진 제작 방법을 배웠다. 1936년 도요다의 첫 양

산 차량은 시장을 강타했지만 얼마 지나지 않아 전쟁 때문에 제조가 중단되었다.

도요타 생산방식

1949년 10월, 일본 코로모. 전후 일본에는 승용차 생산에 대한 규제가 가해지고 있었다.

1945년 도요다 키이치로는 ‘미국을 따라잡자’는 캐치프레이즈를 내걸었지만 미국의 대량

생산 모델을 답습해서는 승산이 없었다. 대량 생산은 수천 개의 동일한 부품을 만듦으로써

규모의 경제를 실현하는 것인데, 당시 일본은 자원이 부족했고 주문은 띄엄띄엄 있었으며

다양한 제품 구색이 요구되고 있었다. 규모의 경제는 한 마디로 실현이 불가능했다.

도요다 키이치로의 비전은 모든 부품이 필요할 때 ‘적시에Just-in-Time’ 조립라인에 도착하는

것이었다. 이는 창고에 보관된 부품을 가져오는 것이 아니라, 필요해지기 직전에 부품을

만드는 방식을 말한다. 이러한 도요다의 비전은 카이치로 사망 10년 후인 1962년, 도요타

생산방식이 전사에 적용되면서 뒤늦게 실현되었다.

6

History _1

오노 다이이치

오노 다이이치(大野 耐一)는 원래 기계 공장장이었는데, 도요다 키이치로의 도전과 비전에

감동하여 훗날 도요타 생산방식으로 명명된 획기적인 생산방식을 만들어 낸 사람이다. 그

는 포드의 생산 시스템을 연구했으며, 미국 슈퍼마켓의 재고관리 방법에서 영감을 얻었다

고 한다. 여기에 방직에 대한 오노 다이이치의 지식과 그가 감독하던 작업자들의 통찰력이

더해졌다. 수년간의 실험을 거쳐 점증적으로 도요타 생산방식이 만들어졌는데, 오노는 그

과정을 영원히 끝나지 않는 것으로 보았다.

그의 저서 『도요타 생산방식』7에서 오노는 도요타 생산방식을 ‘철저하게 낭비를 제거하는

생산방식’ 이라고 말했다. 이 책에서 그는 이것을 받치는 두 개의 축이 적시생산흐름Just-in-

Time flow과 자동화(自働化)라고 하였다.

적시생산흐름Just-in-Time Flow

적시생산흐름은 그 당시의 모든 통념과는 완전히 반대였다는 사실에 주목해야 한다. 오노

의 시도에 대한 반발은 엄청났지만, 그는 키이치로의 사촌이며 키이치로가 떠난 1950년

이 후 여러 부서에서 고위 경영자를 지낸 도요다 에이지(豊田 英二)의 후원을 받아 성공할

수 있었다. 두 명의 도요다는 앞으로 전개될 게임은 규모의 경제가 아니라 복잡도를 정복하

는 것이란 사실을 똑똑히 인지하고 있었다. 규모의 경제에서는 물량이 2배로 늘어날 경우

단위당 비용을 15~25% 줄일 수 있지만, 다양성이 2배가 되면 비용은 20~35% 증가한

다.8 적시생산흐름은 다양성에 의해 초래되는 주요 비용 증가 요인들을 제거한다. 사실 이

것은 복잡도를 효과적으로 통제할 수 있는 우리가 가진 유일한 산업 모델이다.9

자동화(지도카)

도요다 직조기는 직공이 없이도 돌릴 수가 있었는데, 이것은 뭔가가 잘못되면 직조기가 이

를 감지하고 자동으로 가동을 중지시키기 때문이었다. 일본어로 ‘지도카’ 인 자동화는 매우

사소한 이상도 즉시 감지하여 하던 일을 중단하고, 문제 원인에 대한 조치를 한 이후에 다

7 이절은TaiichiOhno,ToyotaProductionSystem:BeyondLarge-ScaleProduction,ProductivityPress,1988.(1978년일본어로쓰

여지고1988년영어로변역됨)에서인용하였는데,이책은매우읽기쉽고오늘날에도강력추천되는훌륭한저서이다.

8 GeorgeStalk,“Time—TheNextSourceofCompetitiveAdvantage,”HarvardBusinessReview,July1988.

9 4.FreddyBalleandMichaelBalle,“LeanorSixSigma,”www.lean.org/library/leanorsigma.pdf참조.

7

1_ 역사

시 일을 시작하는 것을 의미한다. 이 중요한 개념을 ‘라인정지stop-the-line’라고도 부르는데 아

마도 이 이름이 더 기억하기 쉬울 것이다.

오노는 자동화autonomation를 ‘인간의 손길을 부여한 자동화automation10’ 라고 불렀다. 그는

이 개념을 이해할 수 있는 또 다른 방법으로, 이와 관련된 용어인 ‘자율적인autonomic’이라는

단어에 주목하였다. 우리의 몸은 호흡, 심장 박동, 소화와 같은 반사신경을 조절하는 자율

신경계를 가지고 있어서 우리가 뜨거운 것을 만지면 자율 신경계는 뇌가 신호를 보낼 때까

지 기다리지 않고 즉시 손을 뒤로 빼게 한다. 자동화autonomation는 조직이 두뇌의 지시를 받

지 않고 사건에 대해 즉시 그리고 올바르게 반응하는 적절한 반사 신경을 갖고 있음을 의미

한다.11

신고 시게오

신고 시게오(新郷 重雄)는 오노가 도요타에서 도요타 생산방식을 구현하는 것을 도왔고, 후

에 전 세계의 기업들이 그 방식을 이해하고 구현하는 것을 컨설팅한 컨설턴트이다. 우리

는 80년대 초반에 적시 생산방식을 구현하고 있었는데 그 당시 적시 생산방식에 대한 최초

의 번역서인 ‘녹색 책12’을 아직도 기억하고 있다. 번역이 좋지 않았고 내용도 무겁고 기술적

이었만 놀라울 정도로 통찰력을 보여주는 책이었다. 신고는 이 책에서 무재고 생산nonstock

production과 무검사zero inspection를 두 가지 주요 테마로 다루고 있다. 자세히 살펴보면 실제로

이것들은 오노가 말하는 도요타 생산방식의 두 기둥과 공학적으로 동치임을 알 수 있다.

무재고 생산

적시생산흐름은 규모의 경제라는 명목으로 만들어지곤 했던 프로세스 상의 비축 재고를 없

애는 것을 의미한다. 모든 것을 소량으로 만드는 것이 핵심이었고 이를 위해서는 장비가 어

떤 부품을 만들다가도 신속하게 전환하여 다른 부품을 만드는 것이 가능해야 한다. 소프트

웨어 개발에서 셋업 시간을 파악하기 위한 한 가지 방법은 소프트웨어 배포에 필요한 시간

을 파악하는 것이다. 어떤 조직은 새로운 소프트웨어를 배포하는 데 몇 주 또는 몇 달이 걸

10 일반적인자동화는自動化(automation)인반면여기서의자동화는사람인변의自働化(autonomation)이다.

11 TaiichiOhno의5)번각주와동일함,p.46,

12 ShigeoShingo,Studyof‘Toyota’ProductionSystem,ProductivityPress1981.

8

History _1

리기 때문에 한 번의 릴리스에 최대한 많은 기능을 넣으려 한다. 이것은 각 릴리스에 대해

대량의 일괄 테스팅, 교육, 통합 작업을 필요로 한다. 반면에 나는 새로운 바이러스가 발

견되면, 몇 시간 이내에 충분히 테스트 된 상태로 내 컴퓨터의 바이러스 백신 소프트웨어가

내 컴퓨터에 업데이트되기를 바란다. 변경의 규모가 작을 것이므로 일반적으로 통합과 교

육은 중요한 문제가 아닐 것이다.

무검사

자동화autonomation의 기저에 깔린 생각은, 시스템은 반드시 실수 방지설계가 되어 있어야 한

다는 것이다. 절대로 장비가 고장났는지 살펴보거나 제품에 문제가 있는지 없는지 테스팅

하는 사람이 있어서는 안된다. 적절하게 실수 방지가 된 시스템은 검사가 필요없다. 우리는

비디오 케이블에서 실수 방지 사례를 접할 수 있다. 모니터 케이블을 컴퓨터나 비디오 프로

젝터에 위 아래를 뒤집어서 꼽는 것은 불가능하다. 왜냐하면, 케이블과 플러그에는 키key가

새겨져 있기 때문이다. 따라서 내가 플러그를 잘 꼽았는지 누군가가 검사해 줄 필요가 없다.

잘못 꼽는 것이 불가능하기 때문이다. 실수 방지설계를 할때는 “저지를 가능성이 있는 실수

는 언젠가 반드시 저지르게 된다” 고 가정한다. 따라서 프로젝트 시작시점부터 실수를 저지

르는 것 자체가 불가능하도록 하는 활동에 시간을 할애해야 한다.

적시 생산방식(Just-in–Time)

도요타 생산방식은 1973년 석유 파동이 발생할 때까지는 일본에서조차 무시되고 있었다.

회사들이 빠르게 성장하고 있었고 만들어낸 제품은 모두 팔려나갔기 때문이었다. 그러나

석유 파동에 따른 경제 침체는 그저 그런 회사들과 뛰어난 회사들을 가려내는 계기가 되었고,

도요타는 이런 상황에서 업계의 강자로 급부상할 수 있었다. 도요타 생산방식은 많은 일본

회사들의 연구대상이 되었고 그 중의 상당 부분은 실제로 채택되었다. 그로부터 10년도 채

지나지 않아 미국과 유럽은 일본과의 치열한 경쟁을 경험하게 된다. 일례로 내가(메리) 80

년대 초반에 비디오 카세트 공장에서 일하고 있었을 때 일본 경쟁사가 현저하게 낮은 가격

으로 시장을 잠식해 들어왔다. 조사해보니 일본 회사들은 적시 생산방식이라는 새로운 방

식을 사용하고 있음을 알 수 있었고, 우리도 경쟁력을 유지하기 위해 그 방식을 적용하였다.

그림 1.1은 공장에서 적시 생산방식을 설명하기 위해 우리가 사용했던 그림이다.

9

1_ 역사

그림 1.1 ㅣ 재고를 줄이면 문제가 드러난다.

재고는 강물의 수위다. 수위가 높으면 물속에 숨어있는 커다란 바위들이 나타나지 않지만

수위를 낮추면 수면 위로 드러나게 된다. 그 때, 그 커다란 바위들을 치워야 한다. 그렇지 않

으면 배가 바위와 부딪치게 될 것이다. 커다란 바위들을 제거하고 나면 수위를 더 낮춰서 더

많은 바위들이 드러나게 할 수 있을 것이고, 이 일을 반복하면 결국 자갈들만 남게 될 것이다.

재고를 많이 유지하고 바위들을 무시해도 되지 않을까? 사실 그 바위들은 발견되지 않고

제품에 숨어드는 결함, 통제되지 않는 불안정한 공정, 보존기간이 만료되기 전까지는 팔리

지 않을 완성품, 재고를 추적하지 못하는 재고 추적 시스템과 같은 것들이다. 그 바위들은

재고가 줄어들 때까지는 나타나지 않는, 엄청난 비용을 초래하는 숨은 낭비들이다.

적시 생산방식을 통해 얻을 수 있었던 핵심적인 교훈은 지역적 효율을 극대화하려는 노력

을 멈추어야 한다는 것이었다. 우리는 많은 고가의 장비들을 놀릴 수 없기 때문에 항상 최

대 생산성으로 가동해야 한다고 생각했다. 그러나 그것은 단지 재고만 늘리는 결과를 가져

왔다. 각각의 장비를 항상 가동할 수 있도록 장비 입구에 원자재를 재고로 쌓아 두었고, 만

들어진 반제품은 갈 곳이 없어서 장비 출구에 재고로 쌓여 갔기 때문이었다. 적시 생산방식

을 적용하고 나서는 재고가 사라지게 되었는데, 장비 가동률을 최대로 올리려는 노력을 그

만두자 공장의 전체적인 생산성이 오히려 향상되는 것을 발견하고 우리는 놀라지 않을 수

없었다.

10

History _1

그림 1.2 ㅣ 지역적 효율을 극대화하려는 노력을 중단하라.

Story 라인정지와 안전의식

적시생산 실천법 중 상대적으로 적용이 쉬웠던 것은 라인정지 문화다. 우리의 비디오 테이프

공장은 다소 휘발성이 있는 물질을 원료로 쓰고 있었기 때문에, 작업장 내에서 강력한 안전

프로그램을 운용하고 있었다. 그러한 안전 프로그램을 통해 우리는 매우 작은 사고조차도 철

저히 조사해야 한다는 것을 이미 알고 있었다. 작은 사고를 소홀히 다루면 후에 엄청난 재앙

을 가져올 수 있기 때문이다.

윅Weick과 서클리프Sutcliffe의 『Managing the Unexpected』13에 의하면 우리 공장과 같은 조

직은 늘 깨어있는 마음mindfulness의 상태를 유지함으로써, 안전에 대해 주의를 기울이는 환경

을 만들어 낸다고 하였다. 저자는 늘 깨어있는 마음에 다음과 같은 다섯 가지 특징이 있다고

하였다.

1. 실패에 대한 주의

무엇이 잘못될 수 있는지 알아내고 이에 대비하는데 많은 시간을 쓴다.

2. 단순화에 대한 저항

크고 복잡한 공장에서 안전은 크고 복잡한 이슈이다.

13 KarlE.WeickandKathleenM.Sutcliffe,ManagingtheUnexpected:AssuringHighPerformanceinanAgeofComplexity,

Jossey-Bass,2001.

11

1_ 역사

3. 운영상의 예민함

공장의 모든 관리자는 상당 시간을 라인에서 일해야 한다.

4. 실수로부터 배우겠다는 다짐

매우 사소한 사건도 철저히 조사하여 이같은 일이 절대 재발하지 않도록 예방하는 조치

를 취한다.

5. 전문지식에 대한 존경

모든 관리자들은 현장의 작업자들이 공장이 어떻게 돌아가는지를 제대로 이해한다는 것

을 안다.

우리는 안전에 대한 우리의 문화를 어렵지 않게 라인정지 문화로 발전시킬 수 있었다. 사고

에 관한 주의에 추가적으로 결함에 대한 주의를 보탰다. 사후검사를 없애기 위해 모든 운용

단계마다 실수 방지 방안을 고안하였다. 결함이 발생할 때마다 작업팀은 제품 생산을 중단하

고 문제의 근본 원인을 조사했다. 만약 결함이 있는 재료가 사전에 검출되지 않고 공정에 들

어가는 일이 발생했다면, 그러한 일이 재발하지 않도록 하는 방안을 고민하였다. 여기서 ‘우

리’란 공장의 생산 근로자들을 의미한다. 바로 그들이 그 공정을 처음으로 설계한 사람들이

기 때문이다.

- 메리 이야기

그림 1.3 ㅣ 간판Kanban 방식에 따라 재고 수레를 시뮬레이션 하는데 사용된 커피 컵

Asd

lkjp

123

a

Asd

lkjp

123

a

qr3c

d 12

3a

Po

d63

123a

Asd

lkjp

123

a

Po

d63

123a

q r3 c

d 1 2

3 a

12

History _1

공장을 적시 생산방식으로 바꾸기로 결정했을 당시, 주변에 우리를 지도해 줄 컨설턴트

가 거의 없었기 때문에 스스로 그 방법을 고안하기로 했다. 우리는 대형 회의 탁자를 커다

란 갈색 종이 한장으로 덮고 그 종이에 전체 공정을 그려서 시뮬레이션을 했다. 인덱스 카

드에서 잘라낸 띠에 재고 품목을 표기하여 ‘간판카드’14를 만들었고 이 재고 품목 띠를 커피

컵에 넣었더니, 해당 재고로 가득찬 수레가 되었다(그림 1.3 참고). 보라, 멋지지 않은가!

그러고 나서 우리는 일주일 분량의 출하 주문을 출력하고 그 주문에 대응하기 위해, 커피

컵들과 공정을 그린 커다란 종이를 마치 게임판처럼 사용하여, 당김 생산방식Pull System을 시

뮬레이션 하였다. 컵의 재고가 바닥나면 그 재고 띠(간판카드)는 이전 공정으로 넘겨졌고,

이전 공정은 그 간판을 물건을 더 만들라는 신호로 인식하게 했다.15

이러한 수작업 시뮬레이션을 통해, 당김 생산방식의 개념을 생산부장, 일반 감독자, 그

리고 교대 감독자에게 순서대로 보여주었다. 마침내 교대 감독자들은 자신이 관할하는 모

든 작업자들과 그 시뮬레이션을 돌려보게 되었다. 그리고 생산의 각 영역별로 이러한 새로

운 당김 생산방식을 그들의 환경에서 어떻게 적용해야 하는지 세부 방안을 마련하도록 요청

했다. 세부적인 준비에 몇 개월이 걸렸지만 마침내 모든 것이 준비되었다. 주말에 전체 공

정을 당김 생산방식으로 완전히 전환하면서 우리는 마음을 졸이지 않을 수 없었다. 전산화

된 스케줄링을 중단하고 이를 간판에 의한 수작업 스케줄링으로 대체한 것이다. 결국, 우리

의 적시 생산방식은 즉각적이고도 엄청난 성공을 가져다 주었는데, 그 성공의 대부분은 세

부 사항이 현장 작업자들에 의해 설계 되었다는 것에 기인한다. 현장 작업자들 또한 이 과

정을 통해 돌발 상황들에 대처하는 방법과 끊임없이 공정을 개선하는 방법을 배우게 되었다.

린

1990년에 출간된 『The Machine That Changed the World』16에서는 이전에 적시 생산방식 또는

도요타 생산방식으로 불리던 것에 새로운 이름을 붙였다. 그 때부터 제조부문의 도요타식

14 도요타에서사용하는부품상자에는어른손바닥크기의전표가붙어있고여기에사용한부품의양이표시된다.이것이Kanban이며

우리말로는‘간판’으로불리고있다.

15 이러한스케줄링방법을간판방식이라고부르며,각공정이무엇을만들어야하는지를보여주는토큰을간판이라고부른다.

16 JamesWomack,DanielJones,andDanielRoos,TheMachineThatChangedtheWorld,RawsonAssociates,1990.

13

1_ 역사

접근방식이 린 생산으로 알려지게 되었다. 그 후 몇 년간 많은 회사들이 린 생산방식을 적

용하려고 하였지만 그것은 매우 어려운 일이었다. 여느 신규 생산방식 모델과 마찬가지로

이 방식도 기존 모델에 많은 투자를 한 조직의 거센 저항을 받아야 했다.

많은 사람들이 린은 반직관적이고, 오랜 기간에 걸쳐 확립된 기존 방식을 대체할 만한 강

한 동기가 결여되었다고 생각했다. 꽤나 많은 회사들이 린 생산방식의 일부만 구현하였는

데, 가령 밀접하게 연관되어 있는 ‘라인정지’ 없이 ‘적시생산’만을 적용하려고 하는 식이다.

그들은 “진정한 린 공장은...생산라인에서 자동차에 실제로 가치를 불어넣는 작업자들에게

최대한의 작업과 책임을 부여한다는 것과, 결함을 검출하고 한번 검출되면 그 근본적인 원

인까지 빠르게 추적하는 결함 추적 시스템을 가지고 있다.”는 핵심을 놓치고 있었다.17

일반적인 개념과 반대되는 새로운 패러다임을 구현할 때 겪는 난관에도 불구하고, 린의

여러 독창적인 방법들은 큰 성공을 낳았고 진정한 린 비즈니스를 만들어내며 꾸준히 번성하

게 되었다. 린 사고방식은 제조로부터 시작하여 주문처리, 소매 판매, 항공기 유지보수와

같은 분야로 전파되었다. 린 원칙은 또한 공급망, 제품 개발, 그리고 소프트웨어 개발까지

확장되었다. 그림 1.4를 참조하라.

그림 1.4 ㅣ 린 가계도(家系圖)

17 14)번각주참고문헌의99페이지.이탤릭체강조는원문내용임.

린

제조

도요타 생산방식

공급망

(가상 통합)

계열*

제품 개발

소프트웨어 개발

도요타 제품개발방식

운영

* 계열, 일본은 다수의 기업들이 '게이레츠(系列: keiretsu)'라고 불리는 기업집단에 속해 있으며 계열소속 기업 간에 금융기관을 중심으로 주식을 상호 보유함으로써 기업 간 장기적 유대관계와 결속 등 상호협력을 도모하는 구조를 갖고 있다.

14

History _1

린 생산방식 / 린 운영

오늘날 린 생산방식은, 규범과 효율성과 효과성에 대한 기준을 제시한다. 사실 린 원칙을

생산에 적용하는 것은 다른 회사가 따라하기가 거의 불가능한 경쟁 우위를 갖게 해 주었다.

예를 들어, 델 컴퓨터의 다품종 주문 생산방식은 ‘주문제작’ 컴퓨터를 거의 어김없이 2,3일

내에 공급하는데, 이런 묘기는 기존의 유통 체계를 포기하지 못하는 경쟁사들로는 절대로

쉽게 따라할 수 없는 것이다. 린은 비제조 분야에도 전파되었다. 타 항공사들이 대량 일괄

수송 스타일인 대도시 터미널 집중 방식hub-and-spoke system을 버리지 못하고 있을 때, 사우스

웨스트 항공은 A 지점에서 B 지점으로 직접 이동하는 방법을 도입했다. 몇몇 업계(예를 들

어 신속 배송 서비스업 같은)는 린 원칙에 근거하여 그 구조가 형성되었는데, 이러한 업계

에서는 린 운영방식을 적용한 회사만이 살아남을 수 있다.

린 공급망

린 생산방식의 실천법이 공장의 구석구석까지 퍼지게 되었다면, 이제 하청업체로 확장해야

한다. 왜냐하면 대량 생산과 린 생산방식은 잘 조화되기 어렵기 때문이다. 도요타는 이것

을 일찍부터 파악하고 하청업체들이 도요타 생산방식을 적용할 수 있도록 독려하고 지원하

였다. 피터 드러커Peter Drucker는 그가 계열Keiretsu이라고 칭한 도요타의 하청업체 네트워크가

경쟁사 대비 25~30%의 비용 우위를 제공한다고 추정했다.18 1980년대 후반 도요타가 미

국으로 건너갔을 때도 도요타는 이와 유사한 하청업체 네트워크를 구성했다. 놀랍게도 미

국 자동차 하청업체들은 공장의 일부는 도요타에 납품을 하기 위해 린 방식으로 운영하고,

나머지는 ‘기존’ 방식대로 운영해야 했는데, 이는 다른 자동차 회사들은 린 방식의 공급업체

를 다룰 수 없었기 때문이다.19 린 공급망은 다른 회사에서 설계되고 제조된 부품들을 조립

해야 하는 델 컴퓨터에도 필수적이었다. ‘가상 통합’을 통해 델은 파트너 업체들이 마치 델

내부에 있는 것처럼 다루고 있는데, 이를 통해 서로 간의 정보를 자유롭게 교환하도록 함으

로써 전체 공급망을 린하게 유지할 수 있었다.

린 공급망에서는 회사들은 회사의 경계를 넘어 끊김없이 매끄럽게 일하는 방식을 배우고,

18 PeterDrucker,ManagementChallengesforthe21stCentury,HarperBusiness,2001,p.33.번역서로는『21세기지식경영』(이재

규역,한국경제신문,2002)가있음.

19 JeffreyDyer,CollaborativeAdvantage:WinningThroughExtendedEnterpriseSupplierNetworks,OxfordUniversityPress,

2000.참조.

ㅣ

15

1_ 역사

개별 회사는 그들의 이익이 전체 공급망의 이익과 연계되어 있다는 것을 숙지하고 있다. 회

사의 경계를 넘어 소프트웨어를 개발하는 조직에게는, 공급망 관리가 별개의 회사들 간에

린 계약관계를 어떻게 형성하고 관리하는지 잘 검증된 모델을 제공한다.

린 제품 개발

렉서스 ES 300의 수석 엔지니어인 야마다 고사쿠Kosaku Yamada는 “도요타와 다른 자동차

회사와의 근본적인 차이는 도요타 생산방식이 아니다. 그것은 도요타 제품개발방식이다”

라고 말했다.20 제품 개발은 운영과는 많이 다르며, 운영에서 성공적이었던 기법들이 개발

에서는 적합하지 않는 경우가 종종 있다. 클라크Clark와 후지모토Fujimoto는 그들이 저술한

획기적인 책 『Product Development Performance』21에서 효과적인 제품 개발이 린 생산방식과

공통점이 많다고 말하고 있다. 표 1.1은 클라크와 후지모토가 기술한 둘 간의 유사점을

요약한 것이다.

표 1.1 ㅣ 린 생산방식과 효과적인 프로젝트 개발과의 유사성22

린 생산방식 린 개발

잦은설정변경 잦은제품변경(소프트웨어릴리스)

짧은생산소요시간 짧은개발기간

제조단계간재공품*재고감소 개발단계간정보재고감소

제조단계간소량부품묶음의잦은이송 개발단계간예비정보의잦은교환

줄어든재고는여유자원과단계간더많은정보흐름을

필요로함

줄어든개발기간은여유자원과단계간정보흐름을필

요로함.

물량변동,혼류생산,제품설계변경에대한적응성 제품설계,일정,비용목표변경에대한적응성

생산작업자에게다기능을부여하여생산성을높임 엔지니어(개발자)에게다기능을부여하여생산성을높임

신속한문제해결과지속적인프로세스개선에집중함 조금씩의잦은변경과지속적인제품과프로세스개선에

집중함

품질과출시일정과제조생산성에대한동시개선 품질과개발일정과개발생산성에대한동시개선

*work-in-process.재공재고라고도하며생산과정중에있는물품을의미한다.

20 GaryS.Vasilash,“EngagingtheES300,”AutomotiveDesignandProduction,September,2001.

21 KimB.ClarkandTakahiroFujimoto,ProductDevelopmentPerformance:Strategy,Organization,andManagement inthe

WorldAutoIndustry,HarvardBusinessSchoolPress,1991.

22 KimB.Clark와TakahiroFujimoto,ProductDevelopmentPerformance,p.172에서인용하여각색하였음.

16

History _1

만약 어떤 회사가 도요타 생산방식의 정수를 추출하여 제품개발에 응용할 수 있다면, 그

첫 번째 후보는 도요타 자신이 될 것이었다. 1990년대에 도요타가 매우 성공적이고 독특한

제품개발 방식을 갖고 있다는 사실이 알려졌을 때, 놀라는 사람은 없었다. 도요타의 접근은

반직관적이면서 동시에 풍부한 통찰력을 갖고 있다. 제조에 특화된 도요타 생산방식의 실천

법을 제품 개발에 적용하려는 시도는 거의 없었지만, 근본적인 원칙은 분명히 그 뿌리가 같다.

개발 프로세스를 통해 나온 제품은 눈부신 것이 될 수도 있고 그저 그런 평범한 것이 될

수도 있다. 세련된 디자인으로 시장을 강타할 수도 있고 고객과 수익의 기대치에 미치지 못

할 수도 있는데, 도요타의 제품은 늘 첫 번째 범주에 들어가곤 했다. 도요타를 지켜본 사

람들은, 그 공이 수석 엔지니어의 리더십에 있다고 말한다. 수석 엔지니어는 제품의 사업

적 성공에 대한 책임을 지는데 그는 시장이 원하는 것이 무엇인지를 파악하는 예리한 시각

과 시스템 설계를 지휘할 수 있는 기술적 역량을 모두 가진 사람이다. 『도요타 방식The Toyota

Way』23에서 제프리 라이커Jeffrey Liker는 렉서스와 프리우스의 개발에 얽힌 이야기들을 풀어놓는

다. 거기에는 두명의 뛰어난 수석 엔지니어가 등장하는데 그들이 어떻게 이런 획기적인 제

품을 기록적인 시간 내에 시장에 출시할 수 있었는지가 상세히 설명되어 있다.

제품 개발은 지식을 창조하는 과정이다. 도요타의 제품개발방식은 설계 영역에 대한 광

범위한 탐색, 다수의 프로토타입에 대한 실제 실험, 새로운 설계에 대한 평가, 가능한 많은

상세 정보에 기반한 의사결정이 이루어지는 정기적인 통합 미팅을 통해 지식을 생성한다.

제품 개발과 생산에서 얻어진 암묵지를 간략하고 유용한 한 페이지의 문서로 요약하여, 그

지식을 효과적으로 형식지로 만든다.24 향후의 활용을 위해 지식을 생성하고 보존하는 것은

도요타 제품개발방식의 가장 큰 특징이다.

국립 제조과학센터NCMS는 도요타 제품개발방식에 대한 다년간의 연구를 수행하였는데,

그 결과는 마이클 케네디Michael Kennedy가 쓴 『Product Development for the Lean Enterprise』25에

요약되어 있는데, 그는 이 책에서 도요타 제품개발방식의 4가지 핵심 요소를 식별해냈다 (그

림 1.5 참고).

23 JeffreyLiker,TheToyotaWay:14ManagementPrinciplesfromtheWorld’sGreatestManufacturer,McGrawHill,2004.번역서로

는『도요타방식』(김기찬역,가산출판사,2004)이있음.

24 지식은형식지(形式知,explicitknowledge)와암묵지(暗默知,tacitknowledge)로구분할수있다.형식지란누구나이해하고다른사

람에게전달할수있는형태의객관적지식을의미하고,암묵지란어떤유형이나규칙으로표현하기어려운주관적이고내재적인지식

을의미한다.

25 MichaelKennedy,『ProductDevelopmentfortheLeanEnterprise:WhyToyota’sSystemIsFourTimesMoreProductiveand

HowYouCanImplementIt』,OakleaPressPress,2003.

17

1_ 역사

그림 1.5 ㅣ 도요타 제품개발방식의 핵심 요소26

도요타 제품개발방식

도요타 제품개발방식에는 다음의 4가지 핵심 요소가 존재한다.

1. 기업가적 정신을 가진 리더에 의한 시스템 설계

도요타의 수석 엔지니어는 제품의 사업적 성공에 대한 책임을 진다. 수석 엔지니어

는 매우 경험이 많은 엔지니어로서 시스템 수준의 설계를 작성할 수 있는 충분한 역

량을 가진 사람이다. 그러나 그는 목표 시장에 대한 깊은 이해를 바탕으로 고객을

기쁘게 할 차를 개발해야 하는 책임도 진다. 수석 엔지니어는 신제품에 대한 비전을

만들어 개발팀에 전파하고, 매일매일 의사결정을 하는 현장 엔지니어들과의 대화를

통해 생각을 늘 신선하게 유지한다. 필요한 경우 비전을 지켜내고 의견 불일치가 일

어난 경우 타협을 중재한다. 또한 일정 계획을 세우고 프로세스를 수정하여 모든 것

이 정해진 시간에 완료될 수 있게 한다.

26 이그림은MichaelKennedy의동일한책p.120에서발췌한것으로허가받아인용하였음.이책에서는가치흐름을크게개발가치흐

름(Developmentvaluestream)과운영가치흐름(Coperationalvaluestream)으로구분하고있다.개발가치흐름은회사의운영가치

흐름을만들고,회사는운영가치흐름을통해고객에게가치를제공하여이윤을창출한다.

지식기반 공학(린 개발 방식)

고객을 위한 운영 가치흐름

전문 기술 인력

책임 기반의 계획과 통제

시스템 설계자의 기업가적 리더십

집합 기반 동시공학

고객을 위한 운영 가치흐름은 4가지 핵심 요소의 상호 작용에 의해 발현됨

18

History _1

2. 전문 기술 인력

도요다 사키치 시절부터, 도요다 가문과 도요타 회사는 기술적으로 세련된 제품을 설계

하는 최고의 엔지니어들을 보유해왔다. 엔지니어가 특정 분야의 진정한 전문가가 되기

까지는 몇 년의 세월이 필요한데, 도요타에서는 자기 분야를 완전히 마스터하기 전까지

는 엔지니어가 다른 부서로 옮기거나 관리직으로 올라가지 않도록 하고 있다. 관리자는

그들이 관리하는 분야의 마스터였던 사람들로, 엔지니어들을 교육하여 견습생에서 숙련

가를 거쳐 마스터로 길러내는 선생님 역할을 한다.

3. 책임 기반의 계획과 통제

수석 엔지니어는 대략 2,3개월 간격의 주요 동기화 시점들로 구성된 자동차 개발 일정

계획을 수립한다. 엔지니어들은 다음 번 동기화 시점까지 해야 할 일을 알고 있으며 그

시점까지 기대하는 결과를 만들어내야 하지만, 그 중간 과정은 간섭받지 않는다. 만약

엔지니어가 그들의 업무를 수행하기 위해 필요한 정보가 있으면, 해당 정보원으로부터

정보를 ‘당기’도록 한다. 최근에 도요타의 수석 엔지니어들은 선구적으로 ‘오베야Oobeya’

*1 방법을 실행하였는데, 이것은 팀 멤버들이 작업을 수행하고 정기적으로 전체 멤버가

미팅을 하는 큰 방을 뜻한다. 오베야에는 개발 이슈와 현황을 보여주는 커다란 차트가

있다.

4. 집합 기반 동시공학Set-Based Concurrent Engineering

집합 기반 공학은 복수의 설계 영역을 탐색하고 그 옵션들을 점차 줄여나가 최적 솔루션

으로 수렴하는 것을 뜻한다. 이것이 실무에서는 무엇을 의미할까? 결정을 내려야만 하

는 순간까지 매우 조심스럽게 결정을 미뤄야 하며, 최후의 순간에 최대한 많은 정보를

바탕으로 결정을 내릴 수 있도록 옵션들을 유지하는 노력을 기울여야 한다는 것을 의미

한다. 집합 기반 설계의 모순은 지식을 창조하기 위한 이러한 접근이 개발 과정에 중복

을 야기한다는 것이다. 중복은 낭비로 비춰질 수 있다. 그러나 전체 시스템 차원에서 보

면 집합 기반 의사결정은, 개발 팀이 ‘결단력’을 위해 일찍 옵션들을 배제시키는 방법보

다 더 빨리 더 최적의 솔루션에 다가가는 것을 가능케 한다.*2

--------

*1도요타의수석엔지니어인요시다타케시(吉田健)가채택한것으로도요타자동차직원들에게는"자동차생산과관련된모든부

서의사람들(디자인에서부터엔지니어링,생산,물류,그리고영업파트까지)이자동차가생산되기2년전부터적어도한달에한

번씩모여정보를공유하고토론을하는것"을의미한다.

*2 집합기반공학에대한더자세한내용은7장참조.

19

1_ 역사

린 소프트웨어 개발

소프트웨어 개발은 제품 개발의 형태를 띄고 있다. 사실 당신이 사용하는 대부분의 소프트

웨어는 제품 형태로 구입한 것이다. 소프트웨어만으로 제품이 되지 않는 경우로는, 하드웨

어 상에서 돌아가는 임베디드 소프트웨어나 게임의 핵심 기능, 검색 엔진을 들 수 있다. 대

부분의 커스텀 소프트웨어(고객 주문 소프트웨어)를 포함한 일부 소프트웨어는 비즈니스

프로세스의 일부로 개발된다. 고객은 우리가 개발하는 소프트웨어를 구매하는 것이 아니라,

게임이나 워드프로세서, 검색기능, 하드웨어 디바이스, 비즈니스 프로세스를 구매하는 것

이다. 이러한 점에서 볼 때, 대부분의 유용한 소프트웨어는 자신의 코드베이스보다 더 큰

어떤 것에 포함된다고embedded 말할 수 있다.

소프트웨어 개발은 전체 제품 개발 프로세스의 일부이며, 실제 우리가 개발하는 것은 다

름 아닌 소프트웨어를 포함하는 제품, 행위, 프로세스다. 따라서 소프트웨어 개발은 제품

개발의 일부라고 말할 수 있다. 그러므로 린 소프트웨어 개발을 이해하고자 한다면 뛰어난

제품 개발을 해내기 위한 구성요소가 무엇인지를 파악해 두는 것이 좋다.

도요타 생산방식과 도요타 제품개발방식은 동일한 근본 원리로부터 출발하였다. 린 소프

트웨어 개발을 실현하는 첫 단계는 다음 장에서 논의할 그 근본 원리를 이해하는 것이다.

시도해 볼 것

1. 도요타 웹 사이트를 방문하여 지도카Jidoka에 대한 비디오를 보라(www.toyota.co.jp/en/

vision/production_system/video.html).27 1920년대부터 만들어온 세련된 도요타 자동

직조기를 볼 수 있다. 적시생산에 대한 비디오와 도요타 생산방식도 볼만하다.

2. 당신은 일괄처리로 작업하기를 좋아하는가? 만약 당신이 100통의 편지를 보내야

한다면 편지를 접고, 봉투에 넣고, 주소 라벨과 우표를 붙이는 일련의 작업을 어떻

게 수행하고 싶은가? 한 번에 한 통씩 작업하는가, 아니면 각 스텝을 일괄로 작업하

는가? 왜 그렇게 하는가? 두 가지 방법을 모두 해보고 시간을 측정하여 어떤 것이

27 2006년4월에새롭게문을연웹사이트로,그페이지는www.toyota.co.jp/en/에가서TopPage▷Company▷Vision&

Philosophy▷ToyotaProductionSystem▷VideoIntroducingtheToyotaProductionSystem에서도볼수있다.

20

History _1

더 빠른지 보라. 만약 자녀들이 있다면 아이들은 이 문제를 어떻게 접근하는지 물어

보라.

3. 표 1.1은 제조와 제품 개발 간의 유사성을 보여준다. 그 표를 당신의 팀과 검토해보

라. 미완성 작업을 재고로 간주하는 것이 당신의 환경에서도 말이 되는가? 다른 비

유들은 어떤가? 유사성은 양날의 칼이다. 제조와 제품개발 간의 유사성 중 어떤 부

분이 당신을 어리둥절하게 만드는가?

4. 회피: 당신은 똑똑한 사람들로 이루어진 조직을 갖고 있다. 문제가 생기면 이 사람

들은 문제를 회피하려고 하는가, 아니면 라인을 정지시키고 그 근본 원인을 찾는가?

지난 주에 당신 그룹에서 일어났던 10대 문제의 목록을 만들고 각 문제마다 그것을

어떻게 해결했는지 적어보라. 각 문제를 5점 척도(0~5)로 점수를 매겨라. 5점은

그 문제의 원인이 파악되고 제거되어서 재발하지 않을 것 같다는 의미이고, 0점은

그 문제가 다시 발생할 것이라는데 의심의 여지가 없다는 뜻이다. 당신의 전체 점수

는 몇 점인가?

5. 만약 당신의 팀이 본능적으로 문제를 회피한다면 그들은 잘못된 반사신경을 갖고 있

는 것이다! 빌드 실패나 의사소통 오류, 설치 실패나 실무에서 보여줄 만큼 충분히

견고하지 않은 코드와 같은 이상한 점을 용납하지 않도록 하는 문화를 형성하는데

무엇이 필요한지를 브레인스토밍하라. ‘라인정지’ 위원회가 그 아이디어를 검토하게

하고, 처음 적용할 최선의 후보를 선택하라. 선택된 분야에 대해 회피의 문화에서

라인정지의 문화로의 전환을 실행하라. 반사적인 라인정지 습관이 만들어지는 것을

확인하라. 이를 반복하라.

21

2■원 칙ㅣ Principles

원칙과 실천법

원칙principle은 시공을 초월하여 변하지 않는 근원적인 진실이며, 실천법practice은 원칙을 특

정 상황에 맞게 적용한 것이다. 실천법은 처한 환경에 따라 달라질 수 있고 달라져야 하며,

상황 전개에 따라서도 변해야 한다.

어떤 팀에서 사용중인 소프트웨어 개발 실천법이 별로 효과가 없어서 이를 바꾸려 하는데,

어떤 것을 선택해야 할지 잘 모른다고 가정해보자. 다시 말해 어딘가에서 벗어나야 하는데

어느 쪽으로 가야 할지 모르는 상황이다. 소프트웨어 개발의 새로운 접근법을 찾을 때, 원

칙을 이해하는 것과 실천법을 살펴보는 것 중 어디에 시간을 쓰는 것이 더 좋은 방법일까?

실행하면서 배우는learn by doing 접근법이 있다. 결국에는 그 기저에 깔린 원칙을 이해하게

될 것이라는 확신을 가지고 서로 밀접하게 연관된 실천법들을 먼저 도입하는 방식이 여기에

해당한다. 반면에 실행하기 전에 이해하는understand-before-doing 접근법이 있다. 근원적인 원

칙을 먼저 이해한 뒤 원칙으로부터 특정 상황에 맞는 실천법을 개발하는 방식이다. 우리는

두 가지 접근법을 결합했을 때 가장 좋은 결과를 얻을 수 있음을 깨달았다. 기저에 깔린 원

칙을 이해하지 못하고 실천법만 그대로 가져다 실행하는 것은 오랫동안 평범한 결과만 낳았

다. 그러나 근원적인 원칙을 이해하고 나면, 유사 조직에서 좋은 성과를 낸 실천법을 가져

와 자신의 환경에 맞도록 수정함으로써 유용한 것으로 만들 수 있다. 이렇게 하면 원칙들을

구현하기 위한 활동을 쉽고 빠르게 시작할 수 있다.

22

Principles _2

예를 들어, 메리의 비디오 테이프 공장에서 적시 생산방식(Just-in-Time, JIT)을 도입했을 때 그

녀의 공장은 조립 공정이 아니라 가공 공정이었기 때문에 도요타의 실천법을 그대로 따라하

기가 불가능했다. 경영진은 그들의 분야에서 JIT가 의미하는 것이 무엇인지 곰곰이 생각해

야 했다. 그들은 도요타의 간판 시스템과 당김 스케줄링pull scheduling과 같은 실천법을 도입

하기로 결정했다. 그러나 재고 감축만으로는 비약적인 비용 절감을 이루기에 충분하지 않

다는 것을 알았고, 그래서 결국 제조 현장의 작업자들을 참여시키는 독특한 방법을 개발하

여 라인정지stop-the-line 문화를 만들어 냈다. 그들은 원칙을 이해하는 것과 실천법을 적응시

키는 것을 잘 조합하여 극적인 성공을 일궈냈다.

90년대에는 많은 회사들이 도요타의 간판 시스템을 따라했지만 그저 그런 결과밖에 얻지

못했다. 그 회사들은 린이 낭비 제거를 목표로 한 경영 시스템이라는 것을 깨닫지 못했다.

아마도 간판 시스템을 도입했던 많은 회사들이 그들의 가치흐름value stream상에 많은 낭비를

남겨두었을 것이라고 추측된다. 마찬가지로 많은 회사들이 이 책에서 소개하는 애자일 소

프트웨어 개발 실천법들을 적용하려 하겠지만, 낭비를 인식하지 못하고, 그것을 제거하기

위해 가치흐름을 관리하지 않고, 직원과 파트너들을 존중하지 않는다면 그 결과는 또다시

그저 그런 것이 되고 말 것이다.

소프트웨어 개발

제조업과 공급망관리supply chain management에서의 린 실천법들은 소프트웨어 개발로 쉽게 변

환되지 않는다. 왜냐하면 소프트웨어와 개발은 둘 다 각각 공정 운영이나 물류와는 사뭇 다

르기 때문이다. ‘소프트웨어’와 ‘개발’이라는 두 단어를 각각 살펴보고 그 독특함이 어디에

있는가를 분석해보기로 하자.

소프트웨어

임베디드 소프트웨어는 제품에서 변경이 가능한 부품이다. 만약 변경할 필요가 없다면 그

것은 하드웨어나 마찬가지다. 기업 소프트웨어는 그 복잡성을 감당해야 하는 비즈니스 프

로세스의 일부분이다. 만약 까다로운 계산이나 복잡한 정보의 흐름을 처리할 일이 있으면

그것은 소프트웨어의 몫이 된다. 소프트웨어는 사용자 상호작용이나 마지막 순간에 해야

할 작업 또는 ‘나중에 신경 쓸’ 작업을 담당하게 된다. 이런 이유로 훌륭한 소프트웨어 아키

23

2_ 원칙

텍처의 특징이라고 할 만한 것들은 거의 모두가 소프트웨어를 쉽게 변경할 수 있도록 하는

것과 관련있다.1 그리고 이것은 놀랄 일이 아니다. 왜냐하면, 전체 소프트웨어의 절반 이상

이 첫 출시 이후에 개발되기 때문이다.2

시간이 지남에 따라 양산 소프트웨어를 수정하는 것은 점점 더 어려워지고 비용은 더 많

이 소요되게 마련이다. 수정은 복잡도를 증가시킨다. 이러한 복잡함은 대개 코드베이스code

base를 경화시켜서 깨지기 쉽게 만든다. 너무나 많은 기업들이 자사의 소프트웨어에 많은 투

자를 했음에도 불구하고 결국 손댈 수 없이 뒤엉켜버린 코드를 만들어냈음을 발견하곤 깜짝

놀란다. 그러나 모든 소프트웨어가 항상 비극으로 끝나는 것은 아니다. 최고의 소프트웨어

제품들은 10년 또는 그 이상 사용되기도 하는데, 그 정도의 긴 시간 동안 사용되는 모든 제

품은 출시 이후에도 정기적인 수정이 이루어진다. 이러한 제품들은 변화를 허용하는 코드

를 만들어내는 아키텍처와 개발 프로세스를 갖고 있다. 소프트웨어라고 부를 만한 모든 코

드는 반드시 변화허용성을 염두에 두고 설계하고 구현해야 한다.

개발

개발은 아이디어를 제품으로 변환하는 과정이다. 이러한 변환의 방법에 대한 두 가지 부류

의 사고가 있는데 하나는 결정론적인 사고이고 다른 하나는 경험론적인 사고이다. 결정론

적 부류는 제품에 대한 완벽한 정의를 먼저 만들고 그 정의를 실현한다. 경험론적 부류는

상위 수준의 제품 컨셉으로 시작하여 잘 정의된 피드백 루프를 통해 그 컨셉에 대한 최적의

해석을 이루어낸다.

도요타 제품개발방식Toyota Product Development System은 정확히 경험론적 부류에 속하며, 차량

에 대한 정의보다는 컨셉으로 시작하여, 개발 프로세스를 거치면서 경험적으로 그 컨셉을

제품화해 나간다. 예를 들어 프리우스Prius의 제품 컨셉을 살펴보면 하이브리드 엔진을 언급

하지 않고, 단지 연비 목표를 리터 당 20km로 설정했을 뿐이었다. 또한, 프리우스의 제품

1 예를들어짐쇼어(JimShore)는‘QualityWithaName’에서고품질소프트웨어아키텍처를다음과같이정의했다.“좋은소프트

웨어설계는만족할만한실행성능을가지면서소프트웨어의생성과수정그리고유지보수시간을최소로하는설계이다.”www.

jamesshore.com/Articles/Quality-With-a-Name.html참조.

2 소프트웨어생명주기에서‘유지보수’에들어가는비용은40%에서90%에이른다.참조논문:Kajko-Mattsson,Mira,UlfWestblom,

StefanForssander,GunnarAndersson,MatsMedin,SariEbarasi,TordFahlgren,Sven-ErikJohansson,StefanTörnquist,

andMargaretaHolmgren,TaxonomyofProblemManagementActivities,ProceedingsoftheFifthEuropeanConferenceon

SoftwareMaintenanceandReengineering,March2001,1–10

24

Principles _2

컨셉은 승객을 위한 실내공간이 넓어야 한다고만 하고 차량의 치수를 지정하지는 않았다.

단지 그 개발 과정에서 도전적인 연비 목표를 달성하기 위한 최선의 방법으로 실험실에서

갓 나온 하이브리드 엔진을 얹었던 것이다.3

우리는 변화하는 환경을 다루는 개발 프로세스라면 경험론적 프로세스여야 한다고 믿는

다. 왜냐하면, 그것이 변화에 적응하기 위한 최선의 방법을 제공하기 때문이다. 위에서 언

급한 것처럼 소프트웨어는 그 본질상 초기 개발 기간뿐만 아니라 수명이 다할 때까지 변화

에 적응할 수 있도록 설계되어야 한다. 따라서 소프트웨어 개발 프로세스는 반드시 경험론

적 프로세스여야 한다.

Story ‘폭포수’란 도대체 무엇인가?

정부 프로젝트에서 일하기 시작한 해인 1999년이 될 때까지 나는 폭포수waterfall란 말과 마주

칠 일이 없었다. 나는 70년대에 자동제어 소프트웨어를 개발하는 (꽤 훌륭한) 프로그래머였

다. 지금이라면 그것을 임베디드 소프트웨어라고 부르겠지만 당시의 컴퓨터는 끼워넣기에는

embedded 너무 컸다. 나는 비디오 테이프를 만드는 매우 복잡한 공정라인을 짓고 가동시키는

대규모 프로젝트에서 일하고 있었다.4 이 프로젝트에 참여한 나의 동료들은 대규모의 복잡

한 테이프 생산라인을 개발하는데 다년간의 경험을 가진 엔지니어들이었다. 프로젝트 관리

는 숙련된 전문가들이 맡았다. 그들은 전체 예산 및 일정에 대한 승인을 얻는 방법이나, 필요

에 따라 계획을 조정할 수 있도록 전문가들에게 업무를 이관하는 방법을 잘 알고 있었다. 예

산과 일정도 중요하지만, 무엇보다도 중요한 목표는 최고의 제품을 생산해내는 라인을 구축

하는 것이었다. 우리 모두는 그 점을 잘 알고 있었다. 그리고, 항상 그렇게 했다.

비디오 카세트 공장의 정보 시스템 관리자가 되었을 때, 나는 엔지니어 시절에 배운 것들을

이용하여 신규 소프트웨어 개발을 관리했다. 이 때도 우리 부서의 가장 중요한 업무는 생산

을 지원하는 것이란 사실을 잊지 않았다. 후에 나는 제품 개발 부서로 이동하였다. 거기서는

새로운 제품을 상품화하기 위해 엄격하지만 매우 유연한 단계별 심의stage-gate 프로세스를

사용했다.

그렇게 함으로써, 나는 1999년 정부 프로젝트에 우연히 투입되기 전까지는 폭포수 방법론으

3 JeffreyLiker,TheToyotaWay,McGraw-Hill,2004.6장의프리우스개발부분참조.

4 테이프를만드는데필요한장비들은1920년대도요타자동직조기社에서만든자동직조기와유사한면이있다.

25

2_ 원칙

로 일하는 것에서 벗어날 수 있었다. 후에 폭포수 접근법을 접하고는 무척 당황스러웠다. 대

체 그런 방법으로 어떻게 성공할 수 있는지 도저히 이해할 수 없었기 때문이다. 그리고 사실

상 그 방법은 성공하지 못했다. 복잡했지만 성공적이었던 프로젝트 경험과 비교적 작은 프로

젝트에서도 실패한 폭포수 방법을 비교해보고 나는 정말 효과가 있는 것이 무엇인가에 관한

책을 쓰기로 결심했다.5 그 책에서 우리는 소프트웨어 개발의 7가지 원칙을 개략적으로 설명

했는데 바로 다음 절에 요약해 두었다.

- 메리 이야기

린 소프트웨어 개발의 7가지 원칙

이번 절에서는 앞서 출간한 책의 핵심인 소프트웨어 개발의 7가지 원칙을 요약하였다. 일부

독자들은 몇 가지 원칙에 대한 용어가 달라졌음을 발견할 수도 있을 것이다. 하지만 그 의도

는 같다. 각각의 원칙을 설명하고 나서 그 원칙과 관련하여 널리 퍼져있는 잘못된 통념을 덧

붙였다. 통념을 사실로 믿고 있는 사람들에게는 그 원칙이 직관에 위배된다고 느껴질 것이다.

원칙 1: 낭비를 제거하라

오노 다이이치(大野 耐一)는 도요타 생산방식Toyota Production System을 ‘낭비를 완전히 제거하기

위한’ 경영 시스템이라고 불렀다.6 그것이 어떻게 운영되는가를 물었을 때 그는 다음과 같

이 말했다. “우리가 하는 모든 것은 고객이 우리에게 주문을 내릴 때부터 우리가 현금을 손

에 넣을 때까지의 시각표timeline를 살펴보는 것이다. 그리고 가치를 더하지 못하는 낭비들을

제거함으로써 그 기간을 단축하는 것이다.”7 이것은 간단히 말해 린 생산Lean Production에 관

한 것이다. 린 소프트웨어 개발에서도 낭비를 제거한다는 목표는 같지만 시각표의 시작과

끝은 수정되어야 한다. (조직마다 의미는 다르겠지만) 시각표는 고객 요구를 반영한 주문을

받을 때 시작되며 요구를 만족시키는 소프트웨어를 배포할 때 끝난다. 린 소프트웨어 개발

5 MaryandTomPoppendieck,“LeanSoftwareDevelopment:AnAgileToolkit”,Addison-Wesley,2003.

6 TaiichiOhno,ToyotaProductionSystem:BeyondLargeScaleProduction,ProductivityPress,1988,p.4.

7 6)번각주와동일함,p.ix.

26

Principles _2

은 가치를 더하지 않는 모든 낭비를 제거하여 그 기간을 단축하는데 중점을 두고 있다.

낭비를 제거하기 위해서는 먼저 낭비를 인지해야 한다. 가치를 더하지 못하는 어떤 것도

낭비이므로 낭비를 제거하기 위한 첫 단계는, 가치가 정말 무엇인지를 감지할 수 있는 예리

한 감각을 개발하는 것이다. 고객이 소프트웨어를 사용하기 시작했을 때 그들이 무엇을 가

치있다고 평가할 것인지를 깊이 이해하는 것 외에 다른 방법은 없다. 소프트웨어 업계에서

는 가치 자체가 변하는 특성을 갖고 있다. 고객들은 그들이 진정 원하는 것이 무엇인지 모

르고 있는 경우가 너무도 많기 때문이다. 더구나 새로 만들어진 소프트웨어가 돌아가는 것

을 보고 나면 원하는 것이 언제나 변하게 마련이다. 그럼에도 불구하고 훌륭한 소프트웨어

개발 조직은 고객가치에 대한 깊은 통찰력을 개발하여 계속해서 그들의 고객을 기쁘게 한다.

구글을 보라. 매번, 어김없이 전 세계의 고객을 기쁘게 하고 있다.

일단 가치를 잘 이해하고 나면, 다음 단계는 현실에서 낭비를 보는 능력을 개발하는 것이

다. 낭비란 고객에게 가치를 적시 적소에 전달하는 것을 방해하는 모든 것을 의미한다. 고

객 가치를 더하지 않는 모든 것은 낭비이며, 고객이 원하는 순간에 가치를 제공받지 못하게

하는 모든 지연도 낭비다.

제조 분야에서 재고는 낭비다. 재고가 있으면 이를 통제하고, 옮기고, 저장하고, 추적하

고, 꺼내와야만 한다. 이것은 시간과 노력을 빼앗아 갈 뿐만 아니라 복잡도를 증가시켜 비

용을 몇 곱절로 늘어나게 한다. 재고는 분실되거나 못 쓰게 되고, 품질 문제를 가리고, 돈

을 묶어놓는다. 따라서 제조에서의 한 가지 목표는 가능한 한 재고를 최소한으로 가져가는

것이다.

소프트웨어 개발에서의 재고는 미완성 작업partially done work이다. 미완성 소프트웨어는 제

조에서의 재고가 가지는 해악을 모두 갖고 있다. 그것은 분실되거나 못 쓰게 되고, 품질 문

제를 가리고, 돈을 묶어놓는다. 거기다가 소프트웨어 개발의 리스크 중 상당수가 미완성 작

업에서 비롯된다.

소프트웨어 개발에서 낭비의 전형적인 형태는 ‘혼란’8이다. 교육에 참가했던 사람들을 보

면 30%에서 50% 정도의 참가자들이 ‘요구사항 혼란’을 경험했고 테스트하고 고치는test-and-

fix 기간이 초기 개발보다 2배 이상 걸리는 경우도 많이 보았다. 우리는 소프트웨어 개발에

8 churn.버터제조용우유교반기를말하는데여기서는개발팀이내외부적요인에의해야기된혼란스러운상황을의미한다.흔히이

러한형태의혼란을'삽질'이라고표현한다.

27

2_ 원칙

서의 혼란이 언제나 잔뜩 쌓인 미완성 작업과 관련되어 있다는 것을 발견했다. 요구사항이

코딩보다 훨씬 먼저 정의된다면 요구사항은 당연히 변할 것이다. 테스팅이 코딩보다 한참

후에 이뤄진다면 테스트하고 고치는 혼란은 피할 수 없다. 불행히도 이런 종류의 혼란은 향

후 지연된 통합(소위 빅뱅 통합이라고 불린다)에 의해 발생할 더 큰 혼란에 대한 예비조짐

일 뿐이다.

그러나 소프트웨어 개발에서 무엇보다 가장 큰 낭비는 가외 기능extra feature이다. 일반적인

커스텀 소프트웨어(고객 주문 소프트웨어)의 경우 대개는 20% 정도의 기능만이 일상적으

로 사용된다. 다시 말해서, 약 3분의 2에 달하는 기능이 거의 사용되지 않는다는 얘기다.9

직접 사용하진 않지만 꼭 필요한 안전이나 보안 등의 기능을 말하는 것이 아니다. 애초부터

필요하지 않았던 기능들을 말하고 있는 것이다. 소프트웨어의 가외 기능을 개발하는데만

막대한 비용을 지불하고 있는 셈이다. 가외 기능은 코드베이스를 더 복잡하게 만들고 이는

다시 놀라운 속도로 비용을 증가시키고, 유지보수 비용도 훨씬 더 비싸게 만든다. 결국 소

프트웨어의 수명을 현저히 감소시킨다.

잘못된 통념: 스펙 조기 확정이 낭비를 줄인다

이러한 가외적인 코드를 개발하게 되는 것은 고객과 벌이는 게임 방식에서 비롯된다. 우리

는 흔히 이런 식의 규칙을 세운다.

존경하는 고객 님, 소프트웨어에 원하는 기능을 빠트리지 않고 목록으로 만들어 주십시오.

그러면 저희가 그것을 문서로 만들어 고객 님의 승인을 요청하겠습니다. 승인 후 변경이

나 추가를 하고 싶으면 ‘변경관리’라고 불리는 매우 복잡한 절차를 밟아서 변경승인을 얻

으셔야 합니다. 그러니 고객님이 바라는 모든 것을 지금 당장 생각해내야 합니다. 왜냐하

면 좋은 소프트웨어를 만들어내기 위해서는 개발을 시작할 때 모든 요구사항을 알아야 하

기 때문입니다.

이런 상황에서 고객이 요구사항 리스트에 이것저것 온갖 것을 다 집어넣는 것이 놀랄 만

한 일인가? 이러한 방식의 범위 조정 게임은 너무나 자주 정반대의 효과를 낳는다. 즉, 쓸

데없는 범위 팽창을 야기하게 되는 것이다. 오노 다이이치가 과잉생산을 제조에서의 가장

9 스탠디쉬(Standish)그룹의회장인짐존슨(JimJohnson)이사르디니아공국에서열린XP2002에서보고한이비율은제한된연구결

과에서나온것이었다.그후로우리는만나는그룹(특히커스텀소프트웨어를개발하는그룹)들마다이숫자가그들의경험에비추어

맞는것인지를물었다.그들의응답은그숫자가완전히똑같지는않더라도그언저리에있음을확인시켜주었다.

28

Principles _2

큰 낭비라고 불렀듯이 사용되지 않는 기능은 소프트웨어 개발에서도 최악의 낭비이다. 필

요하지 않으면서 존재하는 모든 코드 조각이 복잡도를 높여서 코드베이스의 남은 일생을 계

속 괴롭힐 것이다. 사용되지 않는 코드로 인해 쓸데없이 테스팅, 문서화, 유지보수 업무가

늘어난다. 이것은 시간이 지남에 따라 코드베이스의 유연성을 갉아먹고 코드를 이해하거나

수정하기가 점점 더 어렵게 만든다. 코드 복잡도에 따른 비용은 다른 모든 비용을 압도한다.

가외 기능들은 소프트웨어 생산성을 가장 크게 저해하는 요인중 하나다.

우리에게 필요한 프로세스는 가치의 80%를 제공하는 20%의 코드를 먼저 개발하고 다

음 단계에는 그 다음으로 가장 중요한 기능을 개발하도록 하는 프로세스이다. 어쩌면 필요

할 수도 있는 모든 것들을 포함하는 목록을 개발 대상으로 잡아서는 절대로 안된다. 특히나

그 목록이 아직 자신이 정확히 무엇을 원하는지 잘 모르는 고객으로부터 나온 것이라면 더

더욱 그렇다.

원칙 2 : 품질을 내재화하라

회의적인 관리자들은 “여기서는 규율이 더 많이 필요합니다. 규율을 줄여서는 안됩니다.”

라고 말하곤 한다. 그럴 때마다 우리는 린 소프트웨어 개발이 바로 규율적인 방법이라고 대

답한다. 단지 사람마다 규율을 보는 시각이 좀 다를 뿐이다. 여러분의 목표는 시작부터 코

드에 품질을 내재화하는 것이지 나중에 품질을 테스트하는 것이 아니다. 결함 추적 시스템

에 결함을 기록하는 데 집중하지 말고, 결함이 처음부터 생기지 않도록 해야 한다. 그렇게

하려면 고도로 규율화된 조직이 되어야 한다.

Story 결함 대기열

이미 CMM 레벨 4를 획득했고 레벨 5에 근접한 조직을 방문한 적이 있다. 우리는 그 사람들

과 규율에 감명을 받았지만 그들의 제품에 대해서는 별로 놀라지 않았다.

그러나 사건이 발생했다. 최근 들어 릴리스 주기가 6주에서 4개월로 길어진 것이다. 그들은

우리에게 그 원인을 찾는 것을 도와달라고 요청했다. 우리는 칠판에 릴리스 주기의 일정표를

그렸는데, 거기서 주기 마지막에 4주간의 테스팅 기간이 있는 것을 발견했다. 나는 “6주 안

에 릴리스를 못하는 것은 당연하네요. 여러분들은 지금 테스팅에만 4주를 쓰고 있습니다.”

라고 말했다.

29

2_ 원칙

품질 담당자는 이렇게 대답했다. “압니다. 테스팅을 자동화해야 합니다. 하지만 문제가 그렇

게 간단하지는 않은 것 같습니다.” 나도 동의했다. 이 조직은 최고의 조직이었다. 아마도 자

동화된 테스팅만으로 해결할 수 없는 무언가가 더 있을 것 같았다.

“4주간의 테스팅에 대한 파레토 분석10을 해 봅시다.” 라고 제안하면서 “4주간의 테스팅 기

간 동안 가장 많은 시간이 드는 곳은 어디인가요?”라고 물었다.

“결함 수정요.”라는 즉각적인 대답이 돌아왔다.

“그렇다면 여러분들은 그 4주 동안 테스팅을 하는 것이 아니라 사실은 결함을 수정하는 것이

로군요! 그러면서 테스팅이라고 부르는 것은 적절하지 않습니다. 만약 고쳐야할 결함이 전혀

없다면 그때는 테스팅이 얼마나 걸릴까요?”

“아마도 2, 3일 정도 걸리겠죠.” 라는 대답이 돌아왔다.

“만약 테스팅을 2, 3일 내에 끝낼 수 있다면, 그때는 다시 예전처럼 6주마다 릴리스를 할 수

있을까요?” 라고 물었다.

“물론이죠.” 라는 즉각적인 대답이 돌아왔다.

“여러분들은 개발 프로세스 상에서 너무 늦게 테스팅을 하는 것으로 보입니다. 이런 결함들

은 훨씬 더 일찍 발견되어야 합니다.” 라고 제안했다.

그러자 그는 “아, 우리는 벌써 그렇게 하고 있어요! 결함 추적 시스템에 다 기록해 두거든요.”

라고 말했다.

“그럼 그 결함들을 이미 알고 있으면서 마지막까지 아무 조치를 취하지 않는다는 말씀이세

요?” 나는 놀라서 물었다.

“네…” 라는 소심한 대답이 돌아왔다.

“좋습니다. 여러분도 이미 무엇을 해야 할지 알고 있는 것 같습니다. 결함을 발견하면 그것

을 기록하지 말고 그냥 고치세요! 최종 검증에서 코드가 잘 동작할 거라는 기대를 갖고 마지

막 테스팅을 2일 정도로 단축하세요.” 이것이 중요하다고 결정하기만 하면 이 뛰어난 조직은

내가 제안한 목표를 달성할 수 있을 것이라고 나는 확신했다.

- 메리 이야기

10 파레토분석은‘80/20’의법칙으로도불리는‘중요한소수와대수롭지않은다수’의법칙을응용한것으로품질의대가인조지프주란

(J.M.Juran)에의해처음으로널리알려지게되었다.그분석은따라서다음과같이진행된다.문제의범주를나누고가장많은문제

에해당하는범주를찾아서그범주를만들어낸문제의근본원인을찾아이를해결한다.가장큰문제의원인이제거되면이제남아있

는문제들에대해다시파레토분석을반복한다.7장에는이기법을사용하는좀더자세한예제가담겨있다.

30

Principles _2

신고 시게오(新郷 重雄)에 의하면 검사inspection에는 두 가지가 있다. 하나는 결함이 발생

한 후에 하는 검사이고 다른 하나는 결함이 발생하기 전에 예방하기 위한 검사이다.11 만약

여러분이 정말 고품질을 추구한다면 결함이 발생한 후 검사할 것이 아니라 처음부터 결함

이 발생하지 않도록 조건들을 통제해야 한다. 만약 이것이 불가능하다면 각각의 작은 단계

가 끝날 때마다 검사하여 결함이 발생하자마자 즉시 잡아내도록 해야 한다. 결함이 발견되

면 라인을 멈추고, 원인을 찾아서, 즉시 고쳐야 한다.

결함 추적 시스템은 미완성 작업의 대기열이다. 만약 여러분이 결함을 수정하려고 덤비

면 그때부터는 재작업의 대기열이다. 우리는 너무나 자주 결함이 대기열에 들어가 있다는

것만으로, 이제 그 결함을 빼먹지 않고 추적할 수 있을 테니 문제가 없을 것이라고 생각한다.

그러나 린의 관점에서 보면 대기열은 낭비의 집합소다. 목표는 대기열에 결함이 없도록 하

는 것이고, 더 궁극적인 목표는 결함을 추적하는 대기열까지 제거하는 것이다. 만약 이것

이 불가능하다고 생각한다면 낸시 반 슈엔더뵈르트Nancy Van Schooenderwoert의 경험을 살펴보

자.12 그녀는 복잡하고 변경이 잦은 임베디드 소프트웨어를 개발하는 3년 동안 단위 테스트

후 발생한 결함이 모두 합쳐 51개 뿐이었으며 어느 순간도 결함이 최대 2개를 넘지 않았다.

누가 2개의 결함을 기록하기 위해 결함 추적 시스템을 사용하겠는가?

오늘날 우리는 개발 중인 코드 결함의 대부분을 걸러낼 수 있는 도구를 갖추고 있다. 테

스트 주도 개발test-driven development 방식을 따르는 개발자들은 코드를 작성하기 전에 단위 테

스트와 인수 테스트를 먼저 작성한다. 그들은 최대한 자주 (대략 1시간마다) 코드와 테스트

를 함께 통합하여 테스트 하니스13를 실행하고 결함이 없음을 확인한다. 만약 테스트가 실

패하면 문제를 해결하거나 오류를 일으킨 코드를 지우기 전까지 새로운 코드를 추가하지 않

는다. 퇴근 무렵에는 더 길고 완전한 테스트 하니스를 실행하고, 매 주말에는 시스템에 더

욱 더 포괄적인 테스트 하니스를 붙여 실행한다. 이러한 프로세스를 사용하는 조직은 발견

된 결함의 원인을 매우 짧은 시간에 찾아낼 뿐만 아니라 믿을 수 없을 정도로 낮은 결함율

을 나타낸다.

11 ShigeoShingo,Studyof‘Toyota’ProductionSystem,ProductivityPress,1981,2.3장참조.

12 NancyVanSchooenderwoertandRonMorsicato,“Taming theEmbeddedTiger-AgileTestTechniques forEmbedded

Software,”Proceedings,AgileDevelopmentConference,SaltLakeCity,June2004,그리고NancyVanSchooenderwoert,

“EmbeddedAgileProjectbytheNumberswithNewbies,”Proceedings,Agile2006Conference,Minneapolis,July2006참조

13 TestHarness-시스템및시스템컴포넌트를시험하는환경의일부분으로시험을지원하는목적하에생성된코드와데이터.시험드

라이버라고도하며일반적으로단위시험이나모듈시험에사용하기위해코드개발자가만든다.

31

2_ 원칙

Story 생산성 급등14

테스트 주도 개발TDD은 코드 품질을 개선하는데 놀라울 정도로 효과적인 방법이다. 2004년

2월, 나는 품질 문제로 씨름하고 있는 한 회사에 이 기법을 소개했다. 모든 코드가 기껏해야

5년밖에 안 되었지만 (Java로 작성된 시스템이었다.) 그들은 레거시 애플리케이션으로 간주

하고 있었다. 출시 후 6개월 동안 주석을 제외한 순수 실행코드 기준으로 1,000라인 당 평균

10개의 결함이 보고되고 있었다.

열악한 품질은 그 회사의 명성과 고객만족에 타격을 주었으며, 적시에 새로운 기능을 추가하

는 능력을 저하시키고 있었다.

이 문제를 해결하기 위해 그 팀은 스크럼15이라는 애자일 개발 프로세스를 사용하였고 곧

TDD를 채택하였다. TDD를 채택한 이후 보고된 결함 수는 1,000라인 당 3개 이하로 줄어들

었다. 사실은 70%의 결함 감소보다도 더 큰 개선을 이루어냈다. 왜냐하면 보고된 결함 중에

서 TDD를 적용하기 전에 작성된 코드에서 나온 것을 따로 추적하지 않았기 때문이다. 즉 보

고된 결함 중 일부는 TDD를 적용하기 전에 작성한 코드의 결과이다. 보수적으로 보더라도

그 팀은 대략 80~90%의 개선을 이루었다고 말할 수 있다.

품질이 향상되자 효과는 여러 형태로 나타났다. 결함(개발 중에 발생한 것과 사용자가 보고

한 것까지 모두 포함)을 잡아내는데 훨씬 더 적은 시간을 사용했기 때문에 생산성이 급등했

다. TDD 적용 전에는 한 사람이 한 달에 기능 점수function point로 7점을 개발했는데, TDD 적

용 후에는 23점이나 개발하게 되었다. 그 팀은 결함을 훨씬 적게 내면서도 3배 이상의 생산

성 향상을 이룬 것이다.

- 마이크 콘Mike Cohn, 마운틴 고트 소프트웨어Mountain Goat Software 社 대표

잘못된 통념: 테스팅의 역할은 결함을 발견하는 것이다

테스트의 역할 그리고 테스트를 개발하고 실행하는 사람들의 역할은 결함을 ‘예방’하는 것

이지 발견하는 것이 아니다. 품질보증 조직은 개발이 끝난 뒤에 품질을 테스트하는 것보다,

시작부터 품질을 코드에 내재화하는 프로세스를 구현해야 한다. 검증이 불필요하다고 말하

는 것이 아니다. 최종 검증은 좋은 생각이다. 다만 검증하는 동안 결함을 발견하는 것은 예

14 경험을들려준마이크콘에게감사한다.허가받아인용함.

15 스크럼(Scrum)은잘알려진반복적개발방법론이다.KenSchwaberandMikeBeedle,AgileSoftwareDevelopmentwithSCRUM,

PrenticeHall,2001,andKenSchwaber,AgileProjectManagementwithScrum,Microsoft,2004.참조.

32

Principles _2

외사항이지 규칙이 되어서는 안된다. 만약 검증이 일상적으로 테스트와 수정의 사이클을

낳는다면, 개발 프로세스 자체에 결함이 있는 것이다.

메리의 공장에서는 사람의 실수에 의해 발생한다고 생각되는 결함의 80%가 사실은 그런

실수를 저지를 수 있게 한 시스템 때문에 발생한다는 것이 상식으로 되어 있다. 따라서, 대

부분의 결함은 사실상 관리상의 문제이다. “처음부터 똑바로 하라” 라는 슬로건은 사후 검

사를 없애기 위한 표어였다. 이것은 각 제조 단계에서 실수 방지mistake-proofing를 함으로써

결함 유발을 쉽게 피하도록 하는 것이었다.

우리가 소프트웨어 개발에 “처음부터 똑바로 하라”라는 슬로건을 사용했을 때는 테스트

주도 개발과 지속적인 통합continuous integration16을 사용하여 코드가 항상 의도한 대로 정확히

동작해야 한다는 의미였다. 그러나 불행히도 그 슬로건은 전혀 다른 의미로 사용되었다. “처

음부터 똑바로 하라”는 말이 코드가 한번 쓰여지면 절대 변경되어서는 안된다는 것을 의미

하는 것으로 해석되었던 것이다. 이러한 해석은 개발자들로 하여금 복잡한 시스템을 설계

하고 개발하는데 최악의 실천법들을 사용하는 것을 조장하였다. 소프트웨어가 한번 작성

되면 절대 바뀌어서는 안된다는 생각은 매우 위험한 잘못된 통념이다.

소프트웨어 개발에서 낭비를 제거하는 최고의 방법을 다시 살펴보자. “코드를 더 적게 짜

라.” 코드를 더 적게 짜기 위해서는 가치의 80%를 제공하는 20%의 코드를 발견하여 그것

을 먼저 개발해야 한다. 이런 식으로 다음 기능들을 추가하다가 기능 추가에 따른 비용보다

얻게 되는 가치가 더 적은 경우에 작업을 멈춘다. 기능을 추가할 때는 코드를 간결하고 결

함이 없게 유지해야 하며 그렇지 못하면 복잡도가 곧 여러분을 위협할만한 수준으로 높아질

것이다. 그래서 우리는 새로운 기능을 추가하기 위해 설계를 리팩터링하여 코드베이스를

간결하게 유지하고, 소프트웨어의 가장 큰 적인 ‘중복’을 제거한다. 이것은 기존 코드를 늘

수정해야 한다는 것을 의미한다.

원칙 3: 지식을 창출하라

‘폭포수 모델’이 우리를 곤혹스럽게 만드는 측면 중 하나는, 지식이 ‘요구사항’이라는 형태로

코딩과 분리되어 존재한다는 생각이다. 소프트웨어 개발은 지식을 창출해가는 프로세스다.

16 ContinuousIntegration:ImprovingSoftwareQualityandReducingRisk.Addison-Wesley,2007

33

2_ 원칙

전체적인 아키텍처 개념은 코딩 전에 개략적으로 그려질 수 있지만 그 아키텍처의 검증은

코드가 작성될 때 이루어진다. 소프트웨어의 상세 설계는 설령 그것이 문서로 먼저 작성된

다고 하더라도 실제로는 코딩 중에 이뤄진다. 초기 설계에서는 구현 중에 마주치는 복잡성

을 충분히 예측할 수 없을 뿐만 아니라 실제 소프트웨어를 개발하면서 얻게 되는 피드백을

고려할 수도 없다. 더 나쁜 것은 초기의 상세 설계는 이해 당사자나 고객으로부터 피드백을

받기가 힘들다는 것이다. 지식을 창출하는 데 중점을 두는 개발 프로세스는 설계가 코딩 중

에 진화할 것이라고 기대하고, 설계를 너무 일찍 확정하는 데 시간을 낭비하지 않을 것이다.

하버드 비즈니스 스쿨의 앨런 맥코맥Alan MacCormack은 조직이 어떻게 학습하는가를 연구하

는데 평생을 보냈다. 예전에 그가 소프트웨어 개발 실천법을 공부하고 있을 때 한 회사로부

터 2개의 프로젝트(‘좋은’ 프로젝트와 ‘나쁜’ 프로젝트)를 평가해 달라는 부탁을 받았다.17 ‘좋

은’ 프로젝트는 교과서대로 운영되었다. 그것은 최적의 설계를 갖고 있었고 그렇게 만들어

진 시스템은 초기의 명세와 매우 가까웠다. ‘나쁜’ 프로젝트는 개발 팀이 시장의 변화를 이

해하고 대응하기 위해 싸우는 동안 계속되는 변화를 겪었다.

맥코맥의 기준에 따라 평가한 ‘좋은’ 프로젝트는 품질, 생산성, 시장 수용성 측면에서 매

우 낮은 점수를 받은 반면 ‘나쁜’ 프로젝트는 시장에서 성공했다. 개발기간 내내 시장을 통

해 학습을 해온 팀이 더 좋은 제품을 만들어낸 것은 놀랄 일이 아니다. 정말 눈이 휘둥그레

질 만한 사실은 그 회사의 관리자들은 시장에 대해 학습하고 시장을 만족시키는 제품을 만

들어내는 것을 ‘나쁜’ 것으로 생각했다는 점이다.

맥코맥은 성공적인 소프트웨어 개발을 위한 실천법을 다음과 같이 4가지로 정리하였다.18

1. 고객의 평가와 피드백을 위한 최소 기능 집합의 조기 출시

2. 일일 빌드와 통합 테스트를 통한 빠른 피드백

3. 좋은 판단을 할 수 있는 경험과 직관을 갖춘 팀 그리고/또는 리더

4. 새로운 기능을 쉽게 추가할 수 있는 모듈화된 아키텍처

17 이이야기는앨런맥코맥의“CreatingaFastandFlexibleProcess:ResearchSuggestsKeys toSuccess”에실려있

다.www.roundtable.com/MRTIndex/FFPD/ARTmaccormack.html,www.agiledevelopmentconference.com/2003/files/

AlanAgileSoftwareJun03.ppt참조.

18 AlanMacCormack,“Product-DevelopmentPracticesThatWork:How InternetCompaniesBuildSoftware,”MITSloan

ManagementReview,Winter2001,Vol.40number2참조.

34

Principles _2

제품 개발에서 오랜 기간 동안 뛰어난 실적을 보여온 회사들은 공통적인 특징이 있다. 그

들은 규율화된 실험을 통해 새로운 지식을 창출하며, 그 지식을 간결하게 정리하여 상위 조

직이 그것을 얻기 쉽게 만든다. 그리고 명확한 자료를 수집할 뿐만 아니라 암묵적인 지식을

명확하게 만들고 그것을 조직의 지식 기반으로 만드는 방법을 모색한다.19 이런 회사들은

개발 중인 제품에 대해 학습하는 것도 중요하지만, 그 지식을 집대성하여 향후의 제품에 사

용할 수 있게 하는 것도 필수적이라는 것을 알고 있다.

개발주기 동안 체계적인 학습을 독려하는 개발 프로세스를 갖는 것도 중요하지만, 개발

프로세스 자체를 체계적으로 개선시킬 필요도 있다. 때때로 우리는, ‘표준’ 프로세스를 찾

는 과정에서 우리 자신의 프로세스를 문서 속에 가둬버려서, 개발 팀이 스스로의 프로세스

를 지속적으로 개선하는 것을 어렵게 만든다. 린 조직은 복잡한 환경에서는 항상 문제가 발

생한다는 것을 알고 있고, 따라서 조직이 지속적으로 자체 프로세스를 개선해야 한다는 것

도 안다. 일의 크고 작음을 떠나, 모든 문제에 대해 그 근본 원인을 찾고 해결하기 위한 최

선의 방법을 찾아 실험 하며, 다시 같은 문제가 생기지 않도록 프로세스를 개선한다. 개발

팀은 의무적으로 프로세스 개선에 노력을 기울여야 하며, 모든 팀은 정기적으로 프로세스

개선을 위한 시간을 따로 확보해야 한다.

잘못된 통념: 예측을 해야 예측이 가능해진다.

회사와 고위 경영진이 가장 바라는 것 중의 하나는 바로 예측 가능한 결과다. 이러한 기대

는 결국 소프트웨어 개발에까지 영향을 미친다. 불행히도 소프트웨어 개발은 예측 불가능

한 것으로 악명이 높고, 그래서 이것을 더 예측 가능하게 해달라는 엄청난 압력이 가해진다.

여기서의 모순은 소프트웨어 개발의 예측 가능성을 개선하려는 열망이 오히려 반대 효과를

갖는 실천법들을 제도화했다는 것이다. 우리는 계획을 세우고, 마치 그것이 미래에 대한 정

확한 예측을 구체화한 것처럼 그 계획에 따라 행동한다. 예측이 사실이라고 가정해버리기

때문에 의사결정을 일찍 내리는 경향이 있고, 그것은 결국 우리 스스로를 꽉 짜여진 틀 안

에 가둬버리는 결과를 낳는다. 그로 인해, 예측이 어긋났을 때 변화에 대응할 능력을 잃어

버린다. 이 문제에 대한 해결책은 더 정확히 예측하는 것이라고 주장할 수도 있을 것이다.

19 IkujiroNonakaandHirotakaTakeuchiinTheKnowledgeCreatingCompany:HowJapaneseCompaniesCreatetheDynamics

ofInnovation,OxfordUniversityPress,1995,p.225.참조.번역서로는『지식창조기업』(장은영역,세종서적,2002)이있다.

35

2_ 원칙

우리는 만약 예측이 1) 복잡하거나, 2) 자세하거나, 3) 먼 미래에 대한 것이거나, 또는 4)

불확실한 환경에 대한 것이라면, 그 예측은 언제나 부정확할 수밖에 없다는 사실을 잊고 있

다. 이러한 종류의 예측을 더 정확하게 하기 위해 아무리 많은 노력을 해도 좋은 결과를 기

대하기는 힘들다. 그러나 우리가 정확한 예측으로부터 시작할 수 없다고 해도 신뢰할 만한

결과를 낳을 수 있는 잘 검증된 방법들이 있다. 그것은 바로 미래에 대한 우리의 예측을 마

치 사실인양 인식하고 행동하는 것을 멈추는 것이다. 예측은 단지 예측일 뿐이다. 대신에

어떤 사건이 발생하면 그에 빠르게 대응할 수 있도록 반응 시간을 줄여야 한다.

결과에 대한 예측 가능성을 높이기 위해서는 의사 결정에 들어가는 추측의 양을 줄여야

한다. 예상이 아닌 사실에 근거한 결정이 가장 예측 가능한 결과를 낳는다. 메리는 제어 엔

지니어로서 경험론적 제어 시스템(피드백 기반의 제어 시스템)이 결정론적 제어 시스템보

다 더 예측 가능한 결과를 낳는다는 것을 안다. 근본적으로는 사건이 일어나기를 기다리고

거기에 빨리 그리고 정확히 대응하는 능력을 잘 개발한 조직이 미래를 예측하려 하는 조직

보다 훨씬 더 예측 가능한 결과를 낳는다.

원칙 4: 확정을 늦춰라

긴급 상황에 대처하는 사람들은 어렵고 예측 불가능하며 위험한 상황을 다루는 훈련을 받

는다. 그들은 어려운 상황을 평가하여 중대한 결정을 내리기까지 얼마 동안 결정을 늦출 수

있는지를 결정하는 방법을 배운다. 그러한 결정을 위한 타임박스20를 설정하고 그 시간이

다 될 때까지 기다리도록 교육받는다. 바로 그 순간이 결정을 내리기 위해 필요한 정보를

가장 많이 확보하는 때이기 때문이다.

소프트웨어를 개발하는 과정에서도 돌이킬 수 없는 결정을 내려야 할 때와 같은 논리를

적용해야 한다. 돌이킬 수 없는 결정은 마지막 결정의 순간last responsible moment까지 미뤄야

한다. 즉, 그 순간을 지나면 너무 늦어져버리는 마지막 순간에 결정을 내려야 하는 것이다.

모든 종류의 의사 결정을 미뤄야 한다는 의미가 아니다. 무엇보다도 먼저, 대부분의 결정

을 돌이킬 수 있게 만들어서 결정을 내리고 나서도 쉽게 바꿀 수 있게 해야 한다. 반복적 개

발의 목표 중에서도 가장 유용한 것이 바로 ‘분석 불능’ 상태에서 시작하여 무언가 구체적

인 방향으로 이동하는 것이다. 그러나 시스템의 초기 기능을 구현하는 동안에는 나중에 변

20 시작과종료시점이정해진일정.

36

Principles _2

경하기 어렵게 만들 만한 중대한 설계 결정을 가급적 피해야 한다. 소프트웨어 시스템이 완

전히 유연할 필요는 없지만 변화가 일어날 만한 부분에는 옵션을 유지할 필요가 있다. 해당

분야와 기술에 대해 상당한 경험을 쌓은 팀이나 리더는 어느 곳에 옵션을 유지해야 하는지

를 본능적으로 알고 있을 것이다.

많은 사람들이 까다로운 결정도 일단 내리고, 리스크 요인들을 정면으로 공략하며, 알

수 없는 것의 개수를 줄이는 것을 좋아한다. 그러나 불확실성이 있고 특히나 복잡성을 동반

한 경우, 더 성공적인 접근방법은 어려운 문제들에 대한 다양한 해결책을 시도하고 중대한

옵션들은 결정을 더 이상 늦출 수 없는 순간까지 보류하는 것이다. 사실 최고의 소프트웨어

설계 전략이라고 하는 것들의 대부분은, 옵션을 결정되지 않은 채로 남겨두었다가 가능한

가장 늦은 시점에 돌이킬 수 없는 결정을 내릴 수 있도록 하는 것이다.

잘못된 통념: 계획을 세우는 것은 확정하는 것이다

“나는 전투를 준비함에 있어 계획plan은 언제나 쓸모가 없다는 것을 발견했다, 그러나 계획

을 세우는 것planning은 필수불가결하다.” 아이젠하워의 이 유명한 말은 계획을 세우는 것과

확정하는 것의 차이에 대한 올바른 통찰을 제공한다. 계획을 세우는 것은 중요한 학습 훈련

이고 조직의 올바른 반사신경을 개발하는데 매우 중요하며, 복잡한 시스템에서 상위 아키

텍처 설계를 확립하는데도 필요하다.

반면에 계획은 과대평가되고 있다. 오노 다이이치의 이야기를 들어보자.21

계획은 아주 쉽게 변한다. 이 세상의 일들은 항상 계획대로 진행되지는 않기 때문에, 상

황의 변화에 대응하여 업무 지시도 빠르게 변해야 한다. 만약 한번 결정한 아이디어를 계

속 고집한다면 계획은 변하지 않을 것이며 사업은 오래 지속될 수 없을 것이다.

사람의 척추는 튼튼할수록 더 잘 휘어진다고 한다. 이러한 탄성elasticity이 중요하다. 만약

뭔가가 잘못되어 척추에 깁스를 한다면 이 중요한 부위가 뻣뻣해지고 기능을 멈추게 된다.

한번 세워진 계획에 집착하는 것은 사람의 몸에 깁스를 하는 것과 같다. 그것은 건강하지

않다.

21 TaiichiOhno,ToyotaProductionSystem:BeyondLargeScaleProduction,ProductivityPress,1988,p.46.

37

2_ 원칙

베리 뵘Barry Boehm과 리차드 터너Richard Turner22는 계획이 곧 확정이라는 기대에 근간을 둔 소

프트웨어 개발 방법론을 설명하기 위해 ‘계획 주도 방법plan-driven method’이라는 용어를 만들

어냈다. 그들은 유능한 계획 주도 프로세스를 “계획된 결과를 만들어 내는 고유한 능력”을

갖고 있는 프로세스라고 정의했다.23 그들은 더 나아가 계획 주도 방법은 정부기관과의 계

약에서 비롯된 것이라고 하였다.24 사실상 약속으로 간주되는 상세 계획을 만들지 않고서,

정부기관에서 요구하는 계약을 대등한 입장에서 체결하는 것은 매우 어려운 일이다.

그러나 민간 분야의 현명한 회사(도요타와 같은)들은 상세 계획에 집착하는 것이 건강하

지 않으며, 특히 상세 계획을 따라잡는 능력에 따라 프로세스 역량을 평가하는 것이 잘못이

라는 사실을 알고 있다. 계획을 세우는 것이 확정하는 것이라는 잘못된 통념에 굴복하지 말

자. 계획은 사려 깊게 하되 확정은 인색하게 해야 한다.

원칙 5: 빨리 인도하라

우리의 자녀들이 너무 어려서 의자에 앉으면 그들의 턱이 테이블 높이 정도 되던 시절에는,

어느 집을 방문하건 항상 두꺼운 시어스25 카탈로그 한두 권쯤은 볼 수 있었고 우리는 그것

을 의자 높이를 높이는데 사용했다. 누구나 그 카탈로그의 페이지들을 넘겨보는 것을 좋아

했고 거기서 주문을 하곤 했다. 배송까지는 2~3주가 걸렸기 때문에 근처 상점에서 구할

수 있는 물건을 일부러 주문하지는 않았다. 1980년대 중반쯤 메인Maine 주의 통신 판매 회

사인 L.L. 빈L.L. Bean은 시간을 무기로 시어스와 경쟁하기로 결정했다. 그들의 목표는 모든

주문에 대해 접수 후 24시간 이내에 물품을 배송하는 것이었다. 이것은 너무나 놀라운 개

념이었기 때문에 다른 회사들은 어떻게 그것이 가능한지 보기 위해 L.L. 빈의 물류 센터를

방문하곤 했다.

얼마 지나지 않아 사람들은 2~3주의 배송 기간이 끔찍하게 느리다고 느끼게 되었다. 창

업 100년을 향해 가던 전통 깊은 시어스 카탈로그로는 더 이상 경쟁력이 없게 되었고 결국

1993년에 문을 닫았다. L.L. 빈은 훨씬 더 적은 비용을 쓰고 있었는데 그 이유는 그들이

22 BarryBoehmandRichardTurner,BalancingAgilityandDiscipline:AGuideforthePerplexed,Addison-Wesley,2004.

23 22)번각주와동일,p.12.

24 22)번각주와동일,p.10.

25 Sears.미국의거대통신판매회사.

38

Principles _2

주문 취소나 변경으로 인한 비용을 줄일 수 있었던 것에서도 찾을 수 있다. 다음을 살펴보자.

시어스에서 노란색 셔츠를 주문했는데 1, 2주 후에 전화를 걸어 “있잖아요, 생각이 바뀌었

어요. 파란색 셔츠로 바꿔주실 수 있나요?”라고 말한다면 그들은 아마도 주문을 바꿔줄 것

이다. 그러나 만약 L.L.빈에 똑같은 요청을 했다고 한다면, 그들은 아마도 이렇게 말할 것

이다. “현관 앞을 보셨나요? 오늘 도착했을 겁니다.”

이야기의 교훈은 어떻게 하면 고객이 그들의 생각을 바꿀 시간이 없을 정도로 빨리 소프

트웨어를 인도할 수 있을지 생각해 보아야 한다는 것이다.

페덱스FedEx는 하룻밤 배송을 가능하게 했다. 사우스웨스트 항공은 공항 게이트에서의 신

속한 턴어라운드26를 최초로 실현했다. 두 회사는 모두 다른 회사들이 그들을 널리 모방한

후에도 각각의 산업에서 주도권을 유지하고 있다. 델이 만들어낸 속도에 기반을 둔 주문 조

립 생산 모형은 모방이 매우 어려운 것으로 이미 판명되었다. 도요타는 혁신적인 하이브리

드 엔진을 갖춘 프리우스 모델을 15개월만에 출시했는데, 이 정도의 제품 개발 속도에 근

접하는 회사는 거의 없다.

시간을 기반으로 경쟁력을 갖춘 회사는 경쟁사에 비해 현저한 비용 우위를 가질 수 있다.

그들은 비용을 초래하는 엄청난 양의 낭비를 제거하였다. 더구나 그들의 결점율은 극단적

으로 낮다. 반복가능하고 안정적인 속도는 뛰어난 품질이 뒷받침되지 않으면 불가능하다.

한발 더 나아가 고객에 대한 깊은 이해를 발전시켰다. 그들은 너무나 빨라서, 제품 개발에

새로운 생각을 시도하고 실제로 먹히는 것이 무엇인지 배우는 실험적인 접근을 하는 것이

부담스럽지 않다.

잘못된 통념: 서두르는 것은 낭비를 낳는다

소프트웨어 업계에는 높은 품질을 얻으려면 “속도를 늦추고 조심해야 한다” 라는 생각이

지배적이었다. 그러나 업계가 그러한 타협을 고객에게 강요하고 있을 때, 그 타협을 깨트

리는 회사는 현저한 경쟁 우위를 점하게 된다.27 이 책의 뒤에서 소개되는 구글과 페이션트

키퍼 社가 바로 고품질의 소프트웨어를 신속하게 공급하는 회사들 중 하나다. 속도와 품질

26 turnaround.비행기의착륙에서출발까지의시간을말한다.항공사입장에서는비용을줄이고승객을신속히수송할수있기때문에

신속한턴어라운드가중요한의미를가진다.

27 GeorgeStalk와RobLachenauer,Hardball:AreYouPlayingtoPlayorPlayingtoWin,HarvardBusinessSchoolPress,2004.

39

2_ 원칙

이 양립할 수 없다는 믿음을 고수하는 소프트웨어 개발 조직은 그리 멀지 않은 미래에 시어

스 카탈로그처럼 역사의 뒤안길로 사라질 운명에 처할 것이다.

주의: 빠른 속도와 꼼수를 동일시 하지 마라. 그 둘은 전혀 다르다. 빠르게 움직이는 개

발 팀은 뛰어난 반사 신경과 규율에 따른 라인정지stop-the-line 문화를 갖추어야 한다. 그 이

유는 명백하다. ‘품질을 내재화하지 않으면 빠른 속도를 유지할 수 없다’.

규율을 추구함에 있어 많은 조직이 상세한 프로세스 계획, 표준화된 작업 산출물, 작업

흐름 문서 그리고 명확한 업무 지침서를 개발한다. 게다가 이러한 일은 주로 프로세스 상의

작업자를 훈련시키고 규율 준수 여부를 관찰하는 지원 조직에 의해 이루어진다. 목표는 다

른 것들 중에서도 프로젝트 간에 인원을 쉽게 이동할 수 있게 하는 표준화되고 반복 가능한

프로세스를 달성하는 것이다.28 그러나 대체 가능한 인력을 만들도록 설계된 프로세스는,

빠르고 유연한 프로세스에 필수적인 사람을 육성해 내지 못한다.

빠른 조직을 만들고 싶으면 옳은 판단을 할 것이라고 신뢰할 수 있고, 서로를 도울 수 있는,

적극적으로 참여하고 연구하는 사람들이 필요하다. 빠르게 움직이는 조직에서는 그 업무를

하는 사람이 지시 받지 않아도 무엇을 해야 하는지 알고 있고, 승인이 없이도 문제를 해결

하고 변화에 대응할 수 있도록 업무가 구성되어 있다. 린 조직은 표준에 맞춰 일한다. 그러

나 그러한 표준들은 업무를 어떻게 수행할 것인지에 대한 현재 수준에서 최고의 지식을 구

체화하고 있기에 존재한다. 그 표준들은 작업자들이 업무를 수행하기 위해 더 좋은 방법을

시험하기 위한 기준선이 된다. 린의 표준은 도전을 받고 개선되기 위해 존재한다.29

고품질을 달성하기 위해서는 2가지 방법이 있다. 여전히 속도를 늦추고 조심하는 것과

사람을 육성하는 것이다. 후자는 사람을 통해 계속해서 프로세스를 개선하고 제품에 품질

을 내재화하며, 경쟁사보다 몇 배나 빨리 고객에게 반복적이고 안정적으로 대응하는 능력

을 개발하는 것을 뜻한다.

28 BarryBoehmandRichardTurner,BalancingAgilityandDiscipline:AGuideforthePerplexed,Addison-Wesley,2004,pp.11–

12.참조

29 JimShook“BringingtheToyotaProductionSystemtotheUnitedStates”inBecomingLean,JeffreyLiker,editor,Productivity

Press,2004,pp.59–60참조.

40

Principles _2

원칙 6: 사람을 존중하라

조엘 스폴스키Joel Spolsky가 대학을 갓 졸업하고 마이크로소프트에 신입사원으로 입사했을 때

맡은 일은 엑셀 프로그램에 매크로 언어 전략을 개발하는 것이었다. 그는 얼마간 고객이 매

크로에 원하는 기능이 무엇인지 연구하고 나서 명세를 작성했다. 애플리케이션 아키텍처

그룹이 명세 이야기를 듣고서 검토를 해주겠다고 했다. 조엘로서는 반가운 소식이었다. 조

엘은 그들로부터 좋은 조언을 들을 수 있을 것이라고 생각했다. 그러나 그 작은 그룹은 매

크로에 대해 조엘보다도 더 모르고 있었다. 거기다 그 그룹에는 박사 4명과 매우 높은 경력

의 상관(빌게이츠의 친구이자 회사 내 서열이 여섯 번째였다)이 있었다. 애플리케이션 아키

텍처 그룹은 고객이 그 매크로를 어떻게 사용할 것인지에 대해 매우 피상적인 아이디어만

갖고 있으면서도, 매크로가 어떻게 구현되어야만 하는지 결정하는 것이 그들의 일이라고

생각했다. 조엘의 관리자들은 그 결정은 조엘의 몫이라고 했고 조엘의 프로그래밍 팀도 그

를 지지했다. 그러나 애플리케이션 아키텍처 그룹은 그것을 못마땅해 했으며 그들의 상관

은 조엘이 매크로 전략을 엉망으로 만들고 있다고 불만을 토로하기 위해 대규모 회의를 소

집했다.

만약 마이크로소프트가 평범한 회사였다면, 여러분은 이 시나리오가 어떻게 마무리 될지

상상할 수 있을 것이다. 애플리케이션 아키텍처 그룹은 제 갈 길을 갔을 것이고 조엘은 마

지못해 따르든지 아니면 회사를 떠났을 것이다. 그러나 마이크로소프트에서는 그렇게 되지

않았다. 대규모 회의 다음 날 부사장이 조엘과 같이 식당에 들러 “그 애플리케이션 아키텍

처 그룹하고는 어떻게 진행되고 있나요?”라고 물었다. 조엘은 모든 것이 잘 되고 있다고 대

답했다. 그러나 그 다음 날 조엘은 애플리케이션 아키텍처 그룹이 해체되었다는 소문을 들

었다. 그는 크게 감명을 받았다. 조엘은 이렇게 말한다. “마이크로소프트에서는 여러분이

엑셀 매크로 전략 팀의 일원이라면, 여러분이 입사한지 6개월도 안 되었다 하더라도, 그것

은 중요하지 않다. 여러분이 엑셀 매크로 전략에 있어서는 신(神)이며 누구도, 설사 그가

회사 내 서열 6위라 할지라도, 여러분의 길을 가로 막을 수는 없다. 이상 끝.”30

조엘의 이야기는 ‘원칙 6: 사람을 존중하라’가 소프트웨어 업계에서 일하는 사람의 관점

에서 보았을 때 무엇을 의미하는지를 보여주고 있다.

30 JoelSpolsky,“TwoStories”,http://www.joelonsoftware.com/articles/twostories.html.허가받아인용.“SmartandGetsthings

done”,Apress2007.번역서로는『똑똑한,100배로일잘하는개발자뽑기:조엘온소프트웨어시즌2』(이석중,위키북스2007)가있다.

41

2_ 원칙

그림 1.531의 도요타 제품개발방식의 4개 핵심 요소 중 3개가 제품개발 프로세스에 종사하

는 사람들과 관련되어 있다는 것은 주목할 만하다. 이 3가지를 살펴보면 사람을 존중한다

는 것이 어떤 의미인지에 대한 폭넓은 아이디어를 얻을 수 있을 것이다.

1. 기업가적 정신을 가진 리더: 사람들은 성공적인 제품을 만드는 곳에서 일하고 싶어

하는데, 매우 성공적인 제품은 대개 뛰어난 리더에 기인하는 경우가 많다. 조직의

구성원을 존중하는 회사는 훌륭한 리더를 양성하고, 적극적으로 참여하고 연구하는

사람들을 육성하며, 위대한 제품을 창조하는데 그들의 노력을 집중하는 리더십을

가지도록 한다.

2. 전문 기술 인력: 특정 분야에서 경쟁 우위를 지속하고자 하는 회사라면 그 분야의

기술적 전문 지식을 개발하고 키워야 한다. 필요한 모든 전문 지식을 구매하는 회사

는 경쟁사 역시 그것을 구매할 수 있다는 것을 깨닫게 될 것이다. 전문 지식에 대한

필요성을 느끼지 못하는 회사는 자신들에게 지속 가능한 경쟁 우위가 없다는 것을

머지않아 발견할 것이다. 현명한 회사는 적절한 기술적 전문 지식을 육성하고, 모든

팀이 목표를 달성하기 위해 필요한 전문 지식을 갖추는 데 집중한다.

3. 책임 기반의 계획과 통제: 사람을 존중한다는 것은 팀에 전반적인 계획과 합리적인

목표만을 부여하면, 그 팀이 목표를 달성하기 위해 스스로 노력할 것이라고 신뢰한

다는 뜻이다. 존중은 사람들에게 무엇을 어떻게 하라고 지시하는 대신 그들 스스로

머리를 굴려 생각해내는 반사신경을 갖춘 조직을 개발하는 것을 의미한다.

잘못된 통념: 유일한 최선의 방법이 존재한다

『Cheaper by the Dozen』32이라는 책은 효율성 전문가인 아버지와 12명의 자녀로 이뤄진 가족

에 관한 매우 재미있는 실제 이야기이다. 11명의 형제 중 넷째로 자란 메리는 어린 시절 이

책을 아주 열심히 읽었다. 최근 메리는 이 책을 다시 읽으면서 여태까지 미처 깨닫지 못했

던 것을 깨달았다. 『Cheaper by the Dozen』이 과학적 관리scientific management의 기원에 관한 독

특한 시각을 보여준다는 것이다. 12명의 아버지 프랭크 길브레스Frank Gilbreth는 어떤 일을

31 MichaelKennedy,ProductDevelopmentfortheLeanEnterprise:WhyToyota’sSystemIsFourTimesMoreProductiveand

HowYouCanImplementIt,OakleaPress,2003,p.120.허가받아인용.

32 FrankB.GilbrethJr.andErnestineGilbrethCarey,CheaperbytheDozen,T.Y.CrowellCo.,1948.같은제목의영화는책과는많

이동떨어진내용이다.번역서로『아빠,고생하신거우리다알아요:아빠,그만좀웃기세요』(장석영역,현실과미래,2000)가있다.

42

Principles _2

하더라도 거기에는 항상 ‘유일한 최선의 방법one best way’이 존재한다고 주장하는 세계적으로

유명한 컨설턴트였다. 길브레스의 조직화된 가족들을 생각하며 행간을 읽어보면, 그의 효

율성 향상 노력의 결과물을 대부분의 작업자들이 받아들이고 싶지 않았을 것이라고 추측할

수 있다. 그러나 프랭크 길브레스의 사람에 대한 공경심 부족이 익살스러운 수준인 반면,

그의 친구인 프레드릭 윈슬로우 테일러Frederick Winslow Taylor가 그의 저서를 통해 보여준 것은

‘노동자’에 대한 숨김 없는 멸시였다.

프랭크 길브레스가 일찍 사망한 후 그의 부인이자 파트너인 릴라이언 길브레스Lillian Gilbreth

가 그 일을 물려 받았는데, 그녀는 훗날 그 시대의 가장 훌륭한 산업공학자 중 한 사람이 되

었다. 그녀는 가족을 돌보는 일33에서도, 그녀의 직업에서도, ‘유일한 최선의 방법’을 찾는

대신 작업자의 동기부여에 초점을 맞추었다. 그러나 상황은 이미 돌이킬 수 없었다. 모든

일에 대해 ‘유일한 최선의 방법’을 찾고 제도화하는 접근방식이 대다수 미국 산업계의 산업

공학자들에게 각인되었다. 소위 프로세스 경찰이라 불리던 사람들의 선조격인 이 산업공학

자들은, 주어진 일을 제대로 이해하지도 않고 표준부터 만들어내곤 했다. 더구나 더 나은

방법에 대한 가능성을 생각하지도 않고 그 표준들을 강요했다.

‘유일한 최선의 방법’같은 것은 없다. 개선될 수 없는 프로세스는 없다. 이것을 여러분 스

스로 증명하고자 한다면, 그저 시간을 좀 내어 사람들이 일하는 모습을 조용히 지켜보라.

잠깐만 지켜보더라도 개선 대상을 많이 발견할 수 있을 것이다. 프로세스는 반드시 그 일을

직접 수행하는 작업 팀에 의해 개선되어야 한다. 그들은 주어진 문제를 가장 큰 것부터, 한

번에 하나씩 해결하기 위한 시간, 권한 그리고 적절한 도움을 필요로 한다. 이러한 영속적

인 개선 프로세스가 모든 소프트웨어 개발 조직에 자리잡고 있어야 한다.

원칙 7: 전체를 최적화하라

소프트웨어 개발은 부분 최적화로 유명하다.

● 악순환 1번 (물론 이런 일은 여러분 회사에서는 절대 일어나지 않아야 한다.)

≉ 고객이 ‘어제’ 느닷없이 새로운 기능을 이야기한다

33 속편,FrankB.GilbrethJr.andErnestineGilbrethCarey,BellesonTheirToes,T.Y.CrowellCo.,1950.번역서로는『천사표우리

엄마』(장석영역,현실과미래,2000)이있다,

43

2_ 원칙

≉ 개발자에게 이렇게 전달된다. “비용이 얼마가 들더라도 빨리 끝내도록!”

≉ 결과: 코드베이스에 조잡한 변경이 가해진다.

≉ 결과: 코드베이스의 복잡도가 증가한다.

≉ 결과: 코드베이스의 결함수가 증가한다.

≉ 결과: 기능을 추가하는데 들어가는 시간이 기하급수적으로 증가한다.

● 악순환 2번 (이것 또한 여러분 회사에서는 일어나지 않아야 한다)

≉ 테스팅 업무가 과중하다.

≉ 결과: 테스팅이 코딩보다 한참 뒤에 이뤄진다.

≉ 결과: 개발자가 피드백을 즉시 얻지 못한다.

≉ 결과: 개발자가 결함을 더 많이 발생시킨다.

≉ 결과: 테스팅 업무가 더 많아진다. 시스템에 결함이 더 많아진다.

≉ 결과: 피드백이 더 지연된다. 이것이 반복된다.

린 조직은 전체 가치흐름을 최적화한다. 전체 가치흐름은 고객 요구를 반영한 주문을 받

았을 때부터 소프트웨어가 배치되어 고객 요구가 만족될 때까지를 포함한다. 만약 어떤 조

직이 전체 가치흐름보다 작은 것을 최적화하는데 집중한다면, 전체 가치흐름이 악화될 것

이라고 말할 수 있다. 우리는 그동안 수업중에 다루었던 가치흐름도value stream map에서 이런

경우를 자주 보았다. 커다란 지연이 발생하는 것은 대부분 한 부서에서 다음 부서로 책임을

넘기면서 그 사이에 정작 고객의 관심사가 제대로 넘어가도록 돌보는 책임은 누구도 지지

않는 경우였다.

조직은 대개 그들이 전체를 최적화하고 있다고 생각한다. 어찌 됐든 누구나 부분 최적화

가 나쁘다는 것을 알고 있으며 아무도 그것을 받아들이려 하지 않는다. 그러나 측정 시스템

상에 부분 최적화가 제도화된 경우는 놀라울 정도로 많다. 후지쯔Fujitsu의 사례를 살펴보자.34

2001년 후지쯔는 영국 항공사인 BMI의 헬프 데스크를 맡게 되었다. 후지쯔는 BMI 종업

원들로부터 받은 요청들을 분석했고 그 결과 요청 중 26%가 항공사 탑승 수속 카운터의 프

34 JamesP.WomackandDanielT.Jones,LeanConsumption:HowCompaniesandCustomersCanCreateValueandWealth

Together,FreePress,2005,pp.58–63.

44

Principles _2

린터 오동작 때문이었다. 후지쯔는 프린터가 얼마 동안 동작불능이었는지 측정하고 BMI

가 그것에 치르는 전체 비용을 산정했다. 그러고 나서 후지쯔는 그 직무사례를 보고함으로

써 BMI 경영진이 프린터를 더 튼튼한 것으로 바꾸도록 했다. 그 후 후지쯔는 헬프 데스크

에 걸려오는 요청의 근본원인을 밝혀내고 이를 제거하기 위한 활동을 계속하여 18개월 후

에는 전체 요청 수의 40%가 감소하였다.

이것은 좋은 이야기처럼 들린다. 그러나 뭔가 잘못된 것이 있다. 대부분의 헬프 데스크는

요청처리 건수에 근거하여 보수를 받는다. 요청 건수를 40% 감소시킴으로써 후지쯔의 수

입도 같은 양만큼 줄어들었다. 다행히도 후지쯔의 성과가 너무 극적이었으므로 BMI와의

재협상을 실시하여 실제 요청이 아닌 ‘잠재적’ 요청에 근거하여 보수를 받을 수 있었다. 새

로운 협의하에서 후지쯔는 BMI가 사업상의 문제를 해결할 수 있도록 근본적으로 지원하는

것을 계속할 수 있는 재정적인 인센티브를 갖게 되었다.

이 이야기는 전통적인 수익 모델하에서 운영되는 헬프 데스크 외주는 고객 문제에 대한

원인을 찾고 해결하기 위한 동기부여가 없음을 보여준다.

조직적인 경계를 넘나드는 것은 비용이 많이 든다. 피터 드러커Peter Drucker는 가치흐름을

관통하는 단일 관리시스템을 유지하는 회사는 경쟁사에 비해 25~30%의 비용 우위를 보인

다고 하였다.35 이것이 사실이라면 구성원 모두가 전체를 최적화하도록 만드는 올바른 인센

티브에 의해 계약, 외주 협약, 그리고 업무에서 상호 협력 체계를 구축함으로써 상당한 양

의 비용 절감이 가능하다.

잘못된 통념: 부분으로 나누어 최적화하라

P. 슬론P. Sloan은 복잡도를 다루기 위한 조직 구조를 창안했다. 그는 분권화된 조직을 만들

고 관리자의 성과를 판단하는데 재정적 지표를 이용했다. 이것은 중역이 직접 통제하던 포

드Ford 방식에 비해 크게 개선된 것이었다. 이것으로 인해 제너럴 모터스General Motors는 다양

한 종류의 차를 생산하고 포드를 앞질러 시장의 선두를 차지하게 되었다. 그 이후 회사들은

성과를 관리하기 위한 올바른 지표를 찾고자 애쓰고 있다.

35 PeterDrucker,ManagementChallengesforthe21stCentury,HarperBusiness,1999,p.33.번역서로는『21세기지식경영(지식근

로자의자기개발법)』(이재규역,한국경제신문사,2002)가있다.

45

2_ 원칙

복잡도를 다루기 위해 지표를 사용한 슬론의 생각은 훌륭했지만 이 같은 개념은 오용되기

쉬운 것이다. 사람들은 복잡한 상황을 작은 조각들로 나누려는 경향이 있는데, 이는 아마

도 일을 매우 작은 작업단위로 나누었던 효율성 전문가들에게서 기인한 것이 아닌가 한다.

잘게 나눈 뒤에는 각각의 조각들을 측정하고 그 측정치를 최적화한다. 여러분은 각각의 측

정치를 최적화하면 전체 시스템도 최적화될 것이라고 기대하겠지만, 그것은 틀린 생각이다.

만약 여러분이 가치흐름을 여러 조각으로 나누어 창고Silo에 넣고 각각을 최적화하면36, 그동

안의 경험으로 볼 때 전체 시스템은 부분 최적화될 것이 거의 확실하다.

모든 것을 측정할 수는 없다. 그러므로 측정을 제한해야 하는데 그렇게 되면 측정의 틈

사이로 빠지는 것이 있게 마련이다.37 예를 들어 프로젝트 성과를 비용, 일정, 목표 범위를

기준으로 측정하려고 한다. 그러나 이러한 측정만으로는 품질과 고객 만족을 고려하지 못

한다. 만약 서로 대립하게 되면 품질과 고객 만족을 포기하게 된다. 그렇다면 어떻게 해야

하는가? 부분으로 나누는 방법을 따르자면 측정 지표를 2개 추가하여 이제는 비용, 일정,

목표 범위와 함께 품질과 고객 만족까지 측정하게 된다. 이것 보라! 우리는 방금 철의 3각

지대를 철의 5각지대로 바꿔놓았다.

측정 시스템이 너무 많은 것을 측정하게 되면, 너무 많은 지표로 인해 진정한 목적을 상

실하게 되고, 지표들끼리 대립하는 상황에서 효과적인 결정을 내릴 수 없게 된다. 해결책은

“더 높은 것을 측정하라”이다. 즉, 측정을 한 수준 위로 올려서 측정의 수를 ‘줄이는’ 것이다.

하위 수준의 지표들이 올바른 값이 나오도록 인도할 상위 수준의 지표를 찾고, 지표들 간에

대립이 있을 경우 올바른 절충안을 찾도록 하는 기반을 확립하라. 위의 프로젝트 지표 예에

서는 지표를 2개 추가하는 대신 지표를 하나로 줄여 정말 중요한 하나만을 측정해야 한다.

프로젝트 평가에서는 투자수익률이 후보가 될 수 있다. 손익 모델은 제품 평가에 잘 맞는

다.38 정말 중요한 오직 하나의 지표를 최적화하면 나머지 숫자들은 스스로 관리될 것이다.

36 사일로효과(siloeffect)참조.조직내에서부서간의협력없이내부의이익만추구함을의미한다.

37 RobAustin,MeasuringandManagingPerformanceinOrganizations,DorsetHouse,1996.이주제를훌륭하게설명하고있다.

38 MaryandTomPoppendieck,LeanSoftwareDevelopment:AnAgileToolkit,Addison-Wesley,2003의83-92쪽참조.번역서로는

『린(Lean)소프트웨어개발:애자일실천도구22가지』(김정민,김현덕,김혜원,박영주공역,인사이트,2007)가있다.

46

Principles _2

Story 중고차39

우리가 하는 수업 중에서 투자수익률 실습은 사람들에게 인기가 좋다. 고객이 정말 만족하

는 의사결정을 내릴 수 있도록 도와주기 때문이다. 한 수업에서 이안Ian과 그의 그룹이 중고

차 재판매 회사의 투자수익률을 산출했다. 차량의 재고 시간을 5일에서 4일로 줄였더니 매

우 높은 재정 수익이 발생하였다.

투자수익률 뒤에 숨어있는 이야기는 더욱 흥미롭다. 이안은 스크럼을 막 배우고 나서 중고차

재판매 회사에서 매우 오래된 컴퓨터 시스템을 대체하는 일을 맡았다. 그는 고객에게 그의

팀이 앞으로 한달 분량씩 점진적으로 소프트웨어를 개발하여 배포할 것이며 만약 그 중 한

번이라도 만족하지 못한다면, 계약을 취소해도 좋다고 말했다.

“뭐라고 말했다고?” 이안의 경영진은 불만을 나타냈다. 만약 그 중고차 재판매 회사의 계약

이 파기되면 그 컨설팅 회사에서 이안에게 더 이상 일을 주지 않을지도 모른다는 암시가 있

었다. 그래서 이안은 매월 고객을 기쁘게 할 방법을 찾는데 더 매달리게 되었다.

여기저기 문의한 끝에 이안은 차량 재고 시간을 줄이는 것이 재정에 긍정적인 효과가 있을

것이라는 사실을 알아냈고, 우리 수업에서 그 효과를 정량화하는 실천법을 익혔다. 그는 고

객을 찾아가 실제 데이터를 얻어서 간단한 재정 모델에 입력했다. 그 결과를 토대로 이안과

고객은 매달 가장 가치있는 기능을 개발하는데 집중할 수 있었다.

몇 개월 후 이안은 그의 고객이 결과에 매우 만족하여 그의 컨설팅 회사가 더 많은 사업을

따내게 될 것이고, 경영진이 매우 기뻐했다는 소식을 우리에게 알려주었다. 이안의 경영진은

애자일 소프트웨어 개발 방법론을 받아들였고 현재 자신들의 회사를 영국에서 최고의 애자

일 회사 중 하나라고 생각하고 있다.

- 메리 이야기

39 이이야기를사용하게해준이안쉬밍즈(IanShimmings)에게감사한다.

47

2_ 원칙

시도해 볼 것

1. 아래 7가지 잘못된 통념 중 여러분이 처한 상황에서 특별히 가슴에 사무치는 것이

있는가? 왜 그런가?

≉ 스펙 조기 확정이 낭비를 줄인다.

≉ 테스팅의 역할은 결함을 발견하는 것이다.

≉ 예측을 해야 예측이 가능해진다.

≉ 계획을 세우는 것은 확정하는 것이다.

≉ 서두르는 것은 낭비를 낳는다.

≉ 유일한 최선의 방법이 존재한다.

≉ 부분으로 나누어 최적화하라.

2. 여러분의 조직에서는 가치흐름 시각표가 언제 시작되는가? “주문을 받는다”는 것이

여러분의 환경에서는 어떤 의미인가? 어떤 회사에서는 개발을 위한 제품 컨셉이 승

인될 때(주문은 승인 프로세스에서 온다) 제품 개발의 시각표가 시작된다. 마케팅

팀이 고객 요구를 인지하고 새로운 기능을 요청할 때 시작되기도 한다. 어떤 것이

여러분의 상황에 가장 적합한가?

3. 혼란: 여러분 회사에서,

a. 요구사항이 문서화된 후 몇 %가 변경되는가?

b. 개발 주기 끝에서 ‘테스트하고 수정하기’ 또는 ‘안정화’ 활동을 하는데 개발 기간

의 몇 %가 소요되는가?

c. 이 같은 비율을 줄이기 위해 무엇을 할 수 있는가?

4. 사람: 일선 감독자들은 부서를 어떻게 이끌고 갈 것인지에 대해 얼마 만큼의 교육

을 받는가? 그들을 평가할 때 강조하는 항목은 무엇인가? 일선 프로젝트 관리자들

은 팀을 어떻게 이끌고 갈 것인지에 대해 얼마 만큼의 교육을 받는가? 그들을 평가

할 때 강조하는 항목은 무엇인가? 두 경우에 차이가 있는가? 왜 그런가?

48

Principles _2

5. 측정: 여러분 조직에서는 사람들마다 성과 측정을 위한 핵심 ‘성과 지표’를 종이 한

장에 정리하여 가지고 있는가? 그렇다면 모든 지표를 (가능하다면 익명으로) 모아

하나의 목록을 만들어 보라. 지표가 얼마나 되는가? 그것들은 올바른 것들인가? 놓

친 핵심 지표는 없는가? “더 높은 것을 측정하라”를 실천할 방법을 생각해낼 수 있

겠는가?

49

3■가 치ㅣ Value

린 해법

『린 솔루션Lean Solutions』에서 제임스 워맥James Womack과 다니엘 존스Daniel Jones는, 그들 자신도

역시 고객이라는 사실을 이야기하면서, 소비자로서 감당해야 하는 골치 아픈 일들이 너무

많아 상당히 성가시다고 말한다. 그들은 고객의 관점에서, 고객에게 상품과 서비스를 제공

하는 우리와 같은 사람들에게, 다음과 같은 메시지를 던진다.1

● “내 문제를 완전하게 해결해 주시오.”

● “내 시간을 낭비하지 마시오.”

● “내가 정말 원하는 것을 제공하시오.”

● “내가 정말 원하는 곳에 가치를 제공하시오.”

● “내가 정말 원할 때 가치를 제공하시오.”

● “내 문제를 풀기 위해 내가 결정해야 하는 것들의 개수를 줄여주시오.”

이미 몇 년 전에 이런 취지를 간파한 회사가 있다. 그 회사를 살펴보자.

1 JamesWomackandDanielJones,LeanSolutions:HowCompaniesandCanCreateValueandWealthTogether,FreePress,

2005,15쪽참조.번역서로는『린솔루션-소비자의시간과비용을절약하라』(이진원역,바다출판사,2007)이있다.

50

Value _3

구글

구글은 사용자들이 최대한 빨리 구글 웹 사이트를 떠나도록 하는 것을 공식적인 목표로

삼고 있는 유일한 회사일 것이다.2

1999년 구글은, 모든 사람이 세상의 정보에 가까이 다가갈 수 있게 만들겠다는 고결한 목

표를 가지고 혼잡한 검색엔진 시장에 뛰어들었다. 구글은 목표를 달성하기 위해 두 가지에

전념하기로 결심했다. 1) 의미있는 검색결과를 누구보다 많이 제공한다. 2) 진정으로 매력

적인 고객 경험을 제공한다. 전략은 적중했다. PC매거진 1999년 마지막 호에서 구글은

웹 애플리케이션 분야의 기술혁신 상을 수상했다. PC매거진은 이렇게 덧붙였다. “몇 번만

접속해 보면 구글에 중독되지 않을 수 없다. 꾸준히 검색결과가 좋게 나오는데 누가 매료되

지 않을 수 있겠는가?”3 기술혁신 상 수상을 계기로 구글은 세상의 이목을 끌게 되었고, 검

색엔진 업계의 정상을 향한 눈부신 성장을 시작했다.

구글이 자사 웹 사이트에 발표한 기업 철학은 다음 4가지 포인트로 시작한다.4

1. 사용자에 집중하라. 그러면 나머지는 알아서 해결될 것이다.

2. 한가지를 정말, 정말 잘하는 것이 최선이다.

3. 웹에서도 민주주의는 적용된다.

4. 빠른 것이 느린 것보다 낫다.

초창기에는 고객 경험을 일부 포기하자는 강한 압력이 있었지만 구글은 이에 굴하지 않았

다. 당시에는 팝업과 배너광고 등이 대유행이었지만, 구글은 사용자가 그것들을 귀찮아한

다는 이유로 엄격히 금지하였다. 구글은 속도에 광적으로 집착했다. 검색 결과를 보여주는

데 조금이라도 지연된다면 그게 무엇이든 사용자의 시간을 낭비하는 것이다. 대부분의 경

쟁업체들이 포털portal을 구축하고 있었지만 구글은 홈페이지를 극단적으로 단순하게 유지

했다. 로고 하나, 짧은 단어 30개, 버튼 2개가 붙은 검색창 하나가 전부였다. 구글은 가외

기능들로 사용자를 산란하게 만들고 싶지 않았다.

결국 구글은 의미있는 검색 결과를 찾아주는 것에 있어서 정말 훌륭해졌고, 시간이 지날

2 구글웹사이트www.google.com/corporate/tenthings.html에서.

3 PC매거진,1999년12월호,104쪽참조.

4 구글웹사이트www.google.com/corporate/tenthings.html에서.

51

3_ 가치

수록 점점 더 향상되었다. 구글 설립자들은 검색결과에 순위를 매기는 독특한 방법을 개발

해냈다. 그들은 페이지마다 ‘투표’한 회수를 집계했다. 여기서 투표란 그 페이지에 대한 참

조를 말하는 것이며, 참조가 많다는 것은 그만큼 중요하다는 의미로 해석되었다. 가장 많

은 득표를 한 페이지가 승자가 되었다. 시간이 지남에 따라 구글은 사람들이 페이지에 투표

하는 방식을 지속적으로 세련되게 다듬었고, 그 결과에 따라 순위를 매겼다.

구글은 제품 개발 프로세스에도 똑같은 4가지 원칙을 적용한다.

1. 가치-고객에 집중하라. 나머지는 알아서 따라올 것이다: 개발 팀이 고객에게만 집

중하여 제품 개발에 임하도록 독려한다. 일단 제품이 알려지기 시작하면 그제서야

회사는 어떻게 수익을 낼지 방법을 찾는다.5

2. 탁월함-한가지를 정말 정말 잘하는 것이 최선이다: 구글은 마치 자사의 검색엔진처

럼, 자신들이 하는 일에 탁월함을 보이려 한다. 구글의 탄탄한 기술적 발판은 동시

에 많은 것을 시험하고 시도해 볼 수 있는 유연성을 제공한다.6

3. 민주주의-웹에서도 민주주의는 적용된다: 새로운 아이디어는, 그것을 활용하고자

하는 열정을 가진 일정 인원 이상의 사람들을 매혹시킴으로써 주목을 끌게 된다. 새

로운 제품들은 구글랩스Google Labs7 사이트에 올려지고 사용자들의 주목을 받으면서

지명도를 얻게 된다.

4. 속도-빠른 것이 느린 것보다 낫다: 구글에서는 다른 회사에서 몇 년씩 걸릴 일들이

매우 빨리 진행된다. 며칠 또는 몇 주 정도로.8

구글이 자신들의 서비스 목록에 지도 관련 서비스를 추가하는 과정을 살펴보자. 2004년

3월 구글은 특정 지역에 국한하여 검색결과를 보여주는 서비스인 구글로컬Google Local의 베

타 버전을 출시하였다. 같은 해 10월, 구글은 키홀Keyhole이라는 회사를 인수하여 전 세계에

걸친 상세한 위성 사진을 얻게 되었다. 2005년 2월, 구글은 구글로컬에 지도 기능을 추가

했다. 2005년 4월, 키홀을 인수한 지 정확히 6개월 만에 위성 사진을 추가했다. 그리고 2

개월 후 구글어스Google Earth가 출시되었다. 구글어스는 지구 모양을 본떠 만든 혁신적이면

5 DavidA.Vise,"Google'sMissingPiece",WashingtonPost,2005년2월10일,E05면참조.

6 KeithH.Hammonds,“HowGoogleGrows...andGrows...andGrows”,FastCompanyIssue69,2003년4월p.74

7 labs.google.com참조.

8 http://video.google.com/videoplay?docid=-8618166999532839788에서...

52

Value _3

서도 매력적인 인터페이스의 데스크톱 애플리케이션으로, 기존의 위성 사진과 지도, 그리

고 지역 검색 기능을 멋지게 하나로 묶어놓았다.

구글은 전략적 비전에 집중한다. 그들의 비전은 세상의 정보를 체계화하여 어디서나 접

근 가능하고 활용 가능하게 만드는 것이다. 이러한 비전을 실현하기 위해, 세련된 알고리즘,

복잡한 하드웨어 그리고 잘 설계된 소프트웨어를 조화시켜 자신들에게 필요한 내부 도구와

웹 기반 제품을 개발한다. 제품과 도구들은 각각 제품 관리, 설계, 엔지니어링, 테스팅, 출

시, 그리고 지속적인 엔지니어링을 수행하는 작은 팀들에 의해, 신속하게 그리고 점진적으

로 개발된다. 충분히 다듬어지기 전이라도 제품을 출시하도록 장려하는데 이는 조기에 사

용자로부터 피드백을 받기 위함이다. 구글이 만든 소프트웨어는 세련된 설계와 높은 품질

로 유명하며 출시될 때마다 변함없이 사용자를 기쁘게 한다.

분명히 구글은 모든 면에서 매우 성공적인 조직이다. 그러나 이보다 중요한 것은 자신의

제품들을 통해 세상이 돌아가는 방식을 바꾸어 왔다는 것이다. 구글은 장기적인 제품 개발

계획이 없고, 기술 인력들에게 그들의 시간 중 20%를 개인 프로젝트에 쓰게 함에도 불구

하고 지속적으로 새로운 상품을 출시해왔다. 구글은 어떤 상품의 개발을 지원할 것인지 결

정할 때도 그들이 검색결과에 순위를 매기는 것과 똑같은 방식으로 결정한다. 우선순위는

개발 팀의 관심 정도와 그 상품에 관심을 가지는 사용자의 수에 기반하여 매겨진다.

우리는 구글이 성공한 이유를, 사용자가 원하는 정보를 (혼란스러움이나 시간 낭비 또는

귀찮은 광고 없이) 원하는 시간과 장소에 정확히 제공했기 때문이라고 생각한다. 구글은 어

린 아이들도 사용할 수 있을 정도로 쉽다. 그리고 구글은 맞춤법을 검사해 주고, 다른 언어

로 번역해 주고, 단위를 환산해 주고, 사전, 계산기, 지도까지 포함하고 있어서 문제를 한

꺼번에 해결해 준다. 이것이 바로 ‘린 해법’의 정의라 할 수 있다.

컨셉에서 현금까지

구글의 첫 번째 상품 개발 일정을 살펴보고 그것이 어떻게 진행되었는지 알아보자.

컨셉

1996년, 래리 페이지Larry Page와 세르게이 브린Sergey Brin은 그들의 공통 과제인 인터넷 검색

을 해결하기 위해 서로 협력하게 된다. 둘은 스탠포드 대학의 전산과 대학원생이었는데, 당

53

3_ 가치

시 데이터 마이닝을 연구하고 있었으므로 인터넷 상에서 데이터 마이닝을 시도해 보기로 하

였다. 2년 후 그들은 후에 구글의 기반이 되는 제품 컨셉을 매우 자세히 전개한 논문을 발

표했다.9

빼어난 제품 컨셉은 혁신의 시작이다. 혁신은 기나긴 연구 과정이 될 수도 있고, 한 번에

번뜩 떠오르는 통찰일 수도 있다. 기업은 혁신을 위한 조건을 갖출 수는 있지만, 위대한 통

찰을 얻기 위한 비법은 없다. 그러나 번뜩이는 통찰만으로는 절대 부족하다. “혁신은 5%의

영감과 95%의 땀이다.”10 대부분의 기업이 가진 문제점은 영감을 가진 사람이 그것을 추구

하기 위한 시간이나 승인을 얻지 못한다는 것이다. 일상적으로 영감을 혁신으로 바꾸는 기

업은 좋은 아이디어를 가진 개인과 팀이 그 아이디어를 배양하여 제품 컨셉으로 변환하기

위한 시간과 공간을 만들어낸다.

타당성 검토

구글도 델Dell과 마찬가지로 기숙사 방에서 시작되었다. 스탠포드 대학의 웹 사이트에 구글

검색창이 처음으로 올려졌을 때, 데이터를 수집하는 컴퓨터는 페이지의 방에 있었다. 마이

클 델Michael Dell과 마찬가지로 페이지와 브린도 사업을 시작하기 위해 곧 학교를 그만 두었다.

최악의 상황이라고 해봐야 다시 학교로 돌아가서 학위를 마무리하는 것뿐이었다. 구글은

1998년 설립되었으나, 페이지와 브린이 타당성을 검토하는 1년에 가까운 기간 동안, 제품

에는 ‘베타’ 표시가 붙어 있었다. 구글이 대중 매체의 주목을 받기 시작하고, 트래픽이 증가

하면서 페이지와 브린은 초기 투자금을 확보하였다. 마침내 베타 표시가 제거되고 연구 프

로젝트가 실제 제품의 토대로 탈바꿈하였다.

제품 개발의 타당성 검토 단계는 실험의 기회를 제공한다는 점에서 중요하다. 타당성 검

토는 논문 연구가 아님을 주목하라. 컨셉을 구상한다는 것은 좋은 것이다. 그러나 실제 세

상에 내놓고 검토하는 것에 비할 만한 것은 없다.

9 SergeyBrin과LawrencePage,“TheAnatomyofaLarge-ScaleHypertextualWebSearchEngine,”ComputerNetworksand

ISDNSystems,30(1–7):107–117,1998년4월.번역서로는『대중의지혜』,홍대운역,랜덤하우스중앙,2005가있다.

10 토머스에디슨의말을인용한것임.

54

Value _3

Story 수작업 견본

3M의 타당성 검토 단계에서 가장 기억에 남는 것은 수작업 견본이다. 수작업 견본은 실험실

에서 가장 기본적인 수작업 장비로 만든 견본 또는 부품을 뜻한다. 그럼에도 불구하고 수작

업으로 만든 이 견본들은 최종 제품을 미리 시험해 볼 수 있는 아주 좋은 시료 역할을 해 주

었다.

우리는 많은 수작업 견본들을 검토한 후, 각 견본에 주의 깊게 라벨을 붙여서 나중에 시험 결

과와 견본의 특성을 연관지을 수 있게 하였다. 또 견본을 시험해 보기 위해 다양한 시도를 하

였는데, 견본을 파괴해 보거나 태양빛에 노출시키거나, 혹은 이런 시험을 고객이 직접 해보

도록 했던것 같다.

나에게 있어서, 타당성 검토 단계는 제대로 기능을 하는 것이 무엇인지를 알아내기 위해 실

제 사용 조건 아래 실제 고객들과 함께, 즉 현장에서 수많은 시험을 해보는 것이다.

- 메리 이야기

이 단계는 시스템 아키텍처를 설계할 때이기도 하다. 시스템 설계는 매우 중요한 규범인

데도 많은 회사들이 하지 않는 것 같다. 비즈니스 프로세스의 주요 기능이 무엇이며, 하드

웨어의 핵심 모듈은 무엇인가? 시스템은 어떤 인터페이스를 가져야 하며, 어떻게 상호작용

해야 하는가? 소프트웨어 아키텍처는 어떻게 구성할 것인가? 시스템의 핵심 제약조건은 무

엇이며, 그것을 어떻게 만족시킬 것인가? 탁월한 시스템 설계는 탁월한 제품의 초석이 된

다. 이것은 아마추어가 해서도 안 되고 전문가라 하더라도 멀리 떨어져 있어서는 안 된다.

제품이 출시됨에 따라 시스템 설계는 진화할 것이다. 따라서 진화가 수월하게 진행될 수 있

도록 사전에 고려할 수 있는 숙련된 설계자들이 시스템 설계를 수행해야 한다.

파일럿

구글은 웹 참조 수에 기초하여 페이지에 순위를 매기는 시스템으로 출발했다. 그것이 동작

하자마자 과학자들은 그들이 생각해낼 수 있는 온갖 종류의 데이터를 모으기 시작했다. 어

떤 결과가 사용되고 어떤 것이 사용되지 않는지, 특정 결과를 찾기 위해 어떤 종류의 검색

문구가 사용되는지, 어떤 종류의 맞춤법 실수가 가장 빈번한지, 얼마나 빨리 결과를 내놓

는지, 사용자들이 얼마나 빨리 답을 얻는지 등의 것들이다. 구글은 이러한 광범위한 데이

55

3_ 가치

터 분석에 근거하여 계속해서 그들의 순위 시스템과 하드웨어 및 소프트웨어 아키텍처를 조

율해나갔다. 구글은 방대한 자료 구조를 처리하는 애플리케이션을 쉽게 개발할 수 있도록

하는 도구를 개발했다. 시험용 애플리케이션을 많이 개발하여 구글랩스에 올려 놓고, 사용

자들이 관심있는 것에 투표하도록 했으며, 여기서 얻은 피드백을 반영하여 애플리케이션을

개선했다. 그리고 고객을 귀찮게 하지 않으면서도 고객이 유용하다고 느끼도록 광고를 게

재하여 수익을 올리는 방법을 찾기 위해 다방면으로 실험을 했다.

제품 개발의 타당성 검토 단계가 끝났다고 제품이 다 만들어져서 나올 것이라고는 아무도

기대하지 않는다. 타당성 검토는 단지 제품이 “가능성이 있다”는 것을 밝힐 뿐이다. 그 시

점부터 제품 개발의 진정한 학습이 시작된다. 훌륭한 제품 개발은 제품 설계를 더욱 세련되

게 다듬는 시행과 학습의 반복을 통해 이루어진다. 이 시점의 목적은 제품을 완성하는 것이

아니라 일부 기능들을 묶어 파일럿 테스트가 가능할 정도로만 만드는 것이다. 점점 완성도

높은 파일럿 제품이 만들어지면서 완제품이 세상에 나오게 된다.

소프트웨어 개발에서의 파일럿 단계는 하드웨어에서의 같은 단계보다 실제 고객에게 출

시할 가능성이 더 높다. 하지만, 8장에서 보게 될 폴라리스Polaris 잠수함 프로젝트 경우에는

애초 9년이 목표였지만 3년만에 작동하는 잠수함을 만들어냈다. 하드웨어의 파일럿 제품

이 고객에게 전달되지는 않는다 해도, 개발 단계에서 가능한 빨리 파일럿 제품을 만들어 임

베디드 소프트웨어와 함께 통합해 보려는 시도는 매우 좋은 생각이다.

시스템 설계가 잘 이루어졌다면, 파일럿 단계에서 소프트웨어를 고객에게 출시하는 것은

거의 대부분 유익하다. 물론 조기 출시가 항상 가능한 것은 아니다. 예를 들어 임베디드 소

프트웨어는 하드웨어보다 먼저 출시할 수 없다. 게임 프로그램은 일부만 완성된 상태로는,

심지어 리뷰어reviewer들에게조차 출시할 수 없다. 왜냐하면, 게임 업계에서는 첫인상이 가

장 중요하며 판매대에 올려져 있는 기간도 매우 짧기 때문이다. 그러나 대부분의 경우 알파,

베타 버전 출시를 통해 소프트웨어를 평가해야 한다는 것이 우리 의견이다. 특히, 레거시

시스템을 새롭게 고치는 프로젝트에서라면, 최소한 실제와 같은 환경을 따로 만들어서라도,

실제 사용자와 실제 (대개는 뒤죽박죽인) 데이터베이스를 가지고 돌려보지 않고서는 사전

에 잘 동작할지 알 수가 없다.

56

Value _3

현금

구글은 마침내 큰 돈(그들이 광고주와 사용자들에게 제공한 가치에 의해 발생한 돈)을 벌기

시작했다. 구글은 검색결과를 광고와 연결짓되, 사용자를 귀찮게 하지는 않는 방법을 찾아

내기까지 상당 기간 동안 실험과 학습을 해야만 했다. 구글의 경쟁 상대가 없는 것은 절대

아니다. 현금의 흐름을 유지하려면, 사용자들에게 끊임없이 획기적인 가치를 제공해야 한다.

감동하는 고객

1984년 동경 리카Rika 대학의 가노 노리아키(狩野 纪昭) 박사는 “매력 품질attractive quality”이

라는 획기적인 논문을 발표하였다.11 거기서 그는 고객을 감동시키는 위대한 제품을 창출하

는 방법을 명확히 하는 도구인 가노 모델을 발표하였다(그림 3.1 참조).

그림 3.1 ㅣ 가노 모델

11 KanoNoriaki,NobuhikoSeraku,FumioTakahashi,ShinichiTsuji:"AttractiveQualityandMust-BeQuality,"Hinshitsu.The

JournaloftheJapaneseSocietyforQualityControl,April1984,pp.39–48.

가노 모델

고객 만

족

품질 수준

매력 품질

성능 품질

당연 품질

57

3_ 가치

가노 모델에 따르면, 시장 진입의 전제 조건은 고객의 기본적인 요구를 만족시키는 것

이다. 일단 진입에 성공하면, 2가지 차별화 방법이 있다. 1) 기능을 추가함으로써 성능을

향상시키거나, 2) 고객이 미처 생각하지 못한 요구를 찾아서 만족시킴으로써 고객을 감동

시키는 것이다. 가노는 성능을 증가시키는 것은 선형적인 결과, 즉 성능이 증가함에 따라

고객만족도가 증가하는 결과를 낳는다고 보았다. 고객만족도를 획기적으로 높이기 위해서

는, 고객이 아쉬워하는 요구를 발견하고 그것을 만족시킴으로써 고객에게 놀라운 기쁨을

선사해야 한다. 가노는 단순히 고객이 요구하는 것을 듣는 것만으로는 위대한 제품을 만

들 수 없고, 고객의 환경을 깊이 이해하고, 아쉬워하는 요구를 발견하여, 그 요구를 만족

시켜 고객을 놀라게 해야 위대한 제품을 만들 수 있다고 하였다. 이것이 고객을 감동시키

는 방법이다.

구글은 고객을 감동시키는데 매우 뛰어나 보인다. 강연과 교육으로 세계를 돌아다니면서

우리는 다음과 같은 질문을 던지곤 했다. 이 방에 계신 분들 중 얼마나 많은 분들이 구글을

좋아하나요? 매번 거의 모든 사람들이 손을 든다. 그리고 이어지는 대화 속에서, 우리는 사

람들이 구글 제품을 이용하는 방식이 생각보다 훨씬 다양하다는 사실에 놀라게 된다. 우리

아들은 정기적으로 구글의 독특한 신기능에 대해 알려주고, 손녀는 구글을 사용하여 초등

학교 과제를 수행한다.

고객에 대한 깊은 이해

“위대한 소프트웨어는, 비즈니스를 정말로 잘 이해하는 사람과 기술을 정말로 잘 아는 사람

과의 정신적 교감에 의해 만들어진다”라고 톰이 기자에게 말했다. 갑자기 기자의 눈이 빛났

다. “이해합니다!”라고 외치면서 그는 인터뷰를 잠시 중단하고 우리에게 다음과 같은 이야

기를 들려주었다.

1990년대 후반, IT 열풍과 함께 모든 신문사가 웹 사이트를 서둘러 구축해야 했습니다.

다른 모든 신문사들은 웹 사이트 설계를 위해 외부 회사에 용역을 주었지만 저희는 프로

그래머 한 명을 고용하여 함께 일을 했어요. 처음에는 그가 하는 이야기를 알아듣는 것조

차 어려웠지만, 얼마 지나지 않아 웹 사이트가 어떤 것인지 이해할 수 있었습니다. 사업

가인 제가 기술자와 협력하여 무엇이 필요하고 어떤 것이 가능한지를 같이 배우게 된 셈

이었죠. 마침내 상당히 가치있는 기능을 구현할 수 있었습니다. 경쟁자들이 컨텐츠를 무

58

Value _3

료로 제공하고 있을 때, 저희는 오히려 컨텐츠에 대한 구독료를 올리기로 결정했습니다.

구독료는 올랐지만 매우 많은 비율의 구독자들이 이를 받아들였습니다. 요즘 저희와 비슷

한 규모의 모든 신문사들이 재정적인 어려움을 겪고 있지만, 저희 회사의 수익성은 매우

높습니다.

세상에는 그저 그런 수준의 소프트웨어들이 널려있지만, 가끔은 정말 혁신적인 소프트

웨어가 나타나 우리의 이목을 끈다. 그러면 우리는 “어떻게 그런 혁신적인 제품을 만들었

을까?”, 좀 더 정확히 말하면 “어떻게 하면 우리도 그런 제품을 만들수 있을까?”를 궁금해

한다.

해야 할 업무에 집중하라

1982년 30세의 스캇 쿡Scott Cook도 똑같은 고민을 하고 있었다.12 그 때는 IBM PC가 막

도입된 때였고, 쿡은 PC를 갖고있는 사람들에게 판매할 소프트웨어를 만드는 기업가 중

한 사람이었다. 쿡은 경쟁자들에 비해 비교우위를 갖고 있었다. 그는 P&G에서 5년간 브

랜드 관리 업무를 하면서, 사람들의 삶을 변화시키는 제품을 기획하고 판매하는 전략을 익

혔다. P&G의 수준 높은 브랜드 매니저들이 업무를 어떻게 하는지 경험하게 된 셈이었다.

그는 아직 최적의 도구가 없어 손길을 기다리는 작업을 찾기 시작했다. 그러다 그는 부인

이 가족의 재정을 관리하는데 매우 힘들어하는 것을 보고, 그 작업을 도와줄 더 나은 재정

관리 소프트웨어가 필요하다고 판단하였다. 이러한 발견을 쿡 혼자서만 한 것은 아니었다.

그가 인튜이트Intuit 社(미국의 세금 관리 및 지불 관리 솔루션 판매업체)를 설립하고 1983

년 Quicken(인튜이트의 회계관리 프로그램)을 출시하기까지 46개 이상의 경쟁사들이 난립

하고 있었다.

P&G에서 쿡은 사람들이 필요로 하는 업무가 무엇이고, 현재 도구에 무엇이 잘못되었는

지, 그리고 그 업무를 더 잘한다는 것이 무엇을 의미하는 지를 철두철미하게 이해하고자 했

다. 그리고 이를 통해 경쟁을 다루는 방법을 배울 수 있었다. 그는 먼저 사람들이 어떻게

그들의 재정을 관리하는지를 차근차근 조사하는 것부터 시작했다. 대부분의 사람들은 단지

3가지 일만을 한다. 요금을 지불하고, 수표 기록을 관리하고, 주기적으로 경비 합계를 내

고 검토하는 것이다. 또한 사람들은 이러한 업무를 즐겁게 느끼지 않으며, 따라서 이것들을

12 SuzanneTaylorandKathySchroeder"InsideIntuit",HarvardBusinessSchoolPress,2003.참조.

59

3_ 가치

가능한 빨리 끝내고 싶어한다는 것을 알아냈다. 그래서 Quicken은 처음부터 이 3가지 일에

만 집중하여, 그 일을 수작업으로 하는 것보다 더 빠르게 하는 것을 목표로 설계되었다. 경

쟁에 대한 그의 이러한 철학을 실행에 옮김으로써, 쿡은 기존의 소프트웨어 업계 경쟁자들

을 완전히 따돌릴 수 있었을 뿐만 아니라, 경쟁 자체를 바꾸어 놓았다.

P&G의 전략은 제품 수명주기 전반을 고려하고 있었다. 쿡은 경쟁사의 재정관리 소프트

웨어가 너무 많은 기능들을 갖고 있는데다, 설치에 몇 시간이나 걸린다는 것을 발견하였다.

쿡은 PC 초보자라도 설치할 수 있고 15분 내에 수표를 발행할 수 있는 매우 단순한 프로그

램을 만들기로 결심했다. Quicken 1.0의 기능과 구조를 단순화하고 목표를 달성하는지 테스

트하기 위해, 그는 사용성 테스트와 유사한 것을 고안해냈다. 수많은 기능을 갖고 있던 경

쟁사 제품은 이 테스트에서, 숙련된 PC 사용자가 첫 수표를 발행하기까지 최대 5시간까지

걸리는 것으로 확인되었다.

단지 더 좋은 도구를 개발했다는 것만으로는 충분하지 않다고 생각했던 인튜이트는, 패

키징과 가격책정에 까지 연구 범위를 확대하였다. 해야 할 업무가 있는 사람들은 그 업무를

하는데 더 나은 도구가 있다는 사실을 어떻게든 알게 된다. 인튜이트는 지속적인 개선을 통

해, 마침내 재정 업무에 관한 한 최고의 도구로서 입지를 굳건히 하게 되었다. 쿡은 가치를

창출하기 위해서는, 해야 할 업무에 집중하여 제품을 개선하고 그 제품이 다른 어떤 대체품

보다도 그 업무를 더 잘 지원해야 한다고 주장한다.13

Story 나의 고객들

내가 공정제어 시스템을 개발할 때는, 누가 나의 고객인지(생산라인을 제어하는 작업자들)

그리고 그들이 하려는 업무(테이프 만들기)가 무엇인지는 의심의 여지가 없었다. 만약 우리

의 시스템이 그 업무에 도움이 되지 않는다면 그들은 시스템을 사용하지 않고 테이프를 만들

것이다. 따라서, 우리의 임무는 명확했다. 만약 작업자들이 여러분의 시스템을 사용하지 않

는다면 그것은 여러분의 잘못이다. 수행해야 할 업무가 무엇인지 이해하지 못한 것이다.

- 메리 이야기

13 ClaytonChristensen,ScottCook,TaddyHall,"MarketingMalpractice:TheCauseandtheCure,"HarvardBusinessReview,2005년12월

60

Value _3

고객중심 조직

위대한 제품은 어떻게 구상되고 개발될까? 1991년 클라크Clark와 후지모토Fujimoto는 『Product

Development Performance』14에서, 위대한 제품은 탁월하고 세밀한 정보 흐름의 결과라는 강

력한 증거를 보여주었다. 고객이 제품을 어떻게 인지하는가 하는 것은 시장과 개발 팀 간에

이루어지는 정보 흐름의 품질에 의해 결정된다. 제품의 기술적 무결성은 개발 팀 동료 간에

이루어지는 정보 흐름의 품질에 의해 결정된다. 이러한 정보 흐름을 촉진시킬 수 있는 방법

이 있다. 1) 먼저 리더십을 제공하고, 2) 다음으로 완전한 팀에 권한을 위임하라.

리더십

우리는 성공적인 제품 개발이 챔피언의 존재와 깊이 관련되어 있음을 오랫동안 보아왔다.

챔피언은 고객의 업무를 잘 알고 있음은 물론 어떤 기술이 고객을 놀라게 또는 기쁘게 하는

지 깊이 이해하고 있어야 한다. 또한, 챔피언은 제품에 대한 핵심 의사 결정을 내려야 하며

그 결과에 대해서도 책임을 진다. 실리콘밸리 제품그룹Silicon Valley Product Group의 마틴 케이건

Martin Cagan은 이렇게 말한다.15

위대한 제품 뒤에는 어김없이 고객에 대한 깊은 공감과 가능성에 대한 통찰력, 그리고 무

엇이 필수적이고 무엇이 부수적인지를 볼 수 있는 능력을 가진 사람이 있다. 이 사람은

자신의 팀이 가진 능력뿐만 아니라 고객에 대해서도 깊이 이해하고 있다. 그는 풍부한 배

경 지식과 확신을 가지고 일을 추진한다. 그는 시장에 우월한 가치를 제공하는데 중점을

두며, 전력투구해야 만들 수 있는 훌륭한 제품을 정의한다. 이러한 사람은 제품 관리자의

직책을 가진 사람이거나, 또는 일개 엔지니어로부터 회사 창립자까지 누구나 될 수 있다.

중요한 것은 반드시 그 역할이 존재해야 하며, 필요한 스킬과 재능을 갖춘 사람이 그 역

할을 수행해야 한다는 것이다.

힘겹게 진행되는 개발 프로젝트를 보면 대개 챔피언 역할이 없는 경우가 많다. 챔피언 역

할을 갖추고자 할 때 참고할 수 있는 몇 가지 모델이 있다. 좋은 모델은 제품 성공에 대한

책임과 의무를 누가 가지는가를 명확히 한다.

14 KimClark와TakahiroFujimoto,"ProductDevelopmentPerformance",HarvardBusinessSchool,1991.

15 SiliconValleyProductGroup의MartinCagan,“BehindEveryGreatProduct—TheRoleoftheProductManager,”2006년2월7일;

www.svproduct.com.에서백서(whitepaper)를다운받을수있음.허가받아인용하였음.

61

3_ 가치

수석 엔지니어

도요타에서는 수석 엔지니어가 자동차 제품군의 사업적 성공에 대한 책임을 진다. 그는 자

동차 설계에 대한 심도있는 지식을 갖춘 경험 많은 엔지니어이다. 그는 소수 지원 인력의

도움을 받아 목표 고객을 심층 분석하고 고객이 무엇에 가치를 두는지를 파악한다. 또한,

마케팅 조사 결과를 검토하며, 딜러와 이야기하고, 목표 고객이 자주 들리는 장소를 방문

하여 그들을 관찰하고 질문을 던진다. 그는 진보된 개발 방법과 스타일, 그리고 생산 기법

을 검토한다. 그는 고위 경영진으로부터 자금을 얻어내고 방침을 부여 받는다. 그러나 궁

극적으로 이러한 정보를 통합하고, 고객이 무엇에 가치를 두는지를 결정하며, 제품의 컨셉

을 작성하고, 개발을 관리하는 등의 일은 수석 엔지니어의 몫이다.16

시에나Sienna의 예를 보자. 도요타에서 처음으로 출시한 미니밴은 그다지 많이 팔리지 않

았다. 수석 엔지니어인 유지 요코야Yuji Yokoya가 그 차량을 개선하려고 했을 때, 그는 포커스

그룹이나 고객의 소리 데이터 외에 더 많은 것이 필요함을 알고 있었다. 그래서 그는 도요

타의 전통인 ‘겐지 겐부츠(現地 現物)’, 즉 ‘직접 현지에서 현물을 확인하는’ 방법을 따랐다.

그는 미니밴(주로 시에나)을 미국, 캐나다, 멕시코의 모든 주를 거치면서 85,000km를 몰

았다. 그는 주로 설계 팀의 핵심 멤버들과 함께 다녔다. 멤버 중에는 체구가 커서 차량 시

트를 다시 설계하고 싶어했던 존 줄라John Jula란 친구가 있었다. 그는 여행하면서 시에나의

고객들이 가치를 두는 것이 무엇인지를 이해하게 되었다. 그것은 넓은 공간, 부모를 위한

편안한 앞 좌석, 아이들을 고려한 뒷 좌석, 그리고 가족 할인 가격이었다. 그 결과로 나온

2004년형 시에나는 미니밴의 매출을 두 배 이상으로 끌어 올렸고, 당시의 치열한 경쟁을

뚫고 정상에 올랐다.

우리는 최근에 시에나 미니밴을 구입했다. 우리는 다른 모델도 진지하게 고려했지만, 다

른 모델들은 앞 좌석에 발을 놓는 부분이 비좁았다. 우리는 휴가 때 수일 동안 차를 타는 경

우도 있어서 앞 좌석의 편안함이 매우 중요하다. 시에나를 시운전하면서 우리는 존이 그 차

량의 앞 좌석을 설계할 때 우리같은 사람들을 염두에 두고 있었음을 알 수 있었다.

이처럼 수석 엔지니어를 이용하는 접근은 단 한 명의 책임자 머리 속에 수많은 정보를 통

합할 수 있다는 장점이 있다. 또한, 오너십이 만들어내는 기업가적 정신은 줄곧 시장에 뛰

16 이문단은DurwardKennethSobek II의1997년미시간대학산업공학과박사학위논문인“PrinciplesThatShapeProduct

DevelopmentSystems:AToyota-ChryslerComparison”의7장에서참조하였다.

62

Value _3

어난 혁신을 가져왔다. 팀은 위대한 리더를 따르고 싶어한다. 왜냐하면, 위대한 리더는 팀

전체를 성공적으로 만드는 것을 돕기 때문이다.

대부분의 오픈소스 프로젝트에는 ‘강한 프로젝트 리더’(즉 수석 엔지니어)가 있다.17 이러

한 오픈소스 프로젝트는 한 개인의 비전으로부터 시작하며, 많은 자발적 지원자들이 참여

하는 경우라도 최종적으로 모든 코드를 검토하거나 승인하는 것은 프로젝트 리더나 그가 직

접 고른 지원자가 맡는다.

수석 엔지니어 방식이 만병통치약은 아니다. 수석 엔지니어 직책을 맡은 사람이 전체 팀

원의 다양한 역량을 높이는 대신 관리에만 집중하는 경우도 생길 수 있다. 오픈소스 프로젝

트에서는 이런 걱정을 할 필요가 없다. 오픈소스 프로젝트 리더는, 만약 그가 좋은 의미의

‘리더’가 아니라고 한다면, 개발자들이 자발적으로 참여하도록 끌어당기는 것 자체가 불가

능하기 때문이다. 그러나 수석 엔지니어를 육성하기 위한 훌륭한 교육 기반이 없거나 수석

엔지니어가 지식을 통합하는 것보다 작업 관리task management에만 집중해야 한다고 믿는 회

사에서는 문제가 될 수 있다.

성공한 소프트웨어 회사의 대부분은 충족되지 않은 시장의 요구에 대한 명확한 통찰과 기

술적인 역량을 겸비한 기업가에 의해 설립되었다. 이베이eBay는 좋은 사례이다. 실제로 이

러한 회사들은 수석 엔지니어가 시작하였다. 불행히도 우리는 회사를 설립한 성공적인 수

석 엔지니어들이 회사가 커지면서 실패한 CEO가 되는 경우를 많이 보아왔다. 그들은 점차

고객 요구사항을 정의하는 일을 마케팅 부서에 넘기면서, 그들을 대신할 새로운 수석 엔지

니어를 육성하는 일에는 소홀히 한다. 5년이나 10년이 지나면서 이러한 회사들은 종종 비

틀거리게 되는데, 경쟁사들이 초기 시장을 잠식해 오는 반면 미래를 구상하고 팀이 위대한

후속 제품을 만들어내도록 이끄는 수석 엔지니어가 없기 때문이다.

리더십 팀

개발의 목적은 아직까지 충족되지 않은 요구를 충족시키는 것이다. 요구가 충족되지 않은

이유는 필요한 신기술이 이제서야 나왔거나, 요구 자체가 인식되지 않았거나, 혹은 둘 다일

수 있다. 때때로 이러한 두 경우를 합치는 가장 좋은 방법은 리더를 두 명 두는 것이다. 즉,

17 EricS.Raymond의"TheCathedralandtheBazaar"참조.www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/,

2000.

63

3_ 가치

시장을 깊이 이해하는 리더와 기술을 잘 아는 리더를 함께 두는 것이다. 예를 들어 인튜이

트에서는 마케팅 전문가와 기술 전문가를 짝짓는 실천법이 회사 창업자로부터 시작되었다.

스캇 쿡은 Quicken의 시장 비전을 만들었고, 톰 프루Tom Proulx는 기술 개발을 이끌었다.18

마케팅과 기술에 이어 세 번째 중요한 요소(예를 들어 제조)가 있다면 제품 개발에 3명의

리더를 두는 것도 의미가 있다. 혼다에서는 제품에 대한 중요한 의사 결정을 위해 판매sales,

공학engineering, 개발development 리더들이 팀을 이루는, 이른바 SED 시스템을 운영한다. 혼

다 역시 마찬가지로 SED 리더십 팀 위에 도요타의 수석 엔지니어와 유사한 대규모 프로젝

트 리더Large Project Leader를 두고 있다.

제품의 가장 중요한 부분에 리더십을 제공하는 것이 중요하다. 예를 들어, 앨리어스Alias 社19

에서는 제품의 특성상 고객 경험이 특히 중요하다. 그래서 가능한 많은 팀에 고객 조사, 상

호작용 설계, 사용성 시험을 모두 책임지는 상호작용 설계자를 2명씩 배정한다.20 사용자

환경조사, 인터뷰, 설문조사, 사용성 시험 등을 통해 수집되는 고객 피드백이 엄청나지만,

상호작용 설계자는 소프트웨어가 완수하고자 하는 일에 대한 깊은 이해를 바탕으로 그러한

정보들을 종합하여, 그 일을 최상의 방법으로 수행하는 제품을 설계한다.

리더십 팀의 멤버는 서로 ‘절친한’ 관계이어야 하며, 전체 개발 팀에게 통일된 방향을 제

시해야 한다.

리더십 공유하기

크라이슬러의 NS 미니밴 플랫폼Caravan/Voyager/Town & Country은 1996년 처음 도입되자마자 히

트 상품이 되었다. 운전석 측에 승객 문을 추가함으로써 미니밴의 개념을 재정의하였으며

모터 트렌드Motor Trend로부터 ‘올해의 자동차 상’을 받았다. 사실 우리는 1997년식 크라이슬

러 Town & Country 미니밴을 8년간 몰았었다. 이 차는 수석 엔지니어가 아닌 전문가 팀에

의해 개발되었는데, 그 전문가들은 고객이 무엇에 가치를 두는지에 대한 합치된 의견을 이

끌어내기 위해 함께 일을 진행했다. 그 팀은 광범위한 시장 조사와 품질기능전개QFD를 수행

하였고, 특정한 의사결정을 돕기 위한 사용성 시험법까지 개발하였다. 팀은 그 일에만 전

18 SeeSuzanneTaylorandKathySchroeder,InsideIntuit,HarvardBusinessSchoolPress,2003.

19 토론토에위치한이회사는3D그래픽스제품을개발하였으며,현재는오토데스크에인수되었다.

20 LynnMiller,Autodesk,Toronto,“CaseStudyofCustomerInputforaSuccessfulProduct,”ExperienceReport,Agile2005.

64

Value _3

념하였고, 같은 장소에 있었으며, 많은 시간을 (주로 일주일에 하루씩) 현 상황을 점검하

고, 서로를 교육시키며, 문제를 해결하는데 사용하였다. 팀 리더의 가장 중요한 업무는 개

발 프로세스를 관리하고, 협동과 팀 빌딩을 촉진하며, 합의된 의사결정을 도출하고, 팀이

올바른 길을 가도록 하는 것이었다.21

의사결정에 대한 책임과 의무가 누구에게 있는지는 명확하지 않지만, 리더십을 공유하는

이러한 방법은 적당한 규모의 소프트웨어 개발 프로젝트에서 유용하게 쓸 수 있는 방법이다.

오픈소스 커뮤니티의, 아파치 프로젝트는 리더십 공유하기의 좋은 사례이다.22

책임자는 누구인가?

마케팅과 기술에 있어서의 훌륭한 리더십은 관련 팀이 함께 일하는 것을 방해하지 않는다.

관련 팀은 리더와 함께 고객 조사에 나가고, 다양한 시각에서 질문을 던지며, 이를 통해 고

객 가치에 대한 공통된 시각을 형성한다. 메리는 3M에서 제품 개발을 한 경험이 있는데,

거기서는 모든 신제품 개발에 ‘챔피언’이 필요하다는 것이 당연하다고 여겨졌다. 챔피언은

충족되지 않은 시장의 요구를 파악하고 그것을 채워줄 수 있는 기술을 개발해 온 기술적인

전문가이다. 그러나 챔피언이라고 하더라도 사실상 그 신제품을 상품화하기 위해 작은 사

업단위를 형성하는 다기능 팀이 있지 않고서는 성공할 수 없다. 팀은 시장의 요구를 명확히

파악하고 제품의 핵심 기능을 결정하기 위해 함께 일한다. 3M에서는 챔피언과 모든 중요

기능부서에서 차출된 인원으로 구성된 팀을 묶은 형태로 수십 년간 매년 수천 개의 신제품

을 쏟아내면서 엄청난 성장을 이루고 있다.

3M에서는 일반적으로 개발 팀이 핵심 결정사항에 대한 합의를 이끌어낸다. 그러나 결

국에는 챔피언이 제품에 대한 책임을 지며, 의사결정이 교착상태에 빠지면 이를 타개하는

책임도 진다. 이와 유사하게, 도요타에서도 기본 원칙은 “고품질의 제품 개발을 위해 팀웍

이 매우 중요하지만, 궁극적인 책임은 항상 한 개인이 져야 한다”는 것이다.23 폴 로저스

Paul Rogers와 마르시아 블렌코Marcia Blenko는 “Who Has the D? How Clear Decision Roles Enhance

Organizational Performance”에서, 탁월한 의사 결정은 높은 성취를 이루는 조직의 특징이며,

21 Sobek의이전문헌과동일.Sobek은이팀을직접관찰하고,그의논문에그이야기를실었음.

22 RoyT.Fielding,“SharedLeadershipintheApacheProject,”CommunicationsoftheACM,1999년4월참조.

23 JamesMorganandJeffreyLiker,TheToyotaProductDevelopmentSystem:IntegratingPeople,Process,andTechnology,

ProductivityPress,2006,p.103.

65

3_ 가치

의사 결정 권한을 명확히 하는 것은 탁월하고 시기 적절한 의사 결정을 이루는 바탕이 된다

고 말한다.24

Story 의사결정권자 지정

나는 3M에서 여러 신제품에 대해 챔피언 역할을 맡았었다. 이 일은 나에게 매우 도전적이고

보람있는 일이었다.

서로 다른 기능부서는 각기 다른 견해를 갖고 있었으므로, 주간 개발 회의에서는 의견 불일

치가 늘상 생겨나곤 했다. 나는 가끔 품질 부서가 정말 제품을 시장에 내놓을 생각이 있는건

지, 그리고 마케팅 부서는 제품 개발이 어려운 작업이라는 것을 제대로 이해하고 있는건지

의심하곤 했다. 나는 이런 분쟁 속에서 사람들이 의사결정의 내용보다는 누가 의사결정을 해

야 하는가에 더 집중하는 경우가 더러 있다는 것을 발견했다.

그래서 나는 의사결정권자를 지정하는 것이 매우 도움이 될 것이라고 생각했다. 나는 우선

그 자리에서 결정을 내리기에 가장 적합한 기능부서를 선택했다. 품질 부서는 최종 출시에

관한 결정을, 마케팅 부서는 어떤 전시회에 출품할 것인지에 관한 결정을, 개발 부서는 특정

기능이 기술적으로 쉬운지 어려운지에 관한 결정을 내리도록 했다.

의사결정권자를 지명하자 토론의 흐름이 즉시 바뀐 것을 알 수 있었다. 팀 멤버들은 의사결

정권자가 그들의 관점으로 문제를 바라보도록 로비를 하기 시작했다. 의사결정권자는 다른

사람들의 관점을 포함할 수 있도록 자신의 관점을 수정했다. 그 뒤로 토론에서는 누가 결정

을 내려야 하는가가 아닌 결정할 내용에 주로 집중하게 되었다.

- 메리 이야기

완전한 팀

완전한 제품은 완전한 팀에 의해 개발된다. 인튜이트의 임원진이 ‘Quicken 임대 부동산 관

리자’ 프로그램을 개발하기로 결정하였을 때, 그들은 ‘소프트웨어 개발자뿐만 아니라’ 제품

을 시장에 출시하는데 필요한 모든 사람을 포함하며, 브랜드 챔피언이 리드하는 개발 팀을

24 PaulRogersandMarciaBlenko,“WhoHastheD?HowClearDecisionRolesEnhanceOrganizationalPerformance,”Harvard

BusinessReview,January2006.

66

Value _3

구성하였다.25 그 팀 멤버들은 전부터 같이 일한 적이 있었다.(그들은 20년간 Quicken 업그

레이드에 참여한 베테랑들이었다). 그러나 이 프로젝트는 그들에게도 처음이었다. 새로운

Quicken 브랜드의 제품이 몇 년에 걸쳐 처음으로 개발되려는 것이었다. 팀에게 맡겨진 임

무는 최대한 빨리 그 과업을 수행하는 딱 맞는 프로세스를 개발하면서 고객의 문제를, 더도

말고 덜도 말고 꼭 필요한 만큼만, 해결하는 것이었다.

개발 팀은 그들의 주 업무가 학습하는 것이라고 결정하였다. 여기서 학습은, 꼭 필요한

기능만을 개발할 수 있도록 고객의 업무에 대해 학습하는 것과, 낭비없이 딱 필요한 만큼의

구조를 제공하는 프로세스에 대해 학습하는 것을 포함한다. 개발 팀은 관리 팀과 같이 정기

적으로 회의에 참석하여 현황을 보고하고 방침을 전달받으며, 다음 단계까지 계속할 것인

지에 대한 승인을 받았다. 이러한 각각의 회의에서 개발 팀은 그동한 학습한 것과 다음 점

검까지 무엇을 학습할 계획인지 보고하였다. 이러한 회의에서 부여받은 방침 외에, 제품 및

프로세스에 대한 의사결정은 팀이 스스로 해나갔다.

Quicken 임대 부동산 관리자 개발 팀은 단체로 고객 인터뷰를 나가는 것부터 시작하였다.

팀원들은 개발자들이 마케팅 부서 사람들과는 다른 질문을 한다는 것을 발견했으며 각자의

다양한 시각 덕분에 모든 팀원이 고객에 대한 깊은 통찰을 얻을 수 있었다. 그들은 개발 프

로세스가 이전 프로젝트 만큼의 문서작업을 요구하지 않는다는 것을 발견했다. 왜냐하면,

팀의 모든 사람이 고객으로부터 같은 내용을 들었기 때문이었다.

팀원들은 그 도전에 의해 활력을 얻었으며 신제품과 새로운 프로세스를 개발하는데 완전

히 몰입하게 되었다. 1년 내에, Quicken 임대 부동산 관리자 프로그램은 평가판을 출시했

는데 깔끔한 인터페이스와 단순한 설정 및 운영 방법으로 커다란 반향을 불러 일으켰다.

운영 용이성 설계

생산 엔지니어들을 제품 설계 팀에 합류하도록 하면서부터 제조 품질에서 큰 발전이 가능

해졌다. 모든 설계는 승인하기 전에 설계대로 제조가 용이한지에 대한 평가가 이루어졌다.

그때부터 빨리 제조하기에 좋을 뿐만 아니라 수리하기도 용이한 제품들을 보게 되었다. 이

것을 제조 용이성 설계라고 불렀다.

25 SoniMeckem이LeanDesign&Development2005,Conference,Chicago,March,2005에서발표함.

67

3_ 가치

Story 제조 용이성 설계

예전에 우리 공장에서는 비디오 카세트를 수작업으로 조립했었다. 공장장은 모든 부서장들

에게 일정 시간을 생산라인에서 일하도록 지시했기 때문에 나도 가끔씩 비디오 카세트를 조

립하는 심야 교대 근무를 하곤 했다. 어떤 나사는 플라스틱 조각이 드라이버 공간을 막고 있

어서, 나사를 박을 때 특별히 제작된 휘어진 드라이버를 사용해야 했다. 그 특별한 공구를 잡

으려고 손을 뻗치고 나사 위치를 잡느라 시간을 소모할 때마다 나는 그 제품를 설계한 사람

을 생산라인에 데려와서 카세트를 몇 대 조립하도록 시키는 상상을 하곤 했다.

그 뒤로는 설계 엔지니어가 나에게 보고를 할 때면 항상 설계를 제조 팀의 검토를 받고 나

서 설계를 마무리하도록 요청했다. 설계자들은 처음엔 당황했지만, 곧바로 제조의 현실에 대

해 존중하는 마음을 갖게 되었다. 얼마되지 않아 그들은 도면을 이틀에 한 번씩 제조 감독자

에게 들고 와서 의견을 듣게 되었다. 말할 필요도 없이, 그 새로운 설계는 조립이 용이하도록

수정되어 있었다.

- 메리 이야기

소프트웨어 개발에서 제조 용이성 설계와 마찬가지인 것이 바로 운영 용이성 설계이다.

소프트웨어 개발에서 컴퓨터 운영, 네트워킹, 유지보수, 고객지원 등은 과소평가된다. 모

든 개발 팀에는 소프트웨어가 실제로 사용될 때 어떠한 문제가 발생할지, 그러한 문제들이

일어나지 않도록 하거나 일어난 후 복구하기 위해 어떤 기능이 필요한지를 고려하도록 독려

하는 팀원이 있어야 한다.

Story 잘못될 수 있는 모든 것은 결국 잘못되고야 만다

예전엔 개발자였고 지금은 운영 관리자인 내 친구가 아주 좋아하는, 개발자들이 명심해야 할

격언이 있다. “잘못될 수 있는 모든 것은 결국 현장에서 잘못되고야 만다. 따라서 우리는 그

러한 문제들을 발견하고, 억제하며, 문제로부터 복구하는 방법이 있어야 한다.” 얼마 전 그로

부터 최근에 발생한 문제를 묘사하는 메일을 받았다.

“XYZ라는 회사가 있는데 이 회사는 기본적으로 매주 소프트웨어를 배포하고 있어. 배포할

때마다 구현하기로 한 기능이 누락되지 않고 회귀 테스트에서 결함이 많이 나오지 않도록 신

경쓰고 있는데, 문제는 장시간 띄워놓거나 부하가 주면 시스템이 불안정하다는 거야. QA에

서 기능시험을 통과해도 여전히 배포할 수준에는 미치지 못하는 경우가 많아.”

68

Value _3

나는 소프트웨어가 문제를 일으킬 때마다 근본 원인 분석을 해보라고 제안했다. 알고보니 그

는 이미 나보다 앞서 있었다.

“문제가 있을 때마다 철저한 사후 분석을 빼놓지 않고 실시하고 있어. 같은 문제가 매번 발

생하는 건 아니지만 문제들이 패턴을 보이긴 해. 문제들이 추적해보면 결국에는 안전하지 못

한 코딩 관행과 관련되어 있다는 걸 발견했어. XYZ의 개발자들은 거의 매주 사이트를 다운

시키는 새로운 방법을 발견하고 있는 셈이지."

불행히도, 그 개발 팀은 더 이상 그 소프트웨어에 책임을 느끼지 않았고, 문제 분석 결과에도

관심을 갖지 않았다.

- 메리 이야기

고객 주문형 개발

특수한 응용환경의 소프트웨어를 개발한다고 해서, 가치를 창출하고 고객을 감동시켜야하

는 의무를 면할 수는 없다. 목표는 여전히 그 소프트웨어에 비용을 지불하는 조직에 뛰어난

가치를 제공하는 것이다. 오히려 리더십과 완전한 팀에 대한 필요성은 범용 제품을 만들 때

보다 주문제작의 경우에 더욱 중요하다. 왜냐하면, 경쟁에 대한 압박이 없어 성공적인 소

프트웨어 제품을 만드는 회사의 핵심 역량인 강력한 고객 중심 사상을 약화시킬 수 있기 때

문이다.

프로젝트에서 제품으로

커스텀 소프트웨어(고객 주문 소프트웨어)는 흔히 프로젝트 형태로 개발된다. 그러나 우리

는 제품 개발이 더 유용한 모델이라고 생각한다. 프로젝트 모델에서 가장 흥미있는 것 중

하나는 프로젝트 자금의 대부분이 프로젝트 초기에 한꺼번에 지급된다는 사실이다(그림 3.2

참조). 자금이 지급되고 나면, 자연스럽게 “투자의 결과로 무엇을 만들어야 하는가? 그리

고 언제 그것을 완료해야 하는가?”라는 질문을 하게 될 것이다. 어쨌거나 자금이 지급되었

으므로 이러한 질문에 대한 답은 상호 간 약속에서 찾을 수 있다. 결국 프로젝트의 성공은

비용과 일정, 그리고 프로젝트 범위에 대한 약속이 지켜졌는가에 의해 판단된다.

69

3_ 가치

그림 3.2 ㅣ 전형적인 프로젝트 모델의 자금 지급

반면에, 제품 개발 모델에서는 자금 지급이 점진적으로 이루어진다(그림 3.3참조). 이러

한 점진적 자금 지급 방식은, 지식을 획득함에 따라 개발 범위가 점차 변화해 나간다는 확

실한 신호이다. 제품 개발의 성공은 일반적으로 그 제품이 궁극적으로 달성한 시장 점유율

과 수익에 의해 결정된다.

프로젝트와 제품 개발 모델 사이에 또 다른 차이점들이 있다. 프로젝트는 시작과 (명백

한) 끝이 있다. 반면, 제품 개발에 시작은 있지만 (바라건대) 끝은 없다. 소프트웨어는 프

로젝트라기보다 제품 개발에 훨씬 더 가깝다. 왜냐하면, 대부분 좋은 소프트웨어는 오랫동

안 사용되고 변화해가기 때문이다. 2장에서 언급했듯이, 전체 소프트웨어의 과반수 이상이

첫 공식 릴리스 이후에 개발된다.

그림 3.3 ㅣ 전형적인 제품 개발 모델의 자금 지급

프로젝트 시작

완 료

유지 보수

컨 셉타당성 검토

내부 릴리스알파 릴리스

베타 릴리스

첫 공식 릴리스

마이너 업그레이드

메이저 릴리스

70

Value _3

Story 커스텀 시스템 개발에 ‘완료’는 없다

공정 제어 시스템을 설치하기 위해 공장에 갔을 때, 우리는 많은 변경 요청이 있을 것이라는

말을 들었다. 이것은 좋은 신호라고 볼 수 있었다. 만약 우리 시스템이 그 공장에 도움이 된

다면, 시스템을 활용하기 위한 더 좋은 아이디어들을 많이 쏟아낼 것이었다.

우리는 제어 시스템이 계속해서 변할 수밖에 없다고 판단하고, 시스템을 항상 설정 변경이

가능하도록 설계하였다. 초기의 객체지향에 관한 일부 아이디어들은 공정 제어 시스템으로

부터 비롯되었다. 왜냐하면, 이 시스템은 펌프, 롤러, 오븐 등과 같은 객체에 기반하여 설계

되었기 때문이다. 테이프 생산라인은 계속해서 다른 제품들을 생산하기 때문에, 제어 시스템

은 조작자가 이러한 객체들의 속도, 압력 그리고 온도를 아주 쉽게 고칠 수 있어야만 한다.

이렇게 설정을 손쉽게 변경할 수 있는 시스템이었음에도 불구하고, 우리는 항상 공장 운영자

가 원하는 수많은 변경사항과 추가기능들을 설치해 주고 나오는 것을 좋아했다. 이것은 열정

을 가진 조직에 우리가 해줄 수 있는 최고의 답례였다.

- 메리 이야기

프로젝트 모델에서는 각 프로젝트마다 새로운 팀이 할당되기 쉽다. 반면 제품은 그 제품

을 계속 지원하기 위해 같은 팀이 개발에서 유지보수까지 맡는 경우가 많다. 소프트웨어는

같은 팀이 계속 지원하는 것이 더 현명한 방법이다. 왜냐하면, 대부분의 소프트웨어는 오

랜 수명주기 동안 업그레이드와 개선이 이루어지는데, 고객, 코드, 해당 분야에 대한 지식

은 다른 팀에 전달하기가 어렵기 때문이다.

IT 부서와 사업 부서의 협력

“IT 부서의 고객이 외부 고객이라면(When IT’s Customers Are External)”26라는 맥킨지 분기

보고서에서 시몬 맥깁슨Simon MacGibbon과 공동 저자들은, 사업 부서를 상대하는 IT 부서는

별도의 소프트웨어 회사처럼 운영되어야 한다고 제안한다. 그들은 소프트웨어 회사가 내부

IT 부서와 차별되는 3가지 측면을 지적하였다.

26 SimonP.MacGibbon,JeffreyR.Schumacher,RanjitS.Tinaikar,“WhenIT’sCustomersAreExternal,”McKinseyQuarterly,Q1

2006.

71

3_ 가치

1. 소프트웨어 회사는 시장이 원하는 것이 무엇인지를 진정으로 이해하기 위해 리서치

를 수행하기 때문에, 팔리는 제품을 가지고 시장에 나타난다. 이 작업을 소홀히 하

면 그 회사는 오래 살아남지 못한다. 소프트웨어 회사는 시장 조사 결과를 계속 갱

신하고, 시장에 제품을 팔기 위해 더 좋은 방법이 없는지 항상 고민한다. 고객을 시

스템 설계에 참여하도록 요구할 수 없는 상황에서도, 고객이 진정으로 필요로 하는

것이 무엇인지 직접 발굴하기 위해 패널이나 포커스 그룹과 같은 모든 수단을 동원

한다. IT 부서는 다른 누군가가 시장 조사를 했을 것이라 가정하고, 마케팅 단계를

생략했다가 나중에 그들의 제품이 사업 부서의 요구를 만족시키지 못한 것을 깨닫고

놀라기 일쑤다.

2. 시장의 극심한 경쟁 때문에, 소프트웨어 회사는 비용을 항상 적정선에 맞춰야만 한

다. 고객이 소프트웨어를 사지 않을 수 없을 정도로 기능을 구현하면서도, 비용 대

비 효율성을 고려하여 개발과 유지보수를 하기 쉽도록 제품을 충분히 단순하게 설계

한다. IT 부서는 사업 부서의 요구사항 목록에 존재하는 모든 기능들이 빠짐없이 시

스템의 핵심 기능이라고 가정해 버리는 경우가 너무나 많다. 심지어 비용이 아주 많

이 드는 기능을 포함한 경우도 마찬가지다. 소프트웨어 회사들이 살아남기 위해 수

행하는 비용과 이익의 균형을 맞추는 행위를, 자신들도 해야 한다고 생각하는 IT 부

서는 거의 없다.

3. 소프트웨어 회사는 제품을 사용하는 고객이 성공하지 못하면 사업을 지속할 수 없다

는 것을 알기 때문에, 고객이 성공하도록 돕기 위해 모든 방안을 모색한다. 또한 자

사의 제품이 오랫동안 시장에서 성공할 수 있도록 하여, 더욱 안정적인 수익 기반을

창출해 나간다. IT 부서는 그들이 납품하는 시스템에 대한 성공 책임이 사업 부서에

있다고 생각하는 경우가 비일비재하다. 아래 논의에서 살펴볼 수 있듯이, 사업 부서

가 개발을 요청하였기 때문에 소프트웨어 개발 노력의 성공 여부는 사업 부서에 일

차적인 책임이 있다. 하지만 제품이 사업의 성공에 기여하지 못한다면 IT 부서 역시

성공한 것이 아니라는 것도 사실이다.

많은 IT 부서가 소프트웨어 개발에 프로젝트 모델을 사용한다. 그러나 프로젝트 모델은

계약 기반의 산업에서 유래한 것으로, 상호 간의 신뢰가 결여된 경우가 많다. 우리는 건전

한 IT 부서와 사업 부서 간 협력을 이끌어내기 위해서는, 제품 개발 모델이 사용되어야 한

다고 제안한다. 왜냐하면, 제품 개발 모델에 내재된 동기부여가 상호 협조적인 관계를 이

끌어내는데 더 적합하다고 보기 때문이다. IT 부서가 회사 내에 있을 때에는, 프로젝트에

72

Value _3

서 사용하는 갑과 을의 모델을 설정할 이유가 없다. 초기에 프로젝트 범위를 고정시킬 필요

가 없고, 고객으로부터 요구사항 확정 승인을 받을 필요도 없으며, 일정에 따라 세부 사항

을 추적하거나, 고객이 중요하다고 하는 모든 것을 해줄 필요도 없다. 대신에 최대의 영업

가치를 최단 시간 내에 최저 비용으로 제공하기 위해 파트너와 협력하고, 시스템을 효율적

으로 사용하도록 도우며, 시간이 지남에 따라 지속적으로 더 좋은 기능을 더 많이 제공해야

한다.

Story 다른 것들은 실패했어요.

나는 한 컨퍼런스에서 대형 금융지주회사의 CIO와 대화를 나눌 기회가 있었다. 그는 전기공

학 분야에서 오랫동안 일해왔지만 IT 분야를 맡아 문제를 ‘해결’해 달라는 요청을 받았다.

“그것은 3년도 더 된 일입니다. 그리고 당신은 제가 실패했다는 것을 이해해야만 합니다.”

그는 말했다. “CMM과 PMIProject Management Institute에서 하라는 대로 시도해 보았지만 2년

만에 저는 좌절하였고 다시 옛날 업무로 복귀했습니다.”

“그러나 다시 1년 후, 저는 IT 분야를 다시 맡아달라는 요청을 받게 되었습니다. 이번에는

다른 방법을 썼습니다. 저는 IT 조직을 운영과 개발 그룹으로 반씩 나눴습니다. 그리고 개발

그룹을 다시 6개의 제품 개발 팀으로 나눴습니다. 각각의 제품 개발 팀은 사업 부서에 제품

을 팔아야 했고, 각 팀은 비용대비 수익을 얼마나 냈는가로 평가를 받았습니다.”

“겨우 6개월이 지났을 뿐이지만 현재까지는 매우 성공적입니다. 왜 진작 그 생각을 못했는

지 모르겠습니다.”

- 메리 이야기

책임

대기업의 IT 부서는 전통적으로 그들이 지원하는 사업 부서와 별개의 조직으로 운영되어

왔다. 이것은 주로 회사가 일관성 있는 정보기술 인프라를 원했고, 같은 조직에 전문가들이

모여있을 때 전문 기술이 더 쉽게 발전될 것이라고 생각했기 때문이다. 그러나 이러한 조직

운영 방식 때문에, 소프트웨어 개발 활동의 결과에 대한 책임이 누구에게 있는지 명확하지

않았고, 그 결과를 어떻게 평가할 것인지는 더 명확하지 않았다.

73

3_ 가치

책임에 대한 문제는 IT 조직에만 국한된 것은 아니다. 이 문제는, 같은 팀에 있는 사람

들이 서로 다른 성과 평가방법을 가진 상이한 조직을 위해 일할 때 항상 발생한다. 예를 들

어, 임베디드 소프트웨어를 개발하는 조직은 하드웨어 개발 부서와는 별도로 운영될 것이다.

그리고 특정 사업의 컨설팅 회사는 분명히 고객사와는 분리된 관리 구조로 되어 있을 것이다.

조직의 구조에 따라 그 성과를 구분하고, 팀의 한 부서에서 다른 부서로 ‘요구사항’을 전

달하도록 하는 것은 특히 효과적이지 못하다. 이러한 접근은 조인트 벤처의 전체 사업 목표

를 모호하게 만들기 쉽고, 오랫동안 부분 최적화만을 얻게 될 것이다. 그 보다는 완전한 다

기능팀 멤버들이 사업적 성과에 대한 책임을 나누어 갖는 것이 훨씬 더 효과적인데, 여기서

사업적 성과는 그들이 하는 일에 대한 자금 지원을 정당화할 수 있는 수준이어야 한다.

그러나 결국에는 IT 투자의 전체적인 사업적 성과에 대한 단일 책임자가 있어야 한다.

우리는 이러한 책임이 사업적 관점의 자금 지원에 달려있다고 믿는다. 기업의 리더들이 IT

투자를 그들의 사업을 운영하는 것과 똑같이 엄격하게 관리한다면, 이러한 투자는 주목할

만한 사업적 성과를 가져오게 될 것이다.27

시도해 볼 것

1. 가노 모델을 사용하여 현재의 개발 노력을 분석해보라. 상위 수준에서 기능과 역량

의 목록을 만들고 이를 인덱스 카드나 포스트잇에 옮겨 보라. 커다란 종이에 가노

모델을 그려서 벽에 붙여라. 그리고 카드나 노트를 가노 모델의 해당 영역에 붙여

보라. 얼마나 많은 기능들이 ‘매력품질’에 해당하는가? 그 비율은 얼마인가?

2. 10장에서 우리는 고객 만족을 평가하는 좋은 지표인 ‘순추천고객지수NPS’에 대해 기

술할 것이다. 여러분의 고객에 대해 순추천고객지수를 계산해보라. 고객들을 대상

으로 여러분의 제품이나 서비스를 동료들에게 얼마나 추천하고 싶은지를 0~10점

척도로 묻는 간단한 조사를 해보라. 9점이나 10점의 비율은 얼마인가? 이것이 추

천 비율이다. 0~6점의 비율은 얼마인가? 이것이 비추천 비율이다. 추천 비율에서

비추천 비율을 빼 보라. 순추천고객지수가 양수인가 음수인가?

27 DanLohmeyer,SofyaPogreb,ScottRobinson,“Who’sAccountableforIT?”,McKinseyQuarterly,December7,2004.참조.

74

Value _3

3. 현재 진행중인 모든 프로그램이나 프로젝트 리스트를 만들어보라. 각 항목에 대해

역할 별로 현재 리더(들)의 이름을 적어보라. 각 역할 별로 몇 명의 리더가 존재하는

가? 각각에 대해 마케팅과 기술에 대한 리더십을 제공하는 사람을 적었는가? 프로

젝트가 얼마나 잘 수행되고 있는가와 그 마케팅 및 기술의 러더십이 상관 관계가 있

는가?

4. 완전한 팀: 팀 내에 필요한 분야에 대한 지원 인력이 있는가? 신기능을 설계할 때,

기술지원팀에서 누군가가 정기적으로 자문을 해주는가? 테스터들이 처음부터 개발

에 참여하는가? 테크니컬라이터들은 언제부터 참여하는가? 고객 또는 고객 대리인

을 팀의 상근 멤버로 참여시키는가?

5. 프로젝트/제품 모델: 개발 노력에 대한 자금 투자가 점진적으로 이루어지는가 아니

면 한꺼번에 이루어지는가? 개발 노력에 대한 성공 판단 기준은 무엇인가? 팀이 그

대로 유지되는가 아니면 구성원들이 정기적으로 새로운 팀으로 이동하는가? 팀은

그들이 개발한 코드를 그들이 유지보수 하는가? 소프트웨어 개발에 투입된 비용의

사업적 성과에 대한 책임을 누가 지는가?