생존을 위해 몸부림친 흔적들과 소고

(SI 사업에서의 Agile 의 적용 )

November, 2009

SK C&C MS Team 민신현 과장

Contents

1. 죽도록 싫은 SI 개발에 대한 소고

2. 개발이 왜 싫어졌는지에 대한 물음

3. 사람을 위한 개발의 노력과 결과

4. 남아 있는 문제들

2
 1. 죽도록 싫은 SI 개발에 대한 소고

“ 한국 SI 산업”은 “후진국형 인건비 산업” 의 현실

저가수주

운영비제외

인건비지급
국가의
잘못된 소프트웨어 발주금 약 삶의질하락
단가 70~80%
가격산정 기술자 80%
발주
( 인력수 , 단가표 하청 경력퇴사
인력경력 )
신입입사

품질저하

경쟁력하락

프로젝트의 성공과 실패는 비전문가에 의해 운빨과 영업력에 좌우됨

3
 1. 죽도록 싫은 SI 개발에 대한 소고

SI 개발과정에서 일어나는 흔한 사례들

1. 도라에몽은 여러분의 소원을 다 들어 줍니다 .( 컨설팅 )

4. 실재 개발과정의 결과물 ( 테스트단계 ) 5. 갈굼

을 갑
병
2. 이런걸로 만들어 주면 좋겠어 ( 요구사항 수렴 )

3. 그까이꺼 이렇게 만들면 되지 말임다 . ( 설계 )

4
 1. 죽도록 싫은 SI 개발에 대한 소고

좌절과 프로젝트가 남긴 것들

6. 개발자의 좌절
7. 프로젝트 종료의 결과

5
 1. 죽도록 싫은 SI 개발에 대한 소고

국제 통계를 보더라도 Project 의 성공율은 30% 정도이며 요구사항에 미치지 못하지만 기간

오버되고 끝난 것이 50% 정도 나머지 20% 정도가 완전히 지옥을 체험하는 프로젝트가 됨

[Source: 소프트웨어 진흥원 ]

6
 1. 죽도록 싫은 SI 개발에 대한 소고

실패하는 원인은 더욱 가관으로 대부분의 문제가 “요구사항”에 기인하고 결국은 시스템의 복잡도가
대부분의 인간의 상상력과 예측 능력 밖의 일이 되고 있음

[Source: 소프트웨어 진흥원 ]

7
 1. 죽도록 싫은 SI 개발에 대한 소고

더욱 가관인것은 “나를 알고 적을 알면 위태롭지 않다”고 했는데도 “나를 모른다는 것”

전제 1. “ 우리팀은 100% 완벽하게 일하므로 WBS 대로만

현실 1. 버그 없는 개발자가 최고
하면 모든 프로젝트는 성공할 수 있다”

전제 2. “ 방법론만 제대로 지키면 모든 프로젝트는 성공할 현실 2. 아르미 방법론 III 의 공식산출물 150 종
수 있다” * 더 될지 모름 -_-;;

전제 3. “ 요구사항은 변화하지 않는다” 현실 3. 변화하지 않는 비즈니스는 없다

전제 4. “ 고객은 내편이다” 현실 4. 술 마실때 만 ...

전제 5. “ 나는 모든 프로젝트 상황을 통제하고 있다” 현실 5. 부하직원만 줘 패면서 method 위치도 모름

8
 1. 죽도록 싫은 SI 개발에 대한 소고

노병은 사라질 뿐

9
 2. 개발이 왜 싫어졌는지에 대한 물음

일반적인 SI 프로젝트에서 테스트는 항상 후순위로 Release 1~2 개월 전부터 Test 가 시작되며

개발자의 손을 떠나 오픈된 코드는 오류 , 요구사항 미충족 등의 문제가 매우 많이 발생

비용

일정도 얼마 안 남았는데 까보니 X 판

거의 전분야에서 재작업 투입
대표적사례 : 서울시 교통카드
안정화까지 L 사 전직원투입

일정
요구분석
설계 개발 테스트

10
 2. 개발이 왜 싫어졌는지에 대한 물음

대부분의 프로젝트 관리자는 방법론의 이정표와 현실의 이정표간의 GAP 을 인식하지 못함

목적지

내 위치를 정확히 아는
이론적 이상 경로

내가 어디 있는지 늦게 깨달았을 때
내가 틀렸음을 일찍 깨달았을 때

