Test-Driven Development 후기
테스트 주도 개발 후기
배경
TDD(Test-Driven Development)라는 개념은 알고 있었지만, 실제로 어떻게 적용해야 하는지 막막했습니다. 특히 “테스트를 먼저 작성한다”는 것이 현실적으로 가능한지, 정말 효과적인지에 대한 의문이 있었습니다. 그러던 중 TDD의 창시자인 켄트 백의 원서를 읽어보게 되었습니다.
핵심 메시지
TDD는 단순히 테스트를 먼저 작성하는 기법이 아니라, 개발자의 사고 방식 자체를 바꾸는 접근법입니다. 켄트 백은 TDD의 핵심을 “빨강-초록-리팩토링” 사이클로 설명합니다.
TDD의 핵심 사이클
빨강(Red): 실패하는 테스트를 작성합니다. 이 단계에서는 구현할 기능을 명확히 정의하고, 어떤 결과를 기대하는지 구체화합니다.
초록(Green): 테스트를 통과하는 최소한의 코드를 작성합니다. 이때는 완벽한 코드가 아니라 “작동하는” 코드에 집중합니다.
리팩토링(Refactor): 중복을 제거하고 코드를 개선합니다. 테스트가 보장하는 안전망 하에서 자신감 있게 코드를 개선할 수 있습니다.
설계에 대한 새로운 관점
흥미롭게도 TDD는 설계를 미리 완벽하게 하는 것이 아니라, 점진적으로 설계를 발견해 나가는 과정입니다. 테스트를 작성하면서 자연스럽게 인터페이스가 정의되고, 클래스 간의 관계가 명확해집니다.
이는 기존의 “설계 -> 구현 -> 테스트” 순서와는 완전히 다른 접근입니다. 테스트를 먼저 작성함으로써 사용자 관점에서 코드를 바라보게 되고, 자연스럽게 더 나은 API 설계로 이어집니다.
두려움과 확신
켄트 백이 강조하는 또 다른 핵심은 “두려움”을 다루는 것입니다. 개발자는 코드를 변경할 때 기존 기능이 깨질까 봐 두려워합니다. 하지만 포괄적인 테스트 스위트가 있다면 자신감 있게 리팩토링할 수 있습니다.
개인적 소감
책을 읽으면서 가장 인상 깊었던 부분은 켄트 백이 실제 Money 예제를 통해 TDD 과정을 단계별로 보여주는 것이었습니다. 처음에는 굉장히 단순한 테스트부터 시작해서, 점진적으로 복잡한 요구사항을 처리해 나가는 과정이 마치 실시간으로 페어 프로그래밍을 하는 것 같았습니다.
특히 “가장 쉬운 것부터 시작하라”는 조언이 와닿았습니다. 완벽한 구현을 한 번에 하려고 하지 말고, 가장 간단한 케이스부터 차근차근 해결해 나가는 접근법이 실무에서도 매우 유용할 것 같습니다.
레거시 시스템에서의 현실
사실 저는 지금까지 완전한 의미의 TDD를 적용해본 적이 없습니다. 제가 참여한 서비스들은 이미 운영 상태였기 때문에, 기존에 없거나 작동하지 않는 테스트들이 많았습니다. 테스트를 새로 구축하기에는 기존 시스템의 도메인 복잡도가 너무 높은 상태였죠.
하지만 이 과정에서 제 파트의 개발을 위해 fixture를 적극적으로 활용해서 테스트 커버리지를 채웠습니다. 복잡한 도메인 객체들을 테스트 가능한 상태로 만들고, 의존성을 격리하는 작업을 통해 점진적으로 테스트 환경을 구축했습니다. 이제는 새로운 기능에 대해서 TDD를 적용할 수 있을 거라는 자신감이 생겼고, 그래서 이 책을 읽어보게 된 것입니다.
팀 차원의 고민
현재 팀에서는 Kotlin과 Kotest를 사용하고 있는데, BehaviorSpec과 DescribeSpec을 주로 활용합니다. 하지만 팀원들 간의 공통된 테스팅 규약을 합의하는 것이 생각보다 어려웠습니다.
특히 요즘은 Claude Code를 비롯해서 AI 도구들로 테스트 케이스를 만드는 것 자체는 어렵지 않은 시대입니다. 하지만 명확한 디렉션이 없다면 일관되지 않은 테스팅 포맷이 만들어지더라고요. describe-context-it 절을 어떻게 나눌지, 단위 테스트의 커버리지는 어느 정도로 할지, 모킹은 언제 사용할지 등등 이런 세부적인 규칙들에 대한 지속적인 논의가 필요했습니다.
실무 적용에 대한 새로운 관점
이 책을 읽고 나니, TDD는 단순히 개인의 개발 방법론이 아니라 팀 전체가 공유해야 하는 개발 문화라는 것을 깨달았습니다. 레거시 시스템에서도 점진적으로 적용할 수 있는 방법들이 있고, 완벽하지 않더라도 TDD의 사고방식을 부분적으로라도 도입하는 것만으로도 충분히 가치가 있다고 생각합니다.
후기
추천 정도: ⭐️⭐️⭐️
기준표
- ⭐ 상황에 따라서 읽어야 한다
- ⭐️⭐️ 읽어두면 좋다
- ⭐️⭐️⭐️ 개발자 필독서 수준