한 칠년전에 읽었었는데, 이사하면서 다시 눈에 띄어 읽어 보았다. 예전에 가졌던 느낌은 XP (eXtreme Programming)는 방법론으로 먹고 살려는 친구들이 만들어낸 것일 뿐이다였는데, 지금은 그런 말뿐만인 방법론만은 아닐지 모르겠다는 생각을 했다. 아마 현재 처해 있는 상황이 XP에서 타파하려고 하는 다음 몇가지 상황들에 부합되기 때문일게다.
- 의미없는, 혹은 자랑스럽지 못한 일을 하고 있다.
- 일이 진전이 없다 혹은 매우 느리다.
- 잘못된 의사 결정이 잦다.
- 영업이 기술에 대해 감놔라 배놔라한다. 그것도 뻔히 잘못 보이는 길로.
- 이대로 가다간 현재의 작업이 중단될 것이며 그 때 '아! 아이들과 시간을 더 많이 보냈어야 했어..'하고 후회할 것이다.
XP는 그러한 상황을 막기 위해서 커뮤니케이션, 단순화, 피드백,용기의 4가지 덕목을 이야기한다. 용기는 기존과의 다른 방법론을 받아 들이겠는가. 이 방법을 의심없이 수행할 수 있겠는가 에 대한 주문과도 같은 개념이며 Kent Beck이 책을 아름답게 만들기 위해 넣은 것이다. (이런식으로 하면 Love도 넣을 수 있다. 사랑없이는 그 어느것도 의미를 갖지 못한다고 기술하면서..) 커뮤니케이션, 단순화, 피드백은 두가지 문제를 해결하기 위한 덕목이다. 그것은 (1) 원하는 문제를 해결하고 있는가? (2) 올바르게 해결하고 있는가? 이다.
현대 사회의 일이란 것이 모두 - 비단 프로그래밍이 아니더라도 - 상당한 복잡도를 가진다. 복잡하지 않은 일은 방법론이 굳이 필요 없기도 하다. 복잡한 일을 하다보면 두가지 현상이 발생한다. 먼저 복잡하기 때문에 그 일을 하는데 많은 사람이 필요하다는 것이다. 많은 사람이 하나의 일을 같이 하면 높은 확률로 배가 산으로 가게 되므로 커뮤니케이션과 피드백을 통해 그러한 일을 막아야한다는 것이 XP의 한 축이다. 두번째로는 복잡한 일은 그 일을 이루는 세부 일들이 서로 인과관계나 포함관계를 이루게 되는데 이 때에 세부 일들이 잘못 해결된 경우는 전체 일 자체가 잘못 해결된다는 것이다. 따라서 복잡한 것은 단순화시켜 오류가능성을 낮추고, 각 세부 일에 대해서는 정기 피드백을 통해 항상 오류가 없는지를 확인하는 것이 XP의 다른 한 축이다.
정리하자면 XP는 일을 올바르게, 그리고 항상 오류없이 단순화하면서 진행할 수 있다는 것이다.
그리고 내 앞에 놓여진 숙제는 무슨 수를 써서라도 자동 테스트 시스템을 구축하라... 라는 것이다.
Though Kent Beck tossed the term XP (eXtreme Programming) and explained it well in this book, I think that his following paragraph summarizes it concisely:
So you code because if you don't code, you haven't done anything. You test because if you don't test, you don't know when you are done coding. You listen because if you don't listen you don't know what to code or what to test And you design so you can keep coding and testing and listening indefinitely. That's it.