출발지

11
 2. 개발이 왜 싫어졌는지에 대한 물음

한국 특유의 “ SSKK” 문화 ( 시키면 시키는 대로 까라면 깐다 )

SSKK 바보개발자 양산

12
 2. 개발이 왜 싫어졌는지에 대한 물음

읽고 이해할 수도 없는 감리사와 PM 만 원하는 문서를 위한 프로젝트

•실재로 2004~2006 년까지 진행했던 H 대학 프로젝트의 산출물은 A4 바인더로 길이 4.5m 였었고 감리사 및 개발팀 어느 누구도
내용을 살펴 볼 수 없었음 .

13
 2. 개발이 왜 싫어졌는지에 대한 물음

처음에는 10 단어까지 들리지만 갈수록 알아 듣는 단어의 수가 줄어 들고 급기야 끝 없는 침묵과

오해와 자신의 목소리만 난무하는 현실

14
 2. 개발이 왜 싫어졌는지에 대한 물음

결국 우리는 “나를 아는 것” , “ 적 (?) 을 아는 것”에 실패하였음

1. 코드 작동이 늦어짐에 따른 고가의 비용지불

2. 정확한 나의 위치를 알 수 있는 방법의 부재

3. 바보 개발자의 양산으로 끝없는 품질하락 사고와 방법의 전환이 필요한 때

4. 프로젝트 후 산더미처럼 쌓여 있는 문서

5. 이해가 안되는 말만 오고 가고 있음

15
 3. 사람을 위한 개발의 노력

성공적인 프로젝트 수행 방법은 타 산업군에서 찾아야 함 ( 하늘아래 새로운 것은 없음 )

상세 SI SW 개발 건설 항공기
RFI - O O O
개발규격 X X O
RFP( 주요내용만 ) 개발요구조건 X X O
선행설계 X O O
테스트를 위한 프로토타잎
- X 조감도 (?)/ 모형 F-22/F-23 등 선행개발
개발
가격 O O O
상세요건 X O O
상세설계 X O O
본계약 ( 주요내용만 )
상세기능 X O O
상세조직 O O O
상세일정 O O O
요구분석 O O O
설계 O O O
구현 O O O
개발
테스트 △ △ O
변경 / 보완 X X O
반복개발 X X O
인수 - O O O

16
 3. 사람을 위한 개발의 노력

먼저 감리는 고객과의 합의를 가장 우선시하므로 “테일러링”내역을 만들어 문서부터 없애거나 통합

해야함

Source: 정보통신감리협회 교육자료 ( 정보통신부 고시 제 1999-104 호 )

17
 3. 사람을 위한 개발의 노력

과감한 문서 통합 및 온라인 공유기반의 Document System 을 구축하고 합의함

품질관리 HUDSON

범위 / 일정관리
TRAC-Wiki
비용관리

인력관리 TRAC-SVN

위험관리 TRAC-Issue Tracker

통합관리
UML-USE CASE
의사소통관리

형상관리 UML-Workflow

품질관리 UML-Class Diagram

고객합의
UML-Sequence
Diagram
일정 / 자원

측정목표 / 방법 Doxygen

18
 3. 사람을 위한 개발의 노력

각 개발프레임워크 요소별 사용은 다음과 같음

HUDSON

TRAC-Wiki

TRAC-SVN

TRAC-Issue Tracker

Star UML

MSWORD/EXCEL

Doxygen

19
 3. 사람을 위한 개발의 노력

성과평가 및 목표설정을 위한 성과평가회의는 통합 관리 개념으로 작성함

유저테스트 결과에 따라 품질관리 및 진척도 점검

공정 개선포인트 도출

범위 / 일정 / 자원 / 인원관리 도출

20
3. 사람을 위한 개발의 노력

이슈 및 위험 , 공정 관리

21
 3. 사람을 위한 개발의 노력

요구사항을 받으면서 USE CASE 에 표현하되 가능한 한글로 표현

USER TEST CASE

USER TEST CASE

USER TEST CASE

USER TEST CASE

USER TEST CASE

USER TEST CASE

* 해외 사업이었기 때문에 영문으로 되어 있는 부분을 양해하여 주십시오 .

22
 3. 사람을 위한 개발의 노력

Sensor Device 의 Activity Diagram 으로 Method 와 Entity 를 정의함

Method
Entity 는 따로 Memo 로 정리

