TDD(Test-Driven Development)는 개발자가 프로덕션 코드를 작성하기 전에 요구사항을 먼저 생각하고 정리하여 테스트 시나리오를 먼저 작성하게 한다. 그리고 테스트를 통과하기 위한 가장 간단한 코드를 작성하고 다시 테스트 코드를 실행하여 테스트가 통과됨을 확인한다. 테스트가 통과된 이후에는 필요에 따라 리팩토링을 할 수 있다. 이러한 주기(Red-Green-Refactor)를 반복하면서 개발하는 것을 TDD라고 한다.
AI가 없던 시절에 일반적으로 TDD는 실제 업무에 사용하기 어려운 도구였다고 생각한다. TDD가 어려운 이유는 테스트의 우선순위와 관심이 현재 AI를 활용하여 코드를 작성하고 있는 시대에 비해서 적었다고 생각한다. 내가 주니어 개발자 시절 겪었던 대부분의 회사는 아쉽게도 테스트에 대한 관심과 우선순위가 낮았다. 따라서 과거에는 TDD를 개발 문화로 정착시키긴 어려웠으며 개인이 필요에 의해서 각자 사용하는 경우가 많았다.
과거에 내가 경험했던 TDD의 장점은 테스트하기 쉬운 구조를 갖게 해준다는 것과 좋은 인터페이스 설계를 갖게 해준다는 것 그리고 추상화를 창조하는 게 아니라 발견하게 해준다는 것이라고 생각한다.
테스트 코드는 AI 시대에 더욱 중요해졌다. AI 시대에 TDD는 SKILL만 있으면 바로 적용 가능하기 때문에 과거와 달리 선택하지 않을 이유가 없다고 생각한다.
인간은 요구사항 명세를 작성하여 AI에게 던져주면 AI가 플래닝과 구현을 진행하게 된다. 이때 AI는 TDD SKILL을 통해서 명세를 테스트로 문서화한다. 즉, 테스트 코드는 AI에게 정책 문서로서 존재하게 된다. 따라서 이후에 다른 작업을 진행하더라도 AI가 플래닝 과정에서는 인간이 전달한 요구사항에 빈틈이 없는지 피드백을 해주며, 구현 과정에서는 테스트 코드가 안전망 역할을 해준다. 이렇게 쌓인 테스트 코드는 대규모 리팩토링을 진행할 때 매우 강력한 안전망 역할을 하고 회귀 문제를 방지한다.
실제로 42dot에서 “모바일과 IVI 간 실시간 프로필 데이터 동기화 시스템"을 대규모 리팩토링(200+ files) 하는 과정에서 AI가 단 한 번도 회귀 문제를 일으키지 않았다. 이때 Test Coverage는 약 70%였다.
장기적으로 변경 가능한 시스템을 설계하고 있는 모든 소프트웨어 엔지니어들은 TDD를 사용해야 한다.