XP 개발을 위한 개발 생산성 향상 파노라마

사실 빠르게 개발하는 것은 그리 어렵지 않지만 품질을 떨어뜨리지 않으면서 빠르게 개발하는 것은 다른 문제다. IT 업계에서 이리저리 치이고 상처가 훈장처럼 남을 즈음이면 패배주의, 냉소주의, 비관주의로 구성되는 3대 주의에 빠지게 된다. 어깨쪽지가 축 처진 개발자들에게 희망을 주는 장면은 많지 않다. 하지만 정말 그럴까? 5부에서는 몇 가지 장면 사례를 통해 빠른 개발을 위해 진정 필요한 것이 무엇인지 함께 고민하는 시간을 가져보자.

개발 생산성을 향상시킨다는 것은 한 가지를 잘 하고 못하는 것에 의해 좌우되는 것이 아니다. 지금까지 여러 필자와 함께 여러 가지 생산성 향상을 위한 방법들에 대해 알아보았다. 이번에는 생산성 향상을 위해 필요한 더욱 근본적인 사항들에 대해함께 생각해 보는 시간을 가져보자.

개발 생산성을 향상시킨다면 과연 얼마나 높일 수 있을까? 두 배? 열 배? 스무 배? 사람마다 개인차가 있듯이 어떤 시스템이나 프로세스를 도입한다고 해서 순식간에 개발 생산성이 높아지는 것은 아니다. 하지만, 복합적인 상황들이 작용하면 우리가 상상하기 힘들 만큼의 개발 생산성 향상 효과를 보기도 한다.

지금부터 보게 될 내용들은 모두 실화를 바탕으로 한 것으로 마치 다큐멘터리 드라마를 보는 듯한 착각이 들지도 모른다. 각 장면에 대해 번잡하고 너저분한 설명을 달지도 않을 것이다. 어차피 누군가 이렇게 하라고 설명한다고 해서 더 잘 받아들일 수 있는 것은 아닌 탓이다.

자 이제 필자가 준비한 열두 개의 장면 속으로 들어가 보자.

장면1 - 개발 생산성 200배 차이의 비밀

미국은 90년대부터 각 주마다 아동 복지 시스템(Statewide Automated Child Welfare Information System)을 개발하도록 했다. 지역이 다르더라도 시스템의 기본 요구사항은 모두 동일하다. 문제는 다음 예에서와 같이 플로리다와 미네소타의 시스템의 구성이 완전히 동일함에도 불구하고 결과는 놀라운 차이가 나타났다.

개발 기간은 둘째 치더라도 미네소타와 플로리다의 개발 비용차이만 200:1이 넘는다. 성공 요인은 뭘까? 최소화된 요구사항, 표준 인프라스트럭처의 활용(재사용으로 볼 수 있음), 적은 인원이지만 능력 있는 8명의 개발자. 특히 자기 아이를 잃은 어머니가 프로젝트에 관여를 했다고 한다. SACWIS에는 미아 찾기도 포함되어 있다.

프로그램은 공장에서 만드는 제화와 달라서 개발 생산성이 몇 배 수준에서 차이나고 마는 것이 아니라, 어떤 사람이 참여 했는가 혹은 어떤 시스템을 사용하고 어떠한 생각으로 프로젝트에 임하는가에 따라 엄청난 차이를 내게 마련이다.

장면2 - 2년보다 큰 일주일

국내 모 기업에서 20여 명의 인원이 투입되어 2년여의 시간동안 중요한 시스템을 개발해 오고 있었다. 시간이 지나도 일에 진척이 없자 한 사람의 외부 인력이 투입되었다. 그 사람이 밑바닥부터 시작하여 혼자서 그 시스템을 만드는데 걸린 시간은 일주일. 게다가 만들어진 최종 코드의 양은 A4 한 장에 불과했다.

이 개발자와 필자가 개인적인 친분이 있기에 이 내용에 대해 상세히 알고 있다. 이 개발자는 어떻게 스무 명의 인원이 2년이라는 긴 시간 동안 해결하지 못한 문제를 일주일 만에 해결한 것일까? 그 해답은 최소화된 요구사항과 개발자의 뛰어난 능력 그리고 적절한 개발환경과 언어의 선택에서 찾아야 할 것이다.

