녹색 성장과 소프트웨어

얼마전의 우리 정부는 연 7% 의 고속 성장 목표에서 환경을 생각하는 녹색성장 정책으로 국가의 정책을 변경하였습니다.

녹색성장이란 저탄소 산업을 육성하여 경제와 산업 성장에 있어서 탄소 연료 소비를 최소화하고 이산화 탄소 등 환경 공해 물질을 억제하여 지구를 환경 파괴로 부터 지키기 위한 산업 성장을 말합니다.

물론 현 정부가 녹색성장의 동력으로 원자력에 의존하는 부분 등 미숙한 부분도 있지만, 심각한 수준에 있는 지구의 환경 파괴 상태를 본다면, 정말 기쁘고 반가운 소식이 아닐 수 없습니다.

TV,인터넷, 라디오, 신문, 잡지, 영화 등 모든 미디어들은 현재의 지구 상태를 매우 심각한 상태로 보고 하며, 우리에게 경고를 주고 있습니다.

하바드, 캠브리지 등 세계의 대학과 그곳의 석학들도 우리에게 심각하게 경고합니다.

하지만 아직 아무도 지구 환경에 대한 긍정적인 영향을 소프트웨어가 큰 부분에 있어 작용한다는 것에 대해서 이야기하지 않는 것 같습니다.

물론 제가 업으로 삼고 있는 것이 소프트웨어 개발이라 좁은 관점에서 사고한 이론인지 모르겠습니다.

하지만 지구의 심각한 문제가 인류가 그동안 사용한 화석 연료로 인한 것이였다면, 현 위기를 벗어날 길은 소프트웨어의 극단적 사용이라고 생각합니다.

인류는 산업 혁명 이후 양적 성장과 크기의 확장에만 매달려 왔습니다. 더 많이, 그리고 더 빠르고, 더 높고, 더 무겁고, 더 크고 등 팽창 위주의 성장이였습니다.

아인슈타인의 진리적 이론인 E=MC^2 에 따르면 질량이 무거우면 에너지의 양이 크다, 즉 인류가 그동한 추구한 확장적 성장에 따라 계속 발전한다면 점점 사용하는 에너지의 양은 늘어나며, 지구의 파괴는 더욱 빨리 질 것입니다.

결국 우리는 지금까지의 관습을 모두 버리고 더욱 작고, 더욱 느리고, 더욱 가벼운 축소의 성장을 이루어야 지금의 위기에서 벗어 날 수 있을 것입니다.

축소의 성장에는 너무나 많은 난관이 있습니다. 크게 만드는 것 보다 작게 만드는 것은 너무나 많은 노력이 들어 갑니다. 또 한 물리적으로 사물을 축소한다는 것은 한계가 있습니다.

자동차를 생각해보십시오. 가끔 모토 쇼에 1인승 미래 자동차가 나옵니다. 실제 오토바이 크기 만큼 작은 차들이지요. 그럼 자동차를 그이상 작게 만들려면 가능할까요?

사람도 타야 하고, 엔지도 있어야 하고, 짐도 실어야 하니까 아마 힘들것 같습니다.

그럼 어떻게 탈것을 더욱 축소 시키면서 발전 시킬 수 있을까요?

여기서 우리는 확장적성장의 패러다임을 버려야 합니다. 자동차를 가볍고 작게 만들것이 아니라 자동차의 목적인 이동을 작고 가볍게 만들어야 한다는 생각을 해야 합니다.

불과 10년 사이에 홈쇼핑, 인터넷 쇼핑이 몇 백배 성장하며, 우리의 생활 양식마저 바꿔 놓고 있습니다.

모든게 It기술과 소프트웨어의 눈부신 발전 때문이지요. 그런데 그런점 생각해보셨습니까? 홈쇼핑과 인터넷 쇼핑 때문에 차량 운행량이 얼마나 줄었을까?

과거 홈쇼핑, 인터넷 쇼핑이 아예 없던 시절 우리는 물건을 사기 위해 시장이나, 백화점 등 물건을 판매하는 곳까지 직접 이동하여야 했습니다.

심지어 지역 특삼물이나, 특별한 물건을 사기 위해 몇십 몇백 킬로미터를 이동해야 할때도 있었습니다.

하지만 지금은 어떻습니까? 저의집에서 제주도의 옥돔을 구매할 수 있습니다.

얼마 전에는 수천 킬로미터가 떨어진 미국의 상점에서 책을 주문 했습니다.

