좋은 소프트웨어를 만드는 어떤 방식 하나, 테스트 주도 개발 (Test-Driven Development) : (하편)

- 상편에 이어서-

(후진 기억력이 크게 일조했지만) 그런식으로 해서 같은 책-테스트주도 개발(TDDBE)-을 5번이나 사서 읽었다.
그런데, 어느날 충격을 받았다.
내가 책을 주었던 어느 누구도 TDD를 업무에 적용하지 않는 것이다.

왜??

이유를 물어봤다.
물어본 사람들은 각자 몇 가지의 이유를 댔다.

1. 이상적인 이야기잖아요? 실제 프로젝트에서는 그런거 할 시간 없어요.
   
2. 어렵더라구요. 막상 적용해 보려면 뭐부터 어떻게 해야 할 지 모르겠어요.
3. 혼자서 좀 해보긴 했는데, 주변에서 하는 사람도 없고 그러다 보니 지쳐서..
4. 적용해 보자고 했더니 관리자가 Best Practice 사례를 보여 달라고 하더라구요. -_-;;
   

등등등...

맞는 말이다.  TDD는 쉽지 않다. 정확히 말하자면 기초를 배우기는 쉬운데 잘하기는 어렵고, TDD가 일상이 되고 습관이 되기는 훨씬 어렵다. 해야하는 이유보다 하지 못할 수 밖에 없는 이유를 대기도 더 쉽다.  대부분은 이런저런 이유로 포기하게 된다. 게다가 TDD를 적용해서 일을 하려면 동일한 작업을 하는데에 있어 평소보다 더 많은 노력이 들어간다. 익숙하지 않다면, 그리고 본인이 프로그래밍 자체를 즐기는 스타일이 아니라면, 30%쯤 시간이 더 든다고 생각하면 된다. 3달 걸릴 일이 4달쯤 걸릴거다.

이렇게 이야기하면 마치 TDD를 하지 말라는 얘기처럼 들릴 것 같다. 하지만 그렇지 않다. 원래 뭐든 포기해 버리면 쉬운 법이다. 하지만, 성공하는 사람이나 조직은 어려움을 포기하지 않는 사람이나 조직이다. 어줍은 조언일런진 모르겠지만 이런말을 해주고 싶다.

온갖 어려움이 있겠지만, 그래도 자신이 하는 일을 더 잘하고 싶고, 스스로가 더 발전하고 싶다는 욕망이 있는 엔지니어라면 TDD를 꼭 해봐야 한다.

남들과 똑같이 하고도 더 뛰어난 사람이 되거나 더 좋은 소프트웨어를 만들 수 있다고 생각한다면 그건 '사행심'이다. 잘 하고 싶으면 더 노력해야 한다. 더 잘 만들고 싶으면 남다른 노력들 수 밖에 없다.

소위 말해 '투자'를 해야 한다. (팀 차원에서 이루어진다면 좋겠지만, 안된다면 개인차원에서라도!)

예전에 누군가가 내게 해준 말이 하나 있는데 이런 시점에선 가끔씩 기억이 난다.

프로는 경기중에 연습하지 않는다.

전문가는 프로고 우리가 지향하는 방향도 프로다. 하지만 우리는 여러가지 이유로 연습은 하지 않고 경기만 한다. 때로는 연습할 시간이 없어서이기도 하고, 돈이 없어서이기도 하고, 연습을 도와줄 사람이 없어서 고독하거나, 아니면 연습한다고 꼭 잘하게 되는것 같지도 않는 것처럼 느껴서일 수도 있다. 이런저런 이유는 많다. 하지만, 연습하지 않고 경기만 한다면, 시간이 흐를수록 본인의 경기는 점점 지리지리 흐느적 해지기 마련이다.  좋은 경기를 만들고, 좋은 작품을 남기고, 좋은 소프트웨어를 만들려면 노력이 필요하다. 단언컨데 TDD는 그런 노력들 최고 중 하나가 되기 충분하다. 
(참고 :  테스트주도개발(TDD)를 배워야 하는 이유, TDD를 이야기 하는 이유)

[경기에 사용하는 도구에 피가 묻을 정도로 연습한 적이 있나요?]

어떻게 하면 그럼 TDD를 좀 더 잘 할 수 있을까?

1. 교육을 받자. - 찾아보면 TDD교육들이 있다. 정부지원 과정중에도 TDD 과정이 있는걸로 알고 있다. 정 안되면 본인을 불러도 된다. :) 교육은 짧은 시간내에 쉽게 지식을 전승받을 수 있는 좋은 방법이다.
   
2. 함께 할 사람을 찾는다. - 찾아보면 TDD를 하고 싶어하는 엔지니어들이 적지 않다. 그리고 가능하다면 짝프로그래밍으로 함께 해보자. 장담컨데 효과는 배가 된다.
   
