최근에 거장들이 방한하고 있습니다.
며칠 전 GoF의 디자인 패턴으로 유명한 Ralph Johnson과 Erich Gamma 가 방한하더니 이번엔 XP로 유명한 Kent Beck이 방한합니다.

방한 중 세미나와 워크샵이 열리는데 'Being Agile(애자일이 되기)'란 주제인 워크샵은 비용이 180만원(VAT제외시) 정도 됩니다. oTL

어쨌든 다행히 세미나는 8만8천원(VAT포함)이며 냉큼 등록했습니다.
세미나의 주제는 'Responsive Design: When, How, and What (반응적 설계 : 언제, 어떻게, 무엇을)' 입니다.
2009년 9월 4일 강남역 과학기술회관에서 열립니다.
재미있는 것은 세미나 일정 중 사인회가 있습니다!
'13:00-13:20 저자, 역자 사인회 (인사이트 제공) 및 휴식'

기대됩니다. 현재 제가 가진 Kent Beck 책으로는 TDD(번역서), XP(번역서), Implementation Patterns(원서) 이 있습니다. 20분 동안 다 받을 수 있을지 모르겠네요!

그러고보니 사인회 말고 기념촬영 시간은 없는데 추가 되면 좋겠군요!
흑흑 뭐 혼자 등록했기 때문에 찍어달라고 할 사람도 없지만...



Kent Beck 의 TDD는 개발자를 인간답게 만들어주는 방법론입니다.
그것은 이론일 뿐이며 Real World 에서는 그렇게 진행할 수 없다는 사람은 다음의 그래프를 보시기 바랍니다.


이것은 최근에 임성현 기술사님을 통해 알게된 자료입니다.
IBM과 MS에서 각 프로젝트 별로 TDD를 하는 팀과 그렇지 않은 팀으로 진행된 연구결과이며 TDD 진행 팀이 그렇지 않은 팀에 비해 15~35%의 개발지연이 발생했지만 39~81%의 오류가 극적으로 감소한 것으로 보고되었습니다. 

이번 그래프는 오류가 발생하는 시점이 코딩 시점에 80% 가 집중되어 있으며 그 때의 처리비용이 극히 낮다는 것을 보여줍니다. QA 조직 혹은 통합 테스트 시에 오류를 발견하고 수정하는데에는 비용이 급격하게 증가합니다. 이미 배포된 후에 발견된 버그를 수정할 경우 또 다른 버그가 생기는 일도 흔하게 발생합니다. 이것을 모두 테스트하는 것은 인간적인 일이 아닙니다. 이것이 가장 중요합니다. 인간주도형 회귀테스트는 인간적이지 않습니다.

그럼에도 불구하고 TDD는 정말 어렵습니다. 유닛 테스트를 도입하는 것도 정말 어렵습니다. Real World 의 프로젝트는 수많은 난관이 존재합니다. 혼자 작업하는 코드에는 고려하지 않았던 수많은 변수가 있습니다.

이 모든 것을 도입하는데에는 고통이 따릅니다. 용기도 필요합니다. Dependency가 극도로 증가되어 있는 프로젝트에 섣불리 도입했을 때엔 그 Side Effect로 인해 프로젝트가 좌초될 수도 있습니다. 그래서 저는 요새 Legacy 프로젝트에 큰 영향을 미치지 않으면서도 조심스럽게 도입하는데 큰 관심을 가지고 있으며 어느 정도 성과도 거두고 있습니다. 약 5년 정도 된 프로젝트이며 이전 Legacy 코드들 까지 합하면 8년, 아니 그 이상된 코드들입니다.

TDD! 힘들어도 지금 당장 아주 간단한 것에서부터 시작하세요. 새로운 프로젝트만이 가능한게 아닙니다. 이미 배포된 프로젝트에서 문제가 발생된 경우도 가능합니다.
버그가 보고되면 테스트 코드를 작성하여 해당 버그를 재현하며 그 테스트를 통과하기 위해 코드를 수정합니다. 여러 테스트 코드를 추가하여 다시 테스트를 통과시키기 위해 코드를 수정합니다. 무엇보다 테스트가 모두 통과하면 안심이 됩니다. 그리고 나중에 해당 코드를 수정하게 되면 다시 이전에 작성해놓은 테스트 코드를 돌려 회귀 테스트를 수행합니다.
그리고 가장 중요한 것! 개발하는 것이 즐겁게 됩니다. 당신은 기계에서 인간이 되는 느낌을 받습니다. 

Real World 에는 수많은 암초가 있는 것 같습니다. 기술적 문제만이 아닌 거지요. ROI도 고려해야 하며 역량 문제도 있습니다. 사람들의 마음, 관계, 정치적 문제까지...
그런 문제를 제외한 채 기술적 문제만을 보아도 상황이 쉬워보이지 않습니다. TDD를 하려고 보면 설계부터 문제가 되는 거지요. 따라서 '프로그램은 왜 실패하는가?(원제: Why Programs Fail?)'에서는 처음부터 디버깅을 염두에 둔 설계가 중요하다고 역설합니다. 모든 것은 부메랑처럼 돌아오게 되어 있습니다. 유닛 테스트 혹은 TDD 도 만능이 아닙니다. 무수히 자라 밀림이 되어버린 정원을 마법처럼 가위손의 정원으로 되돌려줄 은탄환은 존재하지 않습니다.

그럼에도 불구하고 지금이라도 조금씩 정원을 가꾸는 좋은 기술들을 익혀나가는 겁니다.
그러면 언젠가 정원일에 익숙해져서 좋은 기회가 왔을 때 그 기회를 놓치지 않을 수 있을 겁니다.
밀림을 가꾸려는 조그만 발버둥질. 그 움직임이 당신을 인간답게 만들어 갑니다.

저작자 표시
Posted by eritaka