만약 그 책을 사기 위해 비행기를 타고 차를 타고 직접 이동했다면 어마어마한 에너지를 사용하여 그 책을 구매한 것이 될 것입니다.

위에서 말한 아인슈타인의 E=MC^2의 법칙으로 생각 해보면 제가 몸무게가 90kg 정도나가고, 위 법칙에 적용받을 수 있는 속도로 이동한다면 에너지의 양은 음....상상을 초월 하는 (참고로 답을 구할 수 있는 분은 구해 보세요 공식은 : E = 90 kg * (3 * 10^8 m/s) ^2) 에너지 양이 나옵니다.

그럼 집에서 그 책을 인터넷을 통해 구매했다고 한다면, 실제 이동한 것은 저희 집에서 미국의 그 상점의 서버까지 연결된 라인을 통해 이동한 전자들 뿐 일 것입니다. 물론 초당 몇 MB 이상씩 이동을 시켜겠지만, 전자의 개당 무게는1 kg * (3 * 10^8 m/s) ^2 이 정도이니 아무리 수많은 전자를 이동시켜 이용했다고 하더라도 사용에너지의 양은 비교가 되지 않습니다.

물론 지금의 말은 검증된 것도 아니고 또 현실적이지도 않습니다. 단순히 아인슈타인의 E=MC^2 이라는 이론을 이용하여 극단적으로 이야기 한 것 뿐입니다.

하지만 우리는 소프트웨어를 사용하므로 기존에 비효율적이었고 낭비의 요소가 많았던 이동을 개선한 것은 사실입니다.

우리 주변에는 이런 것 뿐 아니라 소프트웨어를 이용하여 에너지를 훨씬 작게 사용하여 기존의 방식과 동일한 효과를 보는 일들이 많을 것입니다.

지구가 위기에 처해진 것은 분명한 사실 인 것 같습니다. 작년에 충격적이었던 엘고어의 “불편한 진실” 이라는 영화가 생각납니다.

우리에게 불편한 진실이지만, 진실은 진실 입니다. 인류 모두가 힘을 모아 지금의 위기를 슬기롭게 해결 해야 합니다.

여기에 소프트웨어 개발을 담당하고 있는 우리도 역시 동참하여 우리의 힘으로 지구를 구할 수 있는 길을 연구하고 고민하여 위기에 처한 지구를 구하는 일에 힘을 보태어야 할 것 입니다.

Q: 지금 사용자 스토리를 읽고 있습니다. 몇 년 전에 XP를 읽고 느꼈던 감동이 다시 오더군요. 그때도 지금도 고민되는 문제점이 있습니다. 제가 XP를 처음 접할 때 저는 벤처기업에 있었고 개발이 상당히 어렵게 진행되고 있었습니다. 대표적으로 회사가 상하로 나누어져 위에서는 개발자를 재촉하고 개발자는 수동적으로 따라가는 구조였습니다. 저는 그때 개발팀을 이끌고 있었고, 그래서 그런 현실이 안타까웠습니다. XP를 읽고 한번에는 안되겠지만 점차 적용을 해야겠다고 생각하고 개발자들과 회의 시간에 XP를 알렸습니다. 그런데 그때의 개발팀의 멤버는 아주 비관적인 말을 했지만 저도 답변을 할 수가 없었고, 지금도 마찬가지 입니다.

"스토리를 만드는 것이 일을 크게 하는 것이 아닌가?. 주어진 데로 하는 것도 쉽지 않은데 스토리를 작성해서 일이 커질 경우 개발 비용을 고스란히 개발팀이 떠 안아야 한다."

이렇게 요약을 할 수 있는데요. 이 부분에 대해서 어떻게 생각하시는 지요? 예를 들면 지금 제가 개발 업체를 다니고 있고, 이번에 우리 회사가 카드회사의 새로운 프로젝트를 맡았다고 할 경우에, 이미 제안서와 요구사항에 의한 비용산출이 끝난 이후 개발팀이 투입이 될 것입니다. 개발팀의 팀장은 XP를 이용하고자 했습니다. 카드회사의 새로운 프로젝트를 사용하는 사용자를 만나 미팅을 해서 프로젝트를 좀더 효과적으로 성공시킬 수 있는 아이디어를 도출할 수 있었습니다. 새롭게 도출된 결과는 카드 회사입장에서 상당히 장점이 있는 것으로 카드 회사는 제가 다니는 회사와 협의를 하게 될 것입니다.

