한빛출판네트워크

이 글에서는 테스트 주도 개발(Test driven development)이 어떻게 활용되고 이점은 무엇인지, 이를 사용했을 때 팀들이 직면할 어려운 점은 무엇인지에 대한 관련 자료와 연구를 검토해보았다. 

 

기존 소프트웨어 개발의 진행 과정은 선형적이다. 하지만 수십년간 애자일 시스템이 대중화됨에 따라(무려 87%이나 되는 팀은 애자일이나 애자일과 비슷한 방식을 따른다) 소프트웨어 개발은 프로젝트의 요구 사항과 특성에 따른 다양한 방법론을 수용하기 시작했다. 

 

테스트 주도 개발(TDD, Test-driven development) 기술은 애자일 소프트웨어 개발 분야에서 주목받고 있는 방법 중 하나이다.

 

전기전자학회(Institute of Electrical and Electronics Engineers, IEEE)에서 발행된 연구 논문에서 저자 Yahya Rafique와 Vojislav Misic는 "TDD (Test-Driven Development)는 익스트림 프로그래밍 (XP) 개발 프로세스의 기본 관행 중 하나"라고 정리한다(출처).

 

TDD를 개발해냈다고 한 사람은 2003년에 “TDD는 단순한 설계를 촉진시켜주며 자신감을 불어 넣어준다” 라고 말한 바가 있다(출처). 하지만 TDD의 생산성이나 품질 클레임에 대한 의문은 남아있다.

 

이 클레임들을 테스트하기 위해 최근 TDD 통계 자료를 수집하는데 주의를 기울였다.

 

이 글은 TDD의 개념 정의와 기존 방식과의 차이점을 기점으로 시작한다. 그런 다음 TDD에 대한 클레임을 입증 및 반증시킨 통계 자료 몇 가지를 살펴보겠다.

 

테스트 주도 개발이란? 

TDD는 소프트웨어 개발자가 테스트를 실행할 프로덕션 코드를  만들기 전에 테스트를 먼저 작성하는 방식이다. 이 기술의 기본적인 발상은 실제 코드를 작성하기 전에 코드 작성자가 전체적인 설계나 요구 사항에 대해 생각하는 시간을 주는 것이다.

 

TDD는 실제 코드를 작성하기 전에 코드 작성자로 하여금 전체적인 설계나 요구 사항에 대해 생각하는 시간을 준다.

 

 

TDD의 과정

1. 테스트 작성: TDD의 시작은 모든 새로운 기능은 테스트를 작성하는 것이다. 프로그래머는 기능의  모든 명세(specification)와 요구 사항에 대해 완벽히 이해하고 있어야한다. 개발 중인 새로운 코드의 방향을 이해하기 위해 유저 스토리와 사례들을 살펴보면 된다.
2. 테스트 실패: 프로그래머가 테스트 작성 후 실행해본다. 아직 구현할 코드가 없기 때문에 테스트는 실패한다. 이건 결국 자동화된 테스트 프레임워크가 제대로 작동되고 있다는 걸 입증해주고 오류가 있는 새로운 테스트가 성공될 가능성을 항상 없애준다.
3. 코드작성: 이제 프로그래머는 어떻게 기능이 설계에 따라 작동하는지 안다. 이제 성공시킬 수 있는 코드를 작성한다. 그 코드가 완벽하지 않을 수도 있고 테스트를 제대로 통과할 수 있지만 상관없다. 그 테스트에서 확인하기 위해 만들어진 기능 그 이상의 코드를 작성하는 것을 바라는 것이 아니다.
4. 테스트 실행: 기능이 설계된대로 작동되는 것을  안다면, 새로운 최신 업데이트가 기존 기능을 건드리지 않는다는 것이 확인 되었기에 프로그래머는 새 코드를 만들어낼 때마다 테스트 관리 도구를 사용하여 테스트를 다시 실행해볼 수 있다.
5. 리팩터 코드: TDD는 코드 베이스가 늘어날 수록 꾸준히 정리해주어야한다. 이전 단계에서 프로그래머는 코드를 작성하는 것에 중점을 두었다면, 이제는 효율성이다. 외적인 특징들을 살리며 프로그램의 소스 코드의 내적 구조를 개선시켜준다. 이 단계는 중복을 없애며 새로운 기능들을 추가하게 해준다.
6. 반복: 위 단계들을 TDD 주기가 모든 기능을 커버할 수 있게 자동으로 반복한다.

 

TDD와 기존 개발 방법의 차이점

