이 글은 익스트림 프로그래밍 2판(변화를 포용하라)의 저자인 XP선구자 켄트 벡의 XP 창조에 대한 이야기 입니다.


17 장 창조이야기


인기 있는 아이디어에는 그것이 어떻게 시작되었는지에 대한 이야기가 따라 나온다. 이런 이야기는 그 아이디어를 쉽게 머릿속에 붙들어 맬 수 있도록 도우며, 듣는 사람이 더 쉽게 이해할 수 있도록 아이디어를 그것이 만들어진 상황과 함께 전달하는 기능을 한다. 다음은 XP의 시작에 대한 내 이야기다.

모든 것은 전화 한 통으로 시작되었다. "크라이슬러의 급여 지급 시스템에 성능 문제가 있는데 한번 오셔서 봐주시겠습니까?" 나는 스몰토크 프로그램의 성능 개선에 대한 글도 쓰고 강의도 한 적이 있었으므로, 그런 전화를 받는 것은 그리 놀랄 일이 아니었다. 나를 약간 놀라게 만든 것은 내가 던진 선별질문 가운데 몇 개에 대한 대답이었다. 그 중 특히 하나가 내 귀에 오래 남았다.


켄트 벡 : "내가 변경을 가했을 때 그 변경이 아무것도 망가뜨리지 않았나 확인하게 해줄 테스트들이 있습니까?"


크라이슬러 : "사실 시스템이 정확한 급여를 아직 계산하지 못한답니다."


정확한 결과를 계산할 필요가 없다면야, 얼마나 빠른 시스템을 요구하든 원하는 대로 만들어 들릴 수 있다. 나는 단지 성능 개선 문제 외에 더 큰 문제가 있다는 냄새를 맡기에 충분한 컨설팅 경험이 있었다. 호기심이 생겼기 때문에, 가보기로 결심 했다.

나는 1996년 (부활절 즈음의) 참회 화요일에 그곳으로 갔다. 날짜를 이렇게 정확히 기억하는 까닭은 나와 그 팀이 오직 참회 화요일에만 굽는 폴란드 젤리 도넛인 'paczkis' 를 먹었기 때문이다.

나는 문제가 있는 프로젝트에서 보이는 증상들을 그 프로젝트에서 금세 포착했다.


  • 그들은 제품 출시까지 두 달 남았다는 이야기를 다섯 달째 하고 있었다.
  • 사람들은 내 질문에 대답하기 전에 누가 엿듣는지 보려고 주위를 둘러 보았다. 이것은 사람들이 팀 동료에게서 자신을 보호하고 있다는 증상이다.
  • 사람들은 눈에 띄게 지쳐 보였으며 신경도 날카로웠다.

컨설팅에서 정말 자주 생기는 일이지만, 의뢰인은 이미 답을 알고 있다. 컨설턴트로서 내가 할 일 가운데 하나는 답을 아는 사람을 찾아 그 답을 권력이 있는 사람에게 전달하는 일이다. 첫째 날 아침 커피를 마실 때, 누군가 이런 말을 했다. "우리가 하드디스크를 날려 버릴 수만 있다면, 프로젝트를 해낼 수 있을 텐데." 배치까지 두 달밖에 남지 않은 상황에 모든 코드를 날려 버린다는 상상에 모든 사람이 불안한 웃음을 지었다.

이틀 후 나는 크라이슬러의 CIO와 회의를 했다. 나는 그녀에게 세 가지 선택을 내밀었다. 현재 진도대로 나가면서 소프트웨어가 배치할 준비가 되긴 할지 언제까지나 확신하지 못하는 것, 프로젝트를 당장 취소하고 그 동안 쌓은 모든 경험을 잃는 것, 더 작은 팀으로 처음부터 다시 시작하는 것. 그녀는 나의 참여 하에 새로 시작하는 것을 선택했다.

큰 변화를 성공하게 만드는 일에는 여러 요소가 필요한데 행운도 그 가운데 하나다. 내가 집에 돌아왔을 때 다음과 같은 론 제프리즈(Ron Jeffries)의 메일이 와 있었다. "일하 거 없어? 나한테 810-555-1234로 전화해줘." 나는 전화를 걸어 이렇게 말했다. "제발 810이 디트로이트 지역 번호라고 말해줘." "앤 아버인데. 디트로이트랑 꽤 가까워." 이것이 어떻게 론이 첫 번째 전업 XP 코치가 되었는가에 대한 이야기다.