이때 제가 다니는 회사에서 "왜 긁어 부스럼을 만들 어냐?"라는 말이 나올 수 있습니다. 많은 경우 아이디어는 일을 크게 하는 경우를 많이 봤습니다. 이런 경우에, 반복 주기에 고객의 의견을 반영함으로써 프로젝트의 완성도는 좋아지지만 점차 발생하게 되는 비용의 문제는 어떻게 해결해야 하는지요? 외국의 경우, 반복 주기마다 계약된 금액이 변경될 수 있나요?. 또는 국내 프로젝트에서는 어떤가요? 계약사항이 있는데도 "갑"이라는 이유로 요구사항을 변경하는 경우도 비일비재한데, 개발팀이 스토리 확장 및 변경에 관한 비용 문제를 어떻게 이겨내야 할까요?

A : 제 경험과 생각으로는 어차피 XP 나 기타 다른 Agile Process 가 아닌 전통 적인 개발 방법론을 사용하더라도 사용자의 기대 수준과 기획 시 계획의 차이는 해결해야 할 문제 인 것 같습니다. 프로젝트의 계약 시 보통 아주 세부적인 사항까지 계약하지는 않습니다. 개발 되는 시스템의 목적과 용도 에 입각해서 세부 사항은 숨기고 고객의 필요한 요구사항을 충족 시킬 것이라는 계약만 이루어 질 뿐입니다. 가령 계약이 기존의 이미 존재하는 시스템을 도입하여 프로그램의 세부 적인 구성을 고려하여 계약 되게 되더라도 실제 개발에서의 고객 요구 사항은 계약 내용과 상이한 점이 존재 할 수 밖에 없습니다. 그렇다고 고객의 요구를 무시하고 계약 되로 개발 할 수는 없죠? 그래서 소프트웨어 프로젝트의 개발 동안 PM 들은 계속 고객과 회사 등 프로젝트 전반에 걸쳐 이해관계가 있는 곳과 조율과 이해를 구하게 되는데 전통적인 개발 방식에서는 이 능력은 전적으로 PM의 역량에 의존하는 경향이 입니다(술로 해결하는 사람들도 많죠ㅡㅡ;;).

하지만 XP 프로세스에서는 계약과 현실의 차이를 고객이 조율하게 함으로 그 과정에 발생 할 수 있는 오해와 갈등을 이해와 화해의 수준으로 해결 하고 있습니다.
고객은 프로젝트 자원을 더 널리지 않고 범위를 가지고 변경된 요구사항을 조정하게 되며, 고객의 요구사항이 변화게 되더라도 결국 개발사의 전체적 비용은 초과 되지 않습니다. 즉 다시 계약 할 필요가 없죠(정말 이거 행복 합니다. 고객에게 추가 계약 이야기 하기는 정말 싫습니다.ㅜㅜ)
여기서 가장 중요한 것은 XP의 프로세스에서는 고객에게 가장 가치가 있는 스토리가 먼저 구현되고 프로젝트 전반에 걸쳐 다듬어 지며, 프로젝트가 완료되기 전 빠른 시간에 고객의 손에 넘어 간다는 것 입니다. 범위의 조정으로 계약 예산의 뒤쪽에 있는 즉 지정된 예산안에 처리가 되지 못하는 스토리들은 고객에게 상대적으로 먼저 수행되고 개발된 스토리보다 덜 중요한 스토리 이며, 개발사가 전체 스토리를 모두 구현하지 못하더라도 최소한의 계약 사항에 명시된 고객에게 제공해야 할 가치는 성공할 수 있는 것입니다.
전체를 망치겠습니까? 우리가 할 수 있는 중요한 몇 개라도 잘 하시겠습니까?ㅎㅎ
행복한 하루 되세요!

TDD 를 이용한 클래스 디자인

오늘 Test Driven Development에 대한 한가지 질문을 받았다.

"프로그램이 어떻게 돌아 가는지 만들어 지지도 않았는데 어떻게 테스트부터 작성해요?"

"너무 테스트를 작성하기가 힘들어요!"

난 TDD를 설명하기 보다는 IDE를 열고 TDD를 이용한 간단한 프로그램 개발을 같이 수행했다.

30분 정도의 설명이 곁들여진 짝 프로그래밍으로 그 사람은 어렴풋이 짐작이 간다는 투로 오늘 많이 배운 것 같다고 했다.

그의 질문처럼 제작 되지도 않은 프로그램을 테스트 할 수 있을까?

클래스 조차 생성되지 않았고, 심지어 클래스의 명 조차 정의 되지 않았는데 뭘 테스트 한다는 것 인가?

