HN이 EvanFlow에 반응한 이유는 TDD가 새로워서가 아니다. 오히려 반대다. 이미 다들 에이전트가 코드를 만질 수 있다는 전제는 받아들였고, 이제는 그 힘을 어떻게 통제하느냐가 더 중요한 질문이 됐다. GitHub README에 따르면 EvanFlow는 Claude Code 위에 16개 스킬과 2개 서브에이전트를 얹어 brainstorm → plan → execute → iterate → stop 루프를 만든다. 시작점은 하나지만, 중간중간 멈춰서 사용자가 승인하고 방향을 다시 잡게 설계돼 있다.

구조를 보면 이 프로젝트가 노리는 불편함이 분명하다. TDD를 구현 뒤 체크리스트로 붙이는 대신, 각 코드 작업 내부 규율로 넣는다. README는 한 번에 하나의 failing test를 쓰고, 최소 구현으로 green을 만들고, 방금 쓴 테스트를 안전망으로 삼아 바로 refactor하는 vertical-slice 흐름을 강조한다. 작업 단위가 3개 이상으로 갈라지면 parallel coder/overseer 경로로 전환해, 코더는 구현하고 오버시어는 읽기 전용 리뷰만 수행한다. 여기에 설계 승인, 계획 승인, 반복 점검 같은 체크포인트가 끼어 있다. 자동 질주보다 브레이크 장치가 앞에 서는 구성이다.

HN 댓글도 정확히 이 지점에서 갈렸다. 회의적인 쪽은 공식 Claude Code 스킬만으로도 TDD는 충분히 된다고 했고, 또 다른 사용자는 이름 붙인 래퍼가 하나 더 늘어나는 것 아니냐고 물었다. 반면 긍정적인 반응은 보호장치에 몰렸다. 자동 커밋을 하지 않고, 모든 git 쓰기 작업 앞에서 멈추고, 위험한 git 명령은 훅으로 막고, 병렬 작업에서는 integration test를 "실행 가능한 계약"으로 다루는 점이 눈에 들어왔다는 것이다. 한 댓글은 특히 병렬 에이전트의 진짜 문제를 잘 짚었다. 각 브랜치의 unit test는 통과해도, 합치는 순간 경계면이 깨진다는 얘기다.

그래서 이 스레드는 새 프레임워크 홍보보다 워크플로 논쟁에 가까웠다. HN이 지금 궁금해하는 것은 모델이 코드를 쓸 수 있느냐가 아니다. 문맥이 틀어지고, 범위가 새고, 자동화가 너무 앞서 나가서 사람이 치우는 시간이 더 커지는 상황을 어떻게 막느냐가 진짜 질문이다. EvanFlow의 매력은 능력을 과시하는 데 있지 않다. 멈춰야 할 곳을 아는 구조를 기능으로 내세운다는 데 있다. HN이 여기서 본 것도 바로 그 통제감이었다.

#tdd

Claude Code용 EvanFlow, HN이 꽂힌 건 자동화보다 통제감