(이미지 협찬 yes24)

 

펭귄너구리 채수원님이 보내주신 TDD책을 어제 받았다. 지금까지 제법 많은 책을 우편을 통해서 받았지만 이 책만큼 기다렸던 것도 없었던 것 같다. 한동안 뜨겁던 TDD에 대한 열기가 막상 TDD를 적용하려고 했을 때 겪게 되는 막막함과 안티들의 큰 목소리 덕에 많이 식고 있는 느낌이었다. 디자인 패턴이니 SOLID는 하는 얘기만 들으면 온몸에 두드러기가 나고 환청이 들린다는 일련의 인간들은 TDD에도 역시 비슷한 이유로 비난을 퍼부어왔다. TDD만큼 닥치고-안티가 많은 것도 없다. 안티는 아닐지라도 TDD를 좀 더 나은 코드를 만들고 즐거운 개발을 하는데 사용할 수 있는 유용한 도구와 실천기술이 아니라 남들에게 우월감을 드러내고 잘난척하기 위해서 어설픈 지식으로 떠들어 대는데 사용했던 사람들도 사실은 TDD 슈도-안티군에 포함되야 할 것이다. 그러는 와중에 TDD에 대해서 오해하게 되고 거리감을 두게된 많은 개발자들이 있는 것을 보며 많이 안타까웠다.

안티에는 답도 없고 약도 없다. 그래서 신경 쓰지 않는다.

차라리 진지하게 TDD에 접근하려고 하지만 막연한 느낌과 무엇을 어떻게 해야 할지 알지 못해서 당황해 하는 사람들에게 좋은 안내를 해주고, 스스로 TDD와 테스트 코드 작성의 즐거움을 느끼게 해주는 것에 관심을 가지는 것이 나을 것이다. 그러기 위해서 몇가지 넘어야 할 장벽이 있는데, 바로 그 장벽을 낮춰주는 데 기여해줄 수 있는 것이 바로 이 책, "TDD 실천법과 도구"라고 생각한다.

펭귄너구리라는 아이디를 쓰는 채수원님은 내가 아는 가장 성실하고 진지한 엔지니어의 한 명이며 재치있고 유머감각 넘치는 이야기로 귀에 쏙쏙 들어오는 설명을 잘해주는 초특급 강사이기도 하다. 치열한 환경의 현장 개발자들에게 TDD를 가르치고 보급하려고 애쓰면서 가졌던 많은 고민과 생각을 풀어놓은 것이 바로 이 책이다. 그래서 이 책의 내용은 살아있고 싱싱하다. 그래서, 지난 몇년간 TDD를 사용하려고 애써왔던 나에게도 이 책은 참 소중하다. 매 페이지마다, 얼마나 많은 연구와 리서치를 했왔고 그것을 적용해보고 고민하는데 얼마나 많은 시간을 써왔는지를 느끼게 해주는 내용으로 가득하다.

이 책은 “TDD를 안하는 놈은 루저"라는 박탈감을 느끼게 해서 허둥지둥 TDD에 뛰어들어 고생과 삽질만 하고, 어디에 하소연도 못하면서 억지로 좋은 척, 아는 척 하게 만드는 그런 책이 아니다. 오히려 편안한 마음으로 TDD를 이해하게 해주고, 그동안 어설프게 TDD를 적용하다 받은 상처를 보듬어주고, 용기를 가지고 한발짝씩 TDD를 해보다가 어려움을 만나면 언제든 다가와 조력자가 되어 줄 수 있는 그런 책이다.

