EvanFlow – Claude Code를 위한 TDD 기반 반복 피드백 루프

Who Should Read

Claude Code를 이미 쓰고 있는 개발자 중, AI가 생성한 코드의 품질을 믿지 못해서 테스트나 검토 없이 커밋하기 불안한 분들에게 적합하다. 특히 혼자 또는 소규모 팀에서 AI 에이전트를 적극 활용하면서도 코드 규율을 유지하고 싶은 개발자를 위한 도구다.

Core Mechanics

• EvanFlow는 Claude Code 플러그인 마켓플레이스에서 '/plugin marketplace add evanklem/evanflow' 명령 하나로 설치할 수 있고, 설치 후 'let's evanflow this'라고 입력하면 전체 루프가 시작된다.
• 전체 흐름은 브레인스토밍 → 플랜 → 실행(vertical-slice TDD) → 반복 → STOP 순서로 진행되며, 각 단계마다 사람이 직접 승인해야 다음 단계로 넘어가는 체크포인트가 있다. git 커밋/스테이징/통합은 절대 자동으로 하지 않는다.
• Vertical-slice TDD(수직 슬라이스 TDD)란 기능 하나를 DB부터 UI까지 끊어서 구현하는 방식인데, EvanFlow는 이를 테스트 단위로 적용한다. 하나의 실패하는 테스트 작성 → 최소한의 구현 → 다음 테스트, 이 사이클을 반복하는 것이 핵심이다.
• HumanEval 연구에 따르면 LLM이 생성한 테스트 어서션(assertion, 결과 검증 코드)의 약 62%가 잘못되어 있다고 한다. 이 때문에 EvanFlow는 구현 규율보다 TDD 규율 자체를 더 엄격하게 강제한다.
• 브레인스토밍 단계에서 2~3가지 접근법을 제안하면서 동시에 'Embedded Grilling(내장된 스트레스 테스트)'을 수행한다. '유저가 X를 하면 뭐가 깨지나?', '롤백 방법은?', '명시적으로 제외할 범위는?' 같은 질문으로 설계 결함을 저렴하게 잡아낸다.
• 반복 단계는 최대 5라운드로 하드캡이 걸려 있고, 매 라운드마다 죽은 코드(dead code), 네이밍, Deletion Test(이 코드를 지워도 테스트가 잡는가), 어서션 정확도, 5가지 실패 모드(환각 동작, 스코프 크리프, 연쇄 오류, 맥락 손실, 도구 오용) 패스를 수행한다. UI가 있으면 headless Chromium으로 스크린샷도 찍는다.
• 독립적인 단위가 3개 이상이고 타입을 공유하는 큰 플랜의 경우, 병렬 coder/overseer 오케스트레이션 모드로 전환된다. 이 경우 터치포인트의 통합 테스트가 응집성 계약(cohesion contract) 역할을 한다.
• 16개의 스킬과 2개의 커스텀 서브에이전트로 구성되며, 스킬들은 evanflow: 네임스페이스 아래에 등록된다(예: /evanflow:evanflow-go). git 가드레일 훅도 플러그인 설치 시 자동으로 활성화된다.

Evidence

