Younghoe.Info (final edition)

채수원님으로부터 책을 증정받은 지가 한참인데 바쁘다고 잊고 살다가 일민형이 백년만에 쓴 서평을 보고 몇 자 덧붙인다. 일민형 서평에 완전 공감하는지라 "me, too." 라고 달아도 충분하지만 짧게 추가.

한마디로 정말 좋은 책이다. 이미 TDD에 익숙한 사람이라도 한번은 훑어볼만한 책이고, TDD에 익숙치 않다면 MUST HAVE 아이템이다. 이 책은 TDD나 자동화 테스트 실천에 필요한 꼭지를 두루 다루고 있다. 일민형이 책 분량이 적다고 아쉬워했는데 난 아이폰이나 플래쉬 책만큼 많이 팔리지는 않는다는 점이 아쉽다. 사실 그래서 더욱 값진 책이다. 열악한 시장성(?)에도 불구하고 집필한 저자의 노력과 의지의 결과물이니까.

책 Q&A를 위한 그룹스가 있다. '애프터'를 만들어가는 독자를 기대하며 찾은 김에 가입을 했다. 책 공식 사이트에 책에 실어준 인터뷰가 있길래 링크한다.

당신이 생각하는 TDD에서 나눈 대화 후에 내가 왜 TDD에 관심을 가졌던가 떠올랐다. 생각해보면 TDD라는 말을 사용하여 몇차례 강의까지 했음에도 불구하고, 아무도 TDD가 무어냐고 나에게 묻지 않았던 것 같다. 내가 TDD를 처음 찾은 것은 UP/RUP 혹은 CBD 방법론을 써서 UML 모델링을 할 때의 취약성 때문이었다. 설계 언어로써 UML은 한계가 많다. 결국, 10여년이 지났어도 UML은 설계서를 Unified 하지 못한 것 같다. 유용하게 쓰이는 것은 높은 추상화 수준에서 클래스 다이어그램이나 객체가 스무개를 넘지 않는 작은 시퀀스 다이그램정도다.

내가 과거에 답답했던 것은 가이드에 의해 만들어내는 UML설계모델의 수많은 다이어그램들이 별로 유기적으로 코드로 이어지지 못하고 있다는 점이다. 내가 만들어야 했던 것은 요구사항부터 구현으로 이어지는 전체 표준 프로세스였다. 결국 유스케이스에서 테스트케이스를 만들게 하고, 이 때 설계한 내용을 구현에 반영하게 했다. 그때, 해결하지 못했던 것은 요구사항에 대응하는 Acceptance test수준에서 컴포넌트 테스트, 그 하위의 클래스 테스트까지 체계화하고, 유기적으로 연계할 방법이었다.

그로부터 2~3년이 흘렀다. 토비형 질문을 통해 내 머리속에서 추출한 TDD의 정의는 내가 TDD를 어떻게 써먹었는가를 여실히 보여준다. 당시 내 입장에선, 지금 이곳에서 유용한 내용을 실천하는 것이지, 원론적인 TDD는 아니었으니까.(지금은 2~3년 전과 같은 상황이 아니고, 이젠 TDD를 Kent Beck이 정의한대로 이해할 필요가 있기 때문에 다시 TDDBE책을 열어봤다. Preface를 꼭 보시기 바란다. ^^)


2~3년이 지났지만, 밑줄친 저 부분에 대한 대답은 여전히 요원하다. 나비효과로 토비형과의 대화에서 'TDD에 어떻게 관심을 가졌는지'를 떠올렸지만, 밑줄친 과제(?)는 쉽게 잊지 못하는 것 같다. 내가 DDD에 관심을 갖았던 것도 거의 같은 이유다. UML을 소모적인 다이어그래밍에 쓰지 않고, 어떻게 설계모델을 구현에 유기적으로 반영할 것인가?

마침 다시 한번 모델링을 돌아볼 기회가 왔다. 어제부터 일을 잠시 쉬면 머리 속에서 모델링에 대한 아이디어가 모락모락 피어난다.