Hanghae Driven Development (aka. HDD)(항해 플러스 프론트 6기 회고 8️⃣주차)

허정석·2025년 8월 31일

WIL 항해플러스

WIL

목록 보기

8/9

3 챕터 제출 실패... ⚠️

항해를 시작하면서 한 챕터 모두 과제 제출 못한 적은 처음이었습니다.

테스트 제출 실패

테스트 챕터여서 더욱 아쉬움이 많이 남습니다. 모든 챕터가 나에게는 다 처음 하는 주제였지만..

테스트는 특히나 생소해서 회사 업무와 병행을 끝 까지 해보고 싶었으나 정말 쉽지 않았습니다.
다른 주차는 그래도 병행이 가능했는데 3 챕터 주간에 모두 상용 배포가 포함 되어 있고..
관리를 소홀히 하다간 큰 일이 날 수 있기에 정신과 시간을 모두 회사 업무에 쏟았습니다.
(~~이게 당연한 거긴 하다.. 직장인은 회사에 최선을 다 해야지~~)

과제 PR 작성을 했지만 TDD에 대해 더 학습을 하고,
코치님의 리뷰처럼 코드를 더 만들어보고 작성을 했더라면.. 이라는 아쉬움이 남습니다.

그래서 이번 회고에는 TDD 에 대해서 정리 해보려 합니다.

TDD: Test Driven Development (테스트 주도 개발)

TDD 🧪

테스트 주도 개발에 대해 다들 한 번씩은 들어봤을 거라고 생각합니다.
물론 제 글로 처음 접하시는 분들도 계실거라고도 생각합니다. 저도 엄청나게 잘 아는 부분이 아니니까
제 경험과 TDD 란 무엇인지 최대한 쉽게 풀어보려고 합니다.!

테스트 코드 작성이 어려웠던 이유.. 🗯️

현업에서 테스트 작성을 했거나, 테스트와 관련된 강의를 수강을 했더라면 접근이 어색하진 않았을텐데
저에게는 이런 경험이 전무해서 테스트 코드에 대해서 어떻게 접근을 해야할지 고민이 됐습니다.

SI회사에서 근무를 하다보니 기능 개발을 우선으로 하고 실제로 로컬과 TB 서버에서 QA 또는 자체 개발 검증을 통해서 이슈 또는 버그 fix 했습니다. 이 순서를 반복하고 상용 배포 일자에 맞춰 완성 후 배포를 진행했습니다.
또 '사실상 기능이 잘 돌아가기만 하면 되지' 라는 것이 업무에 대다수를 차지했습니다.
(~~모든 SI 업체가 이렇진 않겠지만요.. 아닌가?~~)

그 후 또 상용 서버에서 QA 팀이 검증을 진행하고 테스트 서버에서 발견이 안됐던 이슈들을 hotfix 형식으로 처리했습니다.

그렇다보니 테스트 코드를 먼저 작성하는 것이 뜬 구름을 잡는 느낌(?)이 너무 강했습니다.

기능 개발이 없는데 어떻게 기능에 대해서 테스트를 하지?
보이지 않는 것에 대해서 무엇(어떤 테스트)을 작성 해야 하지?
유닛, 통합, e2e 테스트가 뭐지? 그리고 이건 내가 어떤 것을 통해서 구분 지어야 할지?
... 그 외 생소한 것들

이러한 이유들로 테스트 코드 작성에 난항을 겪었습니다.
그럼 TDD 는 어떤 방식으로 이뤄져야 할까요?

Red-Green-Refactor 🔴🟢⚫️

테스트_코드_작성_요령

위 이미지는 8 주차 발제 자료 중 일부를 캡쳐한 것 입니다.
이미지처럼 테스트 코드 작성을 꽤나 단순한 플로우로 진행이 됩니다.

Red 🔴

처음에는 "왜 실패하는 테스트를 먼저 만들어야 할까?" 라는 의문이 컸습니다.
하지만 요구사항 중심으로 생각해보니 Red 단계의 진짜 의미를 제 나름 알게 되었습니다.

Red 단계 = 구체적인 목표 설정 단계

무조건 코드부터 작성하는 것이 아님

무엇을 구현할지 먼저 생각하는 시간

어떤 기능이 필요한지 방향성을 잡는 단계

이제 Red 단계가 단순한 테스트 작성이 아니라 설계의 시작이라는 것을 이해했습니다.

Red 예시 코드

// calculator.test.ts
describe('Calculator', () => {
  test('두 숫자를 더할 수 있다', () => {
    const calculator = new Calculator();
    const result = calculator.add(2, 3);
    expect(result).toBe(5);
  });
});


// calculator.ts
class Calculator {
  // 아직 구현하지 않음 - 테스트가 실패함
}

Green 🟢

설정한 목표를 Green 단계에서는 해당 방향성을 실행에 옮기는 단계입니다.
실제 구현을 통해 설계의 구체적인 틀(현실화)이 만들어지는 과정이라고 느꼈습니다.

처음에는 테스트를 통과시키기 위해 복잡하게 생각했는데,
"정말 필요한 것만 구현하면 되는구나"라는 깨달음을 얻었습니다.

Green 예시 코드

// calculator.ts
class Calculator {
  add(a: number, b: number): number {
    return a + b; // 최소한의 구현으로 테스트 통과
  }
}

Refactor ⚫️

Red 단계에서 목표를 설정하고, Green 단계에서 기능을 구현했다면,
Refactor 단계에서는 "코드의 동작은 그대로 두고 코드를 개선한다"는 원칙을 따릅니다.

테스트가 통과했다는 것은 기능이 정상적으로 동작한다는 의미입니다.
이제 그 기능을 그대로 유지하면서 코드 자체를 더 좋게 만들어야 합니다.

중복 제거, 가독성 향상, 구조 개선 등을 통해 코드의 품질을 높이는 것이
Refactor 단계의 핵심입니다.

// calculator.ts
class Calculator {
  add(a: number, b: number): number {
    // 입력값 검증 추가
    if (typeof a !== 'number' || typeof b !== 'number') {
      throw new Error('숫자만 입력 가능합니다');
    }
    
    return a + b;
  }
}