물론 이 책을 본다고 갑자기 TDD의 고수가 되는 것은 아니다. 김창준님이 추천사에도 썼듯이 TDD는 한번에 비급을 배워서 쉽게 마스터할 수 있는 것이 아니다. 오히려 충분한 시간을 들여서 고민하고 생각하고 많은 시도를 해보면서 차근차근 몸에 익히는 내공을 쌓는 훈련이 반드시 필요하다. 프로그래밍이라는 것이 원래 그렇듯이 TDD에도 정답이란 없고, 항상 더 나은 방법이 있을 것이라는 기대를 가지고 새로운 시각을 가지고 창의적인 접근을 하려는 노력이 동반되야 한다. 이 책에 소개한 내용이나 인용한 글들이 모두 정답이라는 생각을 가지기 보다는, 저자와 한판 붙어보자는 심정으로 책을 읽는 내내 가상의 토론을 즐기는 것도 좋을 것이다. 무엇보다도 꾸준히 작은 분량이라도 TDD를 해보는 습관을 들이는 것이 중요하다. 내가 작년초에 결심한 것 한가지는 TDD를 거창한 개발에만 사용하는 것이 아니라, 평소에 간단한 코드 하나를 만들 때도 사용하도록 습관을 들이자는 것이었다. 그 뒤로 HelloWorld 수준의 간단한 코드를 만들때도 항상 테스트를 먼저 만들어보려고 노력했다. 그리고 시간이 얼마 흐른뒤에 느낀 것은, 이전에는 TDD를 한다면 뭔가 힘을 잔뜩 주고 TDD를 해보고 말테다라는 긴장감 있었는데,  TDD를 코딩 습관으로 만들어버린 후로는 그냥 평범하고 자연스러운 것이 되어버렸다. 테스트를 따로 만든다가 아니라 테스트가 그냥 내가 당연히 만들어야 할 자연스러운 코드가 되어버린 것이다. JUnitMax가 테스트를 빌드과정의 하나로 만들어버린 것과 비슷한 느낌이다. TDD를 특별히 한다는 생각도 들지 않는다. 그냥 원래 코드는 그렇게 만드는 것이라는 습관이 들었고 그것이 편하고 자연스럽게 느껴지기 때문이다. 김창준님이 예전에 TDD를 제대로 하려면 최소한 6개월은 수련을 해야 한 기억이 (가물가물) 난다. TDD책을 보고 가끔 개발에 적용하는 시간이 아니라, 매일 빠짐없이 TDD를 좀 더 잘하기 위한 훈련의 시간을 30분에서 한시간이라도 잡고 그것을 6개월간 꾸준히 해야 한다는 얘기라고 생각한다.

이 책에 대해서 한가지 불만이 있다면 그것은 책이 너무 얇다는 것이다. 아이폰과 안드로이드, 트위터 따위가 장악해버린 출판시장에 비인기 종목인 TDD의 책이 나온 것만으로도 다행이라고 생각하지만 그래도 조금만 더 많은 얘기를, 좀 더 구체적으로 할 수 있는 지면이 허용되었더라면 좋았을 것을 이라는 아쉬움이 남는다.

하나 더 바라기는 이 책의 예제를 시연하는 동영상, 스크린캐스트가 공개되었으면 좋겠다. 나는 김창준님과 강규영님이, 그 무뚝뚝하고 어색한 목소리로 TDD를 진행하는 동영상을 우연히 본 것이 TDD에 관심을 가지게된 계기가 되었다. 이 책에 많은 그림과 코드가 잘 나와있긴 하지만 역시 TDD는 그 역동적인 과정을 눈으로 보는게 제맛이다. 수원님이 아니더라도 성실한 독자들 중에서 누군가 만들어 공개하지 않을까 기대도 해본다.

다음 주까지는 스프링 책을 마무리하는 최종 작업 때문에 바빠서 여유가 없겠지만, 그 후에 이 책의 내용을 차근 차근 정리해서 블로그에 올려볼 생각이다.

 

책을 주문하고 싶으면 여기. http://www.yes24.com/24/goods/3908398?scode=032&srank=1

저자의 책 소개를 보고 싶으면 저기. http://blog.doortts.com/128

나는 아닌데…

아니긴 뭐가 아닌가.