TDD를 잘 이해하기위해 기존 방식부터 프로그래밍에 따른 차이점에 대해 알아보자.

 

가장 큰 차이점은 기존 방법들은 선형적인 프로세스를 거친다면 TDD는 주기적인 프로세스를 거친다는 것이다.

 

기존 테스트 방법을 사용하는 프로그래머들은 코드 작성을 시작으로 개발 프로세스 마지막 단계에서는 테스트만 집중한다. 반면에 TDD 모델 사용자는 테스트를 먼저 생성하고 그 후에 테스트에 맞는 코드를 개발한다. 이런 접근 방식은 소프트웨어 테스트의 “Shift left movement”의 많은 원칙들을 공유한다.

 

기존 방식을 쓰는 프로그래머는 코드의 정확성에 대해 집중할 수 있지만 모든 코드 오류를 잡아낼 수는 없다. 반면 TDD를 사용하는 프로그래머는 코드를 리팩토링하며 테스트가 성공할 때까지 코드를 작업한다. 이 작업은 코드가 기능에 충족될 때까지 이루어지기에 결국 버그를 줄일 수 있다.

 

TDD는 기존 테스트 개발보다 느리다, 빠르다?

TDD가 프로그래밍 프로세스를 빠르게 해준다는 여부와 관련하여 다양한 소스로부터 상반된 통계 자료들이 나온다.

 

Microsoft와 IBM팀 소프트웨어 엔지니어들의 사례 연구는 TDD 기술을 사용했을 때 “팀들은 초기 개발 시간이 15-35% 정도 늘어났다” 라고 결론지었다. 하지만 이 숫자들은 “경영진에서 주관적으로 추정한” 수치라고 언급한다.

 

품질이 개선되었다는 Microsoft와 IBM의 연구의 관점에서 보았을 때, 만약 장기적으로 본다면 TDD는 나중에 결함들을 고쳐야하는 시간을 절약해줄 수 있다고 볼 수 있다. Microsoft와  IBM 팀들도 이 주장에 동의했다. 

 

TDD를 사용할 때 경험많은 전문가들의 초기 인식에 대한 연구는 “어디서부터 시작할지 이해하고 기능을 위해 아직 존재하지도 않은 테스트를 만드는 방법에 능숙해지는 초기 어려움을 극복해내면, 참가자들은 새로운 기능들을 구현하고 광범위한 테스트 범위로 인하여 수정하게 될 때 더 큰 자신감을 얻게 되었다” 라고 결론을 짓는다. 이는 시간이 지남에 따라 상황이 개선된다는 걸 말해준다.

 

온라인 출판 플랫폼인 Medium.com에서 글을 쓰는 프로그래머이자 책 “Composing Software”와 “Programming JavaScript Applications”의 저자인 Erick Elliot은 TDD가 그의 삶을 어떻게 변화시켰는지에 중점을 둔다. Elliot은 이 프로세스가 처음에 얼마나 느려질 수 있는지에 대해 지적하지만  “2년정도 지난 어느 시점에서 마법 같은 일이 일어나기 시작했다. TDD를 안썼을 때보다 단위 테스트를 통해 코딩을 훨씬 더 빠르게 하기 시작했다.” 라고 말했다.

 

TDD는 처음 초기 단계에서 느려 보인다. 하지만 장기적으로 보았을 때 더 높은 품질의 코드로 절약된 시간이 초기 단계에서 쓴 시간을 상쇄시켜줄 수 있다. 또한 프로그래머들이 TDD에 능숙해지는만큼 더 빨리 작업할 수 있게 해준다고 볼 수 있다. 

 

높은 품질의 결과물을 만들기 위해서 시간이 얼마나 걸리는 지 측정하려면 많은 요인들을 고려해봐야한다. 

 

TDD가 버그를 줄여주는가?

위에서 TDD의 주요 장점 중 하나는 버그가 적다는 것인데 과연 통계 자료는 어떨까?

 

위에서 언급된 Microsoft와 IBM 엔지니어링 팀의 연구는 “TDD 방식을 사용하지 않은 유사한 프로젝트에 비해 4개 결과물의 시험판 결함 밀도가 40% 에서 90%까지 감소했다.” 라고 발표했다. 특히 IBM 팀은 결함 밀도가 40%, Microsoft는 60-90% 감소되었다고 한다. 

 

TDD의 높은 품질에 대한 통계 자료는 어떠한가?

