TDD(테스트 주도 개발)로 견고한 코드 작성하기: 실무 적용 가이드

2026-03-22Development

TDD와 Clean Code

소프트웨어 개발 방법론의 고전이자 영원한 숙제인 TDD (Test Driven Development). "테스트를 먼저 작성하라"는 이 단순한 원칙이 왜 실무에서는 지켜지기 어려운 걸까요? 그리고 TDD를 제대로 수행했을 때 우리는 어떤 이점을 얻을 수 있을까요? 이 글에서는 켄트 벡의 철학부터 시작해, 실제 프론트엔드 개발 환경(Jest + React Testing Library)에서 TDD를 어떻게 수행하는지 단계별로 심도 있게 다룹니다.

1. TDD의 3단계 사이클: Red, Green, Refactor

TDD는 단순히 테스트를 많이 짜는 것이 아닙니다. 생각의 순서를 바꾸는 훈련입니다. 그 핵심에는 Red-Green-Refactor라는 리듬이 있습니다.

1.1 Red: 실패하는 테스트 작성

많은 개발자가 구현 코드를 머릿속에 그리며 테스트를 작성합니다. 하지만 TDD의 첫 단계는 **"우리가 무엇을 만들고 싶은가?"**를 정의하는 것입니다. 아직 구현체가 없으므로, 우리가 원하는 행위를 코드로 작성하면 당연히 실패(Red)해야 합니다. 컴파일 에러가 나거나, 기대값이 다르다는 메시지를 보는 것이 이 단계의 목표입니다.

"실패하지 않는 테스트는 가치가 없다."

1.2 Green: 테스트 통과를 위한 최소한의 구현

이제 테스트를 통과시키기 위해 코드를 작성합니다. 여기서 중요한 원칙은 **"죄악(Sin)을 저질러서라도 빨리 초록불을 보라"**는 것입니다. 하드코딩을 해도 좋고, 스파게티 코드를 짜도 좋습니다. 오직 현재 실패하고 있는 그 테스트 하나를 통과시키는 데에만 집중합니다. 이 과정은 우리에게 "작동하는 코드"에 대한 심리적 안정감을 줍니다.

1.3 Refactor: 중복 제거와 설계 개선

테스트가 통과했다면 이제 비로소 개발자 모자를 쓰고 코드를 다듬을 시간입니다. 변수명을 명확하게 바꾸고, 함수를 분리하고, 중복을 제거합니다. 이때 가장 강력한 무기는 바로 방금 작성한 테스트사입니다. 리팩터링 과정에서 실수로 기능을 망가뜨리더라도, 테스트가 즉시 알려줄 것이기 때문입니다. 이것이 TDD가 주는 "수정의 용기"입니다.

2. 프론트엔드에서의 TDD (React 예시)

백엔드 로직에 비해 UI는 테스트하기 어렵다는 편견이 있습니다. 하지만 **React Testing Library(RTL)**의 등장으로 사용자 관점의 테스트가 가능해졌습니다.

2.1 시나리오 정의

간단한 "할 일 목록(Todo List)"을 만든다고 가정해 봅시다.

입력창에 텍스트를 넣고 '추가' 버튼을 누르면 목록에 아이템이 추가되어야 한다.
입력창은 비워져야 한다.

2.2 테스트 작성 (Red)

test('새로운 할 일을 추가할 수 있다', () => {
  render(<TodoList />);
  const input = screen.getByPlaceholderText('할 일을 입력하세요');
  const button = screen.getByText('추가');

  fireEvent.change(input, { target: { value: 'TDD 공부하기' } });
  fireEvent.click(button);

  expect(screen.getByText('TDD 공부하기')).toBeInTheDocument();
});

이 시점에서 TodoList 컴포넌트는 비어있거나 존재하지 않으므로 테스트는 실패합니다.

2.3 구현 (Green)

function TodoList() {
  const [todos, setTodos] = useState<string[]>([]);
  const [text, setText] = useState('');

  return (
    <div>
      <input 
        placeholder="할 일을 입력하세요" 
        value={text} 
        onChange={e => setText(e.target.value)} 
      />
      <button onClick={() => setTodos([...todos, text])}>추가</button>
      <ul>
        {todos.map(todo => <li key={todo}>{todo}</li>)}
      </ul>
    </div>
  );
}

최소한의 코드로 테스트를 통과시킵니다.

2.4 리팩터링 (Refactor)

addTodo 핸들러 함수를 분리하거나, UI 구조를 개선합니다. 또는 text 상태를 비우는 로직을 추가하지 않았음을 깨닫고 새로운 테스트 케이스를 추가할 수도 있습니다.

3. TDD가 주는 진정한 가치: 문서화와 신뢰

TDD로 작성된 테스트 코드는 그 자체로 살아있는 문서입니다. 새로운 팀원이 합류했을 때, 기획서를 뒤지는 것보다 테스트 코드를 읽는 것이 컴포넌트의 동작을 이해하는 데 훨씬 빠르고 정확합니다. 또한, 배포 날 금요일 오후에도 두려움 없이 코드를 수정하고 배포할 수 있는 자신감을 줍니다.

결론적으로 TDD는 개발 속도를 늦추는 걸림돌이 아닙니다. 오히려 디버깅 시간을 획기적으로 줄여주어, 전체적인 개발 주기를 단축시키고 코드의 품질을 보장하는, 시니어 개발자로 가는 가장 확실한 지름길입니다.

4. TDD 도입의 현실적 장벽과 극복법

