TDD 세미나 회고

사내 세미나가 약 두 달 만에 열렸다.
주제는 TDD.
TDD는 워낙 핫하다 보니 그 동안 관심만 있었지,, 아니 관심있다 할 수도 없다. 뭔지 알고는 싶은데 적극적으로 알아보려 하지도 않았으니. 그저 테스트 라이브러리를 돌리는 것만이 TDD인줄만 알았다.

테스트 주도 개발 이라는 용어는 알지만 그래서 도대체 어떻게 하는 건데?? 하는 심정으로 듣게 되었다.
듣고 나서는 그야말로 NewSensation이었다. 이걸 왜 이제 안거지??

회사의 백엔드 분이 발표를 하셨는데, 처음 개념 설명을 간단히 하고 (이 때는 당연히 어리둥절 했다.) 바로 라이브 코딩을 하셨다. 충격 그 자체였다.
기존 개발 방식의 틀을 완전히 깨는 접근이었다.

그 동안 우리가 했던 개발 방식은,

PM으로부터 요구 사항이 주어지면 -> 그를 바탕으로 개발자가 해석을 한 내용으로 개발을 한다 -> 해당 코드를 바탕으로 개발자 또는 QA 테스트를 한다. -> 예상치 못한 버그가 생기면 버그를 고친다 (리팩토링)

이런 방식 이었다면,

TDD는,

PM으로부터 요구 사항이 주어지면 -> 실패하는 테스트 코드를 개발한다 -> 테스트를 통과할 정도로만 코드를 작성한다 -> 리팩토링을 한다.

이 과정에서 예외 케이스나 고려사항이 생기면 요구 사항을 수정하거나 테스트의 보호를 받으며 개선한다.

이런 TDD를 거치면서 기존 개발 방식에 비해 얻는 것은

1. 버그가 줄어든다.
2. 계속된 리팩토링으로 품질 좋은 코드가 생성된다.
3. 디버깅 시간이 줄어든다.
4. PM과 상호 빠른 피드백

등 장점 투성이였다.

CTO 님도 TDD가 주변에서 좋다고만 들었지 이렇게 좋을 줄은 몰랐다며 우리 회사도 공식적으로 TDD를 적용했으면 좋겠다고 하셨다.

하지만 기존 개발 방식에 너무 익숙해서 그런지, 자리에 와서 해보려 하니 쉽게 함수 하나 조차 만드는 데에도 손이 떨어지지 않는다. 그리고 또 확장해서 프론트엔드에는 어떻게 적용시킬지, 고민이 되었다.

세미나 후 짧은 토론 시간에서 누군가 한 말이 인상깊었다.
TDD는 결국 애자일 하기 위해서 탄생한 것이 아닐까?
퇴근길에 계속 생각하게 되는 의미있는 세미나였다.