실무에서 TDD의 장담점과 의사결정

소프트웨어 공학에서 학문적으로 말하는 TDD의 장단점과 실무에서 느끼는 장단점에는 차이가 있음.
여기에서는 현업에서 실무자들의 피드백을 바탕으로 정리함

1. 시간과 비용을 증가시킨다
   • TDD는 평균적으로 1.5배의 시간과 비용을 증가시킴
     잘짜여진 테스트 코드를 작성해야 하기에 당연한 결과임. 비용이 높다는 것은 변화에 굼뜨다는 것이기에, 자주 빠르게 요구사항이 변화하는 부분은 TDD에서 제외하기도 함
   • TDD 투자비용을 회수하는 시기는 보통 2-3년 이후
     현업의 연구보고서에 따르면 평균적으로 2-3년 후 부터, 극적인 효과를 볼 수 있다고 함. 예를들어 수년 후에 팀이 개편되거나 입퇴사로 사람이 바뀌는 경우 교육이나 적응기간이 필요하기 마련인데, TDD코드를 작성해두었다면 사람과 무관하게 일관된 Quality를 유지할 수 있기 때문
      
     반대로 유행에 민감한 소프트웨어, 매년 변하는 SW는 TDD의 효과를 보기 전에 코드의 수명이 다하기에, 오히려 TDD가 독일 수 있음. 2-3년 후에도 살아 남을지 성공여부가 불활실한 초안, 실험적인 개발이나 스타트업에서는 TDD를 도입하지 않는 것이 장점일 수 있음
   • 모든 비용을 지불하고도 Quality가 우선적으로 보장되어야하는 경우 적합
     사용자 수가 많은 글로벌 서비스, 신뢰도가 무엇보다 중요한 금융서비스, 많은 사람이 참여하는 대규모 프로젝트(혹은 오픈소스 프로젝트)는 TDD가 적합
2. TDD는 코딩의 영역이 아니라 QA의 영역
   • 소프트웨어 개발을 3단계로 나눌 때 분석 및 설계, 구현 및 코딩, 테스트 및 QA로 나뉘는데 TDD는 코딩이 아니라 QA에 해당함. 즉 Quality를 보장하기 위한 활동에 속함. TDD는 테스트 및 QA 단계에 소요되는 비용을 줄이기 위한 기술임
   • 코딩을 담당하는 개발팀과 TDD를 담당하는 QA팀을 분리함
     테스터와 개발자를 분리하는 것처럼, TDD를 작성하는 팀과 소프트웨어를 작성하는 개발팀으로 분리하는 경우가 일반적임. 코딩과 TDD를 동일한 팀이 진행하는 것은, 개발자가 혼자서 개발과 테스트를 다하는 것과 같은 비효율을 가져옴. 버그를 만들어낸 사람은 버그가 있는지 모르기 때문에 TDD코드와 소프트웨어 개발코드는 서로 다른 사람이 개발하고 서로 교차검증을 할 수 있게 해야함
   • TDD를 포기하고, 전통적인 테스트 방법을 선택하기도 함
     현업에서는 소프트웨어의 성격에 따라 TDD를 도입하지 않는 의사결정을 내기도 함. 이 경우 대안으로 테스트팀(QA팀)을 따로 뽑고 전통적인 방법으로 Quality를 향상시키게 됨
      
     수년 이상 장기간 서비스되고, 변화에 둔감하며, Quality가 무엇보다도 우선된다면 TDD가 나은 선택일 수 있음. 예를들어 OS, DB, 금융서비스, SNS, Utility 등은 TDD를 통한 이점을 얻을 수 있음
      
     반대로 유행에 민감하거나, 일회성, 일시적인 게임, 홍보물, 엔터테인먼트 성격의 앱, 매년 수차례 요구사항이 변화하는 분야, 2-3년 뒤를 알 수 없는 실험적인 개발이라면 TDD 대신 별도의 테스트를 진행하는 것이 나은 선택일 수 있음
3. TDD는 만병통치약이 아님
   • TDD는 Quality를 향상시키기 위해 선택할 수 있는 하나의 수단임
     수단이 목적을 지배하는 오류에 빠지지 않도록, TDD를 맹신하지도 말고 유연한 시각으로 도입할지 때로는 제외할지 판단 하는 것이 필요
   • 기성복이 아닌 맞춤복을 만든다는 생각으로 접근해야함
     무엇을 아는 것과 실행하는 것은 다른 영역이고, 학문적인 접근과 실무적인 접근은 차이가 나기 마련임. TDD를 도입할 때는 현장의 목소리에 귀를 기울이고 시행착오를 조정해 나가며 조직에 어울리는 문화로 녹여내야 하는 것이지, 학문적인 내용만으로 단시간에 효과를 볼 수 있는 만능열쇠가 아님