Extreme Programming Installed

Extreme Programming Installed - 론 제프리즈 & 앤 앤더슨 외 지음, 박현철 외 옮김/인사이트

이전에 XP에 관해서 알고 있었던 것은 마소의 특집기사에 실렸던 내용이 전부였고, 이번에 제대로 한번 알아보자는 생각이 들어서 김학규님이 추천하신 XP Installed를 선택했다.

이미지는 보면 알겠지만 Dilbert에서. 사실은 이 편말고 Pair Programming에 관한 편을 올리고 싶었는데 이미지를 구할 수 없었다. 이미지를 찾기 위해서 뒤지다가 보니, "Dilbert에 XP에 관한 내용이 나왔다. 이제 XP도 buzzword로 공인받은거냐?"라는 어느 포럼의 재미있는 thread를 발견했다. XP의 효용성에 관해서 의문을 가진 사람은 많은데, 내가 저 이미지를 퍼온 블로그에서는 "나는 XP를 실행하고 있는데, 다행히 내 고객은 위의 만화에서 나오는 것과 달리 제대로 된 고객이다."라는 커멘트를 보고 좀 더 믿어보아도 되겠다는 생각이 들었다.

많은 사람들의 의문과는 달리 책에서 이야기하는 내용은 꽤 감동적이었다. 나말고 같이 일하는 사람들도 공감해야 실행할 수 있다는 것을 제외하고는. 이 책에서는 고객, 관리자, 프로그래머로 나누어서 이야기하는데, 고객을 설득하기란 참 어려울 것 같다. 이 부분은 프로젝트의 "성공"이란 무엇인가에 대한 공감대를 먼저 형성하는 것이 중요할 것 같다.

사실 고객에 관해서는 꽤 어려운 화두가 나올 수 있을 것 같다. 이 책에서 고객에 대해서 강조하는 것 하나는 고객이 프로그래머와 같이 있어야 한다는 것인데, SI 경험이 있는 사람들은 이 것만으로 얼마나 상황이 좋아지는지(또는 나빠지는지)를 잘 알텐데, 그러면 1차적인 고객이라고 할 수 있는 기획자가 같이 있는 게임 개발은 왜 원활히 진행되지 않을까? 기획자가 XP에서 말하는 좋은 고객이 아니라서? 그렇게 말해버리면 프로그래머로서는 참 편할지 모르겠지만, 그렇게 쉽게 떠넘길 수 있는 것은 아닌 것 같다. 이 책에서도 말하고 있지 않은가. "누구의 잘못"인가가 중요한게 아니라 "무엇을 잘못했는가"를 찾아야 한다고.

일정의 추정에 대해서도 꽤 쓸모있(어 보이)는 이야기를 하는데, 하나의 작업이 1주 정도의 기간에 가능하도록 단위를 쪼개라는 것이다. 이게 1개월이 되면, 그 추정의 신뢰성은 떨어진다는 것이다. 또한 이미 추정한 일정에 대해서도 끊임없이(실제로 진행된 작업의 결과를 기반으로) 재추정하여 점점 더 일정의 신뢰도를 높여가야 할 것으로 생각된다.

실행하기가 매우 어려워보이는 것 하나가 "작은 배포"인데, 여기에 대해서는 참여하는 사람들의 마인드 변화가 중요할 것 같다. "이것 밖에 안되었다."가 아닌 "이만큼 되었다"라고 말할 수 있는 그런 시각이 없이는, 작은 배포는 고객으로 부터의 압력을 증가시킬 뿐일 것 같다. (물론 그런 고객은 XP에서 말하는 바람직한 고객은 아닐 것이다.) 작은 배포가 이 책에서 말하는 것과 같이 지속적으로 성취감을 느끼게 할 수 있는 환경이 아닌 한은 오히려 역으로 작용할 것 같다.

단순한 설계에 대해서는 매우 공감하고 있다. 확장성 있는 구조란, 준비되어 있는 구조가 아니라 군더더기가 없어서 쉽게 추가/수정할 수 있는 구조라는게 내 경험 속에서의 판단이고, 그런 내 경험과도 동일한 결론인 것 같다. 미래를 위한 설계보다, 현재에 최적인 설계 + 리팩토링이 좀 더 좋은 방법론일 것 같다. 특히나 만들어야 할 것이 계속 변화할 경우에는. 일부에서는 리팩토링이 잘못된 설계로 인한 오버헤드라는 인식이 큰 것 같은데, 잘못된 설계로 인한 리팩토링은 오버헤드이지만, 요구사항의 변화에 따른 리팩토링은 필요 코스트로 받아들여져야할 것이다. 물론 이게 설득력을 가지기 위해서는 단순한 설계가 정말로 개발을 가속화하는 것을 보여주어야 할 것 같다.

짝 프로그래밍에 대해서는 아직 잘 모르겠다. 이건 정말로 해보기 전에는 뭐라고 말하기 힘들 것 같다. Dilbert에서는 짝 프로그래밍이 "두 사람에게 PC를 한대 주어서 비용을 절감"하는 것이라 비꼬지만,(짝 프로그래밍을 비꼰 것인지, 짝 프로그래밍을 이해하지 못하는 사람들을 비꼰 것인지는 솔직히 잘 모르겠다.) 적어도 경험자가 신입을 키우는 방법론으로는 꽤 유용할 것 같다고 생각하고 있다. Pair Programming Illuminated를 읽고 나면 좀 더 생각이 정리될 것 같으나, 우선은 다른 책들을 먼저 볼 것 같다.

테스트 주도 개발에 대해서는 근본적인 취지는 좋은 듯 하나, 실제적인 실행방법에 관해서는 아직 감이 잘 안온다. 결국은 직접 시행착오를 겪으면서 몸으로 익히지 않으면 안될 것 같다는 느낌이나, 일단은 테스트 주도 개발을 먼저 읽어보면서 시행착오를 줄일 방법을 찾아볼 생각이다.

이 책에서 동의하지 않는 부분은 주당 40시간의 근무. 물론 한국에서처럼 룰루랄라하면서 주당 60시간 일하는 것과, 업무에만 집중하며 40시간 일하는 것은 확실히 틀리다는 것을 알고 있지만, (나는 예전에 2주간 일본 회사에서 일하면서 점심시간 외에는 화장실 가는 것 외에는 커피 한잔 담배 한대의 휴식도 하지 않으면서 일하는 사람들을 경험해보았다. 그 사람들은 정시출근, 정시퇴근이었지만, 일하는 시간이 적다는 느낌은 전혀 받을 턱이 없었다.) 근본적으로 나는 Good to Great에서 이야기하는 것처럼 5명을 고용해서, 7명의 급여를 주고, 10명의 일을 하게 하는 것이 회사나 직원이나 행복해지는 방법이라고 생각하기 때문에, 주당 40시간이라는 구체적인 수치에 동의하기는 힘들다. (참고로 이야기하자면 나는 5명에게 7명의 급여를 주고 8명분의 일을 시키는게 적정선이라고 생각하는데, 이건 내가 피고용자이기 때문일지도 모르겠다.) 물론 무작정 업무의 질이 떨어지지 않게 하기위해서 적정 시간의 휴식이 확보되어야 한다는 근본적인 취지에 대해서는 동의한다.

개발 방법론에 대한 책들을 보면 공통적으로 드는 생각이, 역시 만병 통치약은 존재하지 않는다는 것이다. 작지만 좋은 방법들이 있고, 그 방법들이 서로 어울릴 수 있게 모일 때 좋은 개발 방법이 되는 것 같다.

XP Installed의 이해를 높이기 위해서 앞으로 읽어야 할 책들. 위에서부터 아마도 먼저 읽을 것 같은 순서.
테스트 주도 개발
Pair Programming Illuminated
Pragmatic Programmer
리팩토링 : 온 동네 품절이다. 가진 사람 찾아서 제본해야 할 듯. 아님 원서를 사던가.