아마도 프로그램의 실제 제작(구현)에 관한 관점에서 테스트를 생각한다면 불가능하고 비효율적이라고 생각 할 것이다.

하지만 난 다시 질문을 하고 싶다.

'Test Driven Development 구현에 관한 것 일까?'

테스트를 작성한다는 것이 어떤 의미 일까?

Unit Test 먼저 작성 할 때 마다 나의 뇌는 클래스의 구조와 디자인 부분에 대해 집중한다는 것을 느낀다.

테스트를 작성할 때 클래스가 담당해야 하는 인터페이스에 집중 하게 된다.

먼저 나는 테스트 해야 하는 스토리(또는 요구 사항)를 하나 선택 한 후 적당한 클래스의 이름과 인스턴스 이름을 생각한다.

그리고 생각한 이름의 클래스를 생성하는 테스트를 작성한다.

User _myUser = new User();

Assert.IsNotNull(_myUser);

테스트를 수행 한다.

오류가 발생해서 빌드가 안 된다. User 클래스를 찾을 수 없다고 한다.

User 클래스를 만든다. 클래스에 아무것도 구현하지 않는다.

Public Class User{

}

테스트를 수행한다.

오 이제 오류가 없이 빌드 된다. 거기다 녹색 불 재수!

이제 다시 스토리를 본다.

'사용자의 생일이 오늘인지 확인할 수 있어야 합니다'

오늘이 사용자 생일인지 확인해주는 메서드가 필요 하겠군, 메서드 명을 뭐라고 한다.?

그냥 메서드 이름은 'BirthdayCheck'로 할까 ?

아님 'TodayIsBirthdayCheck'로 할까?

두 번째 것이 모호 하지 않고 좋을 것 같다.

테스트를 작성 한다.

_myUser.Birthday = ToDay();

Assert.IsTrue(_myUser.TodayIsBirthdayCheck());

테스트를 수행한다.

젠장! 빌드 오류다. Birthday 프로퍼티를 찾을 수 없다고 한다.

User 클래스로 가서 'Birthday' 프로퍼티를 만든다.

Public DateTime Birthday

{

    Set{

     _birthday = value;

    }

}

다시 테스트 수행 또 오류다.

_birthday 필드를 찾을 수 없다고 한다.

_birthday 필드를 선언한다.

Private DateTime _birthday;

다시 테스트를 수행한다.

지겨운 오류! 이번엔 TodayIsBirthdayCheck() 를 찾을 수 없다고 한다.

User에 TodayIsBirthdayCheck() 메서드를 만든다.

Public bool TodayIsBirthday()

{

    Return null;

}

다시 테스트 오! 이제 빌드 오류는 발생하지 않는다.

하지만 빨간불! 자 여기서 목표는 로직의 완성이 아니다.

빨리 녹색불 을 보는 것 테스트를 통과 하는 것이 우리가 할 일 이다.

그래서 난 그냥 TodayIsBirthday() 메서드에 True를 반환하게 한다.

Public bool TodayIsBirthday()

{

    Return true;

}

다시 테스트

신이여 감사합니다. 통과 다!

여기까지다 여기까지가 TDD의 끝이다.

'사용자의 생일이 오늘인지 확인할 수 있어야 합니다' 스토리에 대한 TDD 가 끝난 것이다.

ㅋㅋㅋ 말도 안 된다고 ?

TDD가 끝난 것이지 프로그램을 만들기 위한 구현이 완전 끝난 것이 아니라는 것을 알기를 바란다.

내가 말하고 싶은 것은 TDD는 구현의 도구가 아니라는 것이다.

이제 가상으로 만든 메서드의 로직을 실제 동작하게 구현 하여야 하며, 그런 중 다른 클래스와 관계를 가지고 작업을 하게 될 것이다.

가령 데이터를 저장소로부터 가져오는 Mapper 클래스나 시간을 나타내는 DateTime 등등 외부와 관계를 맺기 시작하며, 클래스의 내부는 점점 복잡해 지며, 우리는 그런 내부의 복잡함을 관리 하기 위해 리팩토링을 하며, 점진적으로 클래스를 완료해 나갈 것이다.

자! 이제 잘 생각 해보자

내부 구현과 리팩토링을 하기 위해 방금 만들어진 테스트를 변경 할 필요가 있을까?

결코 그런 일은 발생 하지 않는다.

스토리의 요구 사항이 변경 되지 않으면 테스트 셋의 정의 또한 변경 되지 않는 것이다.

아무런 기능을 하지 않지만 이름과 형태의 정의로 테스트 셋이 완료가 되었다.

