2-4. TDD에 대한 오해

해당 포스트는 이규원님의 "Spring Boot TDD" 강의를 기반으로 작성하였습니다.

Spring Boot TDD - 입문부터 실전까지 정확하게| 이규원 - 인프런 강의

---

TDD 오해 소개: 프로그래머를 위한 명확한 이해

TDD(Test-Driven Development)는 소프트웨어 개발에서 큰 관심을 받지만, 그만큼 오해도 많습니다. 이러한 오해는 TDD 학습을 주저하게 하거나, 도입 후 효과를 제대로 누리지 못하게 만듭니다. 이 글에서는 TDD에 대한 주요 오해를 서론부터 시작해 하나씩 살펴보고, 각 오해의 사실과 반례를 상세히 설명하겠습니다. 이를 통해 TDD의 본질을 제대로 이해하고, 실무에서 효과적으로 적용할 수 있도록 돕겠습니다. 오해는 TDD의 핵심(테스트 중심 개발, 코드 안정성)을 왜곡하므로, 사실 기반으로 바로잡는 것이 중요합니다.

 

1. TDD 오해의 배경과 영향

TDD는 코드 작성 전에 테스트를 만들어 요구사항을 명확히 하고, 변경에 강한 소프트웨어를 만드는 방법입니다. 그러나 오해가 쌓이면 TDD를 "어렵거나 비효율적"으로 인식하게 됩니다. 오해는 학습·도입을 막거나, 잘못된 적용으로 거짓 음성(테스트 성공인데 실제 실패)이나 비용 증가를 초래합니다. 아래에서 주요 오해를 사실과 반례로 풀어보겠습니다. 각 오해는 TDD의 유연성을 무시한 결과로, TDD는 도구나 구조에 얽매이지 않고 본질(테스트 주도)에 초점을 맞춥니다.

 

2. 오해 1: Mock(테스트 대역)을 잘 사용해야 TDD를 잘 할 수 있다

