실무에서의 TDD 적용 시 고려사항 - Spring Boot로 시작하는 TDD 14편Considerations for Applying TDD in Practice - TDD with Spring Boot Part 14
📅
🚀
들어가기 전에 🔗
지금까지 우리는 13편에 걸쳐 TDD의 기술적인 방법들을 모두 익혔습니다.
이제 여러분은 혼자서도 충분히 테스트 코드를 작성하고 기능을 구현할 수 있는
능력
을 갖췄습니다.하지만 학교나 개인 프로젝트가 아닌, 실제 회사(실무)에 가면 상황이 조금 다릅니다.
"바빠 죽겠는데 언제 테스트를 짜고 있어요?"
"테스트 코드 짜느라 일정이 2배로 늘어나는 거 아니에요?"
이런 현실적인 질문들과 마주하게 됩니다.
오늘은 TDD를 실무에 적용할 때 고려해야 할
비용
과 타협점
에 대해 솔직하게 이야기해 보겠습니다.🚀
테스트 작성 비용과 생산성 🔗
많은 분이 오해하는 것이 있습니다.
바로 "TDD를 하면 개발 시간이 오래 걸린다"는 것입니다.
결론부터 말씀드리면,
초반에는 오래 걸리는 것이 맞지만, 전체 기간을 보면 오히려 빠릅니다.
✅
그래프로 보는 생산성 🔗
- 초기 개발 단계테스트 코드를 짜지 않고 막 개발하는 게 훨씬 빠릅니다. 고민 없이 코드만 치면 되니까요. TDD는 설계도 하고 테스트도 짜야 해서 느리게 느껴집니다.
- 유지보수 단계기능이 쌓이고 코드가 복잡해지면 상황이 역전됩니다. 테스트가 없는 코드는 수정할 때마다 버그가 터지고, 그걸 고치느라 며칠 밤을 새웁니다. 반면 TDD로 짠 코드는안전망이 있어 수정이 빠르고 과감합니다.
즉, TDD는 미래의 나에게 시간을 투자 하는 것과 같습니다.
당장의 1시간을 투자해서, 미래의 야근 10시간을 막는 셈입니다.
🚀
무엇을 테스트하고, 무엇을 버릴까? 🔗
실무에서는 모든 코드에 테스트를 작성하는 것이 불가능할 때가 많습니다.
그래서
선택과 집중
이 필요합니다.
어떤 코드를 반드시 테스트해야 하고, 어떤 코드는 넘어가도 될까요?- 반드시 테스트해야 하는 코드 (Core)돈과 관련된 로직 (결제, 정산, 할인 계산). 비즈니스 규칙이 복잡한 로직 (영업 시간 체크, 등급 산정). 자주 변경되거나 에러가 나면 치명적인 부분.
- 테스트하지 않아도 되는 코드 (Trivial)단순한 Getter/Setter 메서드. 프레임워크가 알아서 해주는 설정 (단순한 Bean 등록 등). 다른 시스템 단순 연동 (외부 라이브러리 자체를 테스트할 필요는 없음). UI 단순 배치나 디자인 요소.
불안하면 테스트하세요. 하지만 "이게 고장 날 확률이 있을까?" 싶을 정도로 단순하다면 과감히 생략해도 됩니다.
🚀
팀 환경에서의 적용 (설득의 기술) 🔗
여러분은 TDD의 장점을 알지만, 팀원들은 모를 수 있습니다.
"우리 팀은 테스트 안 짜는데 저만 짜도 되나요?"라는 질문을 정말 많이 받습니다.
✅
혼자 시작하세요 🔗
팀 전체 프로세스를 바꾸려 하지 마세요.
- 버그가 발생하면, 그 버그를 재현하는 테스트를 먼저 만듭니다.
- 코드를 고치고 테스트가 통과하는 것을 확인합니다.
- 자신 있게 배포합니다.
시간이 지나면 팀원들이 느낍니다.
"어? 저 친구가 짠 코드는 버그가 별로 없네?"
"저 친구는 코드를 수정하는 걸 별로 안 무서워하네?"
그때가 기회입니다. 팀원들이 관심을 보일 때 TDD의 경험을 공유하면 자연스럽게 문화가 퍼집니다.
말로 설득하는 것보다
결과
로 보여주는 것이 가장 강력합니다.🚀
레거시 코드 다루기 (Legacy Code) 🔗
신규 프로젝트가 아니라, 이미 테스트 없이 짜여진 거대한 코드 덩어리(레거시)를 만날 수도 있습니다.
이걸 다 테스트 코드로 덮으려는 생각은 버리세요. 불가능합니다.
✅
보이스카우트 규칙 🔗
"머물렀던 자리를 떠날 때는, 들어왔을 때보다 깨끗하게 하라."
이 규칙을 코드에 적용하세요.
전체를 뜯어고치는 게 아니라,
내가 오늘 수정해야 할 부분
만이라도 테스트를 짜는 겁니다.- 수정할 코드 주변에 보호막(테스트)을 칩니다.
- 코드를 수정하고 리팩토링 합니다.
- 커밋합니다.
이렇게 야금야금 테스트 영역을 넓혀가는 것이 가장 현실적이고 안전한 전략입니다.
🚀
결론 🔗
TDD는 법이 아닙니다. 더 좋은 소프트웨어를 만들기 위한
습관
이자 도구
입니다.
너무 강박을 가질 필요는 없습니다.- 비용:초기 비용은 들지만, 유지보수 비용을 획기적으로 줄여줍니다.
- 범위:핵심 비즈니스 로직 위주로 테스트하고, 단순한 코드는 생략하세요.
- 팀워크:강요하지 말고, 나부터 시작해서 안정성을 증명하세요.
- 레거시:욕심내지 말고, 내가 손대는 부분부터 조금씩 개선하세요.
이제 여러분은 TDD라는 강력한 무기를 손에 넣었습니다.
이 무기를 언제 어떻게 휘둘러야 할지는 여러분의 경험이 쌓이면서 더 정교해질 것입니다.
다음 시간은 대망의 마지막 편입니다. 지금까지 배운Spring Boot TDD 여정을 총정리하고, 앞으로 여러분이 나아가야 할 학습 방향을 제시하며 시리즈를 마무리하겠습니다.
✅
참고 🔗
- Working Effectively with Legacy Code (Michael Feathers)↗ 테스트가 없는(레거시) 코드를 안전하게 수정하는 전략을 다룬 명저입니다.
- The Pareto Principle (80/20 Rule)↗ 결과의 80%는 20%의 원인에서 나온다는 법칙으로, 테스트 커버리지 전략에 적용할 수 있습니다.