AI로 TDD로 돌리기 — Kent Beck의 CLAUDE를 보고 입맛대로 바꾸기

클로드 코드(Claude Code)를 쓰다 보면 속도는 정말 빠르다.
한 번 프롬프트만 잘 주면 엔터프라이즈 레벨의 코드도 순식간에 뽑힌다.

 

그런데 문제는, 결과물의 일관성이다.
클린하지 않은 로직, 규칙이 제각각인 이름, 그리고 지나치게 과한 코드들.
결국 내가 손을 많이 봐야 하고, 며칠 써보면 토큰은 순식간에 녹아내린다.

그래서 ‘이걸 어떻게 하면 AI에게 인간의 루틴을 심어줄 수 있을까?’ 라는 생각이 들었다.
그 시점에서 눈에 들어온 게 바로 Kent Beck의 CLAUDE.md였다.

 

📖 Kent Beck의 CLAUDE.md — “AI에게도 TDD를 시킨다”

얼마 전 딩코딩코 님 유튜브에서 봤는데, 켄트 백은 클로드 코드를 TDD 형태로 돌리고 있었다.
AI에게 “작은 단위, 명확한 목표, 단계적 리팩터링”을 그대로 강제하는 방식이다.

BPlusTree3/rust/docs/CLAUDE.md at ca80e4d85a99cd0af2effe717f709d43e80403bc · KentBeck/BPlusTree3

 

 

 

딩코딩코 님의 유튜브

 

Red — 실패하는 테스트 작성 (최소 단위 목표)
Green — 통과시키는 최소 코드 작성 (실행 가능한 구현)
Refactor — 구조 변경, 동작 동일 (Tidy First 적용)

 

이게 인간이 하는 TDD의 본질인데, 켄트는 그대로 클로드에게 시켰던 거다.

 

그래서 나는 이걸 내 입맛대로 바꿨다

AI에게 시킬 루틴을 아래처럼 설계했다.

1. create-prd → 기능을 제품 단위로 정의 (요구사항 명확화)
2. breakdown-prd → 유즈케이스/도메인 규칙 분리 (계층별 책임)
3. create-plan → 테스트·구현 계획 생성 (plan.md 작성)
4. red → 실패하는 테스트 작성
5. green → 통과시키는 최소 코드 작성
6. refactor → 구조 변경, 동작 동일
7. go → 시나리오 단위 실행 (end-to-end 검증)
8. validate → ArchUnit/Lint/Rule 검사 (컨벤션 준수 확인)

 

 

create-prd

말 그대로 “무엇을 만들 건가?”를 명확히 정의한다.
이걸 실행하면 헥사고날 구조(도메인, 애플리케이션, 어댑터) 기준으로
각 레이어에 필요한 기능들을 세분화해 질문하고, PRD 형태로 구체화한다.

레이어별로 나누는 이유는 단순하다.
병렬 수행이 쉽고, 각 레이어마다 별도의 코딩 컨벤션 검증을 적용할 수 있기 때문이다.

전체를 한꺼번에 돌리면 오히려 비효율적이라, “작게 쪼개서 정확히 돌리는” 구조로 설계했다.

또한 각 레이어별 커맨드도 나눠놨는데 그 이유는 Claude의 Skills를 적용하기 위함이다.

 

 

 

 

 

breakdown-prd

이 단계에선 create-prd 결과를 태스크 단위로 쪼갠다.
도메인, 애플리케이션, 어댑터 단위로 PRD가 분리되어
각 레이어의 TDD 사이클을 독립적으로 수행할 수 있게 된다.

 

 

 

create-plan

이제 위에서 만들어진 tasks를 기반으로 TDD 사이클을 기록할 plan.md를 만든다.
레드-그린-리팩터 루틴이 어떻게 흘러가야 하는지를 명시적으로 남기는 단계다.

 

 

go (red → green)

go를 실행하면 Red → Green을 반복한다.
plan에 정의된 테스트를 하나씩 통과시키며 체크해나간다.
결국 “테스트를 통과하는 최소한의 코드만 작성”하게 되므로
AI가 쓸데없는 보일러플레이트나 의미 없는 코드들을 덜 생성한다.

validate

하나의 레이어 작업이 끝나면 validate를 실행한다.
이때 docs/ 아래에 정의한 코딩 컨벤션 문서와 대조하여 위반 여부를 검증한다.
만약 위반이 감지되면 리팩터링용 PRD를 자동 생성하게 된다.

 

이 방식의 장점

 

• 불필요한 코드가 없다.
  실패하는 테스트 → 최소 구현 → 구조 개선 순으로 진행되기 때문에
  AI가 “불필요한 데드 코드”를 만들어낼 여지가 거의 없다.
• 테스트 커버리지가 높다.
  항상 테스트를 먼저 작성하니, 커버리지 90% 이상은 자연스럽게 따라온다.
• 리팩터링에 강하다.
  잘 만들어진 테스트 위에서 새 케이스를 추가하고 통과시키는 구조라
  버그 수정이나 신규 기능 추가가 훨씬 안정적이다.

 

 

그리고 지금은 여기에 LangFuse 로그 수집을 붙였다.
각 커맨드와 TDD 사이클이 얼마나 걸리는지 추적 중이다.
이 데이터를 분석하면 “AI와 인간이 함께 TDD를 돌릴 때 얼마나 효율적인가”를
정량적으로 평가할 수 있을 것 같다.

 

 

 

 

 

이 모든 기능, 컨벤션, 그리고 ArchUnit 테스트는
아래 깃허브 프로젝트에 정리해 두었다.

GitHub - ryu-qqq/claude-spring-standards