My Agent Skill for Test-Driven Development

TL;DR Highlight

AI 에이전트가 형편없는 테스트를 작성하는 문제를 해결하기 위해, Kent Beck의 Canon TDD 원칙을 'Skill'로 만들어 에이전트에게 주입하는 방법을 공유한다. 에이전트 코딩에서 테스트 품질을 높이고 싶은 개발자에게 실용적인 접근법을 제시한다.

Who Should Read

Claude Code, Cursor 등 AI 에이전트를 이용해 개발하면서 에이전트가 작성하는 테스트 품질이 낮아 고민인 개발자. 특히 Ruby on Rails 환경이지만, 원칙 자체는 어떤 언어/프레임워크에도 적용 가능하다.

Core Mechanics

AI 에이전트가 테스트를 못 짜는 건 단순히 모델 한계가 아니라, 학습 데이터인 인간이 작성한 테스트 자체가 형편없기 때문이다. 교육 자료에서 가르치는 테스팅 관행도 수준이 낮은 경우가 많다.
에이전트에게 그냥 'TDD로 작성해'라고만 해도 어느 정도 효과가 있지만, 구체적으로 'Kent Beck의 Canon TDD를 따르라'고 지시하면 약 60% 수준까지는 품질이 올라간다는 게 저자의 경험이다.
저자가 직접 만든 'Specify-Encode-Fulfill(SEF)' 루프는 기존 Red-Green-Refactor 대신 쓰는 개인적인 TDD 대안이다. Specify(무엇을 만들지 명세), Encode(명세를 자동화 테스트로 변환), Fulfill(테스트를 통과하는 코드 작성) 순서로 진행한다.
Canon TDD의 핵심은 현재 실패하는 테스트를 통과시키는 데 필요한 최소한의 코드만 작성하는 것이다. 필요 이상의 코드를 미리 작성하는 '투기적 코딩(speculative coding)'을 피해야 테스트로 커버되지 않는 코드가 생기지 않는다.
리팩터링은 반드시 동작 변경을 커밋한 이후에만 선택적으로 한다. 동작 변경과 리팩터링을 같은 커밋에 섞으면 안 된다는 규칙이 포함된다.
테스트 설계 자체를 검토하기 위해 'Test Design Review' 라는 별도 Skill을 만들었고, 이 Skill은 편향을 피하기 위해 별도의 에이전트를 spawning해서 원래 에이전트가 작성한 테스트의 설계 원칙 위반(예: 결과가 아닌 수단에 집중하는 테스트)을 찾아 수정 제안을 한다.
테스트뿐 아니라 일반 소프트웨어 설계 원칙('사물을 있는 그대로 명명하라' 등)도 적용하기 위해 'Software Design Review' Skill도 별도로 운용한다.
에이전트에게 '테스트를 짜기 어렵다면 코드 구조를 먼저 정리해야 한다는 신호일 수 있다'고 가르쳤더니, Claude가 이 원칙을 꽤 잘 따라서 스스로 멈추고 리팩터링이 필요한지 먼저 물어보는 행동을 보이고 있다.

Evidence

간단한 지시만으로도 충분하다는 반론이 있었다. 한 댓글에서는 'Claude Code와 Codex에게 단순히 "uv run pytest로 테스트하고, red/green TDD를 써"라고만 해도 최근엔 꽤 좋은 결과가 나온다'며, 별도의 복잡한 Skill이 필요한지 의문을 제기했다.
TDD가 토큰 비용을 급격히 늘린다는 실용적인 반론이 있었다. 기능이 자주 변경되거나 제거되는 프로젝트에서는 TDD를 적용하면 속도가 크게 느려지고 비용이 많이 든다는 경험을 공유했으며, 특히 멀티 에이전트 환경에서는 테스트가 실제 컴포넌트를 테스트하지 않는 '할루시네이션 테스트'나 false positive로 인한 의도치 않은 리팩터링이 발생했다는 사례도 있었다.
별도 에이전트를 통한 코드 리뷰 방식이 효과적이라는 경험 공유도 있었다. 한 댓글에서는 계획 단계에서 2~3라운드의 서브 에이전트 리뷰를 포함시키고, 중요한 코드의 경우 다른 프런티어 랩(예: Anthropic vs OpenAI)의 에이전트를 4번째 리뷰어로 쓰면 코드 품질이 눈에 띄게 향상되고 버그가 줄어든다고 했다. 토큰 비용은 더 들지만 나중에 버그를 고치는 것보다 효율적이라는 주장이었다.
Matt Pocock의 Skill 워크플로우를 소개하는 댓글도 있었다. /grill-with-docs → /to-prd → /to-issue → /tdd 순서로 진행하는 워크플로우인데, 공통 언어로 요구사항을 이해하고 → PRD(제품 요구사항 문서)를 작성하고 → 이슈를 만든 뒤 → TDD로 구현하는 체계적인 흐름이라는 설명이었다.
TDD 자체가 LLM 시대에는 나쁜 아이디어라는 강경한 반론도 있었다. 모델이 이미 버그 없는 전문가 수준의 코드를 안정적으로 작성하고 복잡한 버그도 빠르게 고칠 수 있는데, 테스트 작성에 드는 토큰 비용과 기술 부채가 그 가치를 못한다는 주장이었다. 반면 다른 댓글에서는 테스트가 에이전트를 올바른 방향으로 유지하는 '가장 큰 레버'라며 정반대 의견을 냈다.

How to Apply

Claude Code나 Cursor를 쓰는데 에이전트가 작성하는 테스트가 의미 없거나 형식적으로 느껴진다면, AGENTS.md나 .cursorrules에 'Kent Beck의 Canon TDD를 따르되, 현재 실패하는 테스트를 통과시키기 위한 최소한의 코드만 작성하고, 동작 변경과 리팩터링을 섞지 말라'는 지시를 추가해보자. 저자에 따르면 이것만으로도 품질이 크게 올라간다.
에이전트가 작성한 테스트의 설계 품질을 높이고 싶다면, 원래 에이전트와 별도로 두 번째 에이전트 세션을 열어서 '이 테스트들이 수단이 아닌 결과를 테스트하는지, 설계 원칙을 위반하는 부분은 없는지 검토해라'라고 요청해보자. 같은 에이전트에게 자기 코드를 리뷰시키는 것보다 별도 세션이 편향 없이 더 날카로운 피드백을 준다.
에이전트가 테스트를 작성하기 어렵다고 하거나 테스트 코드가 복잡해진다면, 이를 프로덕션 코드의 설계 문제를 알려주는 신호로 받아들여라. '테스트하기 어렵다면 코드를 먼저 리팩터링해야 한다는 신호다'라고 시스템 프롬프트에 명시하면, 에이전트가 스스로 멈추고 리팩터링 필요성을 먼저 확인하는 행동을 보이게 된다.
저자의 TDD Skill을 직접 사용하고 싶다면, GitHub에 공개된 파일(기사 내 링크 참조)을 내려받아 자신의 Claude 프로젝트나 Cursor 설정에 Skill로 등록하면 된다. 이미 살아있는 문서로 지속 업데이트되고 있어서 직접 fork해서 자신의 팀 상황에 맞게 수정하는 것도 좋다.

Terminology

Canon TDDKent Beck이 정의한 TDD의 '표준 형태'. 단순히 테스트를 먼저 쓰는 게 아니라, 명세 목록 작성 → 테스트 인코딩 → 최소 코드 작성 → 선택적 리팩터링의 엄격한 절차를 따르는 방식이다.

SkillAI 에이전트에게 특정 작업을 어떻게 수행할지 가르치는 재사용 가능한 지시문 묶음. 마치 사람에게 업무 매뉴얼을 주는 것처럼, 에이전트가 특정 상황에서 일관된 방식으로 행동하도록 만든다.

Speculative Coding현재 테스트를 통과하는 데 필요한 것 이상의 코드를 미리 작성하는 습관. '나중에 필요할 것 같아서' 작성한 코드는 테스트로 커버되지 않아 나중에 버그의 원인이 될 수 있다.

Tautological Test테스트가 자기 자신을 검증하는 의미 없는 테스트. 예를 들어 `user.name = 'Alice'`를 설정하고 바로 `expect(user.name).to eq('Alice')`를 검증하는 것처럼, 비즈니스 로직을 전혀 검증하지 않는 테스트를 말한다.

Red-Green-RefactorTDD의 전통적인 사이클. 실패하는 테스트 작성(Red) → 테스트를 통과하는 코드 작성(Green) → 코드 구조 개선(Refactor) 세 단계를 반복한다.

Spawning에이전트가 특정 작업을 위해 별도의 새로운 에이전트 세션을 생성하는 것. 원래 에이전트의 맥락과 편향으로부터 독립된 리뷰어를 만들기 위해 쓰인다.