3. 책을 읽자. - 시중에 괜찮은 책들이 몇 권 있다. 개인적으로 느끼는 난이도 순서는 다음과 같다.
   
   테스트주도개발 : TDD실천법과 도구 (채수원)
   -> 테스트주도개발 (켄트벡)
   -> .NET예제로 배우는 단위테스트(로이 오셔로브)
   -> xUnit 테스트 패턴(제라드 메스저로스)
   
   서점가서 살펴보고 본인 수준에 맞는 책으로 읽어 보자. ".NET예제로 배우는 단위테스트"의 경우 .NET기반이라 자바 개발자들에겐 조금 아쉽겠지만, 중간쯤에는 일반적인 단위테스트 작성법에 대한 이야기들이 많이 들어 있어서 그 부분만 읽어도 괜찮을 듯 싶다.
   
4. 자신의 업무에 적용해 보자. - 쓰지 않으면 배워도 잊혀지기 마련이다. 업무에 TDD를 적용해 보는 것이 필요하다. 단, 자신의 업무 전체를 TDD로 하려 마음먹지 말자. 작게 시작하는 것이 좋다. 이왕이면 변경이 잦거나 로직이 복잡하다고 생각하는 것부터 시작해보자.
   

이 외에도 더 있겠지만, 위 네가지부터 시작하면 좋을 것 같다.

자, 이제 이 글을 마무리 지을 시점이다. 이 글 상편을 시작한것이 봄이었는데 하편을 미루다 미루다 가을이 되었다. 사실 내가 하고자 하는 말은 이미 제목에서 다 했다고 생각한다. :)

좋은 소프트웨어를 만드는 어떤 방식 하나, 테스트 주도 개발 

좋은 소프트웨어를 만드는 여러가지 방법 중 많은 엔지니어들이 추천하는 테스트주도 개발(Test-Driven Development). 아직 시작안했다면 늦지 않았으니까 시작해 보길 권한다.

ps.
전편에도 손발이 오그라 드는 얘길 조금 썼는데, 후편에도 하나 해보자면, TDD를 어려워 하는 엔지니어들이 TDD 시작하는데에 도움이 되었으면 하는 마음에서 눈물의 책(이라고 쓰고 TDD실천법과 도구라고 읽는 책)도 썼다. 어떻게 생각할런지 모르겠지만, 난 나와 같은 업종에서 일하는 IT인들을 참 좋아한다. 같은 별에서, 그것도 같은 나라에서 같은 언어로 같은 일을 한다는 것이 얼마나 경이로우면서도 동질감 큰 인연인지 모르겠다고 생각하곤 한다. 좋은 음악은 함께 나눠듣고 싶은 마음처럼, 좋은 기술은 함께 공유하고 함께 성장하고 싶은 마음이 크다. TDD가 그런 기술이 되었으면 좋겠다.

ps2.
이런 저런 장점을 이야기 한다 하더라도 TDD를 해야 겠다는 마음을 먹는 건 여전히 쉽진 않다.

차라리 캘리포니아 금광(=아이폰 앱 대박) 같은 TDD관련 사례라도 퍼진다면, 무조건 달려가고 볼 개발자라도 많이 생길텐데 사실 그런 사례도 없다. 있어도 널리 소개 되질 않는다. 외국에는 많이 있고, 잘 된 사례도 많다고는 하지만, 이거야 원~ 이게 무슨 북미 신화도 아니고, TDD에 대해서는 '그랬었었~었대더라~' 식의 지인 통신같은 이야기만 잔뜩이다. 결국 나같았어도 쉽게 따라 뛰어들 용기가 생기지 않을 것 같다.

그런사실을 잘 알기에 국내 사례를 찾아서 여기저기 돌아다녀 봤다. 아쉽지만, 개인 차원의 이야기는 어느 정도 있었지만, 팀 단위로 TDD를 하는 경우는 직접 본 경우가 아직 없다. 우리 어른 들이 좋아하는 수치적인 자료와 함께 현재도 지속적으로 진행되는 모습을 보여줄 수 있는 사례는 더더 없지 싶다. (소개로 들은 바에 의하면 넥스트리 소프트라는 회사에서는 단위테스트 작성이 당연한 분위기와 문화가 되었다고 하는데 확인은 못해봤다. 어느 정도이고 어느 수준인지 정말 궁금하다)

그래도 한가지 고무적인 점은 사내(LG CNS)에서 TDD에 대한 사례가 조금씩 쌓여가고 있다는 점이다. 내년 정도쯤이면 의미있는 자료와 수치들을 공개할 수 있지 않을까 생각한다.