핀란드에서 열린 IEEE(전기전자학회)의  2007년 첫 번째 국제 심포지엄에서 발표된 연구 결과를 기반으로 Maria Siniaalto와 Pekka Abrahamsson은 TDD로 개발되지 않은 소프트웨어와 비교할 때 TDD가 더 나은 코드 품질을 생성한다는 것을 발표했다.

 

그들의 논문에서는 TDD가 프로세스 트래킹과 작업 판단을 향상시켰다는 중국에서 진행된 연구를 인용한다. 동일한 연구에서는 “TDD는 또한 다음과 같은 일관된 관행과 가이드라인을 개선한다”라고 정리한다. 결과적으로 더 적은 오류와 품질이 높아진다. 또한 TDD를 사용한 팀은 오류를 더욱 더 빠르게 수정할 수 있었다.  

 

평균 약 10년 전문 경험이 있는 개발자들이 TDD를 활용했을 때 그들의 인식을 조사하기 위한 연구에서는 “TDD는 코드를 더 읽기 쉽고 개선하는데 도움을 주었다” 라고 말한 개발자를 예로 든다. 또다른 참가자는 “TDD는 더 나은 유지보수를 가능케해준다”라고 말했다. 

 

TDD는 단순한 설계를 도와주는가?

North Carolina State University 컴퓨터학부의 Boby George와 Laurie Williams는 24명의 프로그래머를 두 그룹으로 나누는 실험을 했다. 한 그룹은  TDD를 사용하고 또 다른 그룹은 선형적인 방식을 사용하게 한 것이다.

 

그들은 참가자들 중 “92%는 TDD가 높은 품질의 코드를 생산해낸다고 여겼고, 79%는 TDD가 단순한 설계를 이끈다고 생각했으며, 71%는 이 방법이 특출나게 효과적이었다라는 의견을 냈다”라고 발표하였다.

 

품질에 관한 이 TDD 통계 자료는 TDD가 실제로 높은 품질의 코드와 단순한 설계를 이끈다는 강력한 근거이다.

 

 

한 연구에서는 참가자들의 79%가 TDD가 단순한 설계로 이끌었다 라고 말했다.

무료 학습 포털 사이트 Guru99.com에서 게시된 한 글에서 Kanchan Kulkarni는 “TDD는 코드를 더 간단하고 명확하게 해준다. 또 개발자들이 적은 문서량을 유지하게 해준다.” 라고 얘기했다.

 

TDD 설계를 따르는 것은 쉬운까?

George와 William의 실험에 따르면 전문 개발자들의 56%는 TDD의 사고방식은 적응하기 어렵다고 믿었고 23%는 초기 설계 단계가 없기 때문에 이러한 어려움이 생긴다고 주장했다. 전체 답변 중 40%는 TDD에 적응하기 어렵다라고 대답했다.

 

이러한 TDD 적응에 관한 통계는 TDD가 적용되기엔 어렵다고 보인다.

 

TDD는 과대평가 되었는가?

머신 러닝, AI, 인프라,  DevOps 및 애자일에 관심이 있는 자칭 풀스택 소프트웨어 개발자인 Tylor Borgeson은 Medium.com에 게시된 글의 제목을 <“TDD는 과대평가 되어있다(Test-Driven Development is Overrated)”>라고 짓는다. 하지만 이 제목에 인용부호를 사용하여 썼다는 것은 사실 그가 말하려는 건 상반된 내용이라는 걸 암시한다.

 

Borgeson은 이 방식이 과대평가 되어있고 느리다고 말하는 사람들은 대부분 이 방법을 장기간 동안 사용해보지 않았다고 지적한다. 그리고 그는 “그럼 이제 TDD로 고통을 안 받을 때까지 가서 연습해보아라” 라고 하며 글을 마쳤다.

 

****

Ben Aston는 QA Lead의 공동창업자이다. Dare, Wunderman, Lowe 및 DDB를 포함한 영국 런던에 있는 제일 큰 디지털 업체들에서 15년 넘게 근무하며 디지털 산업에 종사해왔다. 영화에서부터 CMS, 게임부터 광고, 그리고 eCRM에서 eCommerce 사이트에 이르기 까지 모든 분야를 일해왔다. Land Rover, Volkswagen 및 Honda를 포함한 자동차 브랜드나 BT, British Gas 및 Exxon같은 유틸리티 브랜드, 또 Unilever와같은  FMCG 브랜드, Sony를 포함한 소비자 가전제품 브랜드 등 운좋게도 다양한 분야의 훌륭한 고객들과 일할 수 있었다. 

 

원문 : Statistics & Studies: The Benefits Of Test Driven Development

번역 : 김정욱