피터의법칙

훈련기간 : 2009.12.17( 목 )

교육시간 : 14:00~20:00(6H)

강 사 명 : 동부 CNI 이종국 차장

과 정 명 : 리더쉽과 팀 빌딩

1

과정 개요- 소프트웨어 엔지니어들을 위한 리더쉽 향상 방법 소개

과정 목표- 개발 프로젝트의 갈등 양상을 살펴보고 이 갈등 상황을 어떻게 조정해야 하는지 알아봄 .

- 개발팀의 심리를 이해하고 이에 대한 해결책을 살펴봄- 아키텍처와 개발의 각 단계별 관련성을 파악하여 리더가 어떻게 의사결정해야 하는지

살펴봄- 프로젝트의 성공 및 실패 사례를 통해 리더쉽이 어떻게 발휘되는지 살펴봄 .

과정 개요

2

목차

1. 소프트웨어 개발 실패 사례 소개 및 원인 분석

2. 프로젝트 실패의 원인 분석

3. 소프트웨어의 특성

4. 소프트웨어 엔지니어링 리더의 역할

5. 리더쉽 사례 연구

6. 결론

3

1. 소프트웨어 개발 실패 사례 소개

콜롬비아호 폭파 사고

덴버공항 수하물 처리 시스템

체르노빌 원전 폭파 사고

마이크로 소프트 워드 프로젝트

프로젝트 실패의 원인 - 탐욕

4

1.1 통제 불가능한 프로젝트의 사례 - 콜럼비아호 폭파 사고

1993 년 콜롬비아 호는 귀환 중 타일이 떨어져 연료탱크가 구멍이 났으며

폭파하여 승무원 7 명이 전원 사망함 .

1. 프로젝트 실패 사례

5

1.2 통제 불가능한 프로젝트의 사례 - 챌린저호 폭파 사고

1986 년 챌린저호는 이륙 후연료탱크의 가스가 새어나가 폭파함 .

승무원 전원 사망 .


6

1.3 통제 불가능한 프로젝트의 사례 - 체르노빌 폭파 사고

1986 년 엔지니어들의 실수로 체르노빌 원전이 폭파됨 .


7

1.4 통제 불가능한 프로젝트의 사례 - 덴버공항 수하물 센터

수하물 처리 시스템 개발 지연으로 공항 개항이 16 개월 지연되고 비용은 20

억 달러가 초과되었음 덴버시 공무원들이 위험성이 큰 수하물 자동 처리 시스템을 도입하였으나

전문업체의 의견을 무시한 것이 가장 큰 원인이었음


8

1.5 통제 불가능한 프로젝트의 사례 - 영국 히드로 공항

유사한 사례가 영국 히드로 공항에서도 발생함 .


9

1.6 통제 불가능한 프로젝트의 사례 -마이크로 소프트 워드개발 프로젝트

‘ ’ 마이크로 소프트의 윈도우용 워드 첫버전은 대표적인 죽임의 행진

프로젝트 였음 .

예정 일정보다 4 년이 지나서 출시되었으나 결함이 너무 많아서 사용이 불가능했음

오류 데이터베이스가 너무 커서 한 서버에서 관리가 불가능할 정도였음

경영진들이 무리한 욕심을 부려서 출시일자를 짧게 잡은 것이 원인이었음

마이크로 소프트는 이 프로젝트를 교훈 삼아 개발자 한명당 테스터 한명을 투입하는

전통을 만들었음


10

1.7 통제 불가능한 프로젝트의 사례 - 미국 국세청 프로젝트

IRS( 미국 국세청 ) 은 40 년 동안 전산 시스템을 현대화하려는 프로젝트를

세번 실행에 옮겼으나 모두 실패 했음 .

IRS 시스템을 업그레이드하려는 첫 시도는 1970 년대에 지미 카터 대통령에 의해 취소되었음

두번째 업그레이드 시도는 1995 년에 국회에 의해 취소되었음 .

• 이미 10 년의 시간이 흐르고 20 억 달러의 비용을 지출했지만 새로운 시스템이 여전히 작동하지 않았음

세번째 시도도 엄청난 일정 지연과 예산 초과가 이어졌음 .

• 기능 목록의 끊임없는 추가와 변경

• 매년 바뀌는 CIO

• 현실적이지 않은 예산과 일정

현재 IRS 는 1960 년데에 처음 구축되어 언제 다운될지 모르는 메인 프레임 시스템을

사용하고 있음 .


11

1.8 통제 불가능한 프로젝트의 사례미국 항공 교통 제어 시스템 (AAS)

AAS 는 역사상최악의 실패 사례임 .

1981 년에 시작되었으며 1994 년에 종료되었음 .

수십억 달러의 비용의 투입되었지만 아무런 성과가 없었음 .

좌절한 프로젝트 참여자들이 자신들의 차를 부수거나 ,

정신이상에 걸리거나 , 심지어는 자살하는 경우도 있었음 .


12

1.9 프로젝트 실패의 원인 - 탐욕

탐욕은 모든프로젝트 실패의 원인이다 .


13


탐욕은 목표를 상실하게 만든다 .


14


탐욕은냉철한판단력을 흐리게 만든다 .


전쟁이 시급한 데군대 병력이 모자라 . 어찌하면 좋겠는가 ?

전쟁이 시급한 데군대 병력이 모자라 . 어찌하면 좋겠는가 ?

병역 의무가 없는 18 세에서 20 세까지의 젊은이를 징병하면 됩니다 .

병역 의무가 없는 18 세에서 20 세까지의 젊은이를 징병하면 됩니다 .

15


탐욕은냉철한판단력을 흐리게 만든다 .


안됩니다 .안됩니다 .

젊은이라도체구가 건장하면 징병해야 하는것 아닌가 ?

젊은이라도체구가 건장하면 징병해야 하는것 아닌가 ?

못의 물을 말려 고기를 잡으면이듬해에는 물고기를 잡을 수 없습니다 .

못의 물을 말려 고기를 잡으면이듬해에는 물고기를 잡을 수 없습니다 .

젊은이들을 모두 징병하면 부역과 세금은 과연 누가 부담할 수 있습니까 ?백성들의 힘을 한꺼번에 쓰려 해서는 안됩니다 .무릇 정치라 함은 더 먼 곳을 바라봐야 하며절대 눈 앞의 이익만을 따져서는 안됩니다 .

젊은이들을 모두 징병하면 부역과 세금은 과연 누가 부담할 수 있습니까 ?백성들의 힘을 한꺼번에 쓰려 해서는 안됩니다 .무릇 정치라 함은 더 먼 곳을 바라봐야 하며절대 눈 앞의 이익만을 따져서는 안됩니다 .

16


그냥두어라저희는 소경이 되어 소경을 인도하는 자로다 .

만일 소경이 소경을 인도하면둘이 다 구덩이에빠지리라


17

1.10 프로젝트 실패의 원인 - 불안

그러므로내가 너희에게 이르노니 목숨을 위하여 무엇을먹을까무엇을

마실까몸을 위하여 무엇을 입을까염려하지말라 .


18


현실성 없는 상상력

과신 현상

집단 사고

상태 폭발

엔트로피 증가

분류 문제

19

2.1 현실성 없는 상상력

꿈을꿀때사람은 행복하다 . 그러나꿈에서깨면우리는돈을벌기 위해

밖으로 나가야 한다 .


20

2.2 과신 현상

모든사람은 자신을 과대평가한다 .


1. 세계 코코아 생산의 75% 는

어디서 이루어지는가 ?

남아메리카 아프리카

2. 공중 폭격이 처음 시작된 때는 ?

1937 년 1849 년

3. 아도니스는 어떤 신인가 ?

사랑의 신 초목의 신

4. 다음 도시 쌍에서 어느 도시의 인구가 더

많은가 ?

라스베가스 마이애미

시드니 멜번

본 하이델베르크

5. 당신의 답이 옳다는 것을 얼마나 확신합니까 ?

50% 60% 70% 80% 90% 100%

21

2.3 집단 사고

집단은매우 보수적이거나매우 모험적인 방안을선택한다 .


22

2.4 상태 폭발

소프트웨어가 가질수있는 상태는매우 많다 .


23

2.5 엔트로피 증가

소프트웨어는내버려두면무질서 해진다 .


24

2.6 분류 문제

모든업무를빠짐없이 정리할 수있는 분류체계는존재하지 않는다 .


25

3. 소프트웨의 특성

전산 업무의 특성

제조업과 건설업의 특성

소프트웨어 개발와 유사한 직종 - 작가

소프트웨어의 특성

소프트웨어 개발의 이미지

좋은 습관의 중요성

26

3.1 전산업무의 특성

여러분은 소프트웨어 개발이라하면어떤이미지가떠오르는가 ?


27

3.2 제조업과 건설업의 특성

건설업과 제조업의 특성은 무엇인가 ?


28

3.3 소프트웨어 개발와 유사한 직종 - 작가

작가의 부인이 전혀이해할 수 없는 것은

작가가창밖을응시하고있을때작가가 일하고있다는점이다 .


29

3.4 소프트웨어의 특성

소프트웨어 개발이 실패하는 것은흔한 일이다 .

프로젝트규모가클수록 실패할 가능성이 커진다 .

요구사항이 하나증가하면개발 기간은 10 배늘어난다 .( 상태폭팔 )

소프트웨어는 시간이 지나면복잡해지고 수정하기 어려워진다 .( 엔트로피증가 )

소프트웨어 개발 생산성 및품질의핵심은 사람이다 .

지체된프로젝트에 사람을 투입하면프로젝트는 더늦어진다 .

“ 분석의핵심은 사용자가바라는 것 ( 요구사항 ) ”을얼마나잘파악하는가 이다 .

“ ”설계의핵심은 소프트웨어를얼마나잘분류하는가 이다 .

지금까지 알려진 생산성 및품질향상의확실한 해결책은 인스펙션이다 .

소프트웨어재사용이 성공한 사례는 없다 .

소프트웨어 생산성과품질을획기적으로높일 수있는 비법은 아직없으며

앞으로도 없을 것이다 .


30

3.5 소프트웨어 개발의 이미지

제조업과건설업 이미지 소프트웨어는 구축하는 것이다 .(X)

소프트웨어는 공장에서 제품을 생산하는 것과 같다 .(X)

‘ 키움’ 과 ‘돌봄’ 의 이미지 소프트웨어는 농사 짓는 것과 같다 .

소프트웨어는 아기를 키우는 것과 같다 .

소프트웨어는 자라고 성장하는 것이다 .

소프트웨어는 자체적으로 성장한다 .

관리자의 역할은 소프트웨어가 잘 성장하도록 돌보는 것이다 .


31

3.6 소프트웨어 개발에 대한 전통적인 시각과 새로운 시각의 비교


주제 전통적인 개발원칙 새로운 시각

