협업과 피드백을 중심으로 유연하게 일하고, 변화에 잘 대응하자는 Agile 개념에 대해 먼저 알아봤다. Agile의 핵심을 잘 이해한 후 소프트웨어 방법론 중 하나인 TDD를 살펴보자.
TDD
TDD란 Test Driven Development의 약자로 테스트가 개발을 이끌어 나간다라는 의미다!
TDD는 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스(Unit Test)를 작성하고, 이를 통과하는 코드를 추가하는 것을 반복하여 구현한다.
TDD의 구체적 행동 개념
보통은 Software의 개발을 할 때 코딩이 다 끝난 후 테스트를 진행한다. 여기서 코딩이 끝난 후란, 개발자 자신이 생각했을 때 코딩을 다 짜고 완성했다고 생각했을 때를 말한다.
TDD는 이 순서를 반대로 생각하여 테스트를 먼저 만들고, 테스트를 통과하기 위한 코드를 만드는 과정을 반복하여 피드백을 적극적으로 받는 것이다.
이렇게 반복적인 단계가 진행되면서 자연스럽게 설계가 개선되고, 소스코드가 간결해진다.
TDD의 추상적 개념
결정과 피드백 사이의 Gap을 인식하고, Gap을 조절하기 위한 테크닉이라고 할 수 있다.
Software를 개발할 경우, 특정 기능을 구현하기 위해서 '기능 구현을 위해 이 방법을 써야지', '이 부분은 특정 logic을 이용하고 특정 output을 얻어야지' 라는 결정을 하게 된다. 또한 실제로 프로그램을 개발하고 테스트할 경우 성공/실패(에러)라는 피드백을 받게된다.
필연적으로 이 결정과 피드백 사이에 갭이 생기게 되고, 이 갭은 커질수록 문제이고 내가 모른다면 더 문제가 된다! 이 둘 사이의 갭을 내가 인식하고, 테스트하는 과정을 반복하며 갭을 줄이는 테크닉을 TDD이라 할 수 있다.
Why TDD? Why Agile?
Agile 개념을 정리하면서 협력과 피드백을 중심으로 유연하고, 변화에 잘 대응하는 방식이 중요하다고 설명했다. 그렇다면 왜 협력과 피드백이 중요해졌을까?
초기 SoftWare의 개발은 계획 중심의 Process였지만, 90년대를 지나며 SW 분야가 넓어지고 사용자들이 일반 대중으로 바뀌었다. 또한 Business Cycle이 짧아지고 사람들의 욕구와 트렌드도 빠르게 변화하며 SW 개발의 불확실성이 높아졌다.
그리고 이러한 불확실성이 높을 때 바로 협력과 피드백이 빛을 발하는 것이다!
Agile과 마찬가지로 TDD도 협력과 피드백을 증진시키는 것이기 때문에 불확실성이 높을 때 도움이 된다.
TDD의 장점
-
보다 튼튼한 객체 지향적인 코드 생산
TDD를 통해 소프트웨어 개발 시 철저한 모듈화가 이루어지고, 그에 따라 종속성, 의존성이 낮은 모듈로 조합된 SW 개발을 가능하게 하며 모듈 추가나 제거에도 SW 전체 구조에 영향을 미치지 않는다. -
재설계 시간 단축
테스트 코드를 먼저 작성하기에 개발자가 지금 무엇을 해야 하는지 명확히 인식하고 개발을 시작한다. 따라서 전반적인 개발 설계가 변경되는 일을 방지할 수 있다. -
Debuging 시간 단축
Data가 잘못 나올 경우 DB 문제인지, 레이어, UI 문제인지 실제 모든 레이어를 전부 디버깅해야 하지만, TDD를 적용할 경우 Unit Test를 전제로 하므로 특정 버그를 손쉽게 찾을 수 있다. -
추가 구현의 용이성
개발이 완료된 SW에 기능을 추가할 경우 기존 코드에 어떤 영향을 미칠지 알 수 없어 우려될 수 있지만, TDD는 Unit Test를 전제로 하므로 테스트 기간을 획기적으로 단축할 수 있다.
TDD의 단점
- 생산성의 저하
개발 속도가 느려진다고 생각하기에 TDD를 반신반의하는 사람들이 많다. 처음부터 2개의 코드를 짜면서 진행해야 하고, 중간중간 테스트를 통해 고쳐나가야 하기 때문에 일반적인 개발방식에 비해 10~30% 정도 소요시간이 증가한다고 한다.
TDD를 실제로 적용하기 어려운 이유
개발 시간의 증가
TDD는 단점에서 언급했던 것처럼 생산성의 저하가 존재한다. 많은 기업이 단기적인 성과에 집중하고, 전체 개발시간을 줄이는 것보다 오늘 일을 끝내는 것을 강조한다. 실제로 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하게 여겨지므로 TDD 방식을 잘 사용하지 않는다.
TDD를 적용의 어려움
TDD는 이제까지 자신이 개발하던 방식을 많이 바꿔야 한다. 따라서 이미 몸에 체득한 것이 많을수록 바꾸기 어렵고, 오히려 개발을 별로 안해본 사람에게 적용하기가 쉽다.
TDD는 이렇게 해야된다는 이미지/틀의 존재
사람들이 반드시 Tool이나 Framework를 이용해서 개발해야된다라고 생각한다. 그래서 결국 규칙에 얽매여 같은 테스트를 copy&paste하고, 도구나 규칙에 집착하게 된다.
Agile의 핵심은 유연성과 변화에 잘 대응하는 것인데 이렇게 규칙에 얽매이는 것은 Agile이 아니고, 그렇기에 TDD 개념도 적용하기 힘든것이다.
How To TDD?
TDD를 잘하기 위해서는 적용적이고 진화론적으로 접근해야 한다.
개발자 스스로 어떻게 해야 피드백을 자주 받을 수 있고, 어떻게 해야 협력이 잘 일어날 수 있도록 할까를 고민하고 일하는 방식을 업그레이드 해야한다.
피드백을 자주 받고, 이를 통해 나의 결정과 피드백 사이의 갭을 지속적으로 인식하고 갭을 줄이기 위한 노력을 할 때 TDD를 잘한다 할 수 있을 것이다.
TIL
개발자로서 중요한 개념인 TDD의 장/단점을 살펴보고 어째서 현업에서 TDD를 적용하기 힘든지 알아봤다. 이를 통해 Agile 개념에 대해서도 알아보며 현재의 개발 Process에서의 불확실성 증가와 협력과 피드백의 중요성에 대해 인식할 수 있었다.
1차 프로젝트에서는 그저 기능구현에만 신경쓰고 SW의 성능이나 테스트에 관해서는 신경도 안썼는데, 2차 프로젝트에서는 Git Flow, Unit Test, Django ORM 등 협업방식과 Software의 성능이나 피드백에 집중적으로 케어하는 모습을 볼 수 있다.
실제로 2차 프로젝트를 진행하며 Unit Test를 모든 기능에 적용시키고 있는데, 생각해보면 미리미리 TDD에 익숙해져 현업에서도 적용할 수 있도록 만드려는 Wecode의 배려가 아닐까 싶다. 조금 번거롭고 시간이 걸려도 기본기가 단단한 개발자가 되기 위한 과정이라고 생각하고 노력해야겠다.
