AI Agent를 위한 TDD(테스트 주도 개발) Skill 만들기
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
관련 논문
Anthropic의 오픈소스 AI 기반 취약점 자동 탐지 프레임워크 공개
Anthropic이 Claude를 활용해 코드 취약점을 자율적으로 탐지·트리아지·패치하는 오픈소스 레퍼런스 구현체를 공개했다. 실제 보안팀과의 협업 경험을 바탕으로 만들어진 파이프라인이라 실전 적용성이 높다.
에이전트는 스스로 물러날까? LLM 에이전트의 In-Band Access-Deny 신호 준수 측정
서버가 SSH 배너나 DB NOTICE로 'AI 에이전트는 접근하지 마세요' 신호를 보내면 GPT-4o, Claude Code 같은 LLM 에이전트가 실제로 물러나는지 실험으로 측정했다.
ToolChoiceConfusion: 신뢰할 수 있는 LLM 에이전트를 위한 Causal Minimal Tool Filtering
LLM 에이전트에 도구를 100개 다 보여주지 말고, 지금 당장 필요한 것 1개만 보여주면 성공률은 그대로에 토큰은 90% 절약된다.
Paseo – 오픈소스 코딩 에이전트 통합 인터페이스 (모바일/데스크탑/CLI 지원)
Claude Code, Codex, GitHub Copilot 등 여러 코딩 에이전트를 하나의 UI로 제어하는 오픈소스 프로젝트로, 로컬 데몬 방식으로 자기 머신에서 실행하면서 모바일에서도 접근할 수 있다.
AI Agent가 가능하게 한 적응형 Computer Worm
단일 GPU에서 돌아가는 오픈소스 LLM만으로 네트워크를 자율 전파하는 AI 웜을 실제로 구현해서, 이게 이론이 아닌 현실임을 증명했다.
LLM Agent로 Time Series Forecasting의 'Last Mile' 문제 해결하기
통계 모델이 만든 예측값을 휴일/캠페인/외부 이벤트 맥락을 반영해 실제 비즈니스에서 쓸 수 있는 수준으로 자동 보정해주는 LLM 에이전트 프레임워크.
ChatGPT for Google Sheets, 워크북 전체 데이터 유출 취약점 발견