= 장면 1 =
미국에서 주마다 아동 복지 시스템(Statewide Automated Child Welfare Information System)을 개발하도록 했다. 시스템의 기본 요구사항은 모두 동일하다. 플로리다와 미네소타의 시스템을 비교해 보면, 두 개가 기본적으로 완전히 동일하다는 점을 제외하면, 놀라운 차이점이 있다.
플로리다의 경우:
시작:
- 1990년에 프로젝트 시작
- 처음엔 프로젝트 비용을 3천2백만불로 추정
- 1998년에 완료할 것으로 계획
- 109명이 참여
- 지금까지 1억7천만불 투입
- 전체 비용이 2억3천만불이 될 것으로 재조정
- 2005년도에 완료할 것으로 계획수정
- 3명의 IBM 컨설턴트 추가 참여 (프로젝트 매니져, 프로젝트 아키텍트, 프로젝트 애널리스트)
미네소타의 경우:
시작:
- 1999년에 프로젝트 시작
- 99년 9월에 1차 단계 완료 및 2000년 중반에 2차 단계 완료 계획
- 비용으로 백십만불 추정
현상황:
- 2000년 초에 완료했음
- 8명 참여
- 백십만불 사용
생산성 차이로 따지면 미네소타와 플로리다는 200:1이 넘는다.
= 장면 2 =
국내 모 기업에서 20여명이 2여년에 걸쳐 "심각한" 시스템을 개발해오고 있었다. 그러다가 중도에 외부인력이 한명 투입되었다. 그 사람은 일주일만에, 밑바닥부터, 그리고 혼자서 그 시스템을 만들어 버린다. 그 사람이 만든 최종 코드의 양은? A4 한장.
= 장면 3 =
최고의 프로그래머는 최악의 프로그래머보다 생산성이 약 10배에서 30배 더 뛰어나다. 중간쯤 되는 프로그래머에 비교하면 2.5배 정도 뛰어나다. 이 수치들은 연구에 따라 약간씩 다르긴 하지만 프로그래머간의 실력 차이가 엄청나다는 점은 거의 동일하다. 흥미롭게도 경력년차는 생산성과 상관성이 없었다. 2년차 프로그래머가 10년차보다 나은 경우도 많다는 말이다.
= 장면 4 =
대략 9000여개의 프로젝트를 분석해 보았더니, 생산성이 가장 낮은 프로젝트는 0.13 FP/SM(staff month 당 function point)인 반면 가장 높은 프로젝트는 165 FP/SM였다.
역사상 가장 생산적인 팀 중 하나였던 윈도우용 볼랜드 쿼트로 프로 개발팀은 그 생산성이 업계 평균에 비해 최소 20배가 넘었다. 숫자로만 이야기한다면, 같은 숫자의 사람들로 20년 걸리는 일을 이 사람들은 1년이면 할 수 있었다는 말이 된다.
= 장면 5 =
대략 5만여개 IT 프로젝트에 대한 누적 통계 자료를 갖고 매년 추가 보고서를 내고 있는 스탠디쉬 그룹(Standish Group)의 카오스 보고서에서는 IT 프로젝트의 평균 성공률을 34% 정도라고 말한다. 해가 가면서 이 수치는 높아지기는 했다 -- 1995년도에는 16% 근방이었다. 하지만 "저는 10명 중 3명만 성공시켜요"라고 말하는 외과의사에게 누가 몸을 맡기겠는가 하는 생각에 다다르면 우리가 전문직(profession)을 가진 사람인가 반문하게 된다.
흥미롭게도 이 통계자료를 프로젝트 크기별로 그룹을 지어서 다시 계산하면 어떤 패턴이 보인다. 일반적으로 작은 프로젝트 성공률은 큰 것의 3배가 넘는다. 예를 들어 6명이 6개월 일하는 프로젝트의 성공률은 50%가 넘는 반면, 500명 이상이 36개월 이상 일하는 "비싼" 프로젝트는 성공률이 0%이고, 250명 이상, 24개월 이상의 프로젝트는 8%의 성공률을 갖는다.
또 다른 케이스 스터디에서는 프로젝트 크기가 증가함에 따라 결함 수는 비선형적으로 증가함을 발견했다. 소프트웨어 공학에 널리 알려진 진실 중 하나는, 결함을 줄이는 최고의 방법은 전체 라인수를 줄이는 것이라는 사실이다.
= 장면 6 =
프로젝트의 크기는 어떻게 정해지는가?
200명이 참가하면 다 큰 프로젝트인가? 200명이 모여서 5년 걸려야만 되는 일을, XP로 10명이 1년만에 해치웠다고 치자. 이 프로젝트는 큰 프로젝트인가 아닌가? 같은 문제를 보고 서로 다른 해결안을 내었는데, 두 해결안의 복잡도가 다르다. 그렇다면 두 프로젝트의 크기는 다른가 같은가?
문제의 복잡도(Problem Complexity)와 해결책의 복잡도(Solution Complexity)는 다를 수 있다.
카오스 보고서에서 우리가 발견할 수 있는 것은 프로젝트 규모가 클수록 프로젝트의 실패확률은 엄청나게 높아진다는 것이다. 만약 우리가 해결책의 복잡도를 줄일 수 있다면? 필요한 참여인원 숫자를 줄일 수 있다면? 동시에 성공확률도 높아질 수 있는 건 아닐까?
= 장면 7 =
마이크로소프트의 XIT Sustained Engineering 팀은 MS의 80여개의 애플리케이션을 유지보수한다. 버그 수정(작업 시간이 120시간 미만인 것들) 같은 작은 변경 요청을 처리하는데, 하나의 변경요청이 처리되기까지 걸리는 시간(리드타임)이 통상 5개월이었다. 해당 팀은 비즈니스 유닛에서 최악의 퍼포먼스를 차지했다.
그런데, 새로운 자원을 추가하지 않고, 기존의 설계, 코딩, 테스팅 등의 엔지니어링 작업의 방식에 변화를 주지 않으면서 어떻게 작업이 쌓이고(queue) 추정하는지를 바꾸는 것만으로 9개월만에 리드타임이 14일로 줄었다. 아무리 긴 변경요청도 5주를 넘지 않았다. 납기일을 맞추는 확률은 이전의 0%에서 90%가 넘는 수치로 바뀌었다. 이제 이 팀은 해당 유닛에서 최고의 팀으로 바뀌었다. 최악에서 최고로.
= 장면 8 =
Smalltalk-80이라는 기념비적 책을 집필하고 PC 매거진에게서 평생 공로상(Lifetime Achievement Award)을 수상한 아델 골드버그(Adele Goldberg)는 2002년도에 파이썬, 조프(zope), 플래시, 스몰토크를 약간씩 섞어 사용해서 높은 품질의 온라인 교육 사이트(Learning Management Production Systems)를 만들었다. 전체 시스템은 아델과 파트타임 플래시 프로그래머 두 사람이 4개월 가량 걸려서 만들었는데, 파이썬이나 조프에 대한 사전지식이 전혀 없는 상태에서 시작했다. 이 시스템은 교육 자료를 만들 수 있는 저작 시스템(authoring system)과 학생 관리를 포함한 교수 시스템, 학생이 운영하는 학습 시스템 등을 모두 포함한다. 일당백의 예.
= 장면 11 =
실버 플래터 소프트웨어(Silver Platter Software)란 회사에서 재미있는 논문을 발표했다. "Promiscuous Pairing and Beginner's Mind"란 글이다. 번역하자면 "빈번한 짝교환과 초심" 정도 되겠다.
그 회사에서는 다양한 방식으로 짝 프로그래밍을 실험하면서 팀 속도(한 이터레이션에 얼마만큼의 일을 했는가 하는 생산성 지표)의 변화를 추적했다.
하루 종일 한번도 짝을 바꾸지 않은 기간과 90분 정도마다 짝을 바꾼 기간을 비교해 보면 후자가 전자에 비해 팀 전체 속도는 2배 이상 높았다.
또한, 일을 개발자들에게 나누어 줄 때, 세가지 다른 방법으로 실험해 보았는데(모두 짝 프로그래밍과 병행), 하나는 가장 적합한 사람(most qualified person)에게 일을 주는 것, 또 하나는 능력에 상관없이 일을 주는 것, 마지막은 가장 부적합한 사람(least qualified person)에게 일을 주는 것이었다. 각 방식으로 몇 이터레이션을 반복해 보았는데, 팀 속도가 가장 높아지는 시점은 마지막 방법, 즉, 가장 그 일을 하기에 부적합한 사람에게 일을 맡긴 경우였다. 동시에 버그 개수나, 필요한 리팩토링의 양 등으로 코드 품질면에서 따져도 마지막 방식이 최고의 성과를 보였다.
= 장면 13 =
스테픈 테일러(Stephen Taylor)는 APL 프로그래머이다. 그는 최근 XP와 APL의 교집합을 찾고 있다. 최근 발표한 "Software Development as a Collaborative Writing Project"라는 논문은 고객과 개발자가 짝 프로그래밍을 하는 신기한 사례를 말하고 있다. 고객이 바로 옆에 앉아서 문제를 설명하는 속도로 프로그래밍이 되며, 심지어 고객 자신도 프로그래밍을 할 수 있다. EDSL의 덕분이다.
개발 속도? 문제 설명의 속도가 바로 개발의 속도가 된다.
= 장면 14 =
필자는 "상상력의 빈곤"이란 말을 종종 한다.사람들은 "우리는 인력이 부족해"라는 말을 쉽게 뱉는다. 그 말은 모든 다른 문제를 탈색시켜 버리는 강력한 효과가 있다. "입 다물어"가 되는 셈이다. 더 이상 논의가 필요 없게 된다. 필자는 그 이면에 우선 상상력의 빈곤이 자리잡고 있다고 본다.
필자가 한국 XP 사용자 모임(http://xper.org)에 썼던 글을 인용하면서 글을 마치겠다.
상상력의 빈곤 : 상상할 수 있는 힘이 모자라다.
- 이런 것은 테스트할 수 없을거야.
- 이 난잡한 코드를 어떻게 무슨 수로 다듬어? 그냥 이렇게 사는거지.
- 원래 비지니스 모델 자체가 복잡하기 때문에 이 의존성들은 더이상 깔끔해질 수 없어.
- 이런식으로 처음부터 퍼포먼스 고려 안하고 코딩하면 서버 올리고 10초만에 다운될걸?
- 이런 일은 여러명이 협력해서 할 수 없을거야.
- 내가 저 사람이랑 같이 일해서 도대체 무슨 시너지와 윈윈이 있을까.
- 우리 시스템의 결함 발생 비율을 100개 이하로 줄인다니 그건 불가능해
- 이 코드 한번 빌드하는데 4시간이 넘는데 어쩌라고.
- 이런 일은 한 달은 족히 걸리는 일이야, 절대 그 이하로는 못하지.
- 고객이랑은 뺏느냐 뺏기느냐 생존 경쟁일 뿐이야.
- 이 일은 절대 자동화 할 수 없어. 그저 사람을 이용해 반복적로만 할 수 있을뿐.
저는 한번은 이반에게 물었습니다. "도대체 어떻게 당신 혼자서 일년만에 컴퓨터 그래픽을 발명해 내고, 첫번째 객체 지향 소프트웨어 시스템을 만들고, 또 최초로 실시간 제약 해결 엔진을 만들 수 있었나요?" 그러자 이반이 답했습니다. "그게 어렵다는 걸 몰랐거든요." --앨런 케이(Alan Kay)가 이반 서덜랜드(IvanSutherland)에 대해
(참고로, 서덜랜드의 Sketch Pad는 대략 일년에 걸쳐(새벽 3시에서 6시까지 -- 나머지 시간은 군사용으로 사용되던 시스템이었음) 개발 되었다. 앨런 케이는 그의 논문을 전산학을 통틀어 가장 위대한 박사학위 논문이라고 일컬으며, 뉴턴의 업적에 비견한다.)
쿄세라의 명예회장 이나모리 카즈오씨의 저서 "경제학"에는 마츠시타 코노스케씨가 했던 말이 실려 있다.
"30% 절감하기란 쉬운 일이 아니다. 그렇다면 반으로 줄이면 어떨까 생각해 보라. 30% 절감을 생각하기 때문에 자잘한 것까지 들쑤시려고 생각하고 있는 건지도 모른다. 그러나 반으로 줄인다고 생각하면 근본부터 다시 생각하지 않으면 안 된다. 그러니 오히려 더 편한 것이다"
도요타 사에서 근무하던 시절에 필자는 오노 다이이치씨로부터 자주 "0을 하나 줄여라" 또는 "만 엔으로 해보라"는 지시를 받았다. --"도요타식 최강의 사원 만들기"에서 인용
국내 모 대기업의 회장도 10% 개선은 어려우나 100% 개선은 쉽다는 맥락의 이야기를 한 것으로 안다. 작은 개선을 생각하려고 하면 일단 주어진 패러다임 내에서 쥐어짜는 법을 생각하게 된다. 하지만 일견 터무니없어 보이는 개선을 생각하면 종종 기존의 패러다임을 벗어날 수 있다. 알고리즘적으로 말하자면 O(N)에서 O(log N)이 될 수도 있는 것이다. 한번은 아내에게 수학 문제를 내어줬는데 끙끙대며 고생을 했다. "그 문제 쉬워"라고 말해주니 그냥 순식간에 풀어버렸다.
대부분 개인과 조직의 정체는 상상력의 빈곤, 고갈에서 시작된다. 일단 이것이 문제가 되면 기술력이나 경험과 지식도 별 도움이 되지 못한다 -- 아니 오히려 장애가 되기도 한다. 하지만 상상력의 한계가 없는 사람과 조직은 어떻게든 계속 발전할 수 있다. 종종 나이브한 사람들이 엄청난 발전을 하는 경우를 본다. 패배주의와 냉소주의에 찌들지 않은 생생하고 펄떡이는 상상력을 갖고 있어서라고 생각한다.
--김창준
'LIFE' 카테고리의 다른 글
| Life is.. (0) | 2007.01.06 |
|---|---|
| Ugly Christmas Happy New Year (0) | 2006.12.25 |
| 나의 2007년도 토정비결... 올려도 되는걸까? :) (0) | 2006.12.06 |
| 비가오네? (0) | 2006.11.06 |
| 끝내 몸살이 나고 말았다.. ㅠ.ㅠ (0) | 2006.11.01 |