프로세스 미리 정해진 엄격한 프로세스 “ 프로젝트는 탐험이다 !”

요구사항 분석 단계에서 요구사항 확정 “ 프로젝트 완료시점까지 요구사항을 받을 수 있다 .”

테스트 구현 후의 테스트 프로젝트 시작부터 테스트가 진행됨

조직 명령과 복종 자발적인 팀웍 형성

소프트웨어에 대한 견해 실 세계에 대한 모델 언어 게임 , 세계 3 이론

프로젝트 종료기준 요구사항대로 구현되었는가 ? 협상

32

3.7 소프트웨어 개발에 대한 새로운 시각


소프트웨어 개발은 등산하는 것에 비유할 수 있음

제한된 시간에 최대의 성과를 올려야 한다 .

예측 불가능한 상황이 발생한다 .

순간순간 의사결정해야 한다 .

팀원의 단결력이 매우 중요하다 .

정해진 milestone은 있으나 ,

나머지는 팀원들이 자유롭게 결정한다 .

33

3.6 좋은 습관의 중요성

기술과툴보다는 사람을 중요시 여기는태도

소프트웨어 시스템의 비전에 대해 고객과 개발자 사이의잦은 대화

일을 미루지 않는태도

욕심을 버리고포기할줄아는 자세

후임자를 생각하며 자신의 명예와 자존심을 위해 시스템을 개발하는 마음가짐

최종 결과는매일의 수고로얻어지는 것임을 아는 마음가짐

모든문제의 시작과 해결책은 프로젝트 현장에있음을 아는 자세

동료를 위해손해보고헌신하려는 자세

관료적인태도를 버리고 무시할줄아는 리더의 자세

신기술을 의심하고 가장잘알려진 해결책을 사용하려는 자세


좋은 습관을 체계화하여 조직에 적용하는 가이드라인이방법론임

34

4. 아키텍처 리더의 역할

프로젝트의 현실

아키텍처의 역할

아키텍처 구성 요소

개발 단계와 아키텍처의 관계

아키텍처 설계 절차

아키텍처 리더의 역할

35

4.1 프로젝트의 현실

프로젝트에서 결정해야 할 기술들이 너무 많다 .


개발툴은 ?

시스템의 보안은 ?

어플리케이션

서버는 ?외부

시스템과의 연동은 ?

UI 는 ?

데이터베이스와의

연결방식은 ?

36


프로젝트에서는선택한 기술들이나 제품의 문제점은

프로젝트 중반에 발견한다 .

이미 개발이 진행중이므로 돌이키기 어렵다 .


개발툴과 케이스툴이 연동되지 않는다 .

개발툴과 형상관리 툴을

연동되지 않는다 .

성능이 너무 낮다 .

레포팅이 않된다 .

선택한 UI 기술때문에어플리케이션 서버 기술 사용에 제약을

받는다 .

37


기술적인 문제에 대해 리더쉽을 발휘하는 사람이 없다 .

많은 회의를 하지만 결정은 내려지지 않고 의사결정은 지연된다 .


성능을 개선할

방법은 ?

괜히 나서서

책임지기 싫다 .

그건 제품 공급업체가 책임져야된

다 .

나는 결정되면 따르겠다 .나도

아이디어가 있지만잘못된

생각이면 비난받을거

다 .38


프로젝트의 일반적인 경향 기술에 대한 비합리적인 의사결정

과거의 경험 답습

프로젝트 실패 원인에 대한 연구 부족

국내프로젝트 경향 무조건적인 신기술 도입

프로젝트 복잡성에 대한 관리 및 통제의 부족

프로젝트 마지막에 리스 발견


프로젝트 실패 !

39

4.5 아키텍처의 역할


비합리적인 결정비합리적인 결정

과거의 경험 답습과거의 경험 답습

과거의 사례에서배우지 못함

과거의 사례에서배우지 못함

프로젝트의 복잡성을

관리하지 못함

프로젝트의 복잡성을

관리하지 못함

프로젝트의 마무리 시점에서

문제점 발생

프로젝트의 마무리 시점에서

문제점 발생

설계자가 제 역할을 하지 못함

설계자가 제 역할을 하지 못함

아키텍처와품질 평가에기초한 결정

아키텍처와품질 평가에기초한 결정

아키텍처를 통한경험 축적

아키텍처를 통한경험 축적

아키텍처를 통한복잡성 관리

아키텍처를 통한복잡성 관리

아키텍처를 통해초기에 문제 해결아키텍처를 통해초기에 문제 해결

아키텍처를 통한설계 가이드라인아키텍처를 통한설계 가이드라인

40

4.6 아키텍처의 정의

소프트웨어 아키텍처는 구현할 시스템에 대한 Top-down view 이다 .

시스템에 대한 기술적인 명세서이다 .

공학적인 청사진이다 .


41

4.7 아키텍처 구성 요소


Software ArchitectureSoftware Architecture

가이드라인과 정책가이드라인과 정책

Module View

Module View

Component&Connector ViewComponent&

Connector ViewAllocation

ViewAllocation

View

Context DiagramContext Diagram InterfaceInterface

설계 가이드라인

설계 가이드라인

코딩

가이드라인

코딩

가이드라인

배포

가이드라인

배포

가이드라인

테스트

가이드라인

테스트

가이드라인

통합

가이드라인

통합

가이드라인

Meta-ArchitectureMeta-Architecture

아키텍처

정의

아키텍처

정의

스타일

아키텍처

스타일

아키텍처

설계 패턴

설계 패턴

의사결정

트리

의사결정

트리

ComponentComponent

역할

아키텍트의

역할

아키텍트의

프로젝트 조직 프로젝트 조직

Framework 사용 및 customization 계획Framework 사용 및 customization 계획

템플릿

아키텍처

템플릿

아키텍처

프로젝트 스케줄프로젝트 스케줄

Prototype Prototype

Utility Program Utility Program

시스템

확장

정책

시스템

확장

정책

유지보수

정책

유지보수

정책

운영

정책

운영

정책

형상 관리 계획형상 관리 계획

툴

가이드라인

툴

가이드라인

CodeViewCodeView

42

4.8 개발 단계와 아키텍처의 관계


Software ArchitectureSoftware ArchitectureHardware

Specification& Configuration

Hardware Specification& Configuration

참조

설계설계

코드코드

시스템시스템

기능적, 비기능적 요구사항기능적, 비기능적 요구사항

분석분석

코드 가이드라인, 원칙, 배포가이드라인,Deployment Architecture

설계 패턴, 설계 가이드라인, 원칙

설계 문서

컴포넌트

요구사항 문서

분석 문서

기능적 요구사항

43

4.9 아키텍처 팀의 역할


프로젝트 관리 팀

아키텍처 팀 분석 /설계팀 개발팀 지원팀

프로젝트 착수 단계


아키텍처 팀분석 /설계팀 개발팀 지원팀

개발 단계


아키텍처 팀

분석 /설계팀 개발팀

지원팀

인수 단계


아키텍처 팀 분석 /설계팀 개발팀지원팀

프로젝트 시작 단계

44

4.10 아키텍처와 개발의 관계


최종 완제품 구축최종 완제품 구축

반복적 소프트웨어 아키텍처 개발

반복적 제품 구현반복적 제품 구현

반복 개발반복 개발

고객의 개선 사항고객의 개선 사항

소프트웨어 아키텍처 개발소프트웨어 아키텍처 개발

마케팅 팀개선 사항마케팅 팀개선 사항

기술적인개선 사항기술적인개선 사항

요구사항 선별요구사항 선별

요구사항정의서 ( 부분 )요구사항정의서 ( 부분 )

아키텍처 초안 작성아키텍처 초안 작성 아키텍처아키텍처 아키텍처 평가아키텍처 평가

아키텍처 상세화아키텍처 상세화설계 가이드라인설계 가이드라인

외부 제품 리스트외부 제품 리스트

분석 /설계분석 /설계 구현구현 테스트테스트 제품 ( 부분 )제품 ( 부분 ) 제품 완성 여부 판단제품 완성 여부 판단

컴포넌트 /제품 배치컴포넌트 /제품 배치

최종 완제품최종 완제품제품 사용

아니요

예

요구사항 정의요구사항 정의

의사 결정 트리의사 결정 트리

예아니요

아키텍처 수정여부아키텍처 수정여부아니요

예

45

4.11 아키텍처와 요구사항의 관계


업무개선사항

제품의특성기능적인

특성

요구사항

품질특성

시스템특성

업무특성

Use Case모델

품질프로파일 업무규칙

성능보안

신뢰

성

하드

웨어

네트

워크

UI시

스템

구성

업무규칙

업무

표준

시스템제약사항

시스

템표준

46

4.12 체계적인 의사결정


의사결정 트리를 이용하여 기술 선택의사결정 트리를 이용하여 기술 선택 아키텍처 설계에 반영아키텍처 설계에 반영 아키텍처 평가 및

테스트아키텍처 평가 및 테스트

Distribution

Concurrency

쐑콪

Presentation

Business Process

Business Entity

Security

Exception Handling

Logging

Monitoring

Network

Clustering

Database

좯캬첕쮱칩쟕좭죃

컋큉 퀉쨥썯�

Decision Factor2004-08-25 - v7

Remote Facade

Data Tranfer Object

Optimistic Lock

Pessimistic Lock

Coarse-Grained Lock

Implicit Lock

Gateway

Mapper

Layer Supertype

Separated Interface

Registry

Value Object

Money

Special Case

Plugin

Service Stub

Record Set

Representation

Model View Controller

Page Controller

Front Controller

Template View

Transform View

Two Step View

Application Controller

State Management

Client Session

Server Session

Database Session

Service LayerDomain facade

Operation script

Object TypeStateful

Stateless

Data Access

Plan Java ObjectOR Mapping

Table Data Gateway

Row Data Gateway

Data Mapper

Active Record

Behavioral Patterns

Unit Of Work

Identity Map

Lazy Load

Structural Patterns

Indentity Field

Foreign Key Mapping

Association Table Mapping

Dependent Mapping

Embedded Value

Serialized LOB

Single Table Inheritance

Class Table Inheritance

Concrete Table Inheritance

Inheriantance Mappers

Metadata Mapping Patterns

Metadata Mapping

Query Object

Repository

OR Mapping Tool

Entity Bean+CMP

Entity Bean+BMP

Representation

Table Module

Domain Model

Transcraction Script

TransactionDB Transaction

WAS Transaction

Validataion Check

Data Caching

Isolation

Synchronous

Stored Procedure 찔쥁��

� ��쨠 쐑촺

Validataion Check

컋큉 퀉쫛줧�

Bottom-up

Top-down

Hybrid

선택한 기술에 대한 설계 및 코딩 가이드라인 작성

프로토타입 구현과메트릭 선택 , 측정성능 모델을 통한 평가