개발자라면 누구나 다 코드를 써내려가기 전 머리 속에서 간단한 테스트가 휘리릭 만들어진다. 이런 조건을 가진 경우 이렇게 액션이 일어나면 이런 결과가 나오겠구나. 그리고 코드를 몇줄 써내려 가고, 코드를 눈으로 따라 보면서 역시 머리 속에서 테스트가 돌아간다. OK. 이러면 잘 돌아가겠다. 생각이 들면 다음 기능으로. 아니면, 이거 좀 이상한데, 여기서 잘못된 값이 나오겠다라고 생각하고 수정으로 들어간다.

매우 짧고, 매우 불안정하며, 실수하기 쉽고, 용량이 감당이 안되서 결국 엉망으로 테스트가 돌아가게 되서 그렇지, 모든 코딩과정에는 머리 속에서 함께 테스트가 일어나기 마련이다.

사람의 두뇌라는게 매우 빠르게 복잡한 사고를 할 수 있기는 하지만, 양이 늘어나면 감당이 안되고 병렬로 처리도 잘 안되고 오류도 잘 나기 마련이다. 그래서 그 머리 속에서 일어나는 그런 코드를 보면서 하는 인간지능 TDD를, 밖으로 끄집어 내서 코드로 만들어버리면, 실수도 안하고 아무리 길고 복잡해도 불평한번 없이 알아서 수행해주는 컴퓨터가 그 귀찮은 일을 대신 해주는 것이다. 그런 사이 개발자는 맘편히 다른 문제에 더 집중할 수 있고.

어짜피 테스트코드를 사용하는 TDD를 못하는 사람이라면, 머리 속으로도 비슷한 작업이 그다지 잘 돌아갈 것이라고 생각되지 않는다. 그나마 두뇌의 스트레스를 줄여주는 쪽으로 하는게 결국 결과가 낫지 않을까?

코딩이란 걸 시작한 이후로 쭉 해온 습관이라 그럭저럭 돌아가는 인간지능 TDD를, 별로 안만들어봐서 어색한 코드로 표현하는 불편이 있긴 하지만 자꾸 노력해서 인간-컴퓨터 협력 TDD로 바꾸면 인생이 편해질 거다. 켄트 벡의 얘기대로 "맘편하게 잠자리에 들 수 있다". 맘편하게 데이트에 나갈 수 있고, 맘편히 휴가를, 맘편하게 가족과 시간을…

 

책에 들어갈 TDD 내용 좀 쉽게 설명하려고 생각해 본건데.. 좀 억지스러운가?

영회한테 배운 제목 낚시 연습으로는 뭐 괜찮은 듯.

좋은 글을 발견하면 깜찍하게 인용,정리하고 폼나는 자기 의견까지 버무려서 글을 쓰는데 탁월한, 위자드닷컴 2008추천블로거 영회가 단골메뉴 단위테스트에 대한 글을 올렸다. 마침 애자일 스프링 책의 테스트관련 챕터를 쓰고 있어서 관심이 더 가서 글을 읽어봤다.

결론은 이렇다.

읽고 보니 그렇다. 테스트를 하지 않고 머리속으로 테스트 하기 좋은 코드를 작성하거나, 작성한 뒤에 테스트를 하면서 수정하기 보다는 당연히 먼저 테스트를 할 때 테스트 하기 좋은 코드를 작성하기가 수월할 것이다. :)

정답이다.

개발자가  작성하는 테스트코드의 함정은 이미 만들면서 설계해놓고, 이상적으로 동작할 것이라고 가정한 방식을 따라 교묘하게 안전하기만 한 테스트를 만들기 쉽다는 것이다. 전문 테스팅 훈련을 받거나, 자신의 코드에 대해서조차 까탈스러운 개발자가 아니라면 이미 머리로 설계해가면서 다 만든 코드에 대해서 꼼꼼한 테스트코드를 작성하기 힘들다. 게다가 테스트를 나중에 작성하는 건 정말 지루하다. 또 영회가 인용한 글에 나오는 것처럼 테스트하기가 어렵거나 단위테스트가 아닌 통합/기능테스트가 막 짬뽕되어 만들어지기가 쉽다. 테스트를 먼저 작성해야 테스터블한 코드기 때문이기도 하다.

 