Method

Method

23
 3. 사람을 위한 개발의 노력

Method 와 Entity 를 따로 Grouping 하여 Class Relation Diagram 을 그려서 개발자에게 전달함

24
 3. 사람을 위한 개발의 노력

상세내역은 Sequence Diagram 으로 정리

UNIT TEST CASE

25
 3. 사람을 위한 개발의 노력

고객과의 합의를 통해 진척도는 마일스톤으로 하고 기간은 성과평가회의때 설정하며 반복 개발

(Iteration Develop) 을 합의하였음

1 주 ~1.5 주

개발 및 테스트

1일

프로토타잎 및
요구분석설계 릴리즈
성과평가

1~2 주 2~3 일

추가 개선 있음

성과평가 / 개선요구 개발종료 및 최종보고

추가개선이 없음
Or
2~3 일 계약기간 만료

2주 2~3 주 X Iteration-n 끝
* 고객 / 개발자 프로세스교육 * Sprint 2 주 + 휴식 2~3 일

26
 3. 사람을 위한 개발의 노력

HUDSON 을 통해 Auto Build, Deploy, UNIT TEST 를 수행하여 매일 아침마다 그날 집중해야 할

일을 찾음

27
 3. 사람을 위한 개발의 노력

SOA 기반의 아키텍쳐 설계로 인해 SOAP Protocol 에 대한 인터페이스 / 성능 테스트를 자동 실행함

28
 3. 사람을 위한 개발의 노력

생성된 Code 는 매일 아침 Build 후에 API 문서를 자동으로 생성하도록 Doxygen 을 운용하였음

29
 3. 사람을 위한 개발의 노력

팀 빌딩을 위해 편견이 없는 인재와 같이 일하는 것이 좋았으며 프로토타잎 개발시 일찍 일을 마치고

퇴근하는 팀원에게 권한과 재량을 부여하였음

프로토타잎의 조직 본 개발에서의 조직

PM PM •팀원도 사람이므로 Performance 가 나오든

못나오든 차별없이 Communication 하는 것이
중요한듯

•커뮤니케이션을 잘하고 일찍 퇴근하는 팀원을

중심으로 설계에 참여시키고 “일찍 퇴근하기”
Leader 로써 활동하게함  업무 개선 담당
Member Member
•가장 중요한 것은 일찍 퇴근하기 운동에 대한
철저한 PM 의 약속이행이었음

•결과적으로 일이 없는 팀원은 오전 근무만 수행

 일이 없는 것은 PM 의 잘못이지 그 팀원의
잘못이 아니라는 Mind 중요

•대신 업무를 마치지 못한 팀원은 밤샘 , 휴일근무

지속

30
 3. 사람을 위한 개발의 노력

팀원과의 커뮤니케이션을 위해 매일 오전 9 시 30 분에 오늘 할 일에 대한 업무 공유 및 난상 토론후

회의록으로 정리함 . 일 이야기가 없다면 주식 , 부동산 , 취미등을 소재로 하고 가장 중요한 것은
“매일 얼굴을 맞대고 있는 같은 팀원”이라는 인식을 팀원에게 심어 줄 필요가 있음

•우리가 남이가 ? 의식 조성

31
 3. 사람을 위한 개발의 노력

잘 갈린 칼은 10 초 걸려서 자를 고기를 단 1 초에 자를 수 있음

32
 4. 남아 있는 문제들

에자일은 자동 만능 Tool 이 아니며 지속적으로 갈아서 쓰는 숯돌 같은 존재이며 정량적 공정

결과와 인간을 인간으로 만드는데 사용되어야 함

33
 4. 남아 있는 문제들

에자일의 과제는 한국의 감리 ( 할아버지 ) 에 맞추어 더 친절해질 필요가 있으며 아직 한국의 실무자
및 고객은 에자일의 업무 수행 방식을 모름

34
 4. 남아 있는 문제들

에자일은 아직 미성숙상태로 미정형되어 선택의 폭이 넓지만 역설적으로 복잡한 미로와 같음

35
 4. 남아 있는 문제들

결국 에자일 전문가가 해결 가능한 영역은 사람이었으며 따라서 , 어느 방법론보다 사람에 대한

기대치를 낮추고 그들과 커뮤니케이션 하기 위한 교육에 많은 공을 들여야 했음

36
FIN

감사합니다 .

37