47

4.13 아키텍처 설계 절차


기능중심의아키텍처설계

아키텍처

아키텍처평가

Use Case 모델

품질프로파일

업무규칙

시스템제약사항

아키텍처전이

설계가이드라인

외부제품리스트

Not OK

OK

요구사항수정

48

4.14 아키텍처 평가

시나리오 기반의평가 방법

프로토타입을 통한평가 방법

성능 테스트 및평가 방법


테스트를 통해 아키텍처를 평가함

49

4.14 아키텍처에서 개발로의 이행

설계 패턴정의Presentation 로직 패턴 정의

Business 로직 패턴 정의

OR 매핑 패턴 정의

상세설계 산출물 정의UI 설계 산출물 정의

서버 설계 산출물 정의

DB 설계 산출물 정의


50

4.15 아키텍처 리더의 역할

아키텍트는 테크니칼리더이다 .

아키텍트는 개발자들에게컨설턴트이자 교사로서의 역할을 수행한다 .

아키텍트는 프로젝트 관리자를 지원한다 .

아키텍트는설계자 , 개발자 , 테스터와 함께아키텍처 팀을 구성한다 .


51


프로젝트에 영향을 미치는 요소

고객사와 개발사의 관계

개발사의 조직 구조

프로젝트 팀과 본사의 충돌 사례

프로젝트 팀이 원하는 사람과 본사가 원하는 사람의 차이

관리자와 개발자의 신뢰

52

5.1 프로젝트에 영향을 미치는 요소는 극히 다양함

개발팀이 일하는건물의 위치도 영향을 미침 프로젝트는 건물의 한 층을 임대했는데 그곳은 고객사에 가까운 곳이었다 .

그런데 그 건물에는 우리만 프로젝트를 수행한 것이 아니고

다른 층에는 고객사의 다른 프로젝트를 다른 회사에서 수행하고 있었다 .

우리가 속했던 회사는 그회사와 교류가 없었다 .

그러나 프로젝트 관리자가 모르는 것이 하나 있었는데 개발팀은 프리랜서들이

대부분이었고

프리랜서들은 고객사와 일을 많이 해서 소속은 달랐지만 서로 잘 알고 있었다 .

그래서 건물 일층에서 담배를 피울때는 개발자들끼리 프로젝트에 대한 정보를 서로

교환하고 있었고 개발자들은 서로의 프로젝트 상황 , 고객사의 동향 정보를 잘 알고

있었다 .

따라서 한 프로젝트가 심각한 상황에 처하고 고객사에서 화를 내면 그 정보가 우리

프로젝트에 전해졌다 .


53

5.1 프로젝트에 영향을 미치는 요소는 극히 다양함

개발팀이 일하는건물의 위치도 영향을 미침 그때는 고객사가 개발팀을 심하게 압박하는 분위기였고 두 프로젝트 모두 심각한

상황이었다 .

그런 상황에서 프리랜서인 개발자들의 이탈이 계속되었다 .

두 프로젝트의 개발자들이 동조하여 더 좋은 프로젝트로 옮긴 것이다 .

본사에서는 이런 상황을 이해하지 못하고 관리자들의 무능을 탓했다 .


54

5.2 고객사와 개발사의 관계

고객사의 정치적인 관심사때문에 개발이 상당히 지연될수있음

프로젝트를 시작하면 거의 한달은 수행 계획서와 워크샵 준비로 시간을 쏟았다 .

수행 계획서나 워크샵의 내용은 제안 단계와 달라진 것이 없었다 .

고객사에서는 어떤 호텔에서 어떤 일정으로 워크샵을 진행하느냐 , 어떻게 현장

직원들의 불만을 차단시킬 멋진 것을 보여주느냐에 더 관심이 많았다 .

실제적인 일은 이렇게 요란한 행사가 끝난후 즉 프로젝트 시작 한달후에나 시작된다고

보면 된다 .

대개 프로젝트가 클수록 이런 행사는 더 자주 있게 된다 .

그리고 주간 보고가 있다 . 주간 보고는 그렇듯한 계획과 실적을 보여주기 위해 진행되며

주간보고를 고객과 진행하기 사흘이나 심지어 일주일 전부터 작성된다 .

좀 심하게 표현하면 프로젝트 내내 고객사의 경영진을 만족시킬 보고서를 작성하는데

시간을 보낸다고 보면 된다 .


55

5.3 개발사의 조직 구조

개발자가속한 조직도 프로젝트의 성공보다는 정치적인 것에 관심이있음 나는 여러 해 전에 내가 속해있던 회사에서 테스트조직을 새로 만든다는 소식을 들었다 .

테스트는 개발 프로세스 상 마지막에 속하는 것이고 개발 작업 중에서 가장 어려운

작업이다 .

따라서 테스트 조직은 개발팀에게 상당히 간섭과 통제를 받아야 했다 .

그런데 테스트 조직이 만들어진 후 이상한 일이 발생했다 .

테스트 팀이 직접 테스트는 하지만 테스트 결과는 PM 을 거치지 않고 본사에 직접

보고된다는 것이다 .

테스트팀의 테스트 결과가 본사에 보고되자 본사의 경영진은 시스템에 오류가 많은 것에

대해 PM 을 질책했다 .

테스트가 프로젝트 팀을 통제하는 도구로 변질된 것이다 .

그 이후에는 개발팀에서 테스트팀이 간여하는 것을 차단했고 테스트 팀은 결국

해체되었다 .


56


개발 프로젝트와 경영진은 보통 의사소통이 단절되어있음 . PM 이 경영진과의 의사소통을 포기하면 어떤 일이 발생하는가 ?

PM 은 거짓보고를 계속 보낼 것이다 .

PM 이 감당할 수 없는 상황까지 거짓보고는 계속될 것이다 .

같은 상황이 고객사의 담당자에게도 발생한다 .

고객사 담당자도 동일하게 경영진과 의사 소통 단절을 경험하게 되고 거짓 보고를 용인하게

된다 .

그래서 실패한 프로젝트 중 많은 프로젝트들이 프로젝트 막판까지 희망 섞인 보고를

보내다가 무너지게 되는 것이다 .

그리고 이런 상황때문에 전사적인 프로젝트 관리 시스템이 프로젝트에 도움이 되지 않는

것이다 .


57


개발 프로젝트와 경영진은 보통 의사소통이 단절되어있음 . 어짜피 입력자가 거짓 데이터를 PMS 에 입력하는 것을 부끄러워하지 않는다 .

CMMi 나 개발 방법론 , 기타 프로젝트 관리 체계도 도움이 되지 않는다 .

PM 이 본사의 경영진을 불신하게 되면 모든 프로젝트 만회 대책이 무용지물이 된다 .


58

5.4 프로젝트 팀과 본사의 충돌 사례

개발 프로젝트는 문제 해결에 ,

본사는 장기적인 관점의 비지니스에 관심이있음 프로젝트 팀은 고객의 지시에 따라 프레임워크에 대한 BMT 를 실시하였다 .

다양한 프레웜워크 개발사를 초청하여 전문가를 불러 평가를 실시했다 .

프로젝트 팀의 고민은 본사에서 개발한 프레임워크를 포함시킬 것인가 말것인가하는

것이었다 .

본사에서 개발한 프레임워크는 외부에서 만든 것에 비하면 기능이 상당히 떨어졌다 .

프로젝트 팀은 고객과의 좋은 관계를 유지하는것에 관심이 있었다 .

그런데 BMT 에 본사 프레임워크가 포함되어 떨어지면 고객의 비웃음을 살 것이고 고객이

프로젝트 수행 능력까지도 의심할것이 두려웠다 .

따라서 어짜피 본사 프레임워크가 선정되지도 않을 것이니 본사 프레임워크는 BMT 에

포함시키지 않기로 결정했다 .

그러나 본사의 입장은 달랐다 .


59

5.4 프로젝트 팀과 본사의 충돌 사례

개발 프로젝트는 문제 해결에 ,

본사는 장기적인 관점의 비지니스에 관심이있음

이번 기회에 어떤 방법을 쓰든 고객사에 본사 프레임워크를 납품시키고 ( 본사 지원팀에서

만든 것이지 개발팀은 그 프레임워크에 관심이 없었다는 것을 생각하라 ) 싶었다 .

개발팀은 이런 요구사항을 거절했다 . 본사의 압력보다는 고객이 더 두려웠기 때문이다 .

끝내 본사 프레임워크는 포함되지 않았으나 BMT 가 끝난후 본사 지원팀과 개발팀 사이는

더 나빠졌다 .


60

5.5 조직이 원하는 사람과 프로젝트에서 원하는 사람의 차이

조직의 중간 관리자는 대개 명령에 가장 잘 순응하는 사람을 택하게 된다 .

그러나 프로젝트 팀은 조직에 순응하는 사람이 아닌 프로젝트에서 발생하는 문제를 가장

빨리 , 아니면 가장 적은 비용으로 해결하는 사람이다 .

따라서 이런 프로젝트 팀장을 관리하는 관리자와 프로젝트 팀장 사이에는 갈등이 생기게

마련이다 .

관리자는 조직이 유형 , 무형으로 지시한 명령에 순응하려 한다 .

그러나 프로젝트 팀장에게는 문제 해결이 우선이기 때문에 이런 조직의 명령을 무시할 수

밖에 없다 .

따라서 프로젝트 팀장이 프로젝트를 잘 해결했다고 해도 조직에서 이사람을 승진시키지는

못할 것이다 .

조직에서 원하는 것은 명령에 순응하는 사람이기 때문이다 .


61

5.5 조직이 원하는 사람과 프로젝트에서 원하는 사람의 차이

또한 고객의 조직을 봐도 문제를 해결하는 사람보다는 명령에 순응하는 사람이 더 많기

때문에 프로젝트 팀장은 어려움을 겪게 마련이다 .

많은 고객이 문제를 회피하는 것처럼 보이는 것은 회피하는 것이 아니라 명령이 떨어지지

않았기 때문이다 .

이 사람들은 명령이 떨어지지 않은 한 어떠한 행동도 취하려고 하지 않기 때문이다 .


62

5.6 개발 팀의 핵심 멤버는 누구인가 ?

PL 이핵심멤버가 아님 나는 6 개월동안의 분석단계 프로젝트에 품질관리자로 참여하였다 .

내가 하는 일은 단순히 분석 산출물의 틀만 만들고 평가만 해주면 되었다 .

참여자는 세 그룹으로 나누어졌는데 퇴역군인들도 있었고 젋은 개발자들도 있었다 .

두팀에 퇴역군인들과 개발자들이 골고루 포진했다 .

프로젝트가 시작되고 보름 정도 지나자 상황이 바뀌었다 .

퇴역군인들가 개발자들은 서로 대화가 되지 않았다 .