그럼 이런 비슷한 얘기를 지금까지 여러번 블로그에 올리면서 단위테스트 또는 TDD 또는 테스트우선방식에 대해서 강조했던 영회는 과연 그렇게 하고 있을까? 했다면 "읽고보니 그렇더라"보다는  "해보니 그렇더라"라는 글을 올리지 않았을까라고 살짝 의심이 가지만, 그간의 영회의 테스트에 대한 뜨거운 열정과 폭발적인 관심을 생각해보면… 흠?

비단 테스트우선이나 TDD가 아니라 자동화된 테스트코드 작성에 대해서도 마찬가지이다.

 

사실 좋다고 알고 있고, 좋다고 이야기하고 떠들어댈 수 있는 것과 실제로 좋기 때문에 꼭 실천하고 하는 것에는 많은 차이가 있다. 나도 TDD가 거의 대부분의 경우에 최고의 개발전략이라고 생각하고 열심히 실천하려고 하고 있지만, 어느 순간 보면 습관적으로 테스트없이 정신없이 코드를 만들고 있는 내 모습을 보고 놀랄 때가 있다. TDD만큼 많은 사람의 입에 오르내리고 인정받는 것도 없지만, 내가 관찰한 결과는 정말 극도로 사용되지 않는 기술이기도 하다.

물론 "나중에라도 JUnit테스트를 만들면 TDD 아니에요?" 하는 사람은 일단 제외하고.

TDD에 대해서 교육까지 시키고, 글도 쓰고, 인정하는 사람들 조차도 왜 실천하지 않을까? 제일 종종 듣는 답변은 "일정상 테스트 작성할 시간이 없어서.."인데, 그 역시나 "TDD가 결국엔 개발시간을 단축시켜준다"라고도 본인 입으로 얘기했던 사람들의 말이라 변명으로 들리지도 않는다.

 

좋은 걸 알면서도 실천 안하는 이유는 뭘까?

여러가지 이유가 있겠지만 나는 가장 큰 이유는 "사실은 정말 좋은 줄 알지 못해서"라고 생각한다. 사람이 말하는 것과 행동하는 것이 다른 큰 이유는 그 말이 진심이 아니거나, 마음 속에선 부정하는 부분이 있기 때문이다. 말로는 인정하지만 몸으로는 부정하는 것 아닐까?

물론 오랜 습관의 문제도 있겠고, 환경 탓을 할 수도 있고, 팀의 문화나 뭐 살인적인 개발일정 등등을 다 얘기할 수도 있겠지만, 개인적인 여유 시간에 작은 코딩을 하나 할 때도 테스트를 안만드는 것을 보면 그런 것들은 다 치사한 변명이었을 것이라는 의심만 든다. 차라리 "TDD해보니 별거 아닌 것 같다"라던가 "TDD는 실력이 아주 뛰어난 사람이 아니면 힘들다"라는 식의 답변이 더 솔직해 보인다. 그런 말을 하는 사람들은 어느 때가 되면 자신의 생각이 잘못됐음을 인정할 가능성이라도 있겠지만, 말로는 항상 좋다고 하지만 막상 현실에선 실천하지 않는 사람은 평생가도 못할지도 모른다.

 

김현국님의 회사 모토가 "개발하다 죽자"라던데, 적어도 TDD를 하려면 "TDD하다 죽자" 정도의 굳은 결심이나, "정말 테스트를 먼저 작성해야 좋은 코드를 작성할 수 있다"라는 진정한 확신과 "좋은 코드를 작성하는 개발자가 되고 싶다"는 열망이 함께 있어야 하지 않을까.

 

참, TDD하다 죽으면 안되니 "TDD하고나서 죽자"로 바꿔야겠다.

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha