TDD, 테스트 주도 개발 이녀석아
만나서 반갑다
이렇게 말하면 뭐하지만, 나는 제대로 개발할 줄 아는게 하나도 없는 개발자다. 어쩌면 아는게 하나도 없을지도 모르겠다.
개발을 잘 모를때는 개발이 마냥 쉽고 재밌었다.
개발을 좀 하기 시작했을 때는 개발을 내가 잘 하는건 아닐까 생각했다.
그리고 비로소 개발공부를 몇 개월 정도 '진짜' 공부 처럼 하게 되면서
이젠 뭘 개발하기가 좀 무섭다. 잘 못 할거 같아서.
아는 게 우물 안일 때는, 그러니까. 그냥 작은 웹 서비스를 프론트 페이지와 웹 서버와 DB서버. 딱 이것만 있으면 별 장애도 없이 굴러가는 서비스만 만들고 보수하던 때에는 걱정이란게 없었고 모르는 것도 없었다. 그 때도 TDD란 이야기를 본 적이 있었지만, 무려 나는 '테스트가 왜 필요해? 잘 돌아가는 코드를 만들면 되지' 하는 허무맹랑한 생각을 갖고 있었다.
실패하는 테스트 코드로부터 출발해라. 이 말이 이토록 대단한 것일 줄이야.
테스트 주도 개발의 핵심은 이것이다. 네 코드가 실패했다고 말해줄 멘토가 항상 곁에 있을 것이다.
테스트코드는 바로 내가 실제 비즈니스 요구사항을 위해 만든 코드를 검증한다. 그리고 아마 첫 빠따라면,
혹은 테스트 코드를 먼저 선행해 만드는 좋은 습관이 있다면 내 첫 코드는 실패할 것이다. 그 편이 이롭기도 하다.
그 다음에 해야할 것은 단순하다. 비즈니스 요구사항을 다시 꼼꼼히 분석하고, 코드를 고친다. 테스트를 통과하면 이 테스트가 충분히 비즈니스 요구사항을 만족시키는지 다시금 생각해본다. 그리고 테스트 역시 개선할 수 있는 부분을 개선해본다. 소위, 엣지 케이스를 탐색한다.
그렇게 몇 번의 과정이 끝나고 나면 코드는 비로소 흠으로부터 어느정도 자유로워 진다.
그러나 이것이 끝이 아니다. 이것만이라면 나는 TDD가 그렇게 반갑지 않았을 것이다.
TDD는 실패 - 성공 - 리팩토링의 순환과정을 갖는다
리팩토링은 코드의 의미를 유지하며 더 나은 것을 만들어 내는 것이다.
많은 사람들이 코드의 가독성, 코드의 느슨한 결합, 코드의 추상화, 코드의 간결함 등을 이야기 한다.
그러나 어떻게 실천할 수 있는지는 상당히 막연하다. '좋은 코드' 또는 '깨끗한 코드'는 그 사람의 코딩에 대한 실력과 숙련도에 비례할 수밖에 없기 때문이다. 반대로 말하자면, 누군가 좋은 코드에 대한 지평을 넓혀주기 전에는 개선할 수 있는 수준 역시 고만고만하다는 것이다.
TDD를 익히면서 느끼는 것은, 테스트로부터 실패를 배우고 실제 코드를 고치는 과정에서 코드를 개선할 수 있는 부분을 반복적으로 검토하게 된다는 것이다. 그리고 이 과정이 '급하게' 비즈니스 요구사항만 어떻게든 처리하는 나의 코드를 훨씬 더 나은 레벨로 만들어 주는 것을 깨달았다.
이전에는 좋은 코드에 대한 욕심이 없었을까? 그렇지 않다. 그러나 막연히 좋은 코드로 짜야지 하는 것은 큰 도움이 되지 않는다. 구체적으로 좋은 코드를 위해 이미 만든 코드를 다시 읽고, 다시 생각하는 과정을 습관처럼 몸에 배게 해야하는 것이다. 그런 면에서 TDD 기법은 단순히 코드의 안정성을 높여주는 것을 떠나서 문제를 꼼꼼히 분석하고, 더 나은 해결법으로 진화시키게 하는 단계적 방법론이라는 생각이 들었다.
TDD는 늘 이슈를 끌고 다녔다. 누군가는 이것이 '낭비'라고 이야기 하기도 한다.
사실 내가 10년차, 15년차가 되어 정말 어떤 프로그래밍 언어와 분야에 깊은 숙련도를 갖게 된다면 테스트 코드 없이도 처음부터 상당히 최적에 가까운 코드를 짤 지도 모른다. 그러나 당장 고작 개발 경력 2년을 겨우 넘긴 나는 처음부터 그렇게 코드를 짤 수 없다. 즉, 숙련자들에게는 이 과정이 더 이상 필요없게 느껴질 수는 있을 지라도, 나처럼 아직 주니어 레벨 이하에서 발버둥 치는 사람들에겐 TDD의 방법론을 따라 코딩을 하는 과정이 그냥 개발을 하는 것에 비해 훨씬 더 실력에 도움이 된다고 느낀다.
아마 오랫동안, 많은 코드에 대해 TDD를 연습하게 될 것 같다.
그동안 막연히 두렵고 싫었던 TDD를 드디어 실천할 수 있게 되어 좋다.