서로 일해온 배경이 달랐기 때문이다 . 퇴역군인들은 개발자들에게 군대에서 하듯이 명령을

내리려고 했지만 말을 듣지 않았다 .

개발자들도 나름대로 자존심이 있었기 때문이다 .

퇴역군인들은 설계상의 문제를 곧 나에게 가지고와 판단을 구했고 나는 나름대로

성심성의껏 도와주었다 .


63


PL 이핵심멤버가 아님 시간이 지나자 퇴역군인들은 나를 중심으로 작업을 진행했다 .

PL 이 있었지만 PL 이 퇴역군인들보다 나이가 어리고 계급도 낮았기 때문에 작업

지시후에는 곧 나와 함께 작업 방향을 결정했고 문제가 발생하면 내가 PL 와 상의하게

되었다 .

이렇듯 나는 품질관리자로서 공식적으로 지시를 내릴 위치는 아니였지만 비공식적으로는

내가 퇴역군인들의 조정자가 된 것이다 .


64


핵심멤버를 추방하여 팀이 와해된사례 이 프로젝트에서는 공식적인 PL 대신 핵심멤버가 프로젝트를 조정하였다 .

이것이 너무 심해서 PL 을 제외하고 핵심멤버를 중심으로 담배도 피우고 식사도 했다 .

그러나 PM 은 이 핵심멤버의 역할을 전혀 인정하지 않았다 .

이 사람은 업무도 잘 알뿐 아니라 개발자들의 상담자 역할도 담당했다 .

핵심멤버가 PL 과 의견 충돌이 잦아지자 PM 은 이 개발자를 프로젝트에서 추방하기로

결정했다 .

핵심멤버가 떠나자 프로젝트 팀원들도 프로젝트를 모두 떠났다 .

PM 은 핵심멤버가 어떤 역할을 하고 있었는지 전혀 알지 못했다 .


65

5.7 역할 떠넘기기

역할떠넘기기로 인해 프로젝트가 지연된사례 프로젝트 팀에서 기술적인 문제가 발생하여 회의에 참석한 경우이다 .

회의는 3 시간이 넘게 진행되었으나 기술적인 문제에 대해 서로 변명밖에 하지 않았다 .

개발팀은 협력업체에게 공을 넘기고 협력업체는 개발팀에게 공을 넘겼다 . 개발팀은 PL

들끼리 공을 넘겼다 .

심지어 PM 도 최종 결정을 해야할 시점에서 책임을 회피하고 아무것도 결정하지 않았다 .

회의가 끝난후 나는 늘 이런식으로 결론없이 회의가 끝나냐고 물어보았다 .

PL 들이 그렇다고 했다 . PM 이 결론을 내지 않아서 회의가 흐지부지 되는 일이 많았다 .

그 프로젝트는 회의를 할 당시 3 주이상 지연되었으나 이런 스타일로 일하면 더 지연될

가능성이 있었다 .

나는 할 수 없이 지원팀에서 3 주동안 인력을 빼서 프로젝트 팀에 공짜로 투입하여 문제를

해결했다 .


66

5.8 리더의 역할

리더는축구감독과같다 .

프로젝트 관리자가 자신을 명령을 내리는 사람으로서의 이미지를 가지고 있다는 것이다 .

나는 관리자들에게는 축구선수들을 지도하는 코치나 감독으로서의 이미지를 가지고

개발팀을 대하기를 권유한다 .

축구 선수들에게 명령을 내리는 코치의 입장과 군대의 지휘관의 입장은 다르다 .

지휘관은 임무를 지시하고 임무가 달성되지 못하면 벌을 내린다 . 그러나 코치는 선수들이

성장하고 자신의 문제점을 고치도록 지도한다 .

또한 팀웍에 문제가 있는 사람을 역할을 바꾼다 .

물론 코치도 선수의 포지션을 바꿀 수 있는 강력한 권력을 가지고 있지만 이 권력을

선수들이 경기를 잘 치룰 수 있도록 훈련하고 환경을 조성하는데 사용한다 .

프로젝트 관리자는 코치와 같은 입장이다 . 선수들이 경기를 잘할 수 있도록 선수를

성장시키고 가장 알맞은 역할을 주는 것이다 . 그리고 선수들 사이의 팀웍이 생기도록

지도한다 .


67

5.9 팀웍이 강한 사례 1

초기 우주 추적 시스템을 만들던 빌의 경우를 보자 .

그의 업무는 전 세계에 퍼져 있는 추적국의 전체 네트워크와 실시간 데이터 입력을 위한

시뮬레이터를 개발하는 일이었는데 , 전 세계 네트워크에 연결하지 않고 전체 시스템을

실시간으로 점검하려는 것이었다 .

그 시뮬레이터의 핵심 코드는 딱 13 개의 기계 명령어로 구성된 매우 작고 함축적인

루프였다 . 빌은 그 루프 코드 작성에 매진하다가 마침내 어느 정도 자신이 생겼을 때 ,

자신의 작업을 비판해 줄 동료를 찾아 나섰다 .( 이는 그의 프로그래밍 그룹에서 표준

절차였다 .)

빌은 매럴린에게 부탁했고 , 그녀는 거꾸로 빌이 나중에 자신의 코드를 호의적으로 검토해

줄 것이라 기대하며 기꺼이 응했다 .

이런 거래는 그 그룹에서 통상적인 일이었다 .

사실 다른 사람을 통한 코드 검토가 꼭 필요한 일임은 모두 인정했지만 왠지 비난을 받는

기분이었는데 , 거래를 하면 비난 받는 느낌 없이 코드를 검토 받을 수 있었다 .


68


그러나 제대로 훈련 받은 프로그래머인 빌에게는 그런 거래의 보호가 필요하지 않았다 .

그의 프로그래밍 가치 체계에서 비밀스럽고 독점적인 프로그래밍은 나쁜 축에 속했고

공개적이고 공유된 프로그래밍이 좋은 축이었다 .

그가 작성한 코드 ( 그의 코드가 아니다 . 그곳에서는 그런 표현을 사용하지 않았다 .) 에서

남이 오류를 찾는 것은 그에 대한 개인적인 공격이 아니라 코드를 개선하기 위함이었다 .

그때가 마침 빌의 컨디션이 과히 좋지 못해 프로그래밍이 잘 안되는 시기였던 듯 , 매럴린은

빌의 코드에서 버그를 하나둘 씩 찾아내기 시작했다 .

그러나 빌은 보통의 프로그래머처럼 방어하는 자세를 취하는 대신에 많은 버그가

발견될수록 더 즐거워했다 .

마침내 그는 회의 사간에 매럴린이 겨우 13줄짜리 코드에서 버그를 17 개나 찾아냈다는

놀라운 사실을 떳떳이 밝혔다 .


69

5.9 팀웍이 강한 사례 1 그리고 어떻게 그런 일이 있을 수 있는지 모든 사람에게 알려야겠다고 생각했다 .

그래서 오늘은 내가 코딩이 잘 안되는 날이라며 자기의 짧은 코드에서 그렇게 많은 버그가

발견되었다는 얘기를 되풀이 해 자세하게 떠들고 다니는 것으로 그날의 남은 업무 시간을

보냈다 .

한편 매럴린은 그 상황에서도 자만하지 않았다 .

버그가 17 개나 있다면 다른 버그가 또 있을 지도 모르겠다고 생각했다 .( 그녀의 판단은

옳았다 .).

그러나 빌의 코드를 검토한지 얼마간의 시간이 지나자 그녀는 원작자인 빌만큼이나 그

코드에 익숙해져 버렸음을 깨달았다 .

그래서 그녀는 또 다른 동료에게 코드 검토를 부탁했다 .

그리고 빌이 다른 동료들에게 웃음을 선사하고 있는 동안 매럴린을 비록ㅎ산 몇몇은 퇴근

시간 전까지 버그를 3 개 더 찾아냈다 .

그 시뮬레이터는 십여 곳에서 설치해 사용되었고 이후 9 년 동안 아무도 새로운 오류를

발견하지 못했다 .


70


한편 매럴린은 그 상황에서도 자만하지 않았다 .

버그가 17 개나 있다면 다른 버그가 또 있을 지도 모르겠다고 생각했다 .( 그녀의 판단은

옳았다 .).

그러나 빌의 코드를 검토한지 얼마간의 시간이 지나자 그녀는 원작자인 빌만큼이나 그

코드에 익숙해져 버렸음을 깨달았다 .

그래서 그녀는 또 다른 동료에게 코드 검토를 부탁했다 .

그리고 빌이 다른 동료들에게 웃음을 선사하고 있는 동안 매럴린을 비록ㅎ산 몇몇은 퇴근

시간 전까지 버그를 3 개 더 찾아냈다 .

그 시뮬레이터는 십여 곳에서 설치해 사용되었고 이후 9 년 동안 아무도 새로운 오류를

발견하지 못했다 .


71


한 컴퓨터 제조회사의 소프트웨어 부서에서 발생한 일이다 .

그 부서 내의 한 그룹이 엄청난 시장 잠재력을 지닌 완전히 새로운 시스템을 개발하는 데

대성공을 거두었다 .

그 성과가 너무 뛰어났기 때문에 경영진은 현금으로 보너스를 지급하기로 결정했는데 ,

누가 경영진 아니랄까 봐 그룹에서 대표격인 사람 한 명에게만 주려했다 .

그런데 그 사람은 모든 사람에게 보너스가 지급되는 게 아니면 자기도 받을 수 없다고

고집했다 .

그의 반응은 그룹 전체가 함께 일궈낸 성과라는 점에서 매우 옳았다 .

그러나 경영진은 그런 사고방식을 이해할 수 없었다 .

경영진 중에는 그가 돈을 더 받으려고 수를 쓰고 있거나 자신의 그룹을 프리마돈나로

만들려는 속셈이라고 생각하는 사람도 있었다 .


72


어쨌든 대표인에게 강제로 보너스를 주고 그룹을 해체하기로 최종 결론을 내렸다 .

그러나 결과는 경영진의 뜻대로 되지는 않았다 .

대표로 뽑힌 사람은 보너스를 받자마자 그룹의 모든 구성원에게 균등하게 분배했고 ,

나중에는 그룹이 통째로 다른 회사로 옮겨가 버렸던 것이다 .


73


프로그래머 열 명으로 구성된 그룹이 대형 항공기 제조사의 프로그래밍 부서에서 일하게

됐다 .

그들은 다른 회사에서 2 년 동안 함께 일한 사이였다 .

그 회사가 갑자기 모든 전산 관련 인력을 나라 반대편으로 배치하기로 결정했는데 ,

이사하기가 싫었던 그들은 모두 함께 다른 회사로 옮겼다 .

각자 여러 회사로부터 매력적인 영입 제안이 있었음에도 불구하고 , 열명을 모두 한꺼번에

고용할 회사를 선택한 것이다 .

