TDD 가 도대체 뭐야?

길었던(?) 사다리 미션이 막을 내렸다. 한 줄로 요약하자면 ‘어렵고 즐거웠다’. 자동차 미션에 비해 난이도가 더 올라간 것도 물론이요, TDD 라는 굉장히 어색한 개발 기법도 한 몫 했다. 코딩보다 고민하는 시간이 더 길었는데, 구현도 구현이지만 TDD 라는 개발 방법론에 대한 고찰이 길지 않았나.

TDD 야 뭐 워낙 많이 들어온 주제고 프리코스 때에도 적용해보려 했던 경험이 있지만 ‘정말 효과적인 방법인지’는 대답하기 힘들었다. 마음에 얻는 안정감은 대단했지만 개발 속도가 현저히 느려지고 설계에는 크게 영향을 미치지 않는다는 느낌. 그냥 테스트나 많이 짜는게 낫지 않은가 하는 생각이 맴돌았다.(물론 잘 모를 때지만)

그러던 중 네오의 TDD 강의의 한 문구가 내게 확 꽂혔다.

TDD의 아이러니 중 하나는 테스트 기술이 아니라는 점이다. TDD는 분석 기술이며, 설계 기술이기도 하다. - 켄트벡, Test Driven Development by Example 중

TDD 의 방법론이 깔끔한 코드를 만드는데 좋다는 것(사이클 중 리팩터링 단계를 통해) 이미 사용해보았기에 잘 알고 있었지만 그 자체가 설계에 영향을 준다는 말은 굉장히 신선했다. 그게 사실이라면 내가 한 TDD는 TDD가 아닐지도 모른다는 생각이 문득 들었다.

궁금한 건 못참는다. 결국 TDD 책을 구매했고 (다 읽지는 못했지만 🤤) 켄트 백이 정말 이야기 하고 싶어하는 것이 무엇인지 조금은 이해하게 되었다. 그리고 프로젝트에 하나씩 적용해보며 나만의 TDD 개념을 쌓아나가고 있다.

스스로 답해보기

사다리 미션에도 여러 스스로 답해보기 문항들이 있었고 하나씩 고찰해보자(다는 힘들고 몇 가지 빠진 것들이 있다).

내가 TDD, 리팩토링을 하는 이유는 무엇인가?

가장 추상적이고 그래서 어려운 질문이다. ‘내가’ TDD 와 리팩토링을 하는 이유? 어떤 크루가 포비와 식사하며 들었던 포비의 질문과 일치한다는 이야기를 해주었다. 좋은 것은 알겠는데 그래서 내가 해야만 하는 이유가 무엇인지 설명하지 못하면 ‘그냥’ 하는 것이랑 다름없다.

깊은 고민 끝에 내가 내린 결론은 이러하다.

TDD 의 영향을 받은 프로젝트는 그렇지 못한 프로젝트 보다 수정할 일이 적고 있더라도 그 비용이 덜하다.

나는 가입자 400명, 일일 평균 사용자 100명 정도의 작은 프로젝트를 운영하고 있다. 또 실제 사용자들에게 피드백을 받기 쉬운 환경에 있기 때문에 프로젝트를 수정할 일이 많다.

실제로 서비스를 운영하던 중 일인데, 하나의 요청에서 수정하는 DB 테이블이 6개 이상, 바디에 전달되는 요소가 10개가 넘는 기능이 있었다. 수많은 if가 하나의 서비스 메서드에 몰빵되어 있는 형태였는데 하필이면 이 메서드에서 버그가 발생했다. 모든 워낙 경우의 수가 많다보니 모든 것을 일일이 포스트맨으로 쏴보며 확인할 수도 없는 노릇이기에 그제야 테스트 코드를 붙이려고 해봤는데 이게 보통일이 아니었던 것. 말하자면 완성하고 다 자른 누드김밥에 김을 한장씩 붙여서 걍 김밥으로 바꾸는 꼴이다. 이 경험은 내가 테스트 코드에 집착하게 된 계기가 되어주었고 이 패러다임에 더 사로잡힌 이유가 되었다.

TDD는 설계기술이지만 TDD 싸이클 그 자체가 그것을 보장해주지는 않는다. TDD는 한번에 해야하는 일(기능)의 바운더리를 작게 유지하게 함으로써 큰 일을 나누어 해결할 수 있는 시각을 넓혀준다. 그리고 이 작은 범위 하나하나를 적절한 객체에게 위임함으로써 완성도 높은 객체지향 설계에 도달한다.

실제로 미션을 구현하는 과정에서는 여러번 수정을 거친다. TDD로 개발한 프로젝트가 전과 달랐던 한가지 분명한 사실은 수정에 대한 두려움이 줄었다는 것. 기존 기능은 이미 작성한 테스트가 보장해줄 것이고 설령 변화할 일이 있더라도 기능을 작은 단위로 잘 나누었다면 그 범위도 작다.

‘동작하는 깔끔한 코드’ 를 만드는 것이 TDD의 목적이다. TDD 로 만든 프로젝트라면 일단 돌아가야 하며 동시에 읽기 쉽고 잘 설계된 코드여야만 한다. 나 또한 그런 코드에 지극히 공감하는 입장으로써 필요하다면 언제든 TDD 를 애용할 준비가 되어있다.

사다리 타기를 TDD로 진행하였는가? 그 과정에서 어려웠던 점은 없는가?

물론 어려웠다. 어색하기도했지만 가장 큰 이유라 함은 습관을 버리지 못함이 크다. 프로그램을 구현하는 방법은 크게 두가지가 있다고 배웠다.

Out -> In 접근 방식 vs In -> Out 접근 방식

둘은 다음과 같은 상황에 적합하다고 하는데

• Out -> In 접근 방식은 도메인 지식이 없거나 요구사항을 객체로 도출할 수 없는 경우 적합
• In -> Out 접근 방식은 도메인 지식이 있거나 요구사항을 객체로 도출할 수 있는 경우 적합

사실 정답은 없다. 사람마다 도메인을 이해하는 능력과 범위가 천차만별이니까. 다만 내가 어려웠던 이유는 무조건 완벽한 설계를 먼저 완성하려는 습관 때문인데, 최대한 작은 클래스부터 생각하고 TDD를 돌리기에는 나의 도메인지식이 부족했다.

이때부터 방법을 바꾸어 큰 범위부터 접근해보았고 내게 있어서 TDD는 이 경우에서 더 효과적이었다. 모든 설계가 그렇지만 완벽한 정답은 없고 TDD는 더 좋은 솔루션을 위한 도구라 생각하는 것이 적절하다.

해당 미션에서 작성한 본인의 코드가 만족스러운가? 다음 미션에선 어떠한 목표로 코드를 작성할 예정인가?

누가 자기 코드에 만족할 수 있을까? 적어도 난 아니다. 그래도 사다리 타기 미션은 내게 좋은 인사이트를 주었다. TDD 를 넘어 조금은 추상적이었던 좋은 설계, 좋은 코드의 기준을 세워볼 수 있었다.

다음 미션의 목표는 ‘누가봐도, 다시봐도 이해가 잘되는 코드’. 다음 미션이 한층 더 성장하게 되는 계기가 되길 바란다.