본문 바로가기

Books in Life/2009

익스트림 프로그래밍(Extreme Programming)


2007년 초인가.. 이 유명한 익스트림 프로그래밍(Extreme Programming)이란 책을 읽은 적이 있습니다. 하지만 제대로 기억나지 않는 관계로 얼마전에 이 책을 다시 읽게 되었습니다.

책장속에서 먼지를 털어내고 다시 이 책을 읽게 된 계기는 "이제 XP란 것을 새롭게 이해할 필요가 있을 것 같다"라는 생각 때문입니다. XP에 대하여 깊은 이해가 부족하다고 최근 느꼈기 때문입니다. 그리고 XP가 이제 프로그래밍 문화 속으로 파고 들고 있다는 확신이 들었기 때문입니다.

사실 저는 XP(혹은 agile)라는 이야기를 처음 들으면서 우리가 기존에 생각해 왔고, 그리고 일부 적용하고 있지만, 제대로 그 효과를 알 수 없었던 것들의 집합 이라는 생각을 했었습니다.

짝 프로그래밍(Pair Programming)이란것이 무었입니까?
XP가 무엇이라고 말하던간에 어찌보면 선배와 후배가 같이 나란히 앉아서 하나의 코드를 보면서 디버깅을 하는 모습이 짝 프로그래밍의 한국적인 모습이라고 생각합니다. 저 뿐만 아니라 많은 프로그래머들이 그동안 함께 일하는 후배들과 동료들과 선배들과 나란히 앉아서 디버깅을 하였을 것입니다.

저역시 문제가 발생할 때마다 나란히 앉아서 문제를 해결하곤 하였습니다. 이는 XP가 나오기 전부터 했던 방식입니다.

그리고 지속적 통합(Continuous Integration)이란 무었입니까?
소프트웨어 개발시 일정 수준의 개발이 이루어지면서부터 많은 시스템들이 지속적 통합을 하여 왔습니다. 물론 주기는 다를 수 있습니다만, 초기에는 느슨하게 통합되다가 시스템이 일정 수준이상 개발되면서 빠른 속도로 지속적으로 통합되곤 하였습니다. 여러분이 만든 프로그램이나 컴포넌트나 인터페이스가 다른 모듈에 영향을 미치고 있었고, 통합을 위한 테스트를 계속 실행하여 왔다면, 일정수준이상 지속적인 통합을 실천해왔다고 생각합니다.


이런 면에서 이 책을 처음 읽었을 때 사실 전 개념을 모아 놓은 후 새로운 개념인듯하게 포장하는 또 다른 개념서 정도로만 생각했습니다. 사실 많은 책들이 이런 식으로 새로운 개념을 이야기하곤 합니다. 특히 영미권의 개념서 중에 이런 책들이 많습니다.

하지만, 이 책을 다시 읽게된 결정적인 이유는 XP가 이제 하나의 문화가 되었다고 생각되었기 때문입니다.
XP에서 말한 실천방법들이 우리가 그동안 해왔던 것이든 아니면 새로운 것이든 간에, XP가 추구하는 하나의 프로그래밍 문화가 우리들 사이에 널리 퍼지고 있으며, 실천되고 있다는 것입니다.

이제 많은 프로그래머들이 의사소통을 잘 할 수 있는 방법들을 찾고 있으며, 팀웍의 중요성이나 인간적인 프로그래밍을 할 수 있는 여건 등에 관하여 제대로된 의식을 가지게 되었습니다. 이 점에 있어서 XP가 많은 역활을 해 왔다고 생각합니다. 즉 XP가 프로그래밍 분야에 새로운 시각을 제공했다고 볼 수 있습니다.

최근 다른 책들을 읽으면서 반대로 이러한 점들을 느꼈으며, 그래서 이 책을 다시 읽게 되었습니다.
이 책을 읽으면서 새롭게 그리고 신선하게 다시 XP를 느낄 수 있어서 좋았습니다. 이 책이 유명한 이유를 다시 느끼겠더라구요 ;-)

중요하다고 생각되는 부분들은 다음과 같습니다.
참고하세요~




익스트림 프로그램(Extreme Programming, XP)의 목표는 뛰어난 소프트웨어 개발이다. 소프트웨어를 더 적은 비용으로, 더 적은 결함만 가지게, 더 높은 생산성으로, 훨씬 투자 대비 회수율이 높게 개발하는 일은 가능하다. 지금은 고생에 허덕이고 있는 팀이라도 자신이 일하는 방법에 깊게 주의를 기울이고 그 방법을 다음으면, 그리고 일반적인 개발 신천방법들을 극단까지 밀어붙이면 이런 결과를 얼마든지 얻을 수 있다.


