TL;DR

  • 세 가지 프로젝트와 두 차례 변경 작업을 대상으로 한 벤치마크에서 tdd-guard는 새 코드베이스에서 비용을 2~4배 높였지만 전반적인 코드 품질은 개선하지 못함.
  • 테스트 우선 규칙이 적용된 설정은 테스트가 요구하지 않는 기능을 사양에서 누락할 수 있으며, 두 설정 모두 테스트에 없는 요구사항을 놓침.
  • 기본 Claude Code는 테스트 품질과 설계 품질에서 우세했고, tdd-guard와 CLAUDE.md 규칙만 적용한 설정은 제한 범위 준수에서 우세함.
  • 기존 코드베이스를 확장할 때 tdd-guard는 매번 새 테스트를 추가하고 실행 간 편차가 가장 작아지는 효과를 보임.
  • 비용은 후속 작업에서 줄어들어 세 프로젝트 기준 1.9~2.4배 수준이며, 플러그인의 실질적 이점은 지속적인 개발에서 테스트 우선 흐름을 강제하는 데 있음.

테스트 설정

  • 세 가지 유형의 소규모 프로젝트를 사용함.
  • 상태 중심의 속도 제한기(rate limiter)
  • 변환 중심의 CSV 파서
  • 제어 흐름 중심의 비동기 작업 재시도 도우미
  • 각 프로젝트를 Claude Code 설정 세 가지로 실행함.
  • A: 별도 지침이 없는 기본 Claude Code
  • B: tdd-guard 규칙을 일반 지침으로 CLAUDE.md에만 작성한 설정
  • C: B와 동일한 규칙을 훅(hook)으로 적용해 Write 또는 Edit를 거부할 수 있는 tdd-guard 플러그인
  • B와 C는 동일한 규칙을 사용하며, 차이는 규칙을 강제하는지 요청만 하는지에 있음.
  • 각 프로젝트에 원래 사양을 확장하는 후속 프롬프트도 적용해 두 번째 변경 작업에서 규칙 준수 여부를 확인함.
  • 사양 세 개, 설정 세 개, 작업 라운드 두 개, 설정별 실행 세 번으로 총 54회 실행함.

평가 방법

  • 같은 프로젝트에서 실행한 두 결과의 소스 코드와 테스트를 평가 기준, 원래 사양, 후속 사양과 함께 프롬프트에 넣고 스크립트로 비교함.
  • 평가자는 네 가지 항목에서 더 나은 결과를 선택하고 각 판단의 이유를 설명함.
  • LLM 평가자가 먼저 제시된 결과를 선호하는 경향을 고려해 호출마다 제시 순서를 무작위화함.
  • 설정별 실행이 세 번이므로 두 설정의 모든 조합을 비교하면 프로젝트당 아홉 쌍이 됨. A와 B, A와 C, B와 C 비교를 합치면 프로젝트당 27쌍임.
  • 세 프로젝트에서 각 쌍을 세 번 평가해 다수결을 적용한 결과 총 243회 평가를 수행함.

품질 결과

  • 테스트 품질: A가 뚜렷하게 우세함. 평가자는 더 긴 테스트 모음과 엣지 케이스 처리를 높게 평가함. C는 B보다 약간 앞섰지만, 주된 근거가 테스트 하나를 더 작성했다는 점이어서 차이는 근소함.
  • 설계 품질: A가 같은 이유로 우세함. B와 C는 동률임.
  • 사양 준수: A가 우세함. B와 C 모두 엣지 케이스 하나와 사양에 명시된 기능 하나를 놓침. 두 설정의 테스트 파일을 확인한 결과, 누락된 경우를 검사하는 테스트를 작성하지 않음.
  • 테스트 우선 규칙이 이미 작성한 테스트에 구현을 고정하고 테스트가 통과한 뒤 멈추게 한 결과임.
  • 범위 절제: 평가자는 앞선 두 항목에서 보상한 추가 구현을 범위 확장으로 판단해 감점함. 이 항목에서는 요청된 것만 구현하는 tdd-guard의 접근이 이점을 보임.
  • 종합하면 A는 테스트 품질과 설계 품질에서, B와 C는 범위 절제에서 우세함. 기억할 핵심 결과는 테스트 우선 규율이 테스트가 요구하지 않는 경우 사양이 요구한 기능조차 구현하지 못하게 할 수 있다는 점임.
  • 모든 품질 항목에서 B와 C의 결과가 비슷해, 규칙을 CLAUDE.md에 붙여 넣는 방식과 비교했을 때 플러그인이 품질 면에서 제공하는 차이는 분명하지 않음.

테스트 수

  • A는 전반적으로 더 많은 테스트를 작성했으며, 이는 테스트 품질 평가와 일치함.
  • 속도 제한기에서는 tdd-guard가 A의 테스트 수에 거의 근접함.

2라운드에서 추가된 테스트

  • 기존 코드베이스를 확장하는 후속 라운드에서 플러그인의 효과가 드러남.
  • C는 모든 실행에서 새 테스트를 추가했으며, 세 설정 가운데 실행 간 편차가 가장 작음.
  • A는 반대로 일부 실행에서 새 테스트를 전혀 추가하지 않음.
  • 이는 훅이 매번 동일한 개발 주기를 강제한다는 플러그인의 주장과 일치함.

비용

  • 1라운드에서 tdd-guard는 기본 Claude Code보다 CSV 파서에서 2.4배, 속도 제한기에서 3.8배, 재시도 도우미에서 2.2배 많은 비용이 듦.
  • 2라운드에서는 각각 2.4배, 2.3배, 1.9배로 낮아짐.
  • 빈 코드베이스를 처음부터 시작하는 작업보다 기존 코드베이스를 확장하는 작업이 저렴해 비용 격차가 좁아짐.
  • 추가 비용은 테스트 우선 개발 규율을 위한 대가임.

결론

  • tdd-guard는 새 코드베이스에서 비용이 2~4배, 기존 코드베이스를 확장할 때는 약 2배 듦.
  • “항상 실패하는 테스트를 먼저 작성”하는 엄격한 규칙은 테스트가 없는 기능을 빠뜨리게 할 수 있으며, 여기에는 사양이 요구한 기능도 포함됨.
  • 비용을 감수할 만한 부분은 지속적인 작업임. 훅이 매번 동일한 주기를 강제해 에이전트의 기억에만 의존하지 않고 코드와 함께 테스트가 계속 늘어남.
  • 저장소: tdd-guard-bench · 동영상: youtu.be/EjtkHa_FH0s · tdd-guard 플러그인: nizos/tdd-guard