TDD 실천 가이드: Red-Green-Refactor

TDD의 가치는 테스트를 먼저 쓴다는 형식에 있지 않습니다. 진짜 가치는 **설계를 더 작은 피드백 루프로 쪼개서, 바꾸기 쉬울 때 더 빨리 배우게 만든다**는 데 있습니다.

그래서 TDD는 의식처럼 따라야 할 절차라기보다, 설계 피드백을 당겨오는 규율에 가깝습니다.

Red-Green-Refactor는 사고 리듬입니다

세 단계가 중요한 이유는 각각의 역할이 분명하기 때문입니다.

작은 행동 하나를 failing test로 정의
그것만 통과시키는 최소 구현 작성
동작을 유지한 채 구조를 정리

어느 단계가 빠져도 가치가 줄어듭니다.

red가 없으면 테스트가 정말 실패를 잡는지 알기 어렵고
green이 없으면 과잉 구현으로 흐르기 쉽고
refactor가 없으면 코드와 테스트 둘 다 중복이 쌓입니다

TDD의 힘은 이 사이클이 충분히 작아서 매 단계가 실제로 무언가를 가르쳐 줄 때 나옵니다.

TDD는 설계 불확실성이 높은 곳에서 특히 강합니다

TDD는 보통 다음 문제에서 투자 대비 효과가 좋습니다.

엣지 케이스가 많은 비즈니스 규칙
파싱과 변환 로직
자주 바뀌는 도메인 규칙
정답 동작은 말하기 쉽지만 구현은 아직 애매한 코드

반대로 프레임워크 wiring, 설정, 탐색적 UI 조립처럼 행동 정의 자체가 아직 흐린 작업에서는 효과가 약할 수 있습니다.

좋은 TDD는 구현이 아니라 행동에서 출발합니다

강한 TDD 테스트는 비즈니스 규칙이나 외부 행동을 설명합니다.

프리미엄 회원에게만 할인이 적용된다
잘못된 입력은 거절된다
중복 요청은 안전하게 무시된다

약한 TDD 테스트는 내부 구조에서 출발합니다.

private helper가 호출된다
특정 메서드가 두 번 호출된다
우연한 내부 객체 구조가 그대로 유지된다

구현 모양을 기준으로 쓴 테스트는 리팩터링을 돕기보다 방해하기 쉽습니다.

사이클은 작게 유지해야 합니다

TDD가 무거워지는 가장 흔한 이유는 처음부터 큰 테스트를 한꺼번에 쓰기 때문입니다.

더 건강한 리듬은 다음과 같습니다.

다음으로 필요한 작은 행동 하나를 고른다
failing example 하나를 만든다
최소 구현으로 통과시킨다
다음 단계로 가기 전에 구조를 정리한다

이렇게 해야 TDD가 의식이 아니라 설계 도구로 남습니다.

Refactor는 선택이 아닙니다

많은 팀이 사실상 “red-green-stop”을 하고 있습니다. 그러면 TDD의 설계 이점 대부분을 놓치게 됩니다.

Refactor 단계는 다음을 하는 시간입니다.

이름을 더 정확하게 만들기
중복 제거
추상화 재배치
의도를 더 선명하게 드러내기

테스트가 통과한다고 해서 설계도 좋아졌다는 뜻은 아닙니다. refactor가 빠지면 구조는 그대로 무거워집니다.

모든 작업에 TDD를 강제할 필요는 없습니다

모든 종류의 작업에 기계적으로 적용하면 TDD는 오히려 답답하고 비효율적으로 느껴집니다.

특히 다음 작업에서는 더 많은 판단이 필요합니다.

시각적 스타일링
아직 제품 요구가 흐린 탐색 작업
서드파티 연동 스파이크
넓은 인프라 wiring

이 경우에는 다른 피드백 루프가 더 나을 수 있습니다. TDD는 설계 선명도를 높이는 도구이지, 보편적 도덕 규칙이 아닙니다.

팀 적용은 지속 가능해야 합니다

건강한 TDD 문화는 보통 다음 특징을 가집니다.

규칙이 진한 코드에서 작은 사이클로 사용
의도가 읽히는 테스트 작성
refactor 품질을 중요하게 보는 리뷰 문화
가치가 적은 곳에 억지 테스트를 만들지 않음

이런 문화가 TDD를 교조주의보다 오래가게 만듭니다.

흔한 안티패턴

다음 패턴은 TDD를 느리고 답답하게 만듭니다.

피드백 없이 큰 테스트 묶음을 먼저 작성
행동 대신 구현 디테일을 검증
green 이후 refactor를 생략
테스트 개수 늘리기가 목적이 됨
설계 피드백이 약한 영역에도 무조건 적용

이런 경우 느린 것은 TDD 자체가 아니라, 유용한 피드백 고리가 사라졌기 때문입니다.

리뷰 체크리스트

TDD 실천이 건강한지 보려면 다음을 물어야 합니다.

테스트가 정말 중요한 행동을 설명하는가
피드백 사이클이 충분히 작은가
refactor 단계에서 코드가 실제로 개선되었는가
내부 리팩터링 후에도 이 테스트가 여전히 가치 있는가
설계 피드백이 유효한 영역에 TDD를 쓰고 있는가

마무리

좋은 TDD는 테스트를 먼저 쓴다는 형식 자체가 목적이 아닙니다. 설계 피드백을 더 일찍, 더 자주 받아 더 나은 코드를 만드는 것이 목적입니다.

그 가치는 사이클이 작고 행동 중심일 때 가장 크게 드러납니다.

다음으로 읽기 좋은 글

🧪 Test

Mock, Stub, Spy 테스트 더블 설계 가이드

Mock, Stub, Spy를 언제 어떤 기준으로 선택해야 하는지 정리합니다. 상태 검증과 상호작용 검증의 차이, 과도한 mocking의 위험, fake와의 선택 기준까지 실무 관점에서 다룹니다.

🧪 Test

React Testing Library 실전 설계 가이드

React Testing Library를 사용자 중심 테스트 도구로 활용하는 방법을 정리합니다. query 우선순위, 상호작용 테스트, 비동기 UI, provider wrapper, 과도한 mocking 회피까지 실무 기준으로 다룹니다.

🔧 Tools

Postman 실전 가이드: API 테스트, 자동화, 협업

Postman을 API 탐색 도구에서 끝내지 않고, 환경 관리, 컬렉션 구조, 공유 테스트 흐름, Newman 기반 CI 검증까지 실무적으로 사용하는 방법을 정리합니다.

⚙️ Backend

Spring Boot 테스트 전략 가이드

단위 테스트, 슬라이스 테스트, 통합 테스트를 어떻게 배치해야 하는지와 함께, 빠른 피드백과 높은 신뢰도를 동시에 얻는 실전 전략을 정리합니다.

AI 서비스 개발, 운영, 성능개선을 하나의 루프로 연결합니다