이런 식으로 그룹이 통째로 자리를 옮기는 경우는 희귀한 일이 아니다 .

경영진은 그런 사람들을 모종의 음모 세력으로 보는 경향이 있지만 , 사실 그들이 원하는

바는 커다란 물질적 이득이 아니다 . 함께 일함으로써 얻는 성취감을 계속 맛보려는 것일

뿐이다 .


74


이 그룹이 항공기 회사로 옮긴지 몇 개월이 지났을 무렵 , 그룹의 관리자가 한 컴퓨터

컨퍼런스에서 전 회사에서 그룹을 관리했던 사람을 우연히 만나게 되었다 .

현관리자는 그 그룹 같은 사람들이 또 있는지 물었다 .

옛 관리자가 그 그룹뿐이었다고 답하자 그는 그런 사람들을 모을 수 있었던 비결을

알려달라고 했다 .

그러나 옛 관리자는 아무런 특별한 점도 생각나지 않았다 .

이탈리아어를 전공하고 대학을 갓 졸업한 사람 . 7 년 동안 고등학교 수학 교사였던 사람 ,

직업 기술자였던 사람 , 경영 대학원을 졸업하고 몇 년 동안 임원 비서와 경리로 일했던

사람 , 별로 특별할 것이 없었다 .

옛 관리자는 그가 왜 그런 비결을 묻는지 궁금했다 .


75


그렇지만 옛 관리자는 솔직하게 대답했다 .

“ 비결 같은 것은 잘 모르겠네요 .

단지 , 그 사람들이 제 밑에 온 이후로 꼭 정해진 시간 안에 제대로 처리해야 할 업무가

있으면 그들 중 한 명에게 줬습니다 .

프로그래머라면 300 명이나 더 있었지만 , 믿음직스러운 이는 그들뿐이었죠 .

모두 천재인 것 같아요 .” 그런 인식은 자신이 보려는 것에만 치중한 결과였다 .

그룹 중 한 명에게 업무를 주었을 때에도 그룹 전체가 협동해서 처리한다는 사실을 이해하지

못했던 것이다 .

그 그룹이 그에게 자신들의 방식을 설명하려 해봤지만 , 그는 몇몇만이 일을 했다는 사실은

숨긴 채 일을 안 한 구성원들도 보듬으려는 의도라고 이해할 뿐이었다 .


76

5.12 관리자와 개발자의 신뢰 1

제 첫 직장은 마이크로소프트 사였는데 , 거기서 가장 처음으로 맡은 업무가 새 언어인 엑셀

매크로에 대한 전략 구상이었습니다 .

바로 작업에 들어가 엑셀 베이직 명세서 초안을 작성했습니다 .

그런데 ‘응용 아키텍처’라는 모종의 그룹이 제 명세서 소문을 듣고는 바짝 긴장을

했다더군요 .

무슨 이유에선지 모르겠지만 , 그 그룹은 자기네가 매크로 언어 전략 수립 같은 일을

주도해야 한다고 생각하고 있었습니다 .

곧 저에게 명세서를 보여달라는 요청이 들어왔습니다 .

저는 응용 아키텍처 그룹이 무엇인지 여기저기 물어 보았습니다만 , 그 그룹을 심각하게

받아들이는 사람은 없는 듯 했습니다 .

알고 보니 , 최근 고용한 박사학위 소지자 네 명으로 이뤄진 그룹이더군요 .

저는 요청대로 명세서를 보내고 그룹을 만나러 갔습니다 . 무언가 도움이 될만한 의견이

있을지도 모른다고 생각했죠 .


77


“ 이러쿵 저러쿵 !” 한 사람이 말했습니다 .

“ 어쩌구 저쩌구 , 어쩌구 저쩌구 !” 또 한 사람이 덧붙였습니다 .

제가 보기에는 별로 대단한 의견이 없었습니다 .

프로그래머 팀은 구현을 계속할 수 있도록 저에게 작업한 내용을 더 내놓으라고 매일

난리였습니다 .

그런데 그때 저를 진짜 놀라게 한 사건이 발생했습니다 .

레드몬드 햇살 아래서 몇몇 동료와 점심을 먹고 있는데 , 피트 히긴스가 말을 걸더군요 .

당시 그는 마이크로소프트 오피스 소프트웨어 부문장이었는데 , 물론 저는 그가 누군지

알지만 그가 저를 일리라고는 생각하지 못했습니다 .

“ 조엘씨 , 일하기가 어때요 ?”라고 묻더군요 . “응용 아키텍처 그룹과 문제가 있다는

이야기를 들었는데 ..”


78


“ 아 , 아닙니다 .” 저는 대답했습니다 . “ 제 선에서 해결할 수 있습니다 ..”

“ 그렇군요 .” 그가 말했습니다 . “ 알겠습니다 .”

그렇게 말하고는 자리를 뜨더군요 .

바로 다음날 , 응용 아키텍처 그룹을 해산한다는 소문이 제 귀에 들어 왔습니다 .

뿐만 아니라 , 그룹원 모두를 서로 다른 부서로 배치해 버린다고 하더군요 .

그걸로 끝이었습니다 .

물론 저야 엄첨나게 놀랐죠 .

마이크로소프트 사에서 엑셀 매크로 전략을 맡은 프로그램 관리자는 엑셀 매크로 전략에

관해서만은 ‘신’입니다 .

경력 6 개월이 채 안되는 신입이라도 상관이 없습니다 .

다른 누구도 , 심지어 서열 6 위라도 건드릴 수 없습니다 .


79

5.13 관리자와 개발자의 신뢰 2 몇 년이 흘러 , 제가 온라인 서비스와 무료 메일 서비스를 제공하는 주고 사에서 일할 때

이야기입니다 .

이번에는 마이크로소프트 사와는 정반대 경험을 했습니다 .

제가 맡은 프로그래머가 두 명 있었는데 , 상사는 저를 건너뛰고 두 사람에게 바로 업무를

지시하는 등 제 권한을 무시하는 행동을 일삼았습니다 .

아예 제게 말하지 않는 경우도 있었습니다 .

월차 같은 사소한 문제도 자신이 직접 승인해야 한다고 생각했습니다 .

주노 사에서 일한지 두어 해가 됐을 무렵 회원 가입 기능을 맡은 적이 있습니다 .

주요 출시 버전인 주노 3.x 에 넣을 회원가입 과정을 총체적으로 책임지는 업무였습니다 .

기술팀에서 경력이 꽤 많은 축에 속했고 , 성과평가에서도 우수했으며 , 관리층도 제

능력을 인정하는 듯 했습니다 .

그러나 전적으로 책임을 맡길만큼 신뢰하지는 않더군요 . 명령과 통제는 여전히

존재했습니다 ..


80

5.13 관리자와 개발자의 신뢰 2 회원가입 과정에서 사용자에게 생년월일을 묻는 단계가 있었습니다 .

수입 , 가장 좋아하는 스포츠 , 자녀 수 , 나이 등 온갖 시시콜콜한 질문에 대답해야만 하는

장황한 과정 중 아주 일부에 불과한 내용이었죠 .

저는 회원가입 과정을 조금이라도 쉽게 하려고 생년월일 입력을 자유형으로 바꿨습니다 .

사용자가 74/8/12 를 입력하든 ‘ 1974 년 8 월 12 일’을 입력하든 상관없게 말입니다 .

자세한 이야기는 생략하고 , 제 상사가 반대했습니다 .

결국 자존심 문제로 이어졌죠 . 처음에는 그 페이지를 작업한 디자이너를 윽박질렀습니다 .

그 다음에는 화살을 제게 돌리더군요 .

자기가 원하는 방식으로 고치라고 저를 못살게 굴었습니다 .

사장에게까지 보고를 올린 후 , 사장도 제 디자인을 비판했다면서 한바탕 난리법석도

떨었습니다 . 주노 사 사장은 사내 시시콜콜한 문제까지 관여하기를 좋아했기에 , 그

정도는 약과였습니다 ..


81

5.13 관리자와 개발자의 신뢰 2 이 때문에 주노 사를 그만두었다고는 말할 수 없지만 , 제가 그 회사를 떠나야 겠다는

생각이 들게 한 일인건 맞습니다 .

아주 사소한 일조차도 권한이 없었습니다 .

게다가 주노 사에는 중간 관리자가 넘쳐났습니다 .

전체 직원 중 4 분의 1 정도가 중간 관리자였는데 , 사소한 일마다 코를 들이밀고는

권한을 과시할 정도로 시간이 남아돌았습니다 .

9 호 건물에서 몸소 왕림하신 부사장님께서 개발자에게 전적으로 권한이 있다고 천명하는

마이크로소프트 사와는 철저히 대조적이었습니다 .


82

5.14 프로그래머의 고집에 대한 사례

한 프로그래머가 어떤 자동차 회사에서 사용할 새 프로그램의 디버깅을 의뢰 받아

디트로이트로 출장을 가게 되었다 .

그 프로그램의 목적은 주문 요청서를 기록한 천공카드로부터 고객이 선택한 옵션을 입력

받아 그에 맞는 자동차를 만드는데 필요한 부품 목록을 도출하는 것이었다 .

우리의 주인공이 도착했을 때 프로그램의 상태는 이미 걷잡을 수 없게 되어 평범한 입력에

대해 “ 타이어 8 개 , 좌석 3 개 그리고 엔진은 없다 .”라는 결과가 나오고 있었다 .

한마디로 말해서 완전히 실패작이었다 .

그러나 아무도 이 상황을 실패로 인식하지 않았다 .

대신 , 전 직원을 2 교대로 나누어 강도 높은 디버깅 작업에 착수했고 프로그래머도

증원했다 .

당연히 상황은 더욱 혼란스러워졌고 , 우리 주인공은 며칠 만에 프로젝트에 가망이 없으며

그런 일에 매달려 밤낮으로 시달리느라 가족들과 떨어져 있을 필요는 없겠다고 판단했다 .

그래서 태도가 비협조적이라는 비난도 감수하며 일을 그만두었다 .


83


돌아가는 비행기에서 그는 일주일 만에 처음으로 조용히 사색할 여유를 가질 수 있었다 .

그러자 문득 지금의 접근법이 지닌 근본적인 문제점이 떠올랐고 , 작업을 두 단계로 나누는

편이 훨씬 더 좋은 방법임을 직감했다 .

새 프로그램의 시연을 본 경영자들은 프로젝트가 계속될 수 있음을 확신했고 , 다른

프로그래머들도 참석하는 설명회를 열도록 했다 .

다른 프로그램머들은 냉담한 분위기를 풍기긴 했지만 조용히 앉아 그의 설명을 끝까지

들었다 .

질문 하나 없이 설명이 끝나갈 즈음에 기존 프로그램의 원작자가 손을 들었다 .