• 오해 설명: TDD를 위해 테스트 대역(테스트 환경에서 실제 구성요소를 대체하는 시스템, 예: Mock)을 필수로 사용해야 한다는 주장. 특히 자바에서 Mockito 같은 도구를 강조.
• 사실: TDD 창시자 Kent Beck은 "테스트 대역을 거의 사용하지 않는다"고 밝혔습니다. 테스트 대역은 유용하지만(예: 외부 시스템 대체), 남용 시 운영 코드와 테스트 간 공유 정보 과다로 설계 변경 비용 증가. 테스트 환경과 운영 환경 차이로 거짓 음성 발생 가능성 높아짐.
  • 테스트 대역 용어: "Test double"로, Mock은 여러 유형 중 하나(xUnit 패턴 참조: https://xunitpatterns.com/Mock%20Object.html).
  • 도구 의존성: Mockito 같은 특수 도구 불필요. 직접 만든 대역은 디버깅·재사용 쉬움(도구 의존성 주입 예: https://martinfowler.com/articles/injection.html).
• 반례: 강의 실습에서 테스트 대역 거의 사용 안 함(단, H2 인메모리 DB만). TDD 여전히 효과적.

 

3. 오해 2: 테스트를 위해 프로젝트 구조를 설계해야 TDD를 잘 할 수 있다

• 오해 설명: TDD를 위해 패키지 구조나 모듈 분리를 최적화해야 한다는 주장.
• 사실: 패키지 구조는 유익하지만, 테스트 영향 크지 않음. 외부 공개 인터페이스와 내부 구현 구분이 더 중요(설계 품질 향상, 테스트 관리 용이).
  • 모듈 분리: 아키텍처 결과로 테스트 비용 낮아질 수 있지만, 테스트 목적만으로 분리 시 거짓 음성 유발 위험.
• 반례: TDD는 구조 최적화 없이도 동작. 강의 실습에서 기본 구조로 TDD 성공.

 

4. 오해 3: 인터페이스 형식을 많이 사용해야 TDD를 잘 할 수 있다

• 오해 설명: TDD를 위해 자바 인터페이스를 광범위하게 사용해야 한다는 주장.
• 사실: 인터페이스는 추상화 도구로 변경·확장 용이하지만, 테스트 목적만으로 도입 시 문제. 테스트 대역(예: 실제 DAO 대신 가짜) 사용 시 운영·테스트 환경 차이로 거짓 음성 발생.
  • 위험성: 복잡도 증가, 테스트 신뢰도 저하. 쉬운 테스트가 항상 좋지 않음.
  • 트레이드오프: 외부 시스템처럼 제어 어려운 경우 인터페이스 고려, 하지만 비용-효과 검토.
• 반례: TDD는 인터페이스 다수 없이도 가능. 강의 실습에서 최소 인터페이스 사용.

 

5. 오해 4: 클래스를 작게 나눠야 TDD를 잘 할 수 있다

• 오해 설명: TDD를 위해 클래스를 작게 분할해야 한다는 주장.
• 사실: 코드 분할은 설계 이점 있지만, 테스트 노출되지 않은 구현 코드 크기는 TDD에 영향 주지 않음. 리팩터링(구현 변경)은 클라이언트(테스트)에 영향 없음.
• 반례: 강의 실습에서 클래스 크기 무관 TDD 성공.

 

6. 오해 5: 클린 아키텍처 또는 헥사고날 아키텍처를 사용해야 TDD를 잘 할 수 있다

• 오해 설명: TDD를 위해 특정 아키텍처(클린/헥사고날) 도입 필수라는 주장.
• 사실: 적응력 높은 아키텍처는 테스트 비용 낮출 수 있지만, 팀 역량·코드 준비 부족 시 비용 과다. 테스트 목적만 도입 시 비효율.
  • 엔지니어링 관점: DfT(Design for Testability)는 비용-효과 검토 필요, 과도 화려함은 독.
• 반례: 강의 실습에서 단순 아키텍처로 TDD 성공.

 

7. 오해 6: 단위 테스트와 통합 테스트를 잘 분리해야 한다

• 오해 설명: TDD를 위해 단위·통합 테스트 명확 구분 필수라는 주장.
• 사실: 업계에서 "단위 테스트" 범위·구조 합의 없음. 일부 vs 전체 시스템 구분 어려움.
  • 문제: 강제 구분 시 과도 테스트 대역 사용, 하위 시스템 과집중으로 거짓 음성·비용 증가.
  • 중요성: 구분보다 자동화 검증(요구사항·시나리오)이 핵심.
• 반례: 강의에서 통합/단위 용어 최소 사용, TDD 여전히 효과적.

 

8. 오해 7: 테스트 실행 시 데이터베이스 엔진 사용을 피해야 한다

• 오해 설명: TDD에서 DB 엔진 사용 피해야 한다는 주장.
• 사실: DB 엔진 장단점 있음(느림 vs 실제 환경 유사). 테스트 전용 DB(예: 인메모리) 활용 가능.
  • 위험: 시스템이 DB와 긴밀 시 분리 어려움, 거짓 음성 유발.
  • 대안: 느림 시 인메모리 엔진 고려, 롤백 대신 임의 데이터 생성으로 대체.
• 반례: 강의 실습에서 H2 인메모리 DB 사용, TDD 성공. 롤백 불필요.

 

9. 오해 8: Spring 컨테이너를 사용하는 테스트는 몹시 불편할 정도로 느리다

• 오해 설명: Spring 컨테이너 테스트가 느려 TDD 불편하다는 주장.
• 사실: 느림 상대적. 기본 싱글턴 관리에도 컨테이너 없이 준비보다 빠름 가능하지만, 체감 중요.
  • 개선: 성능 최적화(예: 비밀번호 암호화 최적화)로 실행 시간 단축.
• 반례: 강의 실습에서 120+ 테스트(HTTP 요청 포함) Spring 컨테이너 사용, 25초(개선 후 6초). TDD 기본 기법으로 충분.