Small Steps Blog

심야에 네이버 스몰토크 카페 멤버들과 채팅을 나누다 테스트 주도 개발 이야기가 나왔습니다. TDD로 문제 풀이를 해봤지만 생각보다 쉽게 진행되지 않는다는 것이 시작이었습니다. 테스트 주도 개발에 대한 제 의견을 조금 얘기해 보겠습니다.


장기적인 관점과 단기적인 관점을 들어서 얘기하는 것이 좋을 것 같습니다.


단기적인 관점으로 보았을 때 TDD를 적용한다고 하여 문제를 더 잘 풀게 되는 것이 아닙니다. 조금 안타깝죠? 하지만 TDD를 쓰지 않고 못푸는 문제를 TDD를 쓴다고 풀 수 있는 것이 아닙니다. 그렇다고 이득이 없지는 않습니다. 풀었을 때의 품질(외적 품질, 내적 품질)이 더 낫다거나 더 빠르게 풀었다거나 하는 이득을 얻을 수 있습니다.

개발을 진행하는 과정을 문제를 풀어내는 것으로 볼 수 있습니다. 이때, 문제를 작은 수준에서 풀어서 크게 키워나가는 것과 문제를 해체하여 개별적으로 풀어내어 합성해 나가는 두 가지 접근이 모두 필요합니다. (위의 두 가지 접근 방법은 김밥나누기를 참고하세요. '썰기'와 '해체하기'로 설명되어 있습니다.) 그런데 TDD에 익숙하지 않은 경우에는, (저 또한 그랬지만)  키워나가는 방법, 즉 썰기라는 무기만 가지고 문제에 접근합니다. 그러다보니 문제를 풀어낼 최소한의 아이디어 없이 일단 덤벼서 더이상 키울 수 없는 한계를 느끼게 되는 경우가 많습니다. 이럴 때 '뭐야 TDD도 별거 아니네' 혹은 '아직 나에게 TDD는 멀었나 보다' 혹은 '이런 문제에는 적합하지 않군' 하고 생각하곤 합니다.
 
썰어서 키워나가는 것도 개발 수준이며, 문제를 해체하는 것도 개발 수준을 반영하는 것입니다. 즉 TDD를 사용한다 하더라도 적절한 작은 단위로 썰어내어 그것부터 시작하여 키워나갈 수 있는 능력과, 문제를 구성하는 요소들로 해체하여 각각을 풀어내는 능력이 없으면 테스트를 만들기가 어렵습니다. 즉 어떤 순서로 어떤 테스트를 만들것인가 하는 테스트 수준이 바로 개발 수준을 드러낸다는 것이죠. (허진영 님의 글에도 잘 설명되어 있네요.)


장기적인 관점에서 보면, TDD는 우리들의 개발 수준(즉 테스트 수준)을 향상시켜주는 좋은 도구입니다. 테스트 코드를 만드려는 시도를 하는 과정에서 점점 실력이 향상되는 것을 경험할 수 있습니다. 간혹 그런 경우가 있습니다. 거의 완성이 되어가는데 결과가 조금 이상합니다. 이리 바꿔보고 저리 바꿔보고 하다보니 어느샌가 잘 동작합니다. 저는 이런 경우, 코드에 끌려왔다라고 표현합니다. 하지만 TDD로 개발할 때는 자신이 통제하지 못하는 상황에서 앞으로 나아가기가 어렵습니다. 처음에는 조금 더 더딜수는 있지만 TDD를 통해 개발을 자신이 통제하려는 의식적인 노력 과정에서 많은 학습이 이뤄지는 것 같습니다.

켄트 벡조차도 자신이 테스트할 수 없는 새로운 환경에 맞닥뜨리면 테스트할 수 있을 때까지 개발을 진행하지 않습니다. 다양한 시도를 통해 학습하고 결국 테스트할 수 있게 되는 순간, 즉 자신이 통제할 수 있게 되는 순간부터 개발을 시작한답니다. 그 기간이 몇 개월이 걸릴 수 도 있구요. (이건 조금 꿈같은 이야기네요 ^^)


이런 맥락에서라면 굳이 TDD를 이용할 필요가 있느냐 싶을 수 있지만, 앞서 언급한 것 처럼 장기적으로 학습 효과가 더 크고, 단기적으로 (자신의 능력범위 안에서) 더 나은 품질을 더 빨리 만들 수 있는데 그걸 마다할 이유는 없지 않을까요?