즉 TDD의 테스트란 외부와 상호 작용을 하는 것의 정의에 대한 검증이다.

공개 인터페이스 디자인에 대한 검증이라고 말 할 수 있다.

우리는 보통 클래스 디자인을 할때 요구사항 정의서를 이용한 클래스다이어그램을 그리는 것을 상상 한다.

클래스다이어그램을 만드는 것이 어떤 행동인가?

요구상항의 요구조건을 수행하는 공개인터페이스에 대한 예측과 정의 아닌가?

그럼 TDD의 테스트 는 무엇인가?

스토리 또는 요구사항에 대한 공개인터페이스의 검증을 작성 하는 것이다.

검증을 작성하기 위해 예측하고 정의 하여야 하니까 이 부분에서 우리는 클래스의 디자인을 수행 하는 것이다.

또한 절대 정적이고 부자연스러운 클래스다이어그램에서 얻을 수 없는 견고한 테스트까지 얻을 수 있으니 클래스를 잘 디자인 하고 만들기 위해서 TDD을 사용할 가치가 충분이 있지 않을까?

eXtreme 프로그래밍 (리팩토링과 기민한 모델링) –인포북- 에서 발취

Q : 소프트웨어 폭주와 실패에 대해서 읽어보면 엄격한 프로젝트 관리와 통제가 위험을 줄여 줄 것 같은데, 실제 그런가?

A : 프로젝트 관리에 대해 좀더 하는 것은 언제나 좋은 일이고 공부를 하다 보면 통제가 중요한 수단이라는 것을 알 수 있을 것이다. 문제는 정확하게 필요한 일과 해결방안을 확실히 알 경우에만 통제가 유효하다는 것이다. 개발자는 항상 개발이 어떤 방향으로 흘러갈지 모른다는 마음가짐을 가져야 한다. 이렇게 되면 우리는 좀더 유연한 사고 방식을 가지게 된다. XP는 형식이나 여러 규제를 없앤 것이 아니고 고객이 사업적 관리를 하고, 개발자들은 좀더 자동화되고 현명한 방법으로 일을 진행하는 것을 요구하는 것이다. 이런 소프트웨어 공학적인 맥락에서 XP가 폭포수 모델보다 더 엄격한 관리를 가한다고 볼 수 있다.

아래의 문답 내용은 월간 마이크로 소프트웨어 의 2001년 12월 호 KentBeck 과 인터뷰에서 XP를 어떻게 경영진에게 소개 할까에 대한 KentBeck의 답변 입니다.

Q : XP를 예컨대 경영자 같은 사람에게 몇 분 만에 설명한다면 어떻게 하겠습니까. 그런 사람들에게 수년 간 XP를 설명해 왔으니 이제는 '진화된' 간략한 소개를 할 수 있을 것 같군요.

A : 당신이 이 소프트웨어가 했으면 하는 모든 것(우리는 이걸 '스토리'라고 부릅니다)을 적을 수 있다고 상상해 보세요. 각각의 스토리는 신기하게도 구현하는 데 일주일이면 됩니다(분명 작은 이야기들이겠죠). 만약 20개의 이야기(스토리)를 가진 프로젝트가 얼마나 걸릴지 알고 싶다면, 답은 20주입니다. 만약 15주 후에 그 프로젝트가 완료되길 바란다면, 당신은 가장 중요한 열다섯 개의 이야기만 고르면 됩니다. 만약 유의미한 열다섯 개의 이야기를 추려낼 수 없다면 당신은 지금 당장 프로젝트를 취소하는 게 좋을 겁니다(아니면 기적을 바라며 기도하든지요).

1주일에 한번씩 당신은 구현할 이야기 하나를 선택합니다. 1주일에 한번씩 당신은 그 주의 이야기와 동시에 이전의 이야기 모두를 포함하는, 출하 가능한 완전한 시스템을 얻게 됩니다. 만약 6주 후에 새로운 이야기를 발견한다면, 당신은 얼마든지 다음주의 이야기로 그것을 선택할 수 있습니다만, 또 다른 이야기 하나는 구현될 수 없다는 것을 기억하세요.

12주 후에 출하할 것을 결정한다면, 당신은 가장 중요한 열두 개의 이야기가 구현될 것을 보장 받습니다. 당신은 나머지 모든 것은 덜 중요하다고 결정한 것이죠.

이 글은 익스트림 프로그래밍 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의 가치, 원칙, 실천방법의 관계를 탐구하고 그 아이디어들을 다듬는 데 들어갔다.