“ 당신 프로그램은 실행 시간이 얼마나 걸리나요 ?” 당신 프로그램이란 말을 강조하며

질문했다 .

“ 입력에 따라 다르겠지만 , 카드당 평균 10 초정도입니다 .”주인공이 대답했다 .

“ 아하 ! 내 프로그램은 카드당 1 초밖에 안 걸리는데요 .” 원작자가 의기양양하게 말했

다 .


84


그때까지 뭔가 불만스러운 표정을 짓던 다른 프로그래머들이 그 대화를 듣고 안도하는

듯했다 .

그러나 아직 젊고 순진한 우리 영웅은 기죽지 않고 차분히 응수했다 .

“ 하지만 그 프로그램은 작동하지 않잖아요 .

프로그램이 작동하지 않아도 괜찮다면 난 1000 분의 1 초에 카드 한장을 처리하는

프로그램도 만들 수 있어요 .

1000 분의 1 초면 카드 판독기가 카드를 읽는 속도보다도 빠른 겁니다”


85

5.15 경영진의 압박

뛰어난 프로그래머이지만 외부에서 임명되어 리더의 직책을 맡다 곤경에 처했던 해럴드의

경우를 보자 .

그는 특정 기일까지 컴파일러를 개발할 팀을 이끄는 리더의 자리를 수락했다 .

그런데 갑자기 회사 측에서 일정은 그대로 유지하면서 요구사항을 늘리길 원했다 .

해럴드는 팀원들과 이 문제를 상의했고 , 기간을 석 달 연장해주지 않는 한 불가능하다는

결론에 도달했다 .

해럴드는 이 결정을 관리자에게 전달했지만 받아들여지지 않았다 .

해럴드가 뜻을 굽히지 않고 강력히 주장하자 , 그 관리자는 해럴드와 더 높은 관리자가

참석하는 회의를 주선했다 .

해럴드는 회의 참석자의 구성을 보고서 회의가 자신을 불구덩이로 물어넣는 모략임을

알아챘다 .


86


편의상 비공식적으로 마련된 이 회의는 , 온갖 위협과 약속이 오가지만 결코 인정은 하지

않는 분위기에서 해럴드 자신이 상당히 중요 인사라는 느낌을 받도록 하려고 마련된

자리였다 .

그러나 해럴드는 관리자가 다음에는 어떤 행동을 할 지 예측할 수 있을 정도로 비슷한

경험이 많았고 , 자신과 팀의 판단에 대한 자신간으로 단단히 무장하고 있었다 .

회의는 한동안 큰 문제 없이 진행되면서 서로 밀고 당기는 가운에 분위기가 점점 고조되었

다 .

마침내 회의는 궁극적인 위협의 단계에 이르렀다 .

해럴드의 관리자는 악역을 도맡아 하는 역할이었고 , 고위 관리자의 임무는 하위 관리자의

거친 위협을 달콤한 약속으로 부드럽게 무마하는 것이었다 .

따라서 해럴드의 관리자가 먼저 “해럴드 .”라고 부르며 말을 꺼냈다 .

그는 의미심장하게 의자를 10 cm 나 앞으로 당겨 앉은 뒤 , 다시 “해럴드”라고 불렀다 .


87


“ 당신은 지금 우리에게 협조하지 않고 있어요 . 관리자로서 당신은 협조하고 타협하는

법을 배워야 합니다 .

어쩌면 당신은 관리자의 소양을 갖추지 못한 듯하군요 .”

해럴드는 그 말에 숨겨진 뉘앙스를 포착하고 , 그냥 넘어가는 대신 아예 드러내 놓고 따지기

시작했다 .

“ 당신 말이 맞는 것 같네요 . 그러면 이 일을 할 만한 다른 사람 , 협조할 줄 아는 사람을

구하면 되지 않겠습니까 ?”

고위 관리자는 해럴드가 한계에 도달했다는 것을 눈치 채고 그를 다시 긍정적인 방향으로

되돌리려 했다 .

그는 “하지만 해럴드 , 그럴 만한 다른 사람이 없어요 . 당신이 이 일을 할 수 있는 유일한

사람이에요 . 우리는 당신을 믿고 있어요 .”라며 추켜세웠다 .

“ 그렇다면 , 내가 그 일을 할 수 있는 유일한 사람이라면 말이죠 . 내가 그 정도기간에는 이

일을 할 수 없다고 얘기하는 데 왜 내말을 안 믿는 겁니까 ?”라고 짐짓 의기양양한 척하는

어조로 해럴드가 말했다 .


88


“ 그건 당신이 문제를 제대로 이해하지 못하고 있으니까 그렇죠”라고 관리자가 쏘아붙였을

때쯤 해럴드는 이미 자리에서 일어나 문 앞으로 걸어가고 있었다 .

그는 막다른 길에 다다른 분위기의 회의장을 나서기 전에 이렇게 말했다 .

” 자 , 이제 결정을 내리세요 . 내가 문제를 이해하는 유일한 사람이라면 , 그럼 내가

문제를 제대로 이해하는 유일한 사람인거고 당신들은 내 식으로 해야 하는 겁니다 .

그게 아니라면 , 당신들은 아무 거림낌 없이 날 자르고 다른 사람을 고용할 수 있겠죠 .

이건 내 문제가 아니라 , 당신들 문제입니다 .

그러나 괜찮으시다면 , 전 그만 일하러 가 봐야겠습니다 .”


89

5.16 프로그래머의 일하는 방식

인공지능 언어인 LISP 에 관한 교과서를 저술할 정도로 깊은 내공을 갖춘 프로그래머였던

그레이엄이 고백한 스스로의 프로그래밍 스타일은 마치 화가가 붓을 놀려서 그림을 완성해

나가는 것과 같은 점진적이고 반복적인 과정으로 이루어져 있었다 .

그는 프로그래밍을 할 때 전체적인 설계를 마치고 나서 코딩을 시작하기보다는 캔버스에

그림을 그릴 때처럼 조금씩 반복되는 작업을 통해서 코드에 살을 붙여 나갔다 .

이 과정에서 키보드는 붓이 되고 모니터는 캔버스가 되었다 .

이와 같은 그레이엄의 스타일에 대해서 필자는 “ 프로그래밍은 예술이다” 에서 다음과 같이

말했다 .

“ 뛰어날 프로그래머였던 그레이엄은 자기 자신도 프로그래밍을 할 때 키보드를 붙잡고

코딩부터 시작한다고 고백했다 .

그가 밝힌 방법은 우선 가볍게 키보드를 두드리면서 코드의 전체 윤곽을 잡고 , 다시

처음으로 돌아가서 조금씩 각 부분의 디테일을 살려 나가는 방식으로 프로그램을 작성하는

것이었다 .


90

5.16 프로그래머의 일하는 방식

그는 코딩이 설계에 앞서는 이와 같은 방식을 조금도 이상하게 여기지 않았다 .

오히려 그는 모든 예술적 창조가 대개 이와 비슷한 과정을 거치면서 이루어지며 그림을

그리는 과정도 이와 다르지 않다고 말했다 .

그리고 미술에서는 그것을 ‘스케치’라는 자연스러운 이름으로 부른다고 지적했다 .”


91

5.17 프로그래머의 과욕


전 직장인 루슨트 테크놀로지스에서 5 년 간 함께 일했던 영국의 프로그래머들은 돌이켜

생각해보건대 , ‘객체’라는 중장비로 온 몸에 철갑을 두른 용맹한 기사들이었다 .

‘ 객체’를 바라보는 그들의 시선은 나무랄데 없이 깊고 중후했다 .

잠시도 공부를 게을리 하지 않는 그들은 디자인 패턴 , 리팩토링 , UML 과 같은 ‘기본적인’

초식에 정통한 것은 물론이고 ‘멀티스레딩’이나 시스템 성능처럼 자칫 발을 헛디디면

내상을 입기 쉬운 심오한 분야에서도 주저함이 없었다 .

그들이 최종적으로 개발해서 들고 온 ‘컴포넌트’에 대한 느낌을 한마디로 간추리자면

그것은 ‘객체의 소나기’였다 .

아무리 철저하고 부지런한 프로그래머라고 해도 버그가 없는 소프트웨어를 작성하는 것은

불가능하다 .

영국 프로그래머들이 작성한 컴포넌트는 대단히 세심하게 작성된 소프트웨어였지만 촘촘한

객체의 그물망을 뚫고 고개를 내미는 버그가 없을 수는 없었다 .

92

5.17 프로그래머의 과욕


소프트웨어가 출시되고 나서 얼마 후에 날짜의 형식이 제대로 변환되지 않은 채 화면에

나타나는 경우가 발생했다 .

이와 같은 버그는 원인을 추측하는 것이 어렵지 않기 때문에 비교적 잡기 쉬운 편에 속한다 .

하지만 영국 친구들의 컴포넌트 내부에서는 이렇게 단순한 버그조차 수정하기가 어려운

버그로 판명되었다 .

버그를 잡기 위해서는 복잡하게 얽히고 설킨 객체의 상속과 위임 관계의 폭포를 한걸음씩

거슬러 올라가야 했기 때문에 생각보다 많은 시간과 노력이 들 수밖에 없었다 .

93

5.18 리더의 자세


리더의 목적이 사리사욕이 아니라 조직의 발전과 행복이어야 하지만 이를 실현하는 수단이

부드러움이나 자비로움일 필요는 없다 .

목적을 위해서는 리더는 때로는 냉정하고 잔인하고 이기적으로 보이기 까지 해야 한다 .

리더가 팀원들의 인정과 칭송을 구하는 순간 팀원들은 리더를 최대한 자기목적을 위해

이용하려 할 것이다 . 따라서 팀원들에게 칭찬을 받으려 하지 말아야 한다 .

마키아벨리의 말을 들어보자 .

“ 여기서 또 하나의 문제가 생기게 된다 . 즉 사랑을 받는 것과 두려움의 대상이 되는 것 중

어느 쪽이 좋은가 하는 점이다 . 누구나 양쪽을 다 갖추었으면 하는 대답을 할 것이다 .

그러나 이 두 가지를 동시에 구비하기란 어려운 일이다 .

따라서 만일 그 중 하나를 택해야 한다면 사랑받는 것보다는 두려움의 대상이 되는 편이

훨씬 안전하다 . 그것은 인간에 대해 일반적으로 다음과 같은 말을 할 수 있기 때문이다 .

94

5.18 리더의 자세


원래 인간은 은혜도 모르고 변덕이 심하며 , 위선자인 데다 뻔뻔스럽고 , 신변의 위험을

피하려 하고 , 물욕에는 눈이 어둡기 때문이라고 . 그래서 당신이 은혜를 베푸는 동안에는

모든 사람이 당신 뜻대로 되고 , 그들은 피와 재산과 생명과 아이들까지도 당신에게 바친

다 .

