TDD가 고객에게 지속적인 가치전달이 되는 이유

TDD와 함께라면 된다. 진짜 된다.

테스트 주도 개발(TDD) 기법을 활용하여 고객의 요구사항과 상관없는 불필요한 코드 작성을 최소화하고 코드로 만들어내는 가치가 안정적이고 지속적으로 통합되어 고객에게 전달되는 것에 기여합니다

TDD를 수련하고 난 뒤 나의 이력서 상단에 꼭 위치시키는 문장이다. TDD에 익숙하지 않은 사람들은 왜 저 문장이 실현 가능한지 의문을 품을 수 있을 것이다. 그래서 이를 설명하고자 한다.

고객의 요구사항과 상관없는 불필요한 코드 작성을 최소화한다

이 문장을 이해하려면 우선 TDD의 기본 프로세스를 아는 것이 필요하다. TDD의 기본 프로세스는 다음과 같다

1. 실패하는 테스트를 "하나" 작성한다.(Red)
2. 작성한 모든 테스트를 통과시키기 위한 구현 코드만 작성한다(Green)
3. 1과 2를 반복한다.
4. 중복 코드가 있다면 리팩터링 한다(Refactor)

위 프로세스는 TDD를 검색해 보면 바로 확인할 수 있을 만큼 잘 알려져 있다. 그러나 이 과정에서 매우 중요하지만 당연하게 생각하거나 놓치고 있는 포인트가 있는데 바로 할 일 목록을 작성하는 것이다.

켄트 백의 저서인 Test-Driven Development : By Example에서 들어주는 할 일 목록의 예시는 이런 것이다.

• 통화가 다른 두 금액을 더해서 주어진 환율에 맞게 변한 금액을 결과로 얻을 수 있어야 한다.
• 어떤 금액을 어떤 수로 곱한 금액을 얻을 수 있어야 한다.

대략 프로그램이 어떠한 명령을 수행하면 값을 획득할 수 있어야 한다 혹은 시스템의 상태가 변경되어야 한다 따위의 것들이다.

그렇다면 이러한 할 일 목록은 어디에서 나올까? 바로 고객의 요구사항이다. 위 다중 통화를 지원하는 화폐의 예제는 다중 통화 계산을 함에 있어서 환율 때문에 불편을 겪고 있는 고객의 문제를 해결하기 위한 프로그램을 작성하는 예시이다.

TDD를 원활히 수행하기 위해서는 고객의 요구사항으로부터 기인한 할 일 목록을 잘 작성하는 것이 중요하다. 왜냐하면 개발자가 코드로 작성하는 테스트 자체가 바로 할 일 목록 중 하나이기 때문이다. 할 일 목록이 잘 작성되지 않으면 테스트가 잘 작성될 수 없고 그러한 테스트를 기반으로 주도된 운영 코드는 고객의 요구사항을 충족시키지 못할 것이기 때문이다.

그렇다면 테스트가 불필요한 코드 작성을 어떻게 최소화한다는 것일까? TDD 프로세스 중 2번을 참고하라. TDD 기법을 활용하는 개발자는 일단 테스트가 작성되면 테스트 통과를 위한 구현 코드만을 작성한다. 중간중간 필요 할 것 같다는 개발자의 직감으로 작성하는 운영 코드는 없다. 정말 필요할 것 같다 판단되면 할 일 목록에 추가하고 테스트 코드를 먼저 작성하기 때문이다. “필요할 것 같은데…”라고 생각해서 작성한 코드는 여지없이 필요 없다. YAGNI 원칙을 떠올리면 이 말의 신빙성을 더할 수 있을 것이다.

 

정리하자면 진짜 고객의 요구사항을 할 일 목록으로 작성하고 이를 기반으로 테스트를 작성하고 테스트 통과를 위한 코드만을 작성한다. 군더더기 없이 깔끔하다.

가치가 안정적이고 지속적으로 통합되어 고객에게 전달되는 것에 기여합니다

이 문장은 나는 TDD가 주는 선물이라고 생각한다. TDD는 테스트를 통과하는데 필요한 운영코드만 작성한다. 반대로 말하면 운영코드는 모두 테스트가 작성되어 있다는 뜻이다. TDD가 시스템에 100% 장애가 없음을 보장하지는 않지만, 테스트가 커버하는 상황에 대해서는 논리적으로 문제가 없음을 보장하는 것이고, TDD 개발자는 항상 작성된 모든 테스트를 통과하는 코드만을 작성하기에 상당히 높은 수준의 안전감을 느낀다.

이러한 안전감은 개발자로 하여금 본인이 작성한 코드가 메인스트림에 병합되는 것에 불편함이 없게 한다. 메인스트림에 불편함 없이 자신이 작성한 코드를 병합할 수 있다면 이는 즉시 고객에게 가치가 꾸준히 전달될 수 있음을 의미한다. 고객의 요구사항을 잘 반영하기 위해 TDD 기법을 활용하였을 뿐이지만 고객에게 가치 파이프라인에 안정성까지 더하는 효과를 가지게 되었다. TDD의 부산물 혹은 선물인 자동화 테스트는 안전하게 개발자가 작성한 코드가 고객에게 안전하게 전달될 수 있도록 기여한다.

TDD를 학습하기 전에는 “TDD는 시간을 트레이드오프해서 안정감을 조금 더하는 그렇다고 100%는 아닌”이라고 생각 했다. 마치 100%가 아니면 활용하지 못한다는 완벽주의인양 떠들어 댔다. 그러나 이는 틀렸다. 틀린 정도가 아니라 TDD가 뭔지도 모르고 그냥 한 헛소리다. 작성된 테스트 만으로도 상당히 높은 수준의 안정성을 제공하고, 충분히 습득한다면 TDD는 시간이 더 많이 든다라는 명제까지 부정할 수 있다.(더 많은 코드를 쳐야 하는 것은 부정할 수 없다.)

 

이전에는 고객의 요구사항으로 개발을 하고, QA단계에서 도출된 몇 가지의 문제들을 다시 반영하였다. 내가 부족한 탓인지 검수 사항은 작은 것이라도 항상 나왔고 수정하여 다시 반영하는 것이 당연한 프로세스라 여겼다.

그러나 TDD를 학습한 이후 신기하게도 검수사항이 없는 경우가 있었다. 이전과 비교했을 때 빈도가 적지 않았다. 물론 항상 검수사항이 없는 것은 아니다. 검수사항이 나온다면 나는 이렇게 수정한다

1. 검수 사항을 할 일 목록으로 추가하고 실패하는 테스트 케이스를 작성한다.
2. 모든 테스트케이스를 통과하는 구현 코드를 작성한다.
3. 만약 중복이 있다면 리팩터링 한다.

이런 프로세스로 개발을 할 수 있게 된 것은 이전 회사에서 만난 CTO님 덕분이다. 이 자리를 빌려 다시 한번 감사의 인사를 전한다.