마틴 파울러도 분석과 관련된 문제에 대해서 그 프로젝트에 컨설팅을 해 주고 있었다. 나는 그를 붙잡고 분석과 테스트하는 일을 도와 달라고 말했는데, 우리가 완전히 새로운 소프트웨어 개발을 시험해 볼 때라도 마틴 파울러 라면 생각을 차분하게 유지하리라는 점을 알고 있었기 때문이다. 마지막으로, 나는 경영진의 지원을 약속 받았으며, 처음에는 불편하게 느껴지는 개발 방식일지라도 계속 붙어 있겠다고 각오한 팀도 하나 얻었다.

이 주일 후 나는 프로젝트를 시작하기 위해 돌아왔다. 맨 처음 할 일은(규모가 줄어든) 팀 구성원들과 개별 면담을 하는 일이라고 결정했다. 일이 잘되게 만들기 위해 그들이 무엇을 할 수 있다고 생각하는지 알고 싶었다. 나는 프로젝트 관리자인 밥 코(Bob Coe)부터 시작했다. 처음 몇 마디 대화를 나눈 다음, 그는 이렇게 물었다. "그래서 프로젝트를 어떻게 진행할 생각입니까?"

대답할 준비는 하고 있었지만 내심 나올까 봐 두려워하던 바로 그 질문이었다. 내가 정확히 무슨 말을 해야 할지 몰랐기 때문이다. 나는 이렇게 말하기 시작했다. "우리는 음…. 석 주짜리 어…. 반복(iteration)들을 할 겁니다. 반복마다 우리는 음…. 몇몇 스토리를 구현할 건데, 그건 메리(급여 지급 전문가)가 고를 거예요. 우리는 스토리를 추정한 다음에 반복 하나당 얼마나 많은 스토리가 들어갈 수 있는지 알아낼 겁니다. 그리고 반복의 수를 세어보면 전체 일정의 길이를 알 수 있겠지요."

"왠지 잘 될 것처럼 들리는 군요."

다음 면담에서 나는 이렇게 말했다. "그러니까 우리는 석 주짜리 반복들을 할 겁니다. 반복마다 스토리를 몇 개 담지요. 우리는 음… 첫 번째 반복만 가지고도 제대로 된 급여명세를 정확히 찍을 수 있도록 반복 안에 스토리들을 넣을 겁니다." 그리고 그 날 면담을 계속 하면서, 면담을 한 번 할 때마다 나는 프로젝트 구조에 익숙해졌고, 그때마다 내 착상에 세부사항을 조금씩 더해 갔다.

내 목표는 내가 소프트웨어 공학에서 가치를 지닌다고 아는 모든 것을 담는 프로젝트 진행 방식을 만든 다음 다이얼을 10까지 돌리는 것이었다. 우리는 꼭 필요한 모든 것을 상상할 수 있는 한 가장 열렬하게 할 것이며 다른 모든 것은 무시하리라. 만약 해야 할 것이 더 있다는 사실을 알게 되면, 그것들은 나중에 추가하리라.

하루가 끝날 때가 되자, 나는 XP의 기본 틀을 잡았다. 고객이 고른 기능들이 정해진 심장박동에 따라 추가되고, 테스트가 자동으로 이루어지며, 언제나 배치 가능한 시스템이 바로 그것이다. 이 정도면 10이라고 생각했던 다이얼이 사실은 8이나 6 정도일 뿐이었다는 사실을 깨닫는 데는 경험이 더 쌓여야 했다.

내가 이것을 '기본'이라 한 까닭은, 이 추상 개념들을 실제 프로젝트에 적용하는 작업을 실제로 한 사람들은 팀이었기 때문이다. 프로세스에는 살을 붙여야 했고, 도구들을 작성해야 했으며, 기술들도 배워야 했고, 인간관계도 새로 만들거나 돈독하게 해야 했다. 나는 소프트웨어 개발을 다르게 하는 방법에 대한 미래상을 제시했고 팀은 실제로 소프트웨어를 그 방법대로, 그리고 그 방법보다 낫게 개발했다.

우리의 첫 번째 과업은 프로젝트를 완료하려면 시간이 얼마나 걸릴지 추정하는 일이었다. 팀은 스토리들을 작성하고 추정했다. 우리는 하루 종일 계획 수립 회의를 해서 모든 스토리를 검토했다. 우리 고객은 첫 번째 배치에 들어갈 최소한의 기능들을 골랐다. 그런 다음 우리는 추정치들을 더해서 나온 날짜를 IT와 발주 조직 의 최고 관리자들에게 보여 주었다. 하루가 끝날 때쯤 한 프로그래머가 내게 이렇게 말했다. "지금까지 본 추정치 가운데 진짜로 믿은 건 이번이 처음이에요." 그런 다음, 팀은 3주 주기로 스토리들을 구현하기 시작했다.