최고의 프로그래머는 최악의 프로그래머보다 생산성이 약 10배에서 30배 더 뛰어나다. 중간쯤 되는 프로그래머와 비교하면2.5배 정도 뛰어나다. 이 수치들은 연구 방법이나 조건에 따라 약간씩 다르긴 하지만 프로그래머 간의 실력 차이가 엄청나다는 사실만은 분명하다.

흥미롭게도 경력이나 연차는 생산성과 상관성이 없었다. 2년차 프로그래머가 10년차보다 나은 경우도 많다는 뜻이다.

장면3 - 1,200배가 넘는 개발 생산성의 차이

대략 9,000여개의 프로젝트를 분석해 보았더니, 생산성이 가장 낮은 프로젝트는 0.13 FP/SM(staff month 당 functionpoint)인 반면 가장 높은 프로젝트는 165 FP/SM이었다. 1,200배가 넘는 차이다.

역사상 가장 생산적인 팀 중 하나였던 윈도우용 볼랜드 쿼트로프로 개발팀은 그 생산성이 업계 평균에 비해 최소 20배가 넘었다. 숫자로만 이야기한다면, 같은 숫자의 사람들로 20년 걸리는일을 이 사람들은 1년이면 할 수 있었다는 말이 된다.

이들의 성공 요인은 제임스 코플리엔(James Coplien)의Borland Software Craftsmanship: A New Look at Process,Quality and Productivity란 논문과 Organizational Patterns

of Agile Software Development란 책에 자세히 기술되어 있으니 참고하자.

장면4 - 소프트웨어의 결함을 줄이는 최고의 방법

대략 5만여 개 IT 프로젝트에 대한 누적 통계 자료를 갖고 매년 추가 보고서를 내고 있는 스탠디쉬 그룹(Standish Group)의 카오스 보고서에서는 IT 프로젝트의 평균 성공률을 34% 정도라고 말한다.

그나마 1995에 16%에 불과하던 성공률이 해를 더하면서 약간씩 높아진 것이다. 하지만“저는 10명 중 3명만 성공시켜요”라고 말하는 외과의사에게 누가 몸을 맡기겠는가 하는 생각에 다다르면 「우리가 정말 전문직(profession)을 가진 사람인가」하는 반문을 하게 된다.

흥미롭게도 이 통계자료를 프로젝트 크기별로 그룹을 지어서 다시 계산하면 어떤 패턴이 보인다. 일반적으로 작은 프로젝트성공률은 큰 것의 3배가 넘는다. 예를 들어 6명이 6개월 일하는 프로젝트의 성공률은 50%가 넘는 반면, 500명 이상이 36개월 이상 일하는 비싼 프로젝트의 성공률은 0%이고, 250명 이상, 24개월 이상의 프로젝트는 8%의 성공률을 갖는다.

또 다른 케이스 스터디에서는 프로젝트 크기가 증가함에 따라 결함 수는 비선형적으로 증가함을 발견했다. 소프트웨어 공학에서 널리 알려진 진실 중 하나는, 결함을 줄이는 최고의 방법은 전체 라인수를 줄이는 것이라는 사실이다.

장면5 - 프로젝트의 크기는 어떻게 정해지는가?

200명이 참가하는 프로젝트라면 무조건 큰 프로젝트일까? 200명이 모여서 5년 걸려야만 되는 일을, XP로 10명이 1년 만에 해치웠다고 치자. 이 프로젝트는 큰 프로젝트인가 아닌가? 같은 문제를 보고 서로 다른 해결안을 내었는데 두 해결안의 복잡도가 다르다. 그렇다면 두 프로젝트의 크기는 다른가 같은가?

여기에서 우리가 알아야 할 것은 「문제의 복잡도(Problem Complexity)와 해결책의 복잡도(Solution Complexity)는 다를 수 있다」는 사실이다.

