그 유명한 켄트 벡의 역작 중 하나!

리팩토링, 유닛 테스트, 게임 등 코딩, 프로그래밍 개발에 있어 모든 좋은 것들을 가장 쉽게 확인하고 즐기게 해주는 프로그래밍 "라이프 스타일"에 관한 책이다. 물론 모든 사람들이 이 스타일에 맞을 수 없지만 프로그래머라면 한번 쯤 알아둘만하다. 단점이라면 켄트 벡이 워낙 강력하게 특정 유형의 개발자가 되라고 요구하기 때문에 맞지 않는다면 거부감이 강하게 들 수 있다는 것과 책이 조금 지루할 수 있다는 것.

소프트웨어 엔지니어링이 전산학의 한 분야로 올라오게 된 가장 큰 원인은 바로 "소프트웨어의 위기"의식 때문이었습니다. 

사실, 소프트웨어의 위기라는 것이 절대적인 개념으로서 존재하는 것이 아니라, 하드웨어의 성장과 비교해봤을때 위기라는 것이었지요. 

60년대 중반 "무어의 법칙" 같은 것들이 이야기 되면서, 하드웨어는 눈부신 성장 속도를 보여주고 있었지만, 그에 비해 소프트웨어는 이전과 별 변함없이 개발되고 사용되었습니다. 

그래서, "왜 소프트웨어는 하드웨어처럼 발전하지 못하는가?"에 대한 의문에 대한 답변으로 소프트웨어 엔지니어링을 연구하기 시작했지요. 

초창기에는 기존 공학분야에서 사용되는 개발 방법론을 잘 차용해서 소프트웨어 개발에 적용시키려고 했었습니다. 

그 대표적인 방법이 "폭포수 모델"로 전 공학 분야에서의 프로젝트 진행의 기본 모델로 사용되고 있습니다. 

- 요구사항 분석 -＞ 설계 -＞ 개발 -＞ 테스트 및 디버깅 -＞ 설치 -＞ 유지보수

의 과정은 건축, 기계 설비, 제품 생산, 소프트웨어 개발을 비롯한 모든 공학 분야에서의 결과물 도출 과정이기도 합니다. 

하지만, 소프트웨어에서만큼은 이 방법이 제대로 동작하지 못했지요. 

그 근본적인 원인은 바로, 이 순차적인 과정이 실제로는 순차적으로 진행되지 않는다는 것, 즉 프로젝트 진행의 불확실성이 유독 소프트웨어에서는 심하기 때문이었습니다. 

건물에 뼈대를 올리는 와중에, "어이, 설계도가 변경되었으니, 지금까지 했던거 부수고 다시 만들자!" 라는 말을 하는 사람은 없지만, 

소프트웨어를 개발하는 와중에 "아, 그 기능 필요없으니까 빼고, 새로 이 기능 넣도록 하자" 라는 말은 수도 없이 들려오지요. 

이 변화, 실제 소프트웨어가 완성되기 직전까지 계속해서 바뀌는 요구사항들을 관리하기 위해, 폭포수 모델을 기반으로 여러 다른 방법들이 제시되었습니다. 

가령, 나선형 모델, 프로토타입 모델, 카오스 모델, V 모델, 에자일 모델.. 등등이 그렇지요. 

이 책은 에자일 방법론의 대표적인 실천 방법으로서의 익스트림 프로그래밍 방법을 설명하고 있습니다. 

그렇다면, 에자일 방법이 무엇인지 먼저 알아봐야겠지요. 

에자일 방법은 폭포수 모델의 실패 원인인 "끊임없는 요구사항의 변화"를 회피해야 하는 요소로 생각하지 않고, 그것을 적극적으로 응대하기 위한 방법입니다. 

즉, "프로젝트가 종료되기 전까지 계속해서 변하는 것은 당연하다. 그렇기에, 처음에 미리 전체 프로그램에 대한 설계를 완성시키고 그것으로 개발하는 것은 당연히 실패할 수 밖에 없다." 라는 가정위에서 탄생한 개발방법론입니다. 

그래서, 짧은 결과물 도출 시스템을 기반으로 (요구사항의 변경이 발생하기 이전에, 이미 결과물을 하나 만들자, 그러면, 그 결과물에 기반해서 요구사항의 변화를 조절할 수 있고, 그렇게 되면, 기 완성한 부분을 폐기해야 하는 경우를 줄일 수 있다는 개념입니다) 전체 프로젝트를 작은 단위(스토리 단위)로 나눠, 팀 구성원을 하나의 유기체로서 같이 개발해 나가는 식으로 동작합니다. 

익스트림 프로그래밍(XP)는 이를 위한 하나의 실천 방법론으로, 에자일 모델이 지향하는 

1)팀원들 사이의 의사소통, 

2)결과물의 단순성(추후 유지보수를 위함)

3) 피드백 (동적으로 발생하는 요구사항 변화에 능동적으로 대처하기 위함) 

4)용기 (생소한 기법이라도 적극적으로 도입하고, 프로젝트 수행시 발생하는 위기 상황에 좌절하지 않기 위함)

와 같은 가치들을 실제 프로젝트 진행과정 속에서 얻어내기 위한 방법들로 이루어져 있습니다. 