팀은 돌아가기 시작했고 나는 자신감이 넘치게 되었다. 나는 우리가 범위를 협상한다면 소프트웨어를 언제나 제시간에 전달할 수 있으리라 확신했다. 하지만 소프트웨어 개발에 확실한 것이란 없다. 어떤 사건 하나가 특히 내 기억에 선명히 남아 있다. 나는 시스템을 기능들로 나누고 기능에 대한 통제권을 고객에게 준다면, 우리 소프트웨어는 언제나 제시간에 배치될 수 있다고 절대적으로 확신하고 있었다. 나는 시스템을 제시간(1997년 1월)에 출시할 수 있다는 내기에 많은 돈을 걸었다. 11월 중순이 되자, 그렇게 되지 않으리라는 점이 분명해졌다. 급여 명세의 숫자들을 충분히 잘 계산하였지만, 출력 파일에는 그 숫자들이 올바로 나오지 않았다. 우리 테스트들은 오직 숫자가 잘 계산되었는지 까지만 확인해 줄 뿐이었다. 결과를 올바로 출력 하려면 해야 할 일들이 더 있었다.

나는 내가 이 상황에 잘 대처했다고 말하고 싶지만 그러지 못했다. 나는 당황했다. 남아 있는 모든 작업을 남은 시간에 쑤셔 넣는 일에 팀이 동의 하도록 만들려고 했다. 체트 핸드릭슨(Chet Hendrickson)이 길게 끄는 말투로 이렇게 말했을 때에야 나는 제정신을 차리게 되었다. "다른 때에는 완료 날짜를 추정할 필요가 있다면 언제나 각 부분에 추정치를 잡은 다음 그걸 더했 잖아요. 지금 상황이라고 뭐가 다릅니까?"

나는 보너스가 날아갈까 봐 걱정하였지만, 다시는 소프트웨어의 배치가 늦는 일은 없도록 만들겠다는 내 꿈에 대해서도 걱정하고 있었다. 상황은 그럭저럭 잘 마무리되었다. 우리는 3월에 검사를 받았으며 시스템은 4월에 가동 되었다.

그 시스템은 3년 동안 가동되고, 2000년에 가동이 중지되었다. 가동을 중단시킨 두 원인은 기술과 재정이었다. 2000년이 되자 스몰토크가 아니라 자바가 명백히 지배적인 객체 기술이었다. 크라이슬러는 잘 사용하지 않는 언어로 작성된 시스템을 언제까지 유지 보수할지 기간도 정하지 않은 채로 유지보수하고 싶어 하지 않았다. 그들은 이미 다른 시스템에서 그런 사항에 처해 있었는데, 그것은 비용도 많이 들고 불편한 일이었다. 우리 프로젝트는 IT 부서에서 재정을 공급 받는 객체 기술 사용에 대한 파일럿 프로젝트였다. IT 부서는 재무부서에 다음 단계를 위해 돈을 대달라고 요청 했다. 재무 부서는 거절 했고, 프로젝트는 중지 되었다.

그 시스템은 안정적이고, 비용이 적게 들고 유지보수와 확장도 쉬웠다. 아키텍처는 유연하고 적절한 상태로 있었다. 결함 비율은 비슷한 프로젝트와 비교할 때 믿을 수 없을 정도로 낮았다. 팀은 새로운 구성원을 맞아들이는 일을 그다지 어려워하지 않았고, 팀원이 한 명 떠날 때 그에 비례하는 정도로만 팀의 효율성에 영향을 미쳤다. 프로젝트는 마지막 순간까지 기술적 성공 사례였다.

그 프로젝트는 비즈니스 성공 사례이기도 했다. 우리 프로젝트는 객체 기술이 대규모 데이터 처리에도 적합하다는 사실을 증명했다. 그러나 비즈니스 요구가 변했다. 소프트웨어 개발 재정 지원의 우선순위는 기술적 실천방법과 비즈니스 실천방법의 이동에 따라 빠르게 변한다.

이것이 XP 시작에 대한 내 이야기다. 그때 이후로, 여러 팀의 많은 생각과 노고가 XP의 가치, 원칙, 실천방법의 관계를 탐구하고 그 아이디어들을 다듬는 데 들어갔다.

'Environment' 카테고리의 다른 글

우분투 설치  (2) 2008.09.23
XP의 통제  (0) 2007.08.22
KentBeck 간단한 XP 정의  (0) 2007.08.21
|
blog comments powered by Disqus

matrim's Blog is powered by Daum & tistory