본문 바로가기

이생각 저생각

테스트주도개발(TDD)를 배워야 하는 이유, TDD를 이야기 하는 이유

오랜 만에 글을 올립니다. 왠지 그럴듯한 이야기나 가치있다고 여겨지는 기술 내용을 써야만 할 것 같은 중압감에 글을 잘 못 적고 있었습니다. 누가 압박을 주는 것도 아닌데 말입니다.

블로그 글쓰기를 다시 재개 할때는 역시 가벼운 이야기를 짧게 하면서 시작하는것이 답인것 같습니다. 그리고 이번 글은 별다른 퇴고의 단계를 거치지 않고 생각의 흐름대로 그냥 적어보려고 합니다. (어색해도 그러려니 해주세요 :)

오늘 하려는 이야기는 '왜 TDD를 배워야 하는가?' 그리고 '왜 Old fashioned IT Man인 제가 이렇게 질기게 TDD를 이야기 하는가?'에 대한 이유를 이야기 하려고 합니다. 600페이지에 가까운 책을, 그것도 기초적인 내용위주의 책을 써가면서 까지 말입니다.

사실 저는 약간 Geek스러워서 오래된 기술/제품 보다는 새로운 기술/경향에 더 열광하는 스타일입니다. 그런데도 나온지 10년이 넘은 기술(?)인 TDD를 이제와서 다시 이야기하려는데는 이유가 있습니다.

강의때 종종 하는 말입니다만, '현실을 변화시킬 수 없는 기술'은 그 한계가 명확하다고 생각합니다. 연구실 안의 기술, 책 속의 이야기일 뿐이기 십상이니까요.

어느날 문득 든 생각이 있습니다. 그간 등장했던 다양한 기술이나 테크닉이 과연 우리의 삶을, 특히 개발자의 삶을 얼마나 풍요롭게 해주었나? 하는 의문점입니다. 개발자의 삶이, 그것도 자신의 일을 천직이라 느끼고 살아가는 개발자에게 있어 일상이 어느정도 나아졌는가? 하는 질문이었습니다.

아이러니 하게도 제가 그동안 배웠던 기술관련 지식중 가장 오래 남아있고, 지금까지도 유효한 지식 하나는 언제 배웠는지도 제대로 기억이 나지 않는, 장치의 속도에 대한 지식입니다.

(빠르다) ------------------------(느리다)
CPU >  메모리 > HDD > Network



물론 까다롭게 따지고 들어가면 레지스트리라던가 L1캐시, L2캐시에, HDD와 Network의 전송량, 응답시간특성등등으로 복잡해 지지겠지만, 기본적으로는 위의 순서를 따릅니다.

어느 분야가 되었든 튜닝을 하는데에 있어 기본 원칙은 아주 분명합니다.
그리고 저는 이 기본원칙이 튜닝의 시작과 끝을 아우른다고 생각합니다.

'빠른속도의 장치를 더 많이 쓰도록 만든다'

'병목이 생기지 않도록 밸런스를 맞춰준다'

이 이외에는 튜닝이 아니라 '증설'이 답이 되니까요.
이 원칙을 위해서 트릭을 쓰고 기술을 적용하는 것일 뿐입니다.

기본원칙에 대한 생각이 견고해야 더 앞으로 많이 나아갈 수 있습니다. 그리고 새로운 기술을 접했을 때에도 더 빨리 더 잘 응용할 수 있게 됩니다. 기술 그 자체에만 집중하면 대부분 우왕좌왕하기 쉽곤합니다.

저는 TDD가 프로그래밍의 기본적인 원칙이자 근본 기술중 하나가 될 수 있다고 생각합니다. 많은 초보자들이 특정 언어의 문법을 배운 다음에는 보통 곧바로 프로그래밍에 들어가곤 하는데, TDD를 빨리 익히면 익힐수록 더 많이 더 빨리 진보할 수 있습니다.

저도 나름 어린시절부터 프로그래밍을 해봤다고 생각합니다만, 이십년 넘게 프로그래밍을 해왔던 시절을 되돌아보면 크게 두 부분으로 연대기를 나눌 수 있습니다.

TDD를 모르던 시절과 TDD를 배우고나서 실천하기 시작한 시절.

기간적으로는 후자의 기간이 훨씬 짧지만, 저의 프로그래밍 스타일과 프로그램을 대하는 방식, 그리고 제 삶에 있어서 여러가지 것들이 TDD를 배운 이후로 드라마틱하게 변화되었습니다.

프로그램과 삶에 대한 관점이 바뀌었다고 할까요?
프로그램이 만만치 않다고 느꼈고, 그러면서도 좀 더 즐길 수 있는 방법을 배웠고, 그리고 삶에 있어서 '실패'가 갖는 의미에 대해서도 다시 생각하게 되었습니다.

제 책 첫장에도 나옵니다만, 영화감독이자 배우인 우디 앨런의 한 마디.


'때때로 실패하지 않으면, 안이하게 살고 있다는 확실한 증거이다'

에 이르는 수준으로 제 삶에 있어 TDD는 확장되었습니다. :)

제가 더 어린 시절에 더 빨리 TDD를 배웠으면 어떻게 되었을까? 하는 생각을 하곤 합니다.

내년 부터는 언어를 막 배운 신입사원에게 TDD를 가르치려고 준비하고 있습니다. 저 혼자가 아니라 회사 차원에서 말입니다. 좋은 습관을 초반부터 만드는것이 중요하기 때문입니다. 그리고 주변의 많은 윗 분들께서도 제 생각에 동참해 주셨습니다.

TDD는 배우기는 쉽지만, 마스터하긴 어려운 기술입니다. 하지만 충분히 가치있는 기술이고, 프로그래밍을 하는 우리의 삶을, 그리고 주변의 모습과 세상을 변화시길수 있는 근본 기술 중 하나라고 저는 믿기 때문에, 앞으로도 조금 더 이야기 하고 다니려고 합니다.

한동안 Agile에 대해 제가 그랬던 것처럼 말입니다.

ps.
외국에서 Agile 기법중 가장 크게 효과를 본 기술 Top5와 가장 배우기 어려웠던(즉 제대로 실행하기 어려웠던)기술 Top5를 조사한 적이 있었습니다. 양쪽 다 순위에 포함된 기법 두 가지가 있는데, TDD와 짝 프로그래밍입니다. 배우긴 어렵지만 배우면 효과가 뛰어난 기술 두 가지인 겁니다.

제 생각은 이렇습니다.

고만고만한 기술 경쟁에서 남들 다하는거 더 잘 하려고 노력해서 우위를 차지 하기는 어렵습니다. 잘해야 반보 앞서거니 뒷서거니 하면서 출혈경쟁이 되기 쉽거든요. 차라리 남들이 어려워서 못한다고 생각하는 기술이나 분야를 '우리'는 잘해야 제대로 앞서 나갈수 있는 겁니다. 그게 블루오션으로 가는 길이고요.