좋은 관계는 좋은 비즈니스를 만든다. 생산성과 자신감과 코딩 또는 일과 관련된 다른 활동들 뿐만 아니라 일터의 인간관계에도 영향을 받는다. 일에서 성공하려면 기술이 있어야 할 뿐만 아니라 좋은 인간관계도 맺어야 한다. XP는 두가지 모두를 다룬다.


XP의 정의는 변화하였다. 2판의 정의는 다음과 같다.
  • XP는 가볍다. XP에서 고객을 위한 가치를 창출하기 위해 꼭 필요한 일만 한다.
  • XP는 소프트웨어 개발의 제약 조건들을 다루는 것에 바탕을 둔 방법론이다.
  • XP는 팀 규모와 상관없이 할 수 있다.
  • XP는 모호하거나 빠른 속도로 변화하는 요구사항에 적응하는 방법론이다.


아울러 "XP란 무엇인가?" 에 대한 켄트 백(Kent Beck)의답변이다.
  • XP는 오래되고 효과가 없는 사회적 습관들을 버리고 효과있는 새로운 습관들을 채택하는 것이다.
  • XP는 오늘 내가 기울인 모든 노력에 대하여 자신을 인정해 주는 것이다.
  • XP는 내일은 좀 더 잘해보려고 애쓰는 것이다.
  • XP는 팀 전체가 공유하는 목표에 내가 얼마나 기여했는지를 잣대로 자신을 평가하는 것이다.
  • XP는 소프트웨어 개발을 하는 중에도 여러분의 인간적인 욕구 가운데 일부를 채우겠다고 요구하는 것이다.


XP는 현재의 현실에 딱 맞는 새로운 방법을 위하여 옛날에 일하던 습관을 버리는 것을 의미한다.


XP는 개발을 이끌기 위한 다섯가지 가치를 포용한다. 그것들은 의사소통, 단순성, 피드백, 용기, 존중이다.


책임감은 누구에게 할당할 수 있는 성질의 것이 아니다. 책임감은 오로지 책임질 마음이 있는 사람이 받아들일 수 있을 뿐이다. 누군가 여러분에게 책임을 지우려 한다 해도, 책임감을 느낄지 그렇지 않을지는 오직 여러분 자신만이 결정할 수 있다.
받아들인 책임(Accepted Resonsibliity)의 원칙을 반영하는 실천방법의 한 예는, 어떤 일을 하겠다고 서명한 사람이 그 일의 평가도 내리는 것이다.
책임이 있는 곳에는 권위도 따라온다 책임과 권위가 잘못 연결되면 의사소통이 왜곡된다.
(우리나라에 대부분의 중간 관리자 이상이나 소위 화성인이라고 불리우는 소프트웨어 아키텍트들이 꼭 읽어봐야 할 부분이라고 생각합니다.)


XP  팀에 대한 조언은, 설계 투자를 단기에 최소화하라는 것이 아니라, 시스템의 지금까지의 필요에 비례하도록 설계 투자를 유지해가라는 것이다. 문제는 설계를 하느냐 마느냐가 아니라, 언제 설계를 하느냐이다. "점진적인 설계"는 최적의 설계시점이란 경험에 비추어 결정된다고 말하는 실천방법이다.


XP에서는 다음과 같은 사람이 가치있는 직원이다.
  • 다른 사람을 존중하는 행동을 한다.
  • 다른 사람과 잘 어울린다.
  • 솔선수범한다.
  • 자신이 약속한 것을 지킨다.


소프트웨어는 사람이 개발한다.


결함은 효율적인 소프트웨어 개발에 필요한 신뢰를 파괴한다. 고객은 소프트웨어를 신뢰할 수 있어야 한다. 관리자는 진행상황 보고서를 믿을 수 있어야 한다. 프로그래머는 서로 신뢰할 수 있어야 한다. 결함은 이런 신뢰를 깨뜨린다. 신뢰가 없다면 다른 누군가가 잘못했을 가능성에 자신을 보호하느라 많은 시간을 소모하게 된다.




이 책을 다시 읽으면서 강하게 들었던 확신은 결국 XP란 사람사이에 관계를 가장 자연스럽게 풀어내기 위한 방법론이며, 사람들의 관계를 바탕으로 소프트웨어의 생산성을 높이기 위한 문화이다. 입니다.

그 어떠한 좋은 실천 사항도 사람들간에 자연스러운 문화가 형성되지 않으면 제대로 실천되지 못할 것입니다. 초기 XP가 국내에 많이 적용되지 못했던 근본적인 이유가 제 생각에는 문화적인 차이가 컷기 때문입니다. 하지만 이제 XP나 agile에 대한 사상이 많이 전파되면서 자연스럽게 문화가 형성되고 있으며, XP의 가치를 근본적으로 받아들일 수 있는 사람들도 많아지고 있다는 생각이 듭니다. 저도 그중에 한 사람이구요 :-)

여튼 다시 읽은 XP 좋았습니다. ;-)