4.1 "시간이 없어서 테스트를 못 쓴다"는 착각이다

TDD 도입을 반대하는 가장 흔한 논리이자, 가장 위험한 착각입니다. 테스트를 작성하지 않으면 초기 개발 속도는 빠를 수 있습니다. 하지만 프로젝트가 복잡해질수록 회귀 테스트에 소요되는 수동 확인 시간, 예상치 못한 버그 수정에 쓰는 핫픽스 시간, 코드 변경에 대한 두려움으로 인한 기술 부채 축적이 기하급수적으로 증가합니다.

경험적으로 TDD를 도입한 팀은 프로젝트 중반 이후부터 테스트가 없는 팀보다 개발 속도가 빨라지기 시작하며, 후반부에는 격차가 더 벌어집니다. 이를 "TDD의 전환점(Tipping Point)"이라고 부릅니다.

4.2 레거시 코드에서 TDD 시작하기

이미 테스트 없이 개발된 레거시 프로젝트에 TDD를 적용하는 것은 쉽지 않지만 불가능하지 않습니다.

변경 지점에서 시작: 전체 코드에 한꺼번에 테스트를 추가하려 하지 마세요. 지금 수정하려는 부분부터 테스트를 작성합니다. 마이클 페더스는 이를 "씰(Seam, 이음새)"이라 불렀습니다.
문자 규약(Characterization Test): 기존 코드의 현재 동작을 그대로 기록하는 테스트를 먼저 작성합니다. 리팩터링 과정에서 기존 동작이 바뀌는 것을 방지하는 안전망 역할을 합니다.

5. 테스트 작성 시 흔히 하는 실수

5.1 구현 세부사항 테스트하기

컴포넌트의 내부 상태 값이 특정 숫자인지 확인하는 테스트는 나쁜 테스트입니다. 내부 구현을 변경하면 기능은 동일한데 테스트가 깨지기 때문입니다. 대신 사용자가 보는 결과(화면에 렌더링된 텍스트, 호출된 API 등)를 테스트하세요.

5.2 너무 많은 Mock 사용

Mock이 3개 이상 필요한 테스트는 설계를 의심해봐야 합니다. 과도한 Mock 사용은 테스트의 신뢰도를 떨어뜨리고, 실제 통합 시 발생하는 문제를 잡아내지 못합니다.

6. 결론: TDD는 용기를 주는 안전망이다

테스트 코드는 프로덕션 코드만큼이나 중요한 자산입니다. 잘 작성된 테스트 스위트는 리팩터링을 할 때 용기를 주고, 새로운 기능을 추가할 때 확신을 줍니다. "내가 이 코드를 건드려도 괜찮은가?"라는 두려움에서 해방되는 것이야말로 TDD가 개발자에게 주는 가장 큰 선물입니다.

X. 깊게 파헤치는 TDD 한계 극복과 비주얼 회귀 테스트 (Deep Dive)

TDD의 경전과도 같은 레드-그린-리팩터 사이클은 서버 중심의 비즈니스 로직에는 그보다 달콤할 수가 없었습니다. 하지만 모던 웹 프론트엔드의 화면 단에 이르면 상황은 전혀 다르게 꼬이기 마련입니다.

1. 행위 주도 프론트엔드 검증 (BDD & E2E)

DOM 구조는 너무도 쉽게 깨집니다. <div> 태그가 <span>으로 변하거나, CSS의 클래스명이 하나 변경될 때마다 100개의 단위 테스트(Unit Test)가 무더기로 빨간불을 뿜어냅니다. 이는 잘못 설계된 취약한 테스트(Fragile Test)입니다.
최신 실무의 해답은 Testing Library와 Cypress/Playwright의 절묘한 양방향 포위 공격에 있습니다. 우리는 버튼 요소의 내부 태그 구조가 어떠한지는 더 이상 테스트하지 않습니다. "화면 상에 '제출' 이라는 권한을 가진 요소가 보이고, 사용자가 그것을 클릭했을 때 알림이 뜨는가?"라는 사용자의 실제 인터랙션 흐름에 집중합니다. 이 행위 기반(Behavior-Driven) 추상화야말로 리팩토링 과정에서 테스트가 발목을 잡지 못하게 하는 강인한 결합 분리의 근원입니다.

2. 정적 UI 무결성과 비주얼 리그래션 (Visual Regression)

그렇다면 단순히 "버튼이 동작하는가"가 아니라 그 "버튼이 어떻게 예쁘게 그려지는가"는 누가 테스트할 수 있을까요?
TDD의 사각지대였던 CSS 레이아웃 파괴 현상을 잡기 위해 탄생한 기술이 바로 시각 회귀 테스트입니다. (Chromatic, Storybook 결합 등)
UI 컴포넌트는 격리된 상태에서 픽셀 단위로 스냅샷 렌더링되며, 기존 베이스라인 이미지와 머신러닝 알고리즘으로 비교당합니다. 1px의 마진 변경이라도 발생하면 파이프라인에서 인간 개발자에게 알림을 띄워 변경 의도를 묻습니다.
이처럼 자바스크립트의 도메인 로직 검증(Jest/Vitest), 컴포넌트 렌더링 로직(Testing Library), 사용자 흐름 통합 타격(Playwright), 픽셀 오차 스튜디오(Visual Regression)까지 갖춘 이 4단 방어 테스트 매트릭스는 대규모 애자일 팀의 코드베이스를 절대 무너지지 않는 난공불락의 요새로 만듭니다.