지난 6월 27일에 있었던 모임이니 2주도 지났지만 휴가도 갔다오고 하다 보니 이제야 정리합니다.(너무 지나서 귀차니즘에 건너뛸까도 생각했습니다만...)
이 책은 너구리님이 2년 전에 쓰신 테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구가 출간할 때 베타리더 등으로 참여했던 사람들을 대상으로 너구리님이 책을 쓰고 2년이 지나면서 달라진 생각, 지금의 생각 등을 공유하기 위해서 만든 자리였습니다. 사실 어떤 시나리오가 있는 세미나가 아니라 너구리님이 자신의 생각을 공유하면서 자유롭게 토론을 하는 분위기였기에 정리하기가 쉽지 않지만 대충 임의로 정리해 봅니다. 여러 사람들이 얘기를 나누어서 누가 말씀하셨는지는 다 기억하기 어려워서 생략합니다.
잘 안된다...
책을 쓰고 2년이 지나면서 배운 점은 TDD가 잘 안된다는 점이라고 하셨습니다. 다른 사람을 설득하려고 했지만 결과적으로 잘되지 않았고 이게 원래 안되는게 아닐까라는 생각이 들었습니다. 과거 CBD(Component-Based Development)가 실패했던 이유에 대해서 많은 얘기가 오갔었는데 그 당시에 CBD가 필요한 상황이 없었거나 받쳐줄 기술이 제대로 갖추어지지 않았으며 장사꾼(?)들이 개입하면서 왜곡되기 시작했고 CBD로 무엇을 하는가에는 관심이 없고 무엇을 얻는가에 너무 집중되어 있었다는 얘기가 있었습니다.(전 CBD는 잘 몰라서....) 어떤 인식이 공유안된 상태에서 새로운 것을 도입하는 것은 상당히 힘들다는 것에 대부분 공감하는 것 같았습니다.
너구리님은 약간 회의적인 시각으로 보셨지만 반대 의견들도 있었습니다. TDD가 실패라면 반대로 성공은 무엇인가를 정의하는 것은 어렵고 OOP도 성공했다고 말하기에는 많은 반론이 있을 것입니다. 이런 면에서 재능이 포터블한가?에 대해서 생각해 볼 수 있는데 시도는 많이 하지만 대부분 잘 되지 않고 이동하는 순간 효과가 확 떨어지는 결과가 대부분입니다. 그럼에도 믿음이 의지력을 만든다고 생각하기 때문에 된다고 믿으면 실제로 되고 안된다고 믿으면 실제로 안될 수 있습니다.
왜 안되는가?
기술이 받쳐주지 못해서 못하는 경우는 거의 없고 실제로도 하는 사람들은 다 TDD를 하고 있습니다. 하지만 시도와 중요도를 기준으로 했을 때 자꾸 뒤로 밀리는 경향이 있습니다. 외견상의 현상만 봤을 때는 문제가 무엇인지를 알지 못하거나 개발자들이 변화를 계속해서 시도하지 않는 문제가 있고 밥 아저씨처럼 "참 쉽죠~"해서 신기했지만 감동도 잠깐이고 어렵고 커버리지 압박등으로 재미도 없는 것 같다는 얘기도 있었습니다.
어떻게 하면 잘 할 수 있는가?
이건 어찌 보면 어떻게 하면 개발을 잘 할수 있는가의 문제입니다. 한가지 방법은 TDD를 잘하는 사람을 관찰하는 것입니다. 너구리님은 일단 TDD를 한다고 했습니다.(책의 저자이기도 하니...) 협력업체 직원같은 경우는 그냥 원래 그렇게 하는거라고 하면 대부분 잘 따라온다고 합니다. 오히려 위험한 사람이 우리 팀에서 가장 잘하는 개발자입니다. [이 부분에 대해서 상당히 공감을 한다.. 나도 현재 협력직? 계약직? 입장인데 어차피 새로운 업무를 맡거나 정규직이 이렇게 해주시고, 어떤 패턴으로 해주세요 라고 요청을 하면, 그 업체에 맞게끔 해주는게 맞기 때문에 조금은 불편하거나 생소하더라도 오히려 기존 세력?? 보다 더 쉽게 받아들이는건 맞는 듯 하다..] 이런 개발자는 보통 코드가 어려운 데다가 테스터블하지 않은 코드도 뛰어난 능력으로 테스트코드를 만들어버리기도 하기 때문에 이런 개발자의 TDD를 보고 배우는 건 위험합니다.
2년동안 보니 다음과 같은 조건의 사람들이 TDD를 잘 합니다.
- TDD의 경험이 있는 사람(장점을 기억하고 있는 사람)
- Divide and Conquer를 잘하는 개발자
- 협동작업을 잘하는 개발자
- 계획하기
- 확인할 방법 생각해보기
- 실행하기
- 기능 요구사항이 명학한지 확인하기
- 머리속으로 단계를 그려보기
- 종이에 적어보기
- 단계별로 확인할 방법을 생각해 보기
- 코딩 시작
책을 쓸 때와는 달라진 생각들
많은 개발자가 Mock에 흥미를 가지지만 대부분의 경우 Mock으로 불필요한 코드들이 생기게 된다.
짝 프로그래밍은 TDD에도 많은 도움이 된다. 짝 프로그래밍에 대해서도(이것도 엄청나게 큰 하나의 주제이므로) 많은 얘기가 오갔는데 짝 프로그래밍에는 소셜 스킬이 중요하다는 얘기가 나왔습니다. 물론 이는 짝이 같은 가치관을 가지고 있지 않으면 짝 프로그래밍이 무척 어렵다는 얘기부터 시작된 것이지만 가치관이 다른 경우 소셜스킬로 해결할 수 있다는 얘기로 이어졌습니다.(이 얘기가 더 맞는듯 합니다.) 대부분 짝 프로그래밍을 가르칠 때 소셜 스킬을 가르치지 않기 때문에 문제가 발생하는데 중요한 사건들은 화면이 아니라 두 사람 사이에서 발생합니다. 그래서 김창준님은 짝 프로그래밍을 조언할 때 화면이 아니라 짝 프로그래밍을 하는 두 사람을 촬영해서 가져오기를 요구한다고 했습니다. 그래서 프로그래밍이 아닌 두 사람간의 문제가 생긴다는 것을 미리 알려주지 않으면 짝 프로그래밍을 하면서 당황하기 때문에 어떤 상황이 생길 수 있고 어떻게 해결해야 하는지 얘기해 주어야 한다고 했습니다.
그리고 이런 얘기를 하는 가운데 김창준님이 don't는 약한 표현이기 때문에 don't를 얘기할 때는 do를 함께 얘기하는게 좋다고 하셨는데 이부분이 꽤 인상적이 었습니다. ~~를 하지 마라만으로 부족하고 대신 ~를 해라까지 나아가는게 좋다는 것이지요. 그리고 대부분은 문제를 감지할 수 있는 방법을 알려주는 것 좋은데 if()로 상황을 주어도 그 조건을 대부분을 감지해 내지 못한다는 얘기셨습니다. 그래서 구체적으로 문제를 감지할 수 있는 방법까지 알려주는게 좋다는 얘기였습니다. [이 부분도 공감이 되는 글귀다.. 햄이 표현하고자 하는 혹은 김창준 님이란 분이 말씀하시는게 내 생각과 의미가 통하는지는 모르겠으나.. 어떤 부분에 대한 문제를 지적 혹은 알려만 주는 것보다는 왜 그렇게 되었는지 혹은 이 부분으로 인해서 어떻게 되고, 해결법에는 어떠한 좋은 것이 있다고 알려주거나 힌트를 주는게 좋다고 생각한다.. 사람들이 가장 큰 실수를 하는 것이 설명을 할 때 자신이 알기 때문에 상대도 알것이라고 생각하고 생략을 하는 것이 많다.. 또한, 본인은 문제점을 간파했기 때문에 당연히 이 사람이 어떻게 조치를 하겠지.. 라고 생각을 할 수 있지만, 상대방이 그것을 알았다면 애초에 지적을 받지 않았을 것이다.. 조금만 더 상대를 배려?? 또는 풀어서 설명해주는 습관이 모두에게 중요하다고 생각이 든다..]
내 생각....
일단 저는 TDD가 실패(?)했다고 생각하지 않는 쪽입니다. 실제로 TDD를 해보면 재미있기도 하지만 때때로 무척 귀찮을 때도 상당히 존재하는데 실제 프로덕션레벨로 나가면 또 상황이 달라지는 것 같습니다. 실배포전에 수정한 내용의 오류르 테스트케이스로 발견했을 때(물론 이는 TDD가 아니라 나중에 유닛테스트를 만들어도 같지만 그냥 뭉뚱구려 얘기합니다.) 테스트케이스를 작성한 보람을 느끼게 됩니다.
또 한편 이게 오픈소스나 공개소스로 넘어가면 얘기가 또 완전히 달라지게 됩니다. TDD는 좀 귀찮기도 하다는 생각을 한다고 하더라도 어떤 오픈소스를 가져다 쓸 생각을 하면 테스트코드가 얼마나 잘 작성되어있는가가 주요한 판단 기준이 되며 소스를 오픈소스로 제공한다고 생각하면 제 코드의 신뢰성을 증명하는데 테스트케이스 만한 것은 없습니다. 실제로 오픈소스 프로젝트들을 보면 대부분 테스트케이스를 작성하고 있으면 코드를 수정해서 제출하더라도 테스트코드를 같이 제출해야 하는 경우가 대부분입니다. 이런 면에서 TDD는 꽤 많이 자리 잡았다고 생각합니다.
암튼 마지막 정리하면서 의견을 낼 때 아직 너무 어려워서 더 쉬워져야한다. 라는 얘기가 있었습니다. 이 말이 제 머릿속에 오래 머물렀었는데 어려운 게 사실이고 그런식으로 생각해 보진 않았기 때문입니다. 많은 프렉티스가 공유되고 정보가 많아지면서 이전보다 쉬워지긴 했지만 여전히 어려운 것은 사실입니다. 하지만 더 쉬워져야 한다에는 공감하지만 쉬워질 수 있는가?에 대해서는 회의적입니다. 다른 얘기를 하면 건강을 유지하려면 음식을 조절해야 하고 운동을 규칙적으로 하고 잠을 충분히 자야합니다. 물론 그렇게 하는 사람도 있지만 직장생활을 하면서 음식조절을 하고 규칙적으로 매일 운동해서 건강하고 좋은 몸은 유지하는 것은 쉽지 않은 일입니다.(그래서 대부분 배가 나오죠.) 그럼에도 건강해 질 수 있는 지름길 같은 것은 존재하지 않고... 운동안하고 먹고싶은거 다 먹으면서 건강하고 날씬한 몸을 유지할 수 있는 방법도 없습니다. 많은 사람이 운동을 규칙적으로 못한다고 잘못된 방법이라고 생각하지도 않습니다. 비슷한 이치가 아닐까요? 좋은 소프트웨어를 만드는 것은 원래 어려운 일이고 여기에 은총알이나 지름길 같은 건 없습니다. 더 많이 생각하고 더 많이 해보고 하는 거지요.(머 그런의미로 이날의 논의가 이뤄졌다고 생각하진 않지만요.)
머 요즘은 그냥 할 수 있는 범위 내에서는 TDD를 해보려고 노력하면서 기술적인 부분에만 관심을 가지고 근본적인 내용에 대해서 고민해 적은 별로 없었습니다. 그냥 노력해야 할 것으로만 생각했을 뿐이지요. 간만에 TDD에 대해서 그 의미에 대해서 많은 생각을 해보고 의견을 들어볼 수 있는 좋은 모임이었습니다. 그리고 너구리님의 엄청난 인맥으로 이날에는 한자리에 모이기 힘든 대단하신 개발자들이 많이 모였는데 끝나고 생각해 보니 단체사진이라도 하나 찍을걸 그랬다는 아쉬움이 남더군요. ㅎ
My Comment..
이 글은 내가 TDD 를 해본적도 없고 햄의 블로그를 통해서 알게 된 것이기에 갖고 올까 고민을 하였다.. 머 언제나 그렇듯이 나에게 있어서 좀 애매한 글들은 고민을 하게 되고 읽어본 후 결정을 한다.. 그래서 역시나 이 글도 읽어보고, 내가 TDD 를 한 것은 아니지만, 나름 공감가거나 내가 하고 싶은 말도 떠오르게 되서 갖고 왔다.. 언어의 영역은 틀리지만, 어느정도 공통성이 있는 것처럼 최초의 주제는 내가 모르는 것일지라도 결국 IT 내에서 일어나는 일들이거나 프로세스이기에 공감가는 부분이 있는 듯 하다..
댓글 없음:
댓글 쓰기