XP의 대표적인 방법들은 

1) 함께 앉기

2) 짝 프로그래밍

3) 스토리 단위의 요구사항

4) 짧은 주기별 반복 개발 (이터레이션 이라고도 하죠)

5) 10분 빌드

6) 지속적 통합

7) 테스트 우선 프로그래밍

8) 점진적 설계

// 중복되는 내용에 대해서는 과감하게 생략했습니다 

등이 있고 이외에 보조 실천방법으로 

1) 진짜 고객 참여

2) 점진적 배치

3) 팀 지속성 및 팀의 크기 줄이기

4) 코드 공유

5) 코드와 테스트

6) 단일 코드 기반

7) 매일 배치

8) 범위 협상 계약

등등의 방법들이 있습니다만, 중요한 것은 이들을 그대로 사용한다고 XP를 적용했다는 것이 아니라는 것입니다. 

이 실전 방법들은, 이전에 말했던 에자일 방법의 4가지 가치를 실제 개발 환경에서 드러내도록 하기 위한 수단일 뿐이지요. 

프로젝트를 진행함에 있어서, 1)팀 구성원들 사이의 인간적인 관계, 2) 프로젝트의 경제성 (프로젝트의 성공 및 적절한 품질에 대한 책임), 3) 참여자들 사이의 상호 이익, 4) 실패 속에서 배우고 성장하기 (이를 위한 반성과 신뢰) 등을 잃지 않는다는 원칙에 따라서, 주어진 가치를 실현하기 위해 노력하다 보니, 제시된 XP 실천 방법들이 효과적이었다는 것이지, 이 실천 방법을 따르면 당연히 이런 가치들이 원칙 안에서 드러나는 것은 아니라는 것이지요. 

200페이지를 겨우 넘는 이 책이 XP와 에자일 방법에 대한 모든 것을 설명해주지는 않습니다만, 다만 XP가 가지고 있는 이상에 대해서는 충분히 잘 설명하고 있다고 생각됩니다. 

프로젝트에 실패하고, 왜 실패했을까를 고민하는 사람들에게 추천할 만한 책이라고 생각됩니다. 

재미있기도 하고요. 

하지만, 혹시 입으로만 컨설팅 하는 가짜 전문가에게 당한 적이 있는 사람이라면, 이 책은 나쁜 기억만을 들추지 않을까 싶기도 합니다. 

어떻게 보면 이 책은 에자일 모델과 그 실행 방법으로서의 XP에 대한 소개이며 에자일이 제시하는 소프트웨어 위기의 해결 방법에 대한 뜬구름 같은 이야기일 뿐이기도 하기 때문입니다. 

개발방법에 대한

책은 지금까지 참 많이 읽은거 같다.

예전엔 이렇게 하는게 있구나 하고 읽었었고..

어느정도 경험이 쌓인 후엔

이론적인 내용으로 생각을 했었다.

[우리나라와는 맞지 않다고 생각햇으므로..]

이번에 읽으면서는

왜 해외에서 넘어오기만 할까 하는 생각을 하게 되었다.

우리나라 상황에 맞는 개발방법론이 분명 있을텐데..

혹은

이러한 XP 사상을 따르는

우리나라에 맞는 방법들도 많을텐데..

하는 생각들이 든다.

항상

프로젝트를 다니다보면

외국에서 유명하다는 개발방법론을..

우리나라 상황에 맞추려고는 하지 않고

그중 괜찮다는것만 짜집기해서

무슨 방법론 이라고 이름까지 지어가지고 하는 경우가 종종 있었다.

예전에 CBD 개발방법론이 무슨 마술인것처럼 떠들썩할때는..

개발기간이 9개월중 1개월이 개발이었다.

8개월이 문서작업으로 일정이 잡혀있는걸 보고 어찌나 놀랐던지

좋다는 방식은 다 집어넣고 개발기간은 오히려 줄여버린거다.

-_-;;

어쨋든

여러 개발방법론들이 있지만

그 주된 목적은 프로젝트의 성공적인 결말에 있고

그에 따른 여러가지 상황에 맞는 방법들이 있다고 생각한다.

우리나라 현실과 맞아떨어지는 기본 틀이 있을것이고

그 기본틀에 상황에 따라 상황에 맞는 방식을 사용하면

그게 좋은 방법론이 아닐까 싶다.  

이 책 또한 그러한

방법들 중 xp 방법론 에 대한 책이고

이 책에서도

XP 의 줄기에서 상황에 따른 유연성을

얘기하고 있다.  

저자는 오래전에 XP 방법론에 대해서 다루고

그 XP 방법론으로 지금까지 해온 경험을 바탕으로

다시 XP 방법론에 대해서 다시 바라보며

이 책을 썼다고 한다.

물론 팀에서의 개발방법에 대해서 도 좋겠지만

개인적인 개발을 할때에도 좋은 방법들이 아닌가 싶다.

다른 여타 방법론에 대한 책들이

방법론에 대해서 강조하는 내용이 많은데 반해

이 책은 XP 방법론에 대한 내용도 있지만

그에 따른 사상도 볼 수 있어

좋았던거 같다.