카오스 보고서에서 우리가 발견할 수 있는 것은 프로젝트 규모가 클수록 프로젝트의 실패확률은 엄청나게 높아진다는 사실이다. 만약 우리가 해결책의 복잡도를 줄일 수 있다면 어떻게 될까? 필요한 참여 인원 숫자를 줄일 수 있다면? 동시에 성공확률도 높아질 수 있는 건 아닐까?

장면6 - 비즈니스 유닛 최악에서 최고로의 변신

마이크로소프트(이하 MS)의 XIT Sustained Engineering 팀은 MS의 80여개의 애플리케이션을 유지 보수한다. 주로 버그 수정(작업 시간이 120시간 미만인 것들) 같은 작은 변경 요청을 처리하는데, 하나의 변경 요청이 처리되기까지 걸리는 시간(리드타임)이 통상 5개월이었다. 해당 팀은 비즈니스 유닛에서 최악의 퍼포먼스를 차지한 셈이다.

그런데, 새로운 자원을 추가하지 않고, 기존의 설계, 코딩, 테스팅 등의 엔지니어링 작업 방식에 변화를 주지 않으면서 어떻게 작업이 쌓이고(queue) 추정하는지를 바꾸는 것만으로 9개월 만에 리드타임을 14일로 줄였다. 아무리 긴 변경 요청도 5주를 넘지 않았다. 납기일을 맞추는 확률은 이전의 0%에서 90%가 넘는 수치로 바뀌었다.

이제 이 팀은 해당 유닛에서 최고의 팀으로 바뀌었다. 최악에서 최고로.

이 사례의 성공요인은 린(Lean)과 제약이론 그리고 애자일 원리를 적용한 데서 찾을 수 있다.

장면7 - 일당백의 개발자

Smalltalk-80이라는 기념비적 책을 집필하고 PC 매거진에서평생 공로상(Lifetime Achievement Award)을 수상한 아델 골드버그(Adele Goldberg)는 2002년도에 파이썬, 조프(zope), 플래시, 스몰토크를 약간씩 섞어 사용해서 높은 품질의 온라인 교육 사이트(Learning Management Production Systems)를 만들었다.

전체 시스템은 아델과 파트타임 플래시 프로그래머 두 사람이 4개월가량 걸려서 만들었다. 놀라운 점은 프로젝트를 시작할 당시에 파이썬이나 조프에 대한 사전 지식이 전혀 없는 상태였다는 사실이다. 이 시스템은 교육 자료를 만들 수 있는 저작 시스템(authoring system)과 학생 관리를 포함한 교수 시스템, 학생이 운영하는 학습 시스템 등을 모두 포함한다.

장면8 - 스크린캐스트의 함정

Ruby on Rails(이하 RoR)를 필두로 해서, 자기 라이브러리, 프레임워크의 우수함을 스크린캐스트(컴퓨터 화면에서 벌어지는 것을 동영상으로 녹화해 배포한 것, 혹은 그 행위)하는 유행이 생겼다.

http://www.rubyonrails.org/screencasts

특히 RoR의 15분 만에 블로그 만들기는 새로운 웹 프레임워크가 보여줘야 할 것의 최소선이 되어 버리기도 했다. 이 스크린캐스트가 나올 때만 해도 자바 프로그래머들에겐 이런 것이 가능하다는 것 자체가 하나의 충격이었다. RoR은 소프트웨어 개발시간 t를 0에 가깝게 가져갈 수 있으며, 이로 인해 소프트웨어 시장과 사회 구조의 변화를 불러올 수 있다는 말까지 나오게 되기도 했다.

그런데 N분만에 뭔가를 해낸다는 것은 사기일 여지가 무척 높다. 라이브러리, 프레임워크 안에 이미 만들어 놓은 기능들을 정해진 각본대로 이용한다면 개발 시간을 줄이는 것은 별 문제가 아닐 것이기 때문이다.

극단적인 예가 최근 공개된 httpy 스크린캐스트이다. 20초 만에 위키위키 사이트를 만들어버린다. 그 비결은? 로컬 호스트에 들어오는 HTTP 요청을 http://c2.com으로 연결시키는 코드를 만드는 것이다. 정말 약았다. 위키를 만든다는 조건과, 최소 시간 안에 만든다는 조건 하에서는 정말 이런 각본이 나올 수도 있는 것이다.

우리는 짜고 치는 고스톱 스크린캐스트를 보면서 한편으로는 비웃지만 또 한편으로는 수긍할 수밖에 없다. 게임의 룰을 어기고 새로운 게임을 만들어 내는 플레이어가 언제나 시장에 나타날수 있으며 심판이 어떻게 판결을 내건 진정한 승자는 무조건 「이기는 사람」이기 때문이다.

장면9 - 라이브러리 사용의 중요성

작년에 OOPSLA 2005에서는 Working with Vision:Scrapheap Challenge - a workshop in post-modern programming 이라는 매우 흥미로운 세션이 열렸다. http://www.

postmodernprogramming.org/scrapheap 포스트모던 프로그래밍이라니 뭔가 심오해 보이지 않는가?

포스트모던 프로그래밍(http://postmodernprogramming.org/)이란 이름은 제임스 노블(James Noble)과 로버트 비들(Robert Biddle) 교수가 2002년에 유행시킨 용어다(논문 제목이 Notes on Postmodern Programming이고, 그 이후에 또 다른 논문을 발표했는데 그 이름은 Notes on Notes on PostmodernProgrmming이었다).

논문의 요지는 이제까지 소프트웨어 개발은 모더니즘의 시각으로 주도되어 왔는데, 거기에서는 시스템이 균등한 컴포넌트들로 구성되고, 또 그 구성 역시 동일하고 단순한 방법으로 이루어진다는 것이다.

반면, 최근 일어나기 시작한 포스트모더니즘적 시각은 소프트웨어는 매우 다양한 요소들을 또 매우 다양한 방법으로 붙여서 결합한 시스템(예컨대 펄이나 유닉스)이며, 또 그것이 그리 나쁜 게 아니라는 것이다. 어떤 이는 이런 방식을 큰 양동이의 풀(glue)이라고 비유한다(큰 진흙덩어리 Big Ball of Mud에 대한 패러디).

동저자의 연구 결과 OOP 소프트웨어의 클래스들 간에는 척도 없는(scale-free) 네트워크가 성립하며, 기존의 균질적인 요소들의 조립인 레고 블럭 비유는 성립하지 않는다고 결론 내렸다.

그 두 사람의 논문에서 소개된「scrap heap programming」이라는 개념 하에 진행된 이 세션은, 진행자가 어떤 소프트웨어 요구사항을 주면 참가자들이 팀을 이뤄 그 소프트웨어를 개발하는 것이다. 여기까지는 일반 컨테스트와 매우 유사하다. 그런데 순진하게 접근했다가는 절대 제 시간 안에 프로그램을 만들지 못한다.

이 컨테스트에서는 공개되어 있는 웹서비스(예컨대 구글API 등)와 프레임워크, 라이브러리를 적극적으로 사용하라고 격려한다. 재사용성을 극대화해보는 것이다. 직접 작성하는 코드는 극히 부분적이며 여러 이질적 요소를 접착해 주는 풀의 역할을 한다. 덕분에 상상도 할 수 없는 적은 노력으로 썩 괜찮은 소프트웨어를 만들 수 있다. 아니, 조립해 낼 수 있다고 해야 할까.

제목에서도 그런 함의를 드러내고 있다. Scrapheap Challenge라는 것은 쓰레기 뭉치로 뭔가 만들어 낸다는 말이다(진짜 쓰레기와 잡동사니로 하는 동명의 대회가 있다 http:// www.channel4.com/science/microsites/S/scrapheap/).

이 대회가 개발자들에게 충격을 주고, 또 지금의 시류와도 너무 잘 들어맞아서인지, 구글에서는 사내에서 이 대회를 작년 크리스마스 직전에 치렀다고 한다(http://www.postmodern programming.org/scrapheap/google).

장면10 - 짝 프로그래밍의 비밀

실버 플래터 소프트웨어(Silver Platter Software)란 회사에서 재미있는 논문을 발표했다. 「Promiscuous Pairing andBeginner」s Mind」란 글이다. 번역하자면 「빈번한 짝교환과 초심」정도 되겠다.

그 회사에서는 다양한 방식으로 짝 프로그래밍을 실험하면서 팀의 개발속도(한 이터레이션에 얼마만큼의 일을 했는가 하는 생산성 지표)의 변화를 추적했다.

하루 종일 한 번도 짝을 바꾸지 않은 기간과 90분 정도마다 짝을 바꾼 기간을 비교해 보면 후자가 전자에 비해 팀 전체 속도는 두 배 이상 높았다.

또한, 일을 개발자들에게 나누어 줄 때, 세 가지 다른 방법으로 실험해 보았는데(모두 짝 프로그래밍과 병행), 하나는 가장 적합한 사람(most qualified person)에게 일을 주는 것, 또 하나는 능력에 상관없이 일을 주는 것, 마지막은 가장 부적합한 사람(leastqualified person)에게 일을 주는 것이었다.

각 방식으로 몇 이터레이션을 반복해 보았는데, 팀 속도가 가장 높아지는 시점은 마지막 방법, 즉, 가장 그 일을 하기에 부적합한 사람에게 일을 맡긴 경우였다. 동시에 버그 개수나, 필요한 리펙토링의 양 등으로 코드 품질 면에서도 마지막 방식이 최고의 성과를 보였다.

장면11 - 도메인 특정 언어의 힘

도메인 특정 언어에 대해 알아보기에 앞서 우선 다음 코드를 살펴보자.

Calendar calendar = Calendar.getInstance();

calendar.setTimeZone(TimeZone.getTimeZone(“Universal”);

calendar.set(Calendar.DATE, 5);

calendar.set(Calendar.MONTH, 3 - 1);

calendar.set(Calendar.YEAR, 2004);

Date march5_2004 = calendar.getTime();

다음 코드와 비교해 보라.

TimePoint march5_2003 = CalendarDate.date(2004, 03, 5);

이번에는 다음 코드를...

class Invoice {

Date dueDate;

int gracePeriodInDays;

boolean isDelinquent(Date currentDate) {

Calendar calendar = Calendar.getInstance();

calendar.setTime(dueDate);

calendar.add(Calendar.DATE, gracePeriodInDays);

delinquencyDate = calendar.getTime();

return currentDate.after(delinquencyDate);

}

}

이 코드와 비교하면?

class Invoice {

TimePoint due;

Duration gracePeriod;

boolean isDelinquent(TimePoint now) {

return now.isAfter(due.plus(gracePeriod));

}

}

지불은 작업이 끝난 달의 마지막 날에서 30일 후 이루어진다는 정보를 어떻게 코드로 표현할까? java.util.Calendar를 이용하면 절대 쉽지 않은 일이다. 하지만 다음을 보자.

CalendarDate dueDate(CalendarDate workEndDate, intallowableDays) {

return workEndDate.month().end().plusDays(allowableDays);

}

리팩토링의 마틴 파울러(Martin Fowler)와 Domain DrivenDesign의 에릭 에반스(Eric Evans)가 뭉쳐서 나온 라이브러리다. 이름하여 Time and Money Code Library(http://timeandmoney.sourceforge.net). 구글의 그레거 호프(GregorHohpe) 같은 아키텍트는 이 라이브러리에 대해 찬사를 보낸다.

http://www.eaipatterns.com/ramblings/40_marchnan.html 도메인 특정 언어(Domain Specific Language), 특히 이 경우는 내장 도메인 특정 언어(Embedded DSL, 줄여서 EDSL)의 힘이 얼마나 센지 보여주는 좋은 예라 하겠다.

장면 12 - EDSL

스테픈 테일러(Stephen Taylor)는 APL 프로그래머이다. 그는 최근 XP와 APL의 교집합을 찾고 있다. 최근 발표한 「Software Development as a Collaborative Writing Project」라는 논문은 고객과 개발자가 짝 프로그래밍을 하는 신기한 사례를 말하고 있다.

고객이 바로 옆에 앉아서 문제를 설명하는 속도로 프로그래밍이 되며, 심지어 고객 자신도 프로그래밍을 할 수 있다. EDSL(Embedded Domain Specific Language)의 덕분이다.

개발 속도? 문제 설명의 속도가 바로 개발의 속도가 된다.

인력이 아닌 상상력의 빈곤을 탓하라

필자는 종종 「상상력의 빈곤」이란 말을 하곤 한다. 사람들은「우리는 인력이 부족해」라는 말을 쉽게 뱉는다. 그 말은 모든 다른 문제를 탈색시켜 버리는 강력한 효과가 있다. 「입 다물어」가되는 셈이다. 인력이 부족하다고 말하는 순간 더 이상 논의가 필요 없게 되는 것이다. 필자는 그 이면에 우선 상상력의 빈곤이 자리 잡고 있다고 본다.

필자가 한국 XP 사용자 모임(http://xper.org)에 썼던 글을 인용하면서 글을 마치겠다.

● 인용 1 - 생각이 바뀌면 모든 것이 바뀐다

엘런 케이(Alan Kay)가 이반 서덜랜드(IvanSutherland)에게 물었다. “도대체 어떻게 당신 혼자서 일 년 만에 컴퓨터 그래픽을 발명해 내고, 첫 번째 객체 지향 소프트웨어 시스템을 만들고, 또 최초로 실시간 제약 해결 엔진까지 만들 수 있었나요?” 그러자 이반이 대답했다. “그게 어렵다는 걸 몰랐거든요.”-앨런 케이가 이반 서덜랜드에 대해

참고로, 서덜랜드의 스케치 패드(Sketch Pad)는 새벽 3시에서 6시까지 하루 세 시간씩(나머지 시간은 군사용으로 사용되던 시스템이었음) 개발하여 일 년 만에 완성되었다. 앨런 케이는 그의 논문을 전산학을 통틀어 가장 위대한 박사학위 논문이라고 일컬으며 뉴턴의 업적에 비견했다.

● 인용 2 - 반으로 줄여보라

쿄세라의 명예회장 이나모리 카즈오씨의 저서「경제학」에는 마츠시타 코노스케씨가 했던 말이 실려 있다.“ 30% 절감하기란 쉬운 일이 아니다. 그렇다면 반으로 줄이면 어떨까 생각해 보라. 30% 절감을 생각하기 때문에 자잘한 것까지 들쑤시려고 생각하고 있는 건지도 모른다. 그러나 반으로 줄인다고 생각하면근본부터 다시 생각하지 않으면 안 된다. 그러니 오히려 더 편한 것이다”

도요타사에서 근무하던 시절에 필자는 오노 다이이치 씨로부터 자주 “0을 하나 줄여라” 또는 “만 엔으로 해보라”는 지시를 받았다. -「도요타식 최강의 사원 만들기」에서 인용

국내 모 대기업의 회장도 10% 개선은 어려우나 100% 개선은 쉽다는 맥락의 이야기를 한 것으로 안다. 작은 개선을 생각하려고 하면 일단 주어진 패러다임 내에서 쥐어짜는 법을 생각하게 된다.

하지만 일견 터무니없어 보이는 개선을 생각하면 종종 기존의 패러다임을 벗어날 수 있다. 알고리즘적으로 말하자면 O(N)에서 O(log N)이 될 수도 있는 것이다. 한번은 아내에게 수학 문제를 내어줬는데 끙끙대며 고생을 했다. 그런데 “그 문제 쉬워”라고 말해주니 그냥 순식간에 풀어버리는 것이었다.

대부분 개인과 조직의 정체는 상상력의 빈곤과 고갈에서 시작된다. 일단 이것이 문제가 되면 기술력이나 경험과 지식도 별로 도움이 되지 못한다. 아니 어설픈 지식은 오히려 장애가 되기도 한다. 하지만 상상력의 한계가 없는 사람과 조직은 어떻게든 계속 발전할 수 있다.

종종 나이브(Naive)한 사람들이 엄청난 발전을 하는 경우를 본다. 패배주의와 냉소주의에 찌들지 않은 생생하고 펄떡이는 상상력을 갖고 있어서라고 생각한다. @

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.