요즘, 이때다! 싶어 질러서 다시 보는 책들이 많다. 솔직히 전에 (지금도ㅠㅠ) 내공이 부족했던 터라 읽어도 그냥 맞는 말이네 - 싶던 책들이었는데, 다시 읽으니 주옥같은 이야기들을 재발견 하게된다. 아... 왜 난 남들보다 항상 몇년씩 뒤쳐지는건지 모르겠다. 엉엉 :'(

XP를 방법론이라고들 많이 하는데, 나는 거기에 좀 거부감이 든다. 솔직히 저자에게 완전히 공감할 수 없는 부분들도 (거의 없다 라기엔) 좀 있고, 저자가 지향하는 가치를 떠올려 볼 때 이런 것들을 적용하면 XP야 식의 유치한 이야기를 하고 있는 건 아니라고 본다. (지만 책이 좀 그런 느낌이다) 다르게 말하자면, 난 이 책에서 설명하고 있는 XP 실행법들을 하나하나 뽑아본 다음 몇몇 가지를 내가 하는 프로젝트에 적용해보는 짓을 할 생각이 전혀 없다. ... 뭐, 그것들이 나쁘다거나 아니면 내가 너무 잘나서 무시해야겠다 하는건 아니고, 그런 식으로 받아들이면 안돼! 라고 본능이 경고를 하고 있다는 것. 내가 속한 팀과 프로젝트에 대해서 더 생각해보고 최소한의 판단 근거가 될 만한 것들을 보기 전에 그냥 해보자 식으로 가져왔다가는 프로젝트가 완전히 말려버릴 것 같다. 언급된 방법을 사용할 수도 있겠지만, 그것은 이 책에 나왔기 때문이 아니라 지금의 나(와 팀과 프로젝트)에게 도움이 될 훌륭한 방법이기 때문이어야 한다.

책장을 덮고 나서 나에게 기억나는 화두들은, (책에 나오지 않는 표현임)

• Extreme communication
• Be opened, Be brave. Also be responsible for what you did.
• Short-term Feedback
• Automate it
• Be simple
• Execute it

이 정도. 그리고, 책을 다시 주루룩 넘겨보며 내가 줄을 그어두었던(내게 먹혔던, 혹은 기억해두고 싶었던) 문장들은 이런 것 들이다.

• 최선을 다하는 것과 의사소통을 명확하게 하는 것이 나의 몫이다.
• 내가 할 수 있는 가장 효율적인 방법으로 의사소통하는 것이 내가 의사소통을 가치 있게 여긴다는 것을 보여준다는 것이다.
• 내가 가치 있게 생각하는 것과 정말로 가치 있는 것 사이의 차이에서 낭비가 발생한다.
  반성은 행동한 다음에 온다.
• 무엇을 해야 할 지 모를 경우, 실패를 감수하는 것이 성공으로 가는 가장 짧고 확실한 길이다.
  고객이 무엇을 문제라고 말하든, 언제나 문제는 사람이라는 것이다.
• 어떤 결정을 내리든 그 결정이 올바른 상황은 존재한다.
• 자동화 테스트를 작성하는 것으로 한 주를 시작하라.
• 설계를 사용하는 시점과 가까운 때에 설계하는 게 더욱 효율적.
• 구현 순서는 기술적인 이유가 아니라 사업적인 이유에 따라 결정되어야 한다.
• 언제나 설계하라 - 오직 경험만이 충분히 좋은 설계를 만들 수 있을 정도로 문제에 대한 충분한 이해를 낳는다.

이런 철학으로 접근했을때 괜찮은 문제(혹은 작업, 프로젝트?)는 어떤 것 들일까? 뭐 언제나 받아들여질 만함 금언들이 다수이지만, 그래도 이 책을 읽고 나서 적당해보여? 라는 생각이 드는 카테고리로는, 이런거 - 팀이 한번도 해본 적이 없는 영역에 도전할 때 - 나 저런거 - 도전적인 기한/품질이 요구될 때 - 가 떠오른다.

... 하지만, 확실히 실천방법들이 아닌 철학으로서의 XP는 어디에든(개발뿐 아니라) 지혜가 될 수 있다(고 생각한다.) 그 와중에서도 가장 와 닿는 키워드 세개만 다시 뽑아보면, Short-term feedback, Automate it, Be simple.

일단 나는, UnitTest를 팀에 들고 가 봐야할듯. 다음 읽을 책은 TDD다.

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.