그러나 이것은 앞서 말했듯이 그럴 필요가 별로 없을 때뿐이다 . 막상 군주가 궁지에 빠지면

그들은 등을 돌린다 .

따라서 그들의 약속만 전적으로 믿고 있던 군주는 다른 준비를 모두 소흘히 해 멸망하고

만다 . 숭고한 정신과 위대함에서가 아니라 보수로 매수한 우정은 그만큼의 값어치밖에

없으며 , 영원한 가치가 있는 것이 아니므로 유사시에는 힘이 될 수 없다 .

또한 인간은 두려워하던 자보다도 애정을 느끼던 자에게 더 가차없이 해를 입힌다 .

그 이유는 원래 사람은 사악하므로 단순히 은혜로 맺어진 애정쯤은 자기와 이해 관계가

얽히는 기회가 생기면 즉시 끊어 버리기 때문이다 .

그러나 두려워하는 자에 대해서는 그들 자신이 처벌이라는 공포로 묶여 있기 때문에 결코

모르는 척할 수 없다 .”

95

5.19 리더는 방해물을 제거한다 .


PM 은 팀원들이 일일 회의 시간에 잔돈을 세는 걸 자주 보았다 .

이유인 즉 , 커피를 살 잔돈이 충분한지 확인하는 것이라고 했다 .

그들은 제품의 기능 향상을 위해 야근을 할 때 , 졸음을 쫓아내려고 커피를 마시고 싶어했

다 . 그러나 그 층에는 커피 자판기가 하나 밖에 없었다 .

PM 은 커피를 공짜로 제공하지 않는 회사를 다녀 본적이 없었고 그래서 이런 생각지도 않은

점을 놓친 실수에 대해 당혹감을 느꼈다 .

그래서 PM 은 시설 관리부장을 찾아가 팀원들에게 커피를 제공해 줄 수 없겠냐고 물었다 .

시설 관리 부장은 회사 규정이라고 거절했다 .

PM 은 팀이 늦게까지 졸지 않고 급한 코드를 작성하기 위해서는 카페인이 필요하다고

항의했다 . 결국 PM 은 공짜 커피를 얻어냈다 .

96

5.20 피터의 법칙


조직 내의 모든 사람은 무능한 수준 , 즉 자신의 능력으로 감당할 수 없는 자리에 오를

때까지 승진하는 경향이 있다 .

군대를 예로 보자 .

일선 지휘관이 능력을 인정받아 더 높은 자리로 승진했다면 새로 이 승진한 직위에서는

군인으로서의 그의 자세나 부하 통솔력 , 용맹스러움 등이 점점 더 중용하지 않게 된다는

것이다 .

그보다 더 높이 승진할 경우에는 정치인이나 정부 관리들을 다루고 이해관계자들을

조종하는 일이 주요 업무가 된다 .

여기서 원칙에 투철한 군인은 정치인으로는 무능해지기 쉽다는 것이다 .

97



맥아더와 아이젠하워 두 사람은 성격도 스타일도 , 걸어간 길도 극적으로 대비되는

군인들이었다 .

맥아더는 웨스트포인트 미 육군사관학교를 수석으로 졸업하고 50 세에 대장으로 승진했

다 .

이는 미군 역사상 가장 빠른 승진 기록이었다 .

그만큼 그가 유능한 군인이었다는 의미일 것이다 .

반면 아이젠하워는 맥아더보다 12 년 후배로 그저 그런 성적으로 미 육군사관학교를

졸업하고 중령 계급장만 16 년 동안 달았던 무명의 초급 장교였다 .

그러다가 제 2 차 세계대전이 발발하자 아이젠하워는 마샬 장군에게 발탁되어 승승장구 ,

해마다 소장 , 중장 , 대장으로 진급했고 마침내 노르망디 상륙작전을 성공적으로 이끌어

영웅이 되어 귀국했다 .

두 사람을 비교하자면 맥아더는 장군으로는 유능했지만 정치적으로 무능했던 반면

아이크는 초급 장교 시절까지는 그저 그런 군인이었으나 별을 달면서부터 준장 - 소장 -

대장까지 , 그리고 대통령까지 한 걸음에 내달린 사람이었다 .98



여기서 관료제의 병폐가 나타난다 .

만약 미국의 대통령 선발이 선거나 아닌 관료주의의 특성인 내부승진 방식으로

이루어졌더라면 연공서열에서 절대적으로 유리한 맥아더가 대통령이 되었을 것이고 ,

그랬다면 맥아더는 미국 역사상 가장 무능한 대통령이 되었을 것이라는 생각이 학자들의

공통된 견해이다 .

맥아더가 군사적으로 전략밖에 모르는 고집불통이었다면 아이크는 장군이 되면서부터는

조정자로서 , 중재자로서 뛰어난 리더쉽을 발휘했다 .

노르망디 상륙작전 당시 아이크의 리더쉽을 보자 .

연합국 사령관인 아이크는 영국의 몽고메리 장군 , 미국의 패튼 장군 , 영국의 처칠 수장 ,

프랑스 드골 대통령의 협조가 절실했다 .

이들 중 어느 하나라도 협조하지 않으면 노르망디 상륙작전은 성공할 수 없었다 .

알다시피 앞서 언급한 인사들은 모두 당대 최고의 고집불통들이었다 .

이해관계가 다르고 색깔이 강한 이들을 다독거려 공통의 분모를 만들어낸 인물이 바로

아이젠하워였다 .99



즉 지위가 높을 수록 전문적인 업무 능력보다는 다양한 이해관계로 얽힌 사람들을 다루고

설득하는 능력이 훨씬 더 중요하다는 것이다 . 이것이 ‘공통분모의 법칙’이다 .

맥아더와 아이크 , 두 사람에 대한 평가는 뉴욕타임스의 제임스 C. 흄스 기자의

회고록에서 극명하게 나타난다 .

그는 어느 날 맥아더와는 점심식사를 , 아이크와는 저녁식사를 같이할 수 있는 행운을

얻었다 .

그는 이렇게 적고 있다 .

“ 맥아더와 식사를 할 때면 그가 얼마나 대단한 사람인가를 알게 되지요 . 그러나 아이크와

식사를 같이 하면 제가 얼마나 대단한지를 알게 된답니다 .”

맥아더는 남의 이야기를 듣지 않는 아집의 사나이였지만 아이크는 남의 이야기를 들어주고 ,

상대를 자기편으로 끌어들이는 재주가 뛰어났던 것이다 .

그것이 높은 자리로 승진할수록 능력을 발휘할 수 있는 자산이다 .

100

5.21 디즈니사의 백설공주 제작팀


디즈니는 마음 속으로 장편의 에니메이션 영화를 구상하고 있었다 . 자신의 캘리포니아

스튜디오를 돌아오자마자 , 그는 백설공주에 관한 동화를 기초로 해서 영화를 제작하기로

결심하였다 .

디즈니는 영화 제작에 4 년을 소비했다 . 그 과정에서 , 그는 디즈니 스튜디오에 비범한

집단을 창설하기도 하였다 .

그는 에니메이션 분야에서 최고인 핵심 인물들과 일을 시작했다 .

그들 중 많은 사람들이 각자 자신들의 작품에 대해 자부하고 있었으나 , 디즈니는 그들에게

합작을 하도록 요구하였다 .

그래서 그들은 개인적으로 작품을 만드는 것이 아니라 , 팀을 이루어 작품 만드는 일을

하였다 .

디즈니는 영화의 이야기 줄거리를 만드는 작업을 할 때 , 화가 , 에니메이션 작가 , 극작

가 , 그리고 음악가로 구성된 소집단과 정규적으로 회합을 가졌고 , 대사를 쓰고 음악을

작곡하였으며 , 250,000 장의 그림을 그려 하나의 완성된 작품을 만들어냈다 .

101



회사의 재정이 바닥났을 때 , 디즈니 스튜디오에서는 종종 갈등이 분출하기도 했으나 ,

팀들은 믿을 수 없을 정도로 응집력이 커졌다 .

그들은 자신들의 프로젝트를 “월트의 어리석은 짓”이라고 매도하던 헐리우드의 회의적

비평가들이 잘못이었음을 증명해 보였다 .

1937 년 백설공주가 출품되었을 때 , 사람들은 영화 제작에서 하나의 주요한 업적이라고

환호하였다 .

디즈니 집단은 주목할 만한 특징들을 많이 가지고 있었다 .

성원들의 동기는 최고조에 달해 있었고 , 리더는 끈기 있게 뛰어난 재질을 발휘하였으며 ,

집단은 목표를 달성하기 위해서 엄청난 장애물들을 극복해내는 수완을 발휘하였다 .

그렇지만 , 그 집단의 가장 독특한 면모는 응집력이었다 .

일부 집단들도 결속의 기미가 보이는 정도까지는 도달하지만 , 이를 넘어서 디즈니 집단은

마치 단일체로서 기능하는 것처럼 보일 정도로 그 응집력은 커졌다 .

102



애니메이션 영화인 백설공주의 제작진들은 자신들이 마치 이 세상에서 가장 훌륭한

애니메이션 스튜디오의 성원들인 것처럼 생각했고 , 그들이 자신들의 목표를 달성할 것을

확신하고 있는 듯하였다 .

그들은 그들의 집단을 서술할 때 , 가족 , 팀 , 공동체라는 단어들을 사용하였다 . 누군가

“우리들은 마치 웨스트 포인드의 한 내무반 동료들인 것 같았다”라고 말했다 .

디즈니 스튜디오의 제작진영은 가까운 친구들이 되었고 , 한참 시간이 흐른 뒤에는

외부와의 연결이 거의 없어졌다 .

실제로 월트 디즈니는 제작진영의 사람들이 너무 친해졌다고 느낄 대에 중간에 끼어 들어

억제시키려고 했다 .

그는 자신의 스튜디오에서 함께 일하는 사람들간에 어떠한 종류의 연애관계도 허용치

않았다 .

의문의 여지없이 디즈니 스튜디오는 응집력이 높았다 .

강력한 힘이 집단의 공조를 유지시켰고 ( 아마도 강력한 힘은 월트 디즈니 그 자신이었을

것이다 .)103



그 스튜디오는 비상하리 만큼 통일되어 있었고 , 성원들 대부분이 서로를 좋아했으며 ,

백설공주를 창출해내기 위해서 열심히 일을 하였다 .

그런데 그 집단은 결코 하루 아침에 응집력이 높아진 것을 아니었다 .

디즈니가 처음 그의 핵심 애니메이터들에게 프로젝트를 설명했을 때 , 많은 애니메이터들이

회의적이었다 .

누구도 디즈니가 추구한 목표를 달성해 보려고 애썼던 사람은 없었다 . 디즈니는 많은 새

직원들을 채용하려고 동분서주했다 .

새로운 얼굴들이 초안을 작성하는 테이블에 나타날 때마다 , 그 집단은 애써 조율을 해야만

했다 .

작업은 여러 가지 요구되는 바가 많은 것이었고 , 많은 애니메이터들이 디즈니의 고답적

기준에 도달하는데 어려움을 겪었다 .

모든 집단이 그러하듯이 , 디즈니 집단도 시간이 지남에 따라 변화해갔다 .

처음 모였기 때문에 생긴 디즈니 집단의 긴장이 수그러들자 , 목표 , 절차 , 그리고 권위

영역에서의 긴장이 고개를 든다 . 104



윌트 디즈니는 직원들의 신성모독 , 음주 , 사내연애 같은 행위를 엄격히 금지시켜야

하겠다는 굳건한 신념을 가지고 있었는데 , 직원들은 종종 디즈니의 이와 같은 엄격한 제한

정책에 대해 불평을 말하기도 하였다 .

몇몇 직원들이 미키 마우스와 미니 마우스가 등장하는 영화를 성인용으로

애니메이션하면서 대항해 왔을 때 , 갈등은 극에 달했다 . 심기가 불편해진 월트 디즈니는

그들을 해고하였다 .

이런 매 위기를 극복하면서 , 디즈니 스튜디오는 더욱 안정되고 , 더욱 조직화되고 ,

그리고 더욱 응집력이 높아졌다 .

디즈니는 공식적인 명령 계통을 수립하였고 관리책임을 분명하게 명시하였다 .

예를 들면 , 수석 애니메이터는 애니메이터들의 과제를 알려주고 , 보상을 조절해 주고 ,

일상적인 일 , 절차 , 그리고 마감 시한을 설쟁해 주고 , 작업을 모니터 한다는 책임을

구체적이며 공식적으로 명시하였다 .

105



성원들은 규칙 , 작업 , 급여 등에 대해서 이따금씩 불평을 토로했지만 , 프로젝트와 동료

성원들에게 무서울 정도로 충성하게 되었다 .

디즈니 스튜디오에서는 , 성원들이 항상 상호간에 또는 보스와 의견의 일치를 보였던 것이

아니라 , 의견의 불일치를 다루는 방식을 변화시켰다 .

의견을 넌지시 비치거나 언쟁을 벌이는 대신에 , 모두에게 유익한 일치에 이르는 방법을

두고 협상해 나갔다 .

월트 디즈니가 어느 애니메이터에게 , “ 일이 어떻게 되어가고 있나 ?”라고 즉흥적인

질문을 하였을 때 , 일을 제대로 못하고 있는 애니메이터가 안심하고 “엉망입니다 .”라고

말할 수 있었다 .

그러면 디즈니는 그를 다른 팀으로 교체해 주었고 , 그는 그 곳에서 극적인 수행성과를

올렸다 .

106



집단이 형성되자마자 생산적인 집단이 되는 경우는 거의 없다 . 생산성은 집단이 성숙된

연후에야 가능하게 되는 것이 보통이다 .

디즈니 스튜디오가 이러한 단계에 다다른 해는 1935 년이었다 .

디즈니 스튜디오의 방문객들의 말로는 디즈니 스튜디오는 북적대지만 정연하게 움직이는

벌집을 연상시킨다는 것이다 .

성원들이 팔꿈치가 맞닿을 정도로 밀집된 사무실 안에서 작업들을 하고 있었으며 ,

복도에서는 비공식적 회의가 열리고 있었으며 , 점심 식사 중에도 특정한 기법의 장점에

대해 논쟁을 벌이고 있었으며 , 선임 애니메이터가 강의하는 예술강좌에 참석하려고 늦은

시간까지 남아 있었다 .

그들은 백설공주를 창조하는 일을 완수해가고 있었다 .

1930 년대 중반에 보였던 디즈니 스튜디오 사람들의 동지애와 작업 윤리는 백설공주가

완성되면서 상당히 많은 부분이 시들해졌다 .

107



그 스튜디오는 다른 프로젝트로 전환하였는데 , 첫 애니메이션 작품에서 보였던 그와 같은

열정과 신기함은 결코 다시 찾아볼 수 없었다 .

디즈니의 직원들 중 상당수가 그에게 여전히 충성을 하였으나 , 점차 그의 방식에 의문을

제시하는 사람들이 늘어났다 .

디즈니 스튜디오는 여전히 성공작을 내놓고 있으며 , 생산적이고 창조적이지만 , 그

일체성은 상당히 소멸되고 말았다 .

1941 년 다수의 애니메이터들이 파업을 했을 때 , 디즈니 스튜디오의 황금기는

종식되었다고 하겠다 .

많은 연구들이 팀을 구성하는 것이 효과적이라는 것을 입증하였다 . 여러가지 많은 유형의

조직과 직무상황에서 집단 중심적인 중재가 있은 후에 결근율 , 이직률 , 고충호소 등이

줄어든다 .

또한 조직에 관한 사례연구들도 팀의 효과성을 입증하고 있다 . 예를 들어 Texas

Instruments라는 회사는 가능한 한 사원들을 소그룹으로 조직화했을 때 생산성이

증가혔다 .

108



미국에서 어떤 기능공이 팀으로 자리를 옮겼을 때 지원적인 감독 , 참여적 리더쉽 ,

집단들간의 조직상의 중복 , 집단 상호작용의 강도 , 사원의 만족이 증가하였고 , 이직은

감소하였다 .

109

110

실습 :

오늘 아이리스 마지막회 입니다 .

팀을 만들어서 아이리스 내용을 아시는 분이 팀원들에게 설명해 주시고

여러분 스스로 아이리스의 마지막 회를 만들어 보십시요 .

팀원들 누구에게도 발표할 기회를 주어야 합니다 .

규칙은 간단합니다 .

팀원중 누가 얘기를 해도 모두 칭찬해 주시고

절대 재미없다는 말을 해서는 안됩니다 .

또한 팀장은 정리만 할 뿐 결정할 권한은 없습니다 . 결정은 팀이 합니다 .

그리고 모아진 의견을 팀장이 정리하여

아이리스 마지막 회의 시나리오를 만들어 보십시요 .

6. 결론

리더쉽에 대한 잘못된 개념

리더쉽의 본질 : 헌신

문제 해결의 기술

111

6.1 리더쉽에 대한 잘못된 개념

리더쉽은 부하를 통제하는 것이다 .

리더쉽은 타고 나는 것이다 .

연구결과 개인의 성격과 리더쉽은 아무 관계도 없음 .

리더쉽에는 공식이있다 .

리더쉽은 만병통치약이다 .

6. 결론

112

6.2 리더쉽의 본질 : 헌신

제갈량은 리더쉽의 모범사례임 .

촉나라는 매우 다양한 집단들이 모였으며 통치하는 것이 쉽지 않았음

제갈량은 신상필벌의 방법으로 나라를 다스림 .

재능 있는 지식인들을 발탁하는 데 힘씀 .

익주의 강력한 대족들이 권세를 휘두르는 것을 봐주지 않고 소수 민족에게도 은덕과 위엄을

사용함 .

제갈량의 지도력은 촉나라의 정치에 투명성과 통일성을 보증하였음 .

자신의 아들 , 조카 , 가장 친한 친구가 법을 어겨도 똑같이 처벌함 .

마속은 대단한 신임을 받는 장수였으나 제갈량의 명령을 어기자 눈물을 흘리며 마속을 처형

함 .

제갈량이 사람들로부터 신뢰와 복종을 얻은 이유는 엄격함과 공정함이었음 .

그 다음에 성실과 신뢰로 사람을 대함 .

또한 제갈량은 유비의 뜻을 받들어 한나라를 복원하기 위해 헌신함 .

6. 결론

113

6.3 문제 해결의 기술 : 미완료 작업 감소

프로젝트 작업 목록을 관리하여 개발자를 방해하지 않도록 한다 .

6. 결론

프로젝트 작업 목록

개인 작업 목록

개인 작업 목록

114

6.4 문제 해결의 기술 : 2주간의 반복

최대 개발 시간을 2 주로 제한하고 문서 작업 , 관리 작업등의 불필요한

요소를 제거한다 .

6. 결론

초기 개념

설계 및초기

프로토타입 구현

받아들일때까지

프로토타입 수정

프로토타입완료 및배포

115

6.5 문제 해결의 기술 : 개발과 병행한 테스트

개발기간을 2 주로 제한하고 오류가 발견되는즉시 프로그램을 개선한다 .

오류 목록을쌓지 않고즉시 개선한다 .

6. 결론

개발 테스트케이스

작성

테스트 버그 수정

1 차 반복1 차 반복



116

6.6 문제 해결의 기술 : 개발에 몰입

개발기간을 짧게 하는 대신개발자는 개발에몰입하게 한다 .

개발외의 모든작업을 자동화내지 관리자가 대신수행한다 .

6. 결론

개발

프로그램 등록

형상관리서버

연속 빌드

자동 테스트

문제 게시

117

6.7 문제 해결의 기술 : 작업 재분배

관리자는 개발자의 작업 생산성을 모니터링하여 적절히 작업을 분배함 .

6. 결론

118

6.8 문제 해결의 기술 : 협업

작업자 , 팀간의 의사소통 시간 단축및 자동화

6. 결론

아키텍처 팀관리자

아키텍처 팀설계자

웹 사이트를 통해 통보

공통 모듈개발 결정

개인별 이슈 할당(새로운 이슈로 등록)

데이터베이스관리자

아키텍처 팀개발자

형상관리자

프로젝트 팀에게통보

Mantis를 통한작업지시

아키텍처 팀 개발 프로세스(상세)

작업 내역서 작성및 분석 요청

MindMap으로요구사항 정리

솔루션 제시(분석 완료로 상태변경)

Prototype 개발 완료(Prototype 개발완료로

상태변경)

Prototype 검토 및설계 문서 작성

(설계 완료로 상태변경)설계 요청

개발(개발 완료로 상태변경)

개발 요청

검토 및 테스트(검토 및 테스트완료

로 상태변경)

배포(해결된이슈로

상태변경)

119

6.9 다음과 같은 관행을 경계할것

6. 결론

기업의 잘못된 관행기업의 잘못된 관행

현재 성공에 안주부서간 높은 장벽 전시성 관리형태

팽배한 보신주의가로막힌 언로

120

6. 결론

변화를 위해서 많은 기업들이 교육을 받고 과제를 수행한다 .

그러나 생각의 변화는 행동의 변화로 이어지지 않는다 .

반대로 무조건 행동을 바꾸면 생각도 바뀌고 그 생각의 변화가 다시 새로운 행동의 변화를 일으킨다 .

왜냐하면 사람은 자신의 변화된 행동을 정당화 시키기 위해가치관과 사고방식을 바꾸기 때문이다 .

그러므로 먼저 행동하라 .

121

Documents

피터의법칙