• Claude Code의 공식 superpowers/brainstorming 스킬이 이미 TDD를 잘 지원한다는 의견이 있었는데, 별도 도구가 필요한지 의문을 제기하는 댓글이 있었다. 이에 대한 직접적인 반박은 없었지만, 저자는 기본 에이전트가 TDD를 '기본으로' 수행하지 않는다는 점을 강조했다.
• TDD의 핵심 3단계인 RED-GREEN-REFACTOR 중 REFACTOR(리팩토링) 단계가 빠져 있다는 지적이 나왔다. 한 댓글은 '테스트가 그린(통과)이 되면 Claude는 다음 테스트로 넘어가도록 최적화되어 있어서, 방금 통과한 테스트를 안전망 삼아 리팩토링하는 게 아니라 나중에 식은 코드를 리팩토링하게 된다'며 이것이 본질적인 차이라고 지적했다.
• 실제로 TDD를 강제하고 싶다면 tdd-guard(https://github.com/nizos/tdd-guard)를 써보라는 대안이 공유됐다. 이 프로젝트는 프롬프트로 TDD를 유도하는 게 아니라 훅을 이용해 실제로 편집을 블로킹하는 방식이라, 컨텍스트가 길어져서 프롬프트가 희석(context rot)되는 문제를 근본적으로 차단한다는 게 핵심이다.
• 병렬 coder/overseer 모드에서 각 에이전트의 단위 테스트는 통과하지만 병합 시점에 인터페이스가 깨지는 문제를 지적하는 댓글이 있었다. 이를 해결하려면 각 병렬 브랜치마다 독립된 failing 테스트가 필요하고, worktree 격리(각 에이전트 환경을 완전히 분리)가 필수라는 구체적 방법이 제시됐다. 실제로 23개 에이전트를 쓰는 Claude Code 플러그인(tonone)을 만들면서 이 문제를 겪었다는 경험담도 공유됐다.
• 에이전트 루프가 길어질수록 초기 설계 컨텍스트가 날아가서 엉뚱한 방향으로 가는 'dumb zone' 문제에 대한 질문이 있었다. 컨텍스트 길이가 드리프트의 원인이며, RED-GREEN-REFACTOR 경계마다 리셋하면 사이클이 짧게 유지되어 이 문제를 피할 수 있다는 의견이 달렸다. EvanFlow의 5라운드 하드캡도 같은 직관에서 나온 장치라는 분석이다.

How to Apply

• Claude Code를 쓰다가 AI가 테스트 없이 구현을 막 쏟아내거나, 테스트를 작성해도 어서션이 엉터리인 경우가 잦다면 '/plugin marketplace add evanklem/evanflow' 로 설치한 뒤 'let's evanflow this — I want to add X feature'라고 시작해보면 된다. 브레인스토밍부터 TDD 루프까지 가이드를 받을 수 있다.
• 큰 기능을 개발할 때 AI에게 한 번에 다 맡겼다가 나중에 고치기 힘든 코드가 나오는 경험이 반복된다면, EvanFlow의 design approval → plan approval → iterate 체크포인트 구조를 활용해 각 단계에서 직접 방향을 잡아주는 방식으로 전환할 수 있다. 특히 설계 승인 시점에 'Embedded Grilling'으로 엣지 케이스를 미리 잡는 게 포인트다.
• TDD를 강제하고 싶은데 프롬프트 기반으로는 컨텍스트가 길어지면 흐지부지되는 경험을 했다면, EvanFlow와 병행해서 tdd-guard(https://github.com/nizos/tdd-guard)도 검토할 만하다. 훅 기반으로 편집 자체를 막아주기 때문에 컨텍스트 희석 문제를 근본적으로 차단한다.
• 3개 이상의 독립 모듈을 동시에 개발하는 상황이라면 EvanFlow의 병렬 coder/overseer 모드를 사용할 수 있다. 단, 병합 시 인터페이스 불일치 문제를 막으려면 각 브랜치에 touchpoint 통합 테스트를 먼저 작성해두고, 가능하면 git worktree로 환경을 격리하는 것이 중요하다.

Code Example

# Claude Code 플러그인 마켓플레이스로 설치 (권장)
/plugin marketplace add evanklem/evanflow
/plugin install evanflow@evanflow

# 재시작 후 사용
"Let's evanflow this — I want to add a small feature that does X."

# 또는 npx로 설치
npx skills add evanflow

# 스킬은 evanflow: 네임스페이스로 등록됨
/evanflow:evanflow-go

Terminology

Related Resources

• EvanFlow GitHub 저장소 (원본)
• tdd-guard – 훅 기반 TDD 강제 도구
• tonone – 23개 에이전트 Claude Code 플러그인